Methods, systems, and computer readable media for utilizing metadata to detect user datagram protocol (UDP) packet traffic loss

Methods, systems, and computer readable media utilizing metadata to detect UDP traffic loss in a test environment are disclosed. In one example, the method includes generating, at a user datagram protocol (UDP) traffic generation module, a plurality of UDP packets associated with a UDP stream, wherein origination information corresponding to the UDP traffic generation module is included in a payload in each of the plurality of UDP packets and receiving, at a UDP traffic receiver module, at least one of the plurality of UDP packets associated with the UDP stream. The method also includes transmitting, from the UDP traffic receiver module to the UDP traffic generation module, recipient information that identifies the UDP traffic receiver module as the receiver of the UDP stream and receiving, at the UDP traffic receiver module via a lossless environment, stream verification metrics from the UDP traffic generation module.

PRIORITY CLAIM

This application claims the benefit of Romanian Patent Application No. A/00675-2012, filed Sep. 21, 2012; the disclosure of which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

The subject matter described herein relates to network equipment testing. More specifically, the subject matter relates to methods, systems, and computer readable media for utilizing metadata to detect user datagram protocol (UDP) traffic loss.

BACKGROUND

In a network element test environment, the ability to generate an accurate loss statistic for stateless user datagram protocol (UDP) traffic is difficult to achieve. Specifically, a UDP packet does not contain sufficient information within the packet header to allow for the detection or identification of missing UDP packets lost at the end of the stream. Likewise, entire UDP streams may also be lost due to UDP packets not containing information that can be used to identify lost UDP packets associated with a common stream. The inability to detect or identify lost UDP packets can result in inefficiencies and increased costs within a test environment.

Accordingly, in light of these difficulties, a need exists for methods, systems, and computer readable media for utilizing metadata to detect UDP packet traffic loss.

SUMMARY

Methods, systems, and computer readable media for utilizing metadata to detect user datagram protocol (UDP) packet traffic loss are disclosed. In one embodiment, the method includes generating, at a user datagram protocol (UDP) traffic generation module, a plurality of UDP packets associated with a UDP stream, wherein origination information corresponding to the UDP traffic generation module is included in a payload in each of the plurality of UDP packets and receiving, at a UDP traffic receiver module, at least one of the plurality of UDP packets associated with the UDP stream. The method also includes transmitting, from the UDP traffic receiver module to the UDP traffic generation module, recipient information that identifies the UDP traffic receiver module as the receiver of the UDP stream and receiving, at the UDP traffic receiver module via a lossless environment, stream verification metrics from the UDP traffic generation module.

As used herein, the term “node” refers to a physical computing platform including one or more processors and memory.

As used herein, the terms “function” or “module” refer to software in combination with hardware and/or firmware for implementing features described herein. In some embodiments, a module may include a field-programmable gateway array (FPGA), an application-specific integrated circuit (ASIC), or a processor.

DETAILED DESCRIPTION

The subject matter described herein discloses methods, systems, and computer readable media for utilizing metadata to detect user datagram protocol (UDP) packet traffic loss. Although the following description describes the present subject matter as applied to UDP packet communication via a network element test environment, the disclosed methods, systems, and computer readable media may be applied to other networks, packet-based protocols, and/or applications without departing from the scope of the present subject matter. For example, the present subject matter may be applied to any communication network in which packet-based signaling/messaging is configured to traverse different network elements or devices and packet loss is a concern.

According to one aspect of the present subject matter, a UDP test packet generator associated with a test system is adapted to generate a related sequence of UDP packets that are assigned to a UDP stream, where the UDP stream is identified within the test system by a unique stream identifier (StreamID) value. Further, each UDP packet associated with the stream is modified to include the stream identifier value in the payload portion of the packet. Also included in the payload portion of the packet is a sequence number identifier which indicates the number and relative order and/or position of the UDP packet within the UDP stream.

Each UDP packet in the stream is transmitted from a first test port associated with the test system, where in one embodiment the first test port is identified by a first card identifier and a first port identifier. It will be appreciated that in other embodiments of the present invention, other identifiers that can be used to identify the first test port may be used. Prior to transmission, the card identifier and port identifier associated with the UDP test packet generator of the packet is also included in the payload of each UDP test packet in the stream. After traversing a system or device under test, the UDP stream is received by a UDP test packet receiver. Upon receiving the UDP stream, the UDP test packet receiver utilizes information contained in the packet payload(s) to confirm its recipient status via a lossless environment/connection. The lossless environment/connection may then be used by the UDP test packet generator to provide stream verification metrics to the UDP test packet receiver, which in turn uses the information to generate an accurate loss statistic for the received UDP packet stream.

