FR3003115A1

FR3003115A1 - Procede d'allocation de ressources pour la mise en oeuvre de reseaux virtuels dans un reseau de telecommunication

Info

Publication number: FR3003115A1
Application number: FR1352011A
Authority: FR
Inventors: Qing Shen
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2013-03-06
Filing date: 2013-03-06
Publication date: 2014-09-12
Also published as: WO2014135793A1

Abstract

L'invention a pour objet un procédé de ressources pour la mise en œuvre d'un réseau virtuel dans un réseau de télécommunication comprenant une pluralité de nœuds de routage (401,402,403,404), le procédé comprenant les étapes suivantes, mises en œuvre par au moins un des nœuds de routage : réception (300) de paquets d'un flux de données munis d'une entête comprenant un champ indiquant le type de service auquel est associé ledit flux ; et allocation (303) au flux de données, en fonction de la valeur de ce champ, d'au moins une ressource relative à un tunnel virtuel vers un autre de ces nœuds de routage.

Description

Procédé d'allocation de ressources pour la mise en oeuvre de réseaux virtuels dans un réseau de télécommunication L'invention concerne un procédé d'allocation de ressources pour la mise en oeuvre de réseaux virtuels dans un réseau de télécommunication et s'applique notamment au domaine des réseaux virtuels. L'ensemble des techniques permettant l'utilisation et la mise en oeuvre de réseaux virtuels est habituellement désigné en utilisant l'expression « virtualisation des réseaux ». Même si cette expression comporte le néologisme « virtualisation » dérivé du mot anglais « virtualization », celle-ci est utilisée dans la description car elle est communément employée par l'homme du métier. La virtualisation des réseaux a pour objectif le partage d'une même infrastructure de réseau de télécommunication ou de différentes infrastructures de réseau de télécommunication. Pour cela, des réseaux virtuels isolés les uns par rapport aux autres sont créés. Les ressources à partager entre les différents réseaux virtuels peuvent être des ressources calculatoires, de la mémoire et/ou de la bande passante. Si le réseau de télécommunication est utilisé pour convoyer des données associées à des services différents, la virtualisation des réseaux permet de les répartir sur plusieurs réseaux virtuels indépendants. Les réseaux VPN, acronyme venant de l'expression « Virtual Private Network », les réseaux VLAN, acronyme venant de l'expression « Virtual Local Area Network », et les réseaux VC comprenant des circuits virtuels sont des exemples connus mettant en oeuvre la technique de virtualisation des réseaux. L'informatique en nuage, désignée habituellement par l'expression anglaise « Cloud Computing », est l'un des domaines pour lequel les techniques de virtualisation sont utilisées.

En effet, le partage des ressources est dans ce cas particulièrement important pour que les opérateurs puissent réaliser des économies et dimensionner le mieux possible leurs réseaux. A ce titre, la virtualisation des réseaux est l'un des outils permettant de rendre l'utilisation de l'informatique en nuage réaliste, que ce soit du point de vue technique ou du point de vue financier. Cette technique est utile en particulier au niveau de la couche IaaS, acronyme venant de l'expression anglo-saxonne « Infrastructure as a Service ». Dans la pratique, il apparaît que l'utilisation de réseaux virtuels n'est pas toujours optimale. A titre d'exemple, si un réseau virtuel est mis en oeuvre pour un service donné, il est possible que les ressources lui étant allouées ne soient plus suffisantes pour satisfaire à la demande des utilisateurs pendant une période de temps donnée. Ainsi, si la bande passante allouée n'est pas suffisante pour supporter le trafic lié à ce service, des problèmes de congestion apparaîtront. D'autre part, si le trafic cesse, les ressources du réseau sont toujours réservées par le réseau virtuel et ne peuvent être utilisées pour d'autres services. Il existe donc un besoin pour gérer dynamiquement et le plus rapidement possible ces réseaux virtuels, et ce de la manière la plus économique et la plus rapide possible.

Un but de l'invention est notamment de pallier les inconvénients précités. A cet effet, l'invention a pour objet un procédé d'allocation de ressources pour la mise en oeuvre d'un réseau virtuel dans un réseau de télécommunication comprenant une pluralité de noeuds de routage, ce procédé comprenant les étapes suivantes, mises en oeuvre par au moins un des noeuds de routage : réception de paquets d'un flux de données munis d'une entête comprenant un champ indiquant le type de service auquel est associé ledit flux ; et allocation au flux de données, en fonction de la valeur de ce champ, d'au moins une ressource relative à un tunnel virtuel vers un autre desdits noeuds de routage. Il est ainsi possible de créer dynamiquement un réseau virtuel dans lequel des ressources, au niveau des tunnels virtuels composant ce réseau, sont allouées spécifiquement à un service, en fonction du type de service qui lui est associé. Selon une caractéristique avantageuses, outre ladite au moins une ressource relative à un tunnel virtuel, une ressource de traitement comprenant une partie des ressources calculatoire et de la mémoire du noeud de routage est allouée au flux de données, ce qui permet de réserver également, pour le service en question, des ressources de traitement au niveau des noeuds de routage impliqués dans le réseau virtuel. Selon un mode de réalisation, les étapes de réception de paquets et d'allocation de ressource sont mises en oeuvre successivement par chacun des noeuds de routage par lesquels transite les paquets du flux de données, ce qui permet une réservation immédiate et progressive, noeud par noeud, des ressources allouées au service via le réseau virtuel. Selon un autre mode de réalisation, le procédé comprend la vérification, pour chacun des noeuds de routage par lesquels transitent les paquets du flux de données, de la disponibilité de la au moins une ressource suite à la réception des paquets du flux de données, l'allocation de cette au moins une ressource étant mise en oeuvre après vérification de la disponibilité de ladite au moins une ressource par l'ensemble desdits noeuds de routage par lesquels transitent les paquets du flux de données. Ceci permet de ne réserver les ressources de réseau virtuel qu'après vérification de leur disponibilité sur l'ensemble du réseau virtuel, ce qui évite la réservation inutile de ressources au niveau des premiers noeuds de routages ou des premiers tunnels virtuels du réseau virtuel lorsqu'il s'avère qu'un noeud ou un tunnel virtuel suivant ne dispose pas de ressources à allouer au service en question.

