Data flow exchange architecture in a mobile vehicle formation and associated exchange process

Abstract

Data Flow Exchange Architecture in a Mobile Vehicle Formation and Associated Exchange Method. The present invention relates to an exchange architecture (10) comprising a plurality of communication platforms (12A,…,12N) and links (14) connecting these communication platforms (12A,…,12N). The architecture (10) is characterized in that each communication platform (12A,…,12N) comprises a path controller (24) connected between at least one security domain and a switch of that platform, identifiable by an address and configured to modify each received packet, when that communication platform (12A,…,12N) is not the destination platform of that packet, to forward it to the path controller of a subsequent communication platform (12A,…,12N) connected by a link (14) to that communication platform (12A,…,12N). Figure for the abstract: Figure 1

Description

Title of the invention: Architecture for exchanging data flows in a formation of mobile vehicles and associated exchange method

[0001] The present invention relates to an architecture for exchanging data flows in a formation of mobile vehicles.

[0002] The present invention also relates to an exchange method associated with such an architecture.

[0003] In a manner known per se, such devices are capable of exchanging digital data between themselves and possibly with a command center via communication links established between them.

[0004] These digital data can be of different natures.

[0005] Thus, for example, this data may include data streams relating to telephone exchanges between at least some of the devices. These data streams, although generally not very large, must be transmitted as a priority in order to ensure quality of service.

[0006] The data exchanged may also include strategic data, for example, relating to the ongoing combat. It is clear that this data must be transmitted not only with high priority but also with guaranteed bandwidth.

[0007] This makes it possible in particular to determine maximum latencies in the transmission of this data and to configure the corresponding combat systems appropriately.

[0008] The exchanged data may also include data of different confidentiality which must be encrypted in order to avoid their interception by a third party.

[0009] Finally, the data exchanged may also include entertainment data, for example from people on board the mobile vehicles. This data, although low priority, may have high throughput rates, particularly when it concerns multimedia data.

[0010] Thus, depending on their nature, at least some of the aforementioned data form privileged data flows which must be transmitted as a priority compared to other data flows and this, according to a guaranteed maximum latency and with a guaranteed flow rate for each of these privileged flows.

[0011] This latency and throughput assurance is achieved by reserving bandwidth for each privileged flow, so that its transfer between its source and destination can be carried out as if, from the point of view of this flow, the communication systems communication were free of any charge.

[0012] Given that there are generally a plurality of paths through the communication systems between a data source and the destination of this data, and that the reservation from which a privileged flow benefits is only valid on one of these paths, it is essential to control the quality of service to impose that this flow actually passes on this path.

[0013] To implement these exchanges, existing architectures generally take the form of a plurality of communication systems on board mobile vehicles and connected to each other by a communication network composed of communication links and switches connecting these links. To direct a flow from one communication system to another, the switches connecting the systems choose the best path for each flow based on logic specific to these switches. For example, a switch can use a default link for each flow of a particular type and when this link is not available, send this flow via another link.

[0014] It is thus understood that it is difficult to impose a particular path for flows except by intervening at the level of the communication network by modifying for example the logic used by one or more switches or by modifying a particular link.

[0015] The need to impose a particular path may be dictated by current operational constraints such as, for example, the relative positioning of mobile devices or the need to be in radio silence, or by external conditions such as, for example, weather conditions or interference experienced.

[0016] Furthermore, given that a privileged flow takes a path on which it benefits from a flow rate reservation, and that the physical capacity of the transmission links constituting this path is likely to vary over time, it is essential to constantly verify that this path always has sufficient bandwidth for the reservation to remain valid.

[0017] Existing architectures also do not allow monitoring of the paths taken by different flows, particularly with regard to delays, flow rates used and flow rates actually available for each transmission means.

[0018] Measuring the flow rate used is not in itself problematic since it involves counting the packets sent to a communication platform. On the other hand, determining the remaining flow rate requires knowing the total flow capacity of each transmission means.

[0019] It is fundamental to be interested in the total flow capacity of each transmission means because the latter can vary depending on operational constraints and external conditions, as defined previously.

[0020] To do this, it is possible, for example, to associate a probe with each communication link capable of measuring the total capacity of this link in real time. This would, however, involve costly modifications to existing communication networks as well as an overload of traffic generated by these probes.

[0021] The present invention aims to overcome these drawbacks and to propose an exchange architecture capable of efficiently managing flows of different types, while making it possible to impose particular paths for these flows and to monitor the different paths taken by these flows, without intervening at the level of the communication network. In other words, the invention makes it possible to solve the aforementioned problems without having to modify the existing communication network.

[0022] To this end, the subject of the invention is an architecture for exchanging data flows in a formation of mobile vehicles, comprising a plurality of communication platforms and links connecting these communication platforms to each other, each communication platform being associated with one of the mobile vehicles or with a command center, and comprising at least one security domain capable of transmitting and receiving privileged data flows and a switch connecting the or each security domain to the links, each privileged data flow being composed of a plurality of packets intended to be transmitted between a source platform and a destination platform according to a transmission conduit reserved for this flow.

[0023] The architecture is characterized in that each communication platform further comprises a path controller connected between the or each security domain and the corresponding switch, identifiable by an address and configured to modify each packet received, when this communication platform is not the destination platform of this packet, to send it back to the path controller of a following communication platform connected by a link to this communication platform.

[0024] According to other advantageous aspects of the invention, the exchange architecture according to the invention comprises one or more of the following characteristics, taken in isolation or in all technically possible combinations:

[0025] - each packet includes a header including a source field defining ini initially an initial source address associated with a client of the source platform of this packet, and a destination field initially defining an initial destination address associated with a client of the destination platform of this packet;

[0026] - the path controller of each communication platform is configured to put in the destination field of each packet received the address of the path controller to which this packet is returned, when this communication platform is not the destination platform of this packet. ;

[0027] - the path controller of each communication platform is configured in further to modify the source field of each packet for which this communication platform is the source platform, by putting therein transmission data usable for the transmission of this packet;

[0028] - the transmission data of each packet includes a source identifier corresponding to the initial source address of this packet, a destination identifier corresponding to the initial destination address of this packet and a conduit identifier identifying the transmission conduit of the privileged data flow to which this packet belongs;

[0029] - the path controller of each communication platform comprises a correspondence table between the source identifiers and the corresponding initial source addresses, and the destination identifiers and the corresponding initial destination addresses;

[0030] - the path controller of each communication platform is configured in furthermore to restore in the destination field and in the source field of each packet received respectively the initial destination address and the initial source address, using the transmission data of this packet, when this communication platform is the destination platform of this packet;

[0031] - the path controller of each communication platform is configured to determine for each received packet the next communication platform in accordance with the transmission channel of the privileged data flow to which this packet belongs.;

[0032] - at least one of the path controllers of each pair of communication platforms communication) connected by a link is configured to measure an actual throughput of this link by comparing the number of packets transmitted in this link and received from it with the other path controller;

[0033] - the path controller of each communication platform is configured to write in the transmission data of each packet to be transmitted via a link a packet reference corresponding to the sequential number of this packet among all the packets transmitted in this link;

[0034] - each communication platform further comprises a central module capable of reconfigure at least one transmission conduit of at least one privileged data flow passing through this platform, when the actual flow rate on at least one link used by this conduit is lower than the flow rate reserved on this link.

[0035] The present invention also relates to a method for exchanging data flows in the architecture as previously described, comprising the following steps, implemented by the path controller of each communication platform:

[0036] - receive a packet;

[0037] - when this communication platform is not the destination platform of this packet, modify this packet to send it back to the path controller of a subsequent communication platform connected by a link) to this communication platform.

[0038] These characteristics and advantages of the invention will appear on reading the description which follows, given solely by way of limiting example, and made with reference to the appended drawings in which:

