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
Endpoint Handlespace Redundancy Protocol (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.
エンドポイントHandlespace冗長プロトコル（ENRP）は（RSerPool）の要件とアーキテクチャをプーリング信頼性の高いサーバーの機能を実現するために集約サーバアクセスプロトコル（至急）と連携して動作するように設計されています。 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
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
ENRP is designed to work in conjunction with ASAP [RFC5352] to accomplish the functionality of RSerPool as defined by its requirements [RFC3237].
ENRPはその要件[RFC3237]で定義されるようにRSerPoolの機能を達成するために、ASAP [RFC5352]と連動して動作するように設計されています。
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.
それは、すべてのプールハンドルを管理しているため、適切なときに、このドキュメントの残りの部分では、我々は、ENRPのhandlespace、または単にhandlespaceとしてこのRSerPoolレジストリサービスを指します。
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クライアントチャンネル：ASAPのユーザ（どちらかのプール要素（PE）またはプールユーザー（PU））はENRPのhandlespaceサービスを要求する通信チャネル。クライアントチャネルは通常、ホームENRPサーバと、よく知られているポート番号のトランスポート・アドレスによって定義されます。
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サーバは、このチャネルを介して他のサーバーに「グループキャスト」のメッセージを送ることができます。 「グループキャスト」では、送信サーバは、ポイントツーポイントストリーム制御伝送プロトコル（SCTP）を送信するサーバとピアとの間の関連の集合を介したメッセージの複数のコピーを、そのピア・サーバーのそれぞれに1を送信します。 「グループキャストは、」便利な1対多スタイルの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は、任意の時点で1台のホームENRPサーバを持たなければならない、とPEとそのホームENRPサーバの両方が、それらの間のこのマスター/スレーブの関係を追跡する必要があります。 PUは、そのホームENRPサーバとして利用できるENRPサーバのいずれかを選択する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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サーバとの間で送受信されるメッセージは、ASAPの一部であり、[RFC5352]で定義されています。 [RFC5354]で定義される共通フォーマットは、すべてのENRPと、ASAPメッセージに使用されます。
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ビットのワード境界で終了していない場合は、次の32ビットワード境界に全て「0」オクテットで埋められます。
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).
すべてのメッセージと同様に、下記のそれぞれの分野/パラメータは、ネットワークバイト順（最上位バイトが最初に送信されることを意味通称ビッグエンディアン）で送信されなければなりません。
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)
Figure 1
図1
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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID: 32 bits (unsigned integer)
送信サーバのID：32ビット（符号なし整数）
This is the ID of the ENRP server that sent this message.
これは、このメッセージを送ったENRPサーバのIDです。
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です。メッセージ（例えば、メッセージは、グループキャストサーバのグループである）は、個々のサーバーのために意図されていない場合、このフィールドは、すべて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です。このパラメータは、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.
このパラメータが存在する場合、それはこのメッセージの送信者のサーバ情報が含まれています（サーバー情報のパラメータは、[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サーバは、そのIDとしてランダムに生成され、非ゼロの32ビット符号なし整数を選択しなければならないとENRPサーバが再起動されるまで、この同じIDを使用しなければなりません。
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データのコピーを要求するために、そのピアの1つにこのメッセージを送信します。このメッセージは、通常、サーバの初期化または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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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'.
このメッセージの送信者がメッセージのみ受信機が所有しているのPEについての情報を要求している場合は「1」に設定してください。それ以外の場合は、「0」に設定します。
Sending Server's ID:
サーバーのIDを送信します：
See Section 2.1.
2.1節を参照してください。
Receiving Server's ID:
サーバーのIDを受信：
See Section 2.1.
2.1節を参照してください。
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.
PEER_NAME_TABLE_RESPONSEメッセージは、ピア・サーバの初期化またはhandlespace同期を支援するために、受信しPEER_NAME_TABLE_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 = 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) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M (More_to_send) Flag: 1 bit
M（More_to_send）フラグ：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」に設定します。
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.
メッセージの長さフィールドの値は、このメッセージの最後に任意のパディングをカバーしませんが、注意してください。
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つのプールエントリがこのメッセージに存在しなければなりません。 [RFC5354]のセクション3.9で定義され、TLVフォーマットで一つ以上のプール要素パラメータが続いているように、以下に示すように、各プール・エントリは、プール・ハンドルパラメーターで開始しなければなりません。
+---------------------------+
: Pool Handle :
+---------------------------+
: PE #1 :
+---------------------------+
: PE #2 :
+---------------------------+
: ... :
+---------------------------+
: PE #n :
+---------------------------+
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.
PEER_NAME_UPDATEメッセージがhandlespaceに登録、再登録、またはPEの登録解除を発表するすべてのピアサーバへのPEのホーム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 = 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
メッセージの長さフィールドの値は、このメッセージの最後に任意のパディングをカバーしませんが、注意してください。
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の要求されたアクションを示します。フィールドには、次のいずれかの値に設定する必要があります。
0x0000 - ADD_PE: Add or update the specified PE in the ENRP handlespace.
0000 - ADD_PE：ENRPのhandlespaceで指定されたPEを追加または更新します。
0x0001 - DEL_PE: Delete the specified PE from the ENRP handlespace.
0x0001 - 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によって予約されており、使用してはいけません。
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を指定します。
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.
PEER_LIST_REQUESTメッセージを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 = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
サーバーのIDを送信します：
See Section 2.1.
2.1節を参照してください。
Receiving Server's ID:
サーバーのIDを受信：
See Section 2.1.
2.1節を参照してください。
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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」に設定しなければなりません。このケースが発生した場合、メッセージは、任意のサーバ情報パラメータを含めることはできません。
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.
メッセージの長さフィールドの値は、このメッセージの最後に任意のパディングをカバーしませんが、注意してください。
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].
それぞれの送信者に知られているピアのサーバ情報パラメータが含まれています。サーバ情報パラメータは、[RFC5354]で定義されています。
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_INIT_TAKEOVERメッセージは、特定のピア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 = 0x07 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's 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です。
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_ACKメッセージはPEER_INIT_TAKEOVERメッセージの受信を確認し、それが引き継ぎに反対しないと引継開始に応答して送信されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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です。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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です。
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]で定義され、このパラメータは、報告されるエラー（複数可）のタイプを示します。
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]で定義されています。
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:
コミュニケーションの二つのタイプがENRPサーバの間で使用されています。
o point-to-point message exchanges from one ENPR server to a specific peer server, and
特定のピアサーバへの1台のENPRサーバからポイント・ツー・ポイント・メッセージ交換、O、及び
o announcements from one server to all its peer servers in the operational scope.
運用スコープ内のすべてのピア・サーバーへの1台のサーバからのお知らせO。
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サーバのチャネルを介して、「グループ・キャスト」を経由して送信されます。
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サービスを開始する必要がある手順を説明します。
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は、サーバーの存続期間中変わらないしなければなりません。サーバID [RFC4086]はランダムガイドラインに関するいくつかの情報を提供するように、通常、良好な32ビットの乱数は、十分であろう。
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空間から分離され、注意してください。
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.
開始サーバがサービスに自分自身をブートストラップするために、既存のピア・サーバーを使用しています。私たちは、このピア・サーバーメンター・サーバを呼び出します。
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.
複数の既存のピア・サーバーが指定されている場合は、開始サーバはそのメンター・サーバとしてそれらのいずれかを選択し、そのバックアップメンター・サーバとして他の人を維持しなければなりません。
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サービスを提供開始する必要があります。
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.
開始サーバは、MAX-TIME-NO-RESPONSEそれがENRP_LIST_REQUESTメッセージを送信終了タイマーたびに開始する必要があります。タイマーがメンターピアから応答を受信する前に満了する場合は、開始サーバは、現在のメンター・サーバとの対話を放棄すべきであり、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.
この要求を受信すると、メンターピアサーバは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メッセージを受信すると、開始サーバは、自身のピアリストを初期化するためのメッセージで運ばれたサーバ情報を使用しなければなりません。
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への応答を待っている）、それは開始することによって、要求を拒絶しなければなりませんサーバと「1」に設定Rフラグを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がメンターピアによって拒否された場合には、開始サーバは、メンター・サーバに数秒、再送信ENRP_LIST_REQUESTを待つべきか、利用可能なバックアップメンターピアが存在する場合、他のメンターピアサーバーを選択し、新しいメンター・サーバにENRP_LIST_REQUESTを送信します。
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.開始サーバは、最初の全体handlespaceが要求されていることを示し、「0」に設定Wフラグで、メンターピアにENRP_HANDLE_TABLE_REQUESTメッセージを送らなければなりません。
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.
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.
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:
ローカルhandlespaceデータベースにENRP_HANDLE_TABLE_RESPONSEメッセージからデータエントリを取り出すとき4.開始サーバは、次の規則を使用してメッセージで運ばれる各プールエントリを処理する必要があります。
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.
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.
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（複数可）を追加しなければなりません。
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.
プールがすでにローカルhandlespaceに存在し、プールのエントリでPE（s）が既にプールのメンバーである場合C.、開始サーバは、新しい情報で既存の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に展開されると、初期化処理が終了すると開始サーバは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データベースの初期化の途中である、またはそれは、現在、他のサーバーへのオープンあまりにも多くのダウンロードのセッションがあります。
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.
このような場合には、メンターピアが開始サーバによって要求を拒絶しなければなりませんし、「1」に設定Rフラグと、なしプールエントリを持つ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がメンターピアによって拒否された場合には、開始サーバは、メンター・サーバに数秒、再送信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を送信し終えるたびに開始する必要があります。このタイマーは、メンターピアから応答を受信せずに満了する場合は、開始サーバは、現在のダウンロードセッションを中止すべきであり、1が利用可能な場合、バックアップメンターピアとの新しいhandlespaceダウンロードを再起動します。
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.
同様に、「1」、それが送信するために、より多くのデータを持っていることを示すためにするMビットをセットENRP_HANDLE_TABLE_RESPONSE、およびメンターピアを送信した後、それがセッションタイマーを開始する必要があります。このタイマーが開始し、サーバーから別の要求を受信せずに満了する場合、メンターピアは、セッションの任意のリソースやレコードを一掃、セッションを中止すべきです。
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.
これは、そのローカルhandlespaceは、例えば、変更されたとき、そのピアに通知するENRPサーバによって使用される更新操作、新たなPEの添加のセットを含む、既存のPEの除去、プールまたは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 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.
ENRPサーバは、新たなPEの追加や既存のPEの変更を示す、「ADD_PE」に設定更新アクションフィールドを持つENRP_HANDLE_UPDATEメッセージ内のすべてのピアにこのアップデートを発表しなければなりません。 PEの完全な新しい情報とそれが属するプールは、それぞれ、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サーバは、送信側サーバーのIDフィールドに、そのサーバIDを記入し、（すなわち、すべて0）受信するサーバのIDを空白のままにする必要があります。
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.
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の属性を交換する必要があります。
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サーバは、既存のPEの除去を示し、DEL_PEに設定更新アクションフィールドとENRP_HANDLE_UPDATEメッセージ内のすべてのピアにPE除去を発表しなければなりません。 PEとプールの完全な情報が属するは、それぞれ、PEパラメータとプール・ハンドルをパラメータとメッセージに示されなければなりません。
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).
送信側サーバーは、送信サーバーのIDフィールドに、そのサーバIDを記入し、（すなわち、すべて0に設定）空白の受信サーバのIDを残しておく必要があります。
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.
ピアがhandlespaceでPEまたはプールを見つけることが失敗した場合、それは更なる行動を取るべきではありません。
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サーバは、その既知のピアのそれぞれの状態に内部記録を保持しなければなりません。このレコードは、サーバーの「ピアリスト」と呼ばれています。
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」に返信必要なフラグが設定されたENRP_PRESENCEメッセージを送らなければなりません。これは、その完全なサーバ情報を含む独自のENRP_PRESENCE（2.1節を参照）で応答する新しいピアを強制します。
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.
すべてのPEER-HEARTBEATサイクル秒、ENRPサーバはENRP_PRESENCEメッセージとそのすべてのピアにその継続的な存在を公表しなければなりません。 ENRP_PRESENCEメッセージに、ENRPサーバは、応答が必要とされないことを示し、「0」に「Replay_required」フラグを設定しなければなりません。
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を参照）のための彼らの内部変数「peer_last_heard」を更新するようになります。
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.
その既知のピアの各々のための内部変数「peer_last_heard」と、この変数の値を保持しなければならない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.
ピアがMAX-TIME-LAST-HEARD秒以上も聞かれていない場合は、ENRPサーバは、直ちにそのピアに「1」にReply_requestフラグが設定されたポイントツーポイント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.
送信に失敗したか、ピアがMAX-TIME-NO-RESPONSE秒後に応答しない場合は、ENRPサーバは、ピア・サーバが死んで考慮しなければならないし、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サーバの障害が発生した場合の動作を継続することができます。
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.
開始サーバが最初にそのすべてのピア・サーバーにENRP_INIT_TAKEOVERメッセージを送信することにより、買収調停プロセスを開始する必要があります。アナウンスが送信されたかのセクション3.1を参照してください。メッセージでは、開始サーバは、サーバのIDを送信し、ターゲットサーバーのIDを入力する必要があります。目標は一つだけ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メッセージを発表した後、開始するサーバーは、ターゲットサーバーのことを除いて、その知られているピアのそれぞれから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 indicates a false failure-detection case by the initiating server. The initiating server MUST stop the takeover operation by marking the target server as "active" and taking no further takeover actions.
1.ピアサーバが（それ自体が）ENRP_INIT_TAKEOVERメッセージに示されているターゲットサーバであると判断した場合、それはすぐにこの引き継ぎプロセスを停止しようとする試みに、すべてのピアENRPサーバにENRP_PRESENCEメッセージを発表しなければなりません。これは、開始サーバによって偽の障害検出場合を示しています。開始サーバが「アクティブ」としてターゲットサーバをマークし、それ以上の買収行動をとらないことでテークオーバー操作を停止する必要があります。
2. If the peer server finds that it has already started its own takeover arbitration process on the same target server, it MUST perform the following arbitration:
ピア・サーバーは、それがすでに同じターゲット・サーバー上で、独自の買収調停プロセスを開始したことを発見した場合2.、それは次の調停を実行する必要があります。
A. If the peer's server ID is smaller in value than the Sending
Server's ID in the arrived ENRP_INIT_TAKEOVER message, the
peer server MUST immediately abort its own take-over attempt
by taking no further takeover actions of its own. Moreover,
the peer MUST mark the target server as "not active" on its
internal peer list so that its status will no longer be
monitored by the peer, and reply to the initiating server
with an ENRP_INIT_TAKEOVER_ACK message.
B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER message.
B.そうでない場合、ピアはENRP_INIT_TAKEOVERメッセージを無視しなければなりません。
3. If the peer finds that it is neither the target server nor is in its own takeover process, the peer MUST: a) mark the target server as "not active" on its internal peer list so that its status will no longer be monitored by this peer, and b) MUST reply to the initiating server with an ENRP_INIT_TAKEOVER_ACK message.
3.ピアは、ターゲットサーバでもないことを発見したり、独自の引き継ぎ処理である場合、ピアはしなければならない：その状態はもはや監視されませんように、a）はその内部ピアリストの「アクティブでない」として、ターゲットサーバをマークこのピアにより、およびb）ENRP_INIT_TAKEOVER_ACKメッセージで開始サーバに返信しなければなりません。
Once the initiating server has received the ENRP_INIT_TAKEOVER_ACK message from all of its currently known peers (except for the target server), it MUST consider that it has won the arbitration and MUST proceed to complete the takeover, following the steps described in Section 3.5.2.
開始サーバが（ターゲット・サーバーを除く）は現在知られている全てのピアからENRP_INIT_TAKEOVER_ACKメッセージを受信したら、それは、セクション3.5.2で説明する手順を以下、それが調停に勝利したことを考慮しなければならないと買収を完了させるために進まなければなら。
However, if it receives an ENRP_PRESENCE from the target server at any point in the arbitration process, the initiating server MUST immediately stop the takeover process and mark the status of the target server as "active".
それは、調停プロセスの任意の時点で、ターゲットサーバからENRP_PRESENCEを受けた場合は、開始サーバーが直ちに引き継ぎ処理を停止し、「アクティブ」として対象サーバの状態をマークする必要があります。
The initiating ENRP server MUST first send, via an announcement, an ENRP_TAKEOVER_SERVER message to inform all its active peers that the takeover has been enforced. The target server's ID MUST be filled in the message. The initiating server SHOULD then remove the target server from its internal peer list.
開始ENRPサーバは、最初の買収が施行されたことを、すべてのアクティブなピアを知らせるために、発表を経て、ENRP_TAKEOVER_SERVERメッセージを送らなければなりません。ターゲットサーバのIDは、メッセージに記入しなければなりません。開始サーバは、その内部ピアリストから目的のサーバーを削除する必要があります。
Then, it SHOULD examine its local copy of the handlespace and claim ownership of each of the PEs originally owned by the target server, by following these steps:
次に、それは、以下の手順を実行して、元々ターゲットサーバが所有するPEのそれぞれのhandlespaceと主張所有権のローカルコピーを調べる必要があります：
1. mark itself as the Home ENRP server of each of the PEs originally owned by the target server;
元々ターゲットサーバが所有するPEのそれぞれのホームENRPサーバとして1.マークそのもの。
2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message, with the 'H' flag set to '1', to each of the PEs. This will trigger the PE to adopt the initiating sever as its new Home ENRP server.
2. PEのそれぞれに、「1」に設定「H」フラグで、ポイントツーポイントASAP_ENDPOINT_KEEP_ALIVEメッセージを送信します。これは、新しいホームENRPサーバとして切断開始を採用するPEの引き金となるでしょう。
When a peer receives the ENRP_TAKEOVER_SERVER message from the initiating server, it SHOULD update its local peer list and PE cache by following these steps:
ピアは、開始サーバからENRP_TAKEOVER_SERVERメッセージを受信すると、以下の手順を実行して、そのローカルピアリストとPEのキャッシュを更新する必要があります：
2. update the Home ENRP server of each PE in its local copy of the handlespace to be the sender of the message, i.e., the initiating server.
2.更新handlespaceのローカルコピー内の各PEのホームENRPサーバは、メッセージの送信者、すなわち、開始サーバすることができます。
Message losses or certain temporary breaks in network connectivity may result in data inconsistency in the local handlespace copy of some of the ENRP servers in an operational scope. Therefore, each ENRP server in the operational scope SHOULD periodically verify that its local copy of handlespace data is still in sync with that of its peers.
メッセージ損失またはネットワーク接続で一定の一時的な中断は、動作範囲内ENRPサーバのいくつかのローカルhandlespaceコピーにデータの矛盾をもたらすことができます。そのため、運用範囲内の各ENRPサーバは、定期的にhandlespaceデータのローカルコピーは、そのピアのそれと同期中であることを確認する必要があります。
This section defines the auditing and re-synchronization procedures for an ENRP server to maintain its handlespace data consistency.
このセクションでは、そのhandlespaceデータの一貫性を維持するためにENRPサーバの監査と再同期手順を定義します。
A checksum covering the data that should be the same is exchanged to figure out whether or not the data is the same.
同じでなければならないデータをカバーするチェックサムは、データが同じであるか否かを把握するために交換されます。
The auditing of handlespace consistency is based on the following procedures:
handlespace一貫性の監査は、以下の手順に基づいています。
1. An ENRP server SHOULD keep a separate PE checksum (a 16-bit integer internal variable) for each of its known peers and for itself. For an ENRP server with 'k' known peers, we denote these internal variables as "pe_checksum_pr0", "pe_checksum_pr1", ..., "pe_checksum_prk", where "pe_checksum_pr0" is the server's own PE checksum. The list of what these checksums cover and a detailed algorithm for calculating them is given in Section 3.6.2.
1】ENRPサーバは、その既知のピアのそれぞれについて、それ自体のために別々のPEチェックサム（16ビット整数内部変数）を保持すべきです。 「k」を知らピアとENRPサーバのために、私たちは「pe_checksum_pr0は、」サーバ自身のPEチェックサムである「pe_checksum_pr0」、「pe_checksum_pr1」、...、「pe_checksum_prk」、としてこれらの内部変数を表します。これらのチェックサムがカバーするもののリストと、それらを計算するためのアルゴリズムの詳細は、セクション3.6.2に記載されています。
2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST include in the message its current PE checksum (i.e., "pe_checksum_pr0").
ENRPサーバはENRP_PRESENCEを送出する2たびに、メッセージ内の現在PEチェックサム（すなわち、「pe_checksum_pr0」）を含まなければなりません。
3. When an ENRP server (server A) receives a PE checksum (carried in an arrived ENRP_PRESENCE) from a peer ENRP server (server B), server A SHOULD compare the PE checksum found in the ENRP_PRESENCE with its own internal PE checksum of server B (i.e., "pe_checksum_prB").
ENRPサーバ（サーバA）は、ピアENRPサーバ（サーバB）から（到着ENRP_PRESENCEで運ば）PEチェックサムを受信3.サーバAは、サーバの独自の内部PEチェックサムとENRP_PRESENCEに見出さPEチェックサムを比較する必要がありB（すなわち、 "pe_checksum_prB"）。
4. If the two values match, server A will consider that there is no handlespace inconsistency between itself and server B, and it should take no further actions.
4.二つの値が一致した場合、サーバーAは自身とサーバBとの間にはhandlespaceに矛盾がないことを考えるだろう、それはそれ以上の行動を取るべきではありません。
5. If the two values do NOT match, server A SHOULD consider that there is a handlespace inconsistency between itself and server B, and a re-synchronization process SHOULD be carried out immediately with server B (see Section 3.6.3).
二つの値が一致しない場合5.は、サーバーAは、（セクション3.6.3を参照）が自身とサーバB間のhandlespaceの矛盾があり、再同期処理は、サーバBですぐに実行されるべきであることを考慮すべきです。
When an ENRP server (server A) calculates an internal PE checksum for a peer (server B), it MUST use the following algorithm.
ENRPサーバ（サーバA）は、ピア（サーバB）のための内部PEチェックサムを計算するとき、それは次のアルゴリズムを使用しなければなりません。
Let us assume that in server A's internal handlespace, there are currently 'M' PEs that are owned by server B. Each of the 'M' PEs will then contribute to the checksum calculation with the following byte block:
：私たちは、サーバーAの内部handlespaceで、「M」のPEのそれぞれが、その後、次のバイトのブロックでチェックサム計算に貢献するサーバBによって所有されている「M」の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle string of the pool the PE belongs (padded with :
: zeros to next 32-bit word boundary, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Id (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, these are not TLVs. This byte block gives each PE a unique byte pattern in the scope. The 16-bit PE checksum for server B "pe_checksum_prB" is then calculated over the byte blocks contributed by the 'M' PEs one by one. The PE checksum calculation MUST use the Internet algorithm described in [RFC1071].
これらはTLVのではありません、注意してください。このバイト・ブロックは、各PEにスコープ内で一意バイトパターンを与えます。サーバB「pe_checksum_prB」の16ビットPEチェックサムは、その後、「M」のPE一つずつによって寄与バイト・ブロックに対して計算されます。 PEチェックサムの計算は、[RFC1071]に記載のインターネットアルゴリズムを使用しなければなりません。
Server A MUST calculate its own PE checksum (i.e., "pe_checksum_pr0") in the same fashion, using the byte blocks of all the PEs owned by itself.
サーバAは、自身が所有するすべてのPEのバイトブロックを用いて、同じ方法で、自身のPEチェックサム（すなわち、「pe_checksum_pr0」）を計算しなければなりません。
Note, whenever an ENRP finds that its internal handlespace has changed (e.g., due to PE registration/de-registration, receiving peer updates, removing failed PEs, downloading handlespace pieces from a peer, etc.), it MUST immediately update all its internal PE checksums that are affected by the change.
ENRPは、その内部handlespaceは（等、ピアの更新、削除失敗のPEを受信するピアからhandlespaceピースをダウンロード起因PE登録/登録解除のために、例えば、）変更されたことを検出するたびに、注意、それはすぐに更新すべての内部をしなければなりません変更によって影響を受けるPEチェックサム。
Implementation Note: when the internal handlespace changes (e.g., a new PE added or an existing PE removed), an implementation need not re-calculate the affected PE checksum; it can instead simply update the checksum by adding or subtracting the byte block of the corresponding PE from the previous checksum value.
実装注：内部handlespaceの変更（例えば、新しいPEが追加または既存のPEを除去）場合、実装は影響PEチェックサムを再計算する必要はありません。その代わりに、単に以前のチェックサム値から、対応するPEのバイトブロックを加算または減算することによってチェックサムを更新することができます。
If an ENRP server determines that there is inconsistency between its local handlespace data and a peer's handlespace data with regard to the PEs owned by that peer, it MUST perform the following steps to re-synchronize the data:
ENRPサーバは、そのピアが所有するPEに関しては、そのローカルhandlespaceデータとピアのhandlespaceデータの間に矛盾があると判断した場合は、再同期データには、次の手順を実行する必要があります。
1. The ENRP server SHOULD first "mark" every PE it knows about that is owned by the peer in its local handlespace database;
1.それはそれについて知っているすべてのPEは、そのローカルのhandlespaceデータベースにピアが所有しているENRPサーバSHOULD最初の「マーク」を。
2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST message with the W flag set to '1' to the peer to request a complete list of PEs owned by the peer;
2. ENRPサーバは、ピアが所有するPEの完全なリストを要求するピアに「1」に設定WフラグをENRP_HANDLE_TABLE_REQUESTメッセージを送信すべきです。
3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with the W flag set to '1', the peer server SHOULD immediately respond with an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently owned by the peer.
3.「1」に設定WフラグをENRP_HANDLE_TABLE_REQUESTメッセージを受信すると、ピア・サーバは直ちに現在のピアが所有するすべてのPEをリストENRP_HANDLE_TABLE_RESPONSEメッセージで応答する必要があります。
4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the ENRP server SHOULD transfer the PE entries carried in the message into its local handlespace database. If a PE entry being transferred already exists in its local database, the ENRP server MUST replace the entry with the copy found in the message and remove the "mark" from the entry.
4. ENRP_HANDLE_TABLE_RESPONSEメッセージを受信すると、ENRPサーバは、そのローカルhandlespaceデータベースにメッセージで運ばPEエントリを転送する必要があります。すでに転送されているPEエントリがそのローカルデータベースに存在する場合、ENRPサーバはメッセージで見つかったコピーを持つエントリを交換し、エントリから「マーク」を削除する必要があります。
5. After transferring all the PE entries from the received ENRP_HANDLE_TABLE_RESPONSE message into its local database, the ENRP server SHOULD check whether there are still PE entries that remain "marked" in its local handlespace. If so, the ENRP server SHOULD silently remove those "marked" entries.
5.そのローカルデータベースに受信ENRP_HANDLE_TABLE_RESPONSEメッセージからすべてのPEエントリを転送した後、ENRPサーバは、そのローカルhandlespaceに「マーク」のままPEエントリがまだあるかどうかをチェックする必要があります。もしそうなら、ENRPサーバは静かにそれらの「マーク」のエントリを削除する必要があります。
Note, similar to what is described in Section 3.2.3, the peer may reject the ENRP_HANDLE_TABLE_REQUEST or use more than one ENRP_HANDLE_TABLE_RESPONSE message to respond.
、メモセクション3.2.3に記載されているものと同様に、ピアはENRP_HANDLE_TABLE_REQUESTを拒否または応答する複数のENRP_HANDLE_TABLE_RESPONSEメッセージを使用してもよいです。
When an ENRP server receives an ENRP message with an unknown message type or a message of known type that contains an unknown parameter, it SHOULD handle the unknown message or the unknown parameter according to the unrecognized message and parameter handling rules defined in Sections 3 and 4 in [RFC5354].
ENRPサーバが不明なメッセージ・タイプまたは未知のパラメータが含まれている既知のタイプのメッセージでENRPメッセージを受信すると、セクション3と4で定義された認識されていないメッセージとパラメータハンドリングルールに従って、未知のメッセージ又は未知パラメータを処理します[RFC5354]インチ
According to the rules, if an error report to the message sender is needed, the ENRP server that discovered the error SHOULD send back an ENRP_ERROR message with a proper error cause code.
メッセージの送信者にエラーレポートが必要な場合は、ルールによると、エラーを発見しENRPサーバは、適切なエラー原因コードでENRP_ERRORメッセージを送り返すべきです。
peer_last_heard - The local time that a peer server was last heard (via receiving either a group-cast or point-to-point message from the peer).
peer_last_heard - ピア・サーバが最後に聞いたことを現地時間（グループキャスト又はピアからポイント・ツー・ポイント・メッセージのいずれかを受信介して）。
pe_checksum_pr - The internal 16-bit PE checksum that an ENRP server keeps for a peer. A separate PE checksum is kept for each of its known peers as well as for itself.
pe_checksum_pr - ENRPサーバはピアの保持する内部16ビットPEチェックサム。別PEチェックサムは、その既知のピアのそれぞれについて、ならびにそれ自体のために維持されます。
PEER-HEARTBEAT-CYCLE - The period for an ENRP server to announce a heartbeat message to all its known peers. (Default=30 secs.)
PEER-HEARTBEAT-CYCLE - ENRPサーバのための期間は、そのすべての既知のピアへのハートビートメッセージを発表します。 （デフォルト= 30秒）。
MAX-TIME-LAST-HEARD - Pre-set threshold for how long an ENRP server will wait before considering a silent peer server potentially dead. (Default=61 secs.)
MAX-TIME-LAST-HEARD - ENRPサーバはサイレントピア・サーバーは、潜在的に死んで検討する前に待機する時間の事前設定されたしきい値。 （デフォルト= 61秒）。
MAX-TIME-NO-RESPONSE - Pre-set threshold for how long a message sender will wait for a response after sending out a message. (Default=5 secs.)
MAX-TIME-NO-RESPONSE - メッセージの送信者がメッセージを送信した後の応答を待機する時間の事前設定されたしきい値。 （デフォルト= 5秒）。
This document (RFC 5353) is the reference for all registrations described in this section. All registrations have been listed on the RSerPool Parameters page.
この文書（RFC 5353）は、このセクションで説明するすべての登録のための基準です。すべての登録はRSerPoolパラメータページに記載されてきました。
ENRP Message Types are maintained by IANA. Ten initial values have been assigned by IANA, as described in Figure 1. IANA created a new table, "ENRP Message Types":
ENRPメッセージタイプはIANAによって維持されています。テン初期値は、図1 IANAで説明したように、IANAによって割り当てられているが、新しいテーブルを作成し、「ENRPメッセージタイプ」：
Type Message Name Reference
----- ------------------------- ---------
0x00 (Reserved by IETF) RFC 5353
0x01 ENRP_PRESENCE RFC 5353
0x02 ENRP_HANDLE_TABLE_REQUEST RFC 5353
0x03 ENRP_HANDLE_TABLE_RESPONSE RFC 5353
0x04 ENRP_HANDLE_UPDATE RFC 5353
0x05 ENRP_LIST_REQUEST RFC 5353
0x06 ENRP_LIST_RESPONSE RFC 5353
0x07 ENRP_INIT_TAKEOVER RFC 5353
0x08 ENRP_INIT_TAKEOVER_ACK RFC 5353
0x09 ENRP_TAKEOVER_SERVER RFC 5353
0x0a ENRP_ERROR RFC 5353
0x0b-0xff (Available for assignment) RFC 5353
Requests to register an ENRP Message Type in this table should be sent to IANA. The number must be unique. The "Specification Required" policy of [RFC5226] MUST be applied.
この表にENRPメッセージタイプを登録するための要求はIANAに送られるべきです。番号は一意である必要があります。 [RFC5226]の「仕様が必要である」というポリシーが適用されなければなりません。
Update Types are maintained by IANA. Two initial values have been assigned by IANA. IANA created a new table, "Update Action Types":
更新タイプはIANAによって維持されています。 2つの初期値は、IANAによって割り当てられています。 IANAは新しいテーブルを作成し、「更新アクション・タイプ」：
Type Update Action Reference
------------- -------------------- ---------
0x0000 ADD_PE RFC 5353
0x0001 DEL_PE RFC 5353
0x0002-0xffff (Available for assignment) RFC 5353
Requests to register an Update Action Type in this table should be sent to IANA. The number must be unique. The "Specification Required" policy of [RFC5226] MUST be applied.
この表の更新アクションタイプを登録するための要求はIANAに送られるべきです。番号は一意である必要があります。 [RFC5226]の「仕様が必要である」というポリシーが適用されなければなりません。
The references for the already assigned port numbers
すでに割り当てられたポート番号の参照
enrp-udp 9901/udp
ENRP-UDP 9901 / UDP
enrp-sctp 9901/sctp
ENRP-SCTP 9901 / SCTP
enrp-sctp-tls 9902/sctp
ENRP-SCTP-TLS 9902 / SCTP
have been updated to RFC 5353.
RFC 5353に更新されました。
The reference for the already assigned ENRP payload protocol identifier 12 have been updated to RFC 5353.
既に割り当てられたENRPペイロードプロトコル識別子12のための基準は、RFC 5353に更新されています。
We present a summary of the threats to the RSerPool architecture and describe security requirements in response to mitigate the threats. Next, we present the security mechanisms, based on TLS, that are implementation requirements in response to the threats. Finally, we present a chain-of-trust argument that examines critical data paths in RSerPool and shows how these paths are protected by the TLS implementation.
私たちは、RSerPoolアーキテクチャに対する脅威の概要を提示し、脅威を軽減するために応じて、セキュリティ要件を記述します。次に、我々は脅威に対応して実装要件ですTLSに基づくセキュリティメカニズムを、提示します。最後に、我々はRSerPoolに重要なデータ・パスを調べて、これらのパスは、TLSの実装により保護されている方法を示しチェーン・オブ・信頼引数を提示します。
"Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats" [RFC5355] describes the threats to the RSerPool architecture in detail and lists the security requirements in response to each threat. From the threats described in this document, the security services required for the RSerPool protocol are enumerated below.
「脅威に対応するセキュリティのための信頼できるサーバプーリング（RSerPool）と要件によって導入脅威」[RFC5355]は詳細にRSerPoolアーキテクチャへの脅威について説明し、それぞれの脅威に対応してセキュリティ要件を示しています。この文書で説明脅威から、RSerPoolプロトコルに必要なセキュリティサービスは、以下に列挙されています。
Threat 1) PE registration/de-registration flooding or spoofing
-----------
Security mechanism in response: ENRP server authenticates the PE.
Threat 2) PE registers with a malicious ENRP server
-----------
Security mechanism in response: PE authenticates the ENRP server.
Threats 1 and 2, taken together, result in mutual authentication of the ENRP server and the PE.
脅威1および2は、一緒になって、ENRPサーバとPEの相互認証をもたらします。
Threat 3) Malicious ENRP server joins the ENRP server pool
-----------
Security mechanism in response: ENRP servers mutually authenticate.
Threat 4) A PU communicates with a malicious ENRP server for handle
resolution
-----------
Security mechanism in response: The PU authenticates the ENRP server.
Threat 5) Replay attack
-----------
Security mechanism in response: Security protocol that has protection
from replay attacks.
Threat 6) Corrupted data that causes a PU to have misinformation
concerning a pool handle resolution
-----------
Security mechanism in response: Security protocol that supports
integrity protection
Threat 7) Eavesdropper snooping on handlespace information
-----------
Security mechanism in response: Security protocol that supports data
confidentiality.
Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to
ENRP server
-----------
Security mechanism in response: ASAP must control the number of ASAP endpoint unreachable messages transmitted from the PU to the ENRP server.
応答のセキュリティ・メカニズム：できるだけ早くENRPサーバにPUから送信できるだけ早くエンドポイント到達不能メッセージの数を制御しなければなりません。
Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
the ENRP server
-----------
Security mechanism in response: ENRP server must control the number
of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE.
To summarize, threats 1-7 require security mechanisms that support authentication, integrity, data confidentiality, and protection from replay attacks.
要約すると、脅威1-7は、セキュリティ認証をサポートするメカニズムを、整合性、データの機密性、およびリプレイ攻撃からの保護を必要とします。
For RSerPool, we need to authenticate the following:
RSerPoolのために、私たちは次のことを認証する必要があります。
PU <---- ENRP server (PU authenticates the ENRP server)
PE <----> ENRP server (mutual authentication)
ENRP server <-----> ENRP server (mutual authentication)
We do not define any new security mechanisms specifically for responding to threats 1-7. Rather, we use an existing IETF security protocol, specifically [RFC3237], to provide the security services required. TLS supports all these requirements and MUST be implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported, at a minimum, by implementers of TLS for RSerPool. For purposes of backwards compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other IETF-approved ciphersuites.
我々は、具体的な脅威1-7に対応するため、新たなセキュリティ・メカニズムを定義していません。むしろ、我々は必要なセキュリティサービスを提供するために、既存のIETFセキュリティプロトコル、特に[RFC3237]を使用します。 TLSは、これらすべての要件をサポートし、実装しなければなりません。 TLS_RSA_WITH_AES_128_CBC_SHAの暗号スイートはRSerPoolのためのTLSの実装によって、最低限、サポートしなければなりません。後方互換性の目的のために、ENRPはTLS_RSA_WITH_3DES_EDE_CBC_SHAをサポートする必要があります。実装者はまた、他のIETF承認の暗号スイートをサポートするかもしれません。
ENRP servers, PEs, and PUs MUST implement TLS. ENRP servers and PEs MUST support mutual authentication using PSK. ENRP servers MUST support mutual authentication among themselves using PSK. PUs MUST authenticate ENRP servers using certificates.
ENRPサーバは、PEを、とのPUは、TLSを実装しなければなりません。 ENRPサーバとPEはPSKを使用して相互認証をサポートしなければなりません。 ENRPサーバは、PSKを使用してそれらの間で相互認証をサポートしなければなりません。 PUが証明書を使用してENRPサーバを認証する必要があります。
TLS with PSK is mandatory to implement as the authentication mechanism for ENRP to ENRP authentication and PE to ENRP authentication. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool. The justification for PSK is that we assume that one administrative domain will control and manage the server pool. This allows for PSK to be implemented and managed by a central security administrator.
PSKとTLS認証をENRPする認証およびPEをENRPするENRPの認証機構として実装することが必須です。 PSKのために、事前共有キーを有する許可を構成しています。プールのネットワーク管理者は、プールに参加することを許可されているノードを決定する必要があります。 PSKのための正当化は、我々は1つの管理ドメインは、サーバー・プールを制御し、管理することを前提としていることです。 PSKが実装され、中央のセキュリティ管理者によって管理されるためこれができます。
TLS with certificates is mandatory to implement as the authentication mechanism for PUs to the ENRP server. PUs MUST authenticate ENRP servers using certificates. ENRP servers MUST possess a site certificate whose subject corresponds to their canonical hostname. PUs MAY have certificates of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use. All RSerPool elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably, well-known distributors of site certificates comparable to those that issue root certificates for web browsers).
証明書とTLSはENRPサーバへのPUのための認証機構として実装するために必須です。 PUが証明書を使用してENRPサーバを認証する必要があります。 ENRPサーバは、その対象と彼らの正規のホスト名に対応して、サイトの証明書を持っている必要があります。 PUは、TLSとの相互認証のために自分自身の証明書を持っているかもしれませんが、何の規定は、その使用については、このドキュメントに記載されていません。 TLSをサポートするすべてのRSerPool要素は、TLSネゴシエーション中に受信した証明書を検証するためのメカニズムを持っている必要があります。これは、認証局によって発行された一つ以上のルート証明書の所持を伴う（好ましくは、Webブラウザ用のルート証明書を発行するものと同等のサイト証明書のよく知られた代理店）。
In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). The client's understanding of the server's identity (typically the identity used to establish the transport connection) is called the "reference identity". The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped; however, the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName of type dNSName) or for which the mapping is performed in a secure manner (e.g., using DNS Security (DNSSEC), or using user- or admin-configured host-to-address/ address-to-host lookup tables).
（サーバのCertificateメッセージに提示される）man-in-the-middle攻撃を防ぐために、クライアントはサーバーの身元を確かめなければなりません。サーバーのID（トランスポート接続を確立するために使用される一般的アイデンティティ）のクライアントの理解は「基準アイデンティティ」と呼ばれています。クライアントは、基準同一のタイプ（例えば、DNS名またはIPアドレス）を決定し、基準アイデンティティとマッチが生成されるまで、対応するタイプのそれぞれのsubjectAltName値との比較を行います。試合が生成されると、サーバの身元が確認された、およびサーバのIDチェックが完了しています。異なるのsubjectAltNameタイプが異なる方法で一致しています。クライアントは、前の比較を実行する異なるタイプの参照IDをマッピングすることができます。マッピングは、リファレンスアイデンティティをマッピングすることができるに利用可能なすべてのsubjectAltNameタイプに対して実行されてもよいです。しかし、基準IDは唯一のマッピングがされているタイプのいずれか、本質的に安全な（例えば、型のdNSNameののsubjectAltNameと比較するURIからDNS名を抽出する）、またはそのためのマッピングは、安全な方法で行われる（にマッピングされなければなりません例えば、DNSセキュリティ（DNSSEC）、またはUSER-または管理者が設定したホストからアドレス/アドレスからホストへのルックアップテーブルを使用）を使用。
If the server identity check fails, user-oriented clients SHOULD either notify the user or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect, or both. Beyond the server identity check described in this section, clients should be prepared to do further checking to ensure that the server is authorized to provide the service it is requested to provide. The client may need to make use of local policy information in making this determination.
サーバーIDチェックが失敗した場合、ユーザー指向のクライアントは、いずれかをユーザに通知したり、輸送接続を閉じ、サーバのアイデンティティが疑わしいであることを示す必要があります。自動化されたクライアントは、トランスポート接続をクローズして、サーバのアイデンティティが疑わしい、またはその両方であることを示すエラーを返すか、ログインする必要があります。このセクションで説明するサーバIDチェックを越えて、クライアントはさらに、サーバは、提供するように要求されたサービスを提供することを許可されていることを確認するチェックを行うために準備する必要があります。クライアントは、この決意を行う際に、ローカルポリシー情報を利用するために必要があるかもしれません。
If the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format, as specified in Section 4 of [RFC3490], before comparison with subjectAltName values of type dNSName. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of [RFC3490] as follows: * in step 1, the domain name SHALL be considered a "stored string"; * in step 3, set the flag called "UseSTD3ASCIIRules"; * in step 4, process each label with the "ToASCII" operation; and * in step 5, change all label separators to U+002E (full stop).
基準IDは国際化ドメイン名である場合型のdNSNameののsubjectAltName値と比較する前に、[RFC3490]のセクション4で指定されるように、適合実装は、ASCII互換エンコーディング（ACE）形式に変換しなければなりません。具体的には、以下のよう適合実装は、[RFC3490]のセクション4で指定された変換操作を実行しなければなりません：*ステップ1で、ドメイン名が「記憶された文字列」と見なさなければなりません。 *ステップ3で、「UseSTD3ASCIIRules」と呼ばれるフラグを設定します。 *工程4、工程「もしToASCII」操作で各ラベルにおいて、そして*ステップ5で、U + 002E（フルストップ）に、すべてのラベルの区切りを変更します。
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality according to the rules specified in Section 3 of RFC 3490. The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then, only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
「へ-ASCII」変換を行った後、DNSラベルと名前が「*」（ASCII 42）ワイルドカード文字は型のdNSNameののsubjectAltName値で許可されているRFC 3490のセクション3で指定された規則に従って等しいかどうかを比較しなければなりません、次に、その値だけでは、一番左の（最下位）DNSラベルとして。このワイルドカードは、サーバー名に任意の一番左のDNSラベルと一致します。つまり、対象* .example.comとは、サーバー名a.example.comとb.example.comと一致しますが、example.comまたはa.b.example.comと一致していないです。
When the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation RFC 791 [RFC0791] and RFC 2460 [RFC2460]. For IP version 4, as specified in RFC 791, the octet string will contain exactly four octets. For IP version 6, as specified in RFC 2460, the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical.
基準IDはIPアドレスである場合、同一性「とは、ネットワークバイト順」オクテットストリング表現RFC 791 [RFC0791]及びRFC 2460 [RFC2460]に変換されなければなりません。 IPバージョン4の場合、RFC 791で指定されているように、オクテット文字列は正確に4オクテットを含んでいます。 IPバージョン6の場合は、RFC 2460で指定されているように、オクテット文字列は、正確に16オクテットを含んでいます。このオクテット文字列は、その後のタイプIPアドレスののsubjectAltName値と比較されます。参照アイデンティティオクテット文字列と値のオクテット文字列が同一である場合、一致が発生します。
After a TLS layer is established in a session, both parties are to independently decide whether or not to continue based on local policy and the security level achieved. If either party decides that the security level is inadequate for it to continue, it SHOULD remove the TLS layer immediately after the TLS (re)negotiation has completed (see RFC 4511)[RFC4511]. Implementations may re-evaluate the security level at any time and, upon finding it inadequate, should remove the TLS layer.
TLS層はセッション中に確立された後、両当事者は独立して、ローカルポリシーと達成セキュリティレベルに基づいて継続するかどうかを決定することです。いずれかの当事者がそれを継続するために、セキュリティレベルが不十分であると判断した場合は、すぐにTLS（再）交渉の後にTLS層を削除する必要があります（RFC 4511を参照してください）[RFC4511]を完了しました。実装はTLS層を除去する必要があり、それが不十分な発見時に、任意の時点でセキュリティレベルを再評価します。
Implementations MUST support TLS with SCTP, as described in [RFC3436] or TLS over TCP, as described in [RFC5246]. When using TLS/SCTP we must ensure that RSerPool does not use any features of SCTP that are not available to a TLS/SCTP user. This is not a difficult technical problem, but simply a requirement. When describing an API of the RSerPool lower layer, we also have to take into account the differences between TLS and SCTP.
TCP上に[RFC3436]またはTLSに記載されているように[RFC5246]で説明されるような実装は、SCTPとTLSをサポートしなければなりません。 TLS / SCTPを使用した場合、我々はRSerPoolは、TLS / SCTPユーザに利用できないSCTPのすべての機能を使用していないことを確認する必要があります。これは困難な技術的問題ではなく、単に必要条件ではありません。 RSerPool下層のAPIを説明するとき、我々も考慮にTLSおよびSCTPの違いを取らなければなりません。
Threat 8 requires the ASAP protocol to limit the number of ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 of RFC 5352) to the ENRP server.
脅威8はENRPサーバへASAP_ENDPOINT_UNREACHABLEメッセージ（RFC 5352のセクション3.5を参照）の数を制限するために、できるだけ早くプロトコルを必要とします。
Threat 9 requires the ENRP protocol to limit the number of ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE.
脅威9は、ENRPサーバからPEへASAP_ENDPOINT_KEEP_ALIVEメッセージの数を制限するENRPプロトコルを必要とします。
There is no security mechanism defined for the multicast announcements. Therefore, a receiver of such an announcement cannot consider the source address of such a message to be a trustworthy address of an ENRP server. A receiver must also be prepared to receive a large number of multicast announcements from attackers.
マルチキャストアナウンスメント用に定義されたセキュリティメカニズムはありません。したがって、そのような発表の受信機は、ENRPサーバの信頼アドレスにそのようなメッセージの送信元アドレスを考慮することができません。受信機はまた、攻撃者からのマルチキャストアナウンスの多数を受け取るように準備されなければなりません。
Security is mandatory to implement in RSerPool and is based on TLS implementation in all three architecture components that comprise RSerPool -- namely PU, PE, and the ENRP server. We define an ENRP server that uses TLS for all communication and authenticates ENRP peers and PE registrants to be a secured ENRP server.
セキュリティはRSerPoolに実装するために必須であり、RSerPoolを含むすべての3つのアーキテクチャコンポーネントでTLSの実装に基づいている - すなわち、PU、PE、およびENRPサーバ。我々は、すべての通信のためにTLSを使用してピアとPEの登録は、保護されたENRPサーバであることがENRP認証ENRPサーバを定義します。
Here is a description of all possible data paths and a description of the security.
ここでは、すべての可能なデータパスの記述とセキュリティの記述があります。
PU <---> secured ENRP server (authentication of ENRP server;
queries over TLS)
PE <---> secured ENRP server (mutual authentication;
registration/de-registration over TLS)
secured ENRP server <---> secured ENRP server (mutual authentication;
database updates using TLS)
If all components of the system authenticate and communicate using TLS, the chain of trust is sound. The root of the trust chain is the ENRP server. If that is secured using TLS, then security will be enforced for all ENRP and PE components that try to connect to it.
システムのすべてのコンポーネントが認証及びTLSを使用して通信する場合は、信頼の連鎖は、音です。信頼チェーンのルートは、ENRPサーバです。それは、TLSを使用して保護されている場合、セキュリティは、接続しようとするすべてのENRPとPEのコンポーネントに適用されます。
Summary of interaction between secured and unsecured components: If the PE does not use TLS and tries to register with a secure ENRP server, it will receive an error message response indicated as an error due to security considerations and the registration will be rejected. If an ENRP server that does not use TLS tries to update the database of a secure ENRP server, then the update will be rejected. If a PU does not use TLS and communicates with a secure ENRP server, it will get a response with the understanding that the response is not secure, as the response can be tampered with in transit even if the ENRP database is secured.
固定され保護されていない構成要素間の相互作用の概要：PEは、TLSを使用して安全なENRPサーバに登録しようとしない場合は、エラーメッセージ応答を受信するによるセキュリティ問題にエラーとして示され、登録は拒否されます。 TLSを使用しないENRPサーバが安全なENRPサーバのデータベースを更新しようとする場合、更新は拒否されます。 PUは、TLSを使用し、安全なENRPサーバと通信していない場合は、応答がENRPデータベースが確保されている場合でも、中に改ざんすることができますよう、応答は、セキュリティで保護されていないことを理解した上で応答を取得します。
The final case is the PU sending a secure request to ENRP. It might be that ENRP and PEs are not secured and this is an allowable configuration. The intent is to secure the communication over the Internet between the PU and the ENRP server.
最後のケースは、PUがENRPに安全な要求を送信します。それはENRPとPEが確保されていないことかもしれないし、これは許容できる構成です。その意図は、PUとENRPサーバ間のインターネットを介した通信を確保することです。
Summary:
概要：
RSerPool architecture components can communicate with each other to establish a chain of trust. Secured PE and ENRP servers reject any communications with unsecured ENRP or PE servers.
RSerPoolアーキテクチャコンポーネントは、信頼の連鎖を確立するために互いに通信することができます。担保PEとENRPサーバは、無担保ENRPまたはPEサーバーとのすべての通信を拒否します。
If the above is enforced, then a chain of trust is established for the RSerPool user.
上記が適用されている場合には、信頼の連鎖はRSerPoolのユーザーのために確立されています。
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, Thomas Dreibholz, Frank Volkmer, and many others for their invaluable comments and feedback.
作者は彼らの貴重なコメントやフィードバックのためにジョンLoughney、リンドンオング、ウォルター・ジョンソン、トーマスDreibholz、フランクVolkmer、および多くの他に感謝したいです。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071]ブレーデン、R.、ボーマン、D.、ヤマウズラ、C.、およびW.プラマー、 "インターネットチェックサムの計算"、RFC 1071、1988年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002.
[RFC3237] Tuexen、M.、謝、Q.、スチュワート、R.、ショア、M.、オング、L.、Loughney、J.、およびM.スティルマン、 "信頼できるサーバプーリングのための要件"、RFC 3237年1月2002。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、レスコラ、E.、およびM. Tuexen、 "ストリーム制御伝送プロトコルを介してトランスポート層セキュリティ"、RFC 3436、2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, September 2008.
[RFC5354]スチュワート、R.、謝、Q.、スティルマン、M.、およびM. Tuexen、 "集計サーバアクセスプロトコル（ASAP）から印刷して、エンドポイントHandlespace冗長プロトコル（ENRP）パラメータ"、RFC 5354、2008年9月。
[RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, September 2008.
[RFC5352]スチュワート、R.、謝、Q.、スティルマン、M.、およびM. Tuexen、 "集計サーバアクセスプロトコル（至急）"、RFC 5352、2008年9月。
[RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege, M., and S. Sengodan, "Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats", RFC 5355, September 2008.
[RFC5355]スティルマンが、M.編、ゴパル、R.、ガットマン、E.、ホールドレッジ、M.、およびS. Sengodanは、 "脅威脅威に応答して信頼できるサーバプーリング（RSerPool）とセキュリティ要件によって導入されました" 、RFC 5355、2008年9月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[SCTPSOCKET] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Work in Progress, July 2008.
[SCTPSOCKET]スチュワート、R.、プーン、K.、Tuexen、M.、Yasevich、V.、およびP.レイ、進歩、2008年7月に作品 "ストリーム制御伝送プロトコル（SCTP）のためのソケットAPIの拡張機能"。
Authors' Addresses
著者のアドレス
Qiaobing Xie The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA
オリンピックアイスQ私はIEにWスイート560ワシントンD.C.、20006 USA専用リソース・グループ1700年ペンシルベニア州AVをX
Phone: +1 224-465-5954 EMail: Qiaobing.Xie@gmail.com
電話：+1 224-465-5954電子メール：Qiaobing.Xie@gmail.com
Randall R. Stewart The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA
ランドールR.スチュワートザ・リソース・グループ1700ペンシルバニアアベニューNWスイート560ワシントンD.C.、20006 USA
Phone: EMail: randall@lakerest.net
電話番号：Eメール：randall@lakerest.net
Maureen Stillman Nokia 1167 Peachtree Ct. Naperville, IL 60540 US
モーリーンスティルマンノキア1167ピーチツリーのCt。ネーパーヴィル、IL 60540米国
Phone: EMail: maureen.stillman@nokia.com
電話番号：Eメール：maureen.stillman@nokia.com
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
マイケルTuexenミュンスター大学。応用科学Stegerwaldstrの。 39 48565シュタインフルトドイツ
EMail: tuexen@fh-muenster.de
メールアドレス：tuexen@fh-muenster.de
Aron J. Silverton Sun Microsystems, Inc. 10 S. Wacker Drive Suite 2000 Chicago, IL 60606 USA
アロンJ.シルバーサン・マイクロシステムズ株式会社10 S.ワッカードライブスイート2000シカゴ、IL 60606 USA
Phone: EMail: ajs.ietf@gmail.com
電話番号：Eメール：ajs.ietf@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。