Selon une caractéristique avantageuse, après vérification de la disponibilité de ladite au moins une ressource, les noeuds de routage envoient un message à un contrôleur de réseau indiquant si cette au moins une ressource est disponible, et, lorsque l'ensemble des noeuds de routage par lesquels transitent les paquets du flux de données ont indiqué qu'au moins une ressource est disponible, envoi du contrôleur à ces noeuds de routage d'un message d'allocation de la au moins une ressource au flux de données. Ceci permet de contrôler la réservation globale des ressources à allouer au service au niveau d'un contrôleur de réseau, typiquement situé à distance au niveau d'un plan de contrôle du réseau. Selon une caractéristique particulière, la au moins une ressource relative à un tunnel virtuel est une partie de la bande passante, du débit maximal ou de la capacité maximale du tunnel virtuel, ce qui permet d'utiliser ce tunnel virtuel pour différents types de service. Selon une autre caractéristique particulière, le champ indiquant le type de service est le champ ToS de l'entête IP des paquets du flux de données. Dans un mode de réalisation de l'invention, la au moins une ressource allouée est libérée lorsqu'aucun paquet du flux de données n'a été reçu pendant une durée d'observation, ce qui permet de rendre disponible ces ressources à d'autres services lorsque ces dernières ne sont plus utilisées. Dans un autre mode de réalisation dans lequel les noeuds de routage contiennent une table de configuration dans laquelle est mémorisée une correspondance entre au moins une valeur du champ indiquant le type de service et au moins une ressource relative à un tunnel virtuel vers un autre des noeuds de routage, le procédé comprend en outre, suite à la réception des paquets du flux de données, la consultation de la table de configuration afin de déduire la ressource relative à un tunnel allouée en fonction de cette correspondance. Ceci permet une gestion dynamique de la création de réseaux virtuels au moyen de table de configuration pouvant être transmises au préalable par un contrôleur de réseau. Selon une caractéristique avantageuse, une règle d'allocation, définie par défaut dans la table de configuration, est utilisée pour allouer la au moins une ressource lorsque la valeur du champ n'a pas d'équivalent dans la table de configuration, ce qui permet la création du réseaux virtuels pour des services non prévus initialement. Alternativement, selon une autre caractéristique avantageuse, un message est envoyé à un contrôleur de réseau lorsque la valeur du champ n'a pas d'équivalent dans la table de configuration, ce contrôleur de réseau retournant au noeud de routage une règle d'allocation à utiliser pour allouer la au moins une ressource. Ceci permet de gérer de manière centralisée, au niveau du contrôleur de réseau, la création du réseaux virtuels pour des services non prévus initialement.

L'invention propose en outre un noeud de routage comprenant des moyens pour mettre en oeuvre le procédé ci-avant. L'invention propose également un contrôleur de réseau comprenant des moyens pour initialiser et mettre à jour des tables de configuration mémorisées dans des noeuds de routage appartement à un réseau de télécommunication, ces tables de configuration mémorisant une correspondance entre au moins une valeur d'un champ, présent dans les entêtes de paquets d'un flux de données et indiquant le type de service auquel est associé ledit flux, et au moins une ressource relative à un tunnel virtuel entre deux desdits noeuds de routage.

L'invention propose en outre un système de télécommunication composé d'une pluralité de noeuds de routage et d'au moins un contrôleur de réseau , les noeuds de routage comprenant des moyens pour mettre en oeuvre le procédé ci-avant, et le contrôleur comprenant des moyens pour mettre à jour les tables de configurations mémorisées par les noeuds de routage. Selon un mode de réalisation avantageux, le contrôleur est configuré pour mettre à jour les tables de routage en utilisant le protocole OpenFlow. Le contrôleur de réseau et un des noeuds de routage peuvent être implémentés au sein d'un même équipement. D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit donnée à titre illustratif et non limitatif, faite en regard des dessins annexés parmi lesquels : les figures lA à 1C illustrent le principe de la virtualisation de réseaux ; la figure 2 donne un exemple d'architecture de réseau et introduit la manière dont le protocole normalisé OpenFlow peut être utilisé ; la figure 3 illustre schématiquement les étapes d'un procédé d'allocation de ressources à des réseaux virtuels ; les figures 4A à 4E illustrent un exemple de création de réseau virtuel selon un premier mode de réalisation de l'invention ; et les figures 5A et 5B illustrent un exemple de création de réseau virtuel selon un deuxième mode de réalisation de l'invention.

