FR3003111A1 - Procede de traitement dans un reseau centre sur les contenus d'une demande relative a un segment de donnees - Google Patents

Abstract

Procédé de traitement d'une demande relative à un segment de données d'un contenu dans un réseau de communication centré sur les contenus, comprenant au moins un serveur substitut, distinct du serveur d'origine, connecté au dispositif par une interface, et mémorisant au moins une partie des contenus d'un domaine, ledit procédé comprenant les étapes suivantes mises en œuvre par un dispositif d'acheminement : - vérification qu'une autre demande relative au segment est pendante vers le serveur substitut, et qu'une demande antérieure relative au segment, associée à l'autre demande pendante et la demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface ; - envoi de la demande par l'intermédiaire d'au moins une interface permettant d'atteindre au moins un serveur d'origine mémorisant le contenu, lorsqu'aucune demande antérieure relative au segment de données n'est pendante vers un serveur d'origine.

Description

Procédé de traitement dans un réseau centré sur les contenus d'une demande relative à un segment de données L'invention se situe dans le domaine des réseaux de communication centrés sur les informations (en anglais ICN pour Information Centric Networking), et concerne plus particulièrement une technique de traitement d'une demande relative à un segment de données dans un réseau de communication centré sur les contenus (en anglais CCN pour Content Centric Networking). Les réseaux ICN se veulent une alternative aux architectures actuelles, plus adaptée aux usages de l'Internet d'aujourd'hui. Les architectures actuelles reposent en effet sur un principe fondamental, celui de communications de machine à machine, avec deux préoccupations majeures, atteindre un équipement du réseau, et maintenir les communications entre des équipements du réseau. L'utilisateur d'aujourd'hui se soucie cependant peu de savoir quelle machine lui fournit l'information recherchée, ou de savoir où trouver l'information, ce qui l'intéresse est bien l'information elle-même. En réponse à cette tendance, les réseaux ICN proposent une nouvelle approche qui se focalise sur les contenus. Le document intitulé « Networking Named Content », de Van Jacobson et al. publié en 2009 dans les actes de la conférence CoNEXT' 09, décrit un nouveau modèle d'architecture ICN, plus précisément un réseau CCN (CCN pour Content Centric Networking), dans lequel un contenu est obtenu par son nom. Il propose de remplacer l'actuel adressage par équipement réseau (permettant d'identifier un équipement dans le réseau par son adresse IP) par un adressage par nom de contenu. Dans cette nouvelle architecture centrée sur les contenus, deux fonctions principales doivent être rendues : proposer l'information, et obtenir l'information. Pour cela, deux types de paquets de données sont définis, une demande relative à un segment de données d'un contenu (Interest packet) et un segment de données (Data packet). Le premier correspond à une demande émise sur le réseau relative à un segment de données recherché, tandis que l'autre correspond au segment de données lui-même. Ces deux types de paquets comportent chacun un identifiant de segment de données permettant notamment de déterminer à quelle(s) demande(s) correspond un segment de données reçu. Le procédé mis en oeuvre par un dispositif d'acheminement du réseau repose principalement sur trois structures de données : une mémoire cache locale ou magasin de contenus (CS pour Content Store), une table d'acheminement (FIB pour Forwarding Information Base), et une table des demandes pendantes (PIT pour Pending Interest Table). Sur réception par l'intermédiaire d'une interface d'une demande relative à un segment de données, le dispositif d'acheminement du réseau vérifie s'il dispose de ce segment de données dans sa mémoire cache locale. Si tel est le cas, le segment de données recherché est envoyé vers l'interface par l'intermédiaire de laquelle la demande est parvenue au dispositif. Dans le cas contraire, le dispositif vérifie dans la table des demandes pendantes s'il existe des demandes antérieures relatives au même segment de données. En cas d'existence de demandes antérieures pour le même segment de données dans la table des demandes pendantes, l'interface par laquelle a été reçue la demande en cours de traitement est ajoutée dans cette table à l'ensemble des interfaces par lesquelles des demandes relatives à ce segment de données ont été reçues. Lorsque la table des demandes pendantes ne comprend pas de demandes antérieures relatives à ce segment de données, le dispositif mémorise dans la table des demandes pendantes l'identifiant du segment de données recherché en association avec l'interface par l'intermédiaire de laquelle la demande relative au segment de données recherché a été reçue. Il détermine ensuite à partir de la table d'acheminement une interface par l'intermédiaire de laquelle il transmet la demande Lorsque le segment de données recherché est reçu par le dispositif d'acheminement, le segment de données est distribué à l'ensemble des interfaces par lesquelles des demandes antérieures relatives à ce segment de données ont été reçues. Telle que prévue dans ce procédé, la table d'acheminement mémorise au moins une interface permettant d'atteindre un serveur d'origine mémorisant le contenu. Ainsi, le serveur d'origine est sollicité dans la plupart des cas, lorsqu'une première demande relative à un segment de données est reçue. Ceci engendre des coûts d'acheminement pour l'opérateur du réseau, notamment des coûts d'interconnexion lorsque le serveur d'origine n'appartient pas au réseau. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.

Selon un premier aspect, l'invention concerne un procédé de traitement d'une demande relative à un segment de données d'un contenu dans un réseau de communication centré sur les contenus, ledit procédé comprenant les étapes suivantes mises en oeuvre par un dispositif d'acheminement du réseau : - envoi de ladite demande par l'intermédiaire d'au moins une première interface permettant d'atteindre au moins un serveur d'origine mémorisant ledit contenu, lorsqu'aucune demande antérieure relative audit segment de données n'est pendante ; caractérisé en ce que, ledit réseau comprenant en outre au moins un serveur substitut, distinct du serveur d'origine, connecté audit dispositif par une deuxième interface, et mémorisant au moins une partie des contenus d'un domaine, ledit procédé comprend les étapes suivantes, préalablement à l'étape d'envoi et conditionnant ledit envoi : - vérification qu'une autre demande relative au segment a été envoyée par l'intermédiaire de ladite deuxième interface et est pendante, et qu'une demande antérieure relative audit segment, associée à l'autre demande pendante et ladite demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface.

Il est connu pour un opérateur d'introduire dans son réseau des serveurs substituts. Ces serveurs substituts sont agencés pour mémoriser certains contenus, par exemple des contenus populaires. Ces serveurs substituts permettent de ne pas solliciter les serveurs d'origine et ainsi de diminuer les coûts d'acheminement. Il est ici souligné que ces serveurs substituts sont distincts des mémoires caches des dispositifs d'acheminement. Lorsqu'une demande relative à un segment de données est transmise sur l'interface par l'intermédiaire de laquelle le dispositif d'acheminement est connecté au serveur substitut, elle n'est pas traitée par d'autres dispositifs d'acheminement situés sur un chemin à destination du serveur d'origine. Il ne s'agit donc pas selon l'invention de solliciter les mémoires caches des dispositifs d'acheminement mais bien de permettre le fonctionnement de serveurs substituts prévus par exemple pour un réseau de distribution de contenus de type CDN. L'étape de vérification qu'une autre demande a été envoyée par l'intermédiaire de la deuxième interface vers le serveur substitut permet d'identifier que le serveur substitut n'a pas répondu et ne dispose donc pas du segment de données recherché. En effet, il n'existe pas dans ces réseaux centrés sur les contenus de mécanismes permettant à un serveur de répondre négativement à une demande, ni de rediriger la demande De plus, lorsqu'une demande relative à ce segment de données a déjà été reçue par la même interface, la demande en cours de traitement correspond alors à une répétition de la demande La demande en cours de traitement est alors acheminée vers le serveur d'origine qui dispose, lui, du segment de données recherché. Du fait que seules les demandes qui n'ont pu obtenir le segment de données recherché à partir d'un serveur substitut sont envoyées vers le serveur d'origine, ce dernier est moins sollicité et le trafic en provenance du serveur d'origine est de fait diminué La charge réseau s'en trouve également diminuée, et l'utilisation de la bande passante optimisée.

Selon une caractéristique particulière du procédé de traitement, pour envoyer ladite autre demande, ledit serveur substitut est déterminé en fonction du nom de domaine duquel dépend le contenu. La détermination d'un serveur substitut en fonction d'un nom de domaine permet une gestion efficace des contenus, dans la mesure où au niveau d'un dispositif d'acheminement selon l'invention il n'est plus nécessaire de mémoriser un catalogue avec le nom complet des contenus. Les contenus peuvent en effet être agrégés par nom de domaine, ce qui permet de restreindre le volume d'informations mémorisées. L'acheminement par nom de domaine est plus rapide, ce qui accélère également le temps de traitement de la demande, et les performances globales du réseau. Par ailleurs le nom de domaine étant une donnée qui évolue peu, l'association entre un nom de domaine et un serveur substitut possède une validité durable. En outre, l'acheminement de la demande vers un serveur d'origine en cas de non réponse du serveur substitut, permet de sécuriser le traitement des demandes, lorsque le contenu n'est pas mémorisé par le serveur substitut. L'identification d'un nom de domaine dans le nom de contenu de la demande relative à un segment de données suffit en effet à déterminer un serveur substitut vers lequel acheminer la demande Selon une autre caractéristique particulière, le procédé de traitement comprend en outre sur réception dudit segment de données les étapes suivantes : - obtention d'au moins une interface par l'intermédiaire de laquelle a été reçue une demande relative audit segment de données, associée à une demande pendante envoyée par l'intermédiaire d'une interface permettant d'atteindre un serveur appartenant au groupe comprenant le serveur d'origine et le serveur substitut ; - envoi dudit segment de données par l'intermédiaire de ladite au moins une interface obtenue. La distribution du contenu sur l'ensemble des interfaces par lesquelles des demandes relatives au segment de données ont été reçues, présente l'avantage de prendre en compte l'ensemble des demandes traitées par le dispositif d'acheminement, associées à des acheminements aussi bien vers un serveur substitut que vers un serveur d'origine.

Selon une autre caractéristique particulière, le procédé de traitement comprend en outre une étape de réception d'une publication émise par le serveur substitut, d'au moins un nom de domaine pour lequel il mémorise une partie des contenus. La réception d'une publication émise par le serveur substitut permet d'indiquer à un dispositif d'acheminement selon l'invention, quels sont les serveurs substituts qui peuvent être sollicités lors d'une demande de contenu. Elle permet en outre à un serveur substitut nouvellement installé dans le réseau de se faire connaître automatiquement auprès des dispositifs d'acheminement selon l'invention appartenant au réseau. Une gestion des serveurs substituts par nom de domaine permet par ailleurs d'octroyer des ressources réseaux adaptées à la popularité du nom de domaine Par exemple un nom de domaine comme « youtube.com », dont les contenus sont particulièrement populaires, disposera de plusieurs serveurs substituts dédiés et dimensionnés pour traiter un nombre important de demandes. Dans un mode de réalisation, le mécanisme de publication permet également à un dispositif d'acheminement de différencier les données d'acheminement relatives au serveur substitut de celles relatives au serveur d'origine. Selon un deuxième aspect, l'invention propose un dispositif d'acheminement d'une demande relative à un segment de données d'un contenu dans un réseau de communication centré sur les contenus, comprenant : - un module d'envoi, agencé pour envoyer ladite demande par l'intermédiaire d'au moins une première interface permettant d'atteindre au moins un serveur d'origine mémorisant ledit contenu, lorsqu'aucune demande antérieure relative audit segment de données n'est pendante ; - un module de vérification, agencé pour vérifier qu'une autre demande relative au segment a été envoyée par l'intermédiaire d'une deuxième interface permettant d'atteindre ledit serveur substitut et est pendante, et qu'une demande antérieure relative audit segment, associée à l'autre demande pendante et ladite demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface.

Les avantages énoncés pour le procédé de traitement d'une demande relative à un segment de données selon le premier aspect sont transposables directement au dispositif d'acheminement selon le deuxième aspect.

Selon une caractéristique particulière, le dispositif d' acheminement comprend en outre un module de réception d'une publication, agencé pour recevoir une publication émise par le serveur substitut, d'au moins un nom de domaine pour lequel ledit serveur mémorise une partie des contenus.

Selon un troisième aspect, l'invention concerne également un réseau de communication centré sur les contenus comprenant au moins un dispositif d' acheminement selon le deuxième aspect, ledit réseau comprenant en outre au moins un serveur substitut, distinct du serveur d'origine, et mémorisant au moins une partie des contenus d'un domaine Un réseau de communication centré sur les contenus comprenant un serveur substitut permet de tirer parti des avantages connus d'un cache au sein d'un tel réseau : libération de ressources réseau, meilleure utilisation de la bande passante, récupération plus rapide d'un contenu populaire, etc. En outre le dispositif d'acheminement présente l'avantage de pouvoir être intégré dans un réseau mixte comprenant à la fois des dispositifs d'acheminement connus de l'état de la technique et des dispositifs d'acheminement selon l'invention. Aucune modification lourde des infrastructures n'est requise, et le déploiement de dispositifs d'acheminement selon l'invention, au sein d'un réseau de communication centré sur les contenus existant est aisé. Grâce à l'invention il est donc possible d'ajouter simplement des fonctionnalités de cache à une architecture réseau centrée sur les contenus existante. Selon une caractéristique particulière, ledit au moins un serveur substitut du réseau de communication selon le troisième aspect, comprend un module de publication, agencé pour publier au moins un nom de domaine pour lequel il mémorise une partie des contenus. Les avantages présentés pour l'une quelconque des caractéristiques particulières selon le premier aspect sont directement transposables au réseau de communication selon le troisième aspect.

L'invention concerne également un programme pour un dispositif d'acheminement selon le deuxième aspect, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit dispositif et un support d'enregistrement lisible par un dispositif d'acheminement sur lequel est enregistré un programme pour un dispositif d'acheminement.

L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels : - la figure 1 représente un réseau de communication centré sur l'information ; - la figure 2 représente un dispositif d'acheminement selon un mode particulier de réalisation ; - les figures 3a et 3b représentent des étapes du procédé de traitement d'un paquet de données selon un mode particulier de réalisation ; - les figures 4a-h illustrent la mise en oeuvre des étapes du procédé dans un scénario particulier.

La figure 1 représente un réseau de communication centré sur l'information 1 permettant à des entités clientes 108a-b d'accéder à des contenus. Tels que représentés sur la figure 1, le réseau est organisé sous la forme d'un réseau maillé. Il n'existe cependant pas de caractère limitatif quant à la topologie du réseau 1 adoptée. Chaque entité cliente 108a-b est reliée au réseau 10 d'un opérateur de réseaux, lui permettant d'envoyer une demande relative à un contenu, et de recevoir ce contenu depuis un équipement du réseau 1. Ces contenus, vidéos, musique, page internet, par exemple, sont échangés sur le réseau sous la forme de segments de données. Un contenu est constitué soit d'un unique segment de données (le segment est dans ce cas représentatif du contenu dans son ensemble), ou de plusieurs segments de données (chunk en anglais). Un contenu est associé dans l'organisation du réseau à un nom de domaine A titre d'exemple non limitatif, un identifiant de contenu est organisé de la façon suivante : - un préfixe ou information relative à un nom de domaine, correspondant à un nom acheminable ou routable, par exemple « youtube.com », - un nom dans l'organisation, par exemple « stream/news/../ videol/versionl». Un segment de données appartenant au contenu est identifié par l'identifiant du contenu et une information relative au numéro de segment. Selon cet exemple, le segment de données est identifié par « /youtube.com/stream/news/../videol/versionl/segmentl».

Le segment de données demandé peut être obtenu depuis un serveur d'origine 106a-c, un serveur substitut 102a-c, un dispositif d'acheminement tel que décrit par Van Jacobson et al. 104a-d, un dispositif d'acheminement 20a-b, ou depuis tout autre dispositif du réseau 1 susceptible de mémoriser ce segment de données. Les serveurs d'origine 106a-c, sont utilisés par les fournisseurs de contenus pour mettre leurs contenus à disposition sur le réseau 1. Ils sont souvent localisés en dehors du réseau 10 de l'opérateur de réseaux. L'opérateur de réseaux peut également être fournisseur de contenus, et disposer de ses propres serveurs d'origine dans son réseau (cas du serveur d'origine 106a qui appartient au réseau 10). En raison de leur fréquente localisation en dehors du réseau propre à l'opérateur de réseaux, ces serveurs sont généralement éloignés des entités clientes. Cet éloignement peut générer des coûts d'interconnexion importants. Les serveurs substituts 102a-c sont utilisés par les opérateurs de réseaux pour mettre en cache des contenus, en mémorisant au moins une partie des contenus d'un nom de domaine. Plus précisément ils permettent de mémoriser localement et temporairement des contenus demandés par une entité cliente 108a-b, afin de les transmettre ultérieurement à d'autres entités clientes. Les serveurs substituts 102a-c sont dédiés à cette fonction de mise en cache des contenus, et ne disposent pas de fonction d'agrégation et de transmission des demandes. Ils sont en particulier à distinguer d'une mémoire cache locale d'un dispositif d'acheminement 20a-b ou 104a-d, notamment en terme de capacité de mémorisation et d'utilisation. Contrairement à une mémoire cache locale qui dispose de capacités limitées ne permettant de mémoriser que quelques segments de données, les serveurs substituts 102a-c sont utilisés pour répliquer des contenus entiers d'un ou plusieurs serveurs d'origine. Ils permettent en particulier, en fonction du nombre de serveurs déployés et de leur localisation dans le réseau de réduire les congestions réseau au niveau des serveurs d'origine. Ces derniers peuvent en effet faire l'objet d'un nombre très important de sollicitations en lien direct avec la popularité des contenus qu'ils mémorisent. En outre, les serveurs substituts 102a-c sont généralement placés au plus près des entités clientes 108a-b afin de réduire les délais d'accès au contenu recherché. De plus, un dispositif d'acheminement ne publie pas de catalogue des segments de données mémorisé dans sa mémoire cache locale. Cette dernière n'est donc pas adressable. Les dispositifs d'acheminement 104a-d permettent d'acheminer une demande relative à un segment de données vers un serveur d'origine mémorisant ce segment de données, puis de l'acheminer ensuite aux entités clientes qui l'ont demandé L'acheminement réalisé est un acheminement par nom, décrit par Van Jacobson et al. dans le document « Networking Named Content » mentionné précédemment, qui repose principalement sur trois structures de données : un magasin de contenus, une table d'acheminement des demandes, et une table des demandes pendantes. Lorsqu'un dispositif 104a-d reçoit une demande, il vérifie dans un premier temps s'il mémorise le segment de données recherché dans son magasin de contenus, et le renvoie si tel est le cas, vers l'interface par laquelle lui est parvenue la demande Dans le cas contraire, le dispositif 104a-d vérifie qu'il n'existe pas de demande relative au segment de données qui ait déjà été reçue par le dispositif, et pour laquelle le segment de données n'a pas encore été reçu. Une telle demande est appelée « demande pendante ». Plus précisément, il s'agit d'une demande pendante vers un serveur d'origine. Si une telle demande pendante existe, la demande en cours n'est pas réacheminée Si aucune demande pendante n'est mémorisée dans la table des demandes pendantes du dispositif 104a-d, la demande relative au segment de données est envoyée vers un serveur d'origine 106a-c, et devient elle-même pendante jusqu'à réception du segment de données recherché. Lorsque le dispositif 104a-d reçoit le segment de données recherché, ce dernier est simplement distribué aux interfaces du dispositif 104a-d par lesquelles des demandes relatives au segment de données ont été reçues. Le réseau 10 de l'opérateur de réseaux, comprend également des dispositifs d'acheminement 20a-b. Ces dispositifs d'acheminement 20a-b, à la différence des dispositifs d'acheminement 104a-d, permettent d'acheminer une demande vers des serveurs d'origine 106a-c, mais également vers des serveurs substituts 102a-c. Les dispositifs d'acheminements 20a-b sont directement connectés à un ou des serveurs substituts 102a-c. Les dispositifs d'acheminements 20a- b orientent la demande relative à un segment de données en priorité vers le serveur substitut lorsque cela est possible. Pour cela un dispositif d'acheminement 20a-b, utilise deux structures de données particulières en complément des trois structures de données décrites précédemment : une table d'acheminement cache et une table de demandes cachées. Lorsqu'un dispositif 20a-b reçoit une demande, il vérifie dans un premier temps si sa mémoire cache locale mémorise le segment de données recherché et le renvoie, si tel est le cas, vers l'interface par laquelle lui est parvenue la demande Dans le cas contraire, le dispositif 20a-b vérifie si le segment de données est attaché à un domaine dont au moins une partie des contenus est mémorisée par un serveur substitut 102a-c. Si tel est le cas, il vérifie ensuite s'il existe une demande pendante vers ce serveur substitut 102a-c, relative au segment de données recherché. Si une telle demande existe, la demande en cours relative au segment de données, si elle est reçue par l'intermédiaire d'une nouvelle interface, n'est pas réacheminée En revanche si l'interface par laquelle est reçue la demande en cours est identique à l'une des interfaces associées à la demande pendante vers un serveur substitut 102a-c, le dispositif d'acheminement 20a-b renvoie la demande vers un serveur d'origine 106a-c. Le dispositif 20a-b permet donc de renvoyer une demande relative à un segment pour laquelle aucun serveur substitut 102a-c n'a répondu, vers un serveur d'origine 106a-c. La demande est alors traitée de la même manière qu'elle l'aurait été par un dispositif d'acheminement 104a-d. Les serveurs substituts 102a-c sont en outre directement connectés avec les dispositifs d'acheminement 20a-b. Ceci permet d'éviter qu'une demande lors de son envoi vers un serveur substitut 102a-c par un dispositif d'acheminement 20a-b, soit aussi envoyée sur un chemin du réseau permettant d'atteindre un serveur d'origine 106a-c. Lorsqu'un serveur substitut 102a-c mémorise le contenu, cela permet également de le délivrer plus rapidement à une entité cliente 108a-b. La figure 2 représente un dispositif d'acheminement 20 selon un mode particulier de réalisation. Il comprend notamment : - un module d'émission / réception 200, agencé pour recevoir et émettre un paquet de données sur le réseau, le paquet de données pouvant être une demande relative à un segment de données, ou un segment de données ; - un module de traitement 202, agencé pour traiter un paquet de données, le paquet de données pouvant notamment être une demande relative à un segment de données ou un segment de données ; - des moyens de mémorisation 206 ou mémoire cache locale, également appelés magasin de contenus ou « Content Store », agencés pour mémoriser des segments de données ; - une première table 210, appelée table d'acheminement des demandes FIB, pour « Forwarding Information Base », agencée pour mémoriser des données d'acheminement des demandes relatives à des segments de données en fonction des identifiants des segments de données, plus précisément une liste d'identifiants d'interface par l'intermédiaire desquelles un serveur d'origine 106a-c est atteint, en association avec un identifiant de segment de données. - une deuxième table 214, appelée table des demandes pendantes PIT, pour « Pending Interest Table », agencée pour mémoriser une liste d'interfaces par l'intermédiaire desquelles une ou des demandes relatives à un segment de données d'un contenu ont été reçues, tant que ce segment de données n'a pas été reçu en réponse. Il s'agit des demandes pendantes vers un serveur d'origine 106a-c ; - un module de réception d'une publication 204, agencé pour recevoir une publication émise par un serveur substitut 102a-c, d'au moins un nom de domaine pour lequel le serveur substitut 102a-c mémorise au moins une partie des contenus ; - une troisième table 208, appelée table d'acheminement cache CFT, pour « Cache Forwarding Table », agencée pour mémoriser des données d'acheminement des demandes relatives à des segments de données vers des serveurs substituts 102a-c, plus précisément une liste d'identifiants d'interface permettant d'atteindre un serveur substitut 102a-c, en association avec un nom de domaine ; - une quatrième table 212, appelée table des demandes cachées pendantes PCIT, pour « Pending Cached Interest Table », agencée pour mémoriser une liste d'interfaces par l'intermédiaire desquelles une ou des demandes relatives à un segment de données d'un contenu ont été reçues, la première de ces demandes ayant été envoyée vers un serveur substitut 102a-c, tant que ce segment de données n'a pas été reçu en réponse. Il s'agit des demandes pendantes vers un serveur substitut 102a-c. Les moyens de mémorisation 206 sont par exemple une zone mémoire, une zone tampon (ou « buffer ») ou bien encore un disque dur externe.