[0039] - [Fig.l] [Fig.l] is a schematic view of a flow exchange architecture of data in a mobile vehicle formation comprising a plurality of communication platforms, each communication platform being associated with a mobile vehicle or a command center;

[0040] - [Fig.2] [Fig.2] is a schematic view of one of the communication platforms communication of [Fig.l] with links associated with this platform; and

[0041] - [Fig.3][Fig.4][Fig.5] Figures 3 to 5 are different views illustrating the implementation implementation of a method for exchanging data flows according to the invention.

[0042] [Fig.l] in fact illustrates an architecture 10 for exchanging data flows in a formation of mobile vehicles.

[0043] This exchange architecture 10 comprises a plurality of communication platforms 12A to 12N and links 14 connecting at least certain pairs of these platforms.

[0044] The connections 14 are formed by transmission means known per se.

[0045] Thus, each link 14 is formed between a pair of platforms 12A to 12N using one or more transmission means known per se.

[0046] These transmission means are possibly wireless of the same nature or of different natures and are for example chosen according to the nature of the mobile machines. These transmission means can also be, at least in part, wired when for example the corresponding platform(s) are immobilized at least temporarily.

[0047] Preferably, each transmission means is a radio or optical transmission means, possibly passing through a satellite system and / or an aircraft or aerostat system or other types of mobile devices not forming part of said formation of mobile devices.

[0048] Each link 14 has a data transmission rate, also called the transmission capacity of this link. This rate is measurable.

[0049] Each communication platform 12A to 12N is associated with one of the mobile vehicles of the formation or with a command center.

[0050] In the example described, each mobile craft has a ship, for example a surface ship or a submersible ship. The associated communication platform to such a device is therefore embarked on board it.

[0051] Generally speaking, a mobile device can be any other device, for example a land device or an aircraft or even a space device.

[0052] By “command center” we mean, for example, a terrestrial command center then including the communication platform associated with it.

[0053] According to other embodiments, the command center can also be mounted on board a mobile vehicle, for example of the same type as the other vehicles or of a different type.

[0054] The communication platforms 12A to 12N are for example substantially similar to each other. Thus, subsequently, only for example the communication platform 12A will be described in detail with reference to [Fig.2].

[0055] Thus, as can be seen in this [Fig.2], the communication platform 12A comprises a plurality of security domains 21A to 21M, a switch 22, a central module 23 and a path controller 24. All of the security domains 21A to 21M of the same communication platform form a communication system of this platform. In this case, the switches 22 of all of the communication platforms 12A to 12N and the links 14 form a communication network of the architecture 10.

[0056] Each security domain 21A to 21M is capable of producing data streams of a confidentiality level specific to this domain and of receiving data streams of the corresponding confidentiality level.

[0057] To do this, each security domain comprises a plurality of clients 31 and a computer network 32 connecting these clients 31 together.

[0058] The computer network 32 is for example a wired LAN type network known per se.

[0059] Each client 31 has, for example, an access terminal usable by a user or an on-board system.

[0060] Thus, each client 31 is able to produce digital data in the form of data streams and to receive digital data also in the form of digital streams.

[0061] According to an exemplary embodiment, at least one of the clients 31 has an encryptor making it possible to encrypt all of the data leaving this domain according to their confidentiality level and to decrypt the data entering this domain, according to techniques known per se. In this case, all of the other clients 31 are connected to the other security domains of the platform 12A and of the other platforms via the encryptor.

[0062] Each client 31 is identifiable by an address, known in the state as “IP address”. This address is, for example, unique within the architecture 10 or at least within each security domain 21A to 21M, when encryptors are used. In the latter case, each encryptor has a unique IP address within the architecture 10.

[0063] Each data stream transmitted or received by the clients 31 is in the form of a plurality of packets. In a manner known per se, each packet comprises a useful message corresponding to the useful data intended to be transmitted to a client, and a header making it possible to transmit this message via the communication network.

[0064] The header of each packet includes in particular a source field and a destination field. For packets circulating in the security domains 21A to 21M or entering these domains or leaving these domains, the source field defines the IP address of the client 31 having sent this packet or possibly of the encryptor of the security domain having sent this packet, and the destination field defines the IP address of the client 31 for which this packet is intended or possibly of the encryptor of the security domain for which this packet is intended.

[0065] The switch 22 connects each security domain 21A to 21M to the communication network and in particular to the links 14 and makes it possible to transmit each packet in accordance with the value of its destination field.

[0066] The central module 23 makes it possible to establish rules for managing all the data flows in the communication platform 12A by establishing a communication plan for this platform.

[0067] In particular, the communication plan established by the central module 23 makes it possible to designate, from among all the data flows managed by the platform 12A, the data flows which must be treated as privileged.

[0068] Each privileged flow is associated with its specification comprising:

[0069] - an identifier of this flow;

[0070] - a source of this flow corresponding to the communication platform intended for produce this flow, also called source platform;

[0071] - a destination of this flow corresponding to the communication platform intended to receive this flow, also called destination platform; and

[0072] - a quality of service of this flow.

[0073] In particular, in a manner known per se, the quality of service comprises conditions under which this flow must be processed.

[0074] These conditions include in particular priorities relating to this flow, latencies as well as its transmission rate.

[0075] Thus, each communication plan includes a list of flow specifications making it possible to define privileged flows whose quality of service is guaranteed, and to choose the paths they take to benefit from this guarantee.

[0076] To define such a communication plan, the central module 23 is able to implement a negotiation with the central modules 23 of the other communication platforms 12B to 12N in order to ensure the reserved bit rates for each of the privileged flows and more generally, their quality of service. This negotiation results in the creation for each privileged flow of a conduit which is a bandwidth reservation on the path that this flow will travel from end to end between its source platform and its destination platform.

[0077] Furthermore, to implement the execution of the communication plan established for the communication platform 12A, the central module 23 is connected to a local management module within each security domain 21A to 21M to a global management module common to all the security domains 21A to 21M. These management modules (not illustrated in [Fig. 2]) therefore make it possible to ensure the management of the data flows in accordance with the communication plan established by the central module 23. Their operation has also been described in detail in the aforementioned documents.

[0078] Generally speaking, by “transmission conduit” for a privileged flow, we mean a reservation of bandwidth in accordance with the specification of this flow, on an end-to-end path determined for this flow.

[0079] A determined path for a privileged flow therefore passes through the source platform of this privileged flow, its destination platform and when the source platform and the destination platform are not connected by one of the links 14, by one or more other communication platforms, then called relay platforms. A path therefore has a series of transmission links. Depending on the number of privileged flows using the same path, this path may contain several conduits. A conduit belongs to a single path.

[0080] Each transmission conduit is formed of a plurality of conduit segments. Each conduit segment corresponds to a reserved flow rate on the link 14 connecting the source platform to the destination platform of the associated flow, or the source platform or the destination platform to one of the relay platforms or two relay platforms between them.

[0081] Thus, the flow rate of each conduit segment is less than or equal to the total flow rate of the connection 14 corresponding to this segment.

[0082] Finally, the segments of the same conduit have an identical reserved flow rate for the same flow. Thus, each transmission conduit has a guaranteed flow rate for the corresponding preferred flow.

[0083] The path controller 24 is connected between the security domains 21A to 21M and the switch 22 and is identifiable by a unique IP address within the architecture 10. This path controller 24 makes it possible to impose a particular path for each packet passing via the communication platform 12A and to monitor all the links 14 connected to this communication platform 12A, in accordance with the decisions taken by the central modules 23.

[0084] To do this, the path controller 24 of the communication platform 12A as well as the path controllers 24 of the other communication platforms 12B to 12N are capable of implementing a method of exchanging data flows in the architecture 10 which will now be explained in detail with reference to FIGS. 3 to 5.

