Packet communication testing apparatus and associated methods

A system includes a packet generator and a packet checker. The packet generator is operable to operable to generate a packet for transmission to a destination device. The packet includes a plurality of fields, including a code field that is operable to store a code generated based on an expected modification to the packet during transmission. The packet checker is associated with the destination device and is operable to receive the packet.

TECHNICAL FIELD

The disclosed concepts relate generally to communication apparatus and related techniques and, more particularly, to apparatus for testing packet processing systems/apparatus, and associated methods.

BACKGROUND

Modern communication systems and apparatus commonly use packets. In other words, rather than the circuit-switched systems in relatively wide use previously, present-day communication systems increasingly use packet-switched techniques, i.e., packet-processing techniques.

Packet-processing systems typically include some mechanism for testing the packets. For example, some systems embed or add a cyclic redundancy code (CRC) or checksum to a packet for testing purposes. Testing increases the reliability of the packet transmission and reception. Thus, testing ultimately increases the reliability and robustness of the communication system. In a conventional scheme, the packet has several fields, including a destination field, a source field, a data field, and a cyclic redundancy check (CRC) field. The CRC field typically includes a CRC value for all the fields in the packet as it exists before transmission and without regard to the transmission channel, destination, etc.

SUMMARY

In one exemplary embodiment, a system includes a packet generator and a packet checker. The packet generator is operable to operable to generate a packet for transmission to a destination device. The packet includes a plurality of fields, including a code field that is operable to store a code generated based on an expected modification to the packet during transmission. The packet checker is associated with the destination device and is operable to receive the packet.

In another exemplary embodiment, an apparatus includes a code generator that generates a code for inclusion in a packet. The code is generated by taking into account changes to the packet during transit from a packet source to a packet destination. In yet another exemplary embodiment, a method of communicating a packet from a source to a destination via a packet path includes obtaining a characteristic of the packet path, and generating a code depending on the characteristic of the packet path. The method further includes including the code in the packet.

DETAILED DESCRIPTION

The disclosed concepts relate generally to packet-processing systems. More specifically, the disclosed concepts provide apparatus and methods for testing packet-processing systems. The testing has application in communication systems, in testing systems, in design and development environments, in research and development environments, etc. Of course, as persons of ordinary skill in the art who have the benefit of the description of the disclosed concepts understand, one may use the disclosed concepts in other contexts and applications, as desired.

Exemplary embodiments according to the disclosed concepts take into account the packet's path, for example, one or more device, or apparatus, and/or link or channel that can modify or cause change to the packet. The embodiments include a code or code field used to confirm or verify proper system operation, proper device operation, proper communication of packets, etc. Thus, the code or code field of the packet, as transmitted from a source, takes into account any changes to the packet that might occur during transit via the packet path from the source to the destination.

By doing so, exemplary embodiments provide the benefit of supplying a correct code field or value at the destination, i.e., a code field or value that accounts for changes to the packet while in transit. Such code fields or values provide more reliable packet-based communication and, thus, more reliable and robust systems that include packet-based communication or packet processing.

Several mechanisms might give rise to packet changes while in transit in the packet path. For example, an intervening or intermediary device between the packet's source and ultimate destination might change the packet by substituting its own address in the packet's address field. As another example, an intervening or intermediary device might modify the data field of the packet.

A variety of techniques or schemes may be used to generate the code values or code fields for inclusion in the packets according to exemplary embodiments. Examples include CRC, parity, checksum, cryptographic hashes, error-detecting and/or error-correcting codes (e.g., Reed Solomon), and the like. The choice of code depends on a variety of factors, such as system or device specifications, the degree of error detection or error correction desired, the amount of hardware and/or software overhead tolerable or possible, etc.

FIG. 1Adepicts a block diagram of a system130according to an exemplary embodiment. Specifically, system130allows the testing of a device, e.g., device under test (DUT), by using one or more packets. System130includes a generator or source133of packets, one or more DUTs139, and a destination or checker145of packets. Thus, the packet path includes link136, DUT(s)139, and link142.

Generator133generates one or more packets and transmits the generated packets to checker145via DUT(s)139. Specifically, generator133may transmit the packet(s) to DUT(s)139via link136. DUT(s)139in turn transmits the packet(s) to checker145via link142. Checker145checks or examines the packet(s) to verify the operation of DUT(s)139.

The generated packets may be modified by DUT(s)139during their transmission from generator133to checker145via a packet path. Accordingly, one or more portions, e.g., fields, of the packet(s) may be modified. Furthermore, the generated packet may similarly be modified by other parts of system130, e.g., links136and/or142, routers, switches, etc.

Generator133accounts for changes to the packet(s) in the code values that are included or encoded in the code field(s) of the packet(s). Specifically, generator133generates the code values of the packet(s) based not only on the original contents of the packet(s) but also based on the changes that the packet(s) will experience during transit from generator133to checker145, i.e., in the packet path. In some exemplary embodiments, changes to the packets may be accounted for in a priori fashion.

Checker145receives the packet(s) via link142. Checker145may calculate a code value associated with the received packets. Checker145may determine whether the DUT, link(s)136and142, etc., have operated as expected, as desired, etc. by comparing the calculated code to the code(s) included in the packet(s) code field(s).

FIG. 1Billustrates a block diagram of a system150according to another exemplary embodiment. System150allows verification or confirmation of the operation of one or more devices and/or links in the path of packet(s).

System150includes a generator or source133of packets, one or more intervening or intermediary devices153, and a destination or checker145of packets. The packet path includes link136, intervening or intermediary device(s)153, and link142.

Generator133generates one or more packets similar to that ofFIG. 1A. The generated packets are transmitted to checker145via intervening or intermediary device(s)153. Specifically, generator133transmits the packet(s) to intervening or intermediary device(s)153via link136. Intervening or intermediary device(s)153in turn transmits the packet(s) to checker145via link142. Checker145checks or examines the packet(s) to determine verification of the operation of one or more parts of system150, e.g., intervening or intermediary device(s)153.

Note that intervening or intermediary device(s)153might modify the contents of the packet(s) while they are in transit from generator133to checker145. As noted above, the modifications to the packets might change one or more parts of the packet(s). Furthermore, other parts of system150(for example, links136and/or142) might modify the packet, for example, via routers, switches, or other devices (not shown explicitly).

Generator133takes into account those changes to the packet(s), and accounts for them in the code values encoded or included in the code field(s) of the packet(s). Specifically, generator133generates the code values of the packet(s) based not only on the original contents of the packet(s) but also on the changes that the packet(s) will experience during transit from generator133to checker145. Put another way, generator133accounts for expected changes to the packet(s) during transit of the packet, for example, via the packet(s) path(s), and generates or calculates code value(s) for the packet(s) based at least in part on the expected changes. The generated or calculated code value(s) are encoded within the respective packet(s), for example, in code field(s)212.

Checker145receives the packet(s) via link142, and calculates a code value for each packet. By comparing the calculated code to the code(s) included in the code field(s) of the packet(s), checker145can determine the correct operation of the intervening or intermediary device(s)153, link(s)136and142, etc., as desired.

Links136and142may include any transmission means serving as a coupling mechanism. For example, links136and142may include buses, wires, cables, optical fibers, etc. The choice of links may depend on a variety of factors. For example, the link choice may depend on specifications associated with one or more devices in system150, the type of communication or functionality desired, etc.