Le module de traitement 202 comporte un sous-module de vérification 216, agencé pour vérifier si une demande relative au segment de données de la demande en cours de traitement a déjà été envoyée vers un serveur substitut 102a-c, et si deux demandes antérieures ont été reçues par l'intermédiaire d'une même interface. Dans un autre mode de réalisation il peut s'agir d'un module indépendant.

Dans un autre mode de réalisation, le dispositif 20 ne comprend pas de module de réception d'une publication 204. Les données d'acheminement de la table CFT sont dans ce cas renseignées localement. Un tel dispositif d'acheminement peut être un routeur du réseau, une passerelle d'accès au réseau, un équipement multiplexeur d'accès.

Nous allons maintenant décrire le procédé de traitement d'un paquet de données, tel qu'il est mis en oeuvre par le dispositif d'acheminement 20, en relation avec les figures 3a et 3b. On se place dans le cas particulier où l'entité cliente 108a souhaite obtenir un segment de données d'un contenu. L'entité cliente 108a transmet une demande IntP, pour « Interest Packet », relative à ce segment de données.

La figure 3a décrit les étapes du procédé de traitement d'un segment de données qui sont mises en oeuvre par le dispositif d'acheminement 20 pour traiter un paquet portant une demande IntP relative à un segment de données.

Dans une étape El, le dispositif d'acheminement 20 reçoit la demande IntP et détermine s'il dispose du segment de données demandé dans son magasin de contenus 206. Pour cela, il procède par exemple par comparaison de l'identifiant CN du segment de données de la demande IntP avec les identifiants des segments mémorisés dans son magasin de contenus 206.

