WO2018111161A1

WO2018111161A1 - Method for secure communication on ethernet

Info

Publication number: WO2018111161A1
Application number: PCT/SE2016/051268
Authority: WO
Inventors: Guido Hiertz; Yunpeng Zang; Filip MESTANOV; János FARKAS
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-12-15
Filing date: 2016-12-15
Publication date: 2018-06-21

Abstract

A method and communication node (300) for communicating data in an Ethernet. The communication node (300) operates in a unidirectional mode by communicating data (3:1A) in only one direction. While in the unidirectional mode, the communication node (300) is also allowed to communicate acknowledge messages (3:1B) in an opposite direction. When detecting (3:2) a mode switching trigger, the communication node (300) operates in a bidirectional mode by both sending (3:3B) and receiving (3:3A) data, such as configuration messages in an updating or upgrading procedure. Thereby, the communication node (300) cannot be manipulated by an intruder to act in a harmful way in the Ethernet.

Description

METHOD FOR SECURE COMMUNICATION ON ETHERNET

Technical field

The present disclosure relates generally to a method and a communication node, for communicating data in an Ethernet.

Background

In the field of wired communication networks, the standard IEEE 802.3, also known as Ethernet, has been developed more than 35 years ago to provide communication of data between nodes within an Ethernet based network referred to as an Ethernet for short. The bit transmission rate that can be achieved over Ethernet has substantially evolved from 10 Megabits per second, Mb/s, to 100 Gigabits per second, Gb/s. Recently, it has been suggested to employ Ethernet for industrial and vehicle applications and home automation.

In the above-mentioned areas of application and elsewhere it may be desirable to protect components and nodes in an Ethernet from being attacked and manipulated by outside intruders, e.g. with the purpose of hostile take-over of the application and possibly communicate potentially harmful data and messages in the network. There are several published reports that describe such malicious attacks on vehicles, factories and machines in which communication nodes of an Ethernet have been successfully breached and infiltrated from the outside.

For example, security can be breached by attacking low cost devices and nodes that serve limited purposes such as providing measurements or observations to a control node or the like. Such simple devices have been designed for simple operation at low cost and they often have poor implementations of higher layer protocols which are thus potentially very vulnerable to attacks. At the same time it may be of great importance to provide high reliability in the communication to or from certain nodes and devices in an Ethernet based network, such as a sensor device that operates to send crucial temperature measurements which must be properly received at some control unit such as cooling unit to ensure accurate operation of a machine or similar. It may be possible to employ firewalls and data inspection for protecting an Ethernet based network. A firewall basically limits the possibility of nodes and devices inside of a protected network to communicate with nodes and devices outside the protected network. Therefore, all traffic exchanged between the network nodes and outside nodes need to pass through the firewall. The firewall observes incoming and outgoing traffic of data packets, e.g. based on some predefined rules, and allows certain packets to pass while other non-allowed packets are discarded, thus basically providing a filtering function. The firewall may be visible as a router of Internet Protocol, IP, packets. Firewalls and related equipment that provide protection and other services such as Virtual Private Network VPN access, may become targets of security attacks themselves. Once infiltrated, other network elements may be vulnerable for attacks and hostile takeovers. Furthermore, firewalls typically require a complete implementation of IP and higher layer protocol stacks. Operating these protocol stacks requires availability of efficient software code that can run on a general purpose Central Processing Unit, CPU. Erroneous software code itself may be prone to attacks. Depending on the firewall rules and the amount of traffic to be filtered, it may be necessary to employ a high performance CPU which may result in increased power consumption. Consequently, it may not be feasible to employ a firewall in some situations, especially in a network with a large amount of sensors and devices, e.g. due to high costs and added complexity.

It is thus a problem to provide protection against malicious attacks and other intrusion on communication nodes in an Ethernet, without resulting in too high costs and complexity. It is also a problem to communicate data from a source node in the Ethernet with sufficiently high reliability, e.g. when it is crucial or important to receive the data at a destination node.

