Résumé

  • Demand RIP remplaçait les annonces WAN périodiques sur X.25 et RNIS par des échanges déclenchés, acquittés et retransmis. Les routes apprises de cette manière devenaient normalement permanentes et ne vieillissaient pas sous le seul effet du silence.
  • Un échec réel d’établissement permettait au gestionnaire de circuit de signaler le prochain saut comme indisponible ; les routes entraient alors en vieillissement, temporisation de retenue puis suppression. L’acquittement prouvait la réception d’un message, non la vérité du chemin ni le succès du service.
  • RFC 1581 ne recensait qu’une mise en œuvre achevée, testée contre elle-même sur deux WAN. Les critères de RFC 1264 distinguaient cette expérience d’une interopérabilité entre réalisations indépendantes.

Le battement périodique occupait le circuit qu’il surveillait

RFC 1582, daté de février 1994 par sa notice officielle, partait d’un fonctionnement simple : établir un circuit virtuel lorsque des données se présentent, puis le libérer lorsque l’activité cesse. Les communications utiles pouvaient être brèves et rares.

RIP continuait pourtant à répéter sa table. Sur un LAN, une diffusion touche le médium partagé. Sur un WAN sans diffusion native, elle se transforme en messages séparés pour chaque voisin. Le RFC évaluait une ronde à N × (N - 1) mises à jour réparties sur N × (N - 1) / 2 connexions. Le nombre de canaux pouvait en outre être inférieur au nombre de voisins ; l’accès de base RNIS cité n’en ouvrait que deux simultanément.

Espacer les annonces réduisait la dépense mais ralentissait la réaction. Garder le rythme empêchait les appels de retomber. Demand RIP n’a pas simplement choisi une durée moyenne : il a lié l’émission à un événement — une demande, une modification de base ou le retour d’un circuit annoncé par son gestionnaire.

L’absence de parole n’effaçait plus l’état accepté

RFC 1581 est l’analyse Informational associée, telle que l’indique sa notice RFC Editor. Elle résumait le marché : aucune diffusion périodique sur le WAN ; une mise à jour déclenchée retransmise jusqu’à acquittement ; les informations reçues ne s’éteignant pas en exploitation normale.

RFC 1582 séparait alors deux sortes de mémoire. Une route reçue par annonces LAN restait temporaire et expirait sans rafraîchissement. Celle issue d’une réponse déclenchée sur le WAN était normalement permanente.

Ce mot ne signifiait pas qu’elle était éternellement vraie. Le routeur maintenait la dernière affirmation admise jusqu’à l’arrivée d’un fait contraire prévu par les règles : route explicitement inaccessible, absence dans une réponse complète, interface tombée, échanges trop longtemps non acquittés ou appel effectivement tenté mais impossible à établir.

« Aucun message récent » n’était donc plus synonyme de panne. Le silence était voulu. Mais il ne constituait pas non plus une nouvelle mesure positive. Il prolongeait une décision antérieure. Le protocole transférait l’initiative de la réfutation du minuteur périodique vers des événements nommés.

Le gestionnaire de circuit pouvait faire vieillir la route

Dans l’empilement de RFC 1582, le gestionnaire se trouvait sous IP, IPX et leurs tâches de routage. Il associait l’adresse logique du prochain saut à l’adresse physique nécessaire pour appeler sur X.25 ou RNIS. À l’arrivée d’un datagramme sans circuit, il essayait d’en ouvrir un ; après une période inactive, il pouvait le fermer.

Si l’appel échouait pendant le service ordinaire, le gestionnaire transmettait circuit down. Les routes permanentes de ce prochain saut devenaient temporaires, vieillissaient, étaient annoncées inaccessibles pendant le hold-down puis pouvaient être supprimées. Un rétablissement précoce permettait de les rendre permanentes ; après expiration, il fallait demander une base complète.

circuit up restait une affirmation étroite. Le gestionnaire avait repris contact selon sa procédure, sans pour autant confirmer chaque route ancienne. Les applications de routage devaient donc réamorcer leurs bases. Réussite de l’appel, existence d’une route, sélection dans le plan de transfert, passage d’un paquet et résultat d’application demeuraient cinq constats distincts.

La méthode de récupération du gestionnaire restait hors périmètre. Une pénurie de canaux, une mauvaise table d’adresses, un refus distant ou une rupture physique pouvaient produire le même signal interne. Celui-ci pouvait justifier une action prudente sans constituer un diagnostic complet.

Un ACK fermait la question du transport, pas celle du chemin