On se réfère tout d'abord aux figures 1A à 1C qui illustrent le principe de la virtualisation de réseaux. La figure 1A illustre un exemple de réseau de télécommunication comprenant une infrastructure composée de six noeuds de routage 101 à 106. Chacun de ces noeuds de routage peut échanger directement (liens 107 à 115) des données numériques avec trois autres noeuds de routage du réseau grâce à la mise en oeuvre des protocoles et ressources physiques adaptés. Ainsi, le noeud de routage 101 peut échanger directement (liens 107, 108 et 113) des données numériques avec les trois noeuds de routage 102, 104 et 106. Sur la base de cette infrastructure, plusieurs réseaux virtuels peuvent être créés.

Par exemple, comme illustré sur la figure 1B, on peut créer un premier réseau virtuel 116 composé de cinq noeuds de routage 101, 102, 104, 105, 106 sélectionnés parmi les six noeuds de routage de l'infrastructure du réseau de télécommunication. Des tunnels virtuels 117 à 122 sont alors configurés pour permettre aux noeuds de routage ainsi sélectionnés d'échanger des données entre eux. La figure 1C illustre un second réseau virtuel 123 se basant sur l'infrastructure du réseau présenté à la figure 1A. Pour le composer, cinq noeuds de routage 101 à 105 sont sélectionnés et six liens virtuels 124 à 129 sont configurés entre ces noeuds. Pour ces deux réseaux virtuels 116 et 123, des noeuds de routage sont utilisés simultanément à la fois pour l'un et pour l'autre. Il est donc nécessaire de partager les ressources de ces noeuds de routage entre les deux réseaux virtuels 116 et 123 auxquels ils sont alloués, que ce soit les ressources de traitement intrinsèques aux noeuds eux-mêmes ou les ressources relatives aux liens virtuels reliant ces noeuds communs aux deux réseaux. On se réfère maintenant à la figure 2, qui donne un exemple d'architecture de réseau et introduit la manière dont le protocole normalisé OpenFlow (marque déposée) peut être utilisé. L'architecture ainsi présentée comprend cinq noeuds de routage 200 à 204 situés dans un plan de transport tel que défini dans ce protocole, ainsi qu'un contrôleur de réseau 205, situé dans un plan de contrôle tel que défini dans ce protocole. Les noeuds de routage comprennent notamment des moyens de transmission permettant l'échange de données avec un autre noeud de routage ou le contrôleur de réseau, ainsi que des moyens de traitement (typiquement un processeur de traitement de données, associé à une mémoire vive et une mémoire morte aptes à mémoriser notamment une table de configuration telle que décrite ci-après) configurés pour mettre en oeuvre le procédé décrit par la suite. Le contrôleur de réseau comprend également des moyens de transmission permettant l'échange de données avec chacun des noeuds de routage ainsi que des moyens de traitement (typiquement un processeur de traitement de données associé à une mémoire vive et une mémoire morte) pour la mise en oeuvre du procédé décrit par la suite. Une table de configuration est mémorisée dans chaque noeud de routage. Cette table de configuration contient un ensemble de champs permettant d'identifier les flux de données reçus par les noeuds et de router ces flux vers d'autres noeuds suivant des règles prédéfinies par cette table. Le protocole OpenFlow permet notamment de programmer les tables de configuration ainsi mémorisées. Il est alors possible de contrôler différents flux en choisissant intelligemment les chemins empruntés par les paquets leur étant associés et la manière dont ils sont traités.

En d'autres termes, le protocole OpenFlow permet de créer différents réseaux virtuels par la programmation, via un contrôleur 205, des tables de configuration mémorisées dans les noeuds de routage. La mise en place de réseaux virtuels permet de partager les ressources matérielles et donc d'améliorer la rentabilité pour l'opérateur du réseau. Le procédé selon l'invention introduit un mécanisme prenant en compte le type de service associé aux flux de données de manière à permettre une gestion optimisée de la capacité des réseaux virtuels en fonction des besoins associés à ces services. Avantageusement, un opérateur de télécommunication mettant en oeuvre l'invention dans son réseau peut ensuite contrôler finement la priorité des services les uns par rapport aux autres en jouant notamment sur la quantité de ressources allouées aux différents réseaux virtuels actifs.

L'invention s'appuie sur une infrastructure de réseau composée de noeuds de routage. L'infrastructure peut également comprendre au moins un contrôleur de réseau. Un noeud de routage réalise notamment des fonctions de routage et d'allocation de ressources. Un contrôleur de réseau est un équipement permettant notamment de configurer les noeuds de routage du réseau. L'invention peut être mise en oeuvre au sein d'un réseau dans lequel les noeuds de routage et les contrôleurs correspondent à des équipements distincts les uns des autres. Dans un mode de réalisation alternatif, l'infrastructure peut comporter au moins un équipement jouant le rôle à la fois de noeud de routage et de contrôleur. Dans un but de simplification de l'exposé, le principe de l'invention est décrit ci-après en prenant l'hypothèse que les noeuds de routage et les contrôleurs de réseau sont implémentés dans des équipements distincts. On se réfère maintenant à la figure 3, qui illustre schématiquement les étapes d'un procédé d'allocation de ressources à des réseaux virtuels selon l'invention. Pour un flux de données associé à un service donné, un réseau virtuel est créé en lui allouant une partie des ressources disponibles dans l'infrastructure du réseau. Pour cela le mécanisme d'allocation tient compte du type de service associé au flux de données. Le type de service correspond à la qualité de service requise pour la transmission du flux, c'est-à-dire à des paramètres comme la tolérance en termes de pertes de paquets, le délai maximum entre l'émission et la réception d'un paquet, ainsi que d'autres paramètres bien connus de l'homme du métier. Selon un aspect de l'invention, la notion de type de service est prise en compte par les noeuds de routage du réseau en analysant les entêtes des paquets du flux. Dans un mode de réalisation préféré, le champ ToS, acronyme venant de l'expression anglo-saxonne « Type of Service », est utilisé à cette fin. Ce champ, indicatif du type de service associé à un flux de données, est inclus dans l'entête IP des paquets et contient des informations relatives à la qualité de service requise pour la transmission du flux de données. Au préalable, le contrôleur transmet aux différents noeuds de routage du réseau des tables de configuration, lesquelles sont alors mémorisées dans les différents noeuds de routage du réseau. Une table de configuration contient un ensemble de règles d'allocations à suivre lors la mise en place de réseaux virtuels. Une fois ces règles définies, le procédé selon l'invention exécuté par les noeuds de routage permet cette allocation de ressources. Une table de configuration peut notamment comprendre plusieurs valeurs de champ ToS auxquelles sont associées un ensemble de règles d'allocation. Ces tables de configuration sont par exemple initialement programmées par l'opérateur du réseau de télécommunication. Lorsqu'un noeud de routage donné reçoit (étape 300) un ou plusieurs paquet appartenant à un flux de données, il analyse (étape 301) ces paquets de manière à déterminer le type de service leur étant associé, donc qui est associé au flux de données, par exemple en extrayant la valeur du champ ToS dans ces paquets. La table de configuration mémorisée dans le noeud de routage est alors consultée (étape 302) afin de vérifier si un réseau virtuel existe déjà pour ce type de service, auquel cas ce réseau virtuel existant est utilisé pour la transmission des paquets du flux. Si, au contraire, ces paquets sont associés à un service pour lequel il n'existe pas encore de réseau virtuel, le noeud de routage alloue (étape 303) alors un ensemble de ressources, afin de participer à la création d'un nouveau réseau virtuel destiné à supporter ce service en transportant le flux de données, et ce en suivant les règles définies dans sa table de configuration. Les ressources allouées par un noeud de routage à la création d'un réseau virtuel correspondent, d'une part, à des ressources relatives à un tunnel virtuel vers un autre noeud de routage du réseau par lequel les paquets de données du flux de données transitent pour fournir le service requis. De telles ressources peuvent correspondre à l'ensemble des ressources du tunnel virtuel lui-même, dans son intégralité, lorsque l'on souhaite réserver l'ensemble du tunnel virtuel entre deux noeuds de routage au seul service requis par l'intermédiaire du flux reçu. Alternativement, ces ressources peuvent correspondre à une portion des ressources du tunnel virtuel. Ainsi, lorsque le tunnel virtuel entre les deux noeuds dispose d'une bande passante maximale, d'un débit maximal ou d'une capacité maximale, les ressources en question correspondent à une portion de ces paramètres, qui peut dépendre du type de service indiqué dans le champ des paquets. Ainsi, à titre d'exemple, pour un tunnel virtuel présentant une bande passante de 200 Mbit/s, des ressources minimums correspondant à 4 Mbits peuvent être allouées à un type particulier de service tel que le vidéo, et utilisées par les flux de données engendrés par ce service. En outre, les ressources allouées par un noeud de routage à la création d'un réseau virtuel peuvent correspondre, d'autre part, à des ressources de traitement intrinsèques au noeud de routage, utilisées pour mettre en place une instance de traitement servant à la création du réseau virtuel. De telles ressources de traitement peuvent typiquement correspondre à des ressources calculatoires et de mémoire du noeud de routage. Tout comme pour les ressources relatives à un tunnel virtuel, une portion plus ou moins grande de ces ressources de traitement peut être alloué au flux reçu, en fonction du type de service requis par ce flux, en fonction de règles associées à la valeur du champ ToS du flux dans la table de configuration. Si la valeur du champ ToS extraite des paquets reçus du flux n'a pas d'équivalent dans la table de configuration d'un noeud de routage, plusieurs alternatives peuvent être envisagées : - Une première alternative consiste à définir au préalable, dans la table de configuration, une règle d'allocation par défaut pour les valeurs de champ ToS non reconnues. Cette règle d'allocation est alors utilisée pour allouer des ressources lors de la réception de paquets associés à un type de service non reconnu. - Une deuxième alternative consiste à ce que le noeud de routage envoie un message à un contrôleur de réseau, lequel lui retourne alors, en temps réel, une règle d'allocation mémorisée préalablement dans le contrôleur de réseau. - Dans une troisième alternative, le service associé au flux de données est tout simplement rejeté. - Dans une quatrième alternative, le flux est considéré comme étant un flux associé à la valeur du champ ToS le moins prioritaire de la table de configuration. Une fois que ces ressources sont allouées à un nouveau réseau virtuel, les paquets du flux transitent dans ce réseau virtuel en utilisant aussi bien les ressources des tunnels virtuels que les instances de traitement allouées au flux. L'introduction de nouveaux services est ainsi simplifiée par une gestion dynamique des réseaux virtuels. En effet, le nouveau réseau virtuel ne se voit alloué que les ressources nécessaires pour supporter le trafic du ou des services qui lui sont associés. En outre, ce mécanisme présente l'avantage déterminant de permettre une libération rapide des ressources allouées ce qui est équivalent à une suppression rapide des réseaux virtuels mal utilisés. Pour cela, différents mécanismes peuvent être mis en oeuvre. Par exemple, pour un flux de données transporté par un réseau virtuel, lorsqu'aucun paquet de ce flux n'est reçu durant une durée dite d' « observation », qui peut être une durée prédéterminée de l'ordre d'une heure à titre d'exemple non limitatif, par l'un des noeuds de routage utilisé par ce réseau virtuel, la ressource allouée par ce noeud de routage à ce réseau virtuel est libérée. Pour implémenter ce mode de réalisation, les différents noeuds de routage du réseau virtuel mis en place pour ce service peuvent incrémenter un compteur temporel, appelé « timer » en anglais, lorsqu'aucun paquet n'est reçu. Au delà d'un certain seuil, correspondant à la durée d'observation susmentionnée, les noeuds de routage libèrent les canaux virtuels et les instances de traitement qu'ils ont eux même réservés. Ces ressources peuvent alors être allouées à d'autres réseaux virtuels associés à d'autres services. L'utilisation des ressources de l'infrastructure de réseau est alors optimisée dynamiquement. On se réfère maintenant aux figures 4A à 4E qui donnent un exemple de création de réseau virtuel selon un premier mode de réalisation de l'invention.

Dans cet exemple, l'infrastructure du réseau 405 comprend un contrôleur 400 et quatre noeuds de routage 401 à 404 disposant chacun d'une certaine quantité de ressources de traitement (par exemple quatre unités de traitement CPU et une mémoire vive de dix giga-octets par noeud). Dans un premier temps, comme illustré sur figure 4A, le contrôleur 400 configure les noeuds de routage 401 à 404 en leur envoyant des messages de configuration respectifs 411 à 414 contenant notamment des tables de configuration, transmises par exemple en utilisant le protocole OpenFlow. Cette phase préalable de configuration a pour fonction de transmettre à chaque noeud de routage une table de configuration faisant correspondre une ou plusieurs valeur de champ ToS à un ensemble de ressources à réserver, notamment à une ressource associée à un tunnel virtuel et une instance de traitement, lorsque cela est nécessaire. A titre d'exemple, une valeur ToS1 du champ ToS peut être associée, dans une telle table de configuration, à la réservation d'une instance de traitement utilisant une unité de traitement CPU et deux-cents méga-octets de mémoire vive. En outre, la valeur ToS1 peut être associée à la création d'un tunnel virtuel, dont les caractéristiques sont également fournies dans la table de configuration, et la réservation d'au moins une partie des ressources de ce tunnel virtuel, par exemple une partie du débit maximal disponible sur ce tunnel virtuel. Suite à cette phase préalable de configuration, comme illustré à l'aide de la figure 4B, les premiers paquets d'un flux F de données arrivent (étape 421) au niveau du premier noeud de routage 401. Ce noeud de routage 401 analyse alors les entêtes IP des paquets reçus, afin d'en déduire le champ ToS du flux. Il se trouve que ce flux F est un flux de données dont la valeur de champ ToS est ToS1, i.e. un flux de données selon un type de service associé à cette valeur ToS1. Le premier noeud de routage 401 consulte alors sa table de configuration, afin de voir si une entrée correspondant à cette valeur ToS1 existe, ce qui est le cas dans cet exemple.

