Introduction
Recent releases of firmware for the IneoQuest Technologies, Inc. Singulus G1-T include new, powerful features that allow line-rate packet modification as well as selective packet drop capabilities while in network TAP mode. User selected packet fields can be modified as the packets are forwarded through the G1-T from the one port to the other port or modified as they are received from one of these ports and transmitted from the same port. In addition, user specified packet criteria can be used to identify packets to selectively forward or to selectively filter traffic. This note describes these features, how they operate, how to configure them via the IQController user interface, and some common applications for their use.
Packet Remap Functional Overview
The Singulus G1-T has two 10/100/1000 Mb/s Copper or Fiber Ethernet ports. Until the Packet Remapping capabilities
were recently introduced, the G1-T's TAP mode has been used to snoop traffic on a link. When the G1-T is inserted in series with a Copper (10/100/1000 BASE-T) or
1000 Mb/s Fiber link, bidirectional traffic is forwarded with a minimum of delay or jitter while MPEG over IP traffic passing through the device is analyzed, packets captured via a variety of user filters, or timestamps examined for latency analysis of stimulus-response traffic, etc. With Packet Remap capabilities, also known as PacketMorph, selected (qualified) packets may be modified at media rate as they flow through the G1-T in TAP mode and/or designated for filtering or forwarding.
Specifically, packets may be selected (qualified) by their Source IP, Destination IP, UDP or TCP Source Port number, UDP or TCP Destination Port number, and/or on which link port they arrived. Once qualified, these packets may be forwarded to the opposite link port or blocked from being forwarded to the opposite link port. Likewise, these packets may be transmitted out the same port on which they arrived or all packets except these qualified packets may be transmitted out the same port on which they arrived.
Following selection based on the criteria described above, the selected packets may be optionally remapped. Remapping includes changing the Destination MAC address, Source MAC address, Destination IP address, Source IP address, UDP or TCP Destination Port number, UDP or TCP Source Port number, and/or the IP header Type of Service (TOS) field.
Following traffic flow selection based on the criteria described above, selective packet dropping can also be configured. Either a user programmable number of packets of a set of streams that meet the selection criteria may be dropped as a one-time event or N packets out of M packets that meet the selection criteria may be dropped repeatedly, where N and M are user configurable numbers.
Packet Remap Details
To use the Singulus G1-T Packet Remap features requires two steps:
1. Configuring the packet qualification criteria to select which incoming packets will be modified and, then,
2. Configuring the remap parameters, which determine how the qualified packets should be modified.
These two configurations are accomplished via the following screen and are discussed below in more detail.
Qualifier Parameters:
Source Packet Type
This packet qualification parameter allows the user to select IPv4 packets with UDP, TCP, or any (unspecified) layer 4 protocol. A received packet must have an IPv4 layer 3 protocol to meet the qualification criteria. A user can further specify that only UDP or TCP packets will meet the criteria by selecting the appropriate option from the Source Packet Type list.
Source/Destination Packet Qualification Address Specification
IP Source and/or Destination Packet addresses can be additional user specified qualification criteria for received packets. By specifying the accompanying Source and/or Destination address Mask, entire subnets or ranges of host addresses can be specified for qualification as easily as a single or small group of hosts. The Mask bits are used to qualify which bits of the address fields must be matched in the receive packet for that packet to be qualified. For example, consider the following Source or Destination IP address/mask specification:
Address: 192.168.144.222
Mask: 255.255.0.0
Since only the upper 16 bits of the Mask are 1s, only the upper 16 bits of the received address are compared to the specified address in determining whether the received address meets the qualification criteria. In this example, all addresses beginning with 192.168 meet the criteria and the lower order address bits are ignored. Similarly, a single IP address, for example 192.168.14.21, can be specified as the qualification criteria with the following specification:
Address: 192.168.14.21
Mask: 255.255.255.255
Either Source or Destination Address ranges or both may be chosen for qualification in the method described above.
Source/Destination Packet Qualification Port Specification
Similar to the Address qualification parameters described above, the received packet's Source and/or Destination Port number can be additional or alternate user specified qualification criteria for received packets. By specifying the accompanying Source and/or Destination Mask, entire ranges of port numbers can be specified for qualification as readily as a single or small group of ports. The Mask bits are used to qualify which bits of the address fields must be matched in the receive packet for that packet to be qualified. For example, consider the following Source or Destination port number/mask specification:
Port Number: 0021 (decimal port number)
Mask: 00F0 (hex mask)
Converting the port number to hex is: 0x15. The mask of 0x00F0 will ensure that only bit positions 7..4 need be matched. Therefore, any hex port number with a value of 0x1 in bit locations 7..4 will match and be qualified. Since protocol Port Numbers are typically noted in decimal, the extra conversion to hex for establishing a mask is necessary.
Two Qualifiers Available
Two independent qualifiers, each as described above, are available for use. Note that the Source Packet Type and Action selections are common to both qualifiers; that is, they must be the same for both qualifiers. One way to utilize both qualifiers is to apply one to the Normal port and the other to the TAP port. If the port Action is then set to Reflect, the two ports can support independent connections and actions to two separate networks or network device ports.
Remap Parameters:
If a packet meets the qualification criteria described above, it may then be modified in various ways including modifying its Source and/or Destination MAC address, Source and/or Destination IP address, and/or its Source and/or Destination Port number. User settable levels of packet dropping may also be imposed on the qualified stream(s).
Source/Destination Packet Address Modification
Destination and/or Source MAC addresses of qualified packets may be modified in one of two ways using the selectable Action options of SET and ADD. If SET is selected, then the 6 byte field for the address is simply used to replace (or "set") the value of that field on the qualified received packet(s). For example, a received packet whose Destination IP address matches a specified qualification value may have its Destination MAC address always changed to a new fixed value -- perhaps to cause it to be forwarded to a specific router or monitor. Alternatively, if the Action option is configured for ADD, the 6 byte field for the address is added to the value of the address on the qualified received packet. This Action can be used to add a fixed offset to all qualified received packets for example.
Source and/or Destination IP addresses may also be remapped. IP addresses have an accompanying Mask field which offers further flexibility. If the Mask field of a dotted decimal value of the IP address is set to 1s and the Action is SET, then that field of the address is set to be the value specified in the address field. The rest of the address of the packet will be the value that was received. For example:
Packet Received: 28.50.144.222
Action: SET
Address Field: 0.0.146.0
Mask: 0.0.255.0
Yields a Packet Transmitted as: 28.50.146.222
Since the Mask fields for the first two dotted decimal fields of 28 and 50 and the last field of 222 are 0, these fields are not affected and the received packet's fields are used for the transmitted packet while the Mask field for bit positions 15..8, which are all ones, cause the transmitted packet to be set to the value in the Address Field (146). Note that this can be used, as in this example, to cause an entire subnet's traffic to be transmitted on another subnet or to alter the Source IP addresses in the same way (or both).
If the Action is configured for ADD rather than SET, the 4-byte field for the address is added to the value of the address on the qualified received packet. This Action can be used to add a fixed offset to all qualified received packets for example. Adding to the flexibility of this operation the accompanying mask can be configured such that only a single or group of dotted decimal fields on the received packet will be affected by the add operation -- that is, an add operation's carry result can be used to affect upper bit positions or not depending on the nonzero mask bits.
Source/Destination Port Number Modification
Similar to the Source/Destination Packet Address Modification option described above, the Source/Destination Port numbers may optionally also be selected for modification. Destination and/or Source Port Numbers of qualified packets may be modified in one of two ways using the selectable Action options of SET and ADD.
If SET is selected, then the 4 byte field for the port number is simply used to replace (or "set") the value of that field on the qualified received packet(s). For example, a received packet whose Destination IP address matches a specified qualification value may have its Destination port number always changed to a new fixed value -- perhaps to cause it to be forwarded to a specific diagnostic process or monitor. Alternatively, if the Action option is configured for ADD, the 4 byte field for the port number is added to the value of the port number on the qualified received packet. This Action can be used to add a fixed port number offset to all qualified received packets for example.
Port numbers have an accompanying Mask field which offers further flexibility. If the Mask field of a portion of the port number is set to 1s and the Action is SET, then that field of the port number is set to the value specified in the port number field. The rest of the port number of the packet will be the value that was received. For example:
Port number of packet received: 0021
Action: SET
Port number Field: 00048
Mask: 0x00F0
Yields a Packet Transmitted with port number: 0049
Converting the received port number to hex is: 0x15. The mask of 0x00F0 will ensure that only bit positions 7..4 will be modified. Since the port number field is set to 48 decimal or 0x0030 hex, bits 7..4 will be Set to 0x3. Thus, the range of port numbers that could be generated is 0x0030 through 0x003F or 48 to 63 decimal. Since the received port number has a 1 in bit position 0 and bits 3..0 are masked off, they are passed, unmodified. Thus the port number that is generated is 0x0031 or 49 decimal. Since protocol Port Numbers are typically noted in decimal, the extra conversion to hex for establishing a mask is necessary.
Type of Service (TOS) field Number Modification
Similar to the Source/Destination Port number modification option described above, the IP header's TOS field octet value (see RFC 1349) or the later defined Differentiated Services Code Point (DSCP) (see RFC 2474) may optionally also be selected for modification. This field may be modified in one of two ways using the selectable Action options of SET and ADD.
If SET is selected, then the 1 byte field for the TOS is used to replace (or "set") the value of that field on the qualified received packet(s). For example, a received packet whose Destination IP address matches a specified qualification value may have its TOS octet value always changed to a new fixed value -- perhaps to cause it to be forwarded with a minimum of delay. Alternatively, if the Action option is configured for ADD, the 1-byte field for the TOS is added to the value of the field on the qualified received packet. This Action can be used to add a fixed value offset to all qualified received packets for example.
The MASK input for the TOS is used the same way as the MASK input described above in the Source/Destination Port Number Modification section, except that the field is only a single octet rather than 4 for the port number and the value is entered in hex rather than in decimal.
Packet Remap Applications
This section describes some sample testing applications that are facilitated by the packet remap features of the Singulus G1-T described above.
Forward Error Correction (FEC) Testing Applications
The ability for the user to selectively drop packets from a test stream while in TAP mode is a simple way to verify the design and implementation of an FEC algorithm. As described above, since the user can set how many consecutive packets in a designated stream are dropped (Loss Period) as well as how often the dropped packets occur (Loss Distance), an FEC test becomes very simple.
A test lab configuration consists of Singulus #1, the test stream source driving an FEC encoder in series with Singulus #2, a Singulus G1-T in TAP mode. The G1-T TAP port connects to the FEC decoder, which, in turn, is connected to the test stream sink or Singulus G1-T #3 stream analyzer as shown below:
Singulus #1 provides the test stimulus data and is configured to transmit a number of media streams. By modifying the drop period (the number of consecutive dropped packets) and distance (the number of good packets between dropped packet events) on Singulus #2 while verifying the FEC-corrected received stream, the FEC encoder/decoder effectiveness can quickly be proven by tracking the stream's MDI on Singulus #3. The rate of deterioration of the stream after exceeding the FEC correction limits will also be seen by monitoring the stream's MDI and viewing the stream on the Aspectus display.
See RFC 2733, An RTP Payload Format for Generic Forward Error Correction, December 1999, also RFC 3357, One-way Loss Pattern Sample Metrics, August 2002, and the Pro-MPEG Code of Practice #3, January 2003, for more reading on FEC implementation and application details.
Echo Loopback Testing Applications
The overall performance of embedded computing devices often depends heavily on their communications protocol stack performance. Evaluating stack performance can be simplified using the configuration below:
By configuring the G1-T remap feature to SET the destination MAC and IP addresses of any received packets to be the DUT, the DUT itself will respond to its own echo requests. For example, this provides the capability for a DUT to initiate a Ping to an arbitrary address, have the G1-T change the destination MAC and IP addresses to be the DUT's address, change the source MAC and IP addresses to be the original destination addresses (or other), and direct the packet back to the DUT. The DUT will respond to the request, which will again be reflected by the G1-T to the DUT satisfying the DUT's initial request.
Using the configuration above, the G1-T both remaps the addresses and clearly captures the progress of the Ping exchange in the screen captures below. In this example configuration, the DUT with an IP Source address of 192.168.1.144 initiates a Ping to 192.168.1.145. The Remap configuration screen shows that when the G1-T receives a packet with destination address of 192.168.1.145, it remaps the destination address to 192.168.1.144 and changes the MAC address to that of the DUT. Of course, the IP header checksum is automatically updated along with the MAC FCS. The Packet Capture screen shows the packets received and retransmitted by the G1-T along with time stamps showing the response times of the DUT. In addition, as shown in the last figure, entire packet display along with protocol stack decode may also be shown by stepping through the captured received packets.
In a similar way, the DUT can use a variety of means to assess its embedded stack performance such as file transfers, web page servers, or whatever tools may be appropriate to the embedded device technology. The G1-T provides the required high performance, line rate, predictable address translation and packet capture as well as packet timestamps thus removing the response variability of a connected network or software based loop back device.
Packet Remap Configuration Screen
Packet Capture Screen Showing Both Ping Requests and Responses from DUT
Protocol Decode and Complete Packet Capture screen
By placing a G1-T configured as a loop back device as described above, an originating device can easily determine network round trip times with high precision. Unlike a software based server solution, since the G1-T performs the address remapping function in hardware, it will provide predictable, fixed response times allowing complex networks to be characterized with high precision.
Load Generation Using Stream Replication for Stress Testing Applications
Streaming load generation is often needed to verify equipment and system
performance. Devices such as network switches and routers, streaming media decoders, etc., must be tested under worst-case network traffic loading conditions. Replicating or scaling a video stream server or other complex stream source may be cost prohibitive for high bandwidth test applications such as for emerging 10 Gigabit Ethernet applications. Alternatively, the Singulus G1-T's network address remapping capabilities may be used to replicate a streaming source to achieve higher bandwidth loads than the source may provide. The original and the replicated streams may then be combined in a layer 2 switch to generate the required higher load as shown below.
Assume that Ports 1-5 on the Switch are 1 Gigabit/second Ethernet ports and Port 6 is a 10 Gigabit/second Ethernet port. Now, for example, if the video server generates 1 Gigabit/second of traffic consisting of 240 program streams with destination IP addresses of 28.50.144.0 through 28.50.144.239 and with a broadcast MAC address, the switch will forward the 240 streams to all ports.
Singulus #1 is configured to remap all received traffic from network 28.50.144.x to 28.50.145.x and to SET the destination MAC address to that of the DUT so that the switch will forward the 28.50.145.x replicated network's data to the 10 Gigabit/second Port 6 only. It should also be configured to reflect the remapped traffic so that the traffic is sent on the same port from which it was received. This allows repeating the process with a new network destination address on the Singulus' 2nd port. Repeating the process on switch ports 3, 4, and 5 with each port using a new destination network address and the same DUT MAC address will cause the DUT to be subjected to a total of 5 Gigabits/second load. Adding additional Singulus G1-Ts will provide an additional 2 Gigabits/second load maximum per unit. Of course the replication idea may be applied to streaming media sources other than video and to other rates besides 1 and 10 Gigabit/second and the actual addresses used may be configured as desired by the user.
Since the replicated streams are produced at media rate within the Singulus G1-T, they will have the temporal characteristics of the inbound stream. For example, if the Singulus receives a burst of 5 packets with minimum IPG, it will generate a remapped burst of 5 packets with minimum IPG. If the switch forwards the traffic with the same temporal fidelity it receives from the stream source, then the aggregate output produced from the equipment ensemble will be similar to that produced from the server but scaled by a factor corresponding to the number of switch ports and Singulus' used. In any case, the replicated stream packets will follow the original packets on the switch output with minimum IPG. This should be considered when determining the test conditions for the DUT.
Dropped packets may also be selectively introduced in each replicator to further stress the DUT.
Rerouting Subnet Traffic for A/B Comparison Testing
During network commissioning or when a network reconfiguration is planned, it is useful to have a simple way to redirect traffic from a large number of users to verify and test configurations. For example, it may be desirable to direct a group of subnets to an alternative router for Internet connectivity as a comparison. Or it may be useful to change a subnet's TOS or Diffserv DSCP markings for alternative priority handling downstream for performance comparison purposes -- especially if the remarked subnet is delay sensitive streaming media traffic. Or, it may be useful to redirect traffic with a particular port number, such as port #80 used for http traffic. These applications may easily be accomplished using the Singulus' remap capabilities described earlier with a network configuration as shown below.
Summary
This note summarizes how to configure the remap and user settable packet drop features supported by the Singulus G1-T and the IQController application software. A few applications are shown to give a taste of how these functions might be applied in device and system testing.
Download
