Background: Adding frame tags to your frame blasting streams - structure and behaviour [legacy; drafted; with algnment info]
Posted by Tim De Backer, Last modified by Dries Decock on 03 April 2018 02:13 PM
FrameTags are added to a ByteBlower Frame object and can be used to automatically insert dynamic information into the different frames of a ByteBlower traffic stream.
Consider a ByteBlower Port on which a Tx.Stream is created. A Frame is added to the stream. The content of a frame is static and can be set using the Bytes.Set function. The following code shows how to create this situation in the Tcl API:
The static bytes of a frame can be changed by calling the Bytes.Set function again. This can be done at all times, even while the Tx.Stream is being transmitted! However, changing the static bytes of a frame is a client-side action. FrameTags allow changing the frame content automatically and at the server side.
Adding a FrameTag to a Frame object causes the following things to happen for each individual frame in the traffic stream:
This entry will show...
Types of FrameTags
Currently two FrameTags exist:
Note that to perform latency measurements and/or out of sequence detection, the test script needs to be configured at two different places:
This post only describes the TX side! See relevant posts on latency and out of sequence detection for more information.
Adding a FrameTag to a Frame
Adding a FrameTag to a Frame object is very simple. Just retrieve the relevant FrameTag object on the frame and enable it.
Note that there are deprectated functions to enable a specific tag directly from the frame object. These are only preserved for backwards compatibility and their behaviour is identical to the two lines of code above.
Adding multiple FrameTags is also possible.
Every FrameTag has a fixed set of properties:
Apart from the position, which can be explicitly set, these properties properties have fixed values and defined by two things:
The current tag metrics are:
The current tag formats are:
Note that in future multiple tags and even metrics may be supported by the various server types (either at the TX side, the RX side or both sides). This could allow some interoperability between server series.
FrameTag insertion mechanism
This section will explain exactly how a tag is inserted into a frame.
Case 1: Alignment value is 1
When the alignment value is 1, the tag can be inserted into the frame at every byte. The tag is inserted as follows:
Requirement: The tag position should always be larger than its length. If a smaller position is set, an error will be thrown (even if that FrameTag is currently disabled).
Case 2: Alignment value is greater than 1
When the alignment value is greater than 1, the exact position of the tag value cannot be determined by the API. Specifically, when a FrameSizeModifier is applied to the frame, the tag position (which is a constant offset relative to the end of the frame), will be located at different positions relative to the start of the frame when the frame size changes.
This means an extra offset is needed and that this extra offset can vary between different frames.
The tag is inserted as follows:
Requirement: The tag position should always be larger than its length. If a smaller position is set, an error will be thrown (even if the FrameTag is currently disabled!)
The best case occurs, when the position matches the frames alignment. In this case:
The worst case occurs, when the position points to 1 byte before the frames alignment. In this case:
Multiple tags can be added into a single frame object. Each of them has its own position and based on that position, some space in the frame is reserved for it. The reserved space is equal to the maximum space that could be needed in the worst aligning situation.
The interval for the worst alignment case of a FrameTag is equal to [position+alignment-1, position-length[. When the alignment is 1, this boils down to [position, position-length[ as one might expect. Note that in these intervals the left boundary is larger then the right, because a larger value means closer to the start of the frame.
Requirement: The positions of all enabled tags must be chosen so that their reserved spaces do not overlap. Enabling a FrameTag whose reserved space would overlap with another enabled FrameTag's reserved space will throw an error.
Automatic placement of FrameTags has multiple advantages:
The automatic behaviour is determined by the transmitting server type. The general principles that define the automatic behaviour are:
1000 series examples
In the 1000 series both tags have an alignment of 1. This means we can place both tags at any position in the frame.
Example 1: Full automatic behaviour
The tags are placed at the end of the frame. If both are enabled, the SequenceTag is placed before the TimeTag:
Example 2: TimeTag has an explicit position
The explicit position is always respected. If the TimeTag position is greater than or equal to 16, the SequenceTag can be placed behind it. If it is less than 16, the SequenceTag is placed right in front of the TimeTag.
Note this works in a similar manner when the SequenceTag has an explicit position.
2000 series examples
In the 2000 series the TimeTag has an alignment of 8, while the SequenceTag has an alignment of 1.
Example 1: Full automatic behaviour
Tags are placed at the end of the frame. If both tags are enabled, the TimeTag is placed before the SequenceTag. Note this is the opposite from the 1000 series! We place the SequenceTag last, because it has an alignment of 1 and thus has a fixed length.
Example 2: TimeTag has an explicit position
The explicit position is always respected. If the TimeTag position is greater than or equal to 17, the SequenceTag can be placed behind it. If not, the SequenceTag is placed in front of it. Note that when its placed in front of it, it respects the reserved interval of the TimeTag!
Minimally required frame sizes
Positioning FrameTags automatically places them as close to the end of the frame as possible. Even so, tagging takes up space, so our frame should have at least a minimal payload so the frame headers are not overwritten.
The table below shows the minimal frame size for various frame header and tagging combinations:
Note that frame sizes with an asterisk (*) are smaller than 60 bytes, the minimum frame size required by the Ethernet specification.
Passing FrameTag settings to triggers at the RX side
Adding a TimeTag or SequenceTag to a Frame object is not enough to perform latency or out of sequence detection tests. At the receiving ByteBlower port, a corresponding receiver must be created. Adding receivers for both can be done as follows:
We will not discuss how to use these receivers here. See the relevant posts on latency and out of sequence detection tests for more information.
What is important is how to pass the TimeTag and/or SequenceTag information (at the TX side) to a Latency and/or OutOfSequence receiver (at the RX side). This is needed because:
The default metric and format values are the same as the default TX values for that server type (see above). Note that in future, servers may have support for multiple metrics and formats and that RX support may differ from TX support. For example, a server may need an alignment of 8 to insert a TimeTag, while being able to read TimeTags at any position.
The default position values are:
Note these values correspond with the positions of the tags when they are used by themselves and positioned automatically. Note, that these default RX settings are always incorrect when using multiple FrameTags in a frame, even when all of them are positioned automatically by the server!
Therefore, passing the FrameTag properties to the RX side, should always be done explicitly by the client script. For a situation where both tags are used, this can be done as follows: