Port Transmit Capabilities

The Ixia module ports format data to be transmitted in a hierarchy of structures:

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:

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:

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:

Each non-continuous stream is related to the next stream by one of four modes:

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:

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:

Some features are common across all UDFs:

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:

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.

Counter Mode UDF Parameters
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.

Random Mode UDF Parameters
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.

Value List Mode UDF Parameters
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.

Range List Mode UDF Parameters
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:

  1. A given value may be repeated a number of times.
  2. That value is incremented and step 1 is repeated for a count. This is called the inner loop.
  3. 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.

Nested Counter Mode UDF Parameters
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:

  1. 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.
  2. 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.

IPv4 Mode UDF parameters
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.

Table Mode UDF Parameters
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.

Transmit Operations
Operation Usage

Start Transmit

Starts the transmission operation on all ports included in the present set of ports. If no transmit operation has been performed yet, or if the last operation was Stop Transmit, then transmission begins with the first stream configured for each port. If a Pause Transmit operation was last performed, then transmission begins at the next packet in the queue for all ports.

Staggered Start Transmit

The same operation is performed as in Start Transmit, except that the start operation is artificially staggered across ports. The time interval between the start of transmission on consecutive ports is in the range of 25-30ms.

Stop Transmit

Stops the transmission operation on all ports included in the present set of ports. A subsequent Start Transmission or Step Stream operation commences from the first stream of each port.

Pause Transmit

Stops the transmission operation on all ports in the present set of ports at the end of transmission of the current packet. A subsequent Start Transmission or Step Stream commences at the beginning of the next packet in the queue on each port.

Step Stream

Causes one packet to be transmitted from each of the ports in the present set of ports.

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:

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:

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.

Capture Operations
Operation Usage

Start Capture

Enables data capture on all ports in the set of ports whose receive mode is set to Capture. Packets are not actually captured until the user-specified capture trigger condition is satisfied.

Stop Capture

Stops data capture on all ports in the set of ports.

Start Latency

Initiates latency measurements for all ports in the set of ports whose receive mode is set to Packet Group operation.

Stop Latency

Stops latency measurements on all ports in the set of ports.

Start Collision

Enables generation of forced collisions on received data, for all ports in the set of ports-if this option is selected for the port and enabled. Applies to half-duplex 10/100 Ethernet connections only.

Stop Collision

Stops generation of forced collisions for all ports in the set of ports.

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:

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:

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:

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:

  1. At 1-3, when packet 2 is missed
  2. At 1-3-2, when 2 is received after 3
  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:

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: