Brevet FR2859340A1 — publié le 20050304

Transmission de trafic multipoint au sein d'un réseau de communication La présente invention concerne les réseaux de communication, notamment ceux se basant sur la pile protocolaire IP (Internet Protocol). Elle est plus précisément relative à la transmission de trafic multipoint (ou multicast selon la terminologie en langue anglaise) au sein de tels réseaux. Le plus souvent, ces réseaux de communication véhiculent des flux de données entre un émetteur et un récepteur. Toutefois, la demande est croissante en services de transmission plus évolués, permettant par exemple la transmission vers plusieurs abonnées simultanément. Cette demande est notamment tirée par des applications comme la diffusion de flux vidéo, la télévision sur IP, etc. Ce mécanisme de transmission multipoint est connu de l'état de la technique. Ainsi, le RFC 1112 décrit le protocole IGMP (Internet Group Management Protocol) qui permet à des terminaux clients de s'abonner à un service de transmission multipoint. Le RFC 2362, quant-à-lui, décrit le mécanisme PIM-SM (Protocol Independent Multicast - Sparse mode) permettant l'acheminement des flux de données multipoint depuis la source vers les terminaux clients (déterminés par exemple via le protocole IGMP), d'une façon indépendante du protocole de routage utilisé pour le réseau (OSPF, RIP...). Plus concrètement, selon le mécanisme IGMP, des terminaux clients souscrivent auprès de leur noeud de réseau le plus proche, afin de recevoir le flux de données. La figure 1 illustre un tel mécanisme, dans lequel les terminaux A et B émettent des demandes d'abonnement auprès des n#uds RA et RB respectivement. Ces n#uds répercutent alors cette demande le long du réseau afin de déterminer un point d'embranchement X où le flux de données F sera dupliqué afin d'être transmis depuis la source S vers les terminaux A et B. Le protocole de routage PIM-SM permet alors à la source S d'effectivement transmettre le flux de données multipoint vers chacun des terminaux abonnés au service, A et B. A terme, du fait de l'accroissement de la demande en transmissions multipoints, les flux de données multipoints seront plus nombreux, et pourront engendrer un encombrement des réseaux de télécommunication. Cet encombrement est doublement pénalisant : - d'une part, les flux de données multipoints risquent d'être entachés d'une baisse de la qualité de service associée (baisse de la qualité de la vidéo...) - d'autre part, il peut provoquer une baisse de la qualité de service associée aux autres flux de données. Par conséquent, du point de vue de l'opérateur du réseau de communication, il est important de pouvoir davantage contrôler le mécanisme de transmission multipoints, afin d'en limiter les inconvénients, et notamment d'en limiter l'impact sur les autres flux de données. Pour ce faire, un premier objet de l'invention est un procédé de transmission de trafic multipoint au sein d'un réseau de communication, comportant # une première étape d'échanges de messages d'informations d'acheminement, entre des équipements du réseau de communication, ces informations d'acheminement représentant l'état des routes entre équipements du réseau, et # une seconde étape de transmission dudit trafic par lesdits équipements en fonction des informations d'acheminement, Ce procédé se caractérise en ce que les messages d'informations d'acheminement comportent un drapeau indiquant pour chacun des routes si celle-ci peut ou non supporter un trafic multipoint, et en ce que, lors de la seconde étape, le trafic multipoint est transmis uniquement par les routes indiquées, par le drapeau, comme pouvant supporter un trafic multipoint. Selon un mode de réalisation de l'invention, les messages d'information d'acheminement sont des LSA conformes au protocole OSPF. Selon un autre mode de réalisation de l'invention, les messages d'information d'acheminement sont des datagrammes conformes au protocole RIP. L'invention a aussi pour objet un équipement de réseau, comportant : # des moyens de routage point-à-point permettant d'échanger des messages d'information d'acheminement avec d'autres équipements de réseau, et d'enrichir une base de routes en fonction de ces informations d'acheminement, # des moyens de routage multipoint, permettant, lors de la transmission d'un flux de données, d'adresser une requête à la base de routes et d'obtenir comme réponse la meilleure route pour transmettre ledit flux de données, Cet équipement se caractérise en ce que : # les moyens de routage point-à-point sont aptes à associer aux routes ajoutées dans ladite base de routes, un drapeau indiquant si la route peut supporter un trafic multipoints ou non, contenu dans les informations d'acheminement, # les moyens de routage multipoint sont prévus pour choisir la meilleure route, uniquement parmi les routes associées à un drapeau indiquant que la route en question peut supporter un trafic multipoint. Selon un mode de réalisation de l'invention, les messages d'information d'acheminement sont des LSA conformes au protocole OSPF. Par exemple, ces LSA peuvent des LSA réseaux, conformes au protocole OSPF v2, et les drapeaux peuvent être insérés dans le champ Options desdits LSA. Alternativement, les LSA peuvent être des Intra-Area-Prefix-LSA , conformes au protocole OSPF v3, et les drapeaux peuvent être insérés dans le champ Prefix Options associé aux préfixes d'adresses contenu dans lesdits LSA. Selon un autre mode de réalisation de l'invention, les messages d'information d'acheminement sont des datagrammes conformes au protocole RIP. Par exemple, les datagrammes peuvent être conformes au protocole RIP 2, et les drapeaux peuvent être insérés dans un champ Route Tag de ce datagramme. Alternativement, les datagrammes peuvent être conformes au protocole RIPng, et les drapeaux peuvent être insérés dans un Next-Hop RTE au sein du datagramme. Selon un mode de réalisation de l'invention, le drapeau peut être codé sur 2 bits et il peut par exemple indiquer que le sous-réseau défini par les informations de routage - peut supporter du trafic point-à-point et du trafic multipoint, lorsque le drapeau vaut 00 , ne peut supporter que du trafic point-à-point, lorsque le drapeau vaut 01 , et ne peut supporter que du trafic multipoint, lorsque le drapeau vaut 10 . L'invention et ses avantages apparaîtront de façon plus claire dans la description de différentes mises en #uvre qui va suivre, en liaison avec les figures annexées La figure 1, précédemment commentée, présente le mécanisme de transmission multipoints selon l'état de la technique. La figure 2 schématise une partie de l'architecture fonctionnelle d'un routeur IP. La figure 3 illustre un réseau de communication, comportant deux sous-réseaux, mettant en relation une source de trafic multipoint et un abonné. La figure 4 montre la constitution d'un paquet de routage OSPF v2, et la mise en #uvre de l'invention pour ce protocole de routage. La figure 5 montre la constitution d'un paquet de routage OSPF v3, et la mise en #uvre de l'invention pour ce protocole de routage. La figure 6 montre la constitution d'un paquet de routage RIP v2, et la mise en #uvre de l'invention pour ce protocole de routage. La figure 7 montre la constitution d'un paquet de routage RIPng, et la mise en #uvre de l'invention pour ce protocole de routage. La figure 2 illustre de façon fonctionnelle les mécanismes de routage au sein d'un routeur IP (Internet Protocol). Une base de routes RDB mémorise l'ensemble des routes connues par le routeur. Un même routeur peut être à même d'utiliser différents protocoles de routage point-à-point (Unicast). Ici, il a été représenté des blocs fonctionnels correspondant aux protocoles OSPF (Open Shortest Path First), RIP (Routing Information Protocol) et un protocole de routage quelconque PR. Ces blocs fonctionnels forment autant de moyens de routage point-à-point. Chacun de ces blocs fonctionnels échange des messages d'informations d'acheminement (ou de routage) avec des routeurs voisins, afin de mutualiser les connaissances que chacun possède du réseau et d'enrichir réciproquement leur base de routes RDB. Ainsi, le bloc fonctionnel OSPF échange des messages de routage conformes au protocole OSPF avec les blocs fonctionnel OSPF des routeurs voisins. De même, le bloc fonctionnel RIP échange des messages de routage conformes au protocole RIP avec les blocs fonctionnel RIP des routeurs voisins. Il en irait encore de même avec d'autres protocoles de routage PR, tels par exemple, BGP (Border Gateway Protocol). Le contenu de ces messages de routage sera vu plus en détail ultérieurement. Il est ici important de noter qu'à chaque découverte d'une nouvelle route par un bloc fonctionnel, celui-ci va l'ajouter dans la base de routes RDB : ainsi, le bloc fonctionnel OSPF transmet une requête AdOSPF d'ajout d'une route dans la base de routes RDB ; le bloc fonctionnel RIP transmet une requête AdR,P d'ajout d'une route dans la base de routes RDB ; etle bloc fonctionnel PR transmet une requête AdPR d'ajout d'une route dans la base de routes RDB. Outre l'ajout d'une route nouvelle, bien sûr, les blocs fonctionnels peuvent être amenés à modifier l'état d'une route (c'est-à-dire à modifier un enregistrement dans la base RDB), voire à supprimer une route de la base RDB, par exemple du fait de la rupture d'un lien physique entre deux routeurs ou de la panne d'un routeur. Selon l'invention, les messages de routage associent aux routes, un drapeau indiquant pour chacune desdites routes si celle-ci peut ou non supporter un trafic multipoint. Aussi, lors de l'ajout d'une nouvelle route ou de la modification d'une route existante dans la base de routes RDB, les blocs fonctionnels précisent la valeur de ce drapeau qui sera associé à la route au sein de la base de route. Sur la figure 2, la base de routes RDB contient, à titre d'exemple, une ligne montrant une telle association entre une route R, et un drapeau F1. Ce drapeau peut prendre comme valeur m , u ou b . La valeur m signifie que la route associée ne peut accepter que du trafic multipoint (multicast) ; la valeur u signifie que la route ne peut accepter que du trafic point-à-point (unicast) ; et la valeur b signifie que la route peut supporter les deux types de trafic ( b pour both en anglais, c'est-àdire les deux ). Selon l'invention, donc, les blocs fonctionnels OSPF, RIP et PPR sont à même de préciser, dans leur requête en ajout ou modification de route, AdOSPF, AdRIP, AdPR, la valeur de ce drapeau. Le bloc fonctionnel PIM-SM, ou tout autre moyen de routage multipoints (Multicast) est prévu pour interroger la base de routes RDB afin de déterminer la route à utiliser pour la transmission des flux de données multipoints transitant par le routeur. Ainsi, à la réception d'un tel trafic, il transmet une requête Req à la base de routes RDB contenant des informations sur le trafic, notamment les adresses de destination du flux. La base de route RDB fournit comme réponse Rep, la meilleure route permettant de joindre les destinations indiquées. Selon l'invention, la base de route RDB sélectionne la meilleure route parmi les routes qui - correspondent aux informations fournies dans la requête Req, notamment aux adresses des destinations du flux de données. - Sont associées à drapeau ayant pour valeur m ou b . Autrement dit, selon l'invention, les routes accessibles uniquement au trafic point-à-point, sont exclues des choix possibles pour le moyen de routage multipoint. La figure 3 illustre un réseau de communication. Ce réseau permet de relier une source S d'un flux de données multipoint à un terminal client A. On suppose que le terminal A s'est convenablement abonné au service de transmission multipoint fourni par la source S, par exemple au moyen du protocole IGMP tel que présenté précédemment. Dans cet exemple, au moins deux chemins existent entre la source S et l'équipement A : un premier passe par le routeur Rus, le sous-réseau NU et le routeur RUA; le second passe par le routeur RMS, le sous-réseau NM et le routeur RMA' Afin d'optimiser son réseau, l'opérateur ne souhaite pas que le trafic multipoint passe par le sous-réseau Nu. Pour ce faire, il configure celui-ci, ainsi que les routeurs d'accès Rus et RUAI comme ne pouvant véhiculer que du trafic point-à-point. De façon classique, en soi, les routeurs Rus, RMS et Rs échangent des informations d'acheminement (autrement dit, des messages de routage), conformément à un protocole de routage tel RIP, OSPF etc. Dans un message mu, le routeur Rus peut ainsi indiquer au routeur Rs que les routes derrière lui , c'est-à-dire dans le sous-réseau NU ne peuvent véhiculer que du traffic point-à-point. Comme décrit précédemment, les moyens de routage point-à-point du routeur Rs mémorisent dans la base de routes du routeur, les routes reçues du routeur Rus en positionnant le drapeau correspondant à la valeur u . Lorsque la source S transmet un flux de données multipoint vers le terminal A, le routeur Rs sélectionnera le meilleur chemin, en excluant du choix les routes associées à une valeur de drapeau égale à u . Le trafic multipoint seront donc acheminé vers le terminal A en passant par le sous-réseau NM. A tout moment, l'opérateur peut modifier la configuration du réseau et, par exemple, reconfigurer son sous-réseau Nu afin que celui-ci puisse véhiculer du trafic multipoint. Par le jeu des échanges de messages de routage, le routeur Rs est alors informé de la modification du statut des routes du sous-réseau NU. Il met donc à jour sa base de routes, en associant de nouvelles valeurs de drapeau aux routes concernées, par exemple la valeur b (les routes peuvent véhiculer du trafic point-à-point et multipoint). Il est ainsi possible à l'opérateur du réseau de communication de contrôler par où passe le trafic multipoint, et donc d'optimiser l'usage de son réseau de communication. L'invention est susceptible de s'appliquer au protocole de routage OSPF, dans ses versions 2 et 3. OSPF v.2 (Open Shortest Path First) est défini par le RFC 2328 de l'IETF (Internet Engineering Task Force) et est adapté au protocole de transport IPv4 (Internet Protocol version 4). Il s'agit d'un protocole permettant aux routeurs d'un réseau de communication d'échanger des informations sur leurs états et sur l'état des liens connectant ses routeurs entre eux. Selon ce protocole, les informations sont transmises au moyen de LSA (Link State Advertisement) de différents types. Parmi ces types, on distingue notamment, les Network-LSA (LSA réseaux) qui véhiculent des informations sur la façon dont les réseaux (ou sous-réseaux) sont interconnectés, et leurs états. Plus précisément, ils sont transmis par un routeur ayant un rôle particulier (appelé Designated Router , Routeur désigné) et ils comportent donc de l'information relative à l'ensemble des routeurs du réseau (y compris le routeur désigné). Un LSA, network-LSA ou autres, est constitué d'un entête (header) et d'un corps de message dont le contenu peut être propre au type de LSA. La figure 4 illustre la constitution d'un tel entête, constitué de 20 octets. Il comporte tout d'abord un champ LS age indiquant le temps écoulé depuis l'émission du LSA. Le champ suivant, Options est relatif à des capacités optionnelles du protocole. Le champ LS Type précise le type de LSA. Sa valeur est à 1 dans le cas d'un LSA de type Network LSA . Le champ Link State ID identifie la portion du réseau qui va être décrite par le LSA. Dans la cas d'un Network LSA , ce champ contient l'adresse de l'interface IP du routeur désigné. Le champ suivant, Advertising Router , contient un identificateur du routeur qui a émis le LSA. Dans le cas d'un Network LSA , le champ contient l'identificateur du routeur désigné du réseau. Le champ LS sequence number identifie le LSA, parmi l'ensemble des LSA émis par un même routeur. Ce champ permet donc de détecter qu'un LSA a déjà été reçu. L'avant dernier champ, LS Checksum est un champ de contrôle d'intégrité du LSA. Enfin, le champ Length contient la longueur totale du LSA. Selon l'invention, on insère dans ces Network-LSA, un drapeau indiquant si les routes relatives à ce réseau peuvent ou non supporter un trafic multipoint. Plus précisément, ce drapeau est inséré dans le champ Options des Network LSA . Selon un mode de réalisation, le drapeau peut consister en un souschamp de ce champ Options , tenant en 2 bits, dont les valeurs possibles peuvent être ainsi affectées : 00 # b ( both ) 01 # u ( Unicast ) 10 # m ( Multicast ) Ainsi, par la transmission des LSA, le routeur désigné d'un sousréseau peut indiquer à l'ensemble du réseau, sa capacité ou non à véhiculer du trafic point-à-point et/ou multipoint. La transmission de cette information est effectuée, selon l'invention, en utilisant le protocole OSPF existant, sans modifier ce protocole, et donc avec un minimum d'impact sur l'architecture des routeurs. L'invention peut aussi s'appliquer au protocole de routage OSPF v3, adapté à la couche protocolaire IPv6. Ce protocole OSPF v3 est défini dans le RFC 2740 de l'IETF, intitulé OSPF for IPv6 . Tout comme OSPF v2 dont il est une évolution, il consiste aussi en la transmission de LSA de différents types. Il existe pour le moment 7 types de LSA : router LSA , network LSA , Inter-Area-Prefix LSA , Inter-AreaRouter LSA , AS-External-LSA , Group-membership LSA , Type-7-LSA , Link-LSA et Intra-Area-Prefix-LSA . Quelque soit le type de LSA, ils se composent d'un entête et d'un corps de message, dont le contenu varie en fonction du type de LSA. La figure 5 illustre la composition d'un LSA de type Intra-Area-PrefixLSA . Il se compose d'un entête H et d'un corps de message. L'entête H est similaire à celle d'un LSA selon OSPF v2, à l'exception du champ Options qui a disparu et du champ LS Type qui occupe 4 octets, et non plus 2 comme selon OSPF v2. Le champ suivant # prefix indique le nombre de préfixes d'adresses qui vont suivre dans le LSA. Les champs suivants, Referenced LS type , Referenced Link State ID and Referenced Advertising identifient le network LSA avec lequel les préfixes d'adresses doivent être associés. Le reste du LSA contient une liste de préfixes d'adresses IPv6. Les champs suivants peuvent donc être répétés d'un nombre de fois indiqué par le champ # Prefix décrit plus haut. Le champ Metric est similaire à celui décrit pour la mise en oeuvre sous Ipv4 et indique un coût associé à cette métrique. Le champ prefixLength indique la longueur, en bits, du préfixe d'adresse, qui est encodé dans le champ Address Prefix . Enfin, le champ PrefixOptions permet de préciser des informations optionnelles associées à ce préfixe d'adresse. Selon l'invention, on insère dans ces Intra-Area-Prefix-LSA , un drapeau indiquant si les routes relatives à ce réseau peuvent ou non supporter un trafic multipoint. Plus précisément, ce drapeau est inséré dans le champ PrefixOptions associé à chaque préfixe d'adresse contenu dans les IntraArea-Prefix-LSA . Selon un mode de réalisation, le drapeau peut consister en un souschamp de ce champ PrefixOptions , tenant en 2 bits, dont les valeurs possibles peuvent être ainsi affectées : 00 # b ( both ) 01 # u ( Unicast ) 10 # m ( Multicast ) Ainsi, par la transmission des LSA, le routeur désigné d'un sousréseau peut indiquer à l'ensemble du réseau, sa capacité ou non à véhiculer du trafic point-à-point et/ou multipoint. La transmission de cette information est effectuée, selon l'invention, en utilisant le protocole OSPF v3 existant, sans modifier ce protocole, et donc avec un minimum d'impact sur l'architecture des routeurs. Selon un autre mode de réalisation, l'invention est susceptible de s'appliquer au protocole de routage RIP, dans ses versions 2 et ng . RIP v. 2 (Routing Information Protocol) est défini par le RFC 2453 de l'IETF (Internet Engineering Task Force) et est adapté au protocole de transport IPv4 (Internet Protocol version 4). Il s'agit d'un protocole permettant aux routeurs d'un réseau de communication d'échanger des informations sur leurs états et sur l'état des liens connectant ses routeurs entre eux. Selon ce protocole, les informations sont transmises au moyen de datagrammes conformes au protocole UDP (User Datagram Protocol). La figure 6 schématise le contenu d'un tel datagramme. Le premier champ Command précise si la datagramme RIP est une requête ou bien une réponse, c'est-à-dire si l'émetteur de ce message souhaite recevoir des informations de routage de la part des routeurs voisins, ou bien s'il fournit lui-même ces informations à un ou plusieurs routeurs. Le champ Version précise la version du protocole RIP. Dans le cas de RIP v2, ce champ doit donc avoir 2 pour valeur. Le champ suivant, indiqué 0 sur la figure, doit contenir des 0 sur 2 octets. Ces trois champs forment l'entête d'un datagramme RIP. Les champs suivants forment le corps du message et ils sont regroupés en entrées RIP (RIP entry) qui sont généralement des entrées de table de routes (Route Table Entries ou RTE). Un datagramme RIP peut contenir jusqu'à 25 de ces entrées RIP . La figure annexée n'en représente qu'une seule qui est une entrée de table de routes . Le champ Address Family Identifier permet d'indiquer le type d'adresse qui va figurer dans le RTE concerné. Dans le cas d'une mise en #uvre du protocole de routage RIP v2 sur un réseau IP, cette valeur vaut 2 (AF-INET). Le champ suivant, Route Tag , est un attribut associé à la route considérée dans le RTE. Son usage est laissé libre par le RFC 2453 définissant le protocole RIP v2. Les deux champs suivants, IP address et Subnet mask permettent de préciser l'adresse du routeur ou du sous-réseau concerné par le RTE. Le champ Next Hop indique l'adresse du routeur par lequel il faut passer pour atteindre ce sous-réseau. Une valeur de 0 indique que le trafic doit être envoyé vers l'émetteur du message. Enfin, le champ Metric indique la métrique courante pour la destination, c'est-à-dire un coût associé. Chacun des routeurs implémentant RIP publie l'ensemble des sousréseau qu'il connaît, à ses voisins. Ceux-ci apprennent donc de nouveaux sous-réseaux dont ils informent leurs propres voisins. Selon l'invention, on insère dans ces datagrammes RIP v2, un drapeau indiquant si les routes relatives au sous-réseau défini par le datagramme RIP v2, peuvent ou non supporter un trafic multipoint. Plus précisément, ce drapeau est inséré dans le champ Route Tag de tous ou certains RTEs contenus dans un datagramme RIP. Selon un mode de réalisation, le drapeau peut consister en un souschamp de ce champ Route Tag , tenant en 2 bits, dont les valeurs possibles peuvent être ainsi affectées : 00 # b ( both ) 01 # u ( Unicast ) 10 # m ( Multicast ) Ainsi, par la transmission des datagrammes RIP 2, un sous-réseau peut indiquer à l'ensemble du réseau, sa capacité ou non à véhiculer du trafic point-à-point et/ou multipoint. La transmission de cette information est effectuée, selon l'invention, en utilisant le protocole RIP 2 existant, sans modifier ce protocole, et donc avec un minimum d'impact sur l'architecture des routeurs. L'invention peut aussi s'appliquer au protocole de routage RIPng, adapté à la couche protocolaire IPv6. Ce protocole RIPng (RIP Next Génération ) est défini dans le RFC 2080 de l'IETF, intitulé RIPng for IPv6 . Tout comme RIP v2 dont il est une évolution, il consiste aussi en la transmission de datagrammes basés sur le protocole UDP. La figure 7 schématise un datagramme RIPng. Les trois premiers champs, Command , Version et 0 forment l'entête du datagramme et sont similaires à ceux décrits dans le cas du protocole RIP 2. A la suite de cet entête, on trouve un ou plusieurs RTE (Route Table Entries), dont le principe est le même que précédemment pour RIP v2, à l'exception notable que l'adresse du routeur vers lequel le datagramme doit ensuite être transmis ne figure plus dans un champ de RTE, comme dans RIP v2, mais fait l'objet d'un RTE particulier, nommé Next-Hop RTE . Selon l'invention, on insère dans ces datagrammes RiPng, un drapeau indiquant si les routes relatives au sous-réseau défini dans le datagramme, peuvent ou non supporter un trafic multipoint. Plus précisément, ce drapeau est inséré dans le Next-Hop RTE contenu dans ce datagramme. Selon un mode de réalisation, le drapeau peut consister en un champ de ce Next-Hop RTE , tenant en 2 bits, dont les valeurs possibles peuvent être ainsi affectées : 00 # b ( both ) 01 # u ( Unicast ) 10 # m ( Multicast ) Ainsi, par la transmission des datagrammes RIPnp, un sous-réseau peut indiquer à l'ensemble du réseau, sa capacité ou non à véhiculer du trafic point-à-point et/ou multipoint. La transmission de cette information est effectuée, selon l'invention, en utilisant le protocole RIPng existant, sans modifier ce protocole, et donc avec un minimum d'impact sur l'architecture des routeurs. REVENDICATIONS 1) Procédé de transmission de trafic multipoint au sein d'un réseau de communication, comportant une première étape d'échanges de messages d'informations d'acheminement, entre des équipements dudit réseau de communication, lesdites informations d'acheminement représentant l'état des routes entre équipements dudit réseau, et une seconde étape de transmission dudit trafic par lesdits équipements en fonction desdites informations d'acheminement, caractérisé en ce que lesdits messages d'informations d'acheminement comportent un drapeau indiquant pour chacun desdites routes si celle-ci peut ou non supporter un trafic multipoint, et en ce que, lors de ladite seconde étape, ledit trafic multipoint est transmis uniquement par les routes indiquées, par ledit drapeau, comme pouvant supporter un trafic multipoint. 2) Procédé selon la revendication précédente, dans lequel lesdits messages d'information d'acheminement sont des LSA conformes au protocole OSPF. 3) Procédé selon la revendication 1, dans lequel lesdits messages d'information d'acheminement sont des datagrammes conformes au protocole RIP. 4) Équipement de réseau, comportant : # des moyens de routage point-à-point (OSPF, RIP, PR), permettant d'échanger des messages d'information d'acheminement avec d'autres équipements de réseau, et d'enrichir une base de routes (RDB) en fonction de ces informations d'acheminement, # des moyens de routage multipoint (PIM-SM), permettant, lors de la transmission d'un flux de données, d'adresser une requête (Req) à ladite base de routes et d'obtenir comme réponse (Rep) la meilleure route pour transmettre ledit flux de données, caractérisé en ce que : # lesdits moyens de routage point-à-point sont aptes à associer aux routes (R1) ajoutées dans ladite base de routes, un drapeau (F1) indiquant si ladite route peut supporter un trafic multipoints ou non, contenu dans lesdites informations d'acheminement, # lesdits moyens de routage multipoint sont prévus pour choisir ladite meilleure route uniquement parmi les routes associées à un drapeau indiquant que ladite route peut supporter un trafic multipoint. 5) Équipement de réseau selon la revendication 4, dans lequel lesdits messages d'information d'acheminement sont des LSA conformes au protocole OSPF. 6) Équipement de réseau selon la revendication 5, dans lequel lesdits LSA sont des LSA réseaux, conformes au protocole OSPF v2, et lesdits drapeaux sont insérés dans le champ Options desdits LSA. 7) équipement de réseau selon la revendication 5, dans lequel lesdits LSA sont des Intra-Area-Prefix-LSA , conformes au protocole OSPF v3, et lesdits drapeaux sont insérés dans le champ Prefix Options associé aux préfixes d'adresses contenu dans lesdits LSA. 8) Équipement de réseau selon la revendication 4, dans lequel lesdits messages d'information d'acheminement sont des datagrammes conformes au protocole RIP. 9) Équipement de réseau selon la revendication 8, dans lequel lesdits datagrammes sont conformes au protocole RIP 2, et lesdits drapeaux sont insérés dans un champ Route Tag dudit datagramme. 10) Équipement de réseau selon la revendication 8, dans lequel lesdits datagrammes sont conformes au protocole RIPng, et lesdits drapeaux sont insérés dans un Next-Hop RTE au sein dudit datagramme. 11) Équipement de réseau selon l'une des revendications 4 à 10, dans lequel ledit drapeau est codé sur 2 bits. 12) Équipement de réseau selon la revendication précédente, dans lequel ledit drapeau indique que le sous-réseau défini par lesdites informations de routage - peut supporter du trafic point-à-point et du trafic multipoint, lorsque ledit drapeau vaut 00 , - ne peut supporter que du trafic point-à-point, lorsque ledit drapeau vaut 01 , et - ne peut supporter que du trafic multipoint, lorsque ledit drapeau vaut 10 .