Network Working Group P. Lei
Request for Comments: 5351 Cisco Systems, Inc.
Category: Informational L. Ong
Ciena Corporation
M. Tuexen
Muenster Univ. of Applied Sciences
T. Dreibholz
University of Duisburg-Essen
September 2008
Network Working Group P. Lei
Request for Comments: 5351 Cisco Systems, Inc.
Category: Informational L. Ong
Ciena Corporation
M. Tuexen
Muenster Univ. of Applied Sciences
T. Dreibholz
University of Duisburg-Essen
September 2008
An Overview of Reliable Server Pooling Protocols
可靠服务器池协议概述
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite.
可靠的服务器池工作（缩写为“RSerPool”）提供了一组独立于应用程序的服务和协议，用于构建容错和高可用的客户端/服务器应用程序。本文档概述了可靠服务器池套件中的协议和机制。
Table of Contents
目录
1. Introduction ....................................................3
2. Aggregate Server Access Protocol (ASAP) Overview ................6
2.1. Pool Initialization ........................................6
2.2. Pool Entity Registration ...................................6
2.3. Pool Entity Selection ......................................7
2.4. Endpoint Keep-Alive ........................................7
2.5. Failover Services ..........................................7
2.5.1. Cookie Mechanism ....................................7
2.5.2. Business Card Mechanism .............................8
3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview ........8
3.1. Initialization .............................................8
3.2. Server Discovery and Home Server Selection .................8
3.3. Failure Detection, Handlespace Audit, and Synchronization ..9
3.4. Server Takeover ............................................9
4. Example Scenarios ...............................................9
4.1. Example Scenario Using RSerPool Resolution Service .........9
4.2. Example Scenario Using RSerPool Session Services ..........11
5. Reference Implementation .......................................12
6. Security Considerations ........................................12
7. IANA Considerations ............................................12
8. Acknowledgements ...............................................12
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
1. Introduction ....................................................3
2. Aggregate Server Access Protocol (ASAP) Overview ................6
2.1. Pool Initialization ........................................6
2.2. Pool Entity Registration ...................................6
2.3. Pool Entity Selection ......................................7
2.4. Endpoint Keep-Alive ........................................7
2.5. Failover Services ..........................................7
2.5.1. Cookie Mechanism ....................................7
2.5.2. Business Card Mechanism .............................8
3. Endpoint Handlespace Redundancy Protocol (ENRP) Overview ........8
3.1. Initialization .............................................8
3.2. Server Discovery and Home Server Selection .................8
3.3. Failure Detection, Handlespace Audit, and Synchronization ..9
3.4. Server Takeover ............................................9
4. Example Scenarios ...............................................9
4.1. Example Scenario Using RSerPool Resolution Service .........9
4.2. Example Scenario Using RSerPool Session Services ..........11
5. Reference Implementation .......................................12
6. Security Considerations ........................................12
7. IANA Considerations ............................................12
8. Acknowledgements ...............................................12
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
The Reliable Server Pooling (RSerPool) protocol suite is designed to provide client applications ("pool users") with the ability to select a server (a "pool element") from among a group of servers providing equivalent service (a "pool"). The protocols are currently targeted for Experimental Track.
可靠服务器池（RSerPool）协议套件旨在为客户端应用程序（“池用户”）提供从提供等效服务的一组服务器（池）中选择服务器（“池元素”）的能力。这些协议目前是针对实验轨道的。
The RSerPool architecture supports high availability and load balancing by enabling a pool user to identify the most appropriate server from the server pool at a given time. The architecture is defined to support a set of basic goals:
RSerPool体系结构支持高可用性和负载平衡，使池用户能够在给定时间从服务器池中识别最合适的服务器。体系结构的定义是为了支持一组基本目标：
o application-independent protocol mechanisms
o 独立于应用程序的协议机制
o separation of server naming from IP addressing
o 服务器命名与IP寻址的分离
o use of the end-to-end principle to avoid dependencies on intermediate equipment
o 使用端到端原则避免对中间设备的依赖
o separation of session availability/failover functionality from the application itself
o 将会话可用性/故障切换功能与应用程序本身分离
o facilitation of different server selection policies
o 促进不同的服务器选择策略
o facilitation of a set of application-independent failover capabilities
o 促进一组独立于应用程序的故障切换功能
o peer-to-peer structure
o 对等结构
The basic components of the RSerPool architecture are shown in Figure 1 below:
RSerPool体系结构的基本组件如下图1所示：
.......................
______ ______ . +-------+ .
/ ENRP \ / ENRP \ . | | .
|Server| <----> |Server|<----------.----->| PE 1 | .
\______/ ENRP \______/ ASAP(1) . | | .
^ . +-------+ .
| . .
| ASAP(2) . Server Pool .
V . .
+-------+ . +-------+ .
| | . | | .
| PU |<---------->. | PE 2 | .
| | PU to PE . | | .
+-------+ . +-------+ .
. .
. +-------+ .
. | | .
. | PE 3 | .
. | | .
. +-------+ .
.......................
.......................
______ ______ . +-------+ .
/ ENRP \ / ENRP \ . | | .
|Server| <----> |Server|<----------.----->| PE 1 | .
\______/ ENRP \______/ ASAP(1) . | | .
^ . +-------+ .
| . .
| ASAP(2) . Server Pool .
V . .
+-------+ . +-------+ .
| | . | | .
| PU |<---------->. | PE 2 | .
| | PU to PE . | | .
+-------+ . +-------+ .
. .
. +-------+ .
. | | .
. | PE 3 | .
. | | .
. +-------+ .
.......................
Figure 1
图1
A server pool is defined as a set of one or more servers providing the same application functionality. The servers are called Pool Elements (PEs). Multiple PEs in a server pool can be used to provide fault tolerance or load sharing, for example. The PEs register into and de-register out of the pool at an entity called the Endpoint haNdlespace Redundancy Protocol (ENRP) server, using the Aggregate Server Access Protocol (ASAP) [RFC5352] (this association is labeled ASAP(1) in the figure).
服务器池定义为一组提供相同应用程序功能的一个或多个服务器。这些服务器称为池元素（PE）。例如，服务器池中的多个PE可用于提供容错或负载共享。PEs使用聚合服务器访问协议（ASAP）[RFC5352]在名为Endpoint haNdlespace Redundancy Protocol（ENRP）服务器的实体上注册到池中并从池中注销（该关联在图中标记为ASAP（1））。
Each server pool is identified by a unique byte string called the pool handle (PH). The pool handle allows a mapping from the pool to a specific PE located by its IP address (both IPv4 and IPv6 PE addresses are supported) and port number. The pool handle is what is specified by the Pool User (PU) when it attempts to access a server in the pool. To resolve the pool handle to the address necessary to access a PE, the PU consults an ENRP server using ASAP (this association is labeled ASAP(2) in the figure). The space of pool handles is assumed to be a flat space with limited operational scope (see RFC 3237 [RFC3237]). Administration of pool handles is not addressed by the RSerPool protocol documents at this time. The protocols used between the PU and PE are application-specific. It is assumed that the PU and PE are configured to support a common set of protocols for application layer communication, independent of the RSerPool mechanisms.
每个服务器池由一个称为池句柄（PH）的唯一字节字符串标识。池句柄允许从池映射到通过其IP地址（支持IPv4和IPv6 PE地址）和端口号定位的特定PE。池句柄是池用户（PU）在尝试访问池中的服务器时指定的句柄。为了将池句柄解析为访问PE所需的地址，PU使用ASAP咨询ENRP服务器（该关联在图中标记为ASAP（2））。假定池句柄的空间为平面空间，操作范围有限（见RFC 3237[RFC3237]）。目前，RSerPool协议文档未涉及池句柄的管理。PU和PE之间使用的协议是特定于应用程序的。假定PU和PE配置为支持应用层通信的公共协议集，独立于RSerPool机制。
RSerPool provides a number of tools to aid client migration between servers on server failure: it allows the client to identify alternative servers, either on initial discovery or in real time; it also allows the original server to provide a state cookie to the client that can be forwarded to an alternative server to provide application-specific state information. This information is exchanged between the PE and PU directly, over the association labeled PU to PE in the figure.
RSerPool提供了许多工具来帮助客户机在服务器故障时在服务器之间迁移：它允许客户机在初始发现时或实时识别备用服务器；它还允许原始服务器向客户端提供状态cookie，该cookie可以转发到替代服务器，以提供特定于应用程序的状态信息。该信息在PE和PU之间通过图中标记为PU-to-PE的关联直接交换。
It is envisioned that ENRP servers provide a fully distributed and fault-tolerant registry service. They use ENRP [RFC5353] to maintain synchronization of data concerning the pool handle mapping space. For PUs and PEs, the ENRP servers are functionally equal. Due to the synchronization provided by ENRP, they can contact an arbitrary one for registration/de-registration (PE) or PH resolution (PU). An illustration containing 3 ENRP servers is provided in Figure 2 below:
设想ENRP服务器提供完全分布式和容错的注册表服务。他们使用ENRP[RFC5353]来维护与池句柄映射空间有关的数据的同步。对于PUs和PEs，ENRP服务器在功能上是相同的。由于ENRP提供的同步，他们可以联系任意一家进行注册/注销（PE）或PH解析（PU）。下图2提供了包含3台ENRP服务器的插图：
______ _____
... / ENRP \ / ENRP \ ...
PEs/PUs <---->|Server| <----> |Server|<----> PEs/PUs
... ASAP \______/ ENRP \______/ ASAP ...
^ ^
| |
| / ENRP \ |
+---->|Server|<----+
ENRP \______/ ENRP
^
| ASAP
v
...
PEs/PUs
...
______ _____
... / ENRP \ / ENRP \ ...
PEs/PUs <---->|Server| <----> |Server|<----> PEs/PUs
... ASAP \______/ ENRP \______/ ASAP ...
^ ^
| |
| / ENRP \ |
+---->|Server|<----+
ENRP \______/ ENRP
^
| ASAP
v
...
PEs/PUs
...
Figure 2
图2
The requirements for the Reliable Server Pooling framework are defined in RFC 3237 [RFC3237]. It is worth noting that the requirements on RSerPool in the area of load balancing partially overlap with grid computing/high-performance computing. However, the scope of both areas is completely different: grid and high-performance computing also cover topics like managing different administrative domains, data locking and synchronization, inter-session communication, and resource accounting for powerful computation services, but the intention of RSerPool is simply a lightweight realization of load distribution and session management. In particular, these functionalities are intended to be used on
RFC 3237[RFC3237]中定义了可靠服务器池框架的要求。值得注意的是，在负载平衡领域对RSerPool的要求与网格计算/高性能计算部分重叠。但是，这两个领域的范围完全不同：网格和高性能计算还包括管理不同的管理域、数据锁定和同步、会话间通信以及强大计算服务的资源核算等主题，但是RSerPool的目的只是轻量级地实现负载分配和会话管理。特别是，这些功能旨在用于
systems with small memory and CPU resources only. Any further functionality is not in the scope of RSerPool and can -- if necessary -- be provided by the application itself.
只有少量内存和CPU资源的系统。任何进一步的功能都不在RSerPool的范围内，如果需要，可以由应用程序本身提供。
This document provides an overview of the RSerPool protocol suite, specifically the Aggregate Server Access Protocol (ASAP) [RFC5352] and the Endpoint Handlespace Redundancy Protocol (ENRP) [RFC5353]. In addition to the protocol specifications, there is a common parameter format specification [RFC5354] for both protocols, a definition of server selection rules (pool policies) [RFC5356], as well as a security threat analysis [RFC5355].
本文档概述了RSerPool协议套件，特别是聚合服务器访问协议（ASAP）[RFC5352]和端点Handlespace冗余协议（ENRP）[RFC5353]。除了协议规范外，两个协议都有一个通用参数格式规范[RFC5354]，一个服务器选择规则（池策略）[RFC5356]的定义，以及一个安全威胁分析[RFC5355]。
ASAP defines a straightforward set of mechanisms necessary to support the creation and maintenance of pools of redundant servers. These mechanisms include:
ASAP定义了一组支持创建和维护冗余服务器池所需的简单机制。这些机制包括：
o registration of a new server into a server pool
o 将新服务器注册到服务器池中
o de-registration of an existing server from a pool
o 从池中注销现有服务器
o resolution of a pool handle to a server or list of servers
o 将池句柄解析为服务器或服务器列表
o liveness detection for servers in a pool
o 池中服务器的活动性检测
o failover mechanisms for handling a server failure
o 用于处理服务器故障的故障转移机制
Pools come into existence when a PE registers the first instance of the pool name with an ENRP server. They disappear when the last PE de-registers. In other words, the starting of the first PE on some machine causes the creation of the pool when the registration reaches the ENRP server.
当PE向ENRP服务器注册池名称的第一个实例时，池就存在了。当最后一个PE注销时，它们消失。换句话说，当注册到达ENRP服务器时，在某些机器上启动第一个PE会导致创建池。
It is assumed that information needed for RSerPool, such as the address of an ENRP server to contact, is configured into the PE beforehand. Methods of automating this configuration process are not addressed at this time.
假定RSerPool所需的信息（如要联系的ENRP服务器的地址）已事先配置到PE中。目前还没有介绍自动化此配置过程的方法。
A new server joins an existing pool by sending a Registration message via ASAP to an ENRP server, indicating the pool handle of the pool that it wishes to join, a PE identifier for itself (chosen randomly), information about its lifetime in the pool, and what transport
新服务器通过ASAP向ENRP服务器发送注册消息来加入现有池，该消息指示其希望加入的池的池句柄、自身的PE标识符（随机选择）、关于其在池中的生存期的信息以及传输方式
protocols and selection policy it supports. The ENRP server that it first contacts is called its Home ENRP server, and maintains a list of subscriptions by the PE as well as performs periodic audits to confirm that the PE is still responsive.
它支持的协议和选择策略。它首先联系的ENRP服务器称为其主ENRP服务器，维护PE订阅的列表，并定期进行审核，以确认PE仍有响应。
Similar procedures are applied to de-register itself from the server pool (or, alternatively, the server may simply let the lifetime that it previously registered with expire, after which it is gracefully removed from the pool).
类似的过程也适用于从服务器池中注销自身（或者，服务器可以简单地让其先前注册的生存期过期，然后将其从池中删除）。
When an endpoint wishes to be connected to a server in the pool, it generates an ASAP Handle Resolution message and sends this to its Home ENRP server. The ENRP server resolves the handle based on its knowledge of pool servers and returns a Handle Resolution Response message via ASAP. The response contains a list of the IP addresses of one or more servers in the pool that can be contacted. The process by which the list of servers is created may involve a number of policies for server selection. The RSerPool protocol suite defines a few basic policies and allows the use of external server selection input for more complex policies.
当端点希望连接到池中的服务器时，它会生成一条ASAP句柄解析消息，并将此消息发送到其主ENRP服务器。ENRP服务器根据其对池服务器的了解来解析句柄，并通过ASAP返回句柄解析响应消息。响应包含池中可联系的一个或多个服务器的IP地址列表。创建服务器列表的过程可能涉及许多服务器选择策略。RSerPool协议套件定义了一些基本策略，并允许使用外部服务器选择输入来实现更复杂的策略。
ENRP servers monitor the status of pool elements using the ASAP Endpoint Keep-Alive message. A PE responds to the ASAP Keep-Alive message with an Endpoint Keep-Alive Ack response.
ENRP服务器使用ASAP端点保持活动消息监视池元素的状态。PE使用端点保持活动Ack响应来响应ASAP保持活动消息。
In addition, a PU can notify its Home ENRP server that the PE it used has become unresponsive by sending an ASAP Endpoint Unreachable message to the ENRP server.
此外，PU可以通过向ENRP服务器发送ASAP端点不可访问消息来通知其家庭ENRP服务器其使用的PE已无响应。
While maintaining application-independence, the RSerPool protocol suite provides some simple hooks for supporting failover of an individual session with a pool element. Generally, mechanisms for failover that rely on application state or transaction status cannot be defined without more specific knowledge of the application being supported. However, some simple mechanisms supported by RSerPool allow some level of failover that any application can use.
在保持应用程序独立性的同时，RSerPool协议套件提供了一些简单的挂钩，用于支持使用池元素的单个会话的故障切换。通常，如果不了解所支持的应用程序的更多具体信息，就无法定义依赖于应用程序状态或事务状态的故障切换机制。但是，RSerPool支持的一些简单机制允许任何应用程序都可以使用某种级别的故障切换。
Cookies may optionally be generated by the ASAP layer and periodically sent from the PE to the PU. The PU only stores the last received cookie. In case of failover, the PU sends this last
cookie可以选择性地由ASAP层生成，并定期从PE发送到PU。PU仅存储最后收到的cookie。在故障转移的情况下，PU将最后发送此消息
received cookie to the new PE. This method provides a simple way of state sharing between the PEs. Please note that the old PE should sign the cookie, and the receiving PE should verify that signature. For the PU, the cookie has no structure and is only stored and transmitted to the new PE.
接收到新PE的cookie。该方法提供了PEs之间状态共享的简单方法。请注意，旧PE应在cookie上签名，接收PE应验证该签名。对于PU，cookie没有结构，仅存储并传输到新PE。
A PE can send a business card to its peer (PE or PU) containing its pool handle and guidance concerning which other PEs the peer should use for failover. This gives a PE a means of telling a PU what it identifies as the "next best" PE to use in case of failure, which may be based on pool considerations, such as load balancing, or user considerations, such as PEs that have the most up-to-date state information.
PE可以向其对等方（PE或PU）发送一张名片，其中包含其池句柄以及关于对等方应使用哪些其他PE进行故障切换的指导。这为PE提供了一种方法，告诉PU在发生故障时，它将使用什么“下一个最佳”PE，这可能是基于池考虑因素（如负载平衡）或用户考虑因素（如具有最新状态信息的PE）。
A set of server pools, which is denoted as a handlespace, is managed by ENRP servers. Pools are not valid in the whole Internet but only in smaller domains, called the operational scope. The ENRP servers use the ENRP protocol in order to maintain a distributed, fault-tolerant, real-time registry service. ENRP servers communicate with each other for information exchange, such as pool membership changes, handlespace data synchronization, etc.
一组服务器池（表示为handlespace）由ENRP服务器管理。池在整个Internet中无效，但仅在较小的域（称为操作范围）中有效。ENRP服务器使用ENRP协议来维护分布式、容错、实时注册表服务。ENRP服务器相互通信以进行信息交换，如池成员身份更改、handlespace数据同步等。
Each ENRP server initially generates a 32-bit server ID that it uses in subsequent messaging and remains unchanged over the lifetime of the server. It then attempts to learn all of the other ENRP servers within the scope of the server pool, either by using a pre-defined Mentor server or by sending out Presence messages on a well-known multicast channel in order to determine other ENRP servers from the responses and select one as Mentor. A Mentor can be any peer ENRP server. The most current handlespace data is requested by Handle Table Requests from the Mentor. The received answer in the form of Handle Table Response messages is unpacked into the local database. After that, the ENRP server is ready to provide ENRP services.
每个ENRP服务器最初生成一个32位服务器ID，用于后续消息传递，并在服务器的生命周期内保持不变。然后，它尝试学习服务器池范围内的所有其他ENRP服务器，或者使用预定义的Mentor服务器，或者通过在已知的多播通道上发送状态消息，以便从响应中确定其他ENRP服务器，并选择一个作为Mentor。导师可以是任何对等的ENRP服务器。最新的handlespace数据由来自Mentor的Handle表请求请求。以句柄表响应消息的形式接收到的应答被解包到本地数据库中。之后，ENRP服务器准备好提供ENRP服务。
PEs can now register their presence with the newly functioning ENRP server by using ASAP messages. They discover the new ENRP server after the server sends out an ASAP Server Announce message on the well-known ASAP multicast channel. PEs only have to register with
PEs现在可以使用ASAP消息在新运行的ENRP服务器上注册其存在。在服务器在著名的ASAP多播通道上发送ASAP服务器公告消息后，他们发现了新的ENRP服务器。PEs只需注册到
one ENRP server, as other ENRP servers supporting the pool will synchronize their knowledge about pool elements using the ENRP protocol.
一个ENRP服务器和支持池的其他ENRP服务器将使用ENRP协议同步其关于池元素的知识。
The PE may have a configured list of ENRP servers to talk to, in the form of a list of IP addresses, in which case it will start to set up associations with some number of them and assign the first one that responds to it as its Home ENRP server.
PE可能有一个配置的ENRP服务器列表，以IP地址列表的形式与之对话，在这种情况下，PE将开始建立与其中一些服务器的关联，并将响应它的第一个服务器分配为其主ENRP服务器。
Alternatively, it can listen on the multicast channel for a set period, and when it hears an ENRP server, start an association. The first server it gets up can then become its Home ENRP server.
或者，它可以在多播频道上监听一段时间，当它听到ENRP服务器时，启动关联。它启动的第一台服务器可以成为它的主ENRP服务器。
ENRP servers send ENRP Presence messages to all of their peers in order to show their liveness. These Presence messages also include a checksum computed over all PE identities for which the ENRP server is in the role of a Home ENRP server. Each ENRP server maintains an up-to-date list of its peers and can also compute the checksum expected from a certain peer, according to its local handlespace database. By comparing the expected sum and the sum reported by a peer (denoted as handlespace audit), an inconsistency can be detected. In such a case, the handlespace -- restricted to the PEs owned by that peer -- can be requested for synchronization, analogously to Section 3.2.
ENRP服务器向其所有对等方发送ENRP状态消息以显示其活跃性。这些状态消息还包括对ENRP服务器充当家庭ENRP服务器角色的所有PE标识计算的校验和。每个ENRP服务器维护其对等方的最新列表，并且还可以根据其本地handlespace数据库计算特定对等方的预期校验和。通过比较预期总和和对等方报告的总和（表示为handlespace audit），可以检测到不一致性。在这种情况下，可以请求handlespace（仅限于该对等方拥有的PEs）进行同步，类似于第3.2节。
If the unresponsiveness of an ENRP server is detected, the remaining ENRP servers negotiate which other server takes over the Home ENRP role for the PEs of the failed peer. After reaching a consensus on the takeover, the ENRP server taking over these PEs sends a notification to its peers (via ENRP) as well as to the PEs taken over (via ASAP).
如果检测到ENRP服务器无响应，其余的ENRP服务器将协商由哪个其他服务器接管故障对等方PE的主ENRP角色。在就接管达成共识后，接管这些PEs的ENRP服务器向其对等方（通过ENRP）以及接管的PEs（通过ASAP）发送通知。
RSerPool can be used in a 'standalone' manner, where the application uses RSerPool to determine the address of a primary server in the pool, and then interacts directly with that server without further use of RSerPool services. If the initial server fails, the application uses RSerPool again to find the next server in the pool.
RSerPool可以以“独立”的方式使用，其中应用程序使用RSerPool确定池中主服务器的地址，然后直接与该服务器交互，而无需进一步使用RSerPool服务。如果初始服务器出现故障，应用程序将再次使用RSerPool查找池中的下一台服务器。
For pool user ("client") applications, if an ASAP implementation is available on the client system, there are typically only three modifications required to the application source code:
对于池用户（“客户端”）应用程序，如果客户端系统上有ASAP实现，则通常只需要对应用程序源代码进行三次修改：
1. Instead of specifying the hostnames of primary, secondary, tertiary servers, etc., the application user specifies a pool handle.
1. 应用程序用户指定池句柄，而不是指定主服务器、辅助服务器、第三服务器等的主机名。
2. Instead of using a DNS-based service (e.g., the Unix library function getaddrinfo()) to translate from a hostname to an IP address, the application will invoke an RSerPool service primitive provisionally named GETPRIMARYSERVER that takes a pool handle as input, and returns the IP address of the primary server. The application then uses that IP address just as it would have used the IP address returned by the DNS in the previous scenario.
2. 应用程序不会使用基于DNS的服务（例如Unix库函数getaddrinfo（））将主机名转换为IP地址，而是调用一个临时命名为GETPRIMARYSERVER的RSerPool服务原语，该原语以池句柄作为输入，并返回主服务器的IP地址。然后，应用程序使用该IP地址，就像它在前面的场景中使用DNS返回的IP地址一样。
3. Without the use of additional RSerPool services, failure detection and failover procedures must be designed into each application. However, when failure is detected on the primary server, instead of invoking DNS translation again on the hostname of a secondary server, the application invokes a service primitive provisionally named GETNEXTSERVER, which performs two functions in a single operation.
3. 在不使用其他RSerPool服务的情况下，必须在每个应用程序中设计故障检测和故障切换过程。但是，当在主服务器上检测到故障时，应用程序不会再次在辅助服务器的主机名上调用DNS转换，而是调用临时命名为GETNEXTSERVER的服务原语，该原语在一个操作中执行两个功能。
1. First, it indicates to the RSerPool layer the failure of the server returned by a previous GETPRIMARYSERVER or GETNEXTSERVER call.
1. 首先，它向RSerPool层指示由上一个GETPRIMARYSERVER或GETNEXTSERVER调用返回的服务器故障。
2. Second, it provides the IP address of the next server that should be contacted, according to the best information available to the RSerPool layer at the present time (e.g., set of available pool elements, pool element policy in effect for the pool, etc.).
2. 其次，它根据当前RSerPool层可用的最佳信息（例如，可用池元素集、池的有效池元素策略等），提供应联系的下一台服务器的IP地址。
Note: at the time of this document, a full API for use with RSerPool protocols has not yet been defined.
注意：在编写本文档时，还没有定义用于RSerPool协议的完整API。
For pool element ("server") applications where an ASAP implementation is available, two changes are required to the application source code:
对于可用ASAP实现的池元素（“服务器”）应用程序，需要对应用程序源代码进行两项更改：
1. The server should invoke the REGISTER service primitive upon startup to add itself into the server pool using an appropriate pool handle. This also includes the address(es) protocol or mapping id, port (if required by the mapping), and pooling policy (or policies).
1. 服务器应该在启动时调用REGISTER service原语，使用适当的池句柄将自己添加到服务器池中。这还包括地址协议或映射id、端口（如果映射需要）和池策略。
2. The server should invoke the DEREGISTER service primitive to remove itself from the server pool when shutting down.
2. 关闭时，服务器应调用注销服务原语将自身从服务器池中删除。
When using these RSerPool services, RSerPool provides benefits that are limited (as compared to utilizing all services), but nevertheless quite useful as compared to not using RSerPool at all. First, the client user need only supply a single string, i.e., the pool handle, rather than a list of servers. Second, the decision as to which server is to be used can be determined dynamically by the server selection mechanism (i.e., a "pool policy" performed by ASAP; see ASAP [RFC5352]). Finally, when failures occur, these are reported to the pool via signaling present in ASAP [RFC5352] and ENRP [RFC5353]; other clients will eventually know (once this failure is confirmed by other elements of the RSerPool architecture) that this server has failed.
在使用这些RSepool服务时，RSepool提供的好处是有限的（与使用所有服务相比），但与根本不使用RSepool相比，它非常有用。首先，客户机用户只需要提供一个字符串，即池句柄，而不是服务器列表。其次，服务器选择机制（即ASAP执行的“池策略”；请参阅ASAP[RFC5352]）可以动态确定要使用哪台服务器。最后，当发生故障时，通过ASAP[RFC5352]和ENRP[RFC5353]中存在的信令向池报告这些故障；其他客户端最终会知道（一旦RSerPool体系结构的其他元素确认此故障），此服务器已发生故障。
When the full suite of RSerPool services is used, all communication between the pool user and the pool element is mediated by the RSerPool framework, including session establishment and teardown, and the sending and receiving of data. Accordingly, it is necessary to modify the application to use the service primitives (i.e., the API) provided by RSerPool, rather than the transport layer primitives provided by TCP, Stream Control Transmission Protocol (SCTP), or whatever transport protocol is being used.
使用全套RSerPool服务时，池用户和池元素之间的所有通信都由RSerPool框架进行调解，包括会话建立和拆卸以及数据的发送和接收。因此，有必要修改应用程序以使用由RSerPool提供的服务原语（即API），而不是由TCP、流控制传输协议（SCTP）或正在使用的任何传输协议提供的传输层原语。
As in the previous case, sessions (rather than connections or associations) are established, and the destination endpoint is specified as a pool handle rather than as a list of IP addresses with a port number. However, failover from one pool element to another is fully automatic, and can be transparent to the application (so long as the application has saved enough state in a state cookie):
与前一种情况一样，将建立会话（而不是连接或关联），并将目标端点指定为池句柄，而不是带有端口号的IP地址列表。但是，从一个池元素到另一个池元素的故障切换是完全自动的，并且对应用程序是透明的（只要应用程序在状态cookie中保存了足够的状态）：
The RSerPool framework control channel provides maintenance functions to keep pool element lists, policies, etc. current.
RSerPool框架控制通道提供维护功能，以保持池元素列表、策略等处于最新状态。
Since the application data (e.g., data channel) is managed by the RSerPool framework, unsent data (data not yet submitted by RSerPool to the underlying transport protocol) is automatically redirected to the newly selected pool element upon failover. If the underlying transport layer supports retrieval of unsent data (as in SCTP), retrieved unsent data can also be automatically re-sent to the newly selected pool element.
由于应用程序数据（例如，数据通道）由RSerPool框架管理，因此未发送的数据（RSerPool尚未提交到基础传输协议的数据）在故障切换时自动重定向到新选择的池元素。如果底层传输层支持检索未发送数据（如在SCTP中），则检索到的未发送数据也可以自动重新发送到新选择的池元素。
An application server (pool element) can provide a state cookie (described in Section 2.5.1) that is automatically passed on to another pool element (by the ASAP layer at the pool user) in the event of a failover. This state cookie can be used to assist the application at the new pool element in recreating whatever state is needed to continue a session or transaction that was
应用程序服务器（池元素）可以提供状态cookie（如第2.5.1节所述），在发生故障转移时，该状态cookie会自动传递给另一个池元素（由池用户的ASAP层）。此状态cookie可用于帮助位于新池元素的应用程序重新创建继续已创建的会话或事务所需的任何状态
interrupted by a failure in the communication between a pool user and the original pool element.
由于池用户和原始池元素之间的通信失败而中断。
The application client (pool user) can provide a callback function that is invoked on the pool user side in the case of a failover. This callback function can execute any application-specific failover code, such as generating a special message (or sequence of messages) that helps the new pool element construct any state needed to continue an in-process session.
应用程序客户端（池用户）可以提供一个回调函数，在发生故障转移时在池用户端调用该函数。此回调函数可以执行任何特定于应用程序的故障切换代码，例如生成特殊消息（或消息序列），以帮助新池元素构造继续进程内会话所需的任何状态。
Suppose in a particular peer-to-peer application, PU A is communicating with PE B, and it so happens that PU A is also a PE in pool X. PU A can pass a "business card" to PE B identifying it as a member of pool X. In the event of a failure at A, or a failure in the communication link between A and B, PE B can use the information in the business card to contact an equivalent PE to PU A from pool X.
假设在一个特定的点对点应用程序中，PU a正在与PE B通信，碰巧PU a也是池X中的PE。PU a可以将一张“名片”传递给PE B，将其标识为池X的成员。如果a发生故障，或者a和B之间的通信链路出现故障，PE B可以使用名片中的信息联系X池中与PU A相当的PE。
Additionally, if the application at PU A is aware of some particular PEs of pool X that would be preferred for B to contact in the event that A becomes unreachable from B, PU A can provide that list to the ASAP layer, and it will be included in A's business card (see Section 2.5.2).
此外，如果PU A的应用程序知道在A无法从B访问时B最好联系的池X的某些特定PE，则PU A可以将该列表提供给ASAP层，并将其包括在A的名片中（参见第2.5.2节）。
A reference implementation of RSerPool is available at [RSerPoolPage] and described in [Dre2006].
[RSerPool页面]提供了RSerPool的参考实现，并在[Dre2006]中进行了描述。
This document does not identify security requirements beyond those already documented in the ENRP and ASAP protocol specifications. A security threat analysis of RSerPool is provided in THREATS [RFC5355].
本文件未确定ENRP和ASAP协议规范中已记录的安全要求以外的安全要求。威胁[RFC5355]中提供了RSerPool的安全威胁分析。
This document does not require additional IANA actions beyond those already identified in the ENRP [RFC5353] and ASAP [RFC5352] protocol specifications.
除了ENRP[RFC5353]和ASAP[RFC5352]协议规范中已经确定的措施外，本文件不需要额外的IANA措施。
The authors wish to thank Maureen Stillman, Qiaobing Xie, Randall Stewart, Scott Bradner, and many others for their invaluable comments.
作者希望感谢莫林·斯蒂尔曼、谢乔冰、兰德尔·斯图尔特、斯科特·布拉德纳和其他许多人的宝贵评论。
[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月。
[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月。
[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
[RFC5353]Xie，Q.，Stewart，R.，Stillman，M.，Tuexen，M.，和A.Silverton，“端点Handlespace冗余协议（ENRP）”，RFC 53532008年9月。
[RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", RFC 5354, September 2008.
[RFC5354]Stewart，R.，Xie，Q.，Stillman，M.，和M.Tuexen，“聚合服务器访问协议（ASAP）和端点Handlespace冗余协议（ENRP）参数”，RFC 53542008年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月。
[RFC5356] Dreibholz, T. and M. Tuexen, "Reliable Server Pooling Policies", RFC 5356, September 2008.
[RFC5356]Dreibholz，T.和M.Tuexen，“可靠的服务器池策略”，RFC 5356，2008年9月。
[RSerPoolPage] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", <http://tdrwww.iem.uni-due.de/dreibholz/rserpool/>.
[RSepoolpage]Dreibholz，T.，“Thomas Dreibholz的RSepool页面”<http://tdrwww.iem.uni-due.de/dreibholz/rserpool/>.
[Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, Optimization and Extension of a Novel IETF Architecture", Ph.D. Thesis University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, March 2007, <http://duepublico.uni-duisburg-essen.de/ servlets/DerivateServlet/Derivate-16326/ Dre2006-final.pdf>.
[Dre2006]Dreibholz，T.，“可靠的服务器池——新型IETF体系结构的评估、优化和扩展”，博士。杜伊斯堡-埃森大学经济学院计算机科学与商业信息系统研究所，2007年3月，<http://duepublico.uni-duisburg-essen.de/ servlets/developerateservlet/developerate-16326/Dre2006 final.pdf>。
Authors' Addresses
作者地址
Peter Lei Cisco Systems, Inc. 955 Happfield Dr. Arlington Heights, IL 60004 US
Peter Lei思科系统公司，美国伊利诺伊州阿灵顿高地Happfield博士955号，邮编60004
Phone: +1 773 695-8201
EMail: peterlei@cisco.com
Phone: +1 773 695-8201
EMail: peterlei@cisco.com
Lyndon Ong Ciena Corporation PO Box 308 Cupertino, CA 95015 US
Lyndon Ong Ciena公司美国加利福尼亚州库比蒂诺308号邮政信箱95015
EMail: Lyong@Ciena.com
EMail: Lyong@Ciena.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
Thomas Dreibholz University of Duisburg-Essen, Institute for Experimental Mathematics Ellernstrasse 29 45326 Essen, Nordrhein-Westfalen Germany
托马斯，德雷布霍兹，杜伊斯堡-埃森大学实验数学研究所EELNSTRASE 29，45326，埃森
Phone: +49 201 183-7637
Fax: +49 201 183-7673
EMail: dreibh@iem.uni-due.de
URI: http://www.iem.uni-due.de/~dreibh/
Phone: +49 201 183-7637
Fax: +49 201 183-7673
EMail: dreibh@iem.uni-due.de
URI: http://www.iem.uni-due.de/~dreibh/
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.