Si le segment demandé est présent dans le magasin de contenu 206 du dispositif 20, il est transmis, dans une étape E2, vers l'interface par l'intermédiaire de laquelle la demande IntP a été reçue. Le dispositif 20 se met ensuite en attente d'une prochaine demande où d'un prochain segment de données à traiter. Dans le cas contraire, c'est-à-dire lorsque le segment de données recherché n'est pas mémorisé dans le magasin de contenus 206, dans une étape E3, le dispositif d'acheminement 20 détermine un nom de domaine DN à partir de l'identifiant CN du segment de données. A partir de ce nom de domaine DN, le dispositif d'acheminement 20 détermine ensuite dans une étape E4, s'il existe dans la table d'acheminement cache CFT 208, une liste d'interfaces directement connectées à un ou plusieurs serveurs substituts, et associée à ce nom de domaine DN. Si le nom de domaine DN n'est pas trouvé dans la table CFT 208, cela signifie qu'il n'existe pas de serveurs substituts connus du dispositif 20 mémorisant au moins une partie des contenus de ce domaine Dans ce cas, le dispositif 20 passe à une étape El 1, et exécute le procédé d'acheminement 30a connu de l'état de la technique tel que décrit par Van Jacobson et al., dans le document précédemment cité. Si le nom de domaine DN est trouvé dans la table CFT 208, le dispositif 20 vérifie ensuite dans une étape E5, si une demande antérieure relative au même segment de données a déjà été envoyée vers un serveur substitut 102a-c. Pour cela il vérifie en particulier si la table des demandes cachées pendantes PCIT 212 mémorise l'identifiant CN du segment de données recherché. Si l'identifiant du segment de données recherché n'est pas dans la table PCIT 212, aucune demande relative à ce segment de données n'a encore été envoyée vers ce serveur substitut 102a-c susceptible de mémoriser le segment de données recherché. Le dispositif 20 mémorise alors, dans une étape E12, l'identifiant CN du segment de données dans la table PCIT 212, en association avec l'interface F par laquelle la demande IntP relative au segment de données a été reçue. Ceci permet au dispositif 20 de marquer la demande IntP comme étant pendante vers un ou des serveurs substituts 102a-c. Dans une étape E13, la demande IntP est ensuite envoyée à un/des serveur(s) substitut(s) 102a-c, par l'intermédiaire de la ou des interfaces associées dans la table CFT 208 au nom de domaine DN, obtenue(s) à l'étape E4. Le traitement du paquet portant la demande relative au segment de données est alors terminé, et le dispositif se met en attente de réception d'un paquet de données. Dans le cas où, à l'étape E5, l'identifiant CN du segment recherché est mémorisé dans la table PCIT 212, cela signifie qu'une demande antérieure, distincte de la demande IntP, a déjà été reçue du dispositif 20 et est pendante vers un serveur substitut 102a-c. Le dispositif 20 vérifie alors dans une étape E6, si une liste LF d'interfaces associées à l'identifiant CN du segment de données de la demande IntP est mémorisée dans la table PCIT 212. L'absence d'une liste LF d'interfaces associée à l'identifiant CN indique au dispositif 20 qu'au moins deux demandes antérieures relatives au segment de données recherché ont été reçues par l'intermédiaire d'une même interface, une demande antérieure ayant été envoyée vers un serveur substitut 102a-c. Ceci permet d'identifier une absence de réponse du serveur substitut 102a-c. Cette absence de réponse peut être due à des raisons techniques, mais également au fait que le serveur substitut ne dispose pas du segment de données recherché. Le dispositif 20 passe alors à l'étape Ell afin de traiter la demande IntP selon le procédé d'acheminement 30a connu de l'état de la technique, décrit précédemment. Ainsi, dans ce cas, la demande IntP est acheminée vers un ou plusieurs serveurs d'origine 106a-c.

On rappelle qu'à l'étape E6, une liste LF d'interfaces associée à l'identifiant CN du segment de données de la demande IntP ayant été obtenue, une ou plusieurs demandes antérieures relatives au même segment de données ont été reçues par l'intermédiaire d'interfaces deux à deux distinctes, et que la première de ces demandes antérieures a été envoyée vers un serveur substitut 102a-c. Dans une étape E7, le dispositif 20 vérifie que l'interface F par laquelle a été reçue la demande IntP n'appartient pas à la liste LF associée à l'identifiant CN du segment de données recherché dans la table PCIT 212. Si tel est le cas, la table PCIT 212 est mise à jour dans une étape E8, afin d'ajouter l'interface F à la liste LF des interfaces associée à l'identifiant CN du segment de données recherché. Ceci permet, à réception du segment de données recherché, de le distribuer à l'ensemble des interfaces par lesquelles une demande relative à ce segment de données recherché a été reçue. Le traitement du paquet portant la demande relative au segment de données est alors terminé, et le dispositif se met en attente de réception d'un nouveau paquet de données. Si, lors de l'étape E7, l'interface F par l'intermédiaire de laquelle a été reçue la demande IntP en cours de traitement, appartient à la liste des interfaces obtenue à l'étape E6, cela signifie que le serveur substitut 102a-c n'a pas répondu à la demande pendante mémorisée dans la table PCIT 212. Dans ce cas, la demande IntP est acheminée vers un serveur d'origine 106a-c. Pour cela, le paquet portant la demande IntP est envoyé vers le procédé d'acheminement 30b adapté du procédé d'acheminement 30a connu de l'état de la technique. Cette adaptation consiste en l'ajout d'une étape E9 de mémorisation de la liste d'interfaces LF dans la table PIT 214 en association avec l'identifiant CN du segment de données recherché, et de suppression de cette liste LF de la table PCIT 212. La liste d'interfaces LF est mémorisée dans la table PIT 214, après que le dispositif 20a-b ait vérifié qu'il n'existe pas de demande pendante vers un serveur d'origine 106a-c relative au segment de données recherché (étape El 1). La demande est ainsi renvoyée vers un serveur d'origine 106a-c. La suppression de la liste LF d'interfaces associée à l'identifiant CN du segment de données dans la table PCIT 212 permet par ailleurs, de ne pas solliciter inutilement la table PCIT 212, lors d'une prochaine demande relative au segment de données (étape E6). L'étape E6 permet en effet comme décrit précédemment de réorienter une demande avec une liste d'interfaces vide directement vers le procédé 30a connu de l'état de la technique. Dans le mode de réalisation décrit, les étapes E12 et E13 sont mises en oeuvre successivement. Dans un autre mode de réalisation, l'étape E13 est mise en oeuvre avant l'étape E12. Dans encore un autre mode de réalisation, les étapes E12 et E13 sont exécutées en parallèle. La demande IntP est traitée à l'issue des étapes E2, E8, E13, ainsi qu'à l'issue des procédés d'acheminement 30a et 30b. Le procédé de traitement passe à une étape d'attente de réception d'un paquet de données. La figure 3b décrit, quant à elle, les étapes du procédé mises en oeuvre pour traiter un segment de données reçu par l'intermédiaire d'une interface f. Dans une étape Fi, le dispositif d'acheminement 20 reçoit un segment de données DatP par l'intermédiaire de l'interface f, et détermine si le segment DatP provient d'un serveur substitut 102a-c. Pour cela il vérifie que le segment DatP a été reçu par l'intermédiaire d'une interface directement connectée à un serveur substitut 102a-c. Si tel est le cas, le dispositif d'acheminement 20 passe à une étape F2b, dans laquelle il vérifie si l'identifiant CN du segment de données reçu est mémorisé dans la table PCIT 212. Si l'identifiant CN ne se trouve pas dans la table PCIT 212, le segment de données reçu ne correspond à aucune demande pendante pour le dispositif 20, et il est ignoré. Si l'identifiant CN se trouve dans la table PCIT 212, une demande relative à ce segment de données est pendante. Dans une étape F3b, les interfaces associées à l'identifiant CN du segment de données, par lesquelles ont été reçues des demandes antérieures, sont obtenues à partir de la table PCIT 212. L'absence d'interfaces associées à l'identifiant CN indique qu'au moins une demande antérieure a été envoyée vers un serveur substitut 102a-c, mais que ce dernier ayant répondu tardivement, une autre demande a entre-temps été envoyée vers un dispositif du réseau distinct d'un serveur substitut 102a-c. Dans une étape F3c, l'identifiant CN est ensuite supprimé de la table PCIT 212. Ceci permet d'acheminer une prochaine demande relative au segment de données vers un serveur substitut 102a-c (étape E5). Le segment de données en cours de traitement est quant à lui ignoré. On souligne ici que lors de la réception du segment de données en réponse à l'autre demande envoyée entre-temps vers un dispositif du réseau distinct d'un serveur substitut 102a-c, le segment de données est acheminé vers la ou les interfaces mémorisées dans la table PIT 214, dans laquelle la ou les interfaces mémorisées dans la table PCIT 212 ont été mémorisées. Ainsi, le fait d'ignorer le segment de données est sans conséquence vis-à-vis des entités clientes 108 a-b . La demande pendante relative au segment de données est ensuite supprimée de la table PCIT 212 dans une étape F5b. Dans une étape F6, le segment de données est envoyé par l'intermédiaire des interfaces obtenues à l'étape F3b. Cet envoi est géré, à titre d'exemple non limitatif, par une file d'attente associée à chaque interface, dans laquelle sont mémorisés les segments de données en attente d'envoi. Le dispositif d'acheminement 20 repasse ensuite en attente de réception d'un paquet de données.

Si le segment de données DatP reçu par le dispositif d'acheminement 20 ne provient pas d'un serveur substitut (étape F1), dans une étape F2a, le dispositif 20 vérifie si l'identifiant CN du segment de données reçu est contenu dans la table PIT 214. Si l'identifiant CN ne se trouve pas dans la table PIT 214, le segment de données reçu ne correspond à aucune demande pendante et il est ignoré. Si l'identifiant CN se trouve dans la table PIT 214, une demande relative à ce segment de données étant pendante, dans une étape F3a, les interfaces associées à l'identifiant CN du segment de données sont obtenues à partir de la table PIT 214. La demande pendante relative au segment de données est ensuite supprimée de la table PIT 214 dans une étape F5a. On notera que dans cette étape, seule la table PIT 214 est mise à jour. La table PCIT 212 mémorise toujours l'identifiant du segment de données recherché. Cela permet de déterminer pour le traitement d'une prochaine demande relative au segment de données, qu'avant d'avoir été envoyée vers un serveur d'origine 106a-c, une demande antérieure pour ce segment de données a été envoyée vers un serveur substitut 102a-c qui n'a pas répondu. La table PCIT n'est donc pas mise à jour, afin que lors d'une prochaine demande relative à ce contenu, cette dernière soit directement orientée vers un serveur d'origine 106a-c.

Le segment de données est envoyé à l'étape F6 par l'intermédiaire des interfaces obtenues à l'étape F3a. Le segment de données DatP est traité à l'issue des étapes F2b, F3b, F2a et F6. Le dispositif d'acheminement 20 repasse ensuite en attente de réception d'un paquet de données. Dans un autre mode de réalisation, l'étape Fi n'est pas prévue. La présence de demandes pendantes est alors systématiquement vérifiée dans les deux tables PCIT et PIT. Dans le mode de réalisation décrit précédemment, deux tables des demandes pendantes sont utilisées : la table des demandes pendantes vers un serveur substitut (table PCIT 212), et celle des demandes pendantes vers un serveur d'origine (table PIT 214). Dans un autre mode de réalisation, une seule table de demandes pendantes est prévue. Dans ce cas, cette table mémorise également en association avec l'identifiant du segment de données si la demande est pendante vers un serveur substitut ou un serveur d'origine. Par ailleurs, un mécanisme de rafraîchissement de la table PCIT 212 est réalisé, à titre d'exemple non limitatif, par la suppression à intervalle régulier (toutes les cinq heures par exemple), de toutes les entrées de la table PCIT 212 relatives à un segment de données pour lesquelles le segment de données n'a pas été reçu. Ceci permet de prendre en compte les évolutions relatives aux contenus mémorisés par les serveurs substituts 102a-c. Un serveur substitut 102a-c est en effet susceptible de mémoriser un contenu qu'il ne mémorisait pas auparavant, et donc d'envoyer un segment de données en réponse à une demande relative à un segment de données de ce contenu. Un tel réseau centré sur les contenus peut également interfonctionner avec un réseau de distribution de contenus de type CDN (Content Deliver)? Network) intégrant des serveurs substituts adressables par leur adresse IP (Internet Protocol). Dans ce dernier cas, la connexion directe entre un dispositif d'acheminement du réseau centré sur les contenus et un serveur substitut s'effectue par exemple par l'intermédiaire d'une passerelle, agencée pour traduire un adressage IP en un adressage par nom et réciproquement. A titre d'illustration du fonctionnement du procédé de traitement d'une demande relative à un segment de données, les figures 4b-h, représentent le contenu des tables CFT 208, FIB 210, PCIT 212 et PIT 214, d'un dispositif d'acheminement 20 au cours de l'exécution de différentes étapes du procédé, pour un scénario particulier représenté à la figure 4a. Dans ce scénario le dispositif d'acheminement 20 a quatre interfaces il, i2, i3 et i4. Il est interfacé avec l'entité cliente 401 par l'intermédiaire de l'interface il, avec l'entité cliente 402 par l'intermédiaire de l'interface i2, avec un serveur substitut 403 par l'intermédiaire de l'interface i3. L'interface i4 lui permet en outre d'atteindre un serveur d'origine 404. A titre illustratif, on se place dans le cas particulier où trois demandes Dl, D2 et D3 relatives à un même segment de données sont émises successivement. Les demandes Dl et D3 sont émises par l'entité cliente 401, et la demande D2 par l'entité cliente 402.

A l'initialisation, les tables CFT et FIB sont chacune renseignées avec une règle d'acheminement. La table CFT indique que toute demande relative à un contenu appartenant au domaine « youtube.com » doit être acheminée par l'intermédiaire de l'interface i3 (figure 4b). La table FIB indique qu'une demande pour le contenu « /youtube.com/streaminews/../videoliversionl » doit être acheminée par l'intermédiaire de l'interface i4 (figure 4c). Les tables PIT et PCIT sont quant à elles vides. L'entité cliente 401 envoie une demande Dl relative au segment de données « /youtube.com/streaminews/../videoliversionl/segmentl ». Elle est reçue par le dispositif 20 par l'intermédiaire de l'interface il. L'identifiant du segment de données demandé indique que le contenu auquel appartient le segment de données recherché est attaché au domaine « youtube.com ». La table CFT comporte une règle d'acheminement pour ce domaine (étape E4). La demande Dl est donc envoyée vers le serveur substitut 403 par l'intermédiaire de l'interface i3 associée au nom de domaine dans la table CFT (étape E13). Cette demande est pendante vers le serveur substitut 403 tant que le segment de données n'a pas été reçu par le dispositif 20. L'identifiant du segment de données associé à l'interface il par l'intermédiaire de laquelle a été reçue la demande Dl est mémorisé (étape E12) dans la table PCIT (figure 4d). L'entité cliente 402 émet à son tour une demande D2 relative au même segment de données « /youtube.com/streaminews/../videoliversionl/segmentl ». Cette demande est reçue par le dispositif 20 par l'intermédiaire de l'interface i2. La table PCIT indique qu'une demande pour le même segment de données a déjà été reçue. La table PCIT est alors mise à jour afin de mémoriser l'interface i2 par l'intermédiaire de laquelle la seconde demande D2 a été reçue (figure 4e). A ce stade la table PIT n'a toujours pas été modifiée (figure 4g).

