Port Transmit Capabilities
The Ixia module ports format data to be transmitted in a hierarchy of structures:
- Streams and Flows-A set of related packet bursts
- Bursts and the Inter-Burst Gap (IBG)-A repetition of packets
- Packets and the Inter-Packet Gap (IPG)-Individual packets/frames
Timing of transmitted data is performed by the use of inter-stream, -burst, and -packet gaps. Ethernet modules use all three types of gaps, programmed to the resolution of their internal clocks. POS modules gaps are implemented by use of empty frames and the resolution of the gap is limited to a multiple of such frames. ATM modules do not use inter-stream or inter-packet gaps, and instead control the transmission rate through empty frames. The three types of gaps are discussed in:
- Streams and the Inter-Stream Gap (ISG)
- Bursts and the Inter-Burst Gap (IBG)
- Packets and the Inter-Packet Gap (IPG)
The percentage of line rate usage for ports is determined using the following formula:
(packet size + 12 byte IPG + requested preamble)/ (packet size + requested IPG + requested preamble) * 100
Streams and Flows
The Ixia system uses sophisticated models for the programming of data to be transmitted. There are two general modes of scheduling data packets for transmission:
- Sequential: The first configured stream in a set of streams is transmitted completely before the next one is sent, and so on, until all of the configured streams have been transmitted. Two types are available:
- Packet Streams
- Packet Flows (available on certain modules)
- Interleaved: The individual packets in the streams are multiplexed into a single stream, such that the total packet rate is the sum of the packet rates for each of the streams. One type is available:
- Advanced Streams (Advanced Stream Scheduler feature)
ATM modules support up to 15 independent stream queues, each of which may contain multiple streams. Up to 4096 total streams may be defined. See Stream Queues.
Packet Streams
This sequential transmission model is supported by the Ixia load modules, where dedicated hardware can be used to generate up to 255 Packet Streams `on-the-fly,' with each stream consisting of up to 16 million bursts of up to 16 million packets each. Transmission of the entire set of packet streams may be repeated continuously for an indefinite period, or repeated only for a user-specified count. The variability of the data within the packets is necessarily generated algorithmically by the hardware transmit engine.
Note: Streams consisting of only one packet are not transmited at wire speed. Also, streams set to random frame size generation does not have accurate IP checksum information. See the IxExplorer Users Guide, Chapter 4, Stream and Flow Control, for more information on creating streams.
Packet Flows
A second sequential data transmission model is supported by software for any Ixia port which supports PacketFlows. An individual packet flow can consist of from 1 to 15,872 packets. For packet flows consisting of only one unique packet each, a maximum of 15,872 individual flows can be transmitted. Because the packets in each of the packet flows is created by the software, including User Defined Fields (UDF) and checksums, and then stored in memory in advance of data transmission, there can be more unique types of packets than is possible with streams. Continuous transmission cannot be selected for flows, but by using a return loop, the flows can be retransmitted for a user-defined count.
Packet streams, which can contain larger amounts of data, are based on only one packet configuration per stream. In contrast, many packet flows can be configured for a single data transmission, where each flow consists of packets with a configuration unique to that flow. Some load modules permit saving/loading of packet flows.
Advanced Streams
A third type of stream configuration is called Advanced Streams, which involves interleaving of all defined streams for a port into a single, multiplexed stream. Each stream is assigned a percentage of the maximum rate. The frames of the streams are multiplexed so that each stream's long-term percentage of the total transmitted data rate is as assigned. When the sum of all of the streams is less than 100% of the data rate, idle bytes are automatically inserted into the multiplexed stream, as appropriate.
Example of Advanced Stream Generation

Stream Queues
Stream queues allow standard packet streams to be grouped together. Up to 15 stream queues may be defined, each containing any number of streams so long as the total number of streams in all queues for a port does not exceed 4,096. Each queue is assigned a percentage of the total and traffic is mixed as in advanced streams. Each queue may represent any number of VPI/VCI pairs; the VPI/VCI pairs may also be generated algorithmically.
Basic Stream Operation
When multiple transmit modes are available, the transmit mode for each port must be set by you to indicate whether it uses streams, flows, or advanced stream scheduling. The programming of sequential streams or flows is according to the same programming model, with a few exceptions related to continuous bursts of packets. Since the model is identical in both cases, we refer to both streams and flows as `streams' while discussing programming.
There are three basic types of sequential streams:
- Continuous Packet: A continuous stream of packets. The packets are not necessarily identical; their contents may vary significantly. (Not available for packet flows.)
- Continuous Burst: A set of counted packets within a burst; the burst is repeated continuously. (Not available for packet flows.)
- Fixed Count Burst: A fixed number of bursts of packets generated in a stream. This stream has a specified number of packets per burst and a specified number of bursts per stream.
Each non-continuous stream is related to the next stream by one of four modes:
- Stop after this stream: Data transmission stops after the completion of the current stream. (For example, after transmission of a stream consisting of 10 bursts of 100 packets each.)
- Advance to Next: Data transmission continues on to the next stream after the completion of the current stream.
- Return to ID: After the completion of the current stream, a previous stream (designated by its Stream ID) is retransmitted once, and then transmission stops.
- Return to ID for Count: After the completion of the current stream, a previous stream (designated by its Stream ID) is retransmitted for the user-specified number of times (count), and then transmission stops.
If a Continuous Packet or Continuous Burst stream is used, it becomes the last stream to be applied and data transmission continues until a Stop Transmit operation is performed.
Streams and the Inter-Stream Gap (ISG)
A programmable Inter-Stream Gap (ISG) can be applied after each stream, as shown in the following figure.
Figure: Inter-Stream Gap (ISG)

