Mon blog

Complétant la série des RFC sur la famille de protocoles Rserpool, famille dont le cahier des charges était le RFC 3237, ce document normalise le protocole ENRP (Endpoint Handlespace Redundancy Protocol) qui est le protocole utilisé entre les serveurs qui font la traduction des identifiants, les handles, en adresses IP.

Rappelons brièvement le fonctionnement de Rserpool (le RFC 5351 fournit une description plus détaillée) : un client, le PU (Pool User) veut accéder aux services fournis par un groupe (pool) de serveurs d'application, les PE (Pool Elements). Le client ne connait que l'identifiant du groupe, le PH (Pool Handle). Pour le traduire en adresses IP, le client utilise le protocole ASAP (RFC 5352) pour demander aux serveurs ENRP cette traduction. Les PE utilisent également ASAP pour s'enregistrer auprès des serveurs ENRP. Et comment les serveurs ENRP se synchronisent-ils ? Avec le protocole ENRP de notre RFC 5353. Grâce à lui, les serveurs ENRP forment un registre distribué et résistant aux pannes.

Notons qu'ENRP n'est conçu que pour fonctionner au sein d'un même domaine administratif, où toutes les machines sont configurées par la même équipe et peuvent donc, après authentification forte, se faire confiance (la section 6 détaille ces exigences de sécurité et impose TLS avec authentification réciproque). La conception d'un tel protocole pour l'Internet entier est encore un défi.

C'est la section 3 qui décrit le fonctionnement du protocole. Au démarrage, un serveur ENRP doit (section 3.2) générer son identifiant ENRP (un entier de 32 bits), trouver un mentor, le pair qui lui donnera les autres informations (la section 3.2.21 explique comment), obtenir la liste de ses pairs (et la garder à jour, cf. section 3.4) puis les tenir au courant des enregistrements/départs de PE (section 3.3) qu'il voit (chaque PE ne parle qu'à un serveur ENRP, son home server).

La section 3.5 détaille la procédure plus compliquée de remplacement (take over), qui permet à un pair de remplacer un pair en panne et de signaler aux PE (via le protocole ASAP) qu'ils doivent changer leur serveur ENRP.

La section 2 du RFC décrit les messages ENRP (s'appuyant sur la base fournie par le RFC 5354). Par exemple, ENRP_PRESENCE (section 2.1) permet à un serveur ENRP d'annoncer à un de ses pairs ENRP qu'il est toujours là. ENRP_HANDLE_TABLE_REQUEST (section 2.2) est utilisé lorsqu'un pair ENRP rejoint les autres et réclame une copie complète de la table des handles et des adresses IP associées. ENRP_HANDLE_UPDATE (section 2.4) servira ensuite aux mises à jour, au fur et à mesure que des PE s'enregistreront ou bien partiront.

ENRP_LIST_REQUEST (section 2.5) est également utilisé à l'initialisation d'un pair ENRP : il lui permet de demander une liste des pairs ENRP actuellement actifs.

Il existe au moins une mise en œuvre d'ENRP dans http://tdrwww.iem.uni-due.de/dreibholz/rserpool/.