Mon blog

Ce nouveau RFC annonce [mais c'est très prématuré] que l'ICN est désormais une technologie mûre et qu'il est temps de se pencher sur les problèmes pratiques de déploiement. Il documente ces problèmes, et des solutions possibles. Il décrit aussi des expériences de déploiement (très limitées et qui ont souvent disparu.)

Si vous voulez réviser le concept d'ICN, lisez le RFC 8793. Il y a plusieurs façons (section 4 du RFC) d'envisager le déploiement des techniques « fondées sur le contenu » (ICN) :

• Une table rase, où on remplace complètement l'Internet existant par une solution à base d'ICN. Cela implique que les actuels routeurs soient tous changés, pour des machines faisant tourner un logiciel comme NFD. (Inutile de dire que c'est complètement irréaliste.)
• Un déploiement de l'ICN comme réseau de base, avec une couche TCP/IP au-dessus, pour continuer à faire tourner l'Internet classique. Cela pose les mêmes problèmes que la table rase.
• Un déploiement de l'ICN au-dessus de l'Internet existant, un réseau virtuel, quoi, comme on faisait pour IPv6 au début. C'est le seul déploiement effectif qu'ait connu l'ICN pour l'instant, avec des idées comme CCNx sur UDP. Cela permet l'expérimentation et le déploiement progressif.
• De l'ICN « sur les côtés » du réseau. On peut envisager une épine dorsale qui reste en TCP/IP, avec des réseaux extérieurs en ICN, et des passerelles entre les deux. Ces réseaux extérieurs en ICN pourraient concerner, par exemple, l'IoT (cf. draft-irtf-icnrg-icniot), et les passerelles transformeraient du CoAP (RFC 7252) en ICN et réciproquement.
• Les technologies qui permettent de découper un réseau physique en plusieurs tranches, chacune abritant un réseau virtuel, comme la 5G, pourraient permettre de faire cohabiter harmonieusement ICN et TCP/IP sur la même infrastructure physique.
• Enfin, on peut imaginer, tant qu'on y est, des déploiements mixtes, mêlant les différentes approches citées ci-dessus.

La section 5 du RFC décrit de manière plus détaillées des chemins de migration possibles. Et la section 6 décrit quelques expériences qui ont effectivement eu lieu (on peut aussi lire le RFC 7945) :

• Le projet FP7 PURSUIT (documenté dans un article IEEE non public) se positionnait comme une approche de table rase mais, en pratique, a été déployé par dessus l'Internet existant. Il a compté jusqu'à 70 nœuds. Comme tous les projets ICN, il a été abandonné à la fin des subventions. (Pour s'amuser, regardez ce qu'est devenu le site Web du projet.)
• Le projet NDN de la NSF a également effectué un déploiement (environ 100 nœuds) sur l'Internet existant.
• Le projet ICN 2020 a produit des rapports sur ses réalisations au-dessus de TCP/IP, avec 37 nœuds ICN.
• Le projet UMOBILE a été déployé entre autre sur le réseau communautaire Guifi, avec dix Raspberry Pi. C'est raconté dans « Information-Centric Multi-Access Edge Computing Platform for Community Mesh Networks ».

Ces projets tournaient sur l'Internet d'aujourd'hui. Mais il y avait aussi d'autres projets qui se situaient plus bas dans le modèle en couches :

• POINT et RIPE ont également utilisé Guifi mais cette fois en étant directement sur le WiFi, avec TCP/IP par dessus. l'ICN.
• Un autre projet concret a connecté 60 nœuds en 6LoWPAN, en utilisant RIOT, et est documenté dans « Information Centric Networking in the IoT: Experiments with NDN in the Wild ».
• Signalons enfin (mais le RFC en liste d'autres) le projet Doctor, sur lequel a été testé le transport de trafic HTTP réel.

Le RFC note qu'aucun de ces déploiements n'a dépassé mille utilisateurs. Pour moi, il s'agissait clairement d'expérimentation et appeler ça « déploiement » est trompeur.

La section 7 du RFC discute des points qui manquent pour des déploiements significatifs, notamment question normalisation. La liste est longue. Le RFC note entre autres :

• Le problème des applications ; un navigateur Web existant n'a aucun moyen de savoir s'il doit récupérer un contenu en ICN ou par des moyens classiques. Aucune API ne permet au programmeur de contrôler ce choix. De même, aucune API vaguement standard n'existe pour utiliser les capacités de l'ICN.
• Le nommage des objets dans l'ICN n'est pas normalisé, quoique il existe des tentatives comme celle du RFC 6920 (voir aussi les RFC 8569 et RFC 8609.)
• Et il y a tous les autres problèmes pratiques, comme l'OAM…
• La sécurité a droit à sa propre section, la 10. (Voir aussi le RFC 7945.) Elle n'a guère été testée en vrai pour l'instant, à part peut-être dans le projet Doctor (voir « Content Poisoning in Named Data Networking: Comprehensive Characterization of real Deployment », une étude détaillée de l'attaque par empoisonnement du contenu, où un méchant producteur essaie d'envoyer du contenu malveillant aux clients, ou bien « A Security Monitoring Plane for Named Data Networking Deployment », les deux articles se sont spécialement concentrés sur NFD.) Compte-tenu de l'expérience de l'Internet, cela sera pourtant un point crucial.