The size and resolution of the Inter-Stream Gaps depends on the particular Ixia module in use. For all modules except 10 Gigabit Ethernet modules, the stream uses the parameters set in the following stream. In 10 Gigabit Ethernet modules, it uses the parameters set in the preceding stream. There are no ISGs before Advanced Scheduler Streams. For non-Ethernet modules, the ISG is implemented by use of empty frames and the resolution of the ISG is limited to a multiple of such frames.
Bursts and the Inter-Burst Gap (IBG)
Bursts are sets of a specified number of packets, separated by programmed gaps between the sets. For Ethernet modules, Inter-Burst Gaps (IBG) are inserted between the sets. For POS modules, bursts of packets are separated by Burst Gaps. ATM modules do not insert IBGs. The size and resolution of these gaps depends on the type of Ixia load module in use. The placement of Inter-Burst Gaps is shown in the following figure.
Figure: Inter-Burst Gap (IBG)/Burst Gap

Packets and the Inter-Packet Gap (IPG)
Streams may contain a counted number of frames, or a continuous set of frames when Continuous Packet mode is used. Frames are separated by programmable Inter-Packet Gaps (IPGs), sometimes referred to as Inter-Frame Gaps (IFGs). The size and resolution of the Inter-Packet Gaps depends on the particular Ixia module in use. For non-Ethernet modules, the ISG is implemented by use of empty frames and the resolution of the IPG is limited to a multiple of such frames. ATM modules do not insert IBGs.The placement of Inter-Packet Gaps is shown in the following figure.
Figure: Inter-Packet Gap (IPG)

Frame Data
The contents of every frame and packet are programmable in terms of structure and data content. The programmable fields are:
- Preamble or Header contents
- Ethernet modules: Preamble Size: The size and resolution depends on the particular Ixia load module used.
- POS modules: Minimum Flag and Header contents: The minimum number of flag fields to precede the packet within the POS frame and the type of encapsulation/signalling.
- ATM modules: Header contents.
- Frame size: The size and resolution depends on the particular Ixia load module used.
- Destination and Source MAC Addresses (Ethernet only): Allows the MAC addresses to be set to constants, vary randomly, or increment/decrement using a mask.
- Data generators: Five different data generators are available. These generators are listed as follows, in order of increasing priority (from top to bottom). The values from generators located lower in this list override data from those higher in the list.
- Protocol-related data: Formatted to correspond to particular data link, transport, and protocol conventions.
- Data link layer controls for Ethernet allow for Ethernet II/SNAP, 802.3 Raw and 802.3 IPX formatting, with support for VLANs, MPLS, and Cisco-proprietary ISL. VLANs are described in Virtual LANs.
- Protocol-specific data for formatting IPv4, IPv6, and IPX packets (such as Source and Destination IP addresses), as well as Layer 4 transport protocol headers (TCP/IP, IGMP, and so on) are also supported. IPv4/IPv6 and IPv6/IPv4 tunneling is also supported.
- IP Source and Destination addresses may be incremented or decremented using a network mask.
- Data Patterns: Can be one of three types: predefined patterns up to 8K bytes in length, randomly generated data, algorithmically generated data, industry standard (such as CJPAT and CRPAT) or user-specified.
- User Defined Fields (UDFs): A number of 32-bit counters. For some modules the counters can each be flexibly configured as multiple 8, 16, 24, and 32-bit counters. Each counter may independently increment or decrement using a mask. These are further described in User Defined Fields (UDF).
- Frame Identity Record (FIR): An identity record stored at the end of the packet. The information is very useful for determining the source of transmitted data found in capture buffers.
- Frame Check Sequence (FCS): The checksum for a packet may be omitted, formatted correctly, or have deliberate errors inserted. Deliberate errors include incorrect checksum, dribble errors, and alignment errors.
Virtual LANs
Virtual LANs (VLANs) are defined in IEEE 802.1Q, and can be used to create subdomains without the use of IP subnets. The IEEE 802.1Q specification uses the explicit VLAN tagging method and port-based VLAN membership. Explicit tagging involves the insertion of a tag header in the frame by the first switch that the frame encounters. This tag header indicates which VLAN the packet belongs to. A frame can belong to only one VLAN.
VLAN tag headers are inserted into the frames, following the source MAC address. A maximum of 4094 VLANs can be supported, based on the length of the 12-bit VLAN ID. The VID value is used to map the frame into a specific VLAN. VLAN IDs 0 and FFF are reserved. VID = 0 indicates the null VLAN ID, which means that the tag header contains only user priority information.
An example of Layer 2 broadcast domain without VLANs is shown in the following figure.
Example of Broadcast Domain Without VLANs