Summary

It is an object of embodiments described herein to address at least some of the problems and issues outlined above. It is possible to achieve this object and others by using a method and a communication node as defined in the attached independent claims.

According to one aspect, a method is performed by a communication node for communicating data in an Ethernet. In this method the communication node initially operates in a unidirectional mode by communicating data in only one direction, wherein acknowledge messages used for indicating whether data has been correctly received or not are allowed to be communicated in an opposite direction in the unidirectional mode. When detecting a mode switching trigger, the communication node operates instead in a bidirectional mode by both sending and receiving data, in response to the detected mode switching trigger. The data communicated in the bidirectional mode may comprise configuration messages in an updating or upgrading procedure. Thereby, the communication node cannot be manipulated by an intruder to act in a harmful way in the Ethernet when in the unidirectional mode. The bidirectional mode may be applied for only a limited time and under attentive control to avoid any harmful communication with an outside intruder.

According to another aspect, a communication node is arranged to communicate data in an Ethernet. The communication node is configured to operate in a unidirectional mode by communicating data in only one direction, wherein acknowledge messages used for indicating whether data has been correctly received or not are allowed to be communicated in an opposite direction. This functionality may be realized by means of a first operating module in the communication node.

The communication node is further configured to detect a mode switching trigger, which may be realized by means of a detecting module in the communication node. The communication node is also configured to operate in a bidirectional mode by both sending and receiving data, in response to the detected mode switching trigger. This functionality may be realized by means of a second operating module in the communication node. The above method and communication node may be configured and implemented according to different optional embodiments to accomplish further features and benefits, to be described below.

A computer program is also provided which comprises instructions which, when executed on at least one processor, cause the at least one processor to carry out the method described above. A carrier containing the above computer program is further provided, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

Brief description of drawings

The solution will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which:

Fig. 1 is a signaling diagram illustrating a communication scenario with two communication nodes operating in a unidirectional mode, according to some possible embodiments. Fig. 2 is a flow chart illustrating a procedure in a communication node, according to further possible embodiments.

Fig. 3 is a signaling diagram illustrating an example of a procedure when the solution is used, according to further possible embodiments.

Fig. 4 is a block diagram illustrating how an Ethernet bridge may be employed, according to further possible embodiments.

Fig. 5 is a flow chart illustrating an example of how a communication node may operate in the unidirectional mode, according to further possible embodiments.

Fig. 6 is a block diagram illustrating a communication node in more detail, according to further possible embodiments. Detailed description

Briefly described, a solution is provided for protection against attacks and other unwanted intrusion on communication nodes in an Ethernet based network, which solution does not entail high costs and complexity. This can be achieved by requiring nodes in the network to allow communication of data in one direction only, either receiving or sending data but not both, which is referred to herein as operating an a "unidirectional mode". Many communication nodes of today with relatively simple construction will still be able to provide functionality as required, such as a sensor node that only needs to send measurement data or the like to a control node or surveillance system, or an actuator node that only needs to receive instructions or sensor data, e.g. in real-time, for accurate operation of a machine part or the like. In this disclosure, the general term "communication node" is used to represent any entity capable of communicating data and messages in an Ethernet. The solution and embodiments described herein are defined in terms of functionality in a communication node.

