Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Content-Centric Networking
Un article de Van Jacobson et al. dans les Communications of the ACM
Article mis en ligne le 25 février 2012
dernière modification le 6 août 2014

par Laurent Bloch
logo imprimer
Licence : CC by-nd

Van Jacobson et cinq autres auteurs ont publié dans le numéro de janvier 2012, vol. 55 N° 1, des Communications of the Association for Computing Machinery un article intitulé Networking Named Content.

 Relier des données plutôt que des serveurs

Le projet est le suivant : aujourd’hui les usages principaux de l’Internet consistent à distribuer ou à retrouver des documents numériques, textes, images, films, musiques ; or les protocoles de l’Internet sont conçus pour établir des conversations entre des ordinateurs.

L’Internet actuel repose sur un modèle qui décrit, fondamentalement, la mise en relation de deux ordinateurs à travers un réseau. Cette problématique remonte aux années 1960 et 1970, lorsque les ressources rares que l’on cherchait à partager étaient des ordinateurs, gros et chers. En vertu de ce modèle, un paquet IP contient deux identifiants, l’adresse de l’origine de la communication, et l’adresse de la destination.

De ce fait, la distribution et le partage de documents numériques (au sens large que nous avons donné ci-dessus) nécessitent la mise en œuvre de mécanismes complexes, tels que les réseaux pair-à-pair ou les Content Distribution Networks (CDN). La sécurité des données et des échanges repose sur la sécurité des ordinateurs et du réseau, ce qui n’a rien de logique, et impose de la complexité là où il y en a déjà trop. C’est un peu comme si, pour assurer la confidentialité du courrier acheminé par voie ferrée, il fallait verrouiller les accès aux gares et enfermer les lignes de chemin de fer dans des tunnels blindés.

La meilleure façon de surmonter ces difficultés une bonne fois pour toutes est de remplacer la question où sont mes données ? par une nouvelle question, plus logique : quelles données me faut-il ?. Les auteurs pensent que l’idée de nom de donnée est une abstraction mieux adaptée aux usages actuels du réseau que l’idée de nom de serveur.

Sur un réseau content-centric circulent deux types de paquets de données : les paquets Interest et les paquets Data. Le navigateur d’un internaute qui cherche tel ou tel morceau de musique sur le Net va émettre un paquet Interest, ce paquet va être diffusé selon un protocole que nous pouvons, en première approche, décrire comme très semblable aux protocoles pair-à-pair que nous connaissons. Le paquet Interest contient le nom (Content Name) du document cherché.

Le nom de la chose cherchée (Content Name) a une structure hiérarchique qui ressemble à celle des noms de domaines, comme par exemple /parc.com/videos/WidgetA.mpg/_v<timestamp>/_s3. Un paquet Data « satisfait » un paquet Interest si le Content Name du paquet Interest est un préfixe de celui du paquet Data. D’ailleurs, un paquet Interest peut être reçu pour un document qui n’existe pas encore, mais que le serveur pourra créer à la volée !

 Mais qui sont ces originaux qui veulent tout changer ?

À ce point de l’exposé, le lecteur un peu informé des réseaux et de leur fonctionnement est en droit de se demander si ce projet n’est pas l’œuvre d’une équipe charlatans comme il s’en constitue régulièrement, et qui ont « de meilleures idées » pour un « meilleur Internet ». À ce lecteur à juste titre sceptique il convient de répondre tout d’abord qu’il ne s’agit pas de pures spéculations, mais qu’un prototype existe et fonctionne au PARC (Palo Alto Research Group). Le PARC, ce sont quand même les gens qui ont inventé Ethernet, l’imprimante laser, les interfaces graphiques à fenêtres et à souris, une bonne partie de la programmation objet, et j’en passe. Quant à Van Jacobson [1], si Vinton Cerf et Robert Kahn sont les pères de TCP/IP (1974), il est le médecin qui a sauvé le nourrisson de ses maladies infantiles, par deux inventions majeures : un système de compression des entêtes de segments TCP, plus guère utilisé aujourd’hui mais qui fut très précieux, dans les protocoles CSLIP et PPP, à l’époque des modems et des lignes à bas débit, et l’algorithme de prévention de congestion qui porte son nom et qui repose sur le principe de « démarrer lentement et accélérer progressivement » (facile à écrire, plus délicat à réaliser dans toutes les piles TCP/IP de la planète), principe qui a permis à l’Internet de passer de quelques centaines de machines connectées à un bon milliard aujourd’hui, avec des lignes dont le débit a été augmenté de trois ordres de grandeur au bas mot. Au passage Jacobson a aussi écrit traceroute et tcpdump. Il ne s’agit donc pas là, avec le projet CCNx, d’un travail d’amateurs naïfs.

 Comment ça marche ?

Concrètement, comment cela fonctionne ? Voyons d’abord rapidement ce qu’il en est pour les couches basses : le transport CCN peut être implanté au-dessus de tout service d’acheminement non-fiable de paquets, comme par exemple IP, UDP, ou un protocole pair-à-pair. Nous n’en parlerons plus.