A variety of packet formats and structures may be used in exemplary embodiments according to the disclosed concepts (for example, the systems illustrated inFIG. 1AandFIG. 1B. As merely one example, the packet(s) may be Ethernet packets. Format of the generated packets may vary based on application, data paths, etc. Referring now toFIGS. 2A-2Bexemplary formats associated with generated packets are shown.

FIG. 2Adepicts a packet200according to an exemplary embodiment. According to one embodiment, packet200is a packet generated by the generator133and transmitted subsequent thereto. Packet200includes a destination field203(denoted as “DST”), a source field206(denoted as “SRC”), data field209, and code field212.

Data field209may be the payload and includes desired data to be transmitted via packet200. For example, data filed209may include digital communication data, speech data, video data, etc.

Destination field203is associated with the address of the destination, e.g., the address of the checker145. For example, in an Ethernet network, destination field203may include the address of a device that packet200is intended for. In this exemplary embodiment, the address associated with the destination device may be “0xDDD” (hexadecimal value “DDD”). Thus, packet200includes a destination address “0xDDD” in its destination field.

Similarly, source field206is associated the address for the source of packet200. The example packet shown inFIG. 2Ashows the address as generally “0xAAA” (hexadecimal value “AAA”). As noted above, one or more devices, for example, routers, switches, and the like, may modify the source address of packet200, i.e., source field206. Thus, the value in source field206may change during the transit of packet200form its original (or subsequent or intervening) source to its destination.

In one embodiment, code field212may include a code value that accounts for the changes that packet200experiences during its transmission from the source to the destination. In this example, code field212includes the generated code value “0xCCC,” which accounts for the changes to one or more fields (e.g., source field203) of packet200during its transmission from the source to the destination.

Note that more than one device or mechanism may alter one or more fields of packet200. Regardless of the cause or mechanism of the change(s), the code value in code field212accounts for those changes. Put another way, the code value in code field212reflects a correct code value if one calculates a code value that takes into account changes that are expected to occur to or in packet200during transmission.

FIG. 2Bshows a packet220according to an exemplary embodiment. Packet220may constitute a packet that a destination or checker (see, for example,FIGS. 1A-1B) receives.

Similar to packet200(seeFIG. 2A), packet220includes a destination field223(denoted as “DST”), a source field226(denoted as “SRC”), data field229, and code field232. Data field209may include any desired data that one wishes to transport, as described above.

Destination field203includes the address for the destination of packet220. In a typical situation, destination field203of packet220has the same value as does destination field of packet200(seeFIG. 2A) although, depending on the type of network or protocol or communication scheme, the destination might change during transit. The example packet shown inFIG. 2Bshows the address as generally “0xDDD” (hexadecimal value “DDD”).

Source field226includes the address for the source of packet220. The example packet shown inFIG. 2Bshows the address as generally “0xBBB” (hexadecimal value “BBB”). Thus, the value in source field226indicates a change of the source address in packet220when compared to packet200(seeFIG. 2A).

Referring to packet220inFIG. 2B, code field212includes a code value that, as described above, takes into account the changes that packet220experiences while in transport from the source to the destination. Depending on whether packet220has experienced any undesirable or unexpected changes while in transit, the code value in code field232of packet220inFIG. 2Bmight differ from the code value in code field212of packet200inFIG. 2A.

A checker or other device or a component of the destination device may calculate a code value associated with packet220. The checker may compare the calculated value to the code value in code field232of the received packet200. Depending on the results of the comparison, the checker may determine whether packet220has experienced any undesirable or unexpected change (e.g., whether a DUT has performed as expected, i.e., correctly, or incorrectly).

In the example shown, code field232of packet220inFIG. 2Bincludes the code value “0xCCC,” the same value as code field212of packet200ofFIG. 2A. Thus, if a checker calculates a code value of “0xCCC” for packet220, one may conclude that packet220has experienced expected changes (if any) and, hence, that the DUT(s) have performed properly, etc.

FIG. 3depicts a flow diagram300for a method of processing packets according to an exemplary embodiment. At303, characteristics of the channel or packet path (e.g., links136and142) and/or DUT(s) or intervening or intermediary device(s) is determined. At306, a code is generated based on the characteristics of the packet path or channel, e.g., channel/link and/or DUT(s) or intervening or intermediary device(s).

At309, the code is included or encoded in a code field of a packet. Subsequently, at312, the packet is transmitted to its respective destination. At the destination, a code is calculated and compared to the code value included in the packet. Depending on the results of the comparison (whether the codes are the same), it can be determined whether the path from the source to the destination has affected the packet in an expected or correct manner or not. For example, one may determine whether one or more DUT(s), links, etc., operated correctly or as expected.

One aspect of the disclosed concepts relates to simulation of various packet-processing apparatus, systems, subsystems, etc. Specifically, one may use the packet-processing techniques to implement methods or algorithms on a computing device or system for logic simulation.

FIG. 4illustrates a flow diagram400for a method of performing simulation according to an exemplary embodiment. At403, a simulation model of the channel and/or the DUT(s) or intervening or intermediary device(s) that are located between a source and a destination is generated. At406, a code (or a packet, including a code field) is generated based on the model.

At409, the device or system is simulated, using the simulation model of the system and the generated code. The simulated model of the system may cause changes the code, based on the characteristics of the system, e.g., how the system modifies or calculates data, etc. At412, the performance of the system is evaluated by examining the simulation results. More specifically, by examining the value of the code after it has been processed by the simulated system, one may determine whether the system performed as expected or correctly.

A computer system, a device, a processor, a controller, etc., may perform, run, or execute the disclosed algorithms, methods, or software in accordance with embodiments of the present invention.FIG. 5shows a block diagram of an exemplary system1000for processing information according to exemplary embodiments of the disclosed concepts. System1000includes a computer device1005, an input device1010, a video/display device1015, and a storage/output device1020, although one may include more than one of each of those devices, as desired.

Computer device1005couples to input device1010, video/display device1015, and storage/output device1020. System1000may include more than one computer device1005, for example, a set of associated computer devices or systems, as desired.

Typically, system1000operates in association with input from a user. The user input typically causes system1000to perform specific desired information-processing tasks, including the tasks described above, such as packet processing, packet-processing apparatus testing, packet-testing, etc. System1000in part uses computer device1005to perform those tasks. Computer device1005includes information-processing circuitry, such as a processor, a central-processing unit (CPU), a controller, a microcontroller, etc., although one may use more than one such device or information-processing circuitry, as persons skilled in the art would understand.

Input device1010receives input from the user and makes that input available to computer device1005for processing. The user input may include data, instructions, etc. Input device1010may constitute an alphanumeric input device (e.g., a keyboard), a pointing device (e.g., a mouse, roller-ball, light pen, touch-sensitive apparatus, for example, a touch-sensitive display, or tablet), or both. The user operates the alphanumeric keyboard to provide text, such as ASCII characters, to computer device1005. Similarly, the user operates the pointing device to provide cursor position or control information to computer device1005.

Video/display device1015displays visual images to the user. Video/display device1015may include graphics circuitry, such as graphics processors, as desired. The visual images may include information about the operation of computer device1005, such as graphs, pictures, images, and text. Video/display device1015may include a computer monitor or display, a projection device, and the like, as persons of ordinary skill in the art would understand. If system1000uses a touch-sensitive display, the display may also operate to provide user input to computer device1005.

Storage/output device1020allows computer device1005to store information for additional processing or later retrieval (e.g., softcopy), to present information in various forms (e.g., hardcopy), or both. As an example, storage/output device1020may include a magnetic, optical, semiconductor, or magneto-optical drive capable of storing information on a desired medium and in a desired format. As another example, storage/output device1020may constitute a printer, plotter, or other output device to generate printed or plotted expressions of the information from computer device1005.

Computer-readable medium1025interrelates structurally and functionally to computer device1005. Computer-readable medium1025stores, encodes, records, and/or embodies functional descriptive material. By way of illustration, the functional descriptive material may include computer programs, computer code, computer applications, and/or information structures (e.g., data structures or file systems). When stored, encoded, recorded, and/or embodied by computer-readable medium1025, the functional descriptive material imparts functionality. The functional descriptive material interrelates to computer-readable medium1025.

Information structures within the functional descriptive material define structural and functional interrelations between the information structures and computer-readable medium1025and/or other aspects of system1000. These interrelations permit the realization of the information structures' functionality.

Moreover, within such functional descriptive material, computer programs define structural and functional interrelations between the computer programs and computer-readable medium1025and other aspects of system1000. These interrelations permit the realization of the computer programs' functionality. Thus, in a general sense, computer-readable medium1025includes information, such as instructions, that when executed by computer device1005, cause computer device1005(system1000, generally) to provide the functionality prescribed by a computer program, software, method, algorithm, etc., as included (partially or entirely) in computer-readable medium1025.

By way of illustration, computer device1005reads, accesses, or copies functional descriptive material into a computer memory (not shown explicitly in the figure) of computer device1005. Computer device1005performs operations in response to the material present in the computer memory. Computer device1005may perform the operations of processing a computer application that causes computer device1005to perform additional operations. Accordingly, the functional descriptive material exhibits a functional interrelation with the way computer device1005executes processes and performs operations.

Furthermore, computer-readable medium1025constitutes an apparatus from which computer device1005may access computer information, programs, code, and/or applications. Computer device1005may process the information, programs, code, and/or applications that cause computer device1005to perform additional or desired tasks or operations.

Note that one may implement computer-readable medium1025in a variety of ways, as persons of ordinary skill in the art would understand. For example, memory within computer device1005may constitute a computer-readable medium1025, as desired.

Alternatively, computer-readable medium1025may include a set of associated, interrelated, coupled (e.g., through conductors, fibers, etc.), or networked computer-readable media, for example, when computer device1005receives the functional descriptive material from a network of computer devices or information-processing systems. Note that computer device1005may receive the functional descriptive material from computer-readable medium1025, the network, or both, as desired.

Referring to the figures, persons of ordinary skill in the art will note that the various blocks shown might depict mainly the conceptual functions and signal flow. The actual circuit implementation might or might not contain separately identifiable hardware for the various functional blocks and might or might not use the particular circuitry shown. For example, one may combine the functionality of various blocks into one circuit block, as desired. Furthermore, one may realize the functionality of a single block in several circuit blocks, as desired. The choice of circuit implementation depends on various factors, such as particular design and performance specifications for a given implementation, as persons of ordinary skill in the art who have the benefit of the description of this disclosure understand. Other modifications and alternative embodiments in addition to those described here will be apparent to persons of ordinary skill in the art who have the benefit of this disclosure. Accordingly, this description teaches those skilled in the art the manner of carrying out the disclosed concepts, and is to be construed as illustrative only.

The forms and embodiments shown and described should be taken as illustrative embodiments. Persons skilled in the art may make various changes in the shape, size and arrangement of parts without departing from the scope of the disclosed concepts in this document. For example, persons skilled in the art may substitute equivalent elements for the elements illustrated and described here.

Moreover, persons skilled in the art who have the benefit of this disclosure may use certain features of the disclosed concepts independently of the use of other features, without departing from the scope of the disclosed concepts.