FR2859340A1 - Transmission de trafic multipoint au sein d'un reseau de communication - Google Patents
Transmission de trafic multipoint au sein d'un reseau de communication Download PDFInfo
- Publication number
- FR2859340A1 FR2859340A1 FR0310284A FR0310284A FR2859340A1 FR 2859340 A1 FR2859340 A1 FR 2859340A1 FR 0310284 A FR0310284 A FR 0310284A FR 0310284 A FR0310284 A FR 0310284A FR 2859340 A1 FR2859340 A1 FR 2859340A1
- Authority
- FR
- France
- Prior art keywords
- multipoint
- point
- flag
- routing information
- traffic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
- H04L12/1877—Measures taken prior to transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/16—Multipoint routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/52—Multiprotocol routers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Equipement de réseau, comportant des moyens de routage point-à-point (OSPF, RIP, PR), et des moyens de routage multipoint (PIM-SM), caractérisé en ce que les moyens de routage point-à-point sont aptes à associer aux routes (R1) ajoutées dans la base de routes, un drapeau (F1) indiquant si cette route peut supporter un trafic multipoints ou non, contenu dans les informations d'acheminement, et les moyens de routage multipoint sont prévus pour choisir la meilleure route uniquement parmi les routes associées à un drapeau indiquant qu'elle peut supporter un trafic multipoint.
Description
<Desc/Clms Page number 1>
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.
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
<Desc/Clms Page number 2>
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
<Desc/Clms Page number 3>
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.
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,
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,
<Desc/Clms Page number 4>
# 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 ,
<Desc/Clms Page number 5>
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 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
<Desc/Clms Page number 6>
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.
RDB, par exemple du fait de la rupture d'un lien physique entre deux routeurs ou de la panne d'un routeur.
<Desc/Clms Page number 7>
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
<Desc/Clms Page number 8>
- 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.
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 .
<Desc/Clms Page number 9>
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.
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
<Desc/Clms Page number 10>
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 .
<Desc/Clms Page number 11>
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.
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.
<Desc/Clms Page number 12>
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.
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 )
00 # b ( both )
01 # u ( Unicast )
10 # m ( Multicast )
<Desc/Clms Page number 13>
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
<Desc/Clms Page number 14>
(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.
<Desc/Clms Page number 15>
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.
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 .
<Desc/Clms Page number 16>
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.
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.
Claims (12)
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
<Desc/Clms Page number 18>
(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.
<Desc/Clms Page number 19>
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 .
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0310284A FR2859340B1 (fr) | 2003-08-29 | 2003-08-29 | Transmission de trafic multipoint au sein d'un reseau de communication |
| PCT/FR2004/001694 WO2005025146A1 (fr) | 2003-08-29 | 2004-06-30 | Transmission de trafic multipoint au sein d’un reseau de communication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0310284A FR2859340B1 (fr) | 2003-08-29 | 2003-08-29 | Transmission de trafic multipoint au sein d'un reseau de communication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2859340A1 true FR2859340A1 (fr) | 2005-03-04 |
| FR2859340B1 FR2859340B1 (fr) | 2006-02-03 |
Family
ID=34130651
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0310284A Expired - Fee Related FR2859340B1 (fr) | 2003-08-29 | 2003-08-29 | Transmission de trafic multipoint au sein d'un reseau de communication |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR2859340B1 (fr) |
| WO (1) | WO2005025146A1 (fr) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9791562B2 (en) | 2007-04-24 | 2017-10-17 | Aviation Communication & Surveillance Systems, Llc | Systems and methods for providing an ATC overlay data link |
| US9465097B2 (en) | 2008-04-17 | 2016-10-11 | Aviation Communication & Surveillance Systems Llc | Systems and methods for providing ADS-B mode control through data overlay |
| EP2491691B1 (fr) * | 2009-10-22 | 2017-05-31 | Aviation Communication & Surveillance Systems LLC | Procédé de transmission d'un message de recouvrement par un signal de contrôle de trafic aérien |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6154463A (en) * | 1997-08-26 | 2000-11-28 | Lucent Technologies, Inc. | System and method for multicast conferencing and online discussion groups |
| EP1107507A2 (fr) * | 1999-12-10 | 2001-06-13 | Nortel Networks Limited | Procédé et dispositif de transfert d'information sur l'état de liaisons par multidiffusion |
| US6252856B1 (en) * | 1996-12-03 | 2001-06-26 | Nortel Networks Limited | Method and apparatus for minimizing calculations required to construct multicast trees |
| US20020001310A1 (en) * | 2000-06-29 | 2002-01-03 | Khanh Mai | Virtual multicasting |
-
2003
- 2003-08-29 FR FR0310284A patent/FR2859340B1/fr not_active Expired - Fee Related
-
2004
- 2004-06-30 WO PCT/FR2004/001694 patent/WO2005025146A1/fr active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6252856B1 (en) * | 1996-12-03 | 2001-06-26 | Nortel Networks Limited | Method and apparatus for minimizing calculations required to construct multicast trees |
| US6154463A (en) * | 1997-08-26 | 2000-11-28 | Lucent Technologies, Inc. | System and method for multicast conferencing and online discussion groups |
| EP1107507A2 (fr) * | 1999-12-10 | 2001-06-13 | Nortel Networks Limited | Procédé et dispositif de transfert d'information sur l'état de liaisons par multidiffusion |
| US20020001310A1 (en) * | 2000-06-29 | 2002-01-03 | Khanh Mai | Virtual multicasting |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2005025146A1 (fr) | 2005-03-17 |
| FR2859340B1 (fr) | 2006-02-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7675912B1 (en) | Method and apparatus for border gateway protocol (BGP) auto discovery | |
| US7080161B2 (en) | Routing information exchange | |
| RU2321959C2 (ru) | Идентификатор источника для нахождения мас-адреса | |
| JP3947471B2 (ja) | ネットワークトンネリング | |
| US7440438B2 (en) | Refresh and filtering mechanisms for LDP based VPLS and L2VPN solutions | |
| WO2018228490A1 (fr) | Procédé, dispositif et système de traversée de domaine de multidiffusion et support de stockage lisible par ordinateur | |
| US20060133390A1 (en) | Method and apparatus providing prioritized convergence in border gateway protocol | |
| US9660825B2 (en) | System and method for multi-source multicasting in content-centric networks | |
| JP4109692B2 (ja) | ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード | |
| FR2896113A1 (fr) | Methode d'assignation d'une adresse ip a un terminal et systeme de communication | |
| US10320675B2 (en) | System and method for routing packets in a stateless content centric network | |
| EP3320656B1 (fr) | Routage de paquets dynamique | |
| FR2978003A1 (fr) | Procede de routage d'un flux en mode non-stockage | |
| KR100636273B1 (ko) | 이더넷을 통한 ｍｐｌｓ 멀티캐스트 패킷 전송 장치 및 방법 | |
| US20210250275A1 (en) | System and Method for Implementing Controller Border Gateway Protocol (cBGP) | |
| WO2008074207A1 (fr) | Système de transmission de données et procédé correspondant | |
| FR2859340A1 (fr) | Transmission de trafic multipoint au sein d'un reseau de communication | |
| Shamim | Troubleshooting IP routing protocols | |
| Edwards et al. | Interdomain Multicast Routing: Practical Juniper Networks and Cisco Systems Solutions | |
| JP2002077257A (ja) | ストリーム配信ネットワークサービス方法およびシステム | |
| KR20060059073A (ko) | 캡슐화와 유니 캐스트 라우팅을 이용하는 디프 서브에서의멀티 캐스트 시스템 및 방법 | |
| EP1595362A1 (fr) | Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte | |
| FR2851705A1 (fr) | Procede de transmission des donnees reposant sur la hierarchie sonet/sdh | |
| FR2866497A1 (fr) | Controleur de bande passante, reseau et procede de gestion de sous-reseau ip | |
| US20120195320A1 (en) | Data sharing method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20070430 |