By only allowing communication of data in one direction, it is not possible for an intruder to take over such a communication node since that would require communication of data in both directions. In the case of a transmit-only node, the intruder is not able to get across any malicious data to the node at all, such as a data program that could make the node act in a harmful way, since the node is not allowed or supposed to receive any data in the unidirectional mode. In the case of a receive-only node, the intruder might be able to send malicious data to the node but the node is not able to act in a harmful way by sending potentially harmful data to other nodes, since it is not allowed or supposed to send any data in the unidirectional mode, thereby not causing any harm in the network in this case either. In both cases, it is an advantage that the communication node thus cannot be manipulated to operate in any harmful way in the network. At the same time, it may be desirable to communicate data with high reliability which is normally achieved by implementing feedback communication of acknowledge messages in the opposite direction which the communicating node is allowed to perform in the unidirectional mode if needed, in addition to the oneway communication of data. For example, some higher layer protocols like TCP are designed to require acknowledge messages which are thus allowed in the opposite direction when in the unidirectional mode. The unidirectional mode as described herein thus allows for communication of data in one direction only and also communication of acknowledge messages in an opposite direction. It should be noted that different communication nodes in an Ethernet may be configured to use different communication directions for data in the unidirectional mode. However, after operating in the unidirectional mode for some time it is likely that the communication node will need to communicate data in the opposite direction as well, e.g. to enable an upgrade or update of the communication node which involves communication of configuration data and messages. In one example, a transmit-only node may need to get instructions and/or configuration data from a configuration or control node, e.g. to change or adjust its operation in some way. In another example, a receive-only node may need to send operational data or the like to a configuration or control node during a configuration procedure.

The above need for reverse communication of data at some point can be solved by switching from the unidirectional mode to an operation mode where data can be communicated in both directions, i.e. both receive and transmit, which is referred to herein as operating an a "bidirectional mode". It is thus possible to upgrade, update or reconfigure the communication node by temporarily using the bidirectional mode. When in the bidirectional mode for a limited period of time, the communication node may be carefully controlled and checked so as to detect and address any harmful communication with an outside intruder.

In this solution the communication node performs the switch from unidirectional mode to bidirectional mode in response to detecting a "mode switching trigger", which term is used herein to represent any input to the communication node for initiating the switch from unidirectional mode to bidirectional mode. For example, the mode switching trigger may comprise an "out-of-band" input such as a button or switch or the like on the communication node being pressed or pushed by some operation personnel. In another example, the mode switching trigger may be implemented as a predefined timeout or the like, e.g. in case reconfiguration or update of the communication node is performed at predefined intervals. For example, after powering the communication node, it may be made accessible by applying the bidirectional mode for a pre-defined duration. If the

communication node is not triggered to perform reconfiguration or update the communication node may fall back to unidirectional communication. Fig. 1 illustrates an example of how the above-described unidirectional mode may be employed in two exemplary communication nodes denoted a data source 100 which operates as a transmit-only node thus being allowed to send but not receive data, and a data destination 102 which operates as a receive-only node thus being allowed to receive but not send data. This solution basically concerns any communication nodes capable of operating in the unidirectional mode and both nodes 100 and 102 may thus operate in accordance with the embodiments described herein. In this example, a feedback function is employed in the unidirectional mode to ensure correct reception of the communicated data.

A first action 1 :1 illustrates that the data source 100 sends data and that the data destination 102 receives the data. Before sending data, the data source 100 adds a so-called Cyclic Redundancy Check, CRC, to each piece of data which CRC has been derived or calculated from the data, e.g. in the form of a checksum or the like. In some cases a Frame Check Sequence, FCS, may be used instead of or together with the CRC. Thereby, the data destination 102 can perform the same calculation of the received data and compare with the attached CRC, in an action 1 :2, to see if the data has been received correctly or not. In case the CRC matches the received data, the data destination 102 returns an acknowledge message ACK to the data source 100, as shown in an action 1 :3. The acknowledgment message may contain a sequence number or the like that indicates which data is acknowledged. In case the CRC does not match the received data, or if no data has been received at all, the data destination 102 may return a negative acknowledgement, NACK, or simply not return any ACK. As a result, the data source 100 resends the data + CRC to the data destination 102, in a final shown action 1 :4. Thus by allowing each communication node 100, 102 to only communicate acknowledge messages in an opposite direction when operating in the unidirectional mode, the data can be communicated with high reliability by being resent when needed, while avoiding an intruder to take over or otherwise manipulate any of the communication nodes 100 and 102. It should be noted that Fig. 1 illustrates only how the communication nodes may operate in the unidirectional mode, thus not illustrating operation in the bidirectional mode.