In the example above, a company has four departments (Sales, and so forth) which are in one switched broadcast domain. Broadcasts are flooded to all of the devices in the domain. A router sends/receives Internet traffic. In the figure below, the departments have been grouped into two separate VLANs, cutting down on the amount of broadcast traffic. For example, VLAN 20 contains Ports 1, 2, 3, and 6 on Switch 1, and Ports 1, 2, 3, and 6 on Switch 2. VLAN 21 contains Ports 4, 5, and 6 on Switch 1, and Ports 1, 4, 5, and 6 on Switch 2.
Example of VLANs

With the new network design, switch ports and attached nodes are assigned to VLANs. Frames are tagged with their VLAN ID as they leave the switch, en route to the second switch. The VLAN ID indicates to the second switch which ports to send the frame to. The VLAN tag is removed as the frame exits a port belonging to that VLAN, on its way to the attached node. With VLANs, bandwidth is conserved, and security is improved. Communication between the VLANs is handled by the existing Layer 3 router.
Stacked VLANs (Q in Q)
VLAN Stacking refers to a mechanism where one VLAN (Virtual Local Area Network) may be encapsulated within another VLAN. This allows a carrier to partition the network among several networks, while allowing each network to still utilize VLANs to their full extent. Without VLAN stacking, if one network provisioned an end user into `VLAN 1,' and another network provisioned one of their end users into `VLAN 1,' the two end users would be able to see each other on the network.
VLAN stacking solves this problem by embedding each instance of the 802.1Q VLAN protocol into a second tier of VLANs. The first network is assigned a `Backbone VLAN,' and within that Backbone VLAN a unique instance of 802.1Q VLAN tags may be used to provide that network with up to 4096 VLAN identifiers. The second network is assigned a different Backbone VLAN, within which another unique instance of 802.1Q VLAN tags is available.
The following figure demonstrates an example packet of a stacked VLAN.
Figure: Stacked VLAN Header Information

User Defined Fields (UDF)
Seven different types of UDFs are available, depending on the load module type. The types of UDFs that are supported by particular port types is detailed in Platform and Reference Overview. Not all features supported by a port type are available on all UDFs; whether a particular UDF type is supported on a particular UDF can be ascertained by looking at the UDF with IxExplorer or programatically using the Tcl API. These types are:
- Counter Mode UDF
- Random Mode UDF
- Value List Mode UDF
- Range List Mode UDF
- Nested Counter Mode UDF
- IPv4 Mode UDF
- Table Mode UDF
Some features are common across all UDFs:
- Counter Type: The size of the counter is available in two modes:
- A single counter with a length of 8, 16, 24 or 32 bits, or
- A 32-bit value that may be divided into one to four 8 to 32 bit counters in any order. For example, 8x8x8x8 (four 8-bit counters), 8x16 (an 8-bit counter followed by a 16 bit counter), or 24x8 (a 24-bit counter followed by an 8-bit counter). In this case, each of the up to four counters may be independently controlled as described in Counter Mode UDF.
- Offset: The offset from the beginning of the packet to the start of the counter.
- Init val: The initial value given to the counter.
- Cascade: Sets the initial value for the counter, in one of two ways:
- From the last value for this stream: The counter continues from the last value generated by this UDF for this stream. The first value for the counter is set from the Init val setting. This type of cascade is sometimes referred to as Cascade From Self.
- From the last value on the previous cascade stream: The counter continues from the last value generated by the last executed stream using this UDF that is also in this cascade mode. The first value for the first UDF is set from the Init val setting. This type of cascade is sometimes referred to as Cascade From Previous Stream.
- Masking: The bit masking operation allows certain bits to maintain constant values, while varying other values. In the IxExplorer GUI, a bit mask is represented as a string of characters, one character per counter bit. For example, a possible Bit Mask setting for an 8-bit counter might be:
0110XXXX
The `0's and `1's represent fixed values after the mask value, while the `X's are bits which vary as a result of the increment, decrement or random value option.
In the TCL/C++ APIs, the Bit Mask value is split into two variables:
- maskSelect: Indicates which bits of the counter are fixed in value, and
- maskval: Indicates the fixed value for any of the bits set in maskSelect.
In all of the UDF figures, the generated counter value is shaded. The parameters are shown in ovals (blue in the online version).
Counter Mode UDF
The counter mode UDF features the ability of a counter (up to four on some load modules) to count up or down or to use random values. Certain bits of the counter may be held at fixed values using a mask. The parameters that affect the counter's operation are shown in the following table.
IxExplorer Label | Tcl API Variables |
---|---|
Counter Type |
countertype |
Offset |
offset |
Init Value |
initval |
Set from Init ValueContinue from last value for this streamCascade continue |
cascadeTypeenableCascade |
Random* |
random |
Continuously Counting |
continuousCount |
Step |
step |
Repeat Count |
repeat |
Mode |
updown |
Bit Mask |
maskvalmaskselect |
* some card types include random mode as part of the counter mode and others use them as a separate mode.
In the TCL APIs the value of the counterMode variable in the udf command should be set to udfCounterMode (0). The operation of counter mode is described in the flowchart shown in the following figure.
Figure: UDF Counter Mode Operation

Random Mode UDF
The random mode UDF features a counter whose values are randomly generated, but may be masked. Cascading modes do not apply to random mode UDFs. The parameters that affect the counter's operation are shown in the following table.
IxExplorer Label | Tcl API Variables |
---|---|
Offset |
offset |
Bit Mask |
maskvalmaskselect |
In the TCL APIs the value of the counterMode variable in the udf command should be set to udfRandomMode (1). The operation of random mode is described in the flowchart shown in the following figure.
Figure: UDF Random Mode Operation

Value List Mode UDF
The value list mode UDF features a counter whose values successively retrieved from a table of values. Cascading modes do not apply to value list mode UDFs. The parameters that affect the counter's operation are shown in the following table.
IxExplorer Label | Ecl API Variables |
---|---|
Offset |
offset |
Counter Type |
countertype |
Data |
valueList |
Set from Init ValueContinue from last value for this stream |
cascadeTypeenableCascade |
In the TCL APIs the value of the counterMode variable in the udf command should be set to udfValueListMode (2). The operation of value list mode is described in the flowchart shown in the following figure.
Figure: UDF Value List Mode Operation

Range List Mode UDF
The range list mode UDF features a counter whose values are generated from a list of value ranges. Each range has an initial value, repeat count, and step value. Cascading modes do not apply to range list mode UDFs. The parameters that affect the counter's operation are shown in the following table.
IxExplorer Label | Tcl API Variables |
---|---|
Offset |
offset |
Counter Type |
countertype |
Init Value |
initval |
Repeat Count |
repeat |
Step |
step |
Set from Init ValueContinue from last value for this stream |
cascadeTypeenableCascade |
In the TCL APIs the value of the counterMode variable in the udf command should be set to udfRangeListMode (4). The initval, repeat, and step values are added into the udf command by the addRange sub-command. The operation of range list mode is described in the flowchart shown in the following figure.
Figure: UDF Range List Mode Operation

Nested Counter Mode UDF
The nested counter mode UDF features a counter whose values are generated from three nested loops:
- A given value may be repeated a number of times.
- That value is incremented and step 1 is repeated for a count. This is called the inner loop.
- That value is incremented and steps 1 and 2 repeated continuously for a count. This is called the outer loop.
The parameters that affect the nested counter's operation are shown in the following table.
IxExplorer Label | Tcl API Variables |
---|---|
Offset |
offset |
Counter Type |
countertype |
Init Value |
initval |
Inner Loop: Repeat value |
innerRepeat |
Inner Loop: increment value |
innerStep |
Inner Loop: loop |
innerLoop |
Outer Loop:increment value |
step |
Outer Loop: loop continuously |
continuousCount |
Outer Loop: repeat outer loop |
repeat |
Set from Init ValueContinue from last value for this stream |
cascadeTypeenableCascade |
In the TCL APIs the value of the counterMode variable in the udf command should be set to udfNestedCouterMode (3). The operation of range list mode is described in the flowchart shown in the following figure.
Figure: UDF Nested Counter Mode Operation

IPv4 Mode UDF
The IPv4 counter mode UDF features a counter designed to be used with IPv4 addresses. The process is:
- A given value may be repeated a number of times. Values with all `1's and `0's in a particular part of the value may be skipped so as to avoid broadcast addresses. The number of low order bits to check for `0's and `1's can be set.
- That value is incremented and step 1 is repeated continuously or for a count.
The parameters that affect the counter's operation are shown in the following table.
IxExplorer Label | Icl API Variables |
---|---|
Offset |
offset |
Counter Type |
countertype |
Init Value |
initval |
Loop: Repeat value |
innerRepeat |
Loop: increment by |
innerStep |
Repeat Loop: Continuously |
continuousCount |
Repeat Loop: times |
repeat |
Skip all zeros and ones |
enableSkipZerosAndOnes |
masked with |
skipMaskBits |
Set from Init ValueContinue from last value for this stream |
cascadeTypeenableCascade |
The operation of IPv4 mode is described in the flowchart shown in the following figure.
Figure: UDF IPv4 Mode Operation

Table Mode UDF
Table UDFs allows to specify a number of lists of values to be placed at designated offsets within a stream. Each list consists of an Offset, a Size, and a list of values.
The following figure illustrates the basic operation of the Table UDFs using a GRE encapsulated packet as an example. Four of the fields in the packets need to be modified on a packet by packet basis-the key and sequence GRE fields and the source and destination IP addresses in the IP header. The Table UDF provides a means by which lists are developed for each of these fields and the list is associated with an offset and size within the packet. During stream generation, all lists are applied at the same time in lock step.
Figure: Table UDF Mode

A Table UDF is applied before, and can be combined with, the standard UDF fields already available on ports. By combining these two features you can model multiple flows using the powerful combination of a value list group for flow identity fields and UDFs for protocol related timestamp/sequence fields.
Table Mode UDF has a limitation compared to the other UDFs. Specifically, Table Mode behaves differently when Random Data payload is enabled for the frame.
Most UDFs are attached to the frame after the Random Data is placed in the frame; the UDFs `overlay'on top of the random data. The Table Mode UDF data, however, is put in the frame before the random data. As a result, the payload is random only after the Table UDF.
For example, if a frame has a Table UDF that is 1 byte wide starting at offset 100, random data cannot appear in the payload until byte 101. Thus, the first 100 of these frames would have the same `random' data appear within the first 99 bytes of the payload-for all 100 frames. The data would truly appear random starting at byte 101, after the Table UDF insertion.
This is the same limitation currently for random data packets that have PGID or Data Integrity enabled.
The parameters that affect the counter's operation are shown in the following table.
IxExplorer Label | Tcl API Variables |
---|---|
Offset |
offset |
Counter Type |
countertype |
Init Value |
initval |
Add Column |
addColumn |
Add Row |
addRow |
Clear All Columns |
clearColumns |
Get First Column |
getFirstColumn |
Get Next Column |
getNextColumn |
Clear All Rows |
clearRows |
Get First Row |
getFirstRow |
Get Next Row |
getNextRow |
Export to File |
export |
Import from File |
import |
Transmit Operations
The transmit operations may be performed across any set of chassis, cards, and ports specified by you. These operations are described in the following table.
Repeat Last Random Pattern
The 10 GE LSM module transmit engine has the ability to provide repeatable random values in all its random number generators. This feature allows to run tests with random parameters such as frame size, frame data, and UDF values to rerun the tests with the same set of random data if a problem is found. A check box on the Port Properties transmit tab is used to enable/disable, repeating the last seed used on the port. In addition to the check box, there is a read-only window showing the last 32 bit master seed value used in generating seeds for all random number generators on the port.
Port Data Capture Capabilities
Most ports have an extensive buffer which may be used either to capture the packet data `raw' as it is received, or to categorize it into groups known as Port Groups. Each port must be designated to have a Receive mode which is either Capture or Packet Groups. Packet groups are used in measuring latency.
The start of capture buffering may be triggered by a set of matching conditions applied to the incoming data, or all data may be captured. Packets can be filtered, as well. During capture mode operation, the amount of data saved in the capture buffer can be limited to a user-defined `capture slice' portion of each incoming packet, rather than the entire packet.
Each port's Capture trigger and filter conditions are based on:
- For Ethernet Modules:
- Data link encapsulation type
- Destination and source MAC addresses
- Protocol layer type: such as IP, IPv6, and ARP
- IPv4 and IPv6 source and destination addresses
- TCP and UDP port numbers
- VLAN IDs
- For POS Modules:
- Use of PPP
- Protocol layer type: such as IP, IPv6, and ARP
- IPv4 and IPv6 source and destination addresses
- TCP and UDP port numbers
- For ATM Modules:
- VPI and VCI combinations
- Protocol layer type: such as IP, IPv6, and ARP
- IPv4 and IPv6 source and destination addresses
- TCP and UDP port numbers
- ATM OAM cells
- Data pattern match for the packet, and matching errors such as: Bad CRC, Bad Packet, Alignment Error, and Dribble Error
- Packet sizes within a user-specified range
Continuous Versus Trigger Capture
For some load modules, there are more advanced options provided for setting up data capture operations on a port. These options are set in the receive mode dialog for the port. The available options are described in the following list:
- Continuous Capture. Options are as follows:
- All packets are captured.
- All packets which match a user-defined Capture Filter condition are captured.
- Trigger Capture:
- Capture operation starts before a packet matching the user-defined Trigger condition is received. Options are:
- All packets are captured.
- No packets are captured.
- All packets which match a user-defined Capture Filter condition are captured.
- Capture operation starts after a packet matching the user-defined Trigger condition is met. Options are:
- All packets are captured.
- All packets that match a user-defined Capture Filter condition are captured.
- All packets that match the user-defined Trigger Capture condition are captured.
- Trigger Position: The slider bar is used to set the position (% transmitted) in the data stream where the Capture Trigger is first applied to incoming packets.
Port Capture Operations
The data capture operations may be performed across any set of chassis, cards, and ports defined by you. These operations are described in the following table.
Forced Collision Operation
In addition to normal capture operation, forced collisions can be generated on the receive side of some 10/100/1000 load module ports, but only when the port is in half-duplex mode.
Forced collisions operate by generating `collision' data as information is being received on the incoming port. The `collision' takes the form of a number of nibbles inserted at a user-specified offset within a packet as it is received. A period with a number of consecutive `collisions' is followed by a period with no collisions. This combination of collisions and non-colliding periods can be repeated indefinitely, or repeated for a user-specified number of times. These parameters are shown in the following figure.
Figure: Forced Collisions

Packet Group Operation
Packet groups are sets of packets which have matching tags, called Packet Group IDs. Real-time latency measurements within packet groups depend on coordination between port transmission and port reception. Each transmitted packet must include an inserted 4-byte packet `group signature' field, which triggers the receiving port to look for the packet group ID. This allows the received data to be recognized and categorized into packet groups for latency analysis.
Packet group IDs should be used to group similar packets. For example, packet groups can be used to tag packets connected to individual router ports. Alternatively, packet groups may be used to tag frame sizes. Such groupings allow to measure the latency with respect to different characteristics (for example, router port number or frame size as in the above scenario).
After packet group operation is triggered on the receiving port, the packet group ID-a 2-byte field which immediately follows the signature-is used as an index by the port's receive buffer to store information related to the latency of the packet. When packet group signatures and packet group IDs are included in transmitted data, an additional time stamp is automatically inserted into the packet. The following figure shows the fields within packets which are important for packet grouping and latency analysis.
Figure: Packet Format for Packet Groups/Latency

A special version of packet groups, known as wide packet groups, uses a 4-byte packet group ID, of which only the low order 17 bits are active. A mask may be applied to the matching of the packet group ID. Latency, sequence checking, and first/last timestamps are supported at the same time. Latency over time and data integrity checking are not supported in this mode. Frames must be greater than or equal to 64 bytes.
Split Packet Group Operation
Split PGID allows the 32-bit PGID field used to identify and group packets to be generated from a concatenation of three separate PGID fields. Note that the method for detecting and determining if a packet has a valid signature is no different from standard PGID operation. A valid signature is still required before the concatenated PGID is considered to be valid.
Instead of having one PGID offset value with one mask, you are allowed to enter up to three separate PGID offsets and masks. The split PGID method works with both the standard instrumentation method or the floating instrumentation method, and does not interfere with other features such as time bins and bin by latency.
In addition to having three 16 bit offset values and three 32 bit mask values, the following possibilities are available for the PGID offset:
- Offset from Start of Frame (Original starting point for PGIDs)
- Offset from End of Floating Instrumentation Pattern Match
- Offset from Start of IP
- Offset from Start of Protocol
The definition of the mask is also different when in split PGID mode. In the standard PGID mode, the mask is only used to zero out PGID values and not to change the width of the final PGID. In split PGID mode, the mask is used to reduce the overall width of the PGID value for that region. A value of 1 in mask field indicates the bit is discarded (masked out).
The final 32 bit PGID value used is a concatenation of the values extracted based on the offset/mask combinations provided for the three PGID regions. The final 32 bit PGID is generated by concatenating the three regions as follows: PGID3, PGID2, and PGID1. If the concatenation of the three regions is not sufficient to fill the 32 bit value, a padding of 0 is used on the remaining leftmost bits.
The following figure demonstrates the three options when employing split PGIDs.
Figure: Split PGID Scenarios

Latency/Jitter Measurements
Latency and Jitter can be measured when packet groups are enabled on a transmitting port and received on a port enabled to receive packet groups. The difference between the received time and the transmitted time held in the packet's time stamp is the measured latency or jitter. The latency is included in a memory cell indexed by the packet group ID. The count of packets received, minimum, maximum, average, and mean latencies are maintained. There are two modes for latency measurement:
- Instantaneous: Latency measured for all received data (continuous). The number of PGID groups available depends on the features being employed on the receive side. The PGID is used as an index into an area of cells and the count/min/max/avg/mean is maintained for each PGID.
- Latency over time: Latency measured for a number of time intervals of equal length, called `time buckets.' The range of cells is divided up over a period of time-for example, for one second intervals over a 30 second period. Each time period (one second in this example) is called a time bucket. Within each time bucket, the data for all PGIDs must be stored into a limited number of cells. This is accomplished by grouping a number of PGIDs together. The grouping is called the `# of PGIDs/Time Bucket'. The figure below demonstrates the relationship between the time buckets and PGIDs in an example. The minimum size time bucket varies by port type, but the size set should be reasonable for the transmission speed of the port-certainly no shorter than 1 microsecond.
Figure: Multiple Latency Time Measurements-Example

The timeline is equally divided into a # of Time Buckets, each of which is oneTime Bucket Duration in length. A time bucket duration can range anywhere from nanoseconds to hours, depending on the user configuration.
The maximum number of time buckets that can be handled is determined by the number of PGIDs in each bucket.
Four types of timing measurements are available, corresponding to the type of device under test:
- Cut-Through: For use with switches and other devices that operate using packet header information. The time interval between the first data bit out of the Ixia transmit port and the first data bit received by the Ixia receive port is measured. The first data bit received on Ethernet links (10/100 and Gigabit modules) is the start of the MAC DA field. For Packet over SONET links, the first bit received is the start of the IP header.
- Store and Forward: For use with routers and other devices that operate on the contents of the entire packet. The time interval between the last data bit out of the Ixia transmit port and the first data bit received by the Ixia receive port is measured. The last data bit out is usually the end of the FCS or CRC, and the first data bit received is as described above for Cut Through.NOTE: Store and Forward latency mode is intended to test Store and Forward switching devices, which receive the entire packet before transmitting it to its destination. If Store and Forward latency is used in loopback, back-to-back or without a Store and Forward switch, then either a zero latency or very high latency is reported.
- Store and Forward Preamble (only available on some load modules): As with store and forward, but measured with respect to the preamble to the Ethernet frame. In this case, the time interval between the last data bit out of the Ixia transmit port and the first preamble data bit received by the Ixia receive port is measured. For this measurement, the size of the preamble (in bytes) is considered.
- Inter-Arrival Time (IAT): Compares the time between PGID packet arrivals. In this case, when a packet with a PGID is received, the PGID is examined. If a packet has already been received with the same PGID, then the timestamp of the previous packet is subtracted from the current timestamp. The interval between the timestamps is the jitter, and it is recorded for statistical purposes.
Sequence Checking Operation
A number of ports have the additional ability to insert a sequence number at a user-specified position in each transmitted packet. This sequence number is different and distinct from any IP sequence number within an IP header. On the receiving port, this special sequence number is retrieved and checked, and any out-of-sequence ordering is counted as a sequence error.
As in packet groups (see Packet Group Operation), for sequence checking a signature value is inserted into the packet on the transmit side to signal the receive side to check the packet. In fact, this particular signature value is shared by both the packet group and the sequence checking operations. Both the signature value and sequence number are 4-byte quantities and must start on 4-byte boundaries. These fields are shown in the following figure.
Figure: Packet Format for Sequence Checking

