RINA : une révolution dans le monde de l’Internet ?

22/12/2018
Publication REE REE 2018-5
OAI : oai:www.see.asso.fr:1301:2018-5:24884
DOI :
contenu protégé  Document accessible sous conditions - vous devez vous connecter ou vous enregistrer pour accéder à ou acquérir ce document.
Prix : 10,00 € TVA 20,0% comprise frais d'expédition hors UE non compris (8,33 € hors TVA) - Accès libre pour les ayants-droit
se connecter (si vous disposez déjà d'un compte sur notre site) ou créer un compte pour commander ou s'inscrire.
 

Résumé

RINA : une révolution dans le monde de l’Internet ?

Auteurs

Portrait de Jean-Pierre Hauet
Jean-Pierre Hauet
RINA : une révolution dans le monde de l’Internet ?
L’IA et l’industrie
L’intelligence artificielle : prothèse ou orthèse ?
Refroidissement des logements : ne refaisons pas l’erreur des chauffages d’appoint
26e Congrès de la Conférence générale des poids et mesures (CGPM) à Versailles
Gérard Mourou, prix Nobel de physique 2018
Transition énergétique : il est temps de redonner la priorité à l’électricité
Comment décarboner les transports lourds de marchandises ?
La RATP se met au vert
Autoconsommation : le débat ne fait que commencer
Un mix gazier 100 % renouvelable en 2050 : peut-on y croire ?
La fiscalité du carbone se renforce
Stratégie nationale bas carbone : les premiers indicateurs de résultats interpellent
Eoliennes flottantes : deux inaugurations importantes mais beaucoup d’incertitudes demeurent
Vers un cluster de l’hydrogène dans la région de Liverpool-Manchester
Les batteries Li-ion pour l’automobile : un marché en pleine évolution
Mobileye et le Road Experience Management (REMTM)
La cyber-sécurité dans les systèmes d'automatisme et de contrôle de procédé
Les applications industrielles et scientifiques des logiciels libres : aperçu général
Les applications industrielles des logiciels. libres
Les applications industrielles des logiciels libres (2ème partie)
L'identification par radiofréquence (RFID) Techniques et perspectives
La cyber-sécurité des automatismes et des systèmes de contrôle de procédé. Le standard ISA-99
Êtes-vous un « maker » ?
Entretien avec Bernard Salha
- TensorFlow, un simple outil de plus ou une révolution pour l’intelligence artificielle ?
Donald Trump annonce que les Etats-Unis se retirent de le l’accord de Paris
L’énergie et les données
Consommer de l’électricité serait-il devenu un péché ?
Un nouveau regard sur la conjecture de Riemann – Philippe Riot, Alain Le Méhauté
Faut-il donner aux autorités chargées du respect de la loi l’accès aux données chiffrées ?
Cybersécurité de l’Internet des objets : même les ampoules connectées pourraient être attaquées
L’Internet des objets - Deux technologies clés : les réseaux de communication et les protocoles (Partie 2)
ISA L’évolution des normes et des modèles
FIEEC - SEE - Présentation SEE et REE - mars 2014
Les radiocommunications à ondes millimétriques arrivent à maturité
L’Internet des objets - Deux technologies clés : les réseaux de communication et les protocoles (Partie 1)
Internet des objets : l’ARCEP et l’ANFR mettent à la consultation l’utilisation de nouvelles bandes de fréquence autour de 900 MHz
L’énergie positive
Controverses sur le chiffrement : Shannon aurait eu son mot à dire
La cyberattaque contre les réseaux électriques ukrainiens du 23 décembre 2015
Le démantèlement des installations nucléaires
L’Accord de Paris
Les data centers
L’hydrogène
Le piégeage et la récolte de l’énergie. L’energy harvesting
Régalez-vous, c’est autant que les Prussiens n’auront pas...
Le kWh mal traité Deuxième partie : le contenu en CO2 du kWh
Le kWh mal traité
Enova2014 - Le technorama de la REE
Les grands projets solaires du pourtour méditerranéen
Après Fukushima, le nucléaire en question ?
On sait désormais stocker les photons pendant une minute
Identification d’objet par imagerie fantôme utilisant le moment orbital angulaire
La découverte du boson de Higgs, si elle est avérée, confirmera le modèle standard
Multiplexage par moment angulaire orbital : mythe ou réalité ?
Supercalculateur quantique: le choix de la supraconductivité
Photovoltaïque : la course au rendement se poursuit
Production d’hydrogène par photolyse de l’eau assistée par résonance plasmon
Vers une meilleure compréhension du bruit de scintillation
Les nombres premiers en première ligne
La nouvelle révolution des moteurs électriques
Les cyber-attaques, un risque pour nos grandes infrastructures ?
Le stockage de l’électricité
Le véhicule électrique (2) : comment donner corps à la transition énergétique ?
L'automatisation des transports publics
Les technologies nouvelles de l’éclairage : leur impact sur l'environnement et la santé
Les énergies marines renouvelables
Le véhicule électrique : une grande cause nationale
Médaille Ampère 2012
Berges2009_Hauet.pdf
Prix Bergès 2009

Métriques

4
0
247.26 Ko
 application/pdf
bitcache://5fff5c933be0b18b84a2db73fcfc6c8e6929b684

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1301:2018-5/24884</identifier><creators><creator><creatorName>Jean-Pierre Hauet</creatorName></creator></creators><titles>
            <title>RINA : une révolution dans le monde de l’Internet ?</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2018</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Sat 22 Dec 2018</date>
	    <date dateType="Updated">Sat 22 Dec 2018</date>
            <date dateType="Submitted">Thu 17 Jan 2019</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">5fff5c933be0b18b84a2db73fcfc6c8e6929b684</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>41154</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

REE N°5/2018 Z 27 L'ARTICLE INVITÉ RINA : une révolution dans le monde de l’Internet ? Introduction par Jean-Pierre Hauet Conçu il y a plus de 40 ans, le modèle de l’Internet est devenu d’une très grande complexité. D ans l’architecture aujourd’hui utilisée, la couche « réseau », caractérisée par l’adres- sage et le protocole de communication IP, est censée assurer l’interconnectivité entre réseaux de communication pouvant reposer sur des couches basses très diversifiées, y compris au niveau de la couche physique. Mais l’universalité du protocole IP est devenue lar- gement illusoire. En effet, le protocole Internet, conçu au dé- part sur l’idée d’offrir un service d'acheminement des trames en mode “best effort”, c’est-à-dire sans garantie formelle de résultat, a dû faire face à une succession de nouveaux be- soins, tels que la garantie de bon acheminement, la gestion de réseau, la mobilité, les communications sans fil, etc. Au cours des dernières années, les questions de sécurité ont pris une importance primordiale. Les protocoles successifs se sont additionnés dans chaque couche du modèle classique TCP/IP, dans le but de répondre à des difficultés ou à des besoins toujours nouveaux. La notion même de couche protocolaire a perdu de son sens et des services essentiels, tels que ceux liés à la qualité de service ou à la sécurité, se trouvent répartis entre différents niveaux de l’architecture. Conçu initialement comme devant être un réseau de réseaux, l’Internet est devenu une gigantesque construction à laquelle des perfectionnements que certains appels des « rustines » sont sans cesse apportés, avec une sécurité qui est de plus en plus difficile à assurer. L’une des faiblesses les plus fondamentales réside dans la conception même du protocole IP et de son « acolyte » TCP, qui conduit à véhicu- ler à tous les niveaux du système les adresses IP avec les conséquences qui en résultent quant aux failles de sécurité, caractérisées notamment par les attaques en usurpation d’adresses ou en déni de service. Pour beaucoup, l’évolution vers IPv6, dont l’objet est de remédier à la pénurie d’adresses de l’IPv4, conduit à une impasse car elle ne remédie en rien, au contraire, aux défi- ciences congénitales de l’Internet. Une école de pensée s’est donc créée, sous l’égide notamment du Français Louis Pouzin, l’un des pionniers de l’Internet1 , pour reprendre le problème plus en amont et repenser l’Internet en tant que réseaux de réseaux. Ainsi est-née l’initiative RINA (Recursive Internetwork Ar- chitecture ou architecture inter-réseau récursive) qui propose une alternative au modèle actuel de TCP/IP. Les principes en 1 Voir notamment l’entretien avec Louis Pouzin dans la REE 2013-4. Figure 1 : Les DAPS (Distributed Applications Processes) et leurs composants – Source : Wikipédia (Edugrasa). 28 ZREE N°5/2018 L'ARTICLE INVITÉ ont été décrits dans leurs grandes lignes dans un document de John Day “Patterns in Network Architecture, a return to fundamentals” publié en 2008. L’idée de base de RINA est que la communication inter-réseau, ou Inter-Process Com- munication (IPC), doit être assurée par un ensemble unique de protocoles, utilisé de façon récursive, plutôt que de repo- ser sur des couches de protocoles spécialisés en fonction du besoin à traiter. RINA entend ainsi reconstruire la structure globale d’Inter- net en formant un modèle comprenant une seule couche répétitive, le DIF (Distributed IPC Facility), qui rassemble le jeu minimal de composants requis pour permettre l’établis- sement d’un IPC distribué entre divers processus d’applica- tion ou DAP (Distributed Application Processes) échangeant par un protocole dénommé CDAP (Common Distributed Application Protocol) les données nécessaires à l’exécution d’une tâche (figure 1). Les DIFs sont eux-mêmes des DAPs dont la communica- tion avec les autres DIFs peut être organisée de façon récur- sive en utilisant le même modèle Tous les niveaux assurent le même service à deux instances ou plus, avec certaines caractéristiques spécifiques (latence, taux de pertes, priori- tés…) (figure 2). RINA prend en charge de manière inhérente, et sans nécessiter de mécanismes supplémentaires la mobilité, le multi-hébergement et la qualité de service, et fournit un environnement sécurisé et configurable. Il peut être déployé de façon incrémentale, en reposant sur Ethernet, à côté ou au-dessus d’IP. RINA est pour ses promoteurs le meilleur choix pour construire les réseaux de prochaine génération en raison de sa théorie solide, de sa simplicité et des fonctionnalités qu’il permet. Plusieurs équipes de chercheurs planchent sur le sujet et notamment l’équipe de recherche RINA de l’univer- sité de Boston, le projet IRATI, dont l’objet est de dévelop- per une implémentation de RINA au-dessus d’Ethernet sous Linux OS, le projet PRISTINE visant à explorer certains aspects essentiels de la programmabilité de RINA et le projet IRINA venant en aval d’IRATI et visant à comparer RINA à d’autres solutions relevant de l’état de l’art. Enfin, il faut citer les travaux de Louis Pouzin dans le cadre de l’association PSOC (Pouzin Society)2 . C’est à ce der- nier que nous ouvrons à nouveau nos colonnes sous forme de cet article invité où Louis Pouzin rappelle les faiblesses du modèle actuel et expose tous les avantages que l’on peut attendre de l’architecture RINA. Q 2 http://pouzinsociety.org/ Figure 2 : Vue d’ensemble de l’architecture RINA – Source : projet PRISTINE. REE N°5/2018 Z 29 L'ARTICLE INVITÉ RINA ou le renouveau de l’Internet L’objet de RINA R INA est un outil logiciel applicable à tout objet connecté : les ordinateurs, les puces de l’Inter- r r net des objets ou encore les mobiles… Il est applicable à tout système qui utilise des logi- ciels de communication permettant à ses éléments consti- tutifs de communiquer entre eux. Le but est d’avoir des prin- cipes de communication (des protocoles) qui soient com- muns et puissent être utilisés par tous les objets susceptibles de communiquer. Au siècle précédent cela s’appelait le téléphone. Un outil qui permet à des gens qui parlent toutes sortes de langues Louis Pouzin Pionnier de l'Internet To restore trust in the Internet, it is now essential to base it in the future on a much stronger foundation than the one it is based on today, essentially TCP/IP network protocol which is the foundation of the current Internet Building the Internet on a new foundation, no longer based on IP layers but on the notion of recursivity based on the principles of Algol computer language and on a model of Inter-Process Communications (IPC), is the goal of the RINA initiative. The principles were described in 2008 in a paper by John Day “Patterns in Network Architecture, a return to fundamentals” In RINA, the network protocol is no longer a means of transporting data but a mechanism for exchange between processes that carry the data. Only processes do access the data they transport. From the outside, it is not possible- for an alien to access the internal addresses, which makes difficult the attacks that we know today. With an architecture where IPC (Inter-Process Commu- nications) replaces layered, connected or offline models, recursively duplicating to accommodate physical networks, provides a safe and efficient way of conveying information. Standardization is beginning to describe this model, and in particular ETSI1 , and several European manufacturers take it to overcome the security shortcomings of ongoing deve- lopments in the 5G or securing confidential data (Toronto Hospital, Stockholm University, etc.). RINA can contribute to the solidity of blockchains, like Car- r r dano’s try in the financial field, but the article focuses pri- i i marily on the telecom field. 1 ETSI GR NGP 003 V1.1.1 (2017-03) – NGP Next Generation Protocol; Packet Routing technologies. ABSTRACT Pour rétablir la confiance dans l’Internet, il est aujourd’hui indispensable de le faire reposer à l’avenir sur des bases beaucoup plus solides que celles sur lesquelles il repose aujourd’hui, essentiellement le protocole réseau TCP/IP qui est le fondement de l’Internet actuel. Bâtir l’Internet sur un nouveau socle, ne reposant plus sur les couches IP mais sur la notion de récursivité basée sur les principes du langage informatique Algol et sur un mo- dèle de communication interprocessus récursif IPC (Inter Process Communications), tel est l’objectif de l’initiative RINA. Ces principes en ont été décrits en 2008 dans un document de John Day “Patterns in Network Architecture, a return to fundamentals”. Dans RINA, le protocole réseau n’est plus un moyen de transporter les données mais il devient un mécanisme d’échange entre processus qui transportent les données. Seuls les processus accèdent aux données qu’ils trans- portent. De l’extérieur, il n’est donc pas possible d’accéder aux adresses internes, ce qui rend difficiles les attaques telles que celles que nous connaissons aujourd’hui. Avec une architecture où les IPC (Inter-Process Commu ( ( - nications) se substituent aux modèles en couches, en s mode connecté ou bien hors connexion, la duplication de manière récursive assure alors un mode de transport de l'information sûr et performant pour s’adapter aux réseaux physiques. La normalisation a commencé à décrire ce modèle, et no- tamment ETSI1 et plusieurs constructeurs européens s’en em- parent pour pallier les insuffisances sécuritaires des dévelop- pements en cours dans la 5G ou pour sécuriser des données sensibles (hôpital de Toronto, Université de Stockholm, etc.). RINA peut contribuer à la solidité des blockchains, comme le tente Cardano dans le domaine financier mais l’article se focalise essentiellement sur le domaine des télécoms. 1 ETSI GR NGP 003 V1.1.1 (2017-03) – NGP Next Generation Protocol; Packet Routing technologies. RÉSUMÉ 30 ZREE N°5/2018 L'ARTICLE INVITÉ de pouvoir communiquer, la contrainte étant que chacun puisse comprendre la langue de l’autre personne. C’est l’objectif de RINA, faire communiquer entre eux tous les systèmes qu’ils soient petits ou gros avec des moyens simples que chaque système peut comprendre. Pourquoi est-ce que ce n’est pas comme cela à l’heure ac- tuelle ? Parce que ce besoin n'avait pas été compris. Ceux qui ont fait Internet étaient ravis de faire des choses compliquées parce que c’est plus intéressant du point de vue technique et parce qu’ils voulaient tous faire un système supérieur aux autres et chaque fois que l’on veut faire un système supérieur à ce qui existe, on fait plus compliqué et donc les systèmes se comprennent de moins en moins. L’Internet sous TCP/IP Pourquoi l’insécurité règne-t-elle dans l’Internet actuel ? C’est parce que la définition des protocoles n’a pas été créée pour examiner tous les cas particuliers, les variantes, les plus vicieux étant généralement ceux où ces protocoles évoluent, une nouvelle version remplaçant une ancienne. Quand un système n’est pas sécurisé, il est capable de faire des choses que l’on n’a pas prévues et comme parfois ces actions sont hostiles ou coûteuses ou ambiguës, elles perturbent le fonctionnement normal des échanges. Le problème dans l’internet actuel, ce sont les variantes. Pour l’instant, les variantes sont incluses dans l’implémen- tation de base. Ce sont les applications, les développements ou les usages qui induisent des variantes qui sont parfois beaucoup plus que des variantes et que l’on nomme alors écosystèmes. C’est un ensemble de procédures, de cou- tumes, de langues ou de systèmes existants. Certes, la diver- sité ou les conventions spécifiques seront toujours indispen- sables mais l’objectif c’est que ces variantes n’empêchent pas de construire un système universel de communication. Comme beaucoup de systèmes ne sont pas à jour, ils uti- lisent des variantes périmées et au bout du compte l’Internet est un système de communication imprécise. Les variantes peuvent être interprétées de manière différente car un sys- tème ne sera pas au même niveau de mise à jour qu’un autre, ce qui sera correct pour un système ne le sera pas pour un autre. Dans l’Internet actuel toutes ces variantes rendent les communications compliquées car tout le monde n’en fait pas les mêmes interprétations Le cas le plus fréquent est celui des mises à jour, c’est un risque parce que l’on n’a pas toujours imaginé tous les cas particuliers qui peuvent se présenter et il y a des quantités de personnes qui ne sont pas au courant de leur existence et ne sont plus au même niveau de communication. Des pro- tocoles imprécis génèrent une culture de l’incertitude. Les hackers connaissent très bien ces cas particuliers, mais cette matière grise non publiée a pour source des personnes qui utilisent mal les protocoles par manque de connaissance ou d’exigence ou par des fraudeurs qui connaissent les cas de mauvais fonctionnement mais qui s’en servent pour tirer parti des incidents dans leur propre intérêt. Le marécage de l’internet d’aujourd’hui Tous les systèmes sont constitués au bout du compte d’éléments physiques. Même si leurs algorithmes de fonc- tionnement ont été testés dans tous les sens, la physique sert à les faire fonctionner et elle est par définition sensible : il peut y avoir des chips qui ont mal cuit, des contacts qui n’étaient pas prévus et qui se produisent quand même, c’est inhérent à tout système qui a des composantes physiques. Internet est actuellement trop complexe, impossible à sécuriser car il est compartimenté, toutes les applications ne tournent pas sur toutes les machines, tous les systèmes y sont spécialisés. Mais si on a l’impression que tout va bien, c’est que ceux qui les font marcher sont des gens expéri- mentés avec des années d’expérience. Ils ont vu un certain nombre de pannes, ils savent où sont les points faibles et ils vont vite à identifier où est le problème. C’est comme cela que l’on vit avec… RINA : les différences Un langage simple Dans l’Internet actuel il y a des dizaines de milliers de manières de composer des commandes et des requêtes, d’organiser des échanges entre les différents systèmes qui ont chacun leur manière de s’exprimer ; on parle alors de syntaxe comme dans les différents langages. Dans RINA, tous ces mécanismes sont réalisés d’une manière qui n’est pas classique. La syntaxe de l’Allemand n’est pas la même que la syntaxe de l’Anglais ni celle des Indiens, etc. Donc il faut avoir néces- sairement des syntaxes spécifiques aux gens qui parlent entre eux pour des choses qu’ils connaissent soit par leur métier, soit parce que c’est la même langue, technique ou humaine. C’est ce qu’a fait RINA, définir des paramètres et poser des conditions qui doivent être remplies par tous les sys- tèmes dans leur protocole de communication de manière qu’ils soient compréhensibles par tous les autres systèmes. Donc il ne faut pas qu’il y en ait beaucoup et il ne faut pas qu’ils soient compliqués. Il faut qu’ils soient simples pour que toutes les personnes qui implémentent ces systèmes puissent les comprendre sans faire d’erreurs d’interprétation. Cela ne peut pas se faire dans un protocole universel parce qu’il en faudrait autant de versions qu’il existe de cas particuliers. On sait très bien que c’est un problème d’avoir REE N°5/2018 Z 31 L'ARTICLE INVITÉ plein de cas particuliers mais le fond du problème c’est que, si on peut l’implémenter, c’est déjà un grand pas en avant de franchi mais que, si on ne peut pas implémenter un système avec des personnes qui utilisent des principes différents de fonctionnement dans leur technique, il n'y aura jamais rien qui fonctionne. Donc, en faisant une structure de base dans laquelle la transmission de l’interprétation du langage qu’on utilise est très simple, ceux qui comprennent ce langage peuvent construire leurs arguments, les développer et les utiliser dans leurs activités spécifiques. RINA est basé sur la récursivité Ce n’est pas une notion toujours très facile à comprendre (voir encadré 1). La récursivité c’est la possibilité de réutiliser des fonctions (principes, règlements ou logiciels) en utilisant les mêmes programmes mais avec des paramètres différents. On sait que l’algorithme est correct, il a toujours fonctionné et que, même si on change les paramètres, il va continuer à fonction- ner. Mais le « si ça marche on ne change rien », ce n’est pas toujours une bonne idée, il faut que vraiment rien d’autre ne change, ce qui n’est souvent pas le cas, et Il faut que cela soit simple, facilement compréhensible par beaucoup de gens, bien testé et conçu pour fonctionner de façon autonome. C’est pourquoi la sécurité dans RINA est basée sur la sim- plicité des techniques de base et aussi des méthodologies de développement récurrentes à chaque fois que l’on ajoute des fonctions supplémentaires. Car, quand une partie de sys- tème dépend d’une autre, c’est un risque et un mauvais design. Toute dépendance d’un système à un autre doit être limitée à des fonctions minimales bien connues et qui ne sont pas dé- pendantes de la physique ou de la logique d’autres systèmes. Il faut pouvoir détecter immédiatement d’où vient le problème. Dans les réseaux, quand on veut faire la preuve qu’un sys- tème marche, il ne suffit pas de prouver qu’il marche quand les autres marchent bien mais qu’il fonctionne bien même quand les autres marchent mal. Quand on construit des sys- tèmes de plus en plus complexes, la règle générale est que chaque morceau d’un système complexe doit être simple de manière à pouvoir prouver qu’il marche bien quand d’autres marchent mal. Cela ne veut pas dire que ça marchera tou- jours bien mais qu’on saura très vite où est la cause du mau- vais fonctionnement. Dans l’Internet actuel, du fait du vieillissement des sys- tèmes, ceux-ci ne sont jamais conformes à ce qu’ils devraient être. Quand il n’y a pas de système d’auto contrôle, le contrôle de voisinage, la sécurité devient mauvaise : on ne sait pas d’où vient le problème, on ne sait pas où il faut chercher car on n’a pas les éléments de base et cela prend des jours ou des semaines et le coût que cela peut représenter. Les fonctions de RINA Dans RINA, la partie fondamentale est très simple et permet d’ajouter des fonctions pour traiter l’information, ces fonctions pouvant varier autant que l’on veut à condi- tion d’utiliser des paramètres. C’est-à-dire qu’à chaque fois que l’on échange des commandes, des demandes ou des réponses entre deux systèmes, on utilise les commandes de base, qui doivent être universelles, et éventuellement des paramètres supplémentaires. On peut prendre l’exemple d’un restaurant et de son menu. On commande une petite quantité des plats pré- sentés à la carte dans laquelle chacun peut faire son choix. Le restaurant est capable de servir des gens très différents à condition qu’il y ait quelques principes de base comme respecter un menu, le tarif, les moyens de paiement. Les particularismes de certains utilisateurs sont définis en faisant référence à des règles, à la carte du restaurant. Tout cela est simple, universel, c’est la base. C’est cela que permet RINA : déployer autant de variantes qu’il est nécessaire d’avoir sans obliger tout le monde à les utiliser. Seuls les utilisateurs ou les applications de ces va- riantes ont besoin de connaître qu’elles existent et ce que l’on peut faire avec. Les bases de l’architecture de RINA La complexité est le premier ennemi de la sécurité. Un système simple est beaucoup plus sûr qu’un système com- pliqué ; ce n’est pas de la science, ce n’est pas de l’abstrac- Qu’est-ce qu’une fonction récursive ? Une fonction ou procédure (ensemble de règles logiques) X est définie récursivement si sa définition est de la forme X = \(A, B, ..., X) où A, B, ... désignent des règles ou fonctions connues et \ une fonction ou procédure combinant A, B, ... et X. C’est dire que X fait appel à elle-même pour se définir. À cette relation générale, il faut associer une condition d’arrêt afin que la procédure ne boucle pas indéfiniment. Le propre d’une procédure récur- sive bien pensée est qu’elle est généralement d’une admirable concision et n’utilise qu’un minimum de concepts extérieurs à sa définition comme dans la définition de la factorielle de n : fonction factorielle(n) {if (n<=1) return 1 else return n*factorielle(n-1)} Encadré 1 : Définition d’une fonction récursive – Source : ChronoMath, une chronologie des mathématiques à l’usage des professeurs de mathématiques, des étudiants et des élèves des lycées & collèges. http://serge.mehl.free.fr/anx/fonc_recur.html 32 ZREE N°5/2018 L'ARTICLE INVITÉ tion, c’est la réalité des choses. Plus un système est com- plexe, pour les utilisateurs, pas pour les machines, plus il y a de chances qu’il y ait des erreurs et des erreurs de sécurité en particulier. Le point fort de RINA ce n’est pas que les programmeurs soient plus malins que les autres mais que la simplicité des protocoles utilisés permette de les examiner avec le plus grand soin. Cela ne veut pas dire qu’il n’y aura jamais d’er- reurs, mais il y en aura beaucoup moins et celles que l’on va trouver pourront être corrigées très rapidement parce qu’elles sont situées dans des cadres de fonctionnement précis. Pourquoi parler d’un « internet à bulles » à propos de RINA. Quand on a un programme qui fonctionne, on peut vou- loir lui adjoindre des fonctions supplémentaires. Si elles sont déjà implémentées ailleurs, on met les deux systèmes ensemble, par exemple deux processus RINA, et on les fait communiquer entre eux, en étudiant les fonctions qui doivent passer de l’un à l’autre. Le nom de bulles est alors utilisé pour être plus compréhensible que si on parlait de sous-programmes. Pour la maintenance, les personnes qui gèrent un projet RINA doivent connaître les particularités de deux systèmes et quand il y en aura trois, quatre, cinq, etc., il faudrait qu'elles connaissent les défauts de tous les autres, ce n’est pas possible. Autrement dit quand on constitue un système formé de plusieurs autres systèmes, chaque bulle peut être considérée comme indépendante mais quand elles sont toutes ensemble c’est autre chose, ce n’est pas simplement 25 bulles ensemble, c’est un système nouveau dans lequel il y a 25 bulles qui ont même entre elles d’autres bulles. Dans ce cas, l’aspect récursif de RINA veut dire que l’on peut en ajouter autant que l’on veut cha- cune étant ou non contenue dans l’autre, à côté de l’autre ou contenant d’autres. Dans RINA il n’y a pas à recoller 36 fois les mêmes choses dans le code. Aujourd’hui, il y a quelques milliers de com- mandes de base dans l’Internet parce que beaucoup de ces commandes sont propres à certains usages. Mais pourquoi faut-il que tout soit présent en même temps ? Quand on tape une commande copie, on voudrait que cela fonctionne dans tous les cas de figure… et on n’y parvient pas. D’abord parce que tous les gens ne sont pas au courant, on lance une balle dans un jeu de quilles sans savoir quelles sont les quilles qui vont tomber. Ces particularismes ne sont pas implémentés de base dans RINA, ils sont simplement « reconnaissables ». Le point fort est que RINA peut les reconnaître et les trans- férer, mais il ne fait rien dessus, il se contente de communi- quer les informations d’un système à l’autre et c’est ensuite à chaque système utilisateur de traiter les paramètres qui le concernent ou de ne pas les traiter s’ils ne le concernent pas et de produire les résultats adéquats uniquement pour ceux qui l’ont demandé et qui sont des demandeurs validés. Autrement dit, c’est un peu un système de filtrage interne, alors qu’aujourd’hui il n’y a pas de filtre, tout va partout, on envoie une commande et les paramètres de la commande peuvent être envoyés à n’importe qui. Si ce sont uniquement des logiciels qui sont concernés, très bien, mais on peut envoyer une commande à un logiciel qui n’est pas du tout concerné c’est la même syntaxe, on met le nom, les para- mètres derrière, c’est le principe du shell2 . Ça va à n’importe qui pour n’importe quoi. RINA et les noms de domaine Chaque processus de RINA est conçu comme une pièce de code en langage Algol ou Perl ou autre. Il y a eu tradi- tionnellement une séparation intellectuelle entre ceux qui faisaient les systèmes et ceux qui développent les langages. Alors que les langages de programmation étaient au départ surtout orientés sur le calcul, par exemple Fortran, c’est devenu de plus en plus complexe. Les objets traités par le langage sont devenus des listes, des arbres, des sous- programmes, tout ce que l’on voulait. On pouvait exprimer dans le cadre d’un langage nouveau, par extension d’un lan- gage existant, toutes sortes d’objets techniques qui étaient beaucoup plus complexes que l’addition, la soustraction, etc. Ce qui veut dire qu’un grand nombre de gens n’ont pas suivi cette évolution. Ils s’imaginent que parce que l’on appelle « truc » une suite de caractères, le problème est réglé… Ce n’est pas vrai du tout. Cela fonctionne si l'on a testé l’exécution de ce morceau de programme que l’on ajoute, avec les formats et les limites de capacité des don- nées qui sont tolérables et adaptées à l'utilisateur. Mais les codeurs ne savent pas, n’ont pas la documentation et n’ont pas, en outre, envie de chercher. Les noms de domaine ont été inventés par l’ICANN en 1998, mais c’est uniquement dans le cadre d’un système de financement mis à la charge des utilisateurs. C’est comme si les gens de l’UIT à Genève avaient décidé que les numéros de téléphone seraient fabriqués et vendus chaque fois q’’un utili- sateur en fait la demande. C’est parfois utile d’administrer ainsi les noms de domaines si on a un grand nombre d’applications à gérer comme les impôts, la météo… mais ce n’est pas né- cessaire que cela soit géré par une seule organisation privée. Pour ce qui est des noms de domaine, on aura toujours besoin d’identifiants quoi que l'on fasse. Dans un ensemble d’applications ou d’usages ou de personnes qui travaillent sur les mêmes données, il faut que chacune puisse définir les données sur lesquelles il travaille : « Je me réfère à tel ensemble de données ». 2 Louis Pouzin est aussi l’inventeur du Shell lors de sa résidence au MIT en 1964. REE N°5/2018 Z 33 L'ARTICLE INVITÉ Mais il faut se mettre d’accord sur un système d’identi- fiants. RINA a autant de systèmes de noms que l’on veut parce c’est la programmation réalisée avec des outils qui datent de 40-50 ans c’est-à-dire de l’Algol imaginé en 1950 par John Backus et Peter Naur mais les gens des systèmes n’ont jamais été intéressés par cela. Pour eux c’était de la programmation, de l’abstraction et cela ne les intéressait pas car ce n’était pas directement lié aux machines. Ceux qui ont conçu l’Algol avaient compris qu’un identi- fiant n’était valable que dans une certaine partie d’un pro- gramme et n’avait aucun sens ailleurs. Un identifiant peut être référencé de l’extérieur si on a des communications avec un autre programme qui sert alors d’identifiant. A ce moment-là, on déclare les identifiants de l’un qui vont être utilisés par l’autre, on établit une corrélation mais ce n’est absolument pas commun à tout le monde, c’est spécifique à ces lots de programmes. Ceux qui ont fait l’Internet n’avait aucune idée de cette culture de langage ; ils ne savaient rien là-dessus, l’identi- fiant était une adresse en machine ou bien une adresse dans un langage de programmation, de code… C’était le même ou pas le même, c’était la pagaille. Ils n’avaient absolument pas de discipline d’identification dans la constitution des pro- grammes de l’internet. Les noms de domaine ça n’avait rien à voir avec le fait d’appliquer une solution, c’était juste un système de finan- cement qui n’existe que pour ceux qui s’en servent. On peut avoir des identifiants spécifiques pour ses applications avec des systèmes de référence qui sont déjà classiques dans les systèmes de programmation où on fait référence à un autre. Les développements actuels de RINA Il existe des bancs d’essai opérationnels et des généra- teurs de test de trafic, des hackathon de développeurs et des applications industrielles. RINA, ce sont des projets vivants, suivis par des équipes de chercheurs et d’industriels: IRATI, ARCFIRE, OCARIN, rLITE, RINAsim, etc. Une page dédiée aux avancées de RINA est abondée par les équipes. Lors de la dernière session du printemps 2018 à Barce- lone, la liste des industriels et centres de recherche présents – Ericsson, Ciena, Telefonica, Vodafone – montre que RINA n’est plus un projet mais une nouvelle révolution qui entraîne des changements de paradigmes dans notre façon de penser l’Internet. La mise en appli- cation dans des technologies phares comme la blockchain Cardano ou le cloud computing de CIENA ou encore le système VANET de voitures intelligentes sont basés sur des pro- tocoles RINA. Ce qui fait dire à Martin Geddes dans un article sur RINA que c’est la killer distributed app et que la révolution RINA est en route… mais comme c’est une architecture et non un protocole, l’implémentation se fera de façon transparente dans toutes les couches de la société. “If TCP/IP is the piston airplane, RINA is the jet age. At the moment, it’s exotic; in 20 years, it will be ordinary” Martin GEDDES - 24/5/2018 Références s HTTPWWWSOFTWAREPRESERVATIONORGPROJECTS!,'/, s HTTPSWWWITUINTFRABOUT0AGESDEFAULTASPX s HTTPICT
ARClREEUINDEXPHPRINA
WORKSHOP

REPORT s HTTPPOUZINSOCIETYORGNODE s HTTPSWWWENCQORCA s HTTPICT
ARCFIREEUWP
CONTENT UPLOADS6!.%4
2).!

 pdf s HTTPWWWMARTINGEDDESCOMTHE
rina-revolution-is-ready-to-roll/ Q La notion de DIF Allocator DIF = Distributed Inter Process Function F IPC = Inter Process Communication Scope = une partie de programme ou de données qui est visible, ce qui n’est pas forcément réciproque. À associer à des propriétés À : lire ou écrire, lire et écrire, pouvoir ou non y accéder, etc. Il n’y a pas de normes pour définir les paramètres d’un scope, en français on parle de « portée » mais c’est inusité dans le monde Internet car moins précis sans la notion de visibilité. La notion de DIF Allocator est une composante r importante de l’architecture RINA. Il s’agit de gérer les liens entre les processus. C’est une communication interprocessus (IPC) entre di- vers processus qui peuvent avoir une portée (scope ( ( ) différente. C’est ce qui fait que l’Internet actuel est faible car il ne connaît pas la notion de scope qui fait partie du langage Algol. Lors d’un processus de demande d’allocation de ressources IPC par une application, c’est à au DIF Allocator de déterminer à quelle fonction d’interpro- cessus distribuée, l’allocation doit être livrée. Si la res- source est disponible sur un DIF qui n’est pas visible ou accessible, l’allocateur de DIF mettra en place un processus d’IPC pour se joindre au DIF ou coopérera avec d’autres allocateurs de DIF afin de créer un DIF ayant une portée suffisante pour permettre un IPC. Louis Pouzin est ancien élève de l’Ecole polytechnique, membre de l’association Eurolinc pour la promotion des langues natives dans l’internet et fondateur de la société Open-Root, gestionnaire d’une racine Internet indépendante.