FIG. 1depicts an exemplary test environment100utilizing an exemplary inter-port communication pathway to conduct signaling via a lossless backplane connection according to an embodiment of the subject matter described herein. In the embodiment shown inFIG. 1, test environment100may include a test system102that generates UDP packet streams that traverse a device under test (DUT)108. In some embodiments, DUT108may include a network address translator (NAT) device, a firewall device, a network router, a proxy server, a gateway element, or the like. Test system102may comprise a server element104and a client element106. In some embodiments, server element104and client element106may comprise a source (or receiver) card, a chassis blade, or any other device that includes at least one port for sending or receiving UDP packets to each other or via DUT108.

In one embodiment, server element104may contain a UDP traffic generation module105that is configured to generate a UDP stream that includes a plurality of UDP packets. Each UDP packet generated by UDP traffic generation module105includes a payload section that is configured to contain origination information associated with server element105. For example, the origination information may include a stream identifier, a sequence identifier, an originating (i.e., source) card/blade identifier, and an originating (i.e., source) port identifier. The stream identifier may include an alphanumeric identifier that is associated with and identifies the generated UDP packet stream (e.g., “Stream ID: 1”). The sequence identifier is a numeric identifier that identifies a single packet with respect to a particular UDP packet stream. For example, the sequence identifier may indicate the number and relative order and/or position of the UDP packet within the UDP stream (e.g., Sequence #: 1000). The originating card/blade identifier and originating port identifier may refer to identifiers/numbers corresponding to a specific card/blade (e.g., Source Card ID: 1) that makes up server element104and a specific receiving port (e.g., Source Test Port ID: 1) belonging to server element104, respectively. In one embodiment, the generated UDP stream is directed to client element107via DUT108.

In one embodiment, client element106may include a UDP traffic receiver module107that is configured to receive a UDP stream that includes a plurality of UDP packets. For example, UDP traffic receiver module107may receive a UDP packet stream generated by UDP traffic generation module105and forwarded by DUT108. Upon receiving a UDP packet from DUT108, UDP traffic receiver module107is configured to access at least a portion of the origination information included in the packet payload. For example, UDP traffic receiver module107may extract the stream identifier (e.g., “Stream ID: 1”), originating card identifier (e.g., Source Card ID: 1) and originating port identifier (e.g., Source Test Port ID: 1) from a received UDP packet. UDP traffic receiver module107may then generate an ownership notification message that includes the stream identifier extracted from the received UDP packet and recipient information, such as a receiver card identifier (e.g., Receiver Card ID: 2) and a receiver test port identifier (e.g., Receiver Test Port ID: 2) associated with client element106. Notably, the stream identifier included in the ownership notification message serves as an indication that client element106is the actual recipient (i.e., the end destination) of the received UDP stream associated with the stream identifier (e.g., “Stream ID: 1”) included in the message. The ownership notification message may be addressed to server element104using the source card identifier and the source port identifier included in the received UDP packet. Notably, the ownership notification message is communicated to server element104via a lossless environment. As used herein, “lossless” or “no loss” indicates that information communicated between a UDP test packet generator (e.g., server element104) and a UDP test packet receiver (e.g., client element106) via a preferred communication pathway will not be lost as a result of the transmission process associated with the communication pathway. InFIG. 1, the lossless environment includes a “no loss” backplane connection110. Exemplary backplane connection110may comprise an Ethernet fabric, a parallel communication bus, a serial communication bus, or the like. The lossless environment utilized by modules105and107may alternatively include a lossless internal mid-plane connection.

Upon receiving the ownership notification message from client element106, server element104generates stream verification metrics associated with the stream identifier (e.g., Stream ID: 1) indicated in the ownership notification message. In one embodiment, the stream verification metrics includes information indicating the number of total packets belonging to the indicated UDP stream (e.g., Stream ID: 1) that was sent by server element104to client element106. Server element104may subsequently generate a response message, which includes the stream verification metrics data, to be sent to client element106via lossless backplane connection110. By providing client element106with stream verification information, the present subject matter provides a reliable mechanism by which a UDP packet test system can identify and/or detect UDP packets that are lost at the end of a UDP stream.

Upon receiving the response message containing the stream verification metrics data, client element106may generate a loss statistic for the associated UDP stream. In one embodiment, client element106may extract the stream verification metrics data from the response message and conduct a packet loss analysis. For example, client element106may compare the number of “total packets sent” indicated in the stream verification metrics data with the actual number of UDP packets (belonging to the UDP stream associated with Stream ID: 1) received from server element104. If the two number values match, then the loss statistic derived by client element106will equal to zero and client element106will determine that no packets associated with the communicated UDP stream were lost. However, if the two number values do not match, then client element106will derive a loss statistic indicating the number of packets lost during the communication of the UDP stream from server element104to client element106.

In some testing scenarios, the entire UDP packet stream may be lost. Specifically, UDP packets associated with the lost UDP stream are not received by any of the UDP test packet receivers (e.g., client element106) in test environment100or test system102. In such a scenario, the UDP test packet generator (e.g., server element104) will not receive an ownership notification message associated with the lost UDP stream and may be configured to signal one or more predefined/default UDP test packet receivers with information indicating that the UDP stream was lost (i.e., UDP stream was sent and never received by a UDP test packet receiver). Such complete loss incidents are important to detect and report when test a DUT using UDP packet traffic.

FIG. 2is a diagram illustrating a test environment utilizing an exemplary inter-port communication pathway to conduct signaling via an external cable connection according to an embodiment of the subject matter described herein. In the embodiment shown inFIG. 2, the test system includes two separate elements, such as a first test chassis201and a second test chassis202, which may be co-located with a DUT208in test environment200. First test chassis201and a second test chassis202may also be communicatively coupled via an external connection210. In one embodiment, the external connection may be an external cable connection.

In one embodiment, server element204may contain a UDP traffic generation module205that is configured to generate a UDP stream that includes a plurality of UDP packets. Each UDP packet generated by UDP traffic generation module205includes a payload section that is configured to contain origination information associated with server element204, such as a stream identifier, a sequence identifier, an originating (i.e., source) card/blade identifier, and an originating (i.e., source) port identifier. In one embodiment, the generated UDP stream is directed to client element207via DUT208.

In one embodiment, client element206may include a UDP traffic receiver module207that is configured to receive a UDP stream. For example, UDP traffic receiver module207may receive a UDP packet stream generated by UDP traffic generation module205and forwarded by DUT208. Upon receiving a UDP packet from DUT208, UDP traffic receiver module207is configured to access and extract at least a portion of the origination information included in the packet payload, such as the stream identifier (e.g., “Stream ID: 1”), originating card identifier (e.g., Source Card ID: 1) and originating port identifier (e.g., Source Test Port ID: 1). UDP traffic receiver module207may then generate an ownership notification message that includes the stream identifier and recipient information, such as a receiver card identifier (e.g., Receiver Card ID: 2) and a receiver test port identifier (e.g., Receiver Test Port ID: 2) associated with client element206. Notably, the stream identifier included in the ownership notification message serves as an indication that client element206is the actual recipient (i.e., the end destination) of the received UDP test stream. The ownership notification message may be addressed to server element204using the previously extracted source card identifier and the source port identifier and may be communicated to server element204via a lossless environment. InFIG. 2, the lossless environment includes a “no loss” external connection210. Exemplary external connection210may comprise an external cable connection, such as a RS232, Fir2Wire, SATA, E-SATA, SCSI, SAS DAS, fibre channel (FC) or iSCSI cable connection.

Upon receiving the ownership notification message from client element206, server element204generates stream verification metrics associated with the stream identifier (e.g., Stream ID: 1) indicated in the ownership notification message. In one embodiment, the stream verification metrics includes information indicating the number of total packets belonging to the indicated UDP stream (e.g., Stream ID: 1) that was sent by server element204to client element206. Server element204may subsequently generate a response message, which includes the stream verification metrics data, to be sent to client element206via lossless backplane connection210.

Upon receiving the response message containing the stream verification metrics data, client element206may generate a loss statistic for the associated UDP stream. In one embodiment, client element206may extract the stream verification metrics data from the response message and conduct a packet loss analysis in an identical manner discussed above with respect toFIG. 1.

FIG. 3is a diagram illustrating a test environment utilizing an exemplary inter-port communication pathway to conduct signaling via a shared data storage element according to an embodiment of the subject matter described herein. In one embodiment, the shared data storage element may include a local cache or database. In the embodiment shown inFIG. 3, test system302may include a server element304and client element306, each of which has communication access to shared data storage element310. Exemplary shared data storage modules may include random access memory, magnetic storage media (e.g., hard disks), optical storage media (e.g., CD, DVD, or Blu-ray discs), or other non-transitory computer readable media.

In one embodiment, server element304may contain a UDP traffic generation module305that is configured to generate a UDP stream that includes a plurality of UDP packets. Each UDP packet generated by UDP traffic generation module305includes a payload section that is configured to contain origination information associated with server element304, such as a stream identifier, a sequence identifier, an originating (i.e., source) card/blade identifier, and an originating (i.e., source) port identifier. In one embodiment, the generated UDP stream is directed to client element307via DUT308.

Upon sending the entire generated UDP stream, server element304is configured to generate and send a message to shared data storage element310via a lossless environment, such as a lossless backplane connection312. In one embodiment, the message may include a “write” message that serves to provision shared data storage element310with an entry indicating the total number of packets sent (i.e., the stream verification metrics data) in the previously generated UDP stream. For example, the message may include the stream identifier (e.g., Stream ID: 1) and the stream verification metrics data (e.g., 1000 total packets sent). In one embodiment, the information may be provisioned as an entry in shared data storage element310and indexed by the stream identifier.

In one embodiment, client element306may include a UDP traffic receiver module307that is configured to receive the generated UDP stream. For example, UDP traffic receiver module307may receive the UDP packet stream generated by UDP traffic generation module305and forwarded by DUT308. Upon receiving a UDP packet from DUT308, UDP traffic receiver module307is configured to access and extract at least a portion of the origination information included in the packet payload, such as the stream identifier (e.g., “Stream ID: 1”). UDP traffic receiver module307may then generate and a query message that includes the stream identifier to shared data storage element310via lossless backplane connection312. Upon receiving the query message, shared data storage element310may access its contents using the stream identifier and obtain the associated stored information (i.e., the stream verification metrics data). In one embodiment, shared data storage element310may subsequently generate and send a response message containing the total packets sent data to client element306via lossless backplane connection312.

Upon receiving the response message containing the stream verification metrics data, client element306may generate a loss statistic for the associated UDP stream. In one embodiment, client element306may extract the stream verification metrics data from the response message and conduct a packet loss analysis in an identical manner discussed above with respect toFIG. 1.

FIG. 4is a diagram illustrating a test environment utilizing an exemplary inter-port communication pathway to conduct signaling via a wireless connection link according to an embodiment of the subject matter described herein. In the embodiment shown inFIG. 4, the test system includes two separate elements, such as a first test chassis401and a second test chassis402, which may be co-located with a DUT408in test environment400. First test chassis401and a second test chassis402may also be communicatively coupled via wireless communication modules (WCMs)413and414. In one embodiment, WCM413and WCM414include inter-port WCMs that are configured to establish a “no loss” wireless communication pathway or link that functions as a lossless environment. For example, the lossless wireless connection link may be a Wi-Fi connection, a WiMAX connection, a Bluetooth connection, or the like.

In one embodiment, server element404may contain a UDP traffic generation module405that is configured to generate a UDP stream that includes a plurality of UDP packets. Each UDP packet generated by UDP traffic generation module405includes a payload section that is configured to contain origination information associated with server element404, such as a stream identifier, a sequence identifier, an originating (i.e., source) card/blade identifier, and an originating (i.e., source) port identifier. In one embodiment, the generated UDP stream is directed to client element407via DUT408.

In one embodiment, client element406may include a UDP traffic receiver module407that is configured to receive a UDP stream. For example, UDP traffic receiver module407may receive a UDP packet stream generated by UDP traffic generation module405and forwarded by DUT408. Upon receiving a UDP packet from DUT408, UDP traffic receiver module407is configured to access and extract at least a portion of the origination information included in the packet payload, such as the stream identifier (e.g., “Stream ID: 1”), originating card identifier (e.g., Source Card ID: 1) and originating port identifier (e.g., Source Test Port ID: 1). UDP traffic receiver module407may then generate an ownership notification message that includes the stream identifier and recipient information, such as a receiver card identifier (e.g., Receiver Card ID: 2) and a receiver test port identifier (e.g., Receiver Test Port ID: 2) associated with client element406. Notably, the stream identifier included in the ownership notification message serves as an indication that client element406is the actual recipient (i.e., the end destination) of the received UDP test stream. The ownership notification message may be addressed to server element404using the previously extracted source card identifier and the source port identifier and may be communicated to server element404over a lossless environment via WCM414. InFIG. 4, the lossless environment includes a “no loss” wireless connection410. Lossless wireless connection410may comprise a Wi-Fi connection, a WiMAX connection, a Bluetooth connection, or the like.

Upon using WCM413to wirelessly receive the ownership notification message from WCM414over the lossless wireless communication pathway/link410, server element404generates stream verification metrics associated with the stream identifier (e.g., Stream ID: 1) indicated in the ownership notification message. In one embodiment, the stream verification metrics includes information indicating the number of total packets belonging to the indicated UDP stream (e.g., Stream ID: 1) that was sent by server element404to client element406. Server element404may subsequently generate a response message, which includes the stream verification metrics data, to be sent to client element406over lossless backplane connection410via WCM413.

Upon using WCM414to receive the response message containing the stream verification metrics data from WCM413over the lossless wireless communication pathway/link410, client element406may generate a loss statistic for the associated UDP stream. In one embodiment, client element406may extract the stream verification metrics data from the response message and conduct a packet loss analysis in an identical manner discussed above with respect toFIG. 1.

FIG. 5is a diagram illustrating an exemplary method500for utilizing metadata to detect user datagram protocol (UDP) traffic loss according to an embodiment of the subject matter described herein. In some embodiments, the exemplary process described herein, or portions thereof, may be performed by a test system, DUT, and/or another node or module. AlthoughFIG. 5may refer to the embodiment and elements depicted inFIG. 1, any of the embodiments and elements depicted inFIGS. 2-4may be utilized without departing from the scope of the present subject matter.

In block502, a UDP stream comprising a plurality of UDP packets with payloads containing origination information is generated. In one embodiment, a UDP test packet generator (e.g., UDP traffic generation module105) associated with a test system is configured to generate a related sequence of UDP packets that are assigned to a UDP stream. The UDP stream is identified within the test system by a unique stream identifier. Moreover, each UDP packet associated with the stream is modified to include the stream identifier (e.g., Stream ID: 1) in the payload portion of the packet. Also included in the payload portion of the packet is a sequence number identifier (e.g., sequence identifier) which indicates the number and relative order and/or position of the UDP packet within the UDP stream. Each UDP packet in the stream is transmitted from a first test port associated with the server element of the test system. In one embodiment, the first test port is identified by a first card identifier (or blade identifier) and a first port identifier.

In block504, one or more UDP packets of the UDP stream are received. In one embodiment, UDP traffic generation module105transmits the UDP stream to UDP traffic receiver module107via a DUT108. For example, the stream of UDP test packets directed to UDP traffic receiver module107may be received by DUT108, which in turn routes and/or forwards the UDP packets to UDP traffic receiver module107. In one embodiment, UDP traffic receiver module107is configured to examine a received UDP packet associated with a stream and extract from the payload portion of the packet the stream identifier, a sequence identifier, a source card identifier, and source port identifier values previously included in the origination message sent by UDP traffic generation module105.

In block506, recipient information is transmitted. In one embodiment, UDP traffic receiver module107is configured to signal UDP traffic generation module105, using the obtained stream identifier, source card identifier, and source port identifier. The purpose of this signaling transaction is to notify UDP traffic generation module105of the identity and/or the contact address of UDP traffic receiver module107as the receiver of the stream. In addition, the signaling transaction also generally indicates to UDP traffic generation module105that at least of portion of the transmitted UDP stream has, in fact, been received. As such, UDP traffic receiver module107may include a receiver card identifier and a receiver port identifier in the signaling message that is sent to UDP traffic generation module105.

In block508, a response message containing stream verification metrics information is received. Upon receiving of the “ownership” notification signaling message, UDP traffic generation module105is adapted to signal UDP traffic receiver module107that “owns” the stream with information that can be used to verify the transmitted UDP stream. Exemplary verification information may include, but is not limited to, the total number of UDP packets in the stream that were transmitted, the total size of all UDP packets in the stream that were transmitted, checksum information associated with the UDP packets in the stream that were transmitted, and the like.

In block510, a loss statistic for the UDP stream is generated. In one embodiment, client element106may extract the stream verification metrics data from the response message and conduct a packet loss analysis. For example, client element106may compare the number of “total packets sent” indicated in the stream verification metrics data with the actual number of UDP packets in the UDP stream received from server element104. If the two number values match, then the loss statistic derived by client element106will equal to zero and client element106will determine that no packets associated with the communicated UDP stream have been lost. However, if the two number values do not match, then client element106will derive a loss statistic indicating the number of packets lost during the communication of the UDP stream from server element104to client element106.