Network Working Group                                          M. Tuexen
Request for Comments: 3237                                    Siemens AG
Category: Informational                                           Q. Xie
                                                                Motorola
                                                              R. Stewart
                                                                M. Shore
                                                                   Cisco
                                                                  L. Ong
                                                                   Ciena
                                                             J. Loughney
                                                             M. Stillman
                                                                   Nokia
                                                            January 2002
        
Network Working Group                                          M. Tuexen
Request for Comments: 3237                                    Siemens AG
Category: Informational                                           Q. Xie
                                                                Motorola
                                                              R. Stewart
                                                                M. Shore
                                                                   Cisco
                                                                  L. Ong
                                                                   Ciena
                                                             J. Loughney
                                                             M. Stillman
                                                                   Nokia
                                                            January 2002
        

Requirements for Reliable Server Pooling

对可靠服务器池的要求

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.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2002). All Rights Reserved.

版权所有(C)互联网协会(2002年)。版权所有。

Abstract

摘要

This document defines a basic set of requirements for reliable server pooling.

本文档定义了可靠服务器池的一组基本要求。

The goal of Reliable Server Pooling (RSerPool) is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool.

可靠服务器池(RSerPool)的目标是开发一种体系结构和协议,用于管理和操作支持高度可靠应用程序的服务器池,以及用于客户端访问服务器池的机制。

1. Introduction
1. 介绍
1.1. Overview
1.1. 概述

The Internet is always on. Many users expect services to be always available; many businesses depend upon connectivity 24 hours a day, 7 days a week, 365 days a year. In order to fulfill this level of performance, many proprietary solutions and operating system dependent solutions have been developed to provide highly reliable and highly available servers.

互联网总是开着的。许多用户希望服务始终可用;许多企业依赖于一年365天、一周7天、每天24小时的连通性。为了实现这一性能水平,开发了许多专有解决方案和依赖于操作系统的解决方案,以提供高可靠性和高可用性的服务器。

This document defines requirements for an architecture and protocols enabling pooling of servers to support high reliability and availability for applications.

本文档定义了支持服务器池的体系结构和协议的要求,以支持应用程序的高可靠性和可用性。

The range of applications that can benefit from reliable server pooling includes both mobile and real-time applications. Reliable server pooling mechanisms will be designed to support functionality for flexible pooling such as registration and deregistration, and load balancing of traffic across the server pool. Mechanisms will need to balance the needs of scalability, overhead traffic and response time to changes in pool status, as discussed below.

可从可靠的服务器池中获益的应用程序范围包括移动和实时应用程序。可靠的服务器池机制将设计为支持灵活池功能,如注册和注销,以及服务器池流量的负载平衡。机制需要平衡可伸缩性、开销流量和池状态变化的响应时间,如下所述。

1.2. Terminology
1.2. 术语

This document uses the following terms:

本文件使用以下术语:

Operation 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 (or pool name): A logical pointer to a pool. Each server pool will be identifiable in the operation scope of the system by a unique pool handle or "name".

池句柄(或池名称):指向池的逻辑指针。每个服务器池将在系统的操作范围内通过唯一的池句柄或“名称”进行标识。

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 name of the pool and one or more destination transport addresses for the pool element.

池元素句柄(或端点句柄):指向池中特定池元素的逻辑指针,由池的名称和池元素的一个或多个目标传输地址组成。

Name space: A cohesive structure of pool names and relations that may be queried by an internal or external agent.

名称空间:池名称和关系的内聚结构,可由内部或外部代理查询。

Name server: Entity which is responsible for managing and maintaining the name space within the RSerPool operation scope.

名称服务器:负责管理和维护RSerPool操作范围内的名称空间的实体。

RSerPool: The architecture and protocols for reliable server pooling.

RSerPool:用于可靠服务器池的体系结构和协议。

1.3. Abbreviations
1.3. 缩写

PE: Pool element

PE:池元素

PU: Pool user

PU:池用户

SCTP: Stream Control Transmission Protocol

SCTP:流控制传输协议

TCP: Transmission Control Protocol

传输控制协议

2. Requirements
2. 要求
2.1. Robustness
2.1. 健壮性

The solution must allow itself to be implemented and deployed in such a way that there is no single point of failure in the system.

解决方案必须允许以这样的方式实现和部署,即系统中没有单点故障。

2.2. Failover Support
2.2. 故障转移支持

The RSerPool architecture must be able to detect failure of pool elements and name servers supporting the pool, and support failover to available alternate resources.

RSerPool体系结构必须能够检测支持池的池元素和名称服务器的故障,并支持到可用备用资源的故障切换。

2.3. Communication Model
2.3. 传播模式

The general architecture should support flexibility of the communication model between pool users and pool elements, especially allowing for a peer-to-peer relationship to support some applications.

通用体系结构应支持池用户和池元素之间通信模型的灵活性,特别是允许对等关系来支持某些应用程序。

2.4. Processing Power
2.4. 处理能力

It should be possible to use the protocol stack in small devices, like handheld wireless devices. The solution must scale to devices with a differing range of processing power.

应该可以在小型设备(如手持无线设备)中使用协议栈。解决方案必须扩展到具有不同处理能力范围的设备。

2.5. Transport Protocol
2.5. 传输协议

The protocols used for the pool handling should not cause network congestion. This means that it should not generate heavy traffic, even in case of failures, and has to use flow control and congestion avoidance algorithms which are interoperable with currently deployed techniques, especially the flow control of TCP [RFC793] and SCTP [RFC2960] and must be compliant with [RFC2914].

用于池处理的协议不应导致网络拥塞。这意味着即使在出现故障的情况下,它也不应产生大量流量,并且必须使用与当前部署的技术可互操作的流量控制和拥塞避免算法,特别是TCP[RFC793]和SCTP[RFC2960]的流量控制,并且必须符合[RFC2914]。

The architecture should not rely on multicast capabilities of the underlying layer. Nevertheless, it can make use of it if multicast capabilities are available.

该体系结构不应依赖于底层的多播功能。然而,如果多播功能可用,它可以利用它。

Network failures have to be handled and concealed from the application layer as much as possible by the transport protocol. This means that the underlying transport protocol must provide a strong network failure handling capability on top of an acknowledged error-free non-duplicated data delivery service. The failure of a network element must be handled by the transport protocol in such a way that the timing requirements are still fulfilled.

必须通过传输协议处理网络故障,并尽可能对应用层进行隐藏。这意味着基础传输协议必须在已确认的无错误非重复数据交付服务之上提供强大的网络故障处理能力。网元故障必须通过传输协议处理,以确保仍然满足定时要求。

2.6. Support of RSerPool Unaware Clients
2.6. 支持RSerPool客户端

The architecture should allow for ease of interaction between pools and non-RSerPool-aware clients. However, it is assumed that only RSerPool-aware participants will receive maximum timing and notification benefits the architecture offers.

该体系结构应允许在池和不支持RSerPool的客户端之间轻松交互。但是,假定只有支持RSerPool的参与者才能获得体系结构提供的最大时间和通知好处。

2.7. Registering and Deregistering
2.7. 登记和注销

Another important requirement is that servers should be able to register to (become PEs) and deregister from a server pool transparently without an interruption in service. This means that after a PE has deregistered, it will continue to serve PUs which started their connection before the deregistration of the PE. New connections will be directed towards an alternative PE.

另一个重要的要求是,服务器应该能够在不中断服务的情况下透明地注册(成为PEs)并从服务器池中注销。这意味着在PE注销后,它将继续为在PE注销前已开始连接的PUs提供服务。新连接将指向替代PE。

Servers should be able to register in multiple server pools which may belong to different namespaces.

服务器应该能够在可能属于不同名称空间的多个服务器池中注册。

2.8. Naming
2.8. 命名

Server pools are identified by pool handles. These pool handles are only valid inside the operation scope. Interoperability between different namespaces has to be provided by other mechanisms.

服务器池由池句柄标识。这些池句柄仅在操作范围内有效。不同名称空间之间的互操作性必须由其他机制提供。

2.9. Name Resolution
2.9. 名称解析

The name resolution should not result in a pool element which is not operational. This might be important for fulfilling the timing requirements described below.

名称解析不应导致池元素不可操作。这对于满足下面描述的定时要求可能很重要。

2.10. Server Selection
2.10. 服务器选择

The RSerPool mechanisms must be able to support different server selection mechanisms. These are called server pool policies.

RSerPool机制必须能够支持不同的服务器选择机制。这些称为服务器池策略。

Examples of server pool policies are:

服务器池策略的示例包括:

- Round Robin

- 循环赛

- Least used

- 最少使用

- Most used

- 最常用

The set of supported policies must be extensible in the sense that new policies can be added as required. Non-stochastic and stochastic policies can be supported.

受支持的策略集必须是可扩展的,因为可以根据需要添加新策略。可以支持非随机和随机策略。

There must be a way for the client to provide operational status feedback to the name server about the pool elements.

客户端必须有一种方法向名称服务器提供有关池元素的操作状态反馈。

The name server protocols must be extensible to allow more refined server selection mechanisms to be implemented as they are developed in the future.

名称服务器协议必须是可扩展的,以便在将来开发时实现更完善的服务器选择机制。

For some applications it is important that a client repeatedly connects to the same server in a pool if it is possible, i.e., if that server is still alive. This feature should be supported through the use of pool element handles.

对于某些应用程序,如果可能的话,客户机必须重复连接到池中的同一服务器,也就是说,如果该服务器仍然处于活动状态,这一点很重要。应该通过使用池元素句柄来支持此功能。

2.11. Timing Requirements and Scaling
2.11. 时间要求和比例

Handling of name resolution must be fast to support real-time applications. Moreover, the name space should reflect pool membership changes to the client application as rapidly as possible, i.e., not waiting until the client application next reconnects.

名称解析的处理必须快速,以支持实时应用程序。此外,名称空间应尽可能快地将池成员身份更改反映到客户端应用程序,即不要等到客户端应用程序下次重新连接。

The architecture should support control of timing parameters based on specific needs, e.g., of an application or implementation.

架构应支持基于特定需求(例如,应用程序或实现)的定时参数控制。

In order to support more rapid and accurate response, the requirements on scalability of the mechanism are limited to server pools consisting of a suitably large but not Internet-wide number of elements, as necessary to support bounded delay in handling real-time name resolution.

为了支持更快速、更准确的响应,对机制可伸缩性的要求仅限于服务器池,该服务器池由适当大但不是互联网范围的元素组成,以支持处理实时名称解析时的有限延迟。

Also, there is no requirement to support hierarchical organization of name servers for scalability. Instead, it is envisioned that the set of name servers supporting a particular pool is organized as a flat space of equivalent servers. Accordingly, the impact of relatively frequent updates to ensure accurate reflection of the status of pool elements is limited to the set of name servers supporting a specific pool.

此外,不需要为可伸缩性支持名称服务器的分层组织。相反,设想将支持特定池的名称服务器集组织为等效服务器的平面空间。因此,确保准确反映池元素状态的相对频繁更新的影响仅限于支持特定池的名称服务器集。

2.12. Scalability
2.12. 可伸缩性

The RSerPool architecture should not require a limitation on the number of server pools or on the number of pool users, although the size of an individual pool may be limited by timing requirements as defined above.

RSerPool体系结构不应要求限制服务器池的数量或池用户的数量,尽管单个池的大小可能会受到上述时间要求的限制。

2.13. Security Requirements
2.13. 安全要求
2.13.1. General
2.13.1. 全体的

- The scaling characteristics of the security architecture should be compatible with those given previously.

- 安全体系结构的扩展特性应与前面给出的特性兼容。

- The security architecture should support hosts having a wide range of processing powers.

- 安全体系结构应支持具有广泛处理能力的主机。

2.13.2. Name Space Services
2.13.2. 名称空间服务

- It must not be possible for an attacker to falsely register as a pool element with the name server either by masquerading as another pool element or by registering in violation of local authorization policy.

- 攻击者不得通过伪装为另一个池元素或违反本地授权策略注册而向名称服务器错误注册为池元素。

- It must not be possible for an attacker to deregister a server which has successfully registered with the name server.

- 攻击者不能取消已成功注册到名称服务器的服务器的注册。

- It must not be possible for an attacker to spoof the response to a query to the name server

- 攻击者不得伪造对名称服务器查询的响应

- It must be possible to protect the privacy of queries to the name server and responses to those queries from the name server.

- 必须能够保护对名称服务器的查询以及对来自名称服务器的查询的响应的隐私。

- Communication among name servers must be afforded the same protections as communication between clients and name servers.

- 必须为名称服务器之间的通信提供与客户端和名称服务器之间的通信相同的保护。

2.13.3. Security State
2.13.3. 安全状态

The security context of an application is a subset of the overall context, and context or state sharing is explicitly out-of-scope for RSerPool. Because RSerPool does introduce new security vulnerabilities to existing applications application designers employing RSerPool should be aware of problems inherent in failing over secured connections. Security services necessarily retain some state and this state may have to be moved or re-established. Examples of this state include authentication or retained ciphertext

应用程序的安全上下文是整个上下文的子集,而上下文或状态共享显然不在RSerPool的范围之内。由于RSerPool确实给现有应用程序引入了新的安全漏洞,因此使用RSerPool的应用程序设计师应该了解安全连接故障转移过程中固有的问题。安全服务必须保留某些状态,并且可能必须移动或重新建立该状态。此状态的示例包括身份验证或保留密文

for ciphers operating in cipher block chaining (CBC) or cipher feedback (CFB) mode. These problems must be addressed by the application or by future work on RSerPool.

用于在密码块链接(CBC)或密码反馈(CFB)模式下运行的密码。这些问题必须通过应用程序或今后的RSerPool工作来解决。

3. Security Considerations
3. 安全考虑

Security issues are discussed in section 2.13.

第2.13节讨论了安全问题。

4. Acknowledgements
4. 致谢

The authors would like to thank Bernard Aboba, Matt Holdrege, Eliot Lear, Christopher Ross, Werner Vogels and many others for their invaluable comments and suggestions.

作者要感谢伯纳德·阿博巴、马特·霍尔德雷格、艾略特·李尔、克里斯托弗·罗斯、沃纳·沃格尔和许多其他人的宝贵意见和建议。

5. References
5. 工具书类

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC793]Postel,J.,“传输控制协议”,标准7,RFC 793,1981年9月。

[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.

[RFC959]Postel,J.和J.Reynolds,“文件传输协议(FTP)”,标准9,RFC959,1985年10月。

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026]Bradner,S.,“互联网标准过程——第3版”,BCP 9,RFC 2026,1996年10月。

[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.

[RFC2608]Guttman,E.,Perkins,C.,Veizades,J.和M.Day,“服务位置协议,版本2”,RFC 26081999年6月。

[RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.

[RFC2719]Ong,L.,Rytina,I.,Garcia,M.,Schwarzbauer,H.,Coene,L.,Lin,H.,Juhasz,I.,Holdrege,M.和C.Sharp,“信号传输的框架架构”,RFC 2719,1999年10月。

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

[RFC2914]Floyd,S.,“拥塞控制原则”,BCP 41,RFC 2914,2000年9月。

[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, November 2000.

[RFC2960]Stewart,R.,Xie,Q.,Morneault,K.,Sharp,C.,Schwarzbauer,H.,Taylor,T.,Rytina,I.,Kalla,M.,Zhang,L.和V.Paxson,“流控制传输协议”,RFC 29602000年11月。

6. Authors' Addresses
6. 作者地址

Michael Tuexen Siemens AG ICN WN CS SE 51 D-81359 Munich Germany

Michael Tuexen西门子公司ICN WN CS SE 51 D-81359德国慕尼黑

   Phone:   +49 89 722 47210
   EMail: Michael.Tuexen@icn.siemens.de
        
   Phone:   +49 89 722 47210
   EMail: Michael.Tuexen@icn.siemens.de
        

Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, Il 60004 USA

谢乔平摩托罗拉公司,美国伊利诺伊州阿灵顿高地2309号舒尔大道西1501号,邮编60004

   Phone: +1 847 632 3028
   EMail: qxie1@email.mot.com
        
   Phone: +1 847 632 3028
   EMail: qxie1@email.mot.com
        

Randall Stewart Cisco Systems, Inc. 24 Burning Bush Trail Crystal Lake, Il 60012 USA

Randall Stewart Cisco Systems,Inc.美国伊利诺伊州水晶湖24号Burning Bush Trail Crystal Lake,邮编:60012

   Phone: +1 815 477 2127
   EMail: rrs@cisco.com
        
   Phone: +1 815 477 2127
   EMail: rrs@cisco.com
        

Melinda Shore Cisco Systems, Inc. 809 Hayts Rd Ithaca, NY 14850 USA

美国纽约州伊萨卡海茨路809号梅林达肖尔思科系统有限公司,邮编14850

   Phone: +1 607 272 7512
   EMail: mshore@cisco.com
        
   Phone: +1 607 272 7512
   EMail: mshore@cisco.com
        

Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA

美国加利福尼亚州库珀蒂诺市林登·翁·西纳10480里奇维尤法院,邮编95014

   Phone: +1 408 366 3358
   EMail: lyong@ciena.com
        
   Phone: +1 408 366 3358
   EMail: lyong@ciena.com
        

John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland

John Loughney诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰

   Phone: +358 50 483 6242
   EMail: john.loughney@nokia.com
        
   Phone: +358 50 483 6242
   EMail: john.loughney@nokia.com
        

Maureen Stillman Nokia 127 W. State Street Ithaca, NY 14850 USA

美国纽约州伊萨卡州州立街西127号莫林·斯蒂尔曼诺基亚14850

   Phone: +1 607 273 0724 62
   EMail: maureen.stillman@nokia.com
        
   Phone: +1 607 273 0724 62
   EMail: maureen.stillman@nokia.com
        
7. Full Copyright Statement
7. 完整版权声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

版权所有(C)互联网协会(2002年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。