La création d'un nouveau réseau virtuel est alors entamée, car aucun réseau virtuel n'existe à ce stade pour supporter le service associé à la valeur ToS1. Le premier noeud de routage 401, connaissant les règles lui permettant contribuer à la configuration de ce nouveau réseau virtuel, crée donc une première instance de traitement 431, en réservant une partie de ses ressources de traitement au traitement du flux F (i.e. une unité de traitement CPU et deux- cents méga-octets de mémoire vive) selon ce qui est indiqué dans la table de configuration. Le premier noeud 401 initie en outre la création d'un tunnel virtuel 441, lui permettant de router les paquets du flux F vers un deuxième noeud 402, et alloue des ressources associées à ce premier tunnel virtuel 441 (typiquement, une partie de la capacité ou du débit maximal de ce tunnel virtuel) à la transmission des paquets de données de ce flux F, selon ce qui est indiqué dans sa table de configuration. Comme illustré sur la figure 4C, les premier paquets reçus par le premier noeud 401 sont alors transmis (étape 422), au moyen du tunnel virtuel 441 et des ressources de ce tunnel allouées au flux F, vers le deuxième noeud 402. Comme pour le premier noeud 401, le deuxième noeud 402 récupère la valeur ToS1 du champ ToS de ces paquets, et détermine quelles sont les règles de configuration du nouveau réseau virtuel en consultant la table de configuration qu'il a mémorisée. Le deuxième noeud 402 crée alors une seconde instance de traitement 432, correspondant à la réservation d'une partie des ressources de traitement de ce deuxième noeud 402 (e.g. une unité de traitement CPU sur les quatre disponibles et à deux-cents méga-octets de mémoire vive) selon sa table de configuration. En outre, le deuxième noeud 402 initie la création d'un deuxième tunnel virtuel 442 vers le troisième noeud de routage 403, et alloue des ressources associées à ce deuxième tunnel à la transmission du flux F, en fonction de ce qui est indiqué dans sa table de configuration, permettant ainsi au deuxième noeud 402 de router les paquets du flux F vers ce troisième noeud 403.

Comme illustré sur la figure 4D, les premier paquets du flux F sont alors transmis (étape 423) par le deuxième noeud 402, au moyen du deuxième tunnel virtuel 442 et des ressources de ce tunnel allouées au flux F, vers le troisième noeud 403. Comme pour les précédents noeuds 401 et 402, ce troisième noeud 403 récupère la valeur ToS1 du champ ToS de ce paquet et détermine les règles de configuration du nouveau réseau virtuel à l'aide de la table de configuration qu'il a mémorisé préalablement. Ce troisième noeud 403 crée à son tour une troisième instance de traitement 433, correspondant à la réservation d'une partie des ressources de ce troisième noeud 403 (e.g. une unité de traitement CPU sur les quatre disponibles et à deux-cents méga-octets de mémoire vive) en fonction de sa table de configuration. En outre, le troisième noeud 403 initie la création d'un troisième tunnel virtuel 443 vers le quatrième noeud de routage 404, et alloue des ressources associées à ce troisième tunnel à la transmission du flux F en fonction de ce qui est indiqué dans sa table de configuration, permettant ainsi au troisième noeud 403 de router les paquets du flux F vers ce quatrième noeud 404 au moyen de ce tunnel virtuel.

Enfin, et comme illustré à l'aide de la figure 4E, les premiers paquets du flux de données ToS1 arrivent au niveau du quatrième noeud de routage 404 (étape 424). Comme pour les noeuds précédents 401, 402 et 403, le quatrième noeud 404 récupère la valeur ToS1 du champ ToS des premiers paquets du flux F et détermine les règles de configuration du nouveau réseau virtuel, en consultant sa table de configuration mémorisée. Le noeud 404 crée alors une quatrième instance de traitement 434, correspondant à la réservation d'une partie des ressources de ce quatrième noeud 404 (e.g. une unité de traitement CPU sur les quatre disponibles et à deux-cents méga-octets de mémoire vive). Les règles de configuration obtenues à partir de sa table de configuration indiquent ensuite à ce noeud 404 qu'il doit transmettre les paquets de ce flux F à l'extérieur de l'infrastructure de réseau (étape 425), par exemple vers le terminal ou le réseau du destinataire du flux, sans recourir à l'établissement d'un tunnel virtuel. Les paquets suivants du flux F transitent ensuite par ces noeuds 401 à 404 en utilisant aussi bien les instances de traitement 431 à 434 réservées au flux F que les ressources allouées à ce flux F dans les tunnels virtuels 441 à 443.

Ce premier mode de réalisation met ainsi en évidence la création de proche en proche d'un réseau virtuel, composé de trois tunnels virtuels 441 à 443 dont une partie au moins des ressources sont réservées, et utilisant quatre instances de traitement au niveau des quatre noeuds 401 à 404, en tenant compte des besoins spécifiques associés au flux F, en fonction du type du service associé à ce flux F tel que décrit par la valeur ToS1.

Seules les ressources de traitement et de tunnel virtuel nécessaires au support du service ont été allouées. De plus, le réseau virtuel ainsi construit peut être libéré à tout moment comme explicité précédemment. Les noeuds 401 à 404 peuvent par exemple incrémenter un compteur temporel et libérer les ressources associées aux trois tunnels virtuels 441 à 443, ainsi que les quatre instances de traitement 431 à 434 qu'ils ont eux-mêmes réservés. Ces ressources peuvent alors être allouées à d'autres réseaux virtuels associés à d'autres services. On se réfère maintenant aux figures 5A et 5B qui illustrent un exemple de création de réseau virtuel selon un deuxième mode de réalisation de l'invention.