Sans prochaine ronde périodique, une modification perdue risquait de rester perdue. L’absence de circuit libre, la saturation de file, la préemption d’un appel ou une trame corrompue pouvaient supprimer un datagramme de routage. RFC 1582 a donc défini requête, réponse, acquittement et retransmission.

Une grande réponse était fragmentée. Chaque fragment recevait son propre acquittement et le destinataire attendait l’ensemble avant d’appliquer la modification. À l’expiration du délai de réassemblage, il jetait la série incomplète et redemandait un état complet. Une nouvelle séquence remplaçait les fragments inachevés de l’ancienne.

Ces règles fabriquaient de bons reçus, à condition de ne pas les agrandir. L’ACK attestait qu’une réponse ou un fragment avait été reçu. Le réassemblage attestait la possession d’un ensemble applicable. La séquence distinguait deux générations. Aucun ne démontrait la véracité de la route, son installation effective, le passage d’un paquet utilisateur ou la disponibilité d’un service.

La liste des voisins formait elle aussi une frontière limitée. Elle contrôlait les destinations d’envoi et les sources acceptées ; un message extérieur à la liste devait être rejeté. RIP-2 pouvait ajouter l’authentification. Une identité autorisée à émettre ne transformait cependant pas chaque métrique en observation du monde.

La facture de ligne devint une dette de mémoire

Une route permanente ne peut compter sur l’oubli. RFC 1582 demandait de conserver toutes les solutions de rechange, ou d’en garder un sous-ensemble tout en mémorisant que d’autres avaient été abandonnées afin de les réclamer avant la perte des dernières options. Le rafraîchissement périodique reconstruisait autrefois cet inventaire ; désormais, la mémoire ou une requête explicite devait le faire.

Moins d’appels impliquait donc davantage d’état durable. Cet état exigeait retrait exact, retransmission fiable, réassemblage complet, coordination avec la couche de circuit et procédure de reprise. Le coût visible baissait et l’obligation de cohérence augmentait.

RFC 1582 examinait aussi des durées de vie logicielles différentes. Dans le produit décrit, gestionnaire et routage étaient presque un même programme. Sur Unix, le premier pouvait résider dans le noyau et le second dans un processus ; ailleurs, une carte séparée pouvait porter le gestionnaire. Dès qu’ils pouvaient mourir séparément, un keepalive et une resynchronisation étaient obligatoires. La survie de l’un ne prouvait pas que l’autre détenait le même état.

Une mise en œuvre n’en valait pas deux

RFC 1581 indiquait qu’une seule réalisation achevée était alors connue. Celle de Spider Systems gérait IP RIP-1, IPX RIP et IPX SAP, mais pas encore RIP-2. Elle avait été testée contre elle-même sur X.25 et RNIS, et avait côtoyé des logiciels ordinaires sur Ethernet. Deux travaux réservés à Novell restaient en développement.

C’était une preuve de code, avec deux contextes WAN. Ce n’était pas la preuve qu’un second auteur de logiciel comprenait les mêmes fragments, temporisations, redémarrages et signaux de circuit.

RFC 1264, dans sa notice officielle, rappelait que les protocoles de routage sont des algorithmes distribués en temps réel. La réussite d’un programme dans un environnement ne garantit pas plusieurs fournisseurs ailleurs. Réalisations indépendantes, essais de toutes les fonctions et démonstration des mécanismes de sécurité formaient des étapes distinctes.

Le bon récit ne transforme pas « exécuté » en « interopérable », mais ne réduit pas non plus l’auto-test au néant. La précision du périmètre fait la valeur du reçu.

L’évolution de 1997 a gardé la même présomption

RFC 2091, publié en janvier 1997 selon sa notice, annonçait des gains face à RFC 1582. Après l’échange complet, il ne transmettait que les changements, réduisait trafic et mémoire, et supprimait la limite de 255 fragments en abandonnant cette fragmentation.

La structure de responsabilité subsistait. Les routes déclenchées restaient normalement permanentes. Le gestionnaire annonçait toujours down et up. Requêtes et réponses exigeaient acquittement et retransmission. Une absence prolongée d’ACK pouvait rendre le prochain saut inaccessible. Une reprise ou un redémarrage appelait toujours un flush et une reconstruction complète.

Un document postérieur ne prouve pas son déploiement. Il montre que la mécanique a changé sans effacer la frontière : état retenu, preuve qui l’invalide, livraison du message, transfert du paquet et résultat du service ne doivent pas être confondus.

Sources