An example of how the solution may be employed in terms of actions performed by a communication node, such as any of the above-described communication nodes 100 and 102, is illustrated by the flow chart in Fig. 2 which will now be described. Fig. 2 thus illustrates a procedure in the communication node for communicating data in an Ethernet based network. Some optional example embodiments that could be used in this procedure will also be described below.

A first action 200 illustrates that the communication node operates in a

unidirectional mode by communicating data in only one direction. While in the unidirectional mode, another action 202 illustrates that the communication node is also allowed to communicate acknowledge messages in an opposite direction, i.e. opposite to the direction for communicating data. The acknowledge messages may be used for indicating whether data has been correctly received or not. For example, the communication node may send or receive a piece of data, e.g. a data packet, and then receive or send, respectively, an acknowledge message referring to that piece of data, such that actions 200 and 202 could be repeated successively any number of times, as indicated by a dashed arrow, before the following actions are performed.

It should be noted that in the unidirectional mode the communication node is allowed to communicate acknowledge messages in the opposite direction and the communication node can thereby decide whether to actually do so or not, which may depend on how important it is to ensure correct reception of the data and/or on how likely it is that the data is not received correctly.

In another action 204, the communication node detects a mode switching trigger, which thus can trigger the communication node to switch its mode of operation as follows. In some example embodiments, the mode switching trigger may be detected by receiving a predefined message or an out-of-band input to the communication node on any of: a button, a switch, a jumper block, an external console or control panel, and a firmware configured to boot on request. The predefined message may be a text message also referred to as an SMS. The above-mentioned firmware that boots on request will now be described. By default, a vendor may install a firmware in a device, i.e. communication node, which configures the device to operate in unidirectional mode. On booting up, the device may search for an alternative firmware. For example, if a technician inserts a USB stick to the device it may boot the firmware found on the USB stick.

Alternatively, the device may have two firmware versions stored. With a specific jumper being set, the device may boot the alternative firmware that enables bidirectional communication. Another alternative may be to access the device through a serial link, e.g. RS-232, which may be used to offer an alternative firmware to the device. Other means to load an alternative firmware may be through a Preboot execution Environment PXE. On boot-up, a device may send out so-called BOOTP or DHCP requests. Via the PXE an associated server may direct the device to a Trivial File Transfer Protocol TFTP server that allows the device to load and operate a firmware over the network.

Another action 206 illustrates that the communication node operates in a bidirectional mode, i.e. instead of operating in the unidirectional mode, by both sending and receiving data, in response to the detected mode switching trigger. In some examples this may be required to enable a configuration procedure where the communication node must communicate various configuration data and messages back and forth with a configuration node or the like. For example, when the communication node needs to be updated, upgraded or reconfigured, the above predefined message may be sent to the communication node in case it acts as a receive-only node, or alternatively the above button, switch, etc. may be pressed or otherwise manipulated on the node, so that the communication node starts to operate in a bidirectional mode. After operating in the bidirectional mode for a while, e.g. during a configuration procedure as mentioned above, the communication node may further detect a mode resuming trigger, such as a timeout of the bidirectional mode or a mode resuming message received from the configuration node, in an optional action 208. In a further shown optional action 210, the communication node may accordingly resume to operate in the unidirectional mode in response to the detected mode resuming trigger.

Some further example embodiments will now be described, which may be employed depending on whether the communication node operates as a send- only node or a receive-only node in the unidirectional mode. In one example embodiment, operating in the unidirectional mode may comprise sending data to a data destination and discarding any data that arrives at the communication node, thus operating as a send-only node. Thereby, the communication node is not able to store, use or forward any incoming harmful data, sometimes referred to as "malware". In another example embodiment, operating in the bidirectional mode may in that case comprise receiving configuration data for updating operation of the communication node.

In an alternative example embodiment, operating in the unidirectional mode may comprise receiving data from a data source and returning acknowledge messages to the data source, that is when the above-described feedback procedure is employed, thus operating as a receive-only node. Thereby, the communication node is not able to cause any harm in the Ethernet by sending or forwarding harmful data. In that case, another example embodiment may be that operating in the bidirectional mode comprises receiving and sending messages in a

configuration procedure for updating operation of the communication node.

An example of a communication involving a receive-only node will now be described with reference to Fig. 3, particularly illustrating the latter two

embodiments. Fig. 3 thus illustrates a first communication node 300, a second communication node 302 and a configuration node 304.

The receive-only first communication node 300 thus initially operates in the unidirectional mode which includes receiving data from the second communication node 302, as shown by a first action 3:1 A. The second communication node 302 may be a transmit-only node in the sense described above, or it may alternatively operate to both send and receive data and Fig. 3 is thus not limited in this respect. Another action 3:1 B illustrates that the first communication node 300 in the unidirectional mode may return acknowledgements to the second communication node 302, to confirm that the data has been received and decoded correctly, e.g. after checking a CRC or the like in the manner described above. Actions 3: 1 A and 3: 1 B may be repeated in the unidirectional mode until it is time to perform an update or upgrade of the first communication node 300, which may be initiated by a predefined message such as a text message or a manual input on a button, switch, or the like on the node 300.

Another action 3:2 illustrates that the first communication node 300 detects a mode switching trigger, and some examples of how this may be realized in practice have been described above. This triggers the first communication node 300 to switch from the unidirectional mode to the bidirectional mode in which the first communication node 300 can both receive and transmit data. When in the bidirectional mode, the first communication node 300 receives one or more configuration messages from the configuration node 304, as shown by an action 3:3A, and transmits one or more configuration messages to the configuration node 304, as shown by an action 3:3A. Actions 3:3A and 3:3B may thus be repeated a number of times until the update or upgrade of the first communication node 300 is completed. The configuration messages in action 3:3A may comprise configuration data that the first

communication node 300 needs to apply, while the configuration messages in action 3:3B may comprise operational data and acknowledgements that the first communication node 300 needs to provide to the configuration node 304. The embodiments described herein are not limited to any particular configuration procedure as such.

When the update or upgrade of the first communication node 300 has been completed, the first communication node 300 detects a mode resuming trigger in a following action 3:4, which may be a timeout of the bidirectional mode or a mode resuming message received from the configuration node 304, as described above for action 208. A final action 3:5 illustrates that the first communication node 300 accordingly resumes to operate in the unidirectional mode by only receiving data but not transmitting any data.

Some further example embodiments of how the communication node may operate are as follows. In one example embodiment, operating in the bidirectional mode may comprise sending a registration message for subscribing to a multicast stream. The registration message, also known as a "multicast registration frame", may be sent to a specific port of another communication node, such as an

Ethernet bridge, that conveys a streaming service by multicasting a data stream to a plurality of communication nodes. It may be possible to allow the communication node to send such a registration message also in the unidirectional mode, even if the node operates as a receive-only node.

In another example embodiment, operating in the unidirectional mode may comprise communicating acknowledge messages in the opposite direction when a certain level of incorrect reception of the data is expected and/or when correct reception of the data is required. It is thus not always motivated or desired to employ a feedback function that acknowledges correct reception of data.

In further example embodiments, the communication node may resume to operate in the unidirectional mode, as in actions 210 and 3:5, e.g. after a predetermined duration from switching to the bidirectional mode or in response to detecting a mode resuming trigger as in actions 208 and 3:4.

In another example embodiment, the data and the acknowledge messages may be communicated with an Ethernet bridge which is connected to other

communication nodes in the Ethernet. In another example embodiment, the above-described mode switching trigger may be received from the Ethernet bridge 400. In that case, another example embodiment may be that when operating in the bidirectional mode, the communication node may receive from the Ethernet bridge 400 a mode resuming trigger to operate in the unidirectional mode, which corresponds to the above-described mode resuming trigger in actions 208 and 3:4. An example of how an Ethernet bridge may be employed in a vehicle is illustrated in Fig. 4 where the Ethernet bridge 400 is connected to various communication nodes in the Ethernet where arrows indicate whether the respective