Dans cet exemple, l'infrastructure du réseau 405 comprend un contrôleur 400 et quatre noeuds de routage 401, 402, 403 et 404, similairement à ce qui a été décrit précédemment, lesquels ont pu mettre en oeuvre une phase préalable de configuration telle que décrite en relation avec la figure 4A. Suite à cette phase préalable de configuration, comme illustré à l'aide de la figure 5A, les premiers paquets d'un flux F de données arrivent (étape 511) au niveau du premier noeud de routage 401. Ce premier noeud 401 analyse alors les entêtes IP des paquets reçus, afin d'en extraire la valeur du champ ToS du flux, ici la valeur ToS1, afin de déterminer le type de service associé au flux F. Le premier noeud 401 consulte ensuite sa table de configuration pour déterminer les ressources requises pour ce services, telles que définies en correspondance à la valeur ToS1 dans cette table, notamment les ressources associées à un premier tunnel virtuel reliant le noeud 401 au noeud suivant 402, telles qu'un débit minimal ou une capacité minimale sur le lien entre ces deux noeuds, ainsi que les ressources de traitement (i.e. capacités de traitement de données, mémoire disponible) au niveau du premier noeud 401 lui-même.

Le premier noeud 401 vérifie alors si ces ressources sont disponibles. Lorsqu'aucune ressource n'est disponible pour ce type de service, le premier noeud 401 arrête le processus de création de réseau virtuel à ce stade, sans qu'il n'y ait aucune réservation inutile de ressource, et envoie un message au contrôleur 400 afin de l'informer de cette situation. Par contre, si les ressources indiquées dans la table pour ce type de service sont disponibles, le premier noeud 401 informe le contrôleur 400 de cette situation et transmet ces premiers paquets vers le deuxième noeud 402 (étape 512), sans réserver à ce stade ces ressources. Après réception de ces premiers paquets du flux F, le deuxième noeud 402 procède similairement au noeud 401, i.e. il analyse les entêtes des paquets reçus, afin d'en extraire la valeur du champ ToS du flux (ici la valeur ToS1) indiquant le type de service associé au flux, consulte sa table de configuration pour déterminer les ressources requises associées au service correspondant à cette valeur ToS1, notamment les ressources associées à un deuxième tunnel virtuel reliant le noeud 402 au noeud suivant 403 ainsi qu'éventuellement des ressources de traitement au niveau du deuxième noeud 402 lui-même, et vérifie la disponibilité de ces ressources.

Si ces ressources sont disponibles pour ce type de service au niveau du deuxième noeud 402, ce deuxième noeud 402 en informe à son tour le contrôleur 400 et transmet les premiers paquets du flux F vers le troisième noeud 403 (étape 513). Après réception de ces premiers paquets du flux F, le troisième noeud 403 procède similairement aux noeuds 401 et 402, i.e. il analyse les entêtes des paquets reçus, afin d'en extraire la valeur ToS1 du champ ToS de ces paquets, consulte sa table de configuration pour déterminer les ressources requises associées au service correspondant à cette valeur ToS1, notamment les ressources associées à un troisième tunnel virtuel reliant le noeud 403 au noeud suivant 404 ainsi qu'éventuellement des ressources de traitement au niveau du troisième noeud 403 lui-même, et vérifie la disponibilité de ces ressources.

Si ces ressources sont disponibles pour ce type de service au niveau du troisième noeud 403, ce troisième noeud 403 en informe le contrôleur 400 et transmet les premiers paquets du flux F vers le quatrième noeud 404 (étape 514). Après réception de ces premiers paquets du flux F, le quatrième noeud 404 procède similairement aux noeuds 401 à 403, et analyse les entêtes des paquets reçus, afin d'en extraire la valeur ToS1 du champ ToS de ces paquets, consulte sa table de configuration pour déterminer les ressources requises associées au service correspondant à cette valeur ToS1, notamment les ressources de traitement au niveau du quatrième noeud 404 lui-même, et vérifie la disponibilité de ces ressources. Ce quatrième noeud 404 étant le dernier noeud par lequel transite le flux F dans l'architecture 405, sa table de configuration ne lui indique pas de ressource à réserver par rapport à un éventuel tunnel virtuel, les paquets du flux F étant alors transmis vers le terminal ou le réseau du destinataire du flux sans recourir à un tunnel virtuel. Ensuite, comme illustré sur la figure 5B, lorsque le contrôleur 400 détermine que tous les noeuds 401 à 404 par lesquels transitent les premiers paquets du flux F ont des ressources disponibles associées à des tunnels virtuels, ainsi qu'à des ressources de traitement intrinsèques aux noeuds 401 à 404, il transmet à ces différents noeuds un message d'allocation de ces ressources (étape 515), afin de créer instantanément un réseau virtuel permettant le transport du flux F. Sur réception d'un tel message de réservation, chaque noeud réserve les ressources disponibles pour l'établissement d'un tunnel virtuel vers le noeud suivant, ainsi que des ressources de traitement intrinsèques à ce noeud, telles que déterminées précédemment lors de la vérification faisant suite à la réception des premiers paquets du flux F. Les tunnels virtuels 521 à 523, ainsi que les instances de traitement 531 à 534, sont ainsi réservés instantanément suite à l'envoi des messages de réservation, et le réseau virtuel destiné à transporter le flux F est construit en une seule fois, après vérification de la disponibilité de ressources sur l'ensemble du réseau virtuel ainsi créé. Par la suite, une fois que le service associé au flux F se termine, les noeuds de routage libèrent aussi bien les ressources de traitement intrinsèques utilisées par les instances de traitement 531 à 534 que les ressources associées aux tunnels virtuels 521 à 523 et informent le contrôleur 400 de la libération de ces ressources, ce qui permet à l'opérateur de l'infrastructure réseau de suivre en temps réel l'évolution des besoins en ressources, par exemple suite à l'introduction de nouveaux services, et de réaffecter notamment des ressources ainsi libérées à ces nouveaux services.