Sequence numbers are integers which start at `0' for each port when transmission is started, and increment by `1' continuously until a Reset Sequence Index operation is performed. Note that multiple sequence errors results when a packet is received out of sequence. For example, if five packets are transmitted in the order 1-2-3-4-5 and received in the order 1-3-2-4-5, three sequence errors are counted:
- At 1-3, when packet 2 is missed
- At 1-3-2, when 2 is received after 3
- At 1-3-2-4, when 4 is received after 2
Switched-Path Duplicate/Gap Checking Mode
This is a mode in sequence checking that allows for detecting duplicate packets, or sequence gaps. IxExplorer stores the largest sequence number received. Any packet that arrives with a lower or equal sequence number is regarded as a duplicated packet. For a flow with no packet reordering, the `reversal errors' matches the number of duplicates received. For a flow with packet reordering, the `reversal errors' gives a count that may be higher than the number of duplicates received.
Data Integrity Checking Operation
A number of ports also possess the ability to check the integrity of data contained in a received packet, by computing an additional 16-bit CRC checksum.
As with packet groups (see Packet Group Operation) and sequence checking (see Sequence Checking Operation), a signature value is inserted into the packet on the transmitting interface, to serve as a trigger for the receiving port to notice and process the additional checksum. The data integrity operation uses a different signature value from the one shared by packet groups and sequence checking.
The data integrity signature value marks the beginning of the range of packet data over which the 16-bit data integrity checksum is calculated, as shown in the figure below. This packet data ends just before the timestamp and normal CRC/FCS. The CRC-16 checksum value must end on a 4-byte boundary. There may be 1, 2, or 3 bytes of zeroes (padding) inserted after the CRC-16, but before the Time Stamp, to enforce all boundary conditions.
Figure: Packet Format for Data Integrity Checking

When the Receive Mode for a port is configured to check for data integrity, received packets are matched for the data integrity signature value, and the additional CRC-16 is checked for accuracy. Any mismatches are recorded as data integrity errors.
Automatic Instrumentation Signature
The Automatic Instrumentation Signature feature allows the receive port to look for a signature at a variable offset from the start of frames. The feature supports Sequence Checking, Latency, Data Integrity functionality, with signature and Packet Group ID (when Automatic Instrumentation is enabled, these receive port options are enabled as well).
In normal stream operation, signatures for Data Integrity, Latency, and Sequence Checking are forced to a single, uniform offset location in each frame of the stream. Many of the Ixia software application (that is, IxVPN, IxChariot, and so forth) can generate streams that place a signature at random places within the frames of a single stream. To accurately detect these signatures on the receive side of the chassis, Automatic Instrumentation Signature is used.
Automatic Instrumentation Signature allows the chassis to look for a floating pattern in the frame. Two data blocks are placed in the frame (by some stream generating application). The first is positioned at a variable offset from the start of the frame. The second is positioned at a fixed 12 byte offset from the end of the frame.
The following figure shows the composition of the blocks.
Figure: Automatic Instrumentation Signature Block

The receive port recognizes an instrumented frame by detecting the Signature in the first block. Once a signature match has occurred, the Packet Group ID (PGID) and Sequence Number are extracted from the frame. Data Integrity also starts immediately following the signature.
The Checksum Adjust field is reserved for load modules that cannot correctly do checksums on large frames.
Port Transmit/Receive Capabilities
Round Trip TCP Flows
For most 10/100 load modules, a special capability exists in the Ixia hardware to enable the measurement of round trip times for IP packets sent through a switch or other network device. The normal setup for this measurement is shown in the following figure.
Figure: RoundTrip TCP Flows Setup

In this scenario, Ports A and X are configured on one IP subnet, and Ports B and Y are configured on a different IP subnet. IP packets sent from A have a source address of A and destination address of B. The DUT is configured to route or forward to Y any packets that it receives on X for an address on B-Y's subnet. After being received on Port B, the packet is reconstructed in a modified form as described in the following list, and sent back in the opposite direction along the path to Port A.
When enabled on the Ixia receiving port (in this case, Port B), the Round Trip TCP Flows feature performs several operations on the received IP packet:
- The Source and Destination IP addresses are reversed, and a packet destined for Port A is created using the reversed addresses.
- The frame size, source and destination MAC addresses, and background data pattern are set as specified by you.
- The timestamp is copied to the new packet unmodified.
- The new packet is transmitted to Port Y on the DUT, and should be routed back to Port A by the DUT.
This re-assembly/retransmit process makes it possible to measure the round-trip time for the packet's trip from Port A through the DUT to Port B, and back through the DUT to Port A again. Note that the Packet Groups feature may be used, in addition, for latency measurements on this round trip. For latency testing, the background data set by the Round Trip TCP Flows feature overwrites the Packet Group Signature Value contained in the packet. It is important that proper programming of the background data pattern be used to insert the appropriate signature value back into the packet.
Port Statistics Capabilities
Each port automatically collects statistics. A wide range of statistics are preprogrammed and available for many types of load modules. Other statistics may be selected or programmed and include:
- User-Defined Statistics: Four counters which can be programmed to increment based on the same conditions as those involved in defining capture triggers and capture filters.
- Quality of Service Types: Separate counts for each of eight Quality of Service values used in IP headers.
- IP/UDP/TCP Checksum Verification Statistics: For hardware checksum verification.
- Data Integrity Statistics: For errors relating to Data Integrity Operation. Refer to Data Integrity Checking Operation.
- Packet Group Statistics: For statistics relating to Latency operations. Refer to Latency/Jitter Measurements.
- Protocol Server Statistics: Protocol-based statistics for a wide range of routing protocols.
- SONET Extended Statistics: Statistics associated with SONET Line, Section and Path characteristics.
- VSR Statistics: Statistics associated with OC192 VSR modules.
- ATM Statistics: Statistics associated with ATM modules.
- BERT Statistics: Statistics associated with BERT error generation and detection.
- Temperature Sensors Statistics: For verifying that temperatures on high-performance 10 Gigabit and OC-192c POS cards are within operational limits.