Error detection/correction and fault detection/recovery – Pulse or data error handling – Digital logic testing
Reexamination Certificate
2000-11-28
2004-08-24
Decady, Albert (Department: 2133)
Error detection/correction and fault detection/recovery
Pulse or data error handling
Digital logic testing
C714S776000, C714S758000
Reexamination Certificate
active
06782503
ABSTRACT:
TECHNICAL FIELD
The invention relates to generation of test packets for testing network interconnect devices.
BACKGROUND
Various different types of data networks exist that provide for many types of communications, such as electronic mail, file transfer, web browsing, text chat, and other exchanges of data. With the increased bandwidth and speed of data networks, communications of voice and other forms of real-time, interactive data have also become possible. Examples of the different types of data networks include local area networks (LANs), wide area networks (WANs), the Internet, and so forth.
Terminals and nodes coupled to a data network include various layers, such as layers according to the Open Systems Interconnect (OSI) model. The lowest layer (layer
1
) is the physical layer, which is the actual electrical and mechanical interface to the transport medium. The next higher layer (layer
2
) is referred to as the data link layer, which is responsible for delivery of information to the transport medium and for error checking the information. The next layer (layer
3
) is referred to as the network layer, which is responsible for the switching and routing of the connection. Other layers are also part of the OSI model.
One example of a layer
2
protocol is the Ethernet protocol, with one version specified in the 802.3 Standard from the Institute of Electrical and Electronics Engineers (IEEE). One example of a layer
3
protocol is the Internet Protocol (IP).
An Ethernet frame includes a destination address, a source address, payload data, and a cyclic redundancy check (CRC) field (for error detection). The payload data of the Ethernet frame carries a layer
3
datagram, such as an IP datagram. An IP datagram also includes a protocol header and a payload. The IP header includes a source network address, a destination network address, control flags, a protocol field to indicate the next level protocol used in the payload of the IP datagram, a header checksum that is calculated based on the content of the IP header, and other information.
A data network includes a number of switches or routers to enable communication of data between endpoints. Packets that are communicated over the data networks contain addresses that are used by switches or routers to forward or route packets to the appropriate path for delivery to the destination.
When a switch or router is manufactured, it is run through a variety of tests. Many of these tests involve sending test packets from a test generator, with the test packets passed through the switch or router under test. The switch or router under test forwards the packets to a receiving test device, which determines if the packets contain errors or not. In conventional test systems designed for verifying some layer
2
switches, a simple check for CRC errors is usually sufficient to identify data corruption. Since many layer
2
switches do not change the contents of packets passing through the switches, the original CRC of the test packet remains unchanged as it passes through the system under test (assuming data corruption did not occur in the system under test). At the receiving end, the receiving test device can simply perform a CRC error detection to determine if data corruption has occurred.
At the transmitting end of every Ethernet system, the CRC value placed into a packet is calculated at the OSI data link layer based on the bit pattern of the Ethernet frame (including the source address, destination address, and payload). At the receiving end of every Ethernet system, the CRC of a received frame is re-calculated to check for errors in transmission. If any of the bits of the destination address, source address, or payload, changes value in transit, then the CRC check performed at the receiving end is designed to indicate that data corruption has occurred. The check at the receiving end is performed at the data link layer by concatenating the data pattern and the CRC bits, with the concatenated bit pattern divided by a preselected divisor polynomialP (which is also used at the transmitting end to generate the CRC bits). If the division produces no remainder (that is, the remainder is zero), then the CRC algorithm provides a reliable indication that no errors have occurred.
Although CRC checking is quick and easy to perform in hardware, and is relatively accurate with layer
2
switches that do not change the content of the test packet, such testing may be insufficient if the switch or router under test is capable of changing the content of test packets, such as the content of the IP header. Some layer
2
switches are able to modify contents of the IP header, such as to change type of service information or to add or change virtual local area network (VLAN) tags. A layer
3
switch or router almost always changes the content of the packet header. Usually the layer
3
switch or router changes the destination and source addresses in the header as well as recalculates a new checksum due to the change of the header. Another type of switch that may cause contents of packets to change is a switch including Asynchronous Transfer Mode (ATM) core device.
When the switch or router under test modifies the content of a packet, a new CRC value is calculated for the modified packet before the switch or router under test transmits the packet to the receiving test device. Thus, at the receiving test device, performance of the CRC error detection will merely indicate if the CRC value generated by the switch or router under test was correct for the data transmitted. The CRC protects against data corruption for the transport medium from the switch or router under test to the receiving test device. However, simple CRC checking at the receiving test device does not enable confirmation regarding whether the switch or router under test performed error-free processing of the packet. Even if the switch or router under test is defective and performs packet header transformations incorrectly, the CRC value calculated by the medium access control (MAC) module in the switch or router under test will still be correct, since the calculated CRC is based on the incorrect packet content. As a result, simple CRC checking does not enable verification of the content of the packet which has been processed by a switch or router under test.
A need thus exists for an improved testing apparatus and method.
SUMMARY
In general, according to one embodiment, a method to enable testing of a system under test comprises storing a header field representing a header of a test packet after transformation by the system under test and storing a target check value. A splice value is calculated for including in the test packet, the splice value being based on the header field, target check value, and a payload of the test packet.
Some embodiments of the invention may have one or more of the following advantages. Verification of test packet content can be performed in tests involving systems or devices that are capable of transforming packet content, such as the header of the packet. The verification can be performed efficiently and at relatively high speed. In some arrangements, the verification of packet content can be performed at substantially wire speeds so that the system or device can be tested at high packet transfer speeds.
REFERENCES:
patent: 4486877 (1984-12-01), Turner
patent: 5673279 (1997-09-01), Oskouy et al.
patent: 5787094 (1998-07-01), Cecchi et al.
patent: 5802105 (1998-09-01), Tiedemann, Jr. et al.
patent: 6038000 (2000-03-01), Hurst, Jr.
patent: 6067303 (2000-05-01), Aaker et al.
patent: 6481012 (2002-11-01), Gordon et al.
U.S. patent application Ser. No. 09/723,388, Dawson, filed Nov. 28, 2000.
U.S. patent application Ser. No. 09/723,836, Dawson, filed Nov. 28, 2000.
Chaudry Mujtaba
De'cady Albert
Nortel Networks Limited
Trop Pruner & Hu P.C.
LandOfFree
Generating a signature to add to a test packet to achieve a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Generating a signature to add to a test packet to achieve a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Generating a signature to add to a test packet to achieve a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3318443