[要約] RFC 5353は、ENRP（Endpoint Handlespace Redundancy Protocol）に関する規格であり、エンドポイントの冗長性を提供するためのプロトコルです。その目的は、ネットワーク上のエンドポイントの冗長性を確保し、信頼性と可用性を向上させることです。
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)
エンドポイントハンドルスペース冗長性プロトコル（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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
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.
エンドポイントハンドルスペース冗長プロトコル（ENRP）は、信頼できるサーバープーリング（RSERPOOL）要件とアーキテクチャの機能を達成するために、Aggregate Server Access Protocol（ASAP）と組み合わせて動作するように設計されています。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]で定義されているように、ASAP [RFC5352]と組み合わせて[RFC5352]と組み合わせて動作するように設計されています[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.
適切な場合はいつでも、このドキュメントの残りの部分では、すべてのプールハンドルを管理するため、このRSERPOOLレジストリサービスをENRPハンドルスペース、または単にハンドルスペースと呼びます。
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ハンドルスペースサービスを要求する通信チャネル。クライアントチャネルは通常、Home Endpサーバーの輸送アドレスと有名なポート番号によって定義されます。
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）関連のセットを介して、各ピアサーバーにメッセージの複数のコピーを送信します。。「Group-Cast」は、1対Manyスタイルの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.
Home Entrp Server：PEまたはPUが現在属しているENRPサーバー。PEは、いつでも1つのホームENRPサーバーのみを備えている必要があり、PEとそのホームENTRPサーバーの両方が、それらの間のこのマスター/スレーブの関係を追跡する必要があります。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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
ほとんどのENTRPメッセージには、固定フィールドとTLV（型-Length-Value）パラメーターの組み合わせが含まれています。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).
すべてのメッセージ、および以下に説明するフィールド/パラメーターは、ネットワークバイトの順序で送信する必要があります（別名Big Endian、最も重要なバイトが最初に送信されることを意味します）。
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サーバーの存在を発表するか、Peer Enrpサーバーのステータスをプローブするために使用されます。このメッセージは、Enrp Serverチャネルで送信されるか、Point-to-Pointが別のEntRPサーバーに送信されます。
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です。このパラメーターは、ハンドルスペースの一貫性監査に含める必要があります。詳細については、セクション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]で定義されています）。このパラメーターはオプションです。ただし、このメッセージがピアから受信した「返信が必要」に応じて送信された場合、送信者はサーバー情報を含める必要があります。
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を使用する必要があります。
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サーバーは、このメッセージをピアの1人に送信して、ハンドルスペースデータのコピーをリクエストします。このメッセージは、通常、サーバーの初期化またはハンドルスペースの再同期中に使用されます。
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
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メッセージは、PEER-SERVERの初期化またはハンドルスペースの同期を支援するために、受信した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'.
このメッセージの送信者に、その後のentrp_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.
このメッセージの送信者がハンドルスペースリクエストを拒否している場合、「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形式で1つ以上のプール要素パラメーターが続きます。
+---------------------------+
: 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メッセージは、PEのHome Endp Serverによってすべてのピアサーバーに送信され、登録、再登録、またはハンドルスペースの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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
0x0000 -add_pe：entrpハンドルスペースの指定されたPEを追加または更新します。
0x0001 - DEL_PE: Delete the specified PE from the ENRP handlespace.
0x0001 -DEL_PE：ENRPハンドルスペースから指定されたPEを削除します。
0x0002 - 0xFFFF: Reserved by IETF.
0x0002-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メッセージは、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 = 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.
entrp_init_takeoverメッセージは、特定のPeer enterpサーバーを引き継ぐ意図を発表するために、ENRPサーバー（The Takeover Initiator）によって送信されます。それはすべての仲間に送られます。
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.
これは、この買収の試みのターゲットであるピアエンブの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メッセージの受信を確認するために、Takeover Initiatorに応じて送信されます。
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.
これは、この買収の試みのターゲットであるピアエンブの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メッセージは、Takeoverイニシエーターによって送信され、すべてのアクティブなPEER 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.
これは、この買収操作のターゲットであるピアエンブのIDです。
The ENRP_ERROR message is sent by a registrar to report an operational error to a peer ENRP server.
Enrp_Errorメッセージは、Peer 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イベントの多くは、サーバーからサーバーとPE/ PE-To-Serverの両方のメッセージ交換を求めています。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サーバーは、プールメンバーシップの変更、ハンドルスペースデータの同期など、情報を交換するために相互に通信する必要があります。
Two types of communications are used amongst ENRP servers:
ENRPサーバーの間で2種類の通信が使用されています。
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サーバーチャネルを介して「グループキャスト」を介して送信されます。
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サーバーである場合は、ハンドルスペースサービスを開始する手順について説明します。
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サーバー（開始サーバー）は、まず同じ運用範囲内のすべての既存のPEER 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).
開始サーバーがメンターピアサーバーを見つけたら（検出手段または管理手段のいずれかによって）、開始サーバーはメンターピアが管理する完全なサーバーリストのコピーをリクエストするためにentrp_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.
Initiatingサーバーは、entrp_list_requestメッセージの送信が完了するたびに、最大時間なしのタイマーを起動する必要があります。メンターピアから回答を受信する前にタイマーが期限切れになった場合、開始サーバーは現在のメンターサーバーとの対話を放棄し、利用可能な場合はバックアップメンターピアに新しいサーバーリストリクエストを送信する必要があります。
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.
このリクエストを受信すると、Mentor Peer Serverはentrp_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.
メンターピアからentrp_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.
ただし、メンター自体がスタートアップのプロセスにあり、ピアサーバーリストを提供する準備ができていない場合（たとえば、メンターピアが別のサーバーへの独自のentrp_list_requestへの応答を待っている場合）サーバーとRPP_LIST_RESPONSEメッセージを使用して応答し、Rフラグを「1」に設定し、応答にサーバー情報が含まれていません。
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.
entrp_list_requestがメンターピアによって拒否された場合、開始サーバーは数秒待ち、enterp_list_requestをメンターサーバーに再送信する必要があります。entrp_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:
ピアリストのダウンロードが完了した後、開始サーバーは、次の手順を実行して、メンターピアサーバーから現在のハンドルスペースデータのコピーを要求する必要があります。
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. 開始サーバーは、最初にentrp_handle_table_requestメッセージをメンターピアに送信する必要があります。Wフラグは「0」に設定されており、ハンドルスペース全体が要求されていることを示しています。
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. このメッセージを受信すると、メンターピアは、メンターピアによって維持されている現在のハンドルスペースデータのコピーが1つ以上のentrp_handle_table_responseメッセージで開始サーバーに送信されるダウンロードセッションを開始する必要があります。（メンターサーバーは、特に大きなハンドルスペースを含む単一の応答を形成して送信するときに、ハンドルスペースが大きいときに、複数のentrp_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.
ダウンロード中に複数のentrp_handle_table_responseメッセージが使用される場合、メンターピアは各entrp_handle_table_responseメッセージのMフラグを使用して、このメッセージがダウンロードセッションの最後のものかを示す必要があります。特に、メンターピアは、転送されるデータが増え、現在のダウンロードセッションの進行状況を追跡する必要がある場合、アウトバウンドentrp_handle_table_responseでMフラグを「1」に設定する必要があります。メンターピアは、ダウンロードセッションの最後のentrp_handle_table_responseでMフラグを「0」に設定し、最後のメッセージを送信した後、ダウンロードセッションを閉じる（つまり、セッションの内部レコードを削除する）（つまり、セッションの内部レコードを削除する）必要があります。
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. ダウンロード中、開始サーバーがentrp_handle_table_responseメッセージを受信するたびに、メッセージにあるデータエントリをローカルハンドルスペースデータベースに転送し、このメッセージがダウンロードセッションの最後のメッセージであるかどうかを確認する必要があります。
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.
ちょうど処理されたenterp_handle_table_responseメッセージでmフラグが「1」に設定されている場合、開始サーバーは次のentrp_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. entrp_handle_table_responseメッセージからローカルハンドルスペースデータベースにデータエントリを開梱する場合、開始サーバーは、次のルールを使用してメッセージに掲載された各プールエントリを処理する必要があります。
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.プールがローカルハンドルスペースに存在しない場合、開始サーバーはローカルハンドルスペースにプールを作成し、プールへのプールエントリにPEを追加する必要があります。
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.プールが既にローカルハンドルスペースに存在しているが、プールエントリのPEが現在プールのメンバーではない場合、開始サーバーは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.
C.プールがローカルハンドルスペースに既に存在し、プールエントリのPEがすでにプールのメンバーである場合、開始サーバーは既存のPEの属性を新しい情報に置き換える必要があります。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. 最後のentrp_handle_table_responseメッセージがメンターピアから受信され、ローカルハンドルスペースに編成されると、初期化プロセスが完了し、イニシエーションサーバーが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.
特定の状況では、メンターのピア自体が開始サーバーにハンドルスペースのダウンロードを提供できない場合があります。たとえば、メンターピアは独自のハンドルスペースデータベースを初期化する最中にいます。または、現在、他のサーバーに開かれたセッションが多すぎます。
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」に設定し、応答にはプールエントリが含まれていないrp_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.
entrp_handle_table_requestがメンターピアによって拒否された場合、開始サーバーは数秒待って、entrp_handle_table_requestをメンターサーバーに再送信する必要があります。entrp_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.
開始されたハンドルスペースのダウンロードセッションは、何らかの理由で中断される場合があります。これに対処するために、開始サーバーは、メンターピアにentrp_handle_table_requestの送信を完了するたびにタイマーを起動する必要があります。このタイマーがメンターピアから応答を受信せずに期限切れになった場合、開始サーバーは現在のダウンロードセッションを中止し、利用可能な場合はバックアップメンターピアで新しいハンドルスペースのダウンロードを再起動する必要があります。
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.
同様に、entrp_handle_table_responseを送信し、メンターピアがmbitを「1」に設定して、送信するデータが増えることを示した後、セッションタイマーを開始する必要があります。このタイマーが開始サーバーから別のリクエストを受信せずに期限切れになった場合、メンターピアはセッションを中止し、セッションのリソースと記録をクリーンアウトする必要があります。
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サーバーが使用する一連の更新操作が含まれ、ローカルハンドルスペースが変更されたときにピアを通知します。たとえば、新しい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がハンドルスペースへの登録または既存のPEに再登録が付与されると、Home Endp Serverはこの手順を使用してすべてのピアを通知します。
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の発表であり、Home Endpサーバーのすべてのピアに送信されます。発表の送信方法については、セクション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サーバーは、更新アクションフィールドが「add_PE」に設定されたentrp_handle_updateメッセージで、すべてのピアにこの更新を発表する必要があります。これは、新しいPEの追加または既存のPEの変更を示しています。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).
Home Endp Serverは、送信サーバーのIDフィールドにサーバーIDを入力し、受信サーバーのIDブランク（つまり、すべての0）を残しておく必要があります。
When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take the following actions:
ピアがこのentrp_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. プールハンドルで示されている名前のプールがハンドルスペースのローカルコピーに存在しない場合、ピアはローカルハンドルスペースに名前付きプールを作成し、最初の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. 名前付きプールがすでにピアのハンドルスペース *のローカルコピーに存在し、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が登録解除が付与されるか、他のいくつかの理由でそのハンドルスペースから削除された場合（例えば、到達不可能な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の発表であり、Home Endpサーバーのすべてのピアに送信されます。発表の送信方法については、セクション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サーバーは、DEL_PEに設定された更新アクションフィールドを使用して、entrp_handle_updateメッセージですべてのピアにPE削除を発表する必要があり、既存の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を入力し、受信サーバーの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.
ピアがこのentrp_handle_updateメッセージを受信したら、最初にプールとPEを独自のハンドルスペースで見つけてから、ローカルハンドルスペースからPEを削除する必要があります。削除されたPEがプールの最後のものである場合、ピアはまた、地元のハンドルスペースからプールを削除する必要があります。
If the peer fails to find the PE or the pool in its handlespace, it SHOULD take no further actions.
ピアがハンドルスペースに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サーバーは、Reply Required Flagを「1」に設定して、到着したメッセージにあるソースアドレスに「1」に設定されたEnrp_Presenceメッセージを送信する必要があります。これにより、新しいピアは、完全なサーバー情報を含む独自のentrp_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 Cycle秒ごとに、ENRPサーバーは、entrp_presenceメッセージを使用して、すべてのピアに継続的な存在を発表する必要があります。entrp_presenceメッセージでは、entrpサーバーは「replay_required」フラグを「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メッセージの到着により、すべてのピアが送信サーバーの内部変数「PEER_LAST_HEARD」を更新します（詳細については、セクション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サーバーは、既知のピアごとに内部変数「PEER_LAST_HEARD」を維持する必要があり、この変数の値は、あらゆるタイプのメッセージ（ポイントツーポイントまたはアナウンス）が受信されるたびに現在の現地時間に更新する必要があります。対応するピア。
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.
ピアが最大時間を超えて耳を傾けていない場合、EntRPサーバーは、そのピアにReply_Requestフラグを「1」に設定してポイントツーポイントEntRP_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.
送信が失敗した場合、またはピアが最大時間と応答の数秒後に返信しない場合、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は自宅のendpサーバーが失敗した場合に操作を続けることができます。
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を入力する必要があります。目標は、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.
ターゲットサーバーを除き、既知の各ピアからのentrp_init_takeover_ackメッセージをターゲットサーバーを除く、entrp_init_takeoverメッセージ（ターゲットサーバーを含むすべての既知のピアに「グループキャスト」）を発表した後、開始サーバーはenrp_init_takeover_ackメッセージを待つ必要があります。
Each peer receiving an ENRP_INIT_TAKEOVER message from the initiating server MUST take the following actions:
開始サーバーからentrp_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. ピアサーバーが（それ自体）がentrp_init_takeoverメッセージに示されているターゲットサーバーであると判断した場合、この買収プロセスを停止するために、すべてのPEER 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.
A.ピアのサーバーIDの値が到着したendp_init_takeoverメッセージの送信サーバーのIDよりも値が小さい場合、ピアサーバーは、独自の買収アクションを実行しないことで、すぐに独自のテイクオーバーの試みを中止する必要があります。さらに、ピアは、ターゲットサーバーを内部ピアリストで「アクティブではない」とマークし、そのステータスがピアによって監視されなくなり、entrp_init_takeover_ackメッセージで開始サーバーに返信する必要があります。
B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER message.
B.それ以外の場合、ピアはentrp_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）entrp_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.
開始サーバーが、現在既知のすべてのピア（ターゲットサーバーを除く）からentrp_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の所有権を主張する必要があります。
1. mark itself as the Home ENRP server of each of the PEs originally owned by the target server;
1. 元々ターゲットサーバーが所有していた各PEのホームエンパーサーバーとしての地位をマークします。
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. 「H」フラグを「1」に設定して、ASAP_ENDPOINT_KEEP_ALIVEメッセージを各PEに送信します。これにより、PEがトリガーされ、新しいHome Endp Serverとして開始Severを採用します。
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:
ピアが開始サーバーからentrp_takeover_serverメッセージを受信すると、これらの手順に従ってローカルピアリストとPEキャッシュを更新する必要があります。
1. remove the target server from its internal peer list;
1. ターゲットサーバーを内部ピアリストから削除します。
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. ハンドルスペースのローカルコピーにある各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サーバーのローカルハンドルスペースコピーがデータの矛盾をもたらす可能性があります。したがって、運用範囲内の各ENRPサーバーは、ハンドルスペースデータのローカルコピーがまだ同業他社のコピーと同期していることを定期的に確認する必要があります。
This section defines the auditing and re-synchronization procedures for an ENRP server to maintain its handlespace data consistency.
このセクションでは、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:
ハンドスペースの一貫性の監査は、次の手順に基づいています。
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ビット整数内部変数）を保持する必要があります。既知のピアを持つENRPサーバーの場合、これらの内部変数を「PE_CHECKSUM_PR0」、「PE_CHECKSUM_PR1」、「...」、「PE_CHECKSUM_PRK」、「PE_CHECKSUM_PR0」と表します。これらのチェックサムがカバーするもののリストとそれらを計算するための詳細なアルゴリズムは、セクション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").
2. ENRPサーバーがENRP_PRESENCEを送信するたびに、メッセージに現在の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").
3. ENRPサーバー（サーバーA）がPEER ENRPサーバー（サーバーB）からPEチェックサム（到着したentrp_presenceで携帯されている）を受信すると、サーバーAは、enterp_preで見つかったPEチェックサムを独自の内部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. 2つの値が一致する場合、サーバーAは、それ自体とサーバーBの間にハンドル空間の矛盾がないことを考慮し、それ以上のアクションは必要ありません。
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. 2つの値が一致しない場合、サーバーAは、それ自体とサーバーBの間にハンドルスペースの矛盾があることを考慮する必要があり、サーバーBで再同期プロセスを直ちに実行する必要があります（セクション3.6.3を参照）。
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の内部ハンドルスペースには、現在サーバーBが所有している「M」ペスがあると仮定しましょう。それぞれの「M」PESは、次のバイトブロックでチェックサムの計算に貢献します。
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の16ビットPEチェックサム "PE_CHECKSUM_PRB"は、「M」PESが1つずつ寄付するバイトブロックを介して計算されます。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_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が内部のハンドルスペースが変更されたことを発見したときはいつでも（たとえば、PE登録/登録の廃止、ピアアップデートの受信、故障した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.
実装注：内部ハンドルスペースが変更された場合（たとえば、新しい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に関してピアのハンドルスペースデータとの間に矛盾があると判断した場合、データを再同期させるために次の手順を実行する必要があります。
1. The ENRP server SHOULD first "mark" every PE it knows about that is owned by the peer in its local handlespace database;
1. ENRPサーバーは、最初に「マーク」する必要があります。それが知っているすべてのPEは、ローカルハンドルスペースデータベースのピアが所有するものです。
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サーバーは、wフラグを「1」に設定したentrp_handle_table_requestメッセージをピアに「1」に送信して、ピアが所有するPEの完全なリストをリクエストする必要があります。
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. wフラグが「1」に設定されたentrp_handle_table_requestメッセージを受信すると、ピアサーバーは、現在ピアが所有しているすべてのPEをリストするentrp_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. entrp_handle_table_responseメッセージを受信すると、entrpサーバーは、メッセージにある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. 受信したentrp_handle_table_responseメッセージからすべてのPEエントリをローカルデータベースに転送した後、entRPサーバーは、ローカルハンドルスペースに「マークされた」ままの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で説明しているものと同様に、ピアはentrp_handle_table_requestを拒否するか、複数のentrp_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サーバーは、適切なエラー原因コードを使用してentrp_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-PEERサーバーが最後に聞かれた現地時間（ピアからグループキャストまたはポイントツーポイントメッセージを受信して）。
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サーバーが潜在的に死亡する可能性があると考える前に、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によって10の初期値が割り当てられました。IANAは新しいテーブル「Endpメッセージタイプ」を作成しました。
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によって維持されます。IANAによって2つの初期値が割り当てられています。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
entrp-udp 9901/udp
enrp-sctp 9901/sctp
entrp-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.
応答したセキュリティメカニズム：ASAPは、PUからENRPサーバーに送信されるASAPエンドポイントの到達不可能なメッセージの数を制御する必要があります。
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 CIPHERSUITEは、少なくとも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、およびPUSはTLSを実装する必要があります。ENRPサーバーとPESは、PSKを使用した相互認証をサポートする必要があります。ENRPサーバーは、PSKを使用して相互認証をサポートする必要があります。PUSは、証明書を使用して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し、ENRP認証にPEの認証メカニズムとして実装することを義務付けています。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サーバーへのPUSの認証メカニズムとして実装することが必須です。PUSは、証明書を使用してENRPサーバーを認証する必要があります。ENRPサーバーは、被写体が標準的なホスト名に対応するサイト証明書を所有する必要があります。PUSには、TLSを使用した相互認証のために独自の証明書がある場合がありますが、このドキュメントに使用するための規定は記載されていません。TLSをサポートするすべてのRSERPOOL要素には、TLS交渉中に受信された証明書を検証するメカニズムが必要です。これには、証明書当局によって発行された1つ以上のルート証明書（できれば、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).
中間の攻撃を防ぐために、クライアントはサーバーのIDを確認する必要があります（サーバーの証明書メッセージに示されているように）。サーバーのID（通常、トランスポート接続の確立に使用されるID）に対するクライアントの理解は、「参照ID」と呼ばれます。クライアントは、参照IDのタイプ（DNS名またはIPアドレスなど）を決定し、一致が生成されるまで、参照IDと対応するタイプの各subjectaltName値との比較を実行します。一致が作成されると、サーバーのIDが検証され、サーバーIDのチェックが完了します。異なるsubmestaltnameタイプは、さまざまな方法で一致しています。クライアントは、比較を実行する前に、参照IDを別のタイプにマッピングできます。マッピングは、参照IDをマッピングできるすべての利用可能なsubmentaltnameタイプに対して実行できます。ただし、参照IDは、マッピングが本質的に安全であるタイプにのみマッピングする必要があります（たとえば、dnsnameのsumberaltnameと比較するためにdns名を抽出して、マッピングが安全な方法で実行される（たとえば、DNSセキュリティ（DNSSEC）を使用するか、ユーザーまたは管理者が構成されているホストからアドレスへ/アドレスからホストへのルックアップテーブルを使用します）。
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が疑わしいことを示す必要があります。自動化されたクライアントは、トランスポート接続を閉じてから、サーバーの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が国際化されたドメイン名である場合、適合実装は、[RFC3490]のセクション4で指定されているように、型DNSNAMEの対象値と比較する前に、ASCII互換エンコード（ACE）形式に変換する必要があります。具体的には、[RFC3490]のセクション4で指定された変換操作を次のように実行する必要があります。 *ステップ1では、ドメイン名は「保存された文字列」と見なされます。*ステップ3では、「uesestd3asciirules」と呼ばれるフラグを設定します。*ステップ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.
「to-ascii」変換を実行した後、DNSラベルと名前は、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アドレスである場合、IDは「ネットワークバイト順」に変換されなければなりません。IPバージョン4の場合、RFC 791で指定されているように、オクテット文字列には正確に4オクテットが含まれます。IPバージョン6の場合、RFC 2460で指定されているように、オクテット文字列には正確に16のオクテットが含まれます。次に、このOctet文字列は、iPaddressのタイプのsubjectaltname値と比較されます。参照IDオクテット文字列と値のオクテット文字列が同一である場合、一致が発生します。
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（RE）交渉が完了した直後に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.
[RFC3436]で説明されているように、[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では、ASAPプロトコルがASAP_ENDPOINT_UNREACHABLEメッセージの数（RFC 5352のセクション3.5を参照）をENRPサーバーに制限する必要があります。
Threat 9 requires the ENRP protocol to limit the number of ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE.
脅威9では、entRPプロトコルがASAP_ENDPOINT_KEEP_ALIVEメッセージの数をENRPサーバーからPEに制限する必要があります。
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.
マルチキャストのアナウンスについて定義されたセキュリティメカニズムはありません。したがって、このような発表の受信者は、そのようなメッセージのソースアドレスをEntRPサーバーの信頼できるアドレスであると考えることはできません。また、受信者は、攻撃者から多数のマルチキャストアナウンスを受け取る準備をする必要があります。
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つのアーキテクチャコンポーネントすべて、つまりPU、PE、およびENRPサーバーのTLS実装に基づいています。すべての通信にTLSを使用し、Enrpピアを認証し、PE登録者を保護された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を使用して認証および通信する場合、信頼のチェーンは健全です。Trustチェーンのルートは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サーバーに登録しようとする場合、セキュリティに関する考慮事項によりエラーとして示されたエラーメッセージ応答がedricedされ、登録は拒否されます。TLSを使用していないENRPサーバーが、Secure 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がEntRPに安全なリクエストを送信することです。ENRPとPESが固定されていない可能性があり、これは許容される構成です。目的は、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アーキテクチャコンポーネントは、互いに通信して、信頼の連鎖を確立することができます。SECUED 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.
著者は、ジョン・ラフニー、リンドン・オング、ウォルター・ジョンソン、トーマス・ドレイブホルツ、フランク・ヴォルク、その他多くのコメントとフィードバックについて感謝したいと考えています。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、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] Braden、R.、Borman、D.、Partridge、C。、およびW. Plummer、「Internet Checksumのコンピューティング」、RFC 1071、1988年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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.、Xie、Q.、Stewart、R.、Shore、M.、Ong、L.、Loughney、J。、およびM. Stillman、「信頼できるサーバープーリングの要件」、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.、Rescorla、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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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] Stewart、R.、Xie、Q.、Stillman、M。、およびM. Tuexen、「Aggregate Server Access Protocol（ASAP）およびEndpoint Handlespace Redundancy Protocol（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] Stewart、R.、Xie、Q.、Stillman、M。、およびM. Tuexen、「Aggregate Server Access Protocol（ASAP）」、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] Stillman、M.、Ed。、Gopal、R.、Guttman、E.、Holdrege、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] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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] Stewart、R.、Poon、K.、Tuexen、M.、Yasevich、V。、およびP. Lei、「Sockets API拡張機能用API拡張機能（SCTP）」、2008年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Qiaobing Xie The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA
Qiaobing Xieリソースグループ1700ペンシルバニアアベニアNWスイート560ワシントンD.C.、20006 USA
Phone: +1 224-465-5954
EMail: 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
電話：電子メール：randall@lakerest.net
Maureen Stillman Nokia 1167 Peachtree Ct. Naperville, IL 60540 US
Maureen Stillman Nokia 1167 Peachtree Ct。イリノイ州ネーパービル60540米国
Phone: EMail: maureen.stillman@nokia.com Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
電話：メール：maureen.stillman@nokia.com Michael Tuexen Muenter Univ。Applied Sciences Stegerwaldstrの。39 48565 Steinfurtドイツ
EMail: tuexen@fh-muenster.de
Aron J. Silverton Sun Microsystems, Inc. 10 S. Wacker Drive Suite 2000 Chicago, IL 60606 USA
Aron J. Silverton Sun Microsystems、Inc。10 S. Wacker Drive Suite 2000 Chicago、IL 60606 USA
Phone: EMail: ajs.ietf@gmail.com
電話：メール：ajs.ietf@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。