communication nodes are receive-only nodes, transmit-only nodes or nodes configured for two-way communication.

In this example, an engine oil temperature may be measured by a simple sensor 402. The engine oil temperature sensor 402 will repetitively send its measurement data to a certain multicast address which means that the data will be

communicated from the Ethernet bridge 400 to multiple communication nodes. For every correctly received piece of data the Ethernet bridge 400 will send an acknowledge message to the engine oil temperature sensor 402, allowing the engine oil temperature sensor402 to retransmit any data that is not

acknowledged.

A dashboard display 404 may operate as a receive-only node. It has registered for the engine oil temperature sensor's messages with the Ethernet bridge 400, allowing the dashboard display 404 to receive measurement data from the engine oil temperature sensor 402. An engine control unit 406 may likewise have registered for the engine oil temperature sensor's messages with the Ethernet bridge 400 and the following description of the dashboard display 404 may also apply to the engine control unit 406.

For every successfully received message with temperature data, the dashboard display 404 will generate an acknowledgment message to the Ethernet bridge 400 indicating that the message with temperature data can be deleted from buffer at a corresponding port of the Ethernet bridge 400. Using the multicast registration message the dashboard display 404 will not receive any other messages that may be transmitted to the Ethernet bridge 400. Furthermore, the dashboard display 404 operates as a receive-only node, thus preventing it to act harmfully when addressed or contacted by an attacker.

An example of how a communication node may operate as a transmit-only node in the unidirectional mode will now be described with reference to the flow chart in Fig. 5. The communication node will thus be referred to as a source node in this example. A first action 500 illustrates that the source node sends data towards a destination node, when operating in the unidirectional mode. The destination node may or may not operate in a unidirectional mode which is outside the scope of this example. It is assumed that a feedback procedure is employed where the destination node is required to acknowledge correct reception of data from the source node, e.g. as described above for Fig. 1 .

A next action 502 indicates that the source node detects that a message has arrived at the source node. It then determines in an action 504 whether the arrived message contains an acknowledgement frame or not, according to the ongoing feedback procedure. When operating in the unidirectional mode, the source node is only allowed to receive acknowledge messages and no other data or messages, e.g. as described for action 202 above. If the arrived message does not contain any acknowledgement frame, the source node will discard the message, as shown in an action 506.

On the other hand, if it is determined in action 504 that the arrived message actually does contain an acknowledgement frame, which the source node is thus allowed to receive, the source node duly receives and processes the

acknowledgement frame in another action 508. If the acknowledgement frame in the message indicates that data sent by the source node has not been received and decoded correctly by the destination node, the source node may retransmit the non-acknowledged data to the destination node, as indicated by an action 510. After either of actions 506 and 510, the process may be repeated by returning to action 500. The block diagram in Fig. 6 illustrates a detailed but non-limiting example of how a communication node 600 may be structured to bring about the above-described solution and embodiments thereof. In this figure, the communication node 600 may be configured to operate according to any of the examples and embodiments of employing the solution as described herein, where appropriate. The

communication node 600 is shown to comprise a processor "P", a memory "M" and a communication circuit "C" with suitable equipment for transmitting and receiving data and messages in the manner described herein.

The communication circuit C in the communication node 600 thus comprises equipment configured for communication with any opposite communication node using a suitable protocol for the communication depending on the implementation. The solution is however not limited to any specific types of messages or protocols. The communication node 600 is, e.g. by means of units, modules or the like, configured or arranged to perform at least some of the actions of the flow chart in either of Figs 2 and 5 and as follows. The communication node 600 is arranged to communicate data in an Ethernet. The communication node 600 is configured to operate in a unidirectional mode by communicating data in only one direction, wherein acknowledge messages used for indicating whether data has been correctly received or not are communicated in an opposite direction. This operation may be performed by a first operating module 600A in the communication node 600, as illustrated in actions 200 and 202. This means that the communication node 600, e.g. the first operating module 600A therein, is configured to either send or receive data, but not both, and further configured to receive or send, respectively, only acknowledge messages related to the data in the opposite direction. The first operating module 600A could alternatively be named a unidirectional or one-way communication module.