Un paquet Interest est émis : il doit être acheminé (routé en argot informatique). Comment cela se passe-t-il ? De façon analogue à ce qui se passe dans les protocoles pair-à-pair, nous allons examiner cela un peu plus en détail.

Voyons d’abord la question des paquets perdus et des interrogations sans réponse : contrairement à TCP, les émetteurs CCN sont sans état, il est de la responsabilité du consommateur final de détecter cette situation et de ré-émettre les paquets
Interest en déshérence.

À la différence de ce qui se passe avec IP, un paquet Interest peut être émis sur plusieurs interfaces, que les auteurs préfèrent d’ailleurs appeler faces, parce qu’il peut s’agir d’échanges avec des processus locaux.

Le nœud CCN émetteur comporte un tampon de mémoire, le ContentStore, qui joue un rôle analogue aux tampons d’un routeur IP, à ceci près qu’un paquet IP, une fois émis, n’a plus aucun intérêt et peut être détruit, alors que les paquets CCN de type Data, qui sont idempotents, auto-identifiés et auto-authentifiés, peuvent être utiles à d’autres consommateurs, et sont gardés dans le ContentStore aussi longtemps que possible.

Un nœud CCN comporte en outre une Pending Interest Table (PIT), qui sert à garder la trace du chemin vers les émetteurs d’Interests, afin que les Data correspondantes puissent leur être envoyées. Dans le protocole CCN, seuls les paquets Interest sont routés, et sur leur trajet, comme le petit Poucet, ils laissent des « miettes de pain » sous forme d’entrées dans la Pending Interest Table, miettes qui seront données aux oiseaux dès lors que le paquet Data correspondant sera passé et aura été envoyé dans la (ou les !) bonne(s) direction(s), ou à défaut à l’expiration d’un délai de garde (timeout en jargon).

 Politique d’émission et de réception

Quand un paquet Interest arrive sur une face, si le ContentStore (rappelez-vous, le buffer) contient un ContentObject dont le ContentName matches avec celui de l’Interest, le ContentObject est émis sur la face par où le paquet Interest est arrivé.

S’il n’y a pas de ContentObject adéquat, la Pending Interest Table (PIT) est examinée afin de voir s’il n’y aurait pas eu déjà un autre Interest pour le même ContentName. Si oui, la face par où vient d’arriver le nouveau paquet Interest est ajoutée, dans la PIT, à la liste des faces par lesquelles il faudra émettre le ContentObject correspondant quand ils arrivera.

Le traitement des paquets Data est plus simple : comme les saumons, ils remontent la chaîne des entrées dans les PIT vers le (ou les) demandeur(s) origina(l|aux).

Les auteurs assurent que tout schéma de routage bon pour IP sera bon aussi pour CCN, parce que le modèle d’émission de paquets de CCN est un sur-ensemble de celui d’IP, avec seulement la levée de certaines restrictions (un paquet peut avoir de multiples destinations, et être enregistré à partie de multiples sources), et la même sémantique pour le routage : agrégation hiérarchique de noms selon le principe de sélection de la plus longue correspondance (longest match lookup).

 Modèle de sécurité de CCN

Le modèle de sécurité de CCN repose sur la sécurité du contenu des objets échangés, par opposition au modèle de sécurité de TCP/IP, qui repose sur la sécurité des nœuds et des liaisons. Tous les objets échangés par CCN sont signés, et les données privées sont chiffrées. Cela allège les contraintes de sécurité sur les serveurs et le réseau. Les auteurs expriment cela en disant que si CCN achemine les données selon un modèle pair-à-pair, son modèle de sécurité est de bout en bout (end-to-end).

CCN confère aussi aux producteurs de données des moyens de contrôler par où passent leurs données, en imposant une politique de routage associée à un contenu et à un signataire.

 Innovation radicale avec reprise de l’existant

Le prototype opérationnel a d’ores et déjà permis de réaliser des essais assez complets. Sans surprise, le protocole est particulièrement prometteur pour la diffusion de contenus à de multiples destinataires.

Ce qui me semble le plus remarquable dans ce projet, c’est qu’il élabore une architecture entièrement nouvelle tout en reprenant, avec un discernement dont on voit bien qu’il résulte d’une connaissance approfondie de l’architecture en place, tout ce qui peut être repris de l’existant, et en y ajoutant les idées novatrices venues du monde du pair-à-pair.

Il y a encore beaucoup d’autres choses intéressantes dans cet article particulièrement clair et agréable à lire, et je ne saurais trop vous recommander de vous procurer l’original, si toutefois vous avez une bibliothèque universitaire décente pas trop loin de chez vous.

Notes :

[1Van est son prénom, ce n’est pas un Néerlandais


Forum
Répondre à cet article


pucePlan du site puceContact puceEspace rédacteurs puce

RSS

2004-2017 © Site WWW de Laurent Bloch - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.87.59