[0085] This data exchange method comprises a step of transmitting at least one packet of a privileged flow by a source platform, a step of transmitting this packet by at least one relay platform and a step of receiving this packet by a destination platform. The privileged flow is then associated with a transmission conduit between the source platform and the destination platform via at least said relay platform. This transmission conduit then guarantees a reserved flow rate for this flow in accordance with the communication plan and compliance with this flow rate is ensured by the local and global management modules of these platforms by implementing for example one or more mechanisms described in documents FR 20 00814, FR 20 00813, FR 20 00811 and FR 20 00809.

[0086] The exchange method according to the invention further comprises a step of monitoring a link 14 following the transmission of several packets via this link 14.

[0087] During the transmission step, it is considered that one of the communication platforms, for example the communication platform 12A, transmits a packet forming part of a privileged flow. This communication platform 12A is therefore the source platform for this privileged flow. This example is illustrated in FIGS. 4 and 5 in which the packet is transmitted between the communication platforms 12A and 12D via the communication platform 12B.

[0088] It is also considered that this packet is sent by one of the clients 31 of this communication platform 12A which indicates in the source field of this packet its IP address which will be designated hereinafter as the initial source address, and in the destination field of this packet the IP address of the client 31 of the communication platform to which this packet is intended. This latter IP address will be designated hereinafter as the initial destination address and corresponds to the reference AI in the example of [Fig.4]. As explained previously, the initial source and initial destination addresses may correspond to the IP addresses of the corresponding encryptors.

[0089] Before being received by the switch 22 of the communication platform 12A, the transmitted packet is received by the path controller 24 of this platform 12A which modifies the destination address of this packet to send it back to the path controller 24 of a following communication platform which is determined according to the transmission path associated with the flow of this packet. In the example of figures 4 and 5, the next communication platform is communication platform 12B.

[0090] To do this, the path controller 24 of the communication platform 12A first modifies the source field of the packet.

[0091] More particularly, the path controller 24 modifies the source field of the packet by putting transmission data there that can be used for the transmission of this packet.

[0092] According to an exemplary embodiment, this transmission data comprises a source identifier corresponding to the initial source address of this packet, a destination identifier corresponding to the initial destination address of this packet, a path identifier identifying the transmission path of the privileged data stream to which this packet belongs and a packet reference for measuring the actual throughput of the corresponding link 14, as will be explained later.

[0093] According to a particular example of the invention, the transmission data may further comprise additional data for specific uses.

[0094] An example of a source field modified to contain the transmission data is illustrated in [Fig.3]. This field extends for example over 32 bits.

[0095] Thus, in the example of this figure, the source field modified by the controller 24 comprises in particular an IZS sub-field comprising the source identifier, an IZD sub-field comprising the destination identifier, an ID sub-field comprising the conduit identifier, a No. sub-field comprising the packet reference and a Disc sub-field comprising the additional data as defined previously.

[0096] The source and destination identifiers are determined by the path controller 24 using, for example, a correspondence table between these identifiers and the real IP addresses of the corresponding clients 31. Such a correspondence table is, for example, transmitted by the central module 23 of the platform 12A prior to the implementation of the method.

[0097] The path identifier, which allows each path controller 24 of a given platform to know the next path controller 24 to which it must send the packets of the path, is for example also transmitted to the path controller 24 of this platform by the central module 23 of the same platform prior to the implementation of the method.

[0098] Finally, the packet reference corresponds for example to the sequential number of this packet among all the packets transmitted in the same link 14 from the communication platform 12A.

[0099] During the same transmission step, the path controller 24 further modifies the destination field by putting there the IP address of the path controller 24 of the next communication platform, according to the transmission path cor- respondent.

[0100] In [Fig.4], this IP address is designated by the reference AB which then corresponds to the IP address of the path controller 24 of the communication platform 12B.

[0101] Thus, the switch 22 of the communication platform 12A is forced to send the packet via the link 14 connecting the communication platforms 12A and 12B, as illustrated in [Fig. 5]. In addition, this also forces the switch 22 of the switching platform 12B to forward the received packet to its path controller 24.

[0102] The following transmission step is then implemented by this path controller 24 of the switching platform 12B.

[0103] During this transmission step, the path controller 24 of the communication platform 12B modifies the destination field of the received packet to transmit it to the path controller of a subsequent communication platform also determined according to the transmission path of this packet. In the example of Figures 4 and 5, this is the communication platform 12D.

[0104] To do this, as in the previous transmission step, the path controller 24 puts in the destination field of this packet the IP address of the path controller 24 of the following communication platform.

[0105] In the example of [Fig.4], the path controller 24 of the communication platform 12B therefore places in this field the address of the path controller 24 of the communication platform 12D which is designated in this figure by the reference AD.

[0106] During the same step, the path controller 24 of the communication platform 12B further modifies the packet reference in the source field by putting there the sequential number of this packet among all the packets transmitted via the link 14 connecting the platforms 12B and 12D.

[0107] Finally, the path controller 24 of the communication platform 12B transmits the packet thus modified to the switch 22 of the same platform which is forced to transmit it to the switch 22 of the communication platform 12D. The latter, upon receiving this packet, is therefore also forced to transmit it to the path controller 24 of the same communication platform 12D.

[0108] Upon receipt of this packet, the path controller 24 of the communication platform 12D determines that it is the destination platform of this packet, by analyzing the path identifier included in the source field of this packet.

[0109] Then, this path controller 24 extracts the other transmission data from the packet source field and using a lookup table similar to that described in relation to the transmission step, determines the initial source address and the initial destination address.

[0110] Thus, this controller 24 restores the destination field by putting the initial destination address there and the source field by putting the initial source address there. Then, the path controller 24 transmits this packet to one of the clients 31 of the communication platform 12D in accordance with the initial destination address. This packet is therefore identical to the packet initially sent by the corresponding client 31.

[0111] As explained previously, the step of monitoring a link 14 is implemented by a pair of communication platforms connected by this link after the transmission of several packets.

[0112] In particular, during this step, the path controller 24 of one of these communication platforms determines a packet loss rate by comparing the number of packets transmitted and received through the link 14. This comparison is made by analyzing the transmitted / received packet references.

[0113] For example, the path controller 24 of the communication platform receiving packets from the link 14 can compare the number of packets actually received from a given instant or from the instant of transmission of a given packet with the sequential number entered in the source field of the last packet received. According to another example, all the packets transmitted are numbered from 1 to N, thus forming a sequence of N packets. The measurements are for example carried out for each sequence of N packets received.

[0114] It is possible to implement the same technique with the packets transmitted by one of the platforms. In this case, the path controller 24 of the platform receiving these packets can transmit to the path controller 24 of the transmitting platform the number of packets received from the instant of transmission of a packet identified by a particular packet reference. This latter path controller 24 then compares this number with the number of packets transmitted in the link 14 from the same instant.

[0115] When the corresponding path controller 24 observes a packet loss rate greater than a certain tolerance, it can conclude that there is a drop in the actual throughput of the corresponding link 14. This controller 24 can therefore transmit this information to the corresponding central module 23 which triggers a reconfiguration of the transmission conduits of the architecture 10 to take this drop in throughput into account.

[0116] It is then understood that the present invention has a certain number of advantages.

[0117] First of all, the invention makes it possible to impose particular paths on packets circulating between different communication platforms in accordance with the flow rate reservations made. This then makes it possible to take into account operational constraints and external conditions. Furthermore, this is done without any intervention at the level of switches, which makes it possible to keep the existing communication network unchanged. In addition, the invention makes it possible to maintain efficient exchanges within the architecture, while respecting the quality of service of the pri- vilified.

[0118] Finally, the exchanges carried out do not modify the initial form of the packets transmitted and do not add additional traffic to the communication network.

Claims

Claims