The communication node 600 is further configured to detect a mode switching trigger. Some non-limiting examples of how a mode switching trigger could be detected have been described above. This operation may be performed by a detecting module 600B in the communication node 600, as illustrated in action 204. The detecting module 600B could alternatively be named a logic module, a mode switching module or a triggering module.

The communication node 600 is further configured to operate in a bidirectional mode by both sending and receiving data, in response to the detected mode switching trigger. This operation may be performed by a second operating module 600C in the communication node 600, as illustrated in action 206. The second operating module 600C could alternatively be named a bidirectional or two-way communication module.

It should be noted that Fig. 6 illustrates various functional modules in the communication node 600, and the skilled person is able to implement these functional modules in practice using suitable software and hardware equipment. Thus, the solution is generally not limited to the shown structure of the

communication node 600 and the functional modules therein may be configured to operate according to any of the features, examples and embodiments described in this disclosure, where appropriate. The functional modules 600A-C described above may be implemented in the communication node 600 by means of program modules of a computer program which may be run by a processor P. The processor P may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units. For example, the processor P may include a general purpose microprocessor, an instruction set processor and/or related chips sets and/or a special purpose microprocessor such as an Application Specific Integrated Circuit (ASIC). Each processor P may also comprise a storage for caching purposes.

The computer program may be carried by a computer program product in the communication node 600 in the form of a memory having a computer readable medium and being connected to the processor P. The computer program product or memory M in the communication node 600 thus comprises a computer readable medium on which the computer program is stored e.g. in the form of computer program modules or the like. For example, the memory M may be a flash memory, a Random-Access Memory (RAM), a Read-Only Memory (ROM) or an Electrically Erasable Programmable ROM (EEPROM), and the program modules could in alternative embodiments be distributed on different computer program products in the form of memories within the communication node 600.

The solution described herein may thus be implemented in the communication node 600 by a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions according to any of the above embodiments and examples, where appropriate. The solution may also be implemented at the communication node 600 in a carrier containing the above computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

While the solution has been described with reference to specific exemplifying embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the solution. For example, the terms "Ethernet", "communication node", "Ethernet bridge",

"acknowledge message", "unidirectional mode", "bidirectional mode", "mode switching trigger" and "mode resuming trigger" have been used throughout this disclosure, although any other corresponding entities, functions, and/or

parameters could also be used having the features and characteristics described here. The solution is defined by the appended claims.

Claims

1 . A method performed by a communication node (100, 102) for communicating data in an Ethernet, the method comprising:

- operating (200) in a unidirectional mode by communicating data in only one direction, wherein acknowledge messages used for indicating whether data has been correctly received or not are allowed to be communicated (202) in an opposite direction in the unidirectional mode,

- detecting (204) a mode switching trigger, and

- operating (206) in a bidirectional mode by both sending and receiving data, in response to the detected mode switching trigger.

2. A method according to claim 1 , wherein the mode switching trigger is detected by receiving a predefined message or an out-of-band input to the communication node (100, 102) on any of: a button, a switch, a jumper block, an external console or control panel, and a firmware configured to boot on request.

3. A method according to claim 1 or 2, wherein operating in the

unidirectional mode comprises sending (500) data to a data destination and discarding (506) any data that arrives at the communication node (100, 102).

4. A method according to claim 3, wherein operating in the bidirectional mode comprises receiving configuration data and messages for updating operation of the communication node (100, 102).

5. A method according to claim 1 or 2, wherein operating in the

unidirectional mode comprises receiving (3: 1 A) data from a data source (302) and returning (3: 1 B) acknowledge messages to the data source.

6. A method according to claim 5, wherein operating in the bidirectional mode comprises receiving (3:3A) and sending (3:3B) data and messages in a configuration procedure for updating operation of the communication node (300).

7. A method according to claim 5 or 6, wherein operating in the bidirectional mode comprises sending a registration message for subscribing to a multicast stream.

8. A method according to any of claims 1 -7, wherein operating in the unidirectional mode comprises communicating acknowledge messages in the opposite direction when a certain level of incorrect reception of the data is expected and/or when correct reception of the data is required.

9. A method according to any of claims 1 -8, wherein the communication node (100, 102) resumes (210) to operate in the unidirectional mode after a predetermined duration from switching to the bidirectional mode or in response to detecting a mode resuming trigger (208).

10. A method according to any of claims 1 -9, wherein the data and the acknowledge messages are communicated with an Ethernet bridge (400) which is connected to other communication nodes in the Ethernet.

1 1 . A method according to claim 10, wherein said mode switching trigger is received from the Ethernet bridge (400).

12. A method according to claim 1 1 , wherein when operating in the bidirectional mode, the communication node (100, 102) receives from the Ethernet bridge (400) a mode resuming trigger to operate in the unidirectional mode.

13. A communication node (600) arranged to communicate data in an Ethernet, wherein the communication node (600) is configured to:

- operate (600A) in a unidirectional mode by communicating data in only one direction, wherein acknowledge messages used for indicating whether data has been correctly received or not are allowed to be communicated (202) in an opposite direction,

- detect (600B) a mode switching trigger, and - operate (600C) in a bidirectional mode by both sending and receiving data, in response to the detected mode switching trigger.

14. A communication node (600) according to claim 13, wherein the communication node (600) is configured to detect the mode switching trigger by receiving a predefined message or an out-of-band input to the communication node on any of: a button, a switch, a jumper block, an external console or control panel, and a firmware configured to boot on request.

15. A communication node (600) according to claim 13 or 14, wherein when operating in the unidirectional mode the communication node (600) is configured to send data to a data destination and discard any data that arrives at the communication node (100, 102).

16. A communication node (600) according to claim 15, wherein when operating in the bidirectional mode the communication node (600) is configured to receive configuration data and messages for updating operation of the

communication node (100, 102).

17. A communication node (600) according to claim 13 or 14, wherein when operating in the unidirectional mode the communication node (600) is configured to receive data from a data source and return acknowledge messages to the data source.

18. A communication node (600) according to claim 17, wherein when operating in the bidirectional mode the communication node (600) is configured to receive and send data and messages in a configuration procedure for updating operation of the communication node (300).

19. A communication node (600) according to claim 17 or 18, wherein when operating in the bidirectional mode the communication node (600) is configured to send a registration message for subscribing to a multicast stream.

20. A communication node (600) according to any of claims 13-19, wherein when operating in the unidirectional mode the communication node (600) is configured to communicate acknowledge messages in the opposite direction when a certain level of incorrect reception of the data is expected and/or when correct reception of the data is required.

21 . A communication node (600) according to any of claims 13-20, wherein the communication node (600) is configured to resume operation in the

unidirectional mode after a predetermined duration from switching to the bidirectional mode or in response to detecting a mode resuming trigger.

22. A communication node (600) according to any of claims 13-9, wherein the communication node (600) is configured to communicate the data and the acknowledge messages with an Ethernet bridge which is connected to other communication nodes in the Ethernet.

23. A communication node (600) according to claim 22, wherein the communication node (600) is configured to receive said mode switching trigger from the Ethernet bridge.

24. A communication node (600) according to claim 23, wherein when operating in the bidirectional mode, the communication node (600) is configured to receive from the Ethernet bridge a mode resuming trigger to operate in the unidirectional mode.

25. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 -12.

26. A carrier containing the computer program of claim 25, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.