WO2005025146A1 - 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 PDF

Info

Publication number
WO2005025146A1
WO2005025146A1 PCT/FR2004/001694 FR2004001694W WO2005025146A1 WO 2005025146 A1 WO2005025146 A1 WO 2005025146A1 FR 2004001694 W FR2004001694 W FR 2004001694W WO 2005025146 A1 WO2005025146 A1 WO 2005025146A1
Authority
WO
WIPO (PCT)
Prior art keywords
protocol
route
point
flag
routing information
Prior art date
Application number
PCT/FR2004/001694
Other languages
English (en)
Inventor
Christophe Preguica
Jean-Pierre Rombeaut
Nicolas Rebierre
Original Assignee
Alcatel
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Alcatel filed Critical Alcatel
Publication of WO2005025146A1 publication Critical patent/WO2005025146A1/fr

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

Definitions

  • the present invention relates to communication networks, in particular those based on the Internet Protocol (IP) stack. More precisely, it relates to the transmission of multipoint traffic (or
  • Multicast in English terminology) within such networks. Most often, these communication networks convey data flows between a transmitter and a receiver. However, demand is growing for more sophisticated transmission services, allowing for example transmission to several subscribers simultaneously. This request is notably driven by applications such as the broadcasting of video streams, television over IP, etc.
  • RFC 1 1 12 describes the IGMP protocol (Internet Group Management Protocol) which allows client terminals to subscribe to a multipoint transmission service.
  • RFC 2362 describes the PIM-SM (Protocol Independent Multicast - Sporse mode) mechanism allowing the routing of multipoint data streams from the source to client terminals (determined for example via the IGMP protocol), independently of the routing protocol used for the network (OSPF, RIP ).
  • IGMP protocol Internet Group Management Protocol
  • PIM-SM Protocol Independent Multicast - Sporse mode
  • FIG. 1 illustrates such a mechanism, in which the
  • a first object of the invention is a method of transmitting multipoint traffic within a communication network, comprising • a first step of exchanging routing information messages, between devices of the network of
  • this routing information representing the state of the routes between devices of the network, and • a second step of transmission of said traffic by said devices as a function of routing information
  • the information messages routing include a flag indicating for each of the routes whether or not it can support multipoint traffic, and in that, during the second step, the multipoint traffic is transmitted only by the routes indicated, by the flag, as capable of supporting multipoint traffic.
  • the routing information messages are LSAs conforming to the OSPF protocol.
  • the routing information messages are datagrams conforming to the RIP protocol.
  • the invention also relates to network equipment, comprising: • point-to-point routing means making it possible to exchange routing information messages with other network equipment, and to enrich a database routes as a function of this routing information, • multipoint routing means, making it possible, when transmitting a data flow, to send a request to the route base and to obtain the best route as a response to transmit said data flow,
  • This equipment is characterized in that: • the point-to-point routing means are capable of associating with the routes added to said route base, a flag indicating whether the route can support multipoint traffic or no, contained in the routing information,
  • the routing information messages are LSAs conforming to the OSPF protocol.
  • these LSAs can be network LSAs, compliant with the OSPF v2 protocol, and flags can be inserted in the "Options" field of said LSAs.
  • the LSAs can be “Intra-Area-Prefix-LSA”, conforming to the OSPF v3 protocol, and the flags can be inserted in the “Prefix Options” field associated with the address prefixes contained in said LSAs.
  • the routing information messages are datagrams conforming to the RIP protocol.
  • datagrams can comply with the RIP 2 protocol, and flags can be inserted in a “Route Tag” field of this datagram.
  • the datagrams can conform to the RIPng protocol, and the flags can be inserted in a “Next-Hop RTE” within the datagram.
  • the flag can be coded on 2 bits and it can for example indicate that the subnetwork defined by the routing information can support point-to-point traffic and multipoint traffic, when the flag is worth "00"
  • FIG. 1 presents the multipoint transmission mechanism according to the state of the art.
  • Figure 2 schematizes part of the functional architecture of an IP router.
  • FIG. 3 illustrates a communication network, comprising two subnets, relating a source of multipoint traffic to a subscriber.
  • Figure 4 shows the constitution of an OSPF v2 routing packet, and the implementation of the invention for this routing protocol.
  • FIG. 5 shows the constitution of an OSPF v3 routing packet, and the implementation of the invention for this routing protocol.
  • Figure 6 shows the constitution of a RIP v2 routing packet, and the implementation of the invention for this routing protocol.
  • FIG. 1 previously commented on, presents the multipoint transmission mechanism according to the state of the art.
  • FIG. 3 illustrates a communication network, comprising two subnets, relating a source of multipoint traffic to a subscriber.
  • Figure 4 shows the constitution of an OSPF v2 routing packet, and the implementation of the invention for this routing protocol.
  • FIG. 5 shows the constitution of an OSPF v
  • FIG. 7 shows the constitution of a RIPng routing packet, and the implementation of the invention for this routing protocol.
  • Figure 2 illustrates functionally the routing mechanisms within an Internet Protocol (IP) router.
  • IP Internet Protocol
  • An RDB route database stores all of the routes known to the router. The same router may be able to use different point-to-point routing protocols (Unicast).
  • functional blocks have been represented
  • any P R routing protocol forms as many point-to-point routing means.
  • Each of these functional blocks exchanges routing information messages (or routing) with neighboring routers, in order to pool the knowledge that each has of the network and reciprocally enrich their RDB route base.
  • the OSPF functional block exchanges routing messages conforming to the OSPF protocol with the OSPF functional blocks of the neighboring routers.
  • the RIP functional block exchanges routing messages conforming to the RIP protocol with the RIP functional blocks of neighboring routers.
  • RDB for example due to the break of a physical link between two routers or the failure of a router.
  • the routing messages associate with the routes, a flag indicating for each of said routes whether or not it can support multipoint traffic. Also, when adding a new route or modifying an existing route in the RDB route base, the functional blocks specify the value of this flag which will be associated with the route within the route base .
  • the RDB route base contains, by way of example, a line showing such an association between a route R and a flag F ⁇
  • This flag can take as value "m", "u” or "b” .
  • the value "m” means that the associated route can only accept multipoint traffic (multicast); the value “u” means that the route can only accept point-to-point traffic (unicast); and the value "b” means that the route can support both types of traffic ("b” for "both" in English, ie "both”).
  • the OSPF, RIP and P PR functional blocks are able to specify, in their request for route addition or modification, Ad OSPF , Ad R , P , Ad PR , the value of this flag.
  • the PIM-SM functional block, or any other multipoint routing means ( ⁇ u / t / cast) is intended to interrogate the RDB route database in order to determine the route to be used for the transmission of multipoint data streams passing through the router. .
  • the RDB route base On receipt of such traffic, it transmits a Req request to the RDB route base containing information on the traffic, in particular the destination addresses of the stream.
  • the RDB route base provides Rep, the best route to reach the indicated destinations.
  • the RDB route base selects the best route among the routes which
  • Figure 3 illustrates a communication network.
  • This network makes it possible to connect a source S of a multipoint data stream to a client terminal A. It is assumed that the terminal A has properly subscribed to the multipoint transmission service provided by the source S, for example by means of the IGMP protocol. as previously presented.
  • the source S for example by means of the IGMP protocol.
  • the operator does not want multipoint traffic to pass through the subnetwork N y .
  • the routers R us , R MS and R s exchange routing information (in other words, routing messages), in accordance with a routing protocol such as RIP, OSPF etc.
  • routing information in other words, routing messages
  • the router R us can thus indicate to the router R s that the routes "behind it", that is to say in the Nu subnetwork can only carry point-to-point traffic.
  • the point-to-point routing means of the router R s store in the route base of the router, the routes received from the router R us by positioning the flag corresponding to the value "u".
  • the operator can modify the network configuration and, for example, reconfigure its Nu subnetwork so that it can carry multipoint traffic.
  • the router R s is then informed of the modification of the status of the routes of the subnetwork N y . It therefore updates its route base, by associating new flag values with the routes concerned, for example the value "b" (the routes can carry point-to-point and multipoint traffic). It is thus possible for the operator of the communication network to control where multipoint traffic passes, and therefore to optimize the use of his communication network.
  • OSPF Internet Engineering Task Force
  • IPv4 Internet Protocol version 4
  • LSA Link State Advertisement
  • LSA Network-LSA or others
  • Figure 4 illustrates the constitution of such a header, consisting of 20 bytes. First of all, it includes an “LS age” field indicating the time elapsed since the LSA was issued. The next field, “Options” relates to optional protocol capabilities.
  • the "LS Type” field specifies the type of LSA.
  • the “Link State ID” field identifies the portion of the network that will be described by the LSA. In the case of a "Network LSA”, this field contains the address of the IP interface of the designated router.
  • the next field, "Advertising Router,” contains an identifier of the router that issued the LSA. In the case of a "Network LSA", the field contains the identifier of the designated network router.
  • the “LS sequence number” field identifies the LSA, among all the LSAs sent by the same router. This field therefore makes it possible to detect that an LSA has already been received.
  • the penultimate field, "LS Checksum” is an LSA integrity control field.
  • the "Length” field contains the total length of the LSA.
  • a flag indicating whether the routes relating to this network can or cannot support multipoint traffic is inserted into these Network-LSAs. More specifically, this flag is inserted in the "Options" field of the "Network LSA".
  • the flag can consist of a sub-field of this "Options" field, holding in 2 bits, whose possible values can be thus affected: 00 ->"b"("both") 01 ->"U"("Unicast") 10 ->"m"("Multicast)
  • the designated router of a subnetwork can indicate to the entire network, its capacity or not to carry point-to-point and / or multipoint traffic.
  • the transmission of this information is carried out, according to the invention, using the existing OSPF protocol, without modifying this protocol, and therefore with a minimum impact on the architecture of the routers.
  • the invention can also be applied to the OSPF v3 routing protocol, adapted to the IPv ⁇ protocol layer.
  • This OSPF v3 protocol is defined in IETF RFC 2740, entitled "OSPF for IPv ⁇ ".
  • OSPF v2 Like OSPF v2, of which it is an evolution, it also consists in the transmission of LSAs of different types.
  • Link-LSA and "Intra-Area- Prefix- LSA”. Whatever the type of LSA, they consist of a header and a message body, the content of which varies according to the type of LSA.
  • FIG. 5 illustrates the composition of an “Intra-Area-Prefix-LSA” type LSA. It consists of an H header and a message body.
  • the header H is similar to that of an LSA according to OSPF v2, except for the "Options” field which has disappeared and the "LS Type” field which occupies 4 bytes, and no longer 2 as according to OSPF v2.
  • the rest of the LSA contains a list of IPv ⁇ address prefixes.
  • the following fields can therefore be repeated a number of times indicated by the “# Prefix” field described above.
  • the “Metric” field is similar to that described for implementation under Ipv4 and indicates a cost associated with this metric.
  • the "prefixLength” field indicates the length, in bits, of the address prefix, which is encoded in the "Address Prefix” field.
  • the "PrefixOptions” field allows you to specify optional information associated with this address prefix.
  • a flag indicating whether the routes relating to this network can or cannot support multipoint traffic is inserted into these “Intra-Area- Prefix- LSA”. More precisely, this flag is inserted in the “PrefixOptions” field associated with each address prefix contained in the “Intra-Area -Prefix- LSA”. According to one embodiment, the flag can consist of a sub-field of this "PrefixOptions” field, holding in 2 bits, whose possible values can be thus affected: 00 - "" b "(" both ") 01 -" u ”(“ Unicast ”) 10 ->“ m ”(“ Multicast ”)
  • the designated router of a subnetwork can indicate to the entire network, its capacity or not to carry point-to-point and / or multipoint traffic.
  • the transmission of this information is carried out, according to the invention, using the existing OSPF v3 protocol, without modifying this protocol, and therefore with a minimum impact on the architecture of the routers.
  • the invention is likely to apply to the RIP routing protocol, in its versions 2 and “ng”.
  • RIP v.2 (Routing Information Protocol) is defined by RFC 2453 of the IETF (Internet Engineering Task Force) and is adapted to the transport protocol
  • IPv4 Internet Protocol version 4
  • UDP User Datagram Protocol
  • Figure 6 shows schematically the content of such a datagram.
  • the first “Command” field specifies whether the RIP datagram is a request or a response, that is to say if the sender of this message wishes to receive routing information from neighboring routers, or else it itself provides this information to one or more routers.
  • the "Version” field specifies the version of the RIP protocol. In the case of RIP v2, this field must therefore have “2” as its value.
  • the next field, indicated “0" in the figure, must contain “0” on 2 bytes.
  • a RIP datagram can contain up to 25 of these
  • the next field, “Route Tag”, is an attribute associated with the route considered in the RTE. Its use is left free by RFC 2453 defining the RIP v2 protocol.
  • the next two fields, "IP address” and “Subnet mask” allow you to specify the address of the router or subnet concerned by the
  • the “Next Hop” field indicates the address of the router through which to reach this subnet. A value of 0 indicates that traffic should be sent to the sender of the message.
  • the "Metric" field indicates the current metric for the destination, that is to say an associated cost.
  • Each of the routers implementing RIP publishes all of the subnets it knows to its neighbors. They therefore learn new subnets of which they inform their own neighbors.
  • a flag is inserted into these RIP v2 datagrams indicating whether the routes relating to the subnet defined by the RIP v2 datagram can or cannot support multipoint traffic. More precisely, this flag is inserted in the “Route Tag” field of all or certain RTEs contained in a RIP datagram.
  • the flag can consist of a sub-field of this “Route Tag” field, holding in 2 bits, the possible values of which can be thus affected: 00 - “b” (“both”) 01 - “ u ”(“ Unicast ”) 10 - • “ m ”(“ Multicast ”)
  • a subnetwork can indicate to the whole network, its capacity or not to convey point-to-point and / or multipoint traffic.
  • the transmission of this information is carried out, according to the invention, using the existing RIP 2 protocol, without modifying this protocol, and therefore with a minimum impact on the architecture of the routers.
  • the invention can also be applied to the RIPng routing protocol, adapted to the IPv ⁇ protocol layer.
  • This RIPng protocol (RIP "Next Generation") is defined in IETF RFC 2080, entitled “RIPng for IPv IP”.
  • RIP v2 Like RIP v2, of which it is an evolution, it also consists in the transmission of datagrams based on the UDP protocol.
  • Figure 7 shows schematically a RIPng datagram.
  • the first three fields, "Command”, “Version” and “0” form the header of the datagram and are similar to those described in the case of the RIP 2 protocol. Following this header, we find one or more RTE ( Route Table
  • a flag is indicated in these RIPng datagrams indicating whether the routes relating to the subnetwork defined in the datagram can or cannot support multipoint traffic. More precisely, this flag is inserted in the “Next-Hop RTE” contained in this datagram. According to one embodiment, the flag can consist of a field of this "Next-Hop RTE", holding in 2 bits, whose possible values can be thus affected: 00 ->"b"("both") 01 -> “U” (“Unicast”) 10 - “m” (“Multicast”)
  • a subnetwork can indicate to the entire network, its capacity or not to carry point-to-point and / or multipoint traffic.
  • the transmission of this information is carried out, according to the invention, using the existing RIPng protocol, without modifying this protocol, and therefore with a minimum impact on the architecture of the routers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Équipement 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

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 1 1 12 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 - Sporse 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
105162/SYC/NVND L:\Salle\Fl 05162\P EMDEP\EXTENS\EXTENS.FR.doc terminaux A et B émettent des demandes d'abonnement auprès des nœuds RA et RB respectivement. Ces noeuds 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
105102/SYC/NVND L:\Salle\F105162\PREMDEP\EXTENS\EXTENS.FR.doc 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,
105162/SYC/NVND L:\Salie\F105162\PRE DEP\E)CTENS\EXTENS.FR.doc • 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 »,
105162/SYC/NVND L:\Salle\Fl 05162\PREMDEP\EXTENS\EXTENS.FR.doc 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 oeuvre 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 oeuvre 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
105102/SYC/NVND L:\Salle\F105162\PREMDEP\EXTENS\EXTENS.FR.doc 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 AdRIP d'ajout d'une route dans la base de routes RDB ; et le 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.
105162/SYC/NVND L\Salle\F1051 ό2\PREMDEP\EXTENS\E>σENS.FR.doc 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 F^ 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, AdR,P, AdPR, la valeur de ce drapeau.
Le bloc fonctionnel PIM-SM, ou tout autre moyen de routage multipoints (Λ u/t/cast) 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
105162/SYC/NVND L:\Salle\Fl 05162\PREMDEP\EXTENS\EXTENS.FR.doc 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 R S, le sous-réseau NM et le routeur R^. Afin d'optimiser son réseau, l'opérateur ne souhaite pas que le trafic multipoint passe par le sous-réseau Ny. Pour ce faire, il configure celui-ci, ainsi que les routeurs d'accès Rus et RUA, 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 ».
105162/SYC/NVND L:\Salle\F105162\PREMDEP\EXTENS\EXTENS.FR.doc 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 Ny. 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). II 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
105162/SYC/NVND L:\Salle\F105162\PREMDEP\EXTENS\EXTENS.FR.doc 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 âge » 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 séquence 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 ».
105162/SYC/NVN D L:\Salle\F 105162\PREMDEP\EXTENS\EXTENS. FR.doc Selon un mode de réalisation, le drapeau peut consister en un sous- champ 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 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 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 IPvό. Ce protocole OSPF v3 est défini dans le RFC 2740 de l'IETF, intitulé « OSPF for IPvό ». 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-Area-
Router LSA », « AS-Extemal-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-Prefix- LSA ». 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.
105162/SYC/NVND L:\Salle\F1051 o2\PREMDEP\EXTENS\EXTENS.FR.doc 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 IPvό. 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 œuvre 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 « Intra- Area -Prefix- LSA ». Selon un mode de réalisation, le drapeau peut consister en un sous- champ 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 »)
105162/SYC/NVN D L:\Salle\F 105162\PREMDEP\EXÏΕNS\EXTENS. FR.doc Ainsi, par la transmission des LSA, le routeur désigné d'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 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 »
105162/SYC/NVND L:\Salle\F105162\PREMDEP\EXTENS\EXTENS.FR.doc (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 sous- ré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.
105162/SYC/NVN D L:\Salle\Fl 051 ό2\PREMDEP\EXTENS\EXTENS. FR.doc Selon un mode de réalisation, le drapeau peut consister en un sous- champ 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 IPvό. Ce protocole RIPng (RIP « Next Génération ») est défini dans le RFC 2080 de l'IETF, intitulé « RIPng for IPvό ». 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 ».
105162/SYC/NVND L:\Salle\F105162\PREMDEP\EXTENS\EXTENS.FR.doc 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.
105162/SYC/NVND L:\Salle\F105162\PREMDEP\EXTENS\EXTENS.FR.doc

Claims

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
105162/SYC/NVND L:\SaIle\Fl 05162\PREMDEP\EXTENS\EXTENS.FR.doc (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 (R,) ajoutées dans ladite base de routes, un drapeau (F^ 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.
105162/SYC/NVND L:\Salle\F105162\PREMDEP\EXTENS\EXTENS.FR.doc 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.
1 1 ) É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 ».
105162/SYC/NVND L:\Salle\F105162\PREMDEP\EXTENS\EXTENS.FR.doc
PCT/FR2004/001694 2003-08-29 2004-06-30 Transmission de trafic multipoint au sein d’un reseau de communication WO2005025146A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR03/10284 2003-08-29
FR0310284A FR2859340B1 (fr) 2003-08-29 2003-08-29 Transmission de trafic multipoint au sein d'un reseau de communication

Publications (1)

Publication Number Publication Date
WO2005025146A1 true WO2005025146A1 (fr) 2005-03-17

Family

ID=34130651

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/001694 WO2005025146A1 (fr) 2003-08-29 2004-06-30 Transmission de trafic multipoint au sein d’un reseau de communication

Country Status (2)

Country Link
FR (1) FR2859340B1 (fr)
WO (1) WO2005025146A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9316722B2 (en) 2008-04-17 2016-04-19 Aviation Communication & Surveillance Systems, Llc Systems and methods for providing ATC overlay protocols
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
US9791562B2 (en) 2007-04-24 2017-10-17 Aviation Communication & Surveillance Systems, Llc Systems and methods for providing an ATC overlay data link

Citations (4)

* Cited by examiner, † Cited by third party
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

Patent Citations (4)

* Cited by examiner, † Cited by third party
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

Cited By (4)

* Cited by examiner, † Cited by third party
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
US9316722B2 (en) 2008-04-17 2016-04-19 Aviation Communication & Surveillance Systems, Llc Systems and methods for providing ATC overlay protocols
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

Also Published As

Publication number Publication date
FR2859340B1 (fr) 2006-02-03
FR2859340A1 (fr) 2005-03-04

Similar Documents

Publication Publication Date Title
US7675912B1 (en) Method and apparatus for border gateway protocol (BGP) auto discovery
US7877508B1 (en) Method and system for intelligently forwarding multicast packets
US6870851B1 (en) Method and system for optimizing routing of data packets
EP1164754B1 (fr) Procédés et arrangements dans un système de télécommunication
US20020150041A1 (en) Method and system for providing an improved quality of service for data transportation over the internet
US20020184393A1 (en) Routing information exchange
US20060140136A1 (en) Automatic route tagging of BGP next-hop routes in IGP
US20060133390A1 (en) Method and apparatus providing prioritized convergence in border gateway protocol
US7274704B1 (en) Piggybacking VPN information in BGP for network based VPN architectures
JP2004534431A (ja) ネットワークトンネリング
CN101133596A (zh) 加快边界网关协议收敛的方法和装置
EP2732589A1 (fr) Procede de routage d'un flux multicast en mode non-stockage
EP3320656B1 (fr) Routage de paquets dynamique
EP1803263A1 (fr) Procede et dispositif de controle d'admission a un service a qualite de service garantie dans un reseau mpls
US20040246971A1 (en) Apparatus for enabling multi-tuple TCP sockets within a computer network
WO2007122353A1 (fr) Procede de selection d'une route de telephonie au sein d'un domaine de telephonie ip, dispositif et programme d'ordinateur correspondants
FR2834412A1 (fr) Noeud de reseau, interface physique contenue par ce noeud et procede de traitement de paquets transportant une charge utile vocale
US20210250275A1 (en) System and Method for Implementing Controller Border Gateway Protocol (cBGP)
US20060114904A1 (en) Differentiated services multicast system and method using encapsulation and unicast
WO2005025146A1 (fr) Transmission de trafic multipoint au sein d’un reseau de communication
Shamim Troubleshooting IP routing protocols
Hanka et al. A novel DHT-based network architecture for the Next Generation Internet
Tran Proactive multicast-based IPSEC discovery protocol and multicast extension
FR2851706A1 (fr) Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte.
FR2805430A1 (fr) Procede de gestion de mobilite dans un reseau de telecommunications, et serveur de mobilite pour la mise en oeuvre du procede

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase