🌐 RINA — Recursive InterNetwork Architecture
Alternative à TCP/IP par John Day · IPC comme principe unificateur · DIF · IRATI · Ouroboros · ARCFIRE · Pouzin Society
🧑💻 John Day — l'architecte de RINA
John Day est un informaticien américain, professeur à Boston University, pionnier des réseaux informatiques qui a participé aux travaux originaux d'ARPANet dans les années 1970. Son livre de 2008, "Patterns in Network Architecture: A Return to Fundamentals" (Prentice-Hall), est la thèse fondatrice de RINA.
Sa conviction centrale : TCP/IP n'est pas une architecture réseau cohérente — c'est un ensemble de solutions ad-hoc accumulées au fil des décennies, sans principe unificateur. En analysant 50 ans de réseaux informatiques, il dégage un pattern récurrent : toute communication réseau peut se réduire à de l'Inter-Process Communication (IPC).
Il co-fonde la Pouzin Society (nommée en hommage à Louis Pouzin, inventeur des datagrammes et père de l'internet français CYCLADES) pour coordonner les recherches RINA au niveau international.
📐 Définition & concepts fondamentaux
RINA (Recursive InterNetwork Architecture) est une architecture réseau clean-slate — elle ne cherche pas à patcher TCP/IP, elle le remplace par un modèle plus cohérent. Elle repose sur deux principes :
- Les réseaux ne sont que de l'IPC — toute communication distante entre processus suit le même modèle qu'un appel local étendu à distance.
- Une seule couche récursive — le découpage en couches se fait par portée/échelle, pas par fonction. Il n'existe qu'un seul type de couche, répété N fois selon les besoins.
DIF — Distributed IPC Facility
IPC — Inter-Process Communication
Adressage 3 niveaux
DAF — Distributed Application Facility
Contrôle de congestion Delta-T
Sécurité par design
⚖️ RINA vs TCP/IP — comparaison
| Dimension | TCP/IP | RINA |
|---|---|---|
| Principe de layering | Par fonction (physique, liaison, réseau, transport, application) — 5 couches distinctes | Par portée/échelle — une seule couche récursive, répétée N fois selon les besoins |
| Adressage | L'adresse IP mélange identité et localisation — source de problèmes de mobilité | Séparation stricte : noms applicatifs (stables) / adresses (locales à DIF) / points d'attache |
| Mobilité | Solutions externes complexes : Mobile IP, LISP — non intégrées à l'architecture | Support natif via la hiérarchie d'adressage — changement de DIF transparent |
| Multihoming | Solutions ad-hoc, multiples adresses IP, configurations ECMP complexes | Inhérent au modèle DIF — un processus peut appartenir à plusieurs DIFs |
| Sécurité | Ajoutée tardivement : TLS, IPSec, DNSSEC — couches séparées, non cohérentes | Intégrée par design dans chaque DIF via politiques configurables |
| Congestion | TCP réactif : détecte la congestion par la perte de paquets après coup | Delta-T proactif : 3 timers bornés, gestion locale à chaque DIF |
| NAT | Indispensable, brise le principe end-to-end, complexifie les protocoles | Inutile — la séparation noms/adresses le rend structurellement superflu |
| Routage | BGP global : tables explosant, ossification, lenteur de convergence | Routage local à chaque DIF — pas de table de routage globale |
| Nombre de protocoles | Des dizaines : IP, TCP, UDP, OSPF, BGP, DNS, DHCP, ARP… | Un seul jeu de protocoles, instancié à chaque DIF avec des politiques différentes |
| Évolutivité | Modification quasi impossible à l'échelle d'Internet — ossification totale | Chaque DIF peut évoluer indépendamment, déploiement progressif possible |
