]> Ideas for a Next Generation of the Reliable Server Pooling Framework Simula Metropolitan Centre for Digital Engineering
Stensberggata 27 0170 Oslo Norway dreibh@simula.no https://www.simula.no/people/dreibh
Internet-Draft This document collects some idea for a next generation of the Reliable Server Pooling framework.
Introduction
Abbreviations
  • ASAP: Aggregate Server Access Protocol
  • ENRP: Endpoint Handlespace Redundancy Protocol
  • ID: Identifier
  • MPTCP: Multi-Path Transmission Control Protocol
  • PE: Pool Element
  • PR: Pool Registrar
  • PU: Pool User
  • RSerPool: Reliable Server Pooling
  • SCTP: Stream Control Transmission Protocol
  • TCP: Transmission Control Protocol
  • VNFPOOL: Virtual Network Function Resource Pooling
Reliable Server Pooling Reliable Server Pooling (RSerPool) has been defined as RFCs in , , , , , , , . There is also a detailed introduction provided by as well as lots of further information material on . RSerPool is therefore not introduced in more detail here.
Scope The scope of this document is to collect some ideas of what to update/change for a next generation of the RSerPool framework. It is a result of lessons learned with more than one decade of RSerPool deployment (see also , , ) as well as ongoing discussions on applying RSerPool for Virtual Network Function Resource Pooling (VNFPOOL; as introduced in more detail in ).
What to Change in the Next Generation of RSerPool?
  • ENRP servers denote the management systems in the context of RSerPool. The term "server" is misleading, since ENRP servers are actually ENRP peers. Literature on RSerPool -- for example -- therefore uses the more accurate term "Pool Registrar" (PR). A future revision of RSerPool should also use this term. (The RSerPool documents did not use "registrar" to avoid confusion with SIP registrars.)
  • Pool Element Identifiers (PE ID) and Pool Registrar Identifiers (PR ID) are 32-bit random numbers used for the identification of PEs and PRs. Since 64-bit CPUs are standard since quite a long time, these IDs should be extended to 64 bits.
  • ENRP uses the Internet-16 checksum defined in to detect handlespace inconsistencies. It is trivially possible to extend the underlying algorithm to 32 bits, and the computation is more efficient on today's CPUs. The checksum algorithm should therefore be changed. (The Internet-16 checksum was finally chosen in 2005 after long decisions to avoid any possible patent issues. The trivial extension of Internet-16 to Internet-32 is probably not an issue any more?)
  • PR failures lead to possible concentration of all PUs and PEs at a single PR. To achieve a better load balancing, the solution ENRP Takeover Suggestion -- as defined in -- should be included in ENRP.
  • For a Handle Resolution, a PR has to decide on how many PEs to select. Selecting too many ones causes additional overhead (which might be unnecessary), selecting too few ones may cause problems for the applications. The extension Handle Resolution Option -- defined in -- provides a possibility for the PU to specify the amount of PEs to be selected. This possibility should be integrated into ASAP.
  • RSerPool defines SCTP (defined in ) as transport protocol for RSerPool. TCP and particularly Multi-Path TCP (MPTCP; see ) should be possible further transport protocols for all RSerPool traffic. SCTP should still be the recommended choice, but allowing TCP/MPTCP could make the deployment much easier. (SCTP is superior, but it lacks of support in operating systems and support by underlying network infrastructure, like firewalls and middleboxes.)
Security Considerations Security considerations for RSerPool can be found in .
IANA Considerations This document introduces no additional considerations for IANA.
Reference Implementation The RSerPool reference implementation RSPLIB, including example applications, can be found at . It supports the functionalities defined by , , , and as well as the options , and . An introduction to this implementation is provided in .
Testbed Platform NorNet is a large-scale and realistic Internet testbed platform with support for Reliable Server Pooling as well as the underlying transport protocols SCTP and MPTCP. A description of and introduction to NorNet is provided in , , . Further information can be found on the project website .
Acknowledgments The author would like to thank Randall R. Stewart, Michael Tuexen, Ning Zong for their discussions and support.
References Normative References Requirements for Reliable Server Pooling This document defines a basic set of requirements for reliable server pooling. This memo provides information for the Internet community. An Overview of Reliable Server Pooling Protocols 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. This memo provides information for the Internet community. Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol. The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. This memo defines an Experimental Protocol for the Internet community. Endpoint Handlespace Redundancy Protocol (ENRP) 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. This memo defines an Experimental Protocol for the Internet community. Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. This memo defines an Experimental Protocol for the Internet community. Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats. This memo provides information for the Internet community. Reliable Server Pooling Policies This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. This memo defines an Experimental Protocol for the Internet community. Reliable Server Pooling MIB Module Definition Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols: ASAP (Aggregate Server Access Protocol) and ENRP (Endpoint Handlespace Redundancy Protocol). This document defines an \%SMIv2- compliant (Structure of Management Information Version 2) Management Information Base (MIB) module providing access to managed objects in an RSerPool implementation. This memo defines an Experimental Protocol for the Internet community. Computing the Internet checksum This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques. Stream Control Transmission Protocol This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK] TCP Extensions for Multipath Operation with Multiple Addresses TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community. Handle Resolution Option for ASAP SimulaMet This document describes the Handle Resolution option for the ASAP protocol. Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling SimulaMet Hainan University This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. Takeover Suggestion Flag for the ENRP Handle Update Message SimulaMet Hainan University This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. Virtualized Network Function (VNF) Pool Problem Statement Network functions are traditionally implemented on specialized hardware rather than on general purpose servers, but there is a clear trend to implement a number of network functions, such as firewall or load balancer, as software on virtualized computing platforms. These virtualized functions are called Virtualized Network Functions (VNFs), which can be used to build network services. The use of VNFs to build network services introduces additional challenges on reliability, such as additional points of failure and the need to coordinate various VNFs. This document introduces a general idea of VNF Pool to support reliable function provision by the VNFs. We then highlight the reliability challenges and issues when using the VNFs to build services. Related IETF works are also briefly described. Informative References Reliable Server Pooling – Evaluation, Optimization and Extension of a Novel IETF Architecture A Powerful Tool-Chain for Setup, Distributed Processing, Analysis and Debugging of OMNeT++ Simulations Evaluation and Optimisation of Multi-Path Transport using the Stream Control Transmission Protocol Design and Implementation of the NorNet Core Research Testbed for Multi-Homed Systems The NorNet Core Testbed – Introduction and Status The NorNet Core Testbed – An Experiment Tutorial Thomas Dreibholz's RSerPool Page NorNet – A Real-World, Large-Scale Multi-Homing Testbed