Une troisième demande D3 toujours relative au même segment de données « /youtube.com/stream/news/../videol/versionl/segmentl » est maintenant émise par l'entité cliente 401. La demande D3 est reçue par l'intermédiaire de la même interface il que la demande Dl. Cette interface il appartient à la liste des interfaces associées dans la table PCIT à la demande pendante vers le serveur substitut 403 (étape E7). Il s'agit donc d'une répétition de la demande sur la même interface. Le serveur substitut 403 n'a donc pas répondu à la demande Dl. La demande est alors acheminée vers le serveur d'origine 404, selon la règle d'acheminement mémorisée dans la table FIB (figure 4c). La liste d'interfaces associée à l'identifiant du segment de données dans la table PCIT est effacée de cette table (figure 4f), puis est mémorisée dans la table PIT (figure 4h). La table PCIT mémorise l'identifiant du segment de données sans identifiant d'interface associé. Cela permet d'identifier qu'une demande envoyée au serveur substitut 403 est restée sans réponse. Ainsi une prochaine demande relative au segment de données « /youtube.com/stream/news/../videol/versionl/segmentl », est directement acheminée vers le serveur d'origine 404. L'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc).

De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Dans un mode de réalisation particulier, les modules 200, 202, 204 sont agencés pour mettre en oeuvre le procédé précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé précédemment décrit, mises en oeuvre par le dispositif de protection. L'invention concerne donc aussi : - un programme pour un dispositif d'acheminement, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit dispositif ; - un support d'enregistrement lisible par un dispositif d'acheminement sur lequel est enregistré le programme pour un dispositif d'acheminement. Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.10

Claims (10)

1. REVENDICATIONS1. Procédé de traitement d'une demande relative à un segment de données d'un contenu dans un réseau de communication centré sur les contenus (1), ledit procédé comprenant les étapes suivantes mises en oeuvre par un dispositif d'acheminement (20a-b) du réseau (1): - envoi (30b) de ladite demande par l'intermédiaire d'au moins une première interface permettant d'atteindre au moins un serveur d'origine (106a-c) mémorisant ledit contenu, lorsqu'aucune demande antérieure relative audit segment de données n'est pendante ; caractérisé en ce que, ledit réseau (1) comprenant en outre au moins un serveur substitut (102a-c), distinct du serveur d'origine (106a-c), connecté audit dispositif (20a-b) par une deuxième interface, et mémorisant au moins une partie des contenus d'un domaine, ledit procédé comprend les étapes suivantes, préalablement à l'étape d'envoi et conditionnant ledit envoi : - vérification (E6) qu'une autre demande relative au segment a été envoyée par l'intermédiaire de ladite deuxième interface et est pendante, et qu'une demande antérieure relative audit segment, associée à l'autre demande pendante, et ladite demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface (E7).
2. 2. Procédé de traitement selon la revendication 1, dans lequel pour envoyer ladite autre demande, ledit serveur substitut (102a-c) est déterminé en fonction du nom de domaine duquel dépend le contenu.
3. 3. Procédé de traitement selon la revendication 1, comprenant en outre sur réception dudit segment de données les étapes suivantes : - obtention (F3a, F3b) d'au moins une interface par l'intermédiaire de laquelle a été reçue une demande relative audit segment de données, associée à une demande pendante envoyée par l'intermédiaire d'une interface permettant d'atteindre un serveur appartenant au groupe comprenant le serveur d'origine et le serveur substitut ; - envoi (F6) dudit segment de données par l'intermédiaire de ladite au moins une interface obtenue.
4. 4. Procédé de traitement selon la revendication 2, comprenant en outre une étape de réception d'une publication émise par le serveur substitut (102a-c), d'au moins un nom de domaine pour lequel il mémorise une partie des contenus.
5. 5. Dispositif d'acheminement (20) d'une demande relative à un segment de données d'un contenu dans un réseau de communication (1) centré sur les contenus, comprenant :- un module d'envoi (200), agencé pour envoyer ladite demande par l'intermédiaire d'au moins une interface permettant d'atteindre au moins un serveur d'origine (106a-c) mémorisant ledit contenu, lorsqu'aucune demande antérieure relative audit segment de données n'est pendante ; - un module de vérification (216), agencé pour vérifier qu'une autre demande relative au segment a été envoyée par l'intermédiaire d'une interface permettant d'atteindre un serveur substitut (102a-c) et est pendante, et qu'une demande antérieure relative audit segment, et ladite demande en cours de traitement ont été reçues par l'intermédiaire d'une même interface.
6. 6. Dispositif d'acheminement (20) selon la revendication 5, comprenant en outre un module de réception (204) d'une publication, agencé pour recevoir une publication émise par le serveur substitut (102a-c), d'au moins un nom de domaine pour lequel ledit serveur (102a-c) mémorise une partie des contenus.
7. 7. Réseau de communication centré sur les contenus (1) comprenant au moins un dispositif d'acheminement (20a-b) selon la revendication 5, ledit réseau (1) comprenant en outre au moins un serveur substitut (102a-c), distinct du serveur d'origine (106a-c), et mémorisant au moins une partie des contenus d'un domaine.
8. 8. Réseau de communication (1) selon la revendication 7, dans lequel ledit au moins un serveur substitut (102a-c) comprend un module de publication, agencé pour publier au moins un nom de domaine pour lequel il mémorise une partie des contenus.
9. 9. Programme pour un dispositif d'acheminement (20a-b) selon la revendication 5 ou 6, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé selon l'une des revendications 1 à 4, lorsque ledit programme est exécuté par ledit dispositif.
10. 10. Support d'enregistrement lisible par un dispositif d'acheminement (20a-b) sur lequel est enregistré le programme selon la revendication 9.30