Claims

REVENDICATIONS1- Procédé d'allocation de ressources pour la mise en oeuvre d'un réseau virtuel dans un réseau de télécommunication comprenant une pluralité de noeuds de routage (401,402,403,404), le procédé comprenant les étapes suivantes, mises en oeuvre par au moins un desdits noeuds de routage : réception (300) de paquets d'un flux de données munis d'une entête comprenant un champ indiquant le type de service auquel est associé ledit flux ; et allocation (303) au flux de données, en fonction de la valeur dudit champ, d'au moins une ressource relative à un tunnel virtuel vers un autre desdits noeuds de routage.
2- Procédé selon la revendication 1, dans lequel, outre ladite au moins une ressource relative à un tunnel virtuel, une ressource de traitement comprenant une partie des ressources calculatoire et de la mémoire du noeud de routage est allouée au flux de données.
3- Procédé selon la revendication 1 ou 2, dans lequel les étapes de réception de paquets et d'allocation de ressource sont mises en oeuvre successivement par chacun desdits noeuds de routage par lesquels transite les paquets du flux de données.
4- Procédé selon la revendication 1 ou 2, comprenant en outre la vérification, pour chacun desdits noeuds de routage par lesquels transitent les paquets du flux de données, de la disponibilité de ladite au moins une ressource suite à la réception des paquets du flux de données ; l'allocation de ladite au moins une ressource étant mise en oeuvre après vérification de la disponibilité de ladite au moins une ressource par l'ensemble desdits noeuds de routage par lesquels transitent les paquets du flux de données.
5- Procédé selon la revendication 4, dans lequel : après vérification de la disponibilité de ladite au moins une ressource, lesdits noeuds de routage envoient un message à un contrôleur de réseau (400) indiquant si ladite au moins une ressource est disponible ; et lorsque l'ensemble desdits noeuds de routage par lesquels transitent les paquets du flux de données ont indiqué qu'au moins une ressource est disponible, envoi (515)du contrôleur de réseau auxdits noeuds de routage d'un message d'allocation de ladite au moins une ressource au flux de données.
6- Procédé selon l'une des revendications 1 à 5, dans lequel ladite au moins une ressource relative à un tunnel virtuel est une partie de la bande passante, du débit maximal ou de la capacité maximale dudit tunnel virtuel.
7- Procédé selon l'une des revendications 1 à 6, dans lequel le champ indiquant le type de service est le champ ToS de l'entête IP des paquets du flux de données.
8- Procédé selon l'une des revendications 1 à 7, dans lequel ladite au moins une ressource allouée est libérée lorsqu'aucun paquet du flux de données n'a été reçu pendant une durée d'observation.
9- Procédé selon la revendication 1 à 8, dans lesdits noeuds de routage contiennent une table de configuration dans laquelle est mémorisée une correspondance entre au moins une valeur dudit champ et au moins une ressource relative à un tunnel virtuel vers un autre desdits noeuds de routage, le procédé comprenant en outre, suite à la réception des paquets du flux de données, la consultation de la table de configuration afin de déduire la ressource relative à un tunnel allouée en fonction de ladite correspondance.
10- Procédé selon la revendication 9, dans lequel une règle d'allocation, définie par défaut dans la table de configuration, est utilisée pour allouer ladite au moins une ressource lorsque la valeur dudit champ n'a pas d'équivalent dans ladite table de configuration.
11- Procédé selon la revendication 9, dans lequel un message est envoyé à un contrôleur de réseau (400) lorsque la valeur dudit champ n'a pas d'équivalent dans la table de configuration, ledit contrôleur (400) retournant au noeud de routage une règle d'allocation à utiliser pour allouer ladite au moins une ressource.
12- Noeud de routage (401, 402, 403, 404) comprenant des moyens pour mettre en oeuvre le procédé selon l'une des revendications 1 à 11.
13-Contrôleur de réseau (400) comprenant des moyens pour initialiser et mettre à jour des tables de configuration mémorisées dans des noeuds de routage appartement à un réseau de télécommunication, lesdites tables de configuration mémorisant une correspondance entre au moins une valeur d'un champ, présent dans les entêtes depaquets d'un flux de données et indiquant le type de service auquel est associé ledit flux, et au moins une ressource relative à un tunnel virtuel entre deux desdits noeuds de routage.
14- Système de télécommunication composé d'une pluralité de noeuds de routage (401,402,403,404) et d'au moins un contrôleur de réseau (400), lesdits noeuds de routage comprenant des moyens pour mettre en oeuvre le procédé selon l'une des revendications 1 à 11, et le contrôleur (400) comprenant des moyens pour mettre à jour les tables de configurations mémorisées par les noeuds de routage.
15- Système de télécommunication selon la revendication 14, dans lequel le contrôleur de réseau est configuré pour mettre à jour les tables de configuration en utilisant le protocole OpenFlow.