User Guide > Ethernet flow

Ethernet flow

Ethernet Frame and UDP Datagram

By defining an Ethernet Frame or UDP Datagram, a Host in your system model can periodically send a data message in the form of an IPDU to one or several other Hosts connecting to an Ethernet network. The difference between an Ethernet Frame and a UDP Datagram is that the latter is placed in an Internet Protocol version 4 datagram (IPv4) and supports fragmentation thereby allowing very large IPDUs to be transmitted over an Ethernet network as a string of Ethernet frames.

In a future release of TCN TimeAnalysis, the Transmission Control Protocol (TCP) will be supported as well.

To add a new Ethernet Frame or UDP Datagram to your system model, right-click on a Host Ethernet port in the Topology/Tree View and select the item of interest .

This will open the Ethernet Frame or UDP Datagram dialog:

Captured Stream

The autonomous car of the future will likely have to rely on a multitude of cameras that records the surroundings of a vehicle in different directions. Furthermore, Ethernet is a strong candidate for the in-vehicle backbone in next generation electrical architectures and like ordinary web cameras, automotive cameras can stream a continuous string of Ethernet frames over such a backbone.

If a physical, automotive grade camera or other Ethernet based sensor is available, its outbound traffic can be recorded by a program like Wireshark or a datalogger and stored in a PCAP file. Given such a capture file, you can quickly make a digital twin model of the sensor and incorporate it into a virtual network by creating a Sensor node, associate the PCAP file with the Sensor and then add a Stream to the Sensor. Via the Stream you can specify, for example, which Hosts will receive the camera Stream. Unlike a physical camera, its digital twin counterpart can easily be replicated and positioned to inject several camera streams at different places in a network model.

The time stamps found within the capture file will be used to specify at which points in time the sensor injects packets into the network. See also Offset below. For best results, the bit speed of the Sensor should be selected to be the same as the bitspeed used by the physical sensor counterpart.

To add a new Stream to your system model, right-click on a Sensor port in the Topology/Tree View and select the Captured Stream item.

This will open the Captured Stream dialog:

Properties

VLAN

Shows which VLAN a Flow will be assigned to when it leaves its source Host or Sensor and enters the link partner Switch. Default is VLAN 1. You can change this by creating a new VLAN and assign it to the Switch port, which is the link partner port of the Flow’s source Host or Sensor port.

Paths

Select Paths from the list of all reachable Target Hosts to specify which Hosts should receive the string of Ethernet frames produced by a Flow.

By selecting the Broadcast checkbox, all available Paths will be used. Broadcasting a Flow implies that all Ethernet frames originating from your Flow will be broadcasted within the VLAN of the Flow using the MAC broadcast address FF:FF:FF:FF:FF:FF.

Note! If the network originating from the Source contains cycles in the VLAN, Broadcast is not allowed.

Note! If the network originating from the Source contains cycles in the IPDU, Broadcast is not allowed.

Furthermore the following rules apply:

Cycle detection is enforced at all times - if you have a broadcast flow and manipulates the network in such a way that cycles emerges in the network covered by the flow, the flow will be removed.

MAC-address

If more than one Path is selected, the Ethernet frames of the Flow will be forwarded using MAC multicast. You are then required to specify a unique MAC multicast address defining the MAC multicast group to which the Stream belongs and this field will be activated.

By clicking the item to the right, a suitable MAC multicast address will be selected automatically.

Wrap Around Delay (Captured Stream only)

A Stream reads Ethernet frames from the capture file specified in the associated Sensor and releases them in accordance with the time stamp recorded with each frame. When the last Ethernet frame in the capture file has been read and released, the Stream will wrap around so that next time the first frame in the file will be read again. Typically, the time stamp of the first Ethernet packet stored in a capture file has a time stamp of 0, so to avoid that the last and first Ethernet frames in the file are released back to back, the Wrap Around Delay can be used to create a gap in time between the last and the first Ethernet frames when wrap-around occurs.

For example, the default capture file specified when a new Sensor is created is the file GenericCamera.hea, which comes with the installation of TCN TimeAnalysis. This file contains a recording of the Ethernet frames transmitted by an automotive grade camera. Typically, each video frame in the video stream corresponds to series of Ethernet frames that are transmitted quite close in time followed by a slightly larger gap before the next cluster of Ethernet frames occurs. By inspection of the file, it has been established that this gap is approximately 2.78 ms, so this is thus a suitable value for the Wrap Around Delay parameter for the capture file GenericCamera.hea.

Priority

When an IPDU is encapsulated in a UDP datagram, the UDP datagram is in turn encapsulated in an IPv4 datagram and the priority specified is placed into the IP ToS bits of the IPv4 header field. Finally, the IPv4 frame is encapsulated in an Ethernet frame that is passed to the egress interface of the Host’s Ethernet output port for transmission onto the Link connecting the Host to an Ethernet Switch.

In the case of a Sensor transmitting a Stream, recorded Ethernet frames are read from the capture file associated with the Sensor. Before such an Ethernet frame is transmitted, its header is inspected and, if it encapsulates an IPv4 frame, the priority associated with the Stream is written to the IP ToS bits of the IPv4 header.

FRER (not Captured Stream at the moment)

As described in [1], FRER stands for Frame Replication and Elimination for Reliability and allows Switches and Hosts to identify specific packets, duplicate them and forward them along different paths to the same end Host(s). Thereby, redundancy can be achieved increasing the likelihood of packets containing time-sensitive or critical data to reach their designated end Host(s) despite link or node failure along the original path. As long as the network remains intact, FRER functions will identify and eliminate duplicate packets in device Ports where redundant paths merge to avoid multiple copies of the same packet ever reaching an end Host.

Initial support for FRER is introduced in version 2.2 of TCN TimeAnlaysis and extended support for this standard will be added in future releases of the tool. Currently, the main limitations are:

In version 2.2, the GUI does not explicitly expose the different FRER tables defined in [1] to the user for configuration and management of the different FRER functions that perform packet replication, elimination etc. Instead, for increased user friendliness, algorithms based on specific rules will automatically figure out which FRER functions to instantiate in which Switch ports along the paths of the multicast flow selected for a FRER flow. The image below shows a simple example based on a multicasted UDP Datagram; as can be seen, redundancy has been activated for this flow by checking the box labeled FRER. Unlike ordinary multicast flows, for FRER flows it is allowed to specify multiple paths that reach the same end Host. In the figure, it can be seen that two different paths reach Host2 and the remaining three paths specify Host3 as target. See subsection Paths above for specific rules governing the specification of paths in FRER multicast flows.

As stated above, as soon as the user has activated FRER and specified the different paths to target Hosts, algorithms will investigate on which links the different paths overlap and automatically instantiate the required FRER functions needed in the different ports. Given a Switch port, a limited number of situations can occur depending on how many redundant paths that pass a particular port, if any, whether packet replication or elimination is required in the port etc. By selecting the FRER tab in the dialog in the previous image, the Stream Table shown in the below image is opened. This table gives an overview of which situations has been identified occuring in the different Switch ports involved in forwarding the FRER packets.

Strategy

There is often a choice with regards to the instantiation of different FRER functions into different Ports in a network. For example, the FRER sequence generation function can typically be instantiated in a Host Port or the corresponding link partner Switch Port. As explained below, the following three check boxes influence the strategies used to automatically instantiate different FRER functions into the different Host and Switch Ports in a network. A benefit from being able to influence the placement of the FRER functions is that backward compatibility with existing switches and/or end stations, that are not aware of FRER, increases.

Regular

If this box is checked, FRER functions will be removed from ports in which they are not strictly needed. Typically, FRER functions removing and applying the Redundancy tag (R-TAG) in Switch Ports will be removed from Switches that do not perform any sequence generation or recovery.

Host generate

If this box is checked, sequence generation functions will be instantiated in Host Ports instead of the corresponding link partner Switch Ports.

Host recovery

If this box is checked, sequence recovery functions will be instantiated in Host Ports instead of the corresponding link partner Switch Ports.

Generate

In this kind of port, a sequence number will be generated identifying the order in which a packet belonging to a FRER flow was transmitted relative to other packets in the same flow.

Output

In a port marked as Output port, functions will identify the packets belonging to a FRER flow and then explicitly encode the sequence number into a packet by adding an R-TAG into its header.

Input

In this kind of port, functions will identify the packets belonging to a FRER flow and then extract the sequence number from an R-TAG found in the packet’s header.

Terminate

In a Terminate port, different redundant paths merge and duplicate packets that have already been seen by the FRER functions are discarded. This is typically done in the Switch port that connects to a target Host and an R-TAG is not inserted into any FRER packet.

Continue

This is like a Terminate port, however, the recovery and elimination is performed in an intermediate Switch port and the FRER packets leaving this kind of port need to contain an R-TAG.

Algorithm

In Ports where a sequence recovery function is instantiated, a choice can be made regarding which recovery algorithm to use; select Vector to employ the VectoryRecoveryAlgorithm or Match to employ the MatchRecoveryAlgorithm.

History Length

This parameter has only meaning when the VectoryRecoveryAlgorithm is used. It then specifies how many bits of the SequenceHistory variable that are to be used.

Actions

The following actions are available for existing Flows - right-click on an Ethernet Frame/UDP Datagram/Stream in the Tree View:

     
Edit Opens the Flow dialog in edit mode.
Delete Removes the Flow from the topology.
Add Timer Opens the New Timer dialog.

References

  1. IEEE Standard 802.1CB-2017