The present disclosure relates to networking systems and devices.
In a computer network, such as a data center, data is transmitted from a source to a destination in the form of packets that generally pass through one or more networking devices (e.g., switches, routers, firewalls, etc.). During the transmission, packets are generally temporarily stored in one or more network buffers of the networking devices.
Certain data center customers demand network architectures that can provide low latency, high bandwidth, and often massive scalability. However, measuring latency may be difficult and time sensitive applications often do not have the proper visibility into how it has taken for packets to reach a certain destination and when packets were actually sourced at specific locations in the network.
Techniques are presented herein to facilitate latency measurements in a networking environment. A first network device receives a packet for transport within a network domain that comprises a plurality of network devices. The plurality of network devices have a common time reference, that is, they are time synchronized. The first network device generates timestamp information indicating time of arrival of the packet at the first network device. The first network device inserts into the packet a tag that comprises at least a first subfield and a second subfield. The first subfield comprises a type indicator to signify to other network devices in the network domain that the tag includes timestamp information, and the second subfield includes the timestamp information. The first network device sends the packet into the network domain to another network device. Other network devices in the network domain which receive that packet can then make latency measurements, insert another tag, overwrite the tag, and perform various other operations described herein.
Reference is first made to
A packet 40 enters the network domain 10 at some edge node, e.g., network device 20(1) in the example of
A timestamp tag (TTAG) is inserted into a packet 40 by the edge network device 20(1) of the network domain 10. The TTAG includes timestamp information indicating time of arrival at network device 20(1). All of the network devices in the network domain 10 that receive the packet 40 (with the inserted TTAG) can perform measurements based on the timestamp information contained in TTAG inserted into packet 40, and perform other operations, including adding another TTAG, overwriting an existing TTAG, adding another timestamp value into an existing TTAG, etc., as will described in more detail hereinafter. As indicated in
The network devices 20(1)-20(N) shown in
Turning now to
The timestamp logic unit 23 generates a timestamp upon arrival of the packet at an ingress port 21 of the network device. The timestamp is with respect to the common time reference 30 used by all network devices in the network domain. The timestamp logic unit 23 may insert the TTAG into a packet 40 immediately upon arrival at the ingress port, and then forward the packet to be processed by the packet processing logic 26, insert the TTAG in parallel with the processing of the packet by the packet processing logic 26, or after processing of the packet by the packet processing logic 26. Examples of various formats of a TTAG are presented hereinafter in connection with
The timestamp logic unit 23 may also be configured to insert additional information into a TTAG, including one or more bits to indicate a validity of the timestamp value, one or more bits to indicate a timing precision of the timestamp value. In general, precision is system or network domain wide and is pre-negotiated among the network devices with respect to the common time reference 30. When a new timestamp value is to be inserted into a packet, a network device uses either ingress port timestamp from the common time reference 30 (synchronized clock) or an invalid value of zero. Invalid values are preserved across the network domain, as described further hereinafter.
Since any device can serve as an edge node in a network domain, each network device includes latency measurement 24 which is configured to perform a latency computation (current time minus the timestamp value contained in a TTAG of a received packet). For example, the latency measurement unit 24 in network device 20(2) may compute the latency associated with packet 40 using the timestamp value contained in the TTAG inserted by edge network device 20(1).
The CPU 28 may perform higher level latency analysis and reporting operations based on software instructions contained in memory 29. The memory 29 may also serve for additional storage of latency measurements. The CPU 28 may send latency measurements to a local or remotely located computing device that is used by a network administrator to monitor performance of network domain 20. Moreover, the CPU 28 in any given network device may receive commands or instructions from a network management station (
Memory 29 may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible memory storage devices. The CPU is, for example, a microprocessor or microcontroller. Thus, in general, the memory 29 may comprise one or more tangible (non-transitory) computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions and when the software is executed (by the CPU 28) it is operable to perform the operations described herein.
The timestamp logic unit 23 and latency measurement unit 24 may be embodied by digital logic gates configured to perform the operations described herein, or in another form, by software stored in memory 29 and executed by CPU 28 to perform the operations described herein. In another example, the timestamp logic unit 23 and latency measurement unit 24 may be integrated or embedded with the packet processing logic 26, which itself may be embodied by one or more application specific integrated circuits (ASICs).
As shown in
Reference is now made to
There is another way to signify an invalid timestamp value in a packet without using the explicit validity bit 130. A Timestamp subfield value of zero represents an invalid timestamp. Thus, when the value contained in Timestamp subfield 130 is all zeros, a network device construes this as indicating that the timestamp contained in the TTAG is invalid. The subfield can be compatible with timestamp always valid in the network when invalid capability is disabled in the network domain. Thus, a predetermined bit pattern (e.g., all zeros) in the Timestamp subfield 130 indicates that the timestamp information of the Timestamp subfield is not valid.
Turning to
In some implementations of the techniques described herein, the number of TTAGs that can be inserted into a packet is limited in number to, for example, six (6) or some number between one (1) and ten (10). In other implementations, the number of TTAGs that can be inserted into a packet is unlimited, in which any device that receives the packet within the network for passing the packet to a destination from a source can insert a TTAG into the packet. In some implementations, when the maximum number of TTAGs that can be inserted into a packet is reached, downstream network devices cannot insert TTAGs into the packet. In yet other implementations, when the maximum number of TTAGs that can be inserted into a packet is reached, downstream network devices are allowed to over-write TTAGs on a first-in, first-out basis.
There are numerous possibilities for locating the TTAG information in the packet. The TTAG can be inserted within a Layer 2 portion of the packet. This is in contrast to conventional approaches that perform application-specific packet time measurements at Layer 3. For example, one conventional packet time measurement approach collects runtime measurement of packets based on an application-specific determination of packet arrivals at Layer 3, as opposed to incorporating timestamp tag information directly into all packets at Layer 2 as accomplished using the techniques presented herein.
In some implementations, such as for Internet Protocol Version 4 (IPv4) or IPv6 packets, the TTAG can be provided immediately after the virtual local area network (VLAN) subfield and immediately before the IPv4 or IPv6 field in the packet header portion of the packet, in which the TTAG is meshed in the protocol stack within the header portion of the packet. Other locations for insertions of the TTAG within a packet may be envisioned while remaining within the spirit and scope of the techniques presented herein.
Turning now to
At 240, the first network device sends the packet to another network device in the network domain, using the normal packet processing functions for the packet. At 250, another network device in the network domain receives the packet, and can perform any one or more of: (i) measuring latency with respect to first network device based on timestamp information in tag, (ii) overwriting tag with new tag, (iii) adding an additional tag to the packet, and (iv) adding an additional timestamp to an existing tag, or (v) doing nothing and processing the packet in the normal course without performing any of operations (i)-)(iv).
At 250, the network device sends the packet on in the network in the ordinary course of packet processing. Operations 240 and 250 are repeated at subsequent network devices in the network domain as the packet travels through the network domain.
As explained above in connection with
Thus, particular implementations of the subject matter have been described. Other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.
The above description is intended by way of example only.
This application is a continuation of U.S. application Ser. No. 13/708,347, filed Dec. 7, 2012, entitled “Timestamping Packets in a Network,” which claims priority to U.S. Provisional Patent Application No. 61/702,323, filed Sep. 18, 2012, also entitled “Timestamping Packets in a Network.” Both applications are incorporated herein by reference in their entirety.
Number | Name | Date | Kind |
---|---|---|---|
6246684 | Chapman et al. | Jun 2001 | B1 |
6690646 | Fichou et al. | Feb 2004 | B1 |
6853623 | Nederveen et al. | Feb 2005 | B2 |
6892237 | Gai et al. | May 2005 | B1 |
6990202 | Wee et al. | Jan 2006 | B2 |
7106731 | Lin et al. | Sep 2006 | B1 |
7395332 | Gai et al. | Jul 2008 | B2 |
7474666 | Kloth et al. | Jan 2009 | B2 |
7539777 | Aitken | May 2009 | B1 |
7656818 | Baroudi et al. | Feb 2010 | B1 |
7792130 | Fischer | Sep 2010 | B2 |
7830793 | Gai et al. | Nov 2010 | B2 |
7899048 | Walker et al. | Mar 2011 | B1 |
7961621 | Bergamasco et al. | Jun 2011 | B2 |
7969971 | Gai et al. | Jun 2011 | B2 |
8116307 | Thesayi et al. | Feb 2012 | B1 |
8166216 | Kondapalli | Apr 2012 | B1 |
8208389 | Alaria et al. | Jun 2012 | B2 |
8274905 | Edwards et al. | Sep 2012 | B2 |
8605588 | Sankaran et al. | Dec 2013 | B2 |
8640036 | Pignataro et al. | Jan 2014 | B2 |
8681806 | Bucknell et al. | Mar 2014 | B2 |
8718482 | Roberts | May 2014 | B1 |
20030231596 | Hong | Dec 2003 | A1 |
20040105392 | Charcranoon | Jun 2004 | A1 |
20060007939 | Elangovan | Jan 2006 | A1 |
20060062209 | Riley | Mar 2006 | A1 |
20060253900 | Paddon et al. | Nov 2006 | A1 |
20060268847 | Halbraich et al. | Nov 2006 | A1 |
20070230697 | Wu | Oct 2007 | A1 |
20080013475 | Bandou | Jan 2008 | A1 |
20080019282 | Alaria | Jan 2008 | A1 |
20080159260 | Vobbilisetty | Jul 2008 | A1 |
20080279181 | Shake | Nov 2008 | A1 |
20090034416 | Baron et al. | Feb 2009 | A1 |
20090041011 | Sheppard | Feb 2009 | A1 |
20090100040 | Sheppard et al. | Apr 2009 | A1 |
20090122805 | Epps | May 2009 | A1 |
20090171474 | Birze et al. | Jul 2009 | A1 |
20100054152 | Foschiano et al. | Mar 2010 | A1 |
20100154033 | Oulai | Jun 2010 | A1 |
20110044173 | Kakadia | Feb 2011 | A1 |
20110069626 | Sun | Mar 2011 | A1 |
20110149998 | Thompson | Jun 2011 | A1 |
20110222412 | Kompella | Sep 2011 | A1 |
20120106576 | Hadzic | May 2012 | A1 |
20120320933 | Magee | Dec 2012 | A1 |
20130036239 | Spencer | Feb 2013 | A1 |
Number | Date | Country |
---|---|---|
2008097001 | Aug 2008 | WO |
Number | Date | Country | |
---|---|---|---|
61702323 | Sep 2012 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 13708347 | Dec 2012 | US |
Child | 14701882 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 14701882 | May 2015 | US |
Child | 16400117 | US |