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
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.
端点Handlespace冗余协议（ENRP）旨在与聚合服务器访问协议（ASAP）配合使用，以实现可靠服务器池（RSerPool）要求和体系结构的功能。在RSerPool的操作范围内，ENRP定义了分布式容错注册表服务的过程和消息格式，用于存储、记账、检索和分发池操作和成员信息。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Definitions ................................................3
1.2. Conventions ................................................4
2. ENRP Message Definitions ........................................4
2.1. ENRP_PRESENCE Message ......................................5
2.2. ENRP_HANDLE_TABLE_REQUEST Message ..........................6
2.3. ENRP_HANDLE_TABLE_RESPONSE Message .........................7
2.4. ENRP_HANDLE_UPDATE Message .................................9
2.5. ENRP_LIST_REQUEST Message .................................10
2.6. ENRP_LIST_RESPONSE Message ................................11
2.7. ENRP_INIT_TAKEOVER Message ................................12
2.8. ENRP_INIT_TAKEOVER_ACK Message ............................13
2.9. ENRP_TAKEOVER_SERVER Message ..............................14
2.10. ENRP_ERROR Message .......................................15
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
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旨在与ASAP[RFC5352]合作，实现其要求[RFC3237]定义的RSerPool功能。
Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information.
在RSerPool的操作范围内，ENRP定义了分布式容错注册表服务的过程和消息格式，用于存储、记账、检索和分发池操作和成员信息。
Whenever appropriate, in the rest of this document, we will refer to this RSerPool registry service as ENRP handlespace, or simply handlespace, because it manages all pool handles.
在本文档的其余部分中，我们将在适当的时候将此RSerPool注册表服务称为ENRP handlespace，或者简称为handlespace，因为它管理所有池句柄。
This document uses the following terms:
本文件使用以下术语：
Operational scope: The part of the network visible to pool users by a specific instance of the reliable server pooling protocols.
操作范围：可靠服务器池协议的特定实例对池用户可见的网络部分。
Pool (or server pool): A collection of servers providing the same application functionality.
池（或服务器池）：提供相同应用程序功能的服务器集合。
Pool handle: A logical pointer to a pool. Each server pool will be identifiable in the operational scope of the system by a unique pool handle.
池句柄：指向池的逻辑指针。每个服务器池将在系统的操作范围内通过唯一的池句柄进行标识。
Pool element: A server entity having registered to a pool.
池元素：已注册到池的服务器实体。
Pool user: A server pool user.
池用户：服务器池用户。
Pool element handle (or endpoint handle): A logical pointer to a particular pool element in a pool, consisting of the pool handle and a destination transport address of the pool element.
池元素句柄（或端点句柄）：指向池中特定池元素的逻辑指针，由池句柄和池元素的目标传输地址组成。
Handle space: A cohesive structure of pool handles and relations that may be queried by an internal or external agent.
句柄空间：池句柄和关系的内聚结构，可由内部或外部代理查询。
ENRP client channel: The communication channel through which an ASAP User (either a Pool Element (PE) or Pool User (PU)) requests ENRP handlespace service. The client channel is usually defined by the transport address of the Home ENRP server and a well-known port number.
ENRP客户端通道：ASAP用户（池元素（PE）或池用户（PU））请求ENRP handlespace服务的通信通道。客户端通道通常由家庭ENRP服务器的传输地址和众所周知的端口号定义。
ENRP server channel: Defined by a list of IP addresses (one for each ENRP server in an operational scope) and a well-known port number. All ENRP servers in an operational scope can send "group-cast" messages to other servers through this channel. In a "group-cast", the sending server sends multiple copies of the message, one to each of its peer servers, over a set of point-to-point Stream Control Transmission Protocol (SCTP) associations between the sending server and the peers. The "group-cast" may be conveniently implemented with the use of the "SCTP_SENDALL" option on a one-to-many style SCTP socket.
ENRP服务器通道：由IP地址列表（操作范围内的每个ENRP服务器一个）和众所周知的端口号定义。操作范围内的所有ENRP服务器都可以通过此通道向其他服务器发送“组广播”消息。在“组广播”中，发送服务器通过发送服务器和对等服务器之间的一组点对点流控制传输协议（SCTP）关联发送消息的多个副本，每个副本发送到其对等服务器。在一对多样式的SCTP套接字上使用“SCTP_SENDALL”选项可以方便地实现“组转换”。
Home ENRP server: The ENRP server to which a PE or PU currently belongs. A PE MUST only have one Home ENRP server at any given time, and both the PE and its Home ENRP server MUST keep track of this master/slave relationship between them. A PU SHOULD select one of the available ENRP servers as its Home ENRP server.
家庭ENRP服务器：PE或PU当前所属的ENRP服务器。PE在任何给定时间必须只有一个主ENRP服务器，并且PE及其主ENRP服务器必须跟踪它们之间的主/从关系。PU应选择一个可用的ENRP服务器作为其主ENRP服务器。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In this section, we define the format of all ENRP messages. These are messages sent and received amongst ENRP servers in an operational scope. Messages sent and received between a PE/PU and an ENRP server are part of ASAP and are defined in [RFC5352]. A common format, that is defined in [RFC5354], is used for all ENRP and ASAP messages.
在本节中，我们定义了所有ENRP消息的格式。这些是在操作范围内的ENRP服务器之间发送和接收的消息。PE/PU和ENRP服务器之间发送和接收的消息是ASAP的一部分，在[RFC5352]中定义。[RFC5354]中定义的通用格式用于所有ENRP和ASAP消息。
Most ENRP messages contain a combination of fixed fields and TLV (Type-Length-Value) parameters. The TLV parameters are also defined in [RFC5354]. If a nested TLV parameter is not ended on a 32-bit word boundary, it will be padded with all '0' octets to the next 32- bit word boundary.
大多数ENRP消息包含固定字段和TLV（类型长度值）参数的组合。TLV参数也在[RFC5354]中定义。如果嵌套TLV参数未在32位字边界上结束，则将使用所有“0”八位字节填充到下一个32位字边界。
All messages, as well as their fields/parameters described below, MUST be transmitted in network byte order (aka Big Endian, meaning the most significant byte is transmitted first).
所有消息及其下面描述的字段/参数必须以网络字节顺序传输（也称为Big-Endian，表示最重要的字节首先传输）。
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)
Type Message Name
----- -------------------------
0x00 - (Reserved by IETF)
0x01 - ENRP_PRESENCE
0x02 - ENRP_HANDLE_TABLE_REQUEST
0x03 - ENRP_HANDLE_TABLE_RESPONSE
0x04 - ENRP_HANDLE_UPDATE
0x05 - ENRP_LIST_REQUEST
0x06 - ENRP_LIST_RESPONSE
0x07 - ENRP_INIT_TAKEOVER
0x08 - ENRP_INIT_TAKEOVER_ACK
0x09 - ENRP_TAKEOVER_SERVER
0x0a - ENRP_ERROR
0x0b-0xff - (Reserved by IETF)
Figure 1
图1
This ENRP message is used to announce (periodically) the presence of an ENRP server, or to probe the status of a peer ENRP server. This message is either sent on the ENRP server channel or sent point-to-point to another ENRP server.
此ENRP消息用于（定期）宣布ENRP服务器的存在，或探测对等ENRP服务器的状态。此消息通过ENRP服务器通道发送或点对点发送到另一个ENRP服务器。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x01 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Checksum Param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
这是一个TLV，包含发送ENRP_状态的ENRP服务器的最新PE校验和。此参数应包含在handlespace一致性审核中。详见第3.6.1节。
Server Information Parameter:
服务器信息参数：
If this parameter is present, it contains the server information of the sender of this message (the Server Information Parameter is defined in [RFC5354]). This parameter is optional. However, if this message is sent in response to a received "reply required" ENRP_PRESENCE from a peer, the sender then MUST include its server information.
如果此参数存在，则它包含此邮件发件人的服务器信息（服务器信息参数在[RFC5354]中定义）。此参数是可选的。但是，如果此消息是响应从对等方收到的“需要回复”ENRP_存在而发送的，则发送方必须包含其服务器信息。
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，并且必须使用相同的ID，直到重新启动ENRP服务器。
An ENRP server sends this message to one of its peers to request a copy of the handlespace data. This message is normally used during server initialization or handlespace re-synchronization.
ENRP服务器将此消息发送给它的一个对等方，以请求handlespace数据的副本。此消息通常在服务器初始化或handlespace重新同步期间使用。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
W (oWn-children-only) Flag: 1 bit
W（仅限自有子女）标志：1位
Set to '1' if the sender of this message is only requesting information about the PEs owned by the message receiver. Otherwise, set to '0'.
如果此消息的发送方仅请求有关消息接收方拥有的PEs的信息，则设置为“1”。否则，设置为“0”。
Sending Server's ID:
正在发送服务器的ID:
See Section 2.1.
见第2.1节。
Receiving Server's ID:
接收服务器的ID:
See Section 2.1.
见第2.1节。
The PEER_NAME_TABLE_RESPONSE message is sent by an ENRP server in response to a received PEER_NAME_TABLE_REQUEST message to assist peer-server initialization or handlespace synchronization.
ENRP服务器发送对等\u名称\u表\u响应消息，以响应接收到的对等\u名称\u表\u请求消息，以协助对等服务器初始化或handlespace同步。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x03 |0|0|0|0|0|0|M|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Entry #1 (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Entry #n (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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（更多发送）标志：1位
Set to '1' if the sender of this message has more pool entries to send in subsequent ENRP_HANDLE_TABLE_RESPONSE messages. Otherwise, set to '0'.
如果此邮件的发件人在后续ENRP\u HANDLE\u TABLE\u响应邮件中有更多池条目要发送，请设置为“1”。否则，设置为“0”。
R (Reject) Flag: 1 bit
R（拒绝）标志：1位
MUST be set to '1' if the sender of this message is rejecting a handlespace request. In this case, pool entries MUST NOT be included. This might happen if the sender of this message is in the middle of initializing its database or is under high load.
如果此邮件的发件人拒绝handlespace请求，则必须将设置为“1”。在这种情况下，不能包括池条目。如果此消息的发送者处于初始化数据库或处于高负载状态，则可能发生这种情况。
Message Length: 16 bits (unsigned integer)
消息长度：16位（无符号整数）
Indicates the entire length of the message, including the header, in number of octets.
以八位字节数表示消息的整个长度，包括标头。
Note, the value in the Message Length field will NOT cover any padding at the end of this message.
注意，“消息长度”字段中的值不会覆盖此消息末尾的任何填充。
Sending Server's ID:
正在发送服务器的ID:
See Section 2.1.
见第2.1节。
Receiving Server's ID:
接收服务器的ID:
See Section 2.1.
见第2.1节。
Pool Entry #1-#n:
池条目#1-#n:
If the R flag is set to '0', at least one pool entry SHOULD be present in this message. Each pool entry MUST start with a Pool Handle parameter, as defined in Section 3.9 of [RFC5354], and is followed by one or more Pool Element parameters in TLV format, as shown below:
如果R标志设置为“0”，则此消息中至少应有一个池条目。每个池条目必须以[RFC5354]第3.9节中定义的池句柄参数开头，后跟一个或多个TLV格式的池元素参数，如下所示：
+---------------------------+
: Pool Handle :
+---------------------------+
: PE #1 :
+---------------------------+
: PE #2 :
+---------------------------+
: ... :
+---------------------------+
: PE #n :
+---------------------------+
+---------------------------+
: 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的家庭ENRP服务器发送到所有对等服务器，以在handlespace中宣布PE的注册、重新注册或注销。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Action | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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-添加PE：在ENRP handlespace中添加或更新指定的PE。
0x0001 - DEL_PE: Delete the specified PE from the ENRP handlespace.
0x0001-删除PE：从ENRP handlespace中删除指定的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.
发送对等列表请求消息以请求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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_响应消息是从ENRP服务器发送的，该服务器接收PEER_LIST_请求消息以返回有关已知ENRP服务器的信息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Parameter of Peer #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Parameter of Peer #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
如果此邮件的发件人拒绝对等\u列表\u请求邮件，则必须将此标志设置为“1”。如果发生这种情况，则消息不得包含任何服务器信息参数。
Message Length: 16 bits (unsigned integer)
消息长度：16位（无符号整数）
Indicates the entire length of the message in number of octets.
以八位字节数表示消息的整个长度。
Note, the value in the Message Length field will NOT cover any padding at the end of this message.
注意，“消息长度”字段中的值不会覆盖此消息末尾的任何填充。
Sending Server's ID:
正在发送服务器的ID:
See Section 2.1.
见第2.1节。
Receiving Server's ID:
接收服务器的ID:
See Section 2.1.
见第2.1节。
Server Information Parameter of Peer #1-#n:
对等服务器的服务器信息参数#1-#n:
Each contains a Server Information Parameter of a peer known to the sender. The Server Information Parameter is defined in [RFC5354].
每个包含发送方已知的对等方的服务器信息参数。服务器信息参数在[RFC5354]中定义。
The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the takeover initiator) to announce its intention of taking over a specific peer ENRP server. It is sent to all its peers.
ENRP服务器（接管发起人）发送ENRP_INIT_TAKEOVER消息，以宣布其接管特定对等ENRP服务器的意图。它被发送给所有的对等方。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x07 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x07 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
正在发送服务器的ID:
See Section 2.1.
见第2.1节。
Receiving Server's ID:
接收服务器的ID:
See Section 2.1.
见第2.1节。
Targeting Server's ID: 32 bits (unsigned integer)
目标服务器ID:32位（无符号整数）
This is the ID of the peer ENRP that is the target of this takeover attempt.
这是作为此次收购尝试目标的对等ENRP的ID。
The PEER_INIT_TAKEOVER_ACK message is sent in response to a takeover initiator to acknowledge the reception of the PEER_INIT_TAKEOVER message and that it does not object to the takeover.
PEER_INIT_TAKEOVER_ACK消息被发送以响应接管发起人，以确认接收到PEER_INIT_TAKEOVER消息，并且它不反对接管。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
正在发送服务器的ID:
See Section 2.1.
见第2.1节。
Receiving Server's ID:
接收服务器的ID:
See Section 2.1.
见第2.1节。
Targeting Server's ID:
目标服务器的ID:
This is the ID of the peer ENRP that is the target of this takeover attempt.
这是作为此次收购尝试目标的对等ENRP的ID。
The PEER_TAKEOVER_REGISTRAR message is sent by the takeover initiator to declare the enforcement of a takeover to all active peer ENRP servers.
对等接管注册器消息由接管发起人发送，以向所有活动对等ENRP服务器声明接管的实施。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
正在发送服务器的ID:
See Section 2.1.
见第2.1节。
Receiving Server's ID:
接收服务器的ID:
See Section 2.1.
见第2.1节。
Targeting Server's ID:
目标服务器的ID:
This is the ID of the peer ENRP that is the target of this takeover operation.
这是作为此接管操作目标的对等ENRP的ID。
The ENRP_ERROR message is sent by a registrar to report an operational error to a peer ENRP server.
ENRP_错误消息由注册器发送，以向对等ENRP服务器报告操作错误。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
正在发送服务器的ID:
See Section 2.1.
见第2.1节。
Receiving Server's ID:
接收服务器的ID:
See Section 2.1.
见第2.1节。
Operational Error Parameter:
操作错误参数：
This parameter, defined in [RFC5354], indicates the type of error(s) being reported.
[RFC5354]中定义的此参数表示报告的错误类型。
In this section, we discuss the operation procedures defined by ENRP. An ENRP server MUST follow these procedures when sending, receiving, or processing ENRP messages.
在本节中，我们将讨论ENRP定义的操作程序。当发送、接收或处理ENRP消息时，ENRP服务器必须遵循这些过程。
Many of the RSerPool events call for both server-to-server and PU/ PE-to-server message exchanges. Only the message exchanges and activities between an ENRP server and its peer(s) are considered within the ENRP scope and are defined in this document.
许多RSerPool事件都要求进行服务器到服务器和PU/PE到服务器的消息交换。在ENRP范围内，仅考虑ENRP服务器与其对等方之间的消息交换和活动，本文件对此进行了定义。
Procedures for exchanging messages between a PE/PU and ENRP servers are defined in [RFC5352].
[RFC5352]中定义了PE/PU和ENRP服务器之间交换消息的过程。
Within an RSerPool operational scope, ENRP servers need to communicate with each other in order to exchange information, such as the pool membership changes, handlespace data synchronization, etc.
在RSerPool操作范围内，ENRP服务器需要相互通信以交换信息，例如池成员身份更改、handlespace数据同步等。
Two types of communications are used amongst ENRP servers:
ENRP服务器之间使用两种类型的通信：
o point-to-point message exchanges from one ENPR server to a specific peer server, and
o 从一个ENPR服务器到特定对等服务器的点对点消息交换，以及
o announcements from one server to all its peer servers in the operational scope.
o 从一台服务器到操作范围内所有对等服务器的公告。
Point-to-point communication is always carried out over an SCTP association between the sending server and the receiving server. Announcements are sent out via "group-casts" over the ENRP server channel.
点对点通信始终通过发送服务器和接收服务器之间的SCTP关联执行。公告通过ENRP服务器频道的“群播”发送。
This section describes the steps a new ENRP server needs to take in order to join the other existing ENRP servers, or to initiate the handlespace service if it is the first ENRP server started in the operational scope.
本节描述了新的ENRP服务器需要采取的步骤，以便加入其他现有的ENRP服务器，或者启动handlespace服务（如果它是在操作范围内启动的第一个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必须在服务器的生命周期内保持不变。通常，一个好的32位随机数就足够了，因为服务器ID[RFC4086]提供了一些关于随机性准则的信息。
Note, there is a very remote chance (about 1 in about 4 billion) that two ENRP servers in an operational scope will generate the same server ID and hence cause a server ID conflict in the pool. However, no severe consequence of such a conflict has been identified.
注意，一个操作范围内的两台ENRP服务器生成相同的服务器ID，从而在池中引起服务器ID冲突的可能性非常小（约为40亿分之一）。然而，尚未发现这种冲突的严重后果。
Note, the ENRP server ID space is separate from the PE Id space defined in [RFC5352].
注意，ENRP服务器ID空间与[RFC5352]中定义的PE ID空间是分开的。
At startup, the ENRP server (the initiating server) will first attempt to learn of all existing peer ENRP servers in the same operational scope, or to determine that it is alone in the scope.
启动时，ENRP服务器（启动服务器）将首先尝试了解同一操作范围内的所有现有对等ENRP服务器，或确定其在该范围内是单独的。
The initiating server uses an existing peer server to bootstrap itself into service. We call this peer server the mentor server.
发起服务器使用现有对等服务器将自身引导到服务中。我们称这个对等服务器为mentor服务器。
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查询、配置数据库、启动脚本等）告知发起服务器一个现有对等服务器，则发起服务器必须将该对等服务器用作其指导服务器。
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.
如果指定了多个现有对等服务器，则发起服务器必须选择其中一个作为其mentor服务器，并保留其他作为其备份mentor服务器。
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).
一旦发起服务器找到其mentor对等服务器（通过发现或管理方式），发起服务器必须向mentor对等服务器发送ENRP_列表_请求消息，以请求mentor对等服务器维护的完整服务器列表副本（维护服务器列表见第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.
发起服务器应在每次完成发送ENRP_列表_请求消息时启动最大时间无响应计时器。如果计时器在收到mentor对等方的响应之前过期，则发起服务器应放弃与当前mentor服务器的交互，并向备份mentor对等方发送新的服务器列表请求（如果有）。
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对等服务器应回复ENRP_列表_响应消息，并在消息正文中包含mentor对等服务器已知的所有现有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.
在接收到来自mentor对等方的ENRP_列表_响应消息后，发起服务器必须使用消息中包含的服务器信息来初始化自己的对等方列表。
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.
但是，如果mentor本身正在启动过程中，并且没有准备好提供对等服务器列表（例如，mentor对等服务器正在等待对其自己的ENRP_列表_请求的响应发送到另一台服务器），则它必须拒绝发起服务器的请求，并使用设置为“1”的ENRP_列表_响应消息进行响应，并且响应中不包含服务器信息。
In the case where its ENRP_LIST_REQUEST is rejected by the mentor peer, the initiating server SHOULD either wait for a few seconds and re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a backup mentor peer available, select another mentor peer server and send the ENRP_LIST_REQUEST to the new mentor server.
如果其ENRP_列表_请求被mentor peer拒绝，则发起服务器应等待几秒钟并将ENRP_列表_请求重新发送到mentor服务器，或者如果有可用的备份mentor peer，则选择另一个mentor peer服务器并将ENRP_列表_请求发送到新的mentor服务器。
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:
对等列表下载完成后，发起服务器必须通过以下步骤从其mentor对等服务器请求当前handlespace数据的副本：
1. The initiating server MUST first send an ENRP_HANDLE_TABLE_REQUEST message to the mentor peer, with the W flag set to '0', indicating that the entire handlespace is requested.
1. 发起服务器必须首先向mentor对等方发送ENRP_HANDLE_TABLE_请求消息，W标志设置为“0”，表示请求整个handlespace。
2. Upon the reception of this message, the mentor peer MUST start a download session in which a copy of the current handlespace data maintained by the mentor peer is sent to the initiating server in one or more ENRP_HANDLE_TABLE_RESPONSE messages. (Note, the mentor server may find it particularly desirable to use multiple ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when the handlespace is large, especially when forming and sending out a single response containing a large handlespace may interrupt its other services.)
2. 收到此消息后，mentor peer必须启动下载会话，在此会话中，mentor peer维护的当前handlespace数据的副本在一个或多个ENRP\u HANDLE\u TABLE\u响应消息中发送到发起服务器。（注意，当handlespace较大时，mentor服务器可能会发现使用多个ENRP_HANDLE_TABLE_响应消息来发送handlespace是特别可取的，尤其是当形成并发送包含较大handlespace的单个响应时，可能会中断其其他服务。）
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.
如果在下载过程中使用了多个ENRP_句柄_表_响应消息，则mentor对等方必须在每个ENRP_句柄_表_响应消息中使用M标志，以指示此消息是否是下载会话的最后一条消息。特别是，如果有更多数据要传输，导师对等方必须在出站ENRP_HANDLE_TABLE_响应中将M标志设置为“1”，并且必须跟踪当前下载会话的进度。mentor对等方必须在下载会话的最后一个ENRP_HANDLE_TABLE_响应中将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. 在下载过程中，发起服务器每次收到ENRP_HANDLE_TABLE_响应消息时，都必须将消息中包含的数据项传输到其本地handlespace数据库中，然后检查此消息是否是下载会话的最后一条消息。
If the M flag is set to '1' in the just processed ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer to request for the next ENRP_HANDLE_TABLE_RESPONSE message.
如果在刚刚处理的ENRP_句柄_表_响应消息中将M标志设置为“1”，则发起服务器必须向mentor对等方发送另一个ENRP_句柄_表_请求消息，以请求下一个ENRP_句柄_表_响应消息。
4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE message into its local handlespace database, the initiating server MUST handle each pool entry carried in the message using the following rules:
4. 将ENRP_HANDLE_TABLE_响应消息中的数据项解包到本地handlespace数据库时，发起服务器必须使用以下规则处理消息中携带的每个池项：
A. If the pool does not exist in the local handlespace, the initiating server MUST create the pool in the local handlespace and add the PE(s) in the pool entry to the pool.
A.如果本地handlespace中不存在池，则发起服务器必须在本地handlespace中创建池，并将池条目中的PE添加到池中。
When creating the pool, the initiation server MUST set the overall member selection policy type of the pool to the policy type indicated in the first PE.
创建池时，启动服务器必须将池的总体成员选择策略类型设置为第一个PE中指示的策略类型。
B. If the pool already exists in the local handlespace, but the PE(s) in the pool entry is not currently a member of the pool, the initiating server MUST add the PE(s) to the pool.
B.如果池已存在于本地handlespace中，但池条目中的PE当前不是池的成员，则发起服务器必须将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.如果本地handlespace中已经存在池，并且池条目中的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. 当从mentor对等方收到最后一条ENRP_HANDLE_TABLE_响应消息并将其解压缩到本地handlespace时，初始化过程完成，发起服务器应开始提供ENRP服务。
Under certain circumstances, the mentor peer itself may not be able to provide a handlespace download to the initiating server. For example, the mentor peer is in the middle of initializing its own handlespace database, or it currently has too many download sessions open to other servers.
在某些情况下，mentor peer本身可能无法向发起服务器提供handlespace下载。例如，Mutor对等体处于初始化自己的手空间数据库的中间，或者当前有太多的下载会话开放给其他服务器。
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.
在这种情况下，mentor对等方必须拒绝发起服务器的请求，并使用ENRP_HANDLE_TABLE_响应消息进行响应，R标志设置为“1”，且响应中不包含池条目。
In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the mentor peer, the initiating server SHOULD either wait for a few seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor server, or if there is a backup mentor peer available, select another mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new mentor server.
如果其ENRP_HANDLE_TABLE_请求被mentor对等服务器拒绝，发起服务器应等待几秒钟，然后将ENRP_HANDLE_TABLE_请求重新发送到mentor服务器，或者如果有可用的备份mentor对等服务器，则选择另一个mentor对等服务器，并将ENRP_HANDLE_TABLE_请求发送到新的mentor服务器。
A handlespace download session that has been started may get interrupted for some reason. To cope with this, the initiating server SHOULD start a timer every time it finishes sending an ENRP_HANDLE_TABLE_REQUEST to its mentor peer. If this timer expires without receiving a response from the mentor peer, the initiating server SHOULD abort the current download session and re-start a new handlespace download with a backup mentor peer, if one is available.
由于某些原因，已启动的handlespace下载会话可能会中断。为了解决这个问题，发起服务器应该在每次完成向其mentor对等方发送ENRP_HANDLE_TABLE_请求时启动计时器。如果此计时器过期而未收到mentor对等方的响应，则发起服务器应中止当前下载会话，并使用备份mentor对等方（如果有）重新启动新的handlespace下载。
Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, and the mentor peer setting the M-bit to '1' to indicate that it has more data to send, it SHOULD start a session timer. If this timer expires without receiving another request from the initiating server, the mentor peer SHOULD abort the session, cleaning out any resource and record of the session.
类似地，在发送ENRP_HANDLE_TABLE_响应，并且mentor对等机将M位设置为“1”以指示其有更多数据要发送之后，它应该启动会话计时器。如果此计时器过期而未收到来自发起服务器的另一个请求，则mentor对等方应中止会话，清除会话的任何资源和记录。
This includes a set of update operations used by an ENRP server to inform its peers when its local handlespace is modified, e.g., addition of a new PE, removal of an existing PE, change of pool or PE properties.
这包括一组由ENRP服务器使用的更新操作，用于在修改其本地handlespace时通知其对等方，例如，添加新PE、删除现有PE、更改池或PE属性。
When a new PE is granted registration to the handlespace or an existing PE is granted a re-registration, the Home ENRP server uses this procedure to inform all its peers.
当新PE被授予handlespace注册或现有PE被授予重新注册时，家庭ENRP服务器使用此过程通知其所有对等方。
This is an ENRP announcement and is sent to all the peer of the Home ENRP server. See Section 3.1 on how announcements are sent.
这是一个ENRP公告，发送给家庭ENRP服务器的所有对等方。请参阅第3.1节，了解如何发送公告。
An ENRP server MUST announce this update to all its peers in a ENRP_HANDLE_UPDATE message with the Update Action field set to 'ADD_PE', indicating the addition of a new PE or the modification of
ENRP服务器必须在ENRP\u HANDLE\u update消息中向其所有对等方宣布此更新，更新操作字段设置为“ADD\u PE”，指示添加新PE或修改
an existing PE. The complete new information of the PE and the pool it belongs to MUST be indicated in the message with a PE parameter and a Pool Handle parameter, respectively.
现有的PE。必须在消息中分别使用PE参数和pool Handle参数指示PE及其所属池的全新信息。
The Home ENRP server SHOULD fill in its server ID in the Sending Server's ID field and leave the Receiving Server's ID blank (i.e., all 0s).
家庭ENRP服务器应在发送服务器的ID字段中填写其服务器ID，并将接收服务器的ID留空（即所有0）。
When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take the following actions:
当对等方收到此ENRP_HANDLE_UPDATE消息时，它必须采取以下操作：
1. If the named pool indicated by the pool handle does not exist in its local copy of the handlespace, the peer MUST create the named pool in its local handlespace and add the PE to the pool as the first PE. It MUST then copy in all other attributes of the PE carried in the message.
1. 如果池句柄指示的命名池在其handlespace的本地副本中不存在，则对等方必须在其本地handlespace中创建命名池，并将PE作为第一个PE添加到池中。然后，它必须复制消息中携带的PE的所有其他属性。
When the new pool is created, the overall member selection policy of the pool MUST be set to the policy type indicated by the PE.
创建新池时，池的整体成员选择策略必须设置为PE指示的策略类型。
2. If the named pool already exists in the peer's local copy of the handlespace *and* the PE does not exist, the peer MUST add the PE to the pool as a new PE and copy in all attributes of the PE carried in the message.
2. 如果命名池已存在于对等方handlespace*的本地副本中，并且*PE不存在，则对等方必须将PE作为新PE添加到池中，并复制消息中携带的PE的所有属性。
3. If the named pool exists *and* the PE is already a member of the pool, the peer MUST replace the attributes of the PE with the new information carried in the message.
3. 如果命名池存在*并且*PE已经是池的成员，则对等方必须用消息中携带的新信息替换PE的属性。
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公告，发送给家庭ENRP服务器的所有对等方。请参阅第3.1节，了解如何发送公告。
An ENRP server MUST announce the PE removal to all its peers in an ENRP_HANDLE_UPDATE message with the Update Action field set to DEL_PE, indicating the removal of an existing PE. The complete information of the PE and the pool it belongs to MUST be indicated in the message with a PE parameter and a Pool Handle parameter, respectively.
ENRP服务器必须在ENRP_HANDLE_UPDATE消息中向其所有对等方宣布PE删除，更新操作字段设置为DEL_PE，表示已删除PE。必须在消息中分别使用PE参数和pool Handle参数指示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.
当对等方收到此ENRP_HANDLE_UPDATE消息时，它必须首先在自己的handlespace中找到池和PE，然后从本地handlespace中删除PE。如果删除的PE是池中的最后一个PE，则对等方还必须从其本地handlespace中删除该池。
If the peer fails to find the PE or the pool in its handlespace, it SHOULD take no further actions.
如果对等方未能在其handlespace中找到PE或池，则不应采取进一步的操作。
An ENRP server MUST keep an internal record on the status of each of its known peers. This record is referred to as the server's "peer list".
ENRP服务器必须对其每个已知对等服务器的状态进行内部记录。此记录称为服务器的“对等列表”。
If a message of any type is received from a previously unknown peer, the ENRP server MUST consider this peer a new peer in the operational scope and add it to the peer list.
如果从先前未知的对等体接收到任何类型的消息，则EnrP服务器必须考虑该对等点在操作范围中的新对等点并将其添加到对等列表中。
The ENRP server MUST send an ENRP_PRESENCE message with the Reply-required flag set to '1' to the source address found in the arrived message. This will force the new peer to reply with its own ENRP_PRESENCE containing its full server information (see Section 2.1).
ENRP服务器必须向到达的消息中找到的源地址发送一条ENRP_状态消息，并将Reply required标志设置为“1”。这将迫使新的对等方以其自身的ENRP_状态回复，该状态包含其完整的服务器信息（参见第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.
每过一秒，ENRP服务器都必须向其所有对等方发出ENRP_状态消息，宣布其继续存在。在ENRP_状态消息中，ENRP服务器必须将“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_存在消息的到达将导致其所有对等方更新发送服务器的内部变量“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.
如果一个对等方未被监听的时间超过最长上次监听时间秒，ENRP服务器必须立即向该对等方发送一个点对点ENRP_状态，并将应答请求标志设置为“1”。
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在其家庭ENRP服务器出现故障时继续运行。
The initiating server SHOULD first start the takeover arbitration process by sending an ENRP_INIT_TAKEOVER message to all its peer servers. See Section 3.1 on how announcements are sent. In the message, the initiating server MUST fill in the Sending Server's ID and Targeting Server's ID. The goal is that only one ENRP server takes over the PE from the target.
发起服务器应首先通过向其所有对等服务器发送ENRP_INIT_takeover消息来启动接管仲裁过程。请参阅第3.1节，了解如何发送公告。在消息中，发起服务器必须填写发送服务器的ID和目标服务器的ID。目标是只有一台ENRP服务器从目标服务器接管PE。
After announcing the ENRP_INIT_TAKEOVER message ("group-casting" to all known peers, including the target server), the initiating server SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of its known peers, except that of the target server.
在向所有已知对等方（包括目标服务器）宣布ENRP_INIT_TAKEOVER（ENRP_INIT_TAKEOVER（ENRP_INIT_TAKEOVER_接管）消息（“组转换”）后，发起服务器应等待来自其每个已知对等方（目标服务器除外）的ENRP_INIT_TAKEOVER_ACK消息。
Each peer receiving an ENRP_INIT_TAKEOVER message from the initiating server MUST take the following actions:
从发起服务器接收ENRP_INIT_TAKEOVER消息的每个对等方必须采取以下措施：
1. If the peer server determines that it (itself) is the target server indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately announce an ENRP_PRESENCE message to all its peer ENRP servers in an attempt to stop this takeover process. This
1. 如果对等服务器确定其（自身）是ENRP_INIT_接管消息中指示的目标服务器，则必须立即向其所有对等ENRP服务器宣布ENRP_存在消息，以尝试停止此接管过程。这
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.
指示发起服务器的错误故障检测案例。启动服务器必须停止接管操作，方法是将目标服务器标记为“活动”，并且不采取进一步的接管操作。
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值小于到达的ENRP_INIT_接管消息中发送服务器的ID值，则对等服务器必须立即中止自己的接管尝试，不再采取自己的接管操作。此外，对等方必须在其内部对等方列表中将目标服务器标记为“非活动”，以便对等方不再监视其状态，并使用ENRP_INIT_TAKEOVER_ACK消息回复发起服务器。
B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER message.
B.否则，对等方必须忽略ENRP_INIT_TAKEOVER消息。
3. If the peer finds that it is neither the target server nor is in its own takeover process, the peer MUST: a) mark the target server as "not active" on its internal peer list so that its status will no longer be monitored by this peer, and b) MUST reply to the initiating server with an ENRP_INIT_TAKEOVER_ACK message.
3. 如果对等方发现它既不是目标服务器，也不在自己的接管过程中，则对等方必须：a）在其内部对等方列表中将目标服务器标记为“非活动”，以便其状态不再被该对等方监控，b）必须使用ENRP_INIT_takeover_ACK消息回复发起服务器。
Once the initiating server has received the ENRP_INIT_TAKEOVER_ACK message from all of its currently known peers (except for the target server), it MUST consider that it has won the arbitration and MUST proceed to complete the takeover, following the steps described in Section 3.5.2.
一旦发起服务器从所有当前已知的对等体（除了目标服务器除外）接收到EnrpIn IntIIOutOfLACK消息，则必须考虑它已经赢得仲裁，并且必须按照第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_存在，发起服务器必须立即停止接管过程，并将目标服务器的状态标记为“活动”。
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_服务器消息，通知其所有活动对等方接管已实施。消息中必须填写目标服务器的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:
然后，它应该检查handlespace的本地副本，并通过以下步骤声明目标服务器最初拥有的每个PE的所有权：
1. mark itself as the Home ENRP server of each of the PEs originally owned by the target server;
1. 将自身标记为目标服务器最初拥有的每个PEs的主ENRP服务器；
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采用发起服务器作为其新的家庭ENRP服务器。
When a peer receives the ENRP_TAKEOVER_SERVER message from the initiating server, it SHOULD update its local peer list and PE cache by following these steps:
当对等方从发起服务器接收到ENRP_TAKEOVER_SERVER消息时，应通过以下步骤更新其本地对等方列表和PE缓存：
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. 在handlespace的本地副本中将每个PE的主ENRP服务器更新为消息的发送者，即发起服务器。
Message losses or certain temporary breaks in network connectivity may result in data inconsistency in the local handlespace copy of some of the ENRP servers in an operational scope. Therefore, each ENRP server in the operational scope SHOULD periodically verify that its local copy of handlespace data is still in sync with that of its peers.
消息丢失或网络连接中的某些临时中断可能会导致操作范围内某些ENRP服务器的本地handlespace副本中的数据不一致。因此，运营范围内的每台ENRP服务器都应定期验证其handlespace数据的本地副本是否与其对等服务器的本地副本保持同步。
This section defines the auditing and re-synchronization procedures for an ENRP server to maintain its handlespace data consistency.
本节定义了ENRP服务器的审核和重新同步过程，以保持其handlespace数据的一致性。
A checksum covering the data that should be the same is exchanged to figure out whether or not the data is the same.
交换包含应该相同的数据的校验和，以确定数据是否相同。
The auditing of handlespace consistency is based on the following procedures:
handlespace一致性的审核基于以下程序：
1. An ENRP server SHOULD keep a separate PE checksum (a 16-bit integer internal variable) for each of its known peers and for itself. For an ENRP server with 'k' known peers, we denote these internal variables as "pe_checksum_pr0", "pe_checksum_pr1", ..., "pe_checksum_prk", where "pe_checksum_pr0" is the server's own PE checksum. The list of what these checksums cover and a detailed algorithm for calculating them is given in Section 3.6.2.
1. ENRP服务器应为其每个已知对等方和自身保留单独的PE校验和（16位整数内部变量）。对于具有“k”个已知对等点的ENRP服务器，我们将这些内部变量表示为“pe_checksum_pr0”、“pe_checksum_pr1”、“pe_checksum_prk”，其中“pe_checksum_pr0”是服务器自己的pe checksum。第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_状态时，它必须在消息中包含其当前PE校验和（即“PE_校验和_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）从对等ENRP服务器（服务器B）接收到PE校验和（在到达的ENRP_存在中携带）时，服务器A应将在ENRP_存在中找到的PE校验和与其自身的服务器B内部PE校验和（即“PE_校验和_prB”）进行比较。
4. If the two values match, server A will consider that there is no handlespace inconsistency between itself and server B, and it should take no further actions.
4. 如果这两个值匹配，服务器A将考虑自身和服务器B之间没有手空间不一致，并且它不应该采取进一步的行动。
5. If the two values do NOT match, server A SHOULD consider that there is a handlespace inconsistency between itself and server B, and a re-synchronization process SHOULD be carried out immediately with server B (see Section 3.6.3).
5. 如果这两个值不匹配，服务器A应该考虑到自身和服务器B之间有一个手空间不一致，并且应该立即用服务器B执行重新同步过程（参见3.3.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的内部handlespace中，当前有服务器B拥有的'M'个PE。然后，每个'M'个PE将使用以下字节块参与校验和计算：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle string of the pool the PE belongs (padded with :
: zeros to next 32-bit word boundary, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Id (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle string of the pool the PE belongs (padded with :
: zeros to next 32-bit word boundary, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Id (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, these are not TLVs. This byte block gives each PE a unique byte pattern in the scope. The 16-bit PE checksum for server B "pe_checksum_prB" is then calculated over the byte blocks contributed by the 'M' PEs one by one. The PE checksum calculation MUST use the Internet algorithm described in [RFC1071].
注意，这些不是TLV。此字节块在作用域中为每个PE提供唯一的字节模式。然后，服务器B“PE_checksum_prB”的16位PE校验和在“M”PE提供的字节块上逐个计算。PE校验和计算必须使用[RFC1071]中描述的互联网算法。
Server A MUST calculate its own PE checksum (i.e., "pe_checksum_pr0") in the same fashion, using the byte blocks of all the PEs owned by itself.
服务器A必须使用其拥有的所有PE的字节块，以相同的方式计算其自身的PE校验和（即“PE\U校验和\U pr0”）。
Note, whenever an ENRP finds that its internal handlespace has changed (e.g., due to PE registration/de-registration, receiving peer updates, removing failed PEs, downloading handlespace pieces from a peer, etc.), it MUST immediately update all its internal PE checksums that are affected by the change.
注意，每当ENRP发现其内部handlespace发生变化（例如，由于PE注册/注销、接收对等更新、删除失败的PE、从对等方下载handlespace部件等），它必须立即更新受变化影响的所有内部PE校验和。
Implementation Note: when the internal handlespace changes (e.g., a new PE added or an existing PE removed), an implementation need not re-calculate the affected PE checksum; it can instead simply update the checksum by adding or subtracting the byte block of the corresponding PE from the previous checksum value.
实施说明：当内部handlespace发生变化（例如，添加新PE或删除现有PE）时，实施无需重新计算受影响的PE校验和；相反，它可以简单地通过从先前的校验和值中添加或减去相应PE的字节块来更新校验和。
If an ENRP server determines that there is inconsistency between its local handlespace data and a peer's handlespace data with regard to the PEs owned by that peer, it MUST perform the following steps to re-synchronize the data:
如果ENRP服务器确定其本地handlespace数据与该对等方拥有的PEs的handlespace数据不一致，则必须执行以下步骤以重新同步数据：
1. The ENRP server SHOULD first "mark" every PE it knows about that is owned by the peer in its local handlespace database;
1. ENRP服务器应首先在其本地handlespace数据库中“标记”其知道的由对等方拥有的每个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服务器应向对等方发送一条ENRP_HANDLE_TABLE_请求消息，W标志设置为“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”的ENRP_HANDLE_TABLE_请求消息后，对等服务器应立即响应ENRP_HANDLE_TABLE_响应消息，其中列出了对等服务器当前拥有的所有PE。
4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the ENRP server SHOULD transfer the PE entries carried in the message into its local handlespace database. If a PE entry being transferred already exists in its local database, the ENRP server MUST replace the entry with the copy found in the message and remove the "mark" from the entry.
4. 收到ENRP_HANDLE_TABLE_响应消息后，ENRP服务器应将消息中包含的PE条目传输到其本地handlespace数据库中。如果正在传输的PE条目已经存在于其本地数据库中，ENRP服务器必须用消息中找到的副本替换该条目，并从条目中删除“标记”。
5. After transferring all the PE entries from the received ENRP_HANDLE_TABLE_RESPONSE message into its local database, the ENRP server SHOULD check whether there are still PE entries that remain "marked" in its local handlespace. If so, the ENRP server SHOULD silently remove those "marked" entries.
5. 将收到的ENRP_HANDLE_TABLE_响应消息中的所有PE条目传输到其本地数据库后，ENRP服务器应检查是否仍有PE条目在其本地handlespace中保持“标记”。如果是这样，ENRP服务器应该悄悄地删除那些“标记”的条目。
Note, similar to what is described in Section 3.2.3, the peer may reject the ENRP_HANDLE_TABLE_REQUEST or use more than one ENRP_HANDLE_TABLE_RESPONSE message to respond.
注意，与第3.2.3节所述类似，对等方可拒绝ENRP_句柄_表_请求或使用多个ENRP_句柄_表_响应消息进行响应。
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消息或包含未知参数的已知类型消息时，它应根据[RFC5354]第3节和第4节中定义的未识别消息和参数处理规则处理未知消息或未知参数。
According to the rules, if an error report to the message sender is needed, the ENRP server that discovered the error SHOULD send back an ENRP_ERROR message with a proper error cause code.
根据规则，如果需要向消息发送者发送错误报告，发现错误的ENRP服务器应发送回带有正确错误原因代码的ENRP_错误消息。
peer_last_heard - The local time that a peer server was last heard (via receiving either a group-cast or point-to-point message from the peer).
peer_last_heard—上次听到对等服务器的本地时间（通过接收来自对等服务器的组广播或点对点消息）。
pe_checksum_pr - The internal 16-bit PE checksum that an ENRP server keeps for a peer. A separate PE checksum is kept for each of its known peers as well as for itself.
pe_校验和\u pr-ENRP服务器为对等方保留的内部16位pe校验和。为每个已知对等方以及自身保留单独的PE校验和。
PEER-HEARTBEAT-CYCLE - The period for an ENRP server to announce a heartbeat message to all its known peers. (Default=30 secs.)
PEER-HEARTBEAT-CYCLE—ENRP服务器向其所有已知对等方宣布心跳消息的时间段。（默认值为30秒。）
MAX-TIME-LAST-HEARD - Pre-set threshold for how long an ENRP server will wait before considering a silent peer server potentially dead. (Default=61 secs.)
MAX-TIME-LAST-HEARD-为ENRP服务器在考虑静默对等服务器可能死机之前等待的时间预设阈值。（默认值为61秒。）
MAX-TIME-NO-RESPONSE - Pre-set threshold for how long a message sender will wait for a response after sending out a message. (Default=5 secs.)
MAX-TIME-NO-RESPONSE（最大时间无响应）-为消息发送者在发送消息后等待响应的时间预设阈值。（默认值为5秒。）
This document (RFC 5353) is the reference for all registrations described in this section. All registrations have been listed on the RSerPool Parameters page.
本文件（RFC 5353）是本节所述所有注册的参考文件。所有注册都已列在RSerPool参数页面上。
ENRP Message Types are maintained by IANA. Ten initial values have been assigned by IANA, as described in Figure 1. IANA created a new table, "ENRP Message Types":
ENRP消息类型由IANA维护。IANA分配了十个初始值，如图1所示。IANA创建了一个新表“ENRP消息类型”：
Type Message Name Reference
----- ------------------------- ---------
0x00 (Reserved by IETF) RFC 5353
0x01 ENRP_PRESENCE RFC 5353
0x02 ENRP_HANDLE_TABLE_REQUEST RFC 5353
0x03 ENRP_HANDLE_TABLE_RESPONSE RFC 5353
0x04 ENRP_HANDLE_UPDATE RFC 5353
0x05 ENRP_LIST_REQUEST RFC 5353
0x06 ENRP_LIST_RESPONSE RFC 5353
0x07 ENRP_INIT_TAKEOVER RFC 5353
0x08 ENRP_INIT_TAKEOVER_ACK RFC 5353
0x09 ENRP_TAKEOVER_SERVER RFC 5353
0x0a ENRP_ERROR RFC 5353
0x0b-0xff (Available for assignment) RFC 5353
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分配了两个初始值。IANA创建了一个新表“更新操作类型”：
Type Update Action Reference
------------- -------------------- ---------
0x0000 ADD_PE RFC 5353
0x0001 DEL_PE RFC 5353
0x0002-0xffff (Available for assignment) RFC 5353
Type Update Action Reference
------------- -------------------- ---------
0x0000 ADD_PE RFC 5353
0x0001 DEL_PE RFC 5353
0x0002-0xffff (Available for assignment) RFC 5353
Requests to register an Update Action Type in this table should be sent to IANA. The number must be unique. The "Specification Required" policy of [RFC5226] MUST be applied.
在此表中注册更新操作类型的请求应发送给IANA。号码必须是唯一的。必须采用[RFC5226]的“要求规范”政策。
The references for the already assigned port numbers
已分配端口号的引用
enrp-udp 9901/udp
enrp udp 9901/udp
enrp-sctp 9901/sctp
enrp sctp 9901/sctp
enrp-sctp-tls 9902/sctp
enrp sctp tls 9902/sctp
have been updated to RFC 5353.
已更新至RFC 5353。
The reference for the already assigned ENRP payload protocol identifier 12 have been updated to RFC 5353.
已分配的ENRP有效负载协议标识符12的参考已更新为RFC 5353。
We present a summary of the threats to the RSerPool architecture and describe security requirements in response to mitigate the threats. Next, we present the security mechanisms, based on TLS, that are implementation requirements in response to the threats. Finally, we present a chain-of-trust argument that examines critical data paths in RSerPool and shows how these paths are protected by the TLS implementation.
我们总结了RSerPool体系结构面临的威胁，并描述了为缓解这些威胁而采取的安全要求。接下来，我们将介绍基于TLS的安全机制，它们是响应威胁的实现需求。最后，我们提供了一个信任链参数，该参数检查RSerPool中的关键数据路径，并显示TLS实现如何保护这些路径。
"Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats" [RFC5355] describes the threats to the RSerPool architecture in detail and lists the security requirements in response to each threat. From the threats described in this document, the security services required for the RSerPool protocol are enumerated below.
“可靠服务器池（RSerPool）带来的威胁和应对威胁的安全要求”[RFC5355]详细描述了对RSerPool体系结构的威胁，并列出了应对每个威胁的安全要求。根据本文档中描述的威胁，下面列举了RSerPool协议所需的安全服务。
Threat 1) PE registration/de-registration flooding or spoofing
-----------
Security mechanism in response: ENRP server authenticates the PE.
Threat 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.
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 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 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 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 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 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
-----------
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.
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)
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\u RSA\u和\u AES\u 128\u CBC\u SHA密码套件必须至少由TLS for RSerPool的实施者支持。为了向后兼容，ENRP应支持TLS_RSA_和_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服务器、PEs和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-to-ENRP身份验证和PE-to-ENRP身份验证的身份验证机制来实现。对于PSK，拥有预共享密钥构成授权。池的网络管理员需要决定哪些节点有权参与池。PSK的理由是我们假设一个管理域将控制和管理服务器池。这允许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作为PUs到ENRP服务器的身份验证机制来实现。PUs必须使用证书对ENRP服务器进行身份验证。ENRP服务器必须拥有一个站点证书，其主题与其规范主机名对应。PUs可能有自己的证书，用于与TLS相互认证，但本文件中没有规定其使用。支持TLS的所有RSerPool元素必须具有验证TLS协商期间收到的证书的机制；这需要拥有一个或多个由证书颁发机构颁发的根证书（最好是与为web浏览器颁发根证书的机构相当的站点证书的知名分销商）。
In order to prevent man-in-the-middle attacks, the client MUST verify the server's identity (as presented in the server's Certificate message). The client's understanding of the server's identity (typically the identity used to establish the transport connection) is called the "reference identity". The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types
为了防止中间人攻击，客户端必须验证服务器的身份（如服务器的证书消息中所示）。客户端对服务器标识（通常是用于建立传输连接的标识）的理解称为“参考标识”。客户端确定参考标识的类型（例如DNS名称或IP地址），并在参考标识和相应类型的每个subjectAltName值之间执行比较，直到生成匹配。一旦生成匹配项，服务器的标识就已验证，并且服务器标识检查已完成。不同的subjectAltName类型
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).
它们以不同的方式匹配。客户端可以在执行比较之前将参考标识映射到不同的类型。可以对引用标识可以映射到的所有可用subjectAltName类型执行映射；但是，引用标识应仅映射到映射本身是安全的（例如，从URI提取DNS名称以与dNSName类型的subjectAltName进行比较）或映射以安全方式（例如，使用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.
如果服务器标识检查失败，面向用户的客户端应通知用户或关闭传输连接，并指示服务器标识可疑。自动客户端应关闭传输连接，然后返回或记录一个错误，表明服务器的身份可疑，或两者都有。除了本节中描述的服务器身份检查之外，客户机还应该准备进行进一步的检查，以确保服务器有权提供请求提供的服务。客户可能需要利用当地的政策信息来确定。
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).
如果参考标识是一个国际化域名，则一致性实现必须将其转换为[RFC3490]第4节规定的ASCII兼容编码（ACE）格式，然后再与dNSName类型的subjectAltName值进行比较。具体而言，一致性实现必须执行[RFC3490]第4节中规定的转换操作，如下：*在步骤1中，域名应被视为“存储字符串”；*在步骤3中，设置名为“usestd3ascirules”的标志*在步骤4中，使用“ToASCII”操作处理每个标签；和*在步骤5中，将所有标签分隔符更改为U+002E（句号）。
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality according to the rules specified in Section 3 of RFC 3490. The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then, only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
执行“到ASCII”转换后，必须根据RFC 3490第3节中规定的规则比较DNS标签和名称是否相等。dNSName类型的subjectAltName值中允许使用“*”（ASCII 42）通配符，然后仅作为该值中最左侧（最低有效）的DNS标签。此通配符与服务器名称中最左边的DNS标签匹配。也就是说，subject*.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
当参考标识为IP地址时，该标识必须转换为“网络字节顺序”八位字节字符串表示RFC 791[RFC0791]和RFC 2460[RFC2460]。对于IP版本4，如RFC 791中所述，八位字节字符串将正好包含四个八位字节。对于IP版本6，如RFC 2460中所规定，八位字节字符串将正好包含十六个八位字节。然后将此八位字节字符串与
subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical.
iPAddress类型的subjectAltName值。如果引用标识八位字节字符串和值八位字节字符串相同，则会发生匹配。
After a TLS layer is established in a session, both parties are to independently decide whether or not to continue based on local policy and the security level achieved. If either party decides that the security level is inadequate for it to continue, it SHOULD remove the TLS layer immediately after the TLS (re)negotiation has completed (see RFC 4511)[RFC4511]. Implementations may re-evaluate the security level at any time and, upon finding it inadequate, should remove the TLS layer.
在会话中建立TLS层后，双方将根据本地策略和达到的安全级别独立决定是否继续。如果任何一方决定安全级别不足以继续，则应在TLS（重新）协商完成后立即移除TLS层（参见RFC 4511）[RFC4511]。实施可能会在任何时候重新评估安全级别，如果发现不充分，应移除TLS层。
Implementations MUST support TLS with SCTP, as described in [RFC3436] or TLS over TCP, as described in [RFC5246]. When using TLS/SCTP we must ensure that RSerPool does not use any features of SCTP that are not available to a TLS/SCTP user. This is not a difficult technical problem, but simply a requirement. When describing an API of the RSerPool lower layer, we also have to take into account the differences between TLS and SCTP.
实现必须支持带有SCTP的TLS，如[RFC3436]所述，或通过TCP的TLS，如[RFC5246]所述。使用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协议限制发送到ENRP服务器的ASAP_端点_不可访问消息的数量（参见RFC 5352第3.5节）。
Threat 9 requires the ENRP protocol to limit the number of ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE.
威胁9要求ENRP协议限制从ENRP服务器到PE的ASAP_ENDPOINT_KEEP_ALIVE消息的数量。
There is no security mechanism defined for the multicast announcements. Therefore, a receiver of such an announcement cannot consider the source address of such a message to be a trustworthy address of an ENRP server. A receiver must also be prepared to receive a large number of multicast announcements from attackers.
没有为多播公告定义安全机制。因此，这样的通知的接收器不能认为这样的消息的源地址是Enrp服务器的可信地址。接收者还必须准备好接收来自攻击者的大量多播通知。
Security is mandatory to implement in RSerPool and is based on TLS implementation in all three architecture components that comprise RSerPool -- namely PU, PE, and the ENRP server. We define an ENRP server that uses TLS for all communication and authenticates ENRP peers and PE registrants to be a secured ENRP server.
安全性是必须在RSerPool中实现的，并且基于构成RSerPool的所有三个体系结构组件（即PU、PE和ENRP服务器）中的TLS实现。我们定义了一个使用TLS进行所有通信的ENRP服务器，并将ENRP对等方和PE注册者认证为安全的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)
PU <---> secured ENRP server (authentication of ENRP server;
queries over TLS)
PE <---> secured ENRP server (mutual authentication;
registration/de-registration over TLS)
secured ENRP server <---> secured ENRP server (mutual authentication;
database updates using TLS)
If all components of the system authenticate and communicate using TLS, the chain of trust is sound. The root of the trust chain is the ENRP server. If that is secured using TLS, then security will be enforced for all ENRP and PE components that try to connect to it.
如果系统的所有组件都使用TLS进行身份验证和通信，则信任链是健全的。信任链的根是ENRP服务器。如果使用TLS对其进行保护，则将对所有尝试连接到它的ENRP和PE组件实施安全保护。
Summary of interaction between secured and unsecured components: If the PE does not use TLS and tries to register with a secure ENRP server, it will receive an error message response indicated as an error due to security considerations and the registration will be rejected. If an ENRP server that does not use TLS tries to update the database of a secure ENRP server, then the update will be rejected. If a PU does not use TLS and communicates with a secure ENRP server, it will get a response with the understanding that the response is not secure, as the response can be tampered with in transit even if the ENRP database is secured.
安全组件和非安全组件之间的交互摘要：如果PE不使用TLS并尝试向安全ENRP服务器注册，则出于安全考虑，它将收到一条错误消息响应，指示为错误，注册将被拒绝。如果不使用TLS的ENRP服务器尝试更新安全ENRP服务器的数据库，则更新将被拒绝。如果PU不使用TLS并与安全的ENRP服务器通信，它将得到一个响应，并理解该响应是不安全的，因为即使ENRP数据库是安全的，响应也可能在传输过程中被篡改。
The final case is the PU sending a secure request to ENRP. It might be that ENRP and PEs are not secured and this is an allowable configuration. The intent is to secure the communication over the Internet between the PU and the ENRP server.
最后一种情况是PU向ENRP发送安全请求。可能是ENRP和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体系结构组件可以相互通信以建立信任链。安全的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.
作者希望感谢John Loughney、Lyndon Ong、Walter Johnson、Thomas Dreibholz、Frank Volkmer和许多其他人的宝贵意见和反馈。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年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，“计算互联网校验和”，RFC 10711988年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，2002年1月。
[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 34902003年3月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，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，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, September 2008.
[RFC5354]Stewart，R.，Xie，Q.，Stillman，M.，和M.Tuexen，“聚合服务器访问协议（ASAP）和端点Handlespace冗余协议（ENRP）参数”，RFC 53542008年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，“聚合服务器访问协议（ASAP）”，RFC 53522008年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 53552008年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，“流控制传输协议（SCTP）的套接字API扩展”，正在进行的工作，2008年7月。
Authors' Addresses
作者地址
Qiaobing Xie The Resource Group 1700 Pennsylvania Ave NW Suite 560 Washington, D.C., 20006 USA
美国华盛顿特区宾夕法尼亚大道西北1700号560室，邮编20006
Phone: +1 224-465-5954
EMail: Qiaobing.Xie@gmail.com
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号560室，邮编：20006
Phone: EMail: randall@lakerest.net
电话：电邮：randall@lakerest.net
Maureen Stillman Nokia 1167 Peachtree Ct. Naperville, IL 60540 US
Maureen Stillman诺基亚1167桃树Ct。伊利诺伊州纳珀维尔60540美国
Phone: EMail: maureen.stillman@nokia.com
电话：电子邮件：莫林。stillman@nokia.com
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
Michael Tuexen Muenster应用科学大学Stegerwaldstr。39 48565德国斯坦福德
EMail: tuexen@fh-muenster.de
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美国伊利诺伊州芝加哥60606
Phone: EMail: ajs.ietf@gmail.com
电话：电子邮件：ajs。ietf@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.