1. Architecture for exchanging (10) data flows in a formation of mobile vehicles, comprising a plurality of communication platforms (12A,...,12N) and links (14) connecting these communication platforms (12A,...,12N) to each other, each communication platform (12A,...,12N) being associated with one of the mobile vehicles or with a command center, and comprising at least one security domain (21 A,...,21M) capable of transmitting and receiving privileged data flows and a switch (22) connecting the or each security domain to the links (14), each privileged data flow being composed of a plurality of packets intended to be transmitted between a source platform (12A,...,12N) and a destination platform (12A,...,12N) according to a transmission channel reserved for this flow; the architecture (10) being characterized in that each communication platform (12A,.. .,12N) further comprises a path controller (24) connected between the or each security domain (21A,...,21M) and the corresponding switch (22), identifiable by an address and configured to modify each received packet, when this communication platform (12A,...,12N) is not the destination platform of this packet, to send it back to the path controller (24) of a next communication platform (12A,...,12N) connected by a link (14) to this communication platform (12A,...,12N); and in that: - each packet comprises a header comprising a source field initially defining an initial source address associated with a client (31) of the source platform (12A,...,12N) of this packet, and a destination field initially defining an initial destination address associated with a client (31) of the destination platform (12A,...,12N) of this packet;. - the path controller (24) of each communication platform (12A,.. .,12N) is configured to put in the destination field of each packet received the address of the path controller (24) to which this packet is returned, when this communication platform (12A,.. .,12N) is not the destination platform of this packet.

2. Architecture (10) according to claim 1, wherein the path controller (24) of each communication platform (12A,...,12N) is further configured to modify the source field of each packet of which this communication platform (12A,.. .,12N) is the source platform, by putting transmission data there which can be used for the transmission of this packet.

3. The architecture (10) of claim 2, wherein the transmission data of each packet comprises a source identifier corresponding to the initial source address of that packet, a destination identifier corresponding to the initial destination address of that packet, and a path identifier identifying the transmission path of the privileged data stream to which that packet belongs.

4. Architecture (10) according to claim 3, in which the path controller (24) of each communication platform (12A,...,12N) comprises a correspondence table between the source identifiers and the corresponding initial source addresses, and the destination identifiers and the corresponding initial destination addresses.

5. Architecture (10) according to any one of claims 2 to 4, in which the path controller (24) of each communication platform (12A,...,12N) is further configured to restore in the destination field and in the source field of each packet received respectively the initial destination address and the initial source address, using the transmission data of this packet, when this communication platform (12A,...,12N) is the destination platform of this packet.

6. Architecture (10) according to any one of the preceding claims, wherein the path controller (24) of each communication platform is configured to determine for each received packet the next communication platform (12A,.. .,12N) in accordance with the transmission path of the privileged data flow to which this packet belongs.

7. Architecture (10) according to any one of the preceding claims, in which at least one of the path controllers (24) of each pair of communication platforms (12A,...,12N) connected by a link (14) is configured to measure an actual throughput of this link by comparing the number of packets transmitted in this link and received from it with the other path controller (24).

8. Architecture (10) according to claim 7 taken in combination with claim 3, in which the path controller (24) of each communication platform (12A,.. .,12N) is configured to write in the transmission data of each packet to be transmitted via a link (14) a packet reference corresponding to the sequential number of this packet among all the packets transmitted in this link (14).

9. Architecture (14) according to claim 7 or 8, in which each communication platform (12A,.. .,12N) further comprises a central module (23) capable of reconfiguring at least one transmission conduit of at least one privileged data flow passing through this platform (12A,.. .,12N), when the actual flow rate on at least one link (14) used by this conduit is lower than the flow rate reserved on this link.

10. Method for exchanging data streams in the architecture (10) according to any one of the preceding claims, comprising the following steps, implemented by the path controller (24) of each communication platform (12A,...,12N): - receiving a packet; - when this communication platform (12A,...,12N) is not the destination platform of this packet, modifying this packet to send it back to the path controller (24) of a following communication platform (12A,...,12N) connected by a link (14) to this communication platform (12A,...,12N).

Images