CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims priority to U.S. Provisional Patent Application Ser. No. 61/873,287, filed Sep. 3, 2013, the contents of which are incorporated herein by reference. 
    
    
     FIELD OF THE INVENTION 
     This invention relates generally to computer network communications. More particularly, this invention relates to evaluating timing information in computer network communications. 
     BACKGROUND OF THE INVENTION 
     Standard protocols exist in IP networks so that two or more nodes in the network are able to synchronize and/or syntonize their individual clocks. The two most widely used protocols are IEEE 1588 and NTS. Synchronization operations are typically performed on a link-by-link basis. 
     It would be desirable to provide a low cost mechanism to obtain comprehensive timing information across a network. 
     SUMMARY 
     A method includes receiving a packet at an ingress node of a network. A hierarchical time stamp is created in the packet by the ingress node. The hierarchical time stamp includes an initial time stamp and an initial node identifier. The packet is passed to another network node, which adds a subsequent time stamp and a subsequent node identifier to the hierarchical time stamp. The packet is received at an egress node of the network. A final time stamp and a final node identifier are added to the hierarchical time stamp at the egress node. The hierarchical time stamp is then removed from the packet and the packet is passed to another network. The hierarchical time stamp is delivered to an analyzer. 
     A network includes nodes to maintain end-to-end timing information between an input node and an output node of the network. Each node in the network affixes a node identifier and a time stamp to a hierarchical time stamp. The output node removes the hierarchical time stamp prior to passing the packet to another network. 
     A network node has a packet analyzer to process a static per port control bit and a dynamic per packet control bit to alternately create a hierarchical time stamp in a packet, remove the hierarchical time stamp from a packet and insert a time stamp in an existing hierarchical time stamp. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows packet time stamps accumulating as a packet flows through a network configured in accordance with an embodiment of the invention. 
         FIG. 2  shows a Hierarchical Time Stamp (HTS) format utilized in accordance with an embodiment of the invention. 
         FIG. 3  shows insertion of an HTS in a typical IP packet processed in accordance with an embodiment of the invention. 
         FIG. 4  shows HTS operations performed in accordance with an embodiment of the invention. 
         FIG. 5  shows HTS operations performed in accordance with an embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows an example of a packet  100  entering a network  102  and leaving the network  102  in the same form. Inside the network  102  timing information is attached to the packet at each node. In particular, a first node  104 , which may be a switch, router or appliance, adds a first time stamp  106 . A second node  108  adds a second time stamp  110 , while a third node  112  adds a third time stamp  114 . An exit node  116  adds a fourth time stamp  118 . The exit node  116  then strips the time stamps  106 ,  110 ,  114  and  118  to render the original packet  100 , while passing the packet  100  and time stamps  106 ,  110 ,  114  and  118  to analyzer  120 . 
     As long as all the nodes in the network can handle the reception of the timestamp information attached to the packet and insertion of the additional timestamp information into the packet, this timing information does not need to follow any of the standard IP protocols. But the non-standard information is stripped before the packet is sent out to a network built with standard equipment. That is, network  102  observes a common non-standard protocol to process the HTS. The information associated with this non-standard protocol is stripped from the packet before routing the packet outside the network  102 . 
     The timing information may have any number of formats. Characteristics associated with formats may include: type of timing information, length of time stamps, aggregate timing information and maximum amount of timing information. For example, each node could insert the time when the packet arrives (ingress TS) at the node and also the time when the packet leaves the node (egress TS), so that the latency through the links that connect the nodes can be determined. Alternatively, the node could insert just the ingress TS or the egress TS. Moreover, the TS themselves could be of different size depending on the accuracy that is needed. 
     For simplicity, the timing information across all nodes may reside in a fixed size all the time, regardless of how many time stamps have been inserted at any given time. There may be a maximum size for the overall timing information, thereby limiting the number of nodes that can insert timing information. 
       FIG. 2  shows two high-level format examples. The format is called Hierarchical Time Stamp or HTS because it contains the information of several nodes as the packet traverses the network. The formats shown in the figure assume a variable HTS payload (HTSP); therefore some control information is needed to determine how many timestamps the HTSP contains at any given time (N in the Figure). This information is part of the HTS Header (HTSH). The HTSH can be positioned anywhere in the HTS, but usually is placed at the beginning or at the end (the two cases shown in the Figure). The HTSH can contain other information, such as the size of each TS, whether there has been an error in the insertion of the TS by a particular node, etc. 
       FIG. 2  also shows how the timestamps are arranged inside the HTS payload. In this case, the last N timestamps are kept in the HTS payload, as opposed to, for example, keeping the first N timestamps seen in the network. 
     Within an IP packet, the most common place to insert the HTS is at the end of the packet (but before the Frame Check Sequence or FCS) so that the transmission of the start-of-packet is not delayed when the HTS is removed from the packet.  FIG. 3  shows this case. In particular,  FIG. 3  shows a typical IP packet  300 , which is modified to create a new packet  302 . The new packet  302  has an HTS  304  positioned before the FCS. It is important to note that the insertion of the HTS does not modify any of the original fields of the packet except for the FCS that needs to be recomputed (if the HTS has been modified) to protect the data in the HTS. 
     Each node needs to support 3 basic operations related to the HTS: (1) create the initial HTS, (2) remove the HTS and (3) insert a TS into the existing HTS.  FIG. 4  shows these operations. The node decides which operation (or none) to perform based on two bits: an HTS_exists bit provides a per-packet notification of whether the HTS exists or not, while the HTS_keep bit provides a per-egress-port configuration that indicates whether the HTS needs to be removed or not before the packet is transmitted. 
       FIG. 5  illustrates an embodiment of the invention. In this embodiment, the HTS is at the end of the packet, but before the FCS. The packet may have an ingress 64-bit time stamp. If it exists, this timestamp is present at the beginning of the packet. If the packet requires the TS be inserted in the HTS, the 48 LSB bits of the TS are concatenated with a 16-bit Node Id as shown at label  500 . The resulting 64 bits are inserted in the HTS. In this case, the timing information inserted by the nodes is a fixed size (64 bits). 
     Alternately, the HTS may be a variable size. That is, the size increases as the packet traverses nodes. The first time the HTS is generated, it will contain a single TS along with the HTSH (for a total of 16 bytes). In one embodiment, the maximum HTS size allowed is 64 bytes, so at most 7 TS can exist in the HTSP. The number of TS in the HTSP is indicated in a field in the HTSH (LastValidTS); a LastValidTS of N indicates that there are N TS in the list. A LastValidTS value of 0 indicates that there is only a single TS in the HTSP. 
     In one embodiment, the HTS always keeps the oldest time stamps. If there is not space for additional time stamps, a bit n the HTSH is set to indicate a stack overflow. The analyzer processes this information. 
       FIG. 5  illustrates an embodiment of the invention with additional control bits. The TS_exists per packet bit indicates whether the TS is present and can be used. The TS_keep per egress-port bit indicates whether the TS, if present, needs to be stripped out before transmitting the packet. 
     Once the different nodes in a network are synchronized or syntonized, it is possible to tag each packet arriving at a node with the timestamp using that node&#39;s internal clock. If this tagging is performed across all the nodes of the network, the latency of the packet across the network can be analyzed in detail by the analyzer  120 . 
     Thus, the invention provides an end-to-end chain of time stamps across a network where each node in the network is configured to process the disclosed HTS. This stands in contrast to known link-by-link time stamp processing techniques that do not provide complete timing information from an ingress port, across intervening ports and then to an egress port. The comprehensive timing information allows the analyzer  120  to perform any number of timing analyses and to enforce quality of service standards at a hardware processing level. 
     Those skilled in the art understand that prior art time stamp techniques are costly at both the hardware and software levels. The invention provides a simple protocol observed by a set of nodes. The simple protocol operates on top of existing synchronization techniques to provide a low cost mechanism for comprehensive timing information across a network of devices observing the protocol. 
     An embodiment of the present invention relates to a computer storage product with a non-transitory computer readable storage medium having computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts. Examples of computer-readable media include, but are not limited to: magnetic media, optical media, magneto-optical media and hardware devices that are specially configured to store and execute program code, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using JAVA®, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hardwired circuitry in place of, or in combination with, machine-executable software instructions. 
     The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that specific details are not required in order to practice the invention. Thus, the foregoing descriptions of specific embodiments of the invention are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed; obviously, many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, they thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the following claims and their equivalents define the scope of the invention.
A method includes receiving a packet at an ingress node of a network. A hierarchical time stamp is created in the packet by the ingress node. The hierarchical time stamp includes an initial time stamp and an initial node identifier. The packet is passed to another network node, which adds a subsequent time stamp and a subsequent node identifier to the hierarchical time stamp. The packet is received at an egress node of the network. A final time stamp and a final node identifier are added to the hierarchical time stamp at the egress node. The hierarchical time stamp is then removed from the packet and the packet is passed to another network. The hierarchical time stamp is delivered to an analyzer.