How to test the network using test data stream

Abstract

Various embodiments of the present disclosure are directed to methods for testing a network using a test data stream. A method for testing a network including a plurality of devices, comprising the following steps: a first device sending a test data stream to a second device on a path through the network, the first device being a regular participant of the network, and the second device being another regular participant of the network; the second device sending the received test data stream and / or at least one diagnostic metric derived from the received test data stream to a diagnostic entity; and the diagnostic entity determining, at least in part based on the test data stream and / or the diagnostic metric received from the second device, whether the path through the network is performing according to at least one predetermined criterion.

Description

Technical Field

[0001] The present invention relates to testing of communication networks (eg Time Sensitive Networks TSN) for use with distributed control systems DCS. Background Art

[0002] Monitoring and active control of industrial plants is based on a variety of information collected within the plant. For example, sensor devices output measurements and actuator devices report their operating status. This information can be used by a distributed control system DCS. For example, sensor data can be used as feedback in a control loop that controls the plant so that certain state variables (such as temperature or pressure) are maintained at a desired set point value.

[0003] This communication is time-critical. Any changes in the measured values ​​need to be communicated in a timely manner to allow the DCS to react to the change. In addition, any actions taken by the DCS need to be communicated to the actuators in the plant in a timely manner. Time-Sensitive Networking (TSN) nominally guarantees end-to-end determinism in communication. However, the network can deviate from this nominal state for a number of reasons, including configuration errors, hardware or wiring failures, or hardware and / or software components that promised a certain performance but failed to deliver on that promise.

[0004] WO 2020 / 143 900 A1 discloses a method for handling TSN communication link failures in a TSN network.

[0005] Invention Objectives

[0006] An object of the present invention is to facilitate the testing of a communications network to verify that it is in proper working order and can be relied upon for time-critical communications.

[0007] This object is achieved by a testing method according to the independent claim. Further advantageous embodiments are specified in the dependent claims. Summary of the invention

[0008] The present invention provides a method for testing a network including a plurality of devices. For example, the network may be selected as a network in an industrial plant configured to carry network traffic of a distributed control system DCS. In particular, such a network may be selected to be deterministic with respect to resource allocation and / or traffic scheduling. Time-sensitive network TSN is a typical example of such a deterministic network.

[0009] During the method, a first device sends a test data stream to a second device, the first device being a regular participant of a network, the second device being another regular participant of the network. The second device sends the received test data stream and / or at least one diagnostic metric derived from the received test data stream to a diagnostic entity. The at least one diagnostic metric may, for example, relate to throughput, delay, reliability and / or jitter.

[0010] The diagnostic entity then determines, based at least in part on the test data stream and / or the diagnostic metric received from the second device, whether the path through the network is performing according to at least one predetermined criterion.

[0011] In this way, the complete network infrastructure along the path between the first device and the second device can be tested at one time. In particular, the path from the first device to the second device does not need to be the shortest path available in the network. Instead, by selecting a longer path through the network, a larger part of the network can be tested. In particular, the path through the network from the first device to the second device can be selected to include all network infrastructure devices of the network. This may not allow the root cause of the problem in the network to be directly pinpointed. But for many applications, it is more important to test whether the entire network is operating normally. If any problem is detected in a network used to transmit control traffic in an industrial plant, no matter what the exact root cause is, it may be advantageous to take immediate action on the industrial plant to move it to a safe state, in which delays or even failures in message delivery will no longer lead to plant shutdowns or even plant damage. For example, an orderly shutdown of a process executed on the plant can be initiated. As a less severe measure, the production rate of the process may be slowed down to the extent that other safety systems or even manual intervention can react quickly enough to prevent damage in the event of further degradation of network performance.

[0012] At the same time, the method is completely flexible as to how and where the diagnostic entity is integrated into the network. For example, the diagnostic entity can be implemented at least partially on a regular participant of the network, on an additional participant added to the network specifically for testing.

[0013] For example, the test data stream may be provided by the diagnosis entity, but the test data stream may also be generated by the first device, depending on the processing capability of the first device.

[0014] For example, a test of the network may be initiated by the diagnostic entity. However, this is not necessary. Instead, the test may also be initiated by the first device. If the first device initiates the test and provides its own test data stream, the diagnostic entity may be substantially reduced to the role of listening to the test data stream and the diagnostic metrics derived therefrom, and drawing conclusions about the normal operation of the network based on this information.

[0015] In a particularly advantageous embodiment, the diagnostic entity is implemented at least partially as part of a time-sensitive network TSN:

[0016] Centralized user configuration CUC,

[0017] Centralized network configuration CNC, and / or

[0018] Engineering tools.

[0019] In this way, any changes in network configuration required to transmit the test data stream from the first device to the second device or to transmit the test data stream and / or diagnostic metrics from the second device to the diagnostic entity can be directly coordinated by the diagnostic entity. For example, bandwidth and other resources may need to be allocated to transmit the test data stream.

[0020] In one embodiment, the first device and the second device are selected as terminal devices, which are the source and / or sink of traffic in the network. Examples of such terminal devices include computers, sensors, actuators, or controllers in distributed control systems. Compared with pure network infrastructure devices that may do most of the work on OSI layer 2 (data link layer) or layer 3 (network layer), such terminal devices have stronger computing power and are more capable of processing test data streams at a more abstract level (i.e., a higher OSI layer). This higher level of processing comes at the expense of being more prone to unexpected delays. In order to reduce the impact of such unexpected delays on network performance measurements, it may be advantageous for the second device to derive at least one diagnostic metric from the received test data stream. If this diagnostic metric is transmitted to a diagnostic entity and experiences further delays during transmission, this diagnostic metric will not be changed.

[0021] Due to their greater processing resources, the terminal devices acting as first and second devices are also able to participate to a greater extent in publish-subscribe systems used in the network, such as the PubSub feature in the Open Platform Communications Unified Architecture (OPC UA). In a publish-subscribe system, an entity can publish messages in one or more channels or topics. An entity can subscribe to a channel or topic and then receive any messages subsequently published in those channels or topics.

[0022] Therefore, in another advantageous embodiment, the method further comprises:

[0023] The diagnostic entity publishes an instruction to send the test data stream to the second device to a topic and / or channel subscribed by the first device; and

[0024] • Publishing, by the diagnostic entity, to a topic and / or channel to which the second device subscribes, an instruction to send the received test data stream and / or diagnostic metric to the diagnostic entity.

[0025] In particular, if the end device is a field device or controller of a distributed control system DCS for an industrial plant, and these devices are already aware of OPC, the device will already have OPC UA PubSub built in. In this case, it is particularly easy to deploy software that enables the end device to act as the first device and the second device of the diagnostic network. This software may call the already existing, tried and tested PubSub functionality. There is less chance of error and the footprint of the additional software is also smaller. Similarly, in other use cases where other publish-subscribe mechanisms besides OPC UA PubSub are already used for the normal operation of the end device, this publish-subscribe mechanism can be re-used to transmit instructions from the diagnostic entity to the first device and the second device.

[0026] The test data stream can in principle be generated by the first device itself. But the test data stream can also be provided by a diagnostic entity, which may have a better understanding of which specific data streams may be suitable for performing a "stress test" on the network. That is, the first device will receive the test data stream from the diagnostic entity and then pass it to the second device. In order to reduce additional delays by this process, the instructions to send the test data stream to the second device may include instructions to convert the data stream received from the diagnostic entity into a test data stream by changing the metadata of this data stream. In particular, such metadata may include a stream identifier and / or scheduling information related to the data stream. By modifying the metadata without actually touching the payload, the test data stream can be obtained with minimal effort on the first device side. The data stream simply makes a "U-turn" at the first device.

[0027] Likewise, the test data stream may make a similar "U-turn" at the second device to be passed to the diagnostic entity. Thus, the instruction to send the received test data stream to the diagnostic entity may include an instruction to modify metadata of the received test data stream.

[0028] As described above, in a network where bandwidth and other resources are scheduled or otherwise allocated, it may be necessary to procure such resources for additional traffic generated during the course of the method. Therefore, in another advantageous embodiment, the first device requests a configuration of a network infrastructure device from a network management entity in order to provide a path from the first device to the second device. As an alternative or combination to this, the second device requests a configuration of a network infrastructure device from the network management entity in order to provide a path from the second device to the diagnostic entity. For example, these requests can be transmitted by a publish-subscribe (PubSub) proxy mechanism. For example, if a request cannot be immediately granted due to a shortage of resources, the first device and the second device can decide which other traffic can be temporarily sacrificed to free up resources for testing.

[0029] In another embodiment, the first device and the second device are selected as network infrastructure devices that forward data streams between terminal devices as sources and sinks. Examples of such network infrastructure devices include switches, routers, bridges, and wireless access points. As previously mentioned, these network infrastructure devices typically have more limited processing capabilities for data streams than terminal devices, and process data streams at lower OSI layers (usually layer 2 or at most layer 3). On the other hand, this processing occurs very quickly, with little if any additional delay. That is, the data stream originating from the diagnostic entity can be sent through the network on one or more "U-turns" and returned to the diagnostic entity by the network infrastructure device very efficiently. Therefore, most of the network infrastructure can be tested by injecting only one test data stream. The only part of the network that this test cannot cover is the connection between the network infrastructure device and the terminal device. In order to detect any problems on these connections, such as loose connections or transceiver failures, the terminal device needs to be used as the first device and the second device as described above. But in most applications, the more important test is the test of the network infrastructure, which can be performed by passing test data streams between network infrastructure devices. In a switching network, a problem with the connection to a terminal station will only affect this terminal station. But problems in the network infrastructure can affect many end devices and are more likely to impair the functionality of the industrial plant that is using the network.

[0030] In particular, since a test data stream can be sent over multiple "U-turns" through the network without undue delay, it is possible for the test data stream to be fed back to the same diagnostic entity from which it originated. This means that this diagnostic entity can directly evaluate the final received test data stream with respect to, for example, integrity and latency. Previously, "two-point testing" was used in many testing situations. That is, the test data stream is sent over the network from a first diagnostic entity to a second diagnostic entity, which then performs the evaluation. In a "single-point testing" setup there is only one diagnostic entity which is a minimal addition to the network for testing purposes. In addition to saving the cost of a second diagnostic entity, this also helps to more accurately measure the performance of the network in the actual state in which it will be used for its intended purpose. In addition, it becomes easier to move this single diagnostic entity to different points in the network to probe it from different angles and possibly discover problems that are only visible from a certain angle.

[0031] In order to send the data stream onto the U-turn, in a particularly advantageous embodiment, the diagnostic entity changes the forwarding configuration of the first device to forward the data stream received from the diagnostic entity as a test data stream to the second device. Likewise, the diagnostic entity changes the forwarding configuration of the second device to forward the test data stream received from the first device to the diagnostic entity. If sufficient computing power is available on the respective devices, the change of the forwarding configuration can be triggered by a publish-subscribe system used in the network (e.g. OPC UAPubSub).

[0032] There are two main ways in which the first device and the second device forward the test data stream. The first way is for the metadata of individual packets of the incoming test data stream to be altered by the first device or by the second device. This is a particularly fast way to reroute the test data stream via OSI layer 2 processing. The second way is to create a new data stream using the payload of the incoming test data stream in a "pick-up-alter-forward" manner. In this way, the devices can collect more detailed diagnostic metrics (e.g., timing information), at the expense of more complex processing required and greater computing power on the side of the first device or the second device.

[0033] In a particularly advantageous embodiment, the at least one test data stream is determined based at least in part on one or more of:

[0034] Traffic patterns expected during normal operation of the network;

[0035] The topology of the network;

[0036] · Network configuration; and

[0037] Network traffic scheduling.

[0038] In this way, the test data flows can be tailored to resemble the traffic that is expected during normal operation of the network, depending on what is to be achieved through the test. But the test data flows may also be tailored to "stress test" specific aspects of the network. For example, if a certain network resource is known to be scarce, a test data flow can be crafted to test whether this resource can possibly be exhausted.

[0039] Not all functionality of the method needs to be concentrated in a single diagnostic entity. In particular, if the diagnostic entity instructs a terminal device or a network infrastructure device to perform certain actions (such as forwarding a test data stream), these actions can be implemented by a helper software application running in the respective device. This helper application can extend the functionality of the ordinary software and / or firmware running on the respective device. For example, a terminal device that is typically used to obtain a measurement value and send it to a controller over a network may lack the functionality to send the incoming data stream on a "U-turn". The software of the network infrastructure device may already have the "U-turn" functionality, but may lack the "pick-change-forward" functionality that allows high-level diagnostic metrics to be derived from the test data stream.

[0040] The method may be implemented in whole or in part by a computer. Therefore, the present invention also relates to one or more computer programs having machine-readable instructions, which, when executed on one or more computers and / or computing instances, cause one or more computers to perform the method. In this case, virtualization platforms, hardware controllers, network infrastructure devices (such as switches, bridges, routers, or wireless access points), and terminal devices (such as sensors, actuators, or other industrial field devices) in a network capable of executing machine-readable instructions are also considered computers. In particular, the network can be implemented as a software-defined network running on general-purpose hardware.

[0041] Therefore, the present invention also relates to a non-transitory storage medium and / or a download product with one or more computer programs. A download product is a product that can be sold in an online store for immediate implementation by downloading. The present invention also provides one or more computers and / or computing instances with one or more computer programs and / or with one or more non-transitory machine-readable storage media and / or download products. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Hereinafter, the present invention is explained using drawings, but is not intended to limit the scope of the present invention.

[0043] Diagram display:

[0044] Figure 1 : An exemplary embodiment of a method 100 for testing a network 1 comprising a plurality of devices 2a to 2f, 3a to 3f;

[0045] Figure 2 : An exemplary application of the method 100 in a network 1 with a terminal device 3b as the first device 4 and a terminal device 3f as the second device 6;

[0046] Figure 3: An exemplary application of the method 100 in a network 1 with a TSN bridge 2a as the first device 4 and a TSN bridge 2d as the second device 6. DETAILED DESCRIPTION

[0047] Figure 1 is a schematic flow chart of an embodiment of a method 100 for testing a network 1. The network 1 comprises a plurality of network infrastructure devices 2a to 2f and a plurality of terminal devices 3a to 3f.

[0048] In step 110 , a first device 4 , which is a regular participant of the network 1 , sends a test data stream 5 to a second device 6 , which is another regular participant of the network 1 .

[0049] In step 120 , the second device 6 sends the received test data stream 5 and / or at least one diagnostic metric 5 a derived from the received test data stream 5 to the diagnostic entity 7 .

[0050] In step 130, the diagnostic entity 7 determines whether the path through the network 1 is performing according to at least one predetermined criterion 8. This determination 10 is based at least in part on the test data stream 5 and / or diagnostic metrics 5a that the diagnostic entity 7 has received from the second device 6.

[0051] According to box 105, the first device 4 and the second device 6 can be selected as terminal devices 3a to 3f, which are sources and / or sinks of traffic of the network 1 during its expected normal operation. According to box 111, the diagnostic entity 7 can then issue an instruction to send the test data stream 5 to the second device 6. This publication can be made for a topic and / or channel subscribed by the first device 4 so that the first device 4 gets it. In particular, according to box 111a, the instruction to send the test data stream 5 to the second device 6 may include an instruction to convert the data stream 5' received from the diagnostic entity 7 into the test data stream 5 by changing the metadata of this data stream 5'.

[0052] Likewise, according to box 121, the diagnostic entity 7 may publish an instruction to send the data stream 5 received at the second device 6 and / or the diagnostic metrics 5a derived from this test data stream 5 to the diagnostic entity 7. This publication may be made for a topic and / or channel to which the second device 6 subscribes, so that the second device 6 gets it. In particular, according to box 121a, the instruction to send the received test data stream 5 to the diagnostic entity 7 may include an instruction to change the metadata of the received test data stream 5.

[0053] According to block 112 , the first device 4 may request configuration of the network infrastructure devices 2 a to 2 f from the network management entity 9 in order to provide a path through the network 1 from the first device to the second device 6 .

[0054] Likewise, according to block 122 , the second device 6 may request the configuration of the network infrastructure devices 2 a to 2 f from the network management entity 9 in order to provide a path from the second device 6 to the diagnostic entity 7 .

[0055] According to block 106, the first device 4 and the second device 6 may be selected as network infrastructure devices 2a to 2f that forward the data stream between the terminal devices 3a to 3f as source and sink. According to block 113, the diagnostic entity 7 may then modify the forwarding configuration of the first device 4 to forward the data stream 5' received from the diagnostic entity 7 to the second device 6 as the test data stream 5. In particular, the forwarding of the test data stream 5 may include

[0056] • modifying metadata of individual packets of the incoming test data stream 5' by the first device 4 according to block 113a; or

[0057] • Creating a new data stream according to block 113b using the payload of the incoming test data stream 5'.

[0058] Likewise, according to block 123, the diagnostic entity 7 may modify the forwarding configuration of the second device 6 to forward the test data stream 5 received from the first device 4 to the diagnostic entity 7. In particular, this forwarding of the test data stream 5 may include

[0059] The metadata of each packet of the incoming test data stream 5 is modified by the second device 6 according to block 123a; or

[0060] • Create a new data stream using the payload of the incoming test data stream 5 according to block 123b.

[0061] According to block 114, at least one test data stream 5 may be determined based at least in part on one or more of:

[0062] · The traffic patterns expected during normal operation of Network 1;

[0063] The topology of network 1;

[0064] · Configuration of Network 1; and

[0065] Traffic scheduling for network 1.

[0066] According to block 115 , a path through the network 1 from the first device 4 to the second device 6 may be selected to include all network infrastructure devices 2 a to 2 f of the network 1 .

[0067] Figure 2The exemplary application of the method 100 to a network 1 is illustrated, which comprises six TSN bridges 2a to 2f as network infrastructure devices and six terminal devices 3a to 3f attached to the TSN bridges 2a to 2f. Furthermore, in this example, the diagnostic entity 7 is attached to the TSN bridge 2c.

[0068] exist Figure 2 In the example shown, terminal device 3b is selected as first device 4, and terminal device 3f is selected as second device 6. Data stream 5' is sent from diagnostic entity 7 to first device 4. Diagnostic entity 7 instructs first device 4 to forward data stream 5' as test data stream 5 to second device 6. Similarly, diagnostic entity 7 instructs second device 6 to forward test data stream 5 to diagnostic entity 7. Figure 2 In the example shown, the first device 4 and the second device 6 request network resources for their respective forwarding tasks from the network management entity 9. That is, the configuration of the TSN bridges 2a to 2f is changed to accommodate the forwarding of the test data stream 5 from the first device 4 to the second device 6 and on to the diagnostic entity 7. For the sake of clarity, this is not shown in FIG. Figure 2 Displayed in.

[0069] Figure 3 The method 100 is described in Figure 2 Another exemplary application of the same network 1 is shown. Figure 2 In comparison, Figure 3 In the example shown, the TSN bridge 2a is selected as the first device 4 and the TSN bridge 2d is selected as the second device 6. A data stream 5' originating from the diagnostic entity 7 is injected into the network 1. This data stream 5' makes a first U-turn at the first device 4 to continue as a test data stream 5 to the second device 6. At the second device 6, the test data stream 5 makes another U-turn to continue to the diagnostic entity 7. In order to adapt the forwarding of the data stream 5 throughout the network 1, the configuration of all TSN bridges 2a to 2f is optionally updated by the diagnostic entity 7 with the help of a helper application installed on each TSN bridge 2a to 2f.

[0070] Reference numerals list

[0071] 1 Network

[0072] 2a-2f Network infrastructure equipment in Network 1

[0073] 3a-3f Terminal devices in network 1

[0074] 4 First device for testing

[0075] 5,5' Test data stream

[0076] 5a Diagnostic metrics derived from test data stream 5

[0077] 6 Second device for testing

[0078] 7 Diagnostic Entities

[0079] 8 Predetermined standards for normal operation of network 1

[0080] 9 Network Management Entity

[0081] 10 Confirmation of normal operation of network 1

[0082] 100 Methods for testing network 1

[0083] 105 Select terminal devices 3a to 3f as first device 4 and second device 6

[0084] 106 Select network devices 2a to 2f as first device 4 and second device 6

[0085] 110 Send the test data stream 5 to the second device 6

[0086] 111 Issue an instruction to send the test data stream 5 to the second device 6

[0087] 111a Transform data stream by changing metadata 5'

[0088] 112 Request a path from the network management entity 9 to the second device 6

[0089] 113 Change the forwarding configuration of the first device 4

[0090] 113a Change the metadata of each packet of data stream 5'

[0091] 113b Create a new data stream using the payload of the incoming data stream 5'

[0092] 114 Determine test data based on specific information 5

[0093] 115 Select a path through network 1 to cover all network devices 2a to 2f

[0094] 120 Send the test data stream 5 and the diagnostic metric 5a to the diagnostic entity 7

[0095] 121 Issue an instruction to send data stream 5 and metric 5a to diagnostic entity 7

[0096] 121a Change the metadata of the received test data stream 5

[0097] 122 Request from network management entity 9 to the path of diagnosis entity 7

[0098] 123 Change the forwarding configuration of the second device 6

[0099] 123a Change the metadata of each packet of data stream 5

[0100] 123b Create a new data stream using the payload of incoming data stream 5

[0101] 130 Obtain confirmation that network 1 is functioning properly 10

Claims

1. A method (100) for testing a network (1) comprising a plurality of devices (2a to 2f, 3a to 3f), comprising the following steps: a test data stream (5) is sent (110) by a first device (4) to a second device (6) on a path through the network (1), the first device (4) being a regular participant of the network (1), the second device (6) being another regular participant of the network (1); The second device (6) sends (120) the received test data stream (5) and / or at least one diagnostic metric (5a) derived from the received test data stream (5) to the diagnostic entity (7); determining (130), by the diagnostic entity (7), at least in part based on the test data stream (5) and / or the diagnostic metric (5a) received from the second device (6), whether the path through the network (1) is performing according to at least one predetermined criterion (8); The diagnostic entity (7) publishes (111) an instruction to send the test data stream (5) to the second device (6) to a topic and / or channel subscribed by the first device (4); as well as The diagnostic entity (7) publishes (121) instructions to send the received test data stream (5) and / or the diagnostic metric (5a) to the diagnostic entity (7) to a topic and / or a channel to which the second device (6) is subscribed.

2. The method (100) according to claim 1, wherein the first device (4) and the second device (6) are selected (105) as terminal devices (3a to 3f), the terminal devices (3a to 3f) being sources and / or sinks of traffic in the network (1).

3. The method (100) of claim 1, wherein The instructions for sending the test data stream (5) to the second device (6) include (111a): instructions for converting the data stream (5') received from the diagnostic entity (7) into the test data stream (5) by changing metadata of the data stream (5'); and / or The instructions to send the received test data stream (5) to the diagnostic entity (7) comprise (121a): instructions to modify metadata of the received test data stream (5).

4. The method (100) according to any one of claims 2 to 3, further comprising: Requesting (112) by the first device (4) from a network management entity (9) a configuration of network infrastructure devices (2a to 2f) in order to provide a path from the first device (4) to the second device (6); and / or Requesting (122) by the second device (6) from a network management entity (9) the configuration of the network infrastructure devices (2a to 2f) in order to provide a path from the second device (6) to the diagnostic entity (7).

5. The method (100) according to claim 1, wherein the first device (4) and the second device (6) are selected (106) as network infrastructure devices (2a to 2f), and the network infrastructure devices (2a to 2f) forward data flows between terminal devices (3a to 3f) as sources and sinks.

6. The method (100) according to claim 5, further comprising: The diagnostic entity (7) changes (113) the forwarding configuration of the first device (4) to forward the data stream (5') received from the diagnostic entity (7) to the second device (6) as the test data stream (5); and The forwarding configuration of the second device (6) is changed (123) by the diagnostic entity to forward the test data stream (5) received from the first device (4) to the diagnostic entity (7).

7. The method (100) according to claim 6, wherein the forwarding of the test data stream (5) comprises: The metadata of each packet of the incoming test data stream (5', 5) is modified (113a, 123a) by the first device (4) or by the second device (6); or • Creating (113b, 123b) a new data stream using the payload of said incoming test data stream (5', 5).

8. The method (100) according to any one of claims 1 to 3 and 5 to 7, wherein at least one test data stream (5) is determined (114) at least in part based on one or more of the following: the traffic patterns expected during normal operation of the network (1); The topology of the network (1); the configuration of the network (1); and Traffic scheduling of the network (1).

9. The method (100) according to any one of claims 1 to 3 and 5 to 7, wherein the network (1) is selected as a network (1) in an industrial plant configured to carry network traffic of a distributed control system DCS.

10. The method (100) according to any one of claims 1 to 3 and 5 to 7, wherein the diagnostic entity (7) is implemented at least partially as part of a time sensitive network TSN: Centralized user configuration CUC, Centralized network configuration CNC, and / or Engineering tools.

11. A method (100) according to any one of claims 1 to 3 and 5 to 7, wherein the path from the first device (4) to the second device (6) through the network (1) is selected (115) to include all network infrastructure devices (2a to 2f) of the network (1).

12. A computer program product comprising machine-readable instructions which, when executed on a computer, cause the computer to perform the method (100) according to any one of claims 1 to 11.

13. A non-transitory storage medium having the computer program product according to claim 12.

14. A computer having the computer program product according to claim 12 and / or having the non-transitory storage medium according to claim 13.

Images