Reliable Server Pooling

Reliable Server Pooling (RSerPool) is a computer protocol framework for management of and access to multiple, coordinated (pooled) servers. RSerPool is an IETF standard, which has been developed by the IETF RSerPool Working Group and documented in RFC 5351, RFC 5352, RFC 5353, RFC 5354, RFC 5355 and RFC 5356. Reliable Server Pooling (RSerPool) is a computer protocol framework for management of and access to multiple, coordinated (pooled) servers. RSerPool is an IETF standard, which has been developed by the IETF RSerPool Working Group and documented in RFC 5351, RFC 5352, RFC 5353, RFC 5354, RFC 5355 and RFC 5356. In the terminology of RSerPool a server is denoted as a Pool Element (PE). In its Pool, it is identified by its Pool Element Identifier (PE ID), a 32-bit number. The PE ID is randomly chosen upon a PE's registration to its pool. The set of all pools is denoted as the Handlespace. In older literature, it may be denoted as Namespace. This denomination has been dropped in order to avoid confusion with the Domain Name System (DNS). Each pool in a handlespace is identified by a unique Pool Handle (PH), which is represented by an arbitrary byte vector. Usually, this is an ASCII or Unicode name of the pool, e.g. 'DownloadPool' or 'WebServerPool'. Each handlespace has a certain scope (e.g. an organization or company), denoted as Operation Scope. It is explicitly not a goal of RSerPool to manage the global Internet's pools within a single handlespace. Due to the localisation of Operation Scopes, it is possible to keep the handlespace 'flat'. That is, PHs do not have any hierarchy in contrast to the Domain Name System with its top-level and sub-domains. This constraint results in a significant simplification of handlespace management. Within an operation scope, the handlespace is managed by redundant Pool Registrars (PR), also denoted as ENRP servers or Name Servers (NS). PRs have to be redundant in order to avoid a PR to become a Single Point of Failure (SPoF). Each PR of an operation scope is identified by its Registrar ID (PR ID), which is a 32-bit random number. It is not necessary to ensure uniqueness of PR IDs. A PR contains a complete copy of the operation scope's handlespace. PRs of an operation scope synchronize their view of the handlespace using the Endpoint Handlespace Redundancy Protocol (ENRP). Older versions of this protocol use the term Endpoint Namespace Redundancy Protocol; this naming has been replaced to avoid confusion with DNS, but the abbreviation has been kept. Due to handlespace synchronization by ENRP, PRs of an operation scope are functionally equal. That is, if any of the PRs fails, each other PR is able to seamlessly replace it. Using the Aggregate Server Access Protocol (ASAP), a PE can add itself to a pool or remove it from by requesting a registration or deregistration from an arbitrary PR of the operation scope. In case of successful registration, the PR chosen for registration becomes the PE's Home-PR (PR-H). A PR-H not only informs the other PRs of the operation scope about the registration or deregistration of its PEs, it also monitors the availability of its PEs by ASAP Keep-Alive messages. A keep-alive message by a PR-H has to be acknowledged by the PE within a certain time interval. If the PE fails to answer within a certain timeout, it is assumed to be dead and immediately removed from the handlespace. Furthermore, a PE is expected to re-register regularly. At a re-registration, it is also possible for the PE to change its list of transport addresses or its policy information. To use the service of a pool, a client — called Pool User (PU) in RSerPool terminology — first has to request the resolution of the pool's PH to a list of PE identities at an arbitrary PR of the operation scope. This selection procedure is denoted as Handle Resolution. For the case that the requested pool is existing, the PR will select a list of PE identities according to the pool's Pool Member Selection Policy, also simply denoted as Pool Policy.