WO2002095609A1 - Systeme metrique de reseau - Google Patents

Systeme metrique de reseau Download PDF

Info

Publication number
WO2002095609A1
WO2002095609A1 PCT/US2002/016957 US0216957W WO02095609A1 WO 2002095609 A1 WO2002095609 A1 WO 2002095609A1 US 0216957 W US0216957 W US 0216957W WO 02095609 A1 WO02095609 A1 WO 02095609A1
Authority
WO
WIPO (PCT)
Prior art keywords
nodal
measurement
packets
measurements
members
Prior art date
Application number
PCT/US2002/016957
Other languages
English (en)
Inventor
Andrew Corlett
Robert Mandeville
Original Assignee
Cqos, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/864,929 external-priority patent/US20030023710A1/en
Application filed by Cqos, Inc. filed Critical Cqos, Inc.
Publication of WO2002095609A1 publication Critical patent/WO2002095609A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/024—Standardisation; Integration using relational databases for representation of network management data, e.g. managing via structured query language [SQL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0681—Configuration of triggering conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps

Definitions

  • This invention relates generally to network metric systems and, more particularly, to a system and methodology for one-way measurement of network metrics at the Internet Protocol layer to produce comparable measurements for network engineering.
  • the present invention resolves the above and other problems by providing a network metric system and methodology which provides comparable measurements over a network at the Internet Protocol (IP) layer for use in network engineering and Internet Service Provider (ISP) performance monitoring.
  • IP Internet Protocol
  • ISP Internet Service Provider
  • the network metric system of the present invention utilizes nodal members to form a nodal network between which one-way measurements are performed over asymmetrical paths.
  • the measurements are performed at the IP layer, and the number of nodal members in the nodal network is scaleable.
  • the measurements include packet ordering data for received packets that is defined using a minimal longest ascending subsequence algorithm.
  • the nodal members in the network metric system of the present invention are used as measurement points and have synchronized timing systems.
  • the nodal members support Network Time Protocol (NTP) timing synchronization and Global Positioning System (GPS) timing synchronization.
  • NTP Network Time Protocol
  • GPS Global Positioning System
  • the one-way measurements are performed by the nodal members at the IP layer and provide cross-application and cross- platform comparable measurements.
  • the system utilizes a vector based measurement system to achieve service-based, comparable measurements.
  • the vector based measurement system defines a vector by an IP source, an IP destination, and a service type.
  • the nodal members include multiple on-board processors, enabling one processor to handle management processes and another processor to handle measurement processes.
  • the nodal members of the network metric system perform processing of the measurement data.
  • the nodal members implement a processing algorithm on raw measurement data recorded for each measurement period. This processing algorithm compacts the raw measurement data.
  • the nodal members of the network metric system are autonomous devices that are capable of generating measurement packets, performing one-way measurements at the IP layer, processing measurement data, and temporarily storing measurement data, despite a service daemon or database outage.
  • the nodal members are functional without requiring a TCP session with the service daemon.
  • Another preferred embodiment of the present invention is directed towards a measurement method for performing measurements over a network.
  • the method includes: performing one-way measurements between nodal members over asymmetrical paths, wherein the measurements are performed at the IP layer in a scalable environment; processing data produced by the one-way measurements between nodal members; transmitting the pre- processed measurement data from the nodal members to a database; and analyzing the pre- processed measurement data.
  • the measurements include packet ordering data for received packets that is defined using a minimal longest ascending subsequence algorithm. More particularly, the method of performing one-way measurements between nodal members is achieved by transmitting measurement packets with CQOS headers between nodal members. Preferably, the method of processing the measurement data produced by the one-way measurements between nodal members also compacts the measurement data.
  • the system includes a nodal network, a database, an application server, a workstation, and at least one service daemon interfacing with nodal network, and the database.
  • the nodal network includes multiple nodal members between which one-way measurements are performed over asymmetrical paths.
  • the measurements are performed at the IP layer, and the number of nodal members used as measurement points in the nodal network is scaleable.
  • the database stores measurement data processed by the nodal members.
  • the workstation provides a user interface for system configuration, including sending vector configuration information to the database, as well as reporting of the measurement data.
  • the user interface of the workstation is alterable without modifying the underlying system architecture.
  • the system is capable of performing measurements and storing measurement data without dependence upon the user interface.
  • the network metric system implements an access protocol that is selectively configurable to allow third party applications to access the system.
  • the network metric system implements a CQOS protocol, which is a non-processor intensive, non-bandwidth intensive protocol for transmitting pre-processed, compacted measurement data.
  • measurement data from each measurement period is sent from the nodal members to the database via this CQOS protocol.
  • the nodal members also communicate with each other and obtain results data using CQOS protocol.
  • configuration data and status data are also sent via CQOS protocol.
  • the database of the network metric system is SQL compliant.
  • the database stores vector configuration information and results of the measurement data to allow generation of true averages in response to user defined parameters.
  • the network metric system provides user-definable groupings of vectors for facilitating vector display and reporting.
  • the nodal members in the nodal network are capable of user-defined customizable groupings for area-specific measurement reporting.
  • the nodal members of the network metric system implement hardware time stamping. Hardware time stamp is more accurate than software time stamping. This system architecture configuration offloads the processor-intensive activity of time stamping and frees up processing power.
  • Each nodal member includes an output buffer, and during the hardware time stamping, header information and data information preferably fill the output buffer before a time stamp is applied to the output buffer.
  • the nodal members of the network metric system generate and transmit measurement packets in order to perform one-way measurements at the IP layer.
  • the measurement packets have a format that preferably includes an Ethernet header, IP header, optional IP routing options, UDP/TCP header, payload, and CQOS header.
  • checksums are calculated on the measurement packets for payload, IP header, UDP/TCP header, and CQOS header.
  • the network metric system facilitates user-definable bandwidth allocation for measurement traffic.
  • each nodal member automatically calculates the rate at which measurement packets are generated, based upon the number of vectors, packet size, and the bandwidth allocation.
  • the network metric system performs accurate measurements at a high sampling rate.
  • Still another preferred method of the present invention is directed towards a measurement method that includes: performing one-way measurements between nodal members over asymmetrical paths, wherein the measurements are performed at the IP layer in a scalable environment; processing data in the nodal members produced by the one-way measurements between nodal members; transmitting the pre-processed measurement data from the nodal members to a database via at least one service daemon that interfaces with the nodal network and the database, wherein the at least one service daemon instructs the nodal members to create vectors, obtains vector configuration information from the database, and processes results data transmitted from the nodal members to the database; and providing for system management capabilities and measurement data analysis via the workstation.
  • the measurements include packet ordering data for received packets that is defined using a minimal longest ascending subsequence algorithm.
  • Yet another preferred embodiment of the present invention is directed towards a measurement system for performing measurements over a network that also performs a readiness test.
  • the system includes a nodal network, a measurement database, a user interface workstation, an application server, and a service daemon.
  • the nodal network includes multiple nodal members between which one-way measurements are performed at the IP layer.
  • the workstation provides a user interface for system configuration, including sending vector configuration information to the database, as well as reporting of measurement data.
  • the application server interfaces between the database and the workstation for system configuration and results display (obtaining the results data from database and preparing the data for display).
  • the service daemon interfaces with the nodal network and the database.
  • a transmitting nodal member performs a readiness test to ensures the willingness of a receiving nodal member to accept measurement traffic before the transmitting nodal member begins to transmit measurement traffic to the receiving nodal member.
  • the measurements include packet ordering data for received packets that is defined using a minimal longest ascending subsequence algorithm.
  • the readiness test of the network metric system preferably includes: broadcasting an Address Resolution Protocol request to a gateway/local host in order to obtain its physical hardware address; pinging the gateway/local host; pinging the receiving nodal member; performing a traceroute to the receiving nodal member; and performing a Go/No Go test using a CQOS protocol which is a non-processor intensive, non-bandwidth intensive protocol for nodal members to communicate with each other.
  • the Go/No Go test of the network metric system is performed by a transmitting nodal member requesting and obtaining permission from a receiving device to transmit measurement traffic before the transmitting nodal member transmits the measurement traffic. This ensures protection against unwanted measurements being made on nodal members, as well as against measurement traffic being sent to a non-nodal member receiving device.
  • the readiness test verifies linkage and reachability of nodal members before measurements are performed without burdening the network with unnecessary duplication of effort.
  • FIG. 1 illustrates a perspective view of the system architecture of the network metric system, in accordance with the present invention
  • FIG. 2 illustrates a block diagram of one embodiment of a nodal member used in the network metric system of the present invention
  • FIG. 3 illustrates an block diagram of another embodiment of a nodal member used in the network metric system of the present invention
  • FIG. 4 illustrates a perspective view of a sample report of the network metric system of the present invention.
  • FIG. 5 illustrates a perspective view of an alarm screen of the network metric system of the present invention.
  • a preferred embodiment network metric system and methodology, constructed in accordance with the present invention provides comparable measurements over a network at the Internet Protocol (IP) layer for use in network engineering and Internet Service Provider (ISP) performance monitoring.
  • IP Internet Protocol
  • ISP Internet Service Provider
  • the network metric system is capable of measuring one-way Internet metrics in a scalable network environment to produce accurate, comparable measurements.
  • the database 40 stores measurement data that is generated by the nodal members 30.
  • the workstation 50 is connected to the database 40 via the application server 46, and provides a user interface for system configuration, including sending vector configuration information to the database.
  • the workstation 50 also provides a user interface for reporting of the measurement data.
  • the application server 46 interfaces between the database 40 and the workstation 50 for system configuration and results display. Results display includes obtaining the results data from database 40 and preparing the data for display.
  • One or more service daemons 60 interface between the nodal network 20 the database 40.
  • measurements are accomplished by transmitting CQOS measurement packets from one nodal member 30 to another nodal member 30.
  • This measurement is made of a one way trip, which is a major improvement over traditional methods (using ping or similar techniques) that measure round trip times.
  • GPS Global Positioning System
  • NTP network time protocol
  • results are calculated based upon a 5 minute measurement period and are transmitted from the receiving nodal member 30 to the database 40 for later analysis.
  • a vector is used to describe a measurement case.
  • Each vector has a start point and an end point.
  • the start point is the nodal member 30 that is transmitting CQOS measurement packets to the receiving nodal member 30, the later of which is the end point.
  • transmitter and receiver are considered equivalent to start point and end point nodal members, respectively.
  • a vector is the fundamental definition of the path and measurement traffic between two nodal members 30 for the calculation of measurements at the IP layer.
  • a vector describes the path and measurement traffic type between two nodal members 30. It is uniquely defined by a measurement packet between specific IP source and destination addresses.
  • a vector is defined by an IP source, an IP destination address, and a service type (differentiated service bits), with user- definable TCP/UDP ports, payload (zeros, ones, or random), and packet size.
  • This fundamental IP layer metric allows for service-based, comparable measurements that translate cross-application and cross-platform.
  • Each vector has an associated set of characteristics. These characteristics include items such as packet size, payload type, header type (none/UDP/TCP), udp/tcp source and destination port numbers, TOS/Dif ⁇ Sev bits, TTL value, IP protocol value, IP options, default gateway, source and destination addresses, and TCP header information. Further, a certain set of characteristics can be assigned a name such as 'high priority' or 'best effort'. This makes it easy to reuse a particular set of characteristics. In a preferred embodiment of the network metric system 10, all measurements are made on the end point nodal member 30. The nodal member 30 is called the vector handler.
  • the transmitter It is the responsibility of the transmitter to send out measurement packets to the receiver. It is also the responsibility of the transmitter to send out an ending packet at the end of each measurement period. This ending packet signals the receiver that all packets in the measurement period have been transmitted. Once the receiver acquires the ending packet at the end of the measurement period, the receiver becomes responsible for gathering the data of all packets received from the transmitter, calculating the results based on the data contained in the packets, and finally sending the results to the database 40 for storage.
  • the CQOS service daemon 60 is the foundation of the scalable and reliable application server architecture.
  • the service daemon 60 interfaces with the nodal members 30 and the database 40, instructs the nodal members to create new vectors, obtains vector configuration information from the database 40, and handles results data transmitted from the nodal members 30 to the database 40. Initially, vector configuration information is sent from the workstation 50 through the application server 46 to the database 40.
  • multiple service daemons 60 are run simultaneously to provide for system redundancy.
  • the system 10 employs a Solaris based operating system, instead of Windows NT. If a service daemon 60 experiences a failure, the nodal members 30 continue to measure and store their results until a replacement daemon is activated.
  • the service daemon 60 allows the network metric system 10 to be self-sustaining, with measurements performed, and results stored, without dependence upon the user interface. Further, the service daemon 60 allows the user interface to be changed or otherwise updated without affecting the underlying system architecture. Moreover, the service daemon 60 preferably allows the flexibility to potentially let third-party applications access the measurement system 10, as desired.
  • the one-way measurements are performed by the nodal numbers 30 and provide cross- application and cross-platform comparable measurements.
  • the system utilizes a vector-based measurement system 10 to achieve service-based, comparable measurements between the nodal numbers 30.
  • the vector-based measurement system 10 defines a vector using an IP source, an IP destination, and a service type.
  • a nodal member 30 can be configured to be the start point or end point of many vectors simultaneously. Note that the packet sent out at the end of each measurement period is not sent for each vector, but rather it is sent on a per nodal member 30 basis. For example, if one nodal member 30 is the transmitter of two vectors to the same receiving nodal member, the transmitting nodal member only sends one packet at the end of the measurement period, not two.
  • the nodal members 30 in the network metric system 10 of the present invention perform measurements and store measurement data over a set measurement period. As described above, the results are preferably calculated based on a 5 minute measurement period. However, any desired measurement period may be used in other embodiments of the present invention.
  • the results data for each measurement period is sent from each nodal member 30 to the database 40 utilizing the CQOS protocol for later analysis.
  • the CQOS Protocol is a communications protocol that is used for communication between nodal members 30 and the other elements of the network metric system 10.
  • the results for each measurement period are sent from each nodal member 30 to the service daemon(s) 60 and then onwards to the database 40 utilizing the CQOS protocol.
  • configuration data and status data are also sent via CQOS protocol.
  • the CQOS protocol is an efficient, secure, non-processor intensive, non-bandwidth intensive transfer protocol. Use of the CQOS protocol allows processor and bandwidth intensive protocols such as Simple Network Management Protocol (SNMP) to be avoided.
  • SNMP Simple Network Management Protocol
  • the CQOS protocol is also used for communication between nodal members 30. Moreover, the CQOS protocol can be expanded and modified, as needed, throughout the development life cycle of the product.
  • the network metric system 10 of the present invention measures and reports a complete set of Internet metrics that are useful to network engineers for proper network design and configuration.
  • the completeness of these Internet metrics provides significant advantages over prior measurement gathering systems.
  • the Internet metrics in accordance with the present invention, preferably include, by way of example only, and not by way of limitation, code version number, source identities, time parameters, sequence/byte/packet loss, out-of-order packets, error packets' types, sequential packet loss (loss patterns), packet hop count, IP protocol tracking, packet TOS and DiffServ changes, packet jitter, one-way latency, outages, and route information.
  • many of these Internet metrics can be subdivided and described in further detail.
  • the code version number provides the version number of software operating in the nodal members 30, which is important when updates are made or are being planned.
  • the sending nodal member ID should be recorded as well as the sending vector ID.
  • all nodal members 30 have a hard-coded identity and can be named.
  • a default identifier of all vectors is automatically created.
  • specific metrics include measurement period ID, nodal measurement period ID, and universal time.
  • the measurement period ID is defined as continuous time divided into periods identified by measurement ID.
  • the nodal member measurement period ID relates to the measurement period of the nodal member that is transmitting packets.
  • the universal time metric provides an absolute time reference for all measurements.
  • sequences received metric when packets are sent to multiple nodal members 30, each nodal member receives a sequence of packets in turn. The number of sequences received is counted separately from the number of bytes and packets received. In order to measure sequential packet loss (the number of packets dropped in a row), it is necessary to be able to identify the sequence in which the packet was sent. This should be indicated per measurement period. Packet loss is calculated as the number of packets transmitted minus the number of packets received. Packet loss does not take account of duplicate packets.
  • the bytes received metric refers to the number of bytes received per measurement period.
  • Bytes transmitted is defined as the number of bytes transmitted per each measurement period.
  • Packets received is defined as the number of packets received per measurement period.
  • packets transmitted is defined as the number of packets transmitted per measurement period.
  • the out-of-order packets metrics category includes a measurement for packets out of order and groups out of order. Referring to the packets out of order measurement, nodal members 30 implement the sophisticated algorithm described below (in the Minimal Longest Ascending Subsequence section) to calculate the number of packets that arrive out of order. Since such packets may be grouped together, the system also applies the algorithm to groups of out-of-order packets to produce the group's out-of-order measurement.
  • Error packet types are a large category of Internet metrics. These include packets duplicated, minimum packets duplicated, maximum packets duplicated, packets dropped, packets dropped due to missing fragment, packets fragmented, minimum packets fragmented, maximum packets fragmented, average packets fragmented, IP packets corrupted, CQOS info packets corrupted, pay load packets corrupted, and optional header packets corrupted.
  • the packets duplicated metric is produced by identifying duplicated packets and accounting for duplicated packets in the calculation of packet loss.
  • the packets dropped metric identifies the packets transmitted and the number of which were dropped. This calculation takes account of duplicated packets.
  • the packets dropped due to the missing fragment metric accounts for packets that were received but counted as drop packets due to missing fragments.
  • the packets fragmented metric is defined as the number of packets received that were fragmented.
  • the nodal members 30 identify corruption in the IP header.
  • the nodal member 30 identifies corruption in the CQOS information field.
  • the payload packets corrupted metric the nodal member 30 identifies corruption in the payload.
  • the nodal member 30 identifies corruption in the optional header.
  • the sequential packet loss (loss patterns) category also preferably includes numerous sub-categories of desirable metrics. These include minimum sequential packets dropped, maximum sequential packets dropped, average sequential packets dropped, standard deviation of sequential packets dropped, minimum sequential packets lost, maximum sequential packets lost, average sequential packets lost, and standard deviation of sequential packets lost. All of these sequential packet loss pattern metrics are calculated using the number of packets dropped in immediate succession to each other. These calculations are performed for both lost and duplicated packets.
  • the packet hop count category of metrics preferably includes the sub-categories of packets TTL changes, packets TTL minimum, packets TTL maximum, and packets TTL average.
  • TTL-based metrics For each of these packets TTL-based metrics, the measurements are calculated by using the hop count derived from the changes in the time-to-live field in the IP header of the packet.
  • TTL time to live is a function that limits the life of a packet to a designated number of hops between nodal members 30.
  • the time-to-live function is useful in identifying the length of a path taken by a packet between two nodal members 30, and is particularly useful with respect to packets that move along asymmetrical paths.
  • the Internet metrics being recorded also include packet IP protocol errors and packet IP protocol changes within the category of IP protocol tracking.
  • Further Internet metrics being tracked include the category of packet type of service (TOS) and differentiated services (DiffServ) changes.
  • Subcategories of metrics within the packet TOS and DiffServ changes category include the packets TOS changes metric, in which the nodal members 30 record differences in the TOS field, as well as the packets first ten TOS count metric.
  • Still another Internet metrics category is packet jitter. Further metrics within this category include jitter minimum, jitter maximum, jitter average, jitter standard deviation, and jitter standard deviation power 4.
  • the jitter standard deviation power 4 metric allows calculation of statistical accuracy from which minimum, maximum, and standard deviation for j itter are reported.
  • One-way latency is another general category of metrics under which several specific Internet metrics are preferably tracked. These include latency minimum, latency maximum, latency average, latency standard deviation, latency standard deviation power, and latency time stamp mismatch.
  • the latency standard deviation power metric is used to allow calculation of statistical accuracy, from which the minimum, maximum, and standard deviation for jitter are reported.
  • Another Internet metric 's category of outages in the network metric system 10 of the present invention includes the subcategories of outages, outage duration, minimum outages, outage duration maximum outages, and outage duration total outages. These subcategories of outage metrics are calculated by using a certain period measured in nanoseconds after which an outage counter is started if no packets are received. The outage counter is stopped when the first new packet is received.
  • the final category of Internet metrics that is tracked by a preferred embodiment of the network metric system 10 is that of route information.
  • the system records first and last packet information for all packets of a measurement period that have IP options set for record route, strict route, or loose routes.
  • the record route function records the actual path taken by a packet between two nodal members 30.
  • the strict route function forces a packet to take a specific path of travel between two nodal members 30.
  • the loose route function allows the packet to take any path as it is routed between nodal members 30.
  • the specific sub- categories of Internet metrics recorded within the route information category include first route type, first route count, first route packet ID, first route data, last route type, last route count, last route packet ID, and last route data.
  • the VectorHandler class is used to encapsulate all received packets and result calculations for a single measurement period. It inherits from the AtomicAlgorithms that contains all of the result calculation routines except for one, the CalculateResults routine.
  • This method is called two minutes after the measurement period is over and the ending packet, indicating that all packets have been sent, arrives from the transmitter.
  • This method retrieves the packets for a given measurement period. It then retrieves the non-unique 0 based period ID from the first packet with a non-corrupted CQOS header. After allocating the required memory to calculate the results, it calls additional methods to do most of the calculations (specifically the methods listed in the AtomicAlgorithms section). This method then gathers the version information, temperature information, vector identification information, additional vector information, route information, and port counters and places them in the results structure. Finally, it calls a method to place the results into the hash tables for temporary storage before transmitting them out to the database on another computer.
  • Inputs nodal memberMPeriodID - unique period ID on which the measurement period calculates results. Outputs: None Returns: TRUE if results were calculated, FALSE if results could not be calculated.
  • This class contains all of the methods that are used by VectorHandler, which inherits this class, to calculate results from the AtomicPacketData linked lists for a measurement period.
  • This method loops through all of the AtomicPacketData packets and places all packets with non-co ⁇ upted CQOS headers in the rlnfb array. During this process, the method saves any information in the results struct that can be obtained from the packets even if certain headers are corrupted or duplicates occur.
  • the main results it calculates are bytes received, packets received, fragmentation, TTL, IP protocol, TOS, latency, and header error results.
  • CQOS headers rCount - mftvrrnnm number of items rlnfo array can hold
  • This method allocates memory for duplicated packets and sorting arrays. It then loops through all of the packets placed by mc_P occssFirstPass into the rlnfo array and places all duplicates found into the duplicated packets array. Next, the method sorts the items in the rlnfb array which are not duplicates into transmission order. Based on the sorted order it calculates jitter by looping through the packets in order transmitted. Outage results are then computed by looping through the packets in the order received and comparing the times received with the min outage value ignoring duplicates. Duplicate results are then calculated by looping through the items previously placed in the duplicate list. Finally, all values previously calculated are placed in the results structure.
  • results - saves appropriate results calculated in this method rlnfo - array with all packets with non-corrupted CQOS headers with duplicate information added by this method
  • This method loops through an array of rlnfo items to find the number of items, and groups of items that are out of order. It places those results in the rxGroupsOutOfOrder and rxPacketsOutOfOrder result fields.
  • FALSE if an error occurs, TRUE if successful mc IsDuplicatedAbove Method This method used by mc_ProcessSecondPass to loop through duplicates that are before the current item. If a duplicate is found before the item then TRUE is returned. Otherwise FALSE is returned.
  • This method is used by mc_ProcessThirdPass to find groups at the beginning of the array and return the new first index of the array. It also updates the current minimum value.
  • This method is used by mc_ProcessThirdPass to find groups at the end of the array and return the new last index of the array. It also updates the current maximum value.
  • the measurement packets utilize a specific, efficient packet format.
  • This packet format includes all of the pertinent information required for the methodology of the network metric system 10 of the present invention.
  • the packet format is configured as: Ethernet header, IP header, optional IP options (strict, loose, or record route), TCP UDP header, payload, and CQOS data.
  • check sums are calculated for payload, IP header, TCP/UDP header, and CQOS header.
  • CQOS measurement packet consists of an Ethernet Header and checksum, an IP header, the payload, and a CQOS header. These items are briefly described in the sections that follow except for TCP/UDP headers. TCP/UDP headers are not discussed because measurement of TCP UDP packets to application ports is not measured.
  • Ethernet Header (14 bytes)
  • IP Header (20 - 80 bytes)
  • the Ethernet protocol is the protocol actually used to physically transport packets to and from the nodal members 30, and to and from the router connected to the nodal members.
  • the format of an Ethernet packet is shown below.
  • Ethernet destination address (first 32 bits)
  • Ethernet dest last 16 bits
  • lEthernet source first 16 bits
  • Ethernet source address last 32 bits
  • the Ethernet destination address is a 48 bit unique identifier of the Ethernet controller to receive the packet.
  • the Ethernet source address is a 48 bit unique identifier of the Ethernet controller transmitting the packet.
  • the payload is the portion where TCP/UDP, IP and CQOS header information resides. It also is the portion where any other data sent is contained.
  • the maximum size of the payload section is 12000 bits which defines the maximum size of data that can be sent per packet.
  • the Ethernet checksum is a 32-bit value that is used to validate the contents of the entire Ethernet packet.
  • IP protocol is used to transport packets across the Internet regardless of the actual connection protocols between routers. This protocol lies at the heart of the Internet and its header fields contain information that is saved in the results. Bits
  • the version field contains the current version of IP (normally 4).
  • the IHL field contains the length of the header in 32 bit words. This is normally 5 except when an IP optional header is used in which case it can be up to 15. (Verify IP optional header size.).
  • the Type of Service (TOS) field contains priority information that may or may not be used by routers to give packets higher or lower priority.
  • the Total Length field specifies the total length of the packet (excluding the Ethernet header and checksum) in bytes.
  • the Identification field is used to identify the packet.
  • the Flags field (3 bits) is used in fragmentation. The first bit, if set, signifies that routers should not fragment the packet. If a router must fragment a packet and the first bit is set, the router will drop the packet. The last bit, if set, signifies that there are more packets after this packet that were originally part of one packet but were fragmented into smaller ones.
  • the Fragment Offset (13 bits) is the offset from the previous beginning of the original packet if it is fragmented into smaller pieces. It is in units of 8 bytes.
  • the Time to Live (TTL) field indicates the max number of hops that this packet can take before reaching the receiver or the packet is dropped.
  • the CQOS header is contained at the end of the Ethernet payload. This header contains original values of data that can be changed during transmission of a packet. It is located by subtracting the size of the CQOS header (88 bytes) from the end of the payload section. If the packet is corrupted, CQOS header can also be found because the first field is 64-bit ASCII field that contains CQOS.
  • the Taglnfo field contains the identifier of the beginning of the CQOS which consists of the ASCII CQOS value and is used to find the header if the parts of the packet are corrupted.
  • the Version field contains the version of the protocol -1.
  • the TOS field contains the original TOS set on the transmitting nodal member 30.
  • the TTL field contains the original TTL set on the transmitting nodal member 30.
  • the IP protocol field contains the original IP protocol set on the transmitting nodal member 30.
  • the P Checksum (Payload Checksum) field contains a checksum for the entire payload.
  • the H Checksum (Header Checksum) field contains a checksum for the CQOS header.
  • the nodal member ID field contains the unique ID of the transmitting nodal member 30.
  • the nodal member Period ID field contains the unique ID of the period for the nodal member 30.
  • the Vector ID contains the ID of the vector.
  • the Period ID contains the 0 based ID of the measurement period.
  • the Burst ID contains the identifier of the burst that this packet is in.
  • the Packet ID contains the identifier of this packet (sequence number).
  • the Tx Timestamp contains the timestamp of the packet when it was transmitted.
  • the Not TX Timestamp field contains the inverse of the Tx Timestamp field so that the field can be verified even if other parts of the header is corrupted.
  • the nodal members 30 contain on-board intelligence, multiple on-board processors, 64-bit counters, full Internet-working functionality, Ethernet ports, a rack-mountable configuration, dual modes of type synchronization, and intelligent upgrading.
  • each nodal member 30 has two 10/100 MBPS Ethernet ports.
  • one port is used for measurement traffic and in-band management traffic.
  • the second port may optionally be used for out-of-band management. This configuration provides the benefit of allowing management traffic to be run on a separate management network.
  • the nodal members 30 are designed with feature expansion in mind, and with room for additional measurement network interfaces.
  • the nodal members 30 are rack-mountable devices that include two U-boxes with front panel LEDs, an IrDA port, and a serial port.
  • a command line interface is also accessible through either the serial port, IrDA port, or Telnet.
  • This rack-mountable configuration provides desirable space efficiency.
  • the IrDA port eliminates the requirement for a serial cable for basic configuration and diagnostics. This also allows CE devices and palm pilot devices to be used for configuration.
  • Component 1 There are two main components that comprise the nodal members 30, Component 1
  • Component 1 contains the time stamping hardware, an Ethernet controller, and a microprocessor. It connects to the auxiliary serial port at the back of the box, the GPS connector, the PPS signal, the Ethernet Measurement port, and Component 2. Component 1 's main responsibility is to transmit and receive packets. When transmitting or receiving packets, Component 1 places a very accurate time stamp in the packet (as described below). Packets received are sent to Component 2 for further processing.
  • Component 2 contains an Ethernet controller and a microprocessor. It connects to the serial port at the front of the box, the PPS signal, the IRDA interface, the Ethernet Auxiliary port, and Component 1. Component 2's responsibility is to keep track and store vectors and their respective packets, calculate results at the end of measurement periods, and handle any high level protocols. The results previously mentioned are calculated on Component 2, except for the layer 2 calculations. All the classes and methods described below are contained in Component 2. Time Stamping
  • the nodal members implement hardware time stamping.
  • Hardware time stamp is more accurate than software time stamping.
  • the hardware time stamping offloads the processor-intensive activity of time stamping to free up processing power.
  • the time stamp is applied to the output buffer after the header information and data information fill the output buffer, so as to more closely represent the time at which the measurement packet is actually transmitted.
  • the time stamp is generated very close to the actual transmit time, such that any remaining delay between the time request and the application of the time stamp, or the transmission of the packet, is discernable with substantial accuracy to permit advancing the time stamp to actual transmission time.
  • the latency time as measured by receiving input to the receive nodal member 30, is substantially devoid of inaccuracy due to processing times and processing variations in the transmitting nodal member 30.
  • the time stamp is generated a short period before it is applied to the packet and the packet is output, the delay between generation of the time stamp and application or packet output, is predictable with substantial accuracy. Unlike conventional systems, the time stamp is not generated before the output buffer begins to fill, and therefore, is not subject to processing delays and irregularities that precede filling the output buffer. Consequently, the time stamp generated can be advanced by a predictable time increment such that the time stamp actually correlates to the time at which the time stamp is applied to the packet, or when the packet is output to the ISP transmission path. This allows application of a time stamp that is initiated at the time at which the packet is formed, or transmitted, not an earlier time.
  • the receiving nodal member 30 similarly generates a time stamp as the packet fills the input buffer, rather than after the packet is further processed.
  • the receive time stamp is offsetable by a predictable time delay to correlate to the time at which the packet is actually received at the receiving nodal member 30.
  • One-way signal latency may, therefore, be accurately determined with a minimum of corruption due to variable internal processing within the sending and receiving nodal members 30.
  • each nodal member 30 includes sufficient onboard intelligence to perform processing of the measurement data for each measurement period. This is achieved by implementing a complex algorithm (described in detail below) and compacting the results, preferably to one kilobyte per five minute measurement period per vector.
  • This distribution of intelligence to each nodal member 30 allows the system to eliminate centralized processing of the raw data. Further, this onboard intelligence and processing ability of the nodal members 30 minimizes the results traffic on the network, thus, increasing scalability as a result of this distributed processing.
  • this system architecture eliminates the problem of single-point failure.
  • Each nodal member 30 stores up to 48 hours of vector information in a circular buffer. If the receiving nodal member 30 does not receive a packet signaling the end of a vectors measurement period within that period, the vector information for that period is considered invalid and is discarded.
  • a preferred embodiment nodal member 30 of the network metric system utilized multiple on-board processors. This allows one processor to handle management processes, while another processor handles measurement processes. This configuration also has the benefit of increasing scalability of the system. Further, the nodal members 30 in one preferred embodiment of the present invention utilize counters with exclusively 64-bit values. This allows wrapping of the counters to be avoided.
  • the nodal members 30 are true Internet working devices, which are capable of supporting TCP/IP, SNMP, Telnet, TFTP, dhcp, BootP, RARP, DNS Resolver, Trace Route, and PING.
  • the nodal members 30 are high-quality devices that service providers can confidently deploy and manage within their own systems.
  • the nodal members 30 in the network metric system 10 of the present invention have synchronized timing systems.
  • the nodal members 30 preferably support network time protocol (NTP), Version 3.
  • NTP network time protocol
  • a prefe ⁇ ed embodiment of the present invention supports synchronization to multiple NTP servers. This synchronization is used in the calculation of one-way latency and jitter measurements. The one-way latency measurements provide insight into the asymmetric behavior of networks, and adds a dimension of understanding of the performance of real-time applications (voice and multimedia).
  • a prefe ⁇ ed embodiment of the present invention also supports global positioning system (GPS) time synchronization, however, the system 10 avoids dependence solely on GPS which can sometimes be difficult to support.
  • GPS global positioning system
  • nodal members 30 of the present invention are preferably capable of intelligent upgrading.
  • the upgrading of the nodal members 30 is automated, and as such, facilitates extreme scalability up to very large numbers of deployed nodal members 30, while maintaining minimal loss of measurement time. This ability greatly enhances ease of upgrading large deployments.
  • new images are booted on all nodal members 30 in a synchronized fashion.
  • the system implements several redundant features in order to account for any occasional failures or e ⁇ ors in the system.
  • the nodal members 30 are equipped with a substantial amount of memory storage capacity (typically as RAM) and store results data for a period of time after the results have been sent to the database 40. If a results packet is lost in the transmission, the service daemon 60 senses this loss and implements the necessary procedures to retrieve the results.
  • This type of automated e ⁇ or recovery allows for the network metric system 10 of the present invention to act as a carrier class, long-term, unattended system deployment.
  • each nodal member 30 employs dual power supplies in order to provide for a backup power source in the case of a power supply failure. Moreover, in accordance with the autonomous nature of the nodal numbers, if a transmitting nodal member 30 is restarted for any reason, the nodal member 30 automatically goes through a Readiness Test and a Go/No-Go Test (described below), followed by the automatic resumption of measurements without any required user intervention.
  • each transmitting nodal member 30 insures the readiness of a receiving nodal member 30 before the transmitting nodal member 30 begins to send measurement traffic to another receiving nodal member 30 by performing a Readiness Test.
  • This Readiness Test verifies linkage and reachability between nodal members 30 before a test is run, without overburdening the network with unnecessary duplication of effort.
  • network metric system 10 a transmitting nodal member 30 performs a five-step Readiness Test upon creation of a new vector by the service daemon 60, or after a restart or other anomaly.
  • the Go/No-Go Test provides protection from unwanted or unauthorized measurements being made on nodal members 30 within the system, as well as providing protection from having nodal member 30 measurement traffic accidentally sent to a non-nodal member device.
  • the network metric system 10 preferably also employs password protection in order to limit access as desired (e.g., access to management applications).
  • a prefe ⁇ ed embodiment to the present invention also provides users with the ability to define multiple service types prepare of nodal members 30. For example, a user is able to specify TCP/UDP Port, DiffServ (differentiated services) field bit values, payload (zeros, ones, and random), and packet length for each user-defined service type. This type of quality of service specific behavioral information is then readily available in the system reports. Further, the work stations and prefe ⁇ ed embodiments of the present invention also allow vectors to be disabled without being deleted from the database 40. This provides the advantage of saving a user from having to redefine a previously defined vector. Certain networks support different priority levels for the routing of network traffic.
  • a router supports two policies, 'high priority' and 'best effort', with the default being best effort.
  • the router knows by a packet's TOS field settings if the packet is a default best effort packet or a high priority packet.
  • the router then schedules the packets transmitted based on the policy. For example, the router reserves 25% of the sending bandwidth for high priority packets and the rest of the transmitting bandwidth for best effort packets. Because TOS fields and other parameters that affect QOS can be modified it is possible to measure the different QOS policies and their effects.
  • packets are sent one at a time in a round robin fashion.
  • a minimum of 2 packets from a single vector must be transmitted in order with no other packets in between.
  • the number of packets that are transmitted one after another in a vector is called the measurement sequence. This is also known as a burst.
  • a measurement sequence size of one is equivalent to the normal round robin transmission scheme. This can be used if the jitter calculations are not desired.
  • This embodiment of the present invention utilizes a round-robin measurement sequence. When multiple vectors are defined per nodal member 30, the measurement packets are transmitted in complete blocks, rather than interspersed with packets for other vectors. This guarantees accurate jitter measurements in the presence of multiple vectors.
  • the network metric system 10 of the present invention Another advantageous feature of the network metric system 10 of the present invention is its ability to provide user-definable measurement bandwidth allocation. This allows service providers that do not have a large amount of bandwidth available for measurement traffic to still be able to utilize the network metric system 10 of the present invention.
  • the vector rates are automatically adjusted in order to utilize only a predetermined amount of bandwidth. Once the user decides upon the amount of bandwidth to be allocated for measurement traffic, each nodal member 30 in the network metric system automatically calculates the rate at which measurement packets are generated based on the number of vectors, packet size, and the bandwidth allocated.
  • Test bandwidth is the rate at which packets for a vector are transmitted. Transmitted packets are not sent out all at once at the beginning of the measurement period. Instead packets are transmitted out, based on measurement sequence, evenly spaced throughout the measurement period.
  • the maximum test bandwidth depends on certain factors: Maximum bandwidth of the network; the number of vectors at work on the nodal member 30; the number of packets per measurement period per vector; the packet size per vector; the measurement period.
  • the number of packets transmitted in a measurement period is definable per vector.
  • the minimum number of packets is one.
  • the maximum number of packets transmitted per vector is dependant upon: the test bandwidth; the number of vectors at work on the nodal member 30; the number of packets per measurement period per vector; the packet size per vector; the measurement period.
  • network metric system 10 of the present invention provides accurate network performance measurements on a large scale in commercial, production environments without significantly degrading network performance.
  • Many prior art systems have utilized a "passive" approach to measurements, in which existing network data packets are sampled and examined.
  • One drawback to this passive approach is that if there are no packets traveling in the network, no measurements can occur.
  • the network metric system 10 of the present invention uses an "active" approach that creates proprietary CQOS data packets that are used for measurement purposes. Therefore, the privacy of non-measurement data packets is not compromised since only CQOS data packets are examined.
  • Packet size is dependent upon the size of the Ethernet header, Ethernet CRC value, IP header, optional IP header, CQOS header and payload.
  • the Ethernet header, Ethernet CRC value, IP header, and CQOS header are always the same size and this is the minimum size of a measurement packet.
  • the maximum packet size is currently defined as the maximum size of an Ethernet packet. This size is currently equal to 1500 bytes total including the header. This size was chosen in order to try and eliminate further packet fragmentation by routers. This may be changed in the future.
  • the size of the payload can be changed and is what determines the size of the packet.
  • the minimum size of the payload is 0.
  • the maximum size of the payload is:
  • the contents of the payload can be specified as being filled with random numbers, all 0's, or all 1 's.
  • the random numbers for each packet are truly randomized and are not generated once for all packets transmitted.
  • HDEFAULTS are the default values given for vector characteristics. Packet information HDEFAULTS are automatically chosen to populate the packet when configuring a vector. Values of this type include the contents of the CQOS and IP headers. These values also specify the payload contents of the packet.
  • Control information HDEFAULTS initially set the defaults for information regarding measurement sequence, test bandwidth, and any other information external to the measurement packets themselves. Preferably, users can modify these characteristics, if needed, to other valid values.
  • HDEFAULTS and specific vector characteristics can be retrieved from a nodal member 30. This makes it possible to fill in the HDEFAULT values through an application before setting up a vector on nodal member 30. In a prefe ⁇ ed embodiment of the present invention, the HDEFAULTS cannot be changed to other values.
  • This section contains the HDEFAULT values defined and co ⁇ esponding definitions in one prefe ⁇ ed embodiment of the present invention. It will be appreciated that other defaults may be used in other embodiments of the present invention. Note that an unsigned -1 signifies that all bits in the field are set.
  • the slow path is taken if a packet requires special handling that cannot be handled directly by the hardware. In this case, the processor on the router must be involved to handle the packet. Conversely, the fast path is taken if a packet does not require special handling and does not have to be sent to the processor for handling.
  • Events that can cause the packet to take the slow path include: TOS field settings that the router needs to modify; a packet size that is too large to be sent out without fragmentation; and a packet with an optional IP header wanting record route or other routing information that must be extracted from the header.
  • a side effect of this route path issue is that a packet can be retransmitted with greater delay then packets that take the fast path. If this delay is long enough, this can cause packets to be received in the incorrect order, even if the packets are sent to the same router.
  • hops The number of routers between the transmitter and receiver, called hops, can have an effect on certain results. As the number of hops increases, the chance of an increase in latency, jitter, and lost packets also increases. Latency and jitter may increase just because of the nature of receiving and retransmission. Lost packets may increase because the packet must go through a greater number of queues where most packets are dropped.
  • the network metric system 10 utilizes a database 40 that is SQL compliant.
  • the database 40 is an Oracle database that manages vector configuration information and all results.
  • the raw data is stored and available for a variety of reports 70, as shown in FIGURE 4.
  • the reports 70 are not pre-created, but rather are pulled directly from the database 40, based on user-defined parameters, the reports are flexible and reflect true averages for the time periods chosen. The averages can be considered true because they are not averages of averages, as commonly and mistakenly calculated by prior art measurement systems.
  • a prefe ⁇ ed database 40 of the present invention stores the original numerator and denominator data so that true averages can be calculated based on the user-defined parameters.
  • the database 40 stores a full range of the complete set of Internet metrics that are described in detail below. Other data fields may also be added to the database 40 in other embodiments as desired.
  • the network metric system 10 manages all aspects of the database 40. However, in other embodiments, the system 10 also supports unique data access requirements and customized application integration via the database.
  • the database 40 provides the vector configuration information to the service daemon 60, as well as storing measurement data transmitted from the nodal members 30 via the service daemon 60.
  • the database 40 obtains the vector configuration information from the user interface of the workstation 50 via the application server 46.
  • the application server 46 operatively connect the database 40 and the workstation 50 for system configuration and results display.
  • Results display includes obtaining the results data from database 40 and preparing the data for display.
  • the workstation 50 provides a user interfaces with the database 40 through the application server 46 for system configuration.
  • System configuration includes creating and sending vector configuration information to the database 40.
  • the application server 46 is removed, and the workstation 50 interfaces with the service daemon 60. (In this embodiment, the functions of the application server 46 are performed by service daemon 60).
  • the network metric system 10 provides easy access to reports and management in the system from any computer without requiring special or complicated software installation.
  • the work station implements multiple secured access levels.
  • Initial security levels include an administrator level and a user level.
  • the administrator has access to system configuration, which includes creation/modification/deletion of nodal members 30, vectors, service types, logical groupings of vectors, and the user access list. These functions are easily accessible to the administrator from the home page of the browser-based user interface. Typically, a user can only view reports. These multiple access levels allow a greater level of security to be implemented into the system.
  • the user interface is secured using the Secure Socket Layer (SSL) protocol and the application server 46 also authenticates user connections.
  • SSL Secure Socket Layer
  • the workstation utilizes a traffic engineering application as an operations and analysis tool that provides a user interface to the network metric system 10.
  • the primary function of the application is to provide meaningful presentation of network performance measurements in order to allow network planners to view real-time, large-scale, scientific measurement of the Quality of Service performance delivered by their IP networks.
  • the workstation 50 is utilized to implement user-definable groupings of vectors.
  • Vectors can be logically grouped for ease of vector display and reporting.
  • Useful groupings of vectors may include geographical, customer, network type, or priority based groupings. Additionally, groupings can also overlap (i.e., a vector can be part of several different groups). This configuration allows for ease of use and customizable reporting to suit various reporting needs and users.
  • secure access may be available on a per-group basis. Alarms
  • a prefe ⁇ ed embodiment of the network metric system 10 provides customised alarms for automatic triggering and notification of emerging performance issues, including integration into Network Management Systems (NMS) to enhance a customer's own network operations facilities.
  • NMS Network Management Systems
  • User alerts may be viewed through the user interface 80 (as shown in FIGURE 5), and may activate notification functions such as e-mail, paging, or transmission of SNMP traps for integration with established Network Management Systems (NMS) like HP Open View.
  • NMS Network Management Systems
  • the alarm capability of the network metric system 10 offer a tangible method of dealing with Service Level Agreements (SLA) compliance.
  • SLA Service Level Agreements
  • a Service Provider may proactively manage their service level agreements for exactly the conditions that cause non-compliance (e.g., delay or outages).
  • the alarm capability and general measurement capability of the present invention allows grouping of measurement vectors to give additional SLA benefits.
  • Groups create a method of applying hierarchies to measurement solutions. hrough the use of groups, a customer may separate the measurement of their IP network many ways, while only instrumenting the measurement solution once.
  • basic real-time reports 70 are automatically generated (without any additional configuration) that show one-way delay, jitter, packet loss and availability measurements. These results are preferably presented in a side-by-side graphical and tabular display, with a separate line for each service type. True averages are provided for each time period, and a minimum, maximum, and standard deviation are also automatically shown.
  • the present invention produces results using numerator and denominator values, so that true averages can be calculated through a sum of all numerators and a sum of all denominators. This avoids the smoothing effect created by calculating an average of averages.
  • a prefe ⁇ ed embodiment in the present invention provides a wide a ⁇ ay of reporting options.
  • the system allows a user to designate continuous time or time period history reporting, measurement period, start time, end time, and bi- or uni-directional measurements. This type of flexible reporting with customizable time periods up to and including the current period is highly advantageous to a system user.
  • the network metric system of the present invention preferably provides click through access to powerful results that are not available from prior measurement products or services.
  • the receiving nodal member is ready to receive measurement packets.
  • a linked list is created for each vector, for each measurement period. Measurement packets received from another nodal member 30 are stored in this linked list in the order received. Packets are stored in an atomic data unit structure.
  • CQOS measurement packets and atomic data units are considered equivalent.
  • the result calculation routines are called. In one prefe ⁇ ed embodiment of the present invention, if the end of measurement period packet is not received within 48 hours, the results are discarded.
  • the calculation methods take the packets received and fills out the results. The results are then sent to another computer for subsequent analysis. The memory associated with the vector's current measurement period is then freed.
  • the packet is inserted into the appropriate linked list based on identification information contained in the CQOS header.
  • This identification information is made up of four fields, the sendingnodal memberlD, the sendingCVectorlD, the measuremenfPeriodID, and the nodal memberMeasurementPeriodlD.
  • the sendingnodal memberlD is a unique identifier that is given to each nodal member 30.
  • the sendingCVectorlD is the vector identifier that is unique per sending nodal member 30.
  • the measuremenfPeriodID is an identifier starting from 0 assigned to each measurement period.
  • the nodal memberMeasurementPeriodlD is also an identifier assigned to each measurement period, but if differs from the measuremenfPeriodID in that it is unique and not 0 based. Based on 3 of the 4 identifiers, that is, sendingnodal memberlD, sendingCVectorlD, and nodal memberMeasurementPeriodlD, a guaranteed unique linked list is located to place the incoming packets into.
  • Duplicate packets can occur because of various reasons. Duplicate packets are taken into account for most result calculations, except for jitter, outages, and ordering. In these cases, only the first occurrence is used. In order to detect duplicates, the list is traversed and all other items in the list are compared with the cu ⁇ ent item. If the sequence number of the item and the transmitted timestamp match, then there is a duplicate. The index of the item is placed in an array allocated to store duplicate indexes. The cu ⁇ ent item is then incremented to the next one until all items in the list have been checked. Note that all items are placed in the duplicate a ⁇ ay, even the first occurrence thereof.
  • the total number of duplicates, minimum number of duplicates for one item, and maximum number of duplicates for one item are all calculated based on the duplicate a ⁇ ay. These are stored in the results as packetsDuplicated, packetsDuplicatedMin, and packetsDuplicatedMax. Eventually, an extra metric may be added that counts duplicates that took a different route from one another using TTL value comparisons.
  • a packet is dropped when a packet is transmitted, but it is not received.
  • the definition of the number of dropped packets is:
  • Fragmentation occurs in routers when a packet arrives that cannot be sent out on the next route without breaking the packet up into smaller pieces. This typically occurs because the next part of the route uses a protocol that has a maximum packet size that is smaller than the size of the current packet. Currently, the maximum size of the packet is set to the maximum size of an Ethernet packet (1500 bytes). To calculate the fragmentation results, a loop is used to retrieve the proper results from all of the atomic packet data.
  • packetsFragmented is the sum of all of the packets that were fragmented and packetsFragmentedMin, packetsFragmentedMax, packetsFragmentedAverageNumerator, packetsFragmentedAverageDenominator are the minimum, maximum, and average fragmented packets respectively.
  • Hop count or Time To Live (TTL) is the maximum number of routers that can be traversed when transmitting data. Each time a packet is retransmitted by a router, it's TTL value is reduced by one. A router that receives a packet with a TTL value of 0 drops the packet. The transmitting nodal member 30 saves the original TTL value in the CQOS header so that when the packet arrives the hop count can be calculated. The HDEFAULT value of TTL is the maximum, 255. To calculate the TTL results, a loop is used to retrieve the proper results from all of the atomic packet data. The cu ⁇ ent packet's TTL value is temporarily stored so that if the TTL field is different for the next packet, the number of changes can be saved.
  • packetsTtlMin, packetsTtlMax, packetsAverageNumerator and packetsAverageDenominator are the minimum, maximum, and average TTL values.
  • packetsTtlChanges is the number of changes of TTL values between all of the packets.
  • Jitter Jitter is the difference between the time a packet is expected to arrive, and the time it actually arrives. In other words, a measurement sequence of packets is transmitted one second apart. Jitter is how far apart the packets actually arrived. Jitter is mathematically defined as:
  • Dropped packets are not counted in jitter calculations. For example, if a burst of 5 packets comes in and packet 3 is dropped, the transmitted sequence of packets that were actually received is: 1,2,4,5. The jitter between packets 1,2 and the jitter between packets 4,5 will be calculated. But since packet 3 was dropped, the jitter between packets 2,3 and 3,4 will not be calculated and included in the results.
  • the accumulated jitter, minimum jitter, maximum jitter, sum of squares, sum of cubes, jitter count, and jitter burst count are all calculated and saved in jitterStdDevSums, jitterMin, jitterMax, jitter SumSqrd, jitterSumCubed, jitterCount, burstsReceived, respectively. Latency
  • Latency is the amount of time that a packet takes to travel from the transmitter to the receiver:
  • Rx - Tx Timestamp received - Timestamp transmitted The timestamp when the packet is transmitted is placed in the packet in the CQOS header upon transmission. When the packet is received another timestamp is recorded.
  • All the packets are traversed and the average latency, maximum latency, minimum latency, sum, sum of squares, sum of cubes, and number of latencies used for calculation for all packets with non-corrupted CQOS headers are calculated. These values are saved in the latency A verageNumerator, latency A verageDenominator, latencyMin, latencyMax, latencyStdDevSums, latencyStdDevSumOfSquares, latencyStdDevSumOfCubes, and latencyStdDevN fields, respectively.
  • An outage occurs when a vector is not available.
  • the causes of an outage can vary from a cable not co ⁇ ectly plugged in, to a router or network failure.
  • an outage is determined if there are no measurement packets received within a certain time period. This period is set by default to be 10 seconds. However, any defined time period may be used in other embodiments of the present invention. If even 1 measurement packet arrives within this set time period, then no outage will occur. Also, only the first occurrence of a duplicate counts towards a received packet. The remaining duplicates do not reset the outage counter. Therefore, packets with e ⁇ ors in them do not reset the counter. The timestamp of when a packet is received is currently used to calculate outages.
  • the outage algorithm works by looping through all of the packets received. Starting from the beginning of the received packets, the outage algorithm finds a packet without e ⁇ ors and with no duplicates for it in the list, and saves the received timestamp of the packet. For every packet, except for the first, the outage algorithm subtracts the time of the cu ⁇ ent valid packet received from the last packet's received timestamp. If the difference is greater than the outage trigger time (currently 10 seconds) then an outage has occu ⁇ ed and is recorded. The algorithm also looks for the last packet received to see if there is an outage of which it can compute the length, without using the maximum of the remainder of the measurement period.
  • the result of the algorithm is the sum of all outage durations, the minimum outage duration, the maximum outage duration, and the number of outages. These values are saved in the results as: outageDurationTotal, outageDurationMin, outageDurationMax, and outages, respectively.
  • the order in which packets are received is another set of data saved in a prefe ⁇ ed embodiment of the present invention.
  • an algorithm is applied whose purpose is to determine how many items are out of order.
  • the algorithm distinguishes between individual packets and groups of packets.
  • a group of packets is one in which all items in the group are in sequential order with no out of order packets there between.
  • the end result of the algorithm is the number of groups of packets and the number of individual packets out of order.
  • MLAS minimal longest ascending subsequence
  • An ascending subsequence of X denoted by S of length m, is defined as any subsequence of X which has the properties that (i) it contains m number of elements, (ii) the elements appear in S in the same order as there appear in X, and (iii) the elements of S are in ascending order.
  • ascending subsequences of length m 3 of possible sequences include:
  • the ascending subsequence(s) of length m - m m! ⁇ are greater in length than all other ascending subsequences in that given X.
  • m mm 5
  • these subsequences are defined as the longest ascending subsequences of X.
  • the set of longest ascending subsequences can be ranked by comparing their terminal elements, and then, if necessary, the subsequence elements, working backwards.
  • the longest ascending subsequences S braid S 2 , S 3 are ranked S 3 ⁇ S 2 ⁇ S, because 8 ⁇ 10 and 7 ⁇ 9.
  • the members belonging to the longest ascending subsequence that has the lowest rank is refe ⁇ ed to as the Minimal Longest Ascending Subsequence (MLAS) of the sequence X.
  • MLAS Minimal Longest Ascending Subsequence
  • the MLAS is unique.
  • the MLAS is S 3 .
  • the packets that are in the MLAS for the sequence are defined to be "in order.” Accordingly, those packets not belonging to the MLAS are considered to be "out of order.”
  • N the number of packets in a group of measurement data
  • the terminal element of this ascending subsequence is x ⁇ ).
  • These terminal elements are ordered, so that x(t,) ⁇ x(t 2 ) ... ⁇ x(tm raax ).
  • search the terminals for a j such that x(t j ) ⁇ x(K) ⁇ x(t j+1 ).
  • the reconstruction of the MLAS is performed after the basic algorithm has been executed; first starting from x(tm max ), and then following the predecessors backwards. It should be emphasized that this step is not necessary if only m.,-, is required.
  • Port counters are used to keep track of the number of frames, collisions, and certain types of e ⁇ ors calculated by the 'layer 2' (Ethernet layer) interface.
  • Each data packet in the received list contains a running estimate of these items. The estimates in the first packet are subtracted from the estimates in the last received packet and these are stored as results for the measurement period.
  • Internet Protocol supports an optional header field that has numerous uses, of which the nodal member 30 currently supports three.
  • Internet Protocol can be used to record the route a packet traversed, or specify loosely or very strictly the way a packet should be routed.
  • the maximum size of this field is specified as 60 bytes. Due to the maximum size limitation, the maximum number of IP addresses that can be recorded or specified is 9.
  • the packet traversed When recording the route, up to 9 routers (the first 9 routers) the packet traversed are saved in the header. Any other routers visited are not be recorded. In order to record this information, it is necessary for the packet to take the slow path through the router. With a strict route specified, the IP addresses of the routers in the optional field must be traversed exactly as placed in the optional header. Using a loose route, the IP addresses of the routers in the optional field must be traversed, but they can be visited in any order and with additional router visits there between.
  • the first and last packets that are received are checked for optional IP header information. Whether or not they contain this information, the packet identifiers of the first and last packet are saved in the firstRoutePacketlD and lastRoutePacketlD fields. The type of optional IP header information is saved in the firstRouteType and lastRouteType fields. The values contained therein are defined as:
  • the actual optional header information and route count for the first and last packet is stored in the firstRouteData, lastRouteData and firstRouteCount, lastRouteCount. Ethernet Errors
  • the first set of e ⁇ ors involves e ⁇ ors that were found previously at the Ethernet layer. These ayer 2' e ⁇ ors are summed in each of the appropriate fields in the results for all packets received in the measurement period. These e ⁇ ors are:
  • the next set of e ⁇ ors involves the CQOS header checksum.
  • This checksum is a 64 bit value that validates the CQOS header items. If this checksum is inco ⁇ ect, critical data cannot be retrieved from the packet such that it cannot be used for TTL, IP protocol, TOS, latency, outage, and jitter calculations. The IP payload is also considered corrupted since the CQOS header is part of the IP payload. If the CQOS header is corrupted, the packet is not stored in the array of packets used for further computations and is ignored for the metrics mentioned below. These items are stored in the a ⁇ ay of packets used for further calculations:
  • the identifier of the burst - cBurstID A pointer to the packet - packet;
  • the identifier of the period - CperiodID (only one packet received in the measurement period has to be free of CQOS header e ⁇ ors to get this anyway);
  • the last set of e ⁇ ors involves the IP header checksum.
  • This checksum is a 16 bit value that validates the IP header items. The checksum does not validate the payload that includes the CQOS header. The following items cannot be properly computed or stored if the IP header is corrupted and so the packet is skipped for these calculations:
  • the number of protocol changes - packetsIPProtocolChanges; and The number of TOS field changes - packetsTosChanges and all other TOS results.
  • bytesReceived is the sum of the number of bytes received in total for the measurement period. To calculate the bytesReceived, the packets are traversed and all of the bytes received for each packet are summed.
  • Up to the first 10 TOS fields are saved into the packetsFirstlOTos a ⁇ ay.
  • All received packets with valid CQOS and IP headers are traversed.
  • the values in the TOS fields in the CQOS header and IP header are examined.
  • the values are compared and, if they differ, the TOS field setting is saved in the packetsFirstlOTos a ⁇ ay. This indicates a router modified the TOS field before re-transmitting the packet.
  • the number of changes stored is placed in packetsFirstlOTosCount.
  • Some general vector information is also stored in the results.
  • the packetsTransmitted, bytesTransmitted, measurementPeriodNanoseconds, and universalTime are retrieved from the vector itself and saved.
  • Version information is stored in the results. This information consists of: Transmitting and receiving main versions - txMainVersion, rxMainVersion;
  • Transmitting and receiving nodal member 30 temperature information is saved in the results.
  • the minimum, maximum, average temperatures of the transmitting and receiving nodal member 30 are saved in: txtemperatureMin, i r atureMin, txtemperatureMax, rxte pcratureMax, txtempeiaturcAverageNumerator, rxtemperatureAvcragcNumerator, 0 txtc ⁇ nperatureAveragcDcnomirator, and rxtempeiatureAveragcDcnominator
  • results structure and the elements that comprise the results structure are referenced below, and are used to store all results calculated by the measurement algorithms.
  • reference to the result structure is a S reference the structure below.
  • uint64 jitterStdDevSumOfSquares //jitter sum of squares uint64 jitterStdDevSumOfCubes; //jitter sum of cubes uint64 jitterStdDevSums; //sum of jitter uint64 jitterStdDevN; //# of jitter calculations /* Latency */ uint64 latency TimestampsMismatch; //# of cases where rx ⁇ tx uint64 latencyMin; //min latency # uint64 latencyMax; //max latency # uint64 latency A verageNumerator; //avg.
  • latency # (numerator) uint64 latency A verageDenominator; //avg. latency # (denominator) uint64 latencyStdDevSumOfSquares; //latency sum of squares uint64 latencyStdDevSumOfCubes; //latency sum of cubes uint64 latencyStdDevSums; //sum of latency uint64 latency StdDevN; //# of latency calculations
  • this structure is used to store information for each measurement packet received.
  • a linked list of these structures for the cu ⁇ ent measurement period is located initially by the measurement algorithms. The list is in order received.
  • struct struct cqosAtomicPacketData ⁇ uint8 cqosheader lPProtocol; //original IP protocol uint8 cqosheader_TOS; //original TOS uint ⁇ cqosheader TTL; //original TTL uint64 cqosheader_nodal memberlD; //ID unique for each nodal member uint64 cqosheader_nodal memberPeriodID;//ID for measurement period (unique, not 0 based) uint64 cqosheader CVectorlD; //ID of vector unique for each nodal member uint64 cqosheader_CPeriodID; //ID of vector unique for each nodal
  • uint64 estimate txCollisions; //# of transmitted collisions uint64 estimate_txNoTxCollisionE ⁇ ors; //# of transmitted late collision e ⁇ ors + max collision e ⁇ ors uint64 estimate rxGoodFrames; //# of received good frames uint64 estimate jxCRCErrors; //# of received CRC errors uint64 estm ⁇ ate_rxAUgnE ⁇ rors; //# of received alignment errors uint64 estimate_ ⁇ cResourceErrors; //# of received resource errors uint64 cstimate_rxShortFrameErrors; //# of received short frame errors /* Packet Error Counters */ uint32 12_rxCRCE ⁇ ror: 1 ; //packet has level 2 checksum error uin ⁇ 32 l2 xAlignmentError l; //packet has level 2 alignment error uin
  • a vector is the fundamental measurement unit.
  • a vector is defined as a packet type and source and destination pair.
  • the packet type describes what the characteristics of the packet are. All packets for the vector have the same characteristics (i.e.
  • Packet types include the ability to control: length of packet; payload type (all zero's, all one's or random); header type (udp, TCP, none); udp/tcp source and destination port numbers; TTL value; TOS/DiffServ bits; IP protocol value; IP loose, strict, and record route options; Default gateway to use for routed networks; Source and Destination addresses; and TCP Header information such as [window size, MSS option, FLAGS, urgent pointer].
  • the format of the packet is as follows:
  • a vector is created by the service daemon 60.
  • the service daemon 60 reads the configuration parameters of the vector from a database and communicates with the nodal member 30 via CQOS Protocol to create the vector on the sending nodal member 30. If the nodal member 30 accepts the configuration request, the nodal member responds to the service daemon 60 with an "ok" status. If the nodal member 30 does not accept the configuration request, the nodal member will not create the vector and responds with an e ⁇ or status.
  • the service daemon 60 issues the Readiness test command (via CQOS Protocol).
  • the readiness test includes a set of tests including the Go/NoGo test, as previously discussed.
  • ARP Default Gateway Send an ARP (Address Resolution Protocol) request to the gateway and store into memory round-trip time (RTT) of the ARP request, execute time, the IP address of the default router, and the MAC address (if valid response) of the default address;
  • ARP Address Resolution Protocol
  • Ping Default Gateway Ping (ICMP Echo Message) to the gateway and store into memory the RTT time, execute time, and IP Address of the gateway;
  • Ping Receiving nodal member Ping the receiving (destination) nodal member 30 and record the RTT time, execute time and IP address of the receiving nodal member 30;
  • Trace Route to Receiving nodal member Trace Route to the receiving nodal member 30 and record each hops IP address, RTT. Also record the execute time and destination IP address;
  • the receiving nodal member 30 does not accept the parameters or user ID/password combination, then either NO response is be given to the sending nodal member 30, or a NoGo message is sent. In either negative case, the sending nodal member 30 will not under any circumstances send measurement packets.
  • the feature is for security in that the users can not create vectors to systems other than nodal members 30 nor create vectors to nodal members 30 that they do not control.
  • measurement packets are sent, which are formed as shown above.
  • the number of packets sent is based on the number of total vectors within the sending nodal member 30, the characteristics of those vectors (e.g. packet size, packets / sequence) and the measurement bandwidth allocated to the sending nodal member 30. Packets are sent at the measurement bandwidth rate over the measurement period (5 minutes). Every measurement period, the number of packets sent is recalculated before the measurements packets sent. Measurement packets are sent until the vector is stopped or deleted.
  • the nodal member 30 As the receiving nodal member 30 receives measurement packets, the nodal member pre-processes them into a unit of data refe ⁇ ed to as an Atomic Packet.
  • the Atomic Packet stores information such as the packet ID, Vector ID, sending nodal member ID, transmit timestamp, receive timestamp, original TTL value and received TTL value, as well as the status of the various regions such as the IP header, UDP/TCP/Other header, payload and CQOS header.
  • the receiving nodal member 30 processes the Atomic Packets via its algorithms (as described above). Once completed, this information is stored for up to 36+ hours. The information is then sent to the service daemon 60 via the CQOS Protocol. If the service daemon 60 does not receive the result packet until some time later than expected, or if the service daemon receives a subsequent results packet, the service daemon polls the nodal member 30 for the results. The service daemon 60 can poll the nodal member 30 for data that was computed/measured 36+ hours in the past.
  • the Internet metric system 10 allows for a very scalable system that is highly distributed.
  • the results data is constant in size regardless of the number of measurement packets sent, the system is far more efficient at storing data and reporting data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un système métrique de réseau (10) comprenant un réseau nodal (20), une base de données (40), un serveur d'application (46), une station de travail (50), et au moins un daemon service (60) faisant interface entre le réseau nodal (20) et la base de données (40). Le réseau nodal (20) est composé de plusieurs éléments nodaux (30) entre lesquels sont réalisées des mesures unidirectionnelles via un parcours asymétrique. Dans le système métrique de réseau (10), les mesures sont réalisées au niveau de la couche IP, contrairement aux systèmes antérieurs qui réalisaient ces mesures au niveau de la couche d'application. En outre, le nombre d'éléments nodaux (30) utilisé en tant que points de mesure dans le réseau nodal (20) est hautement échelonnable, afin de permettre la réalisation de mesures précises dans un environnement de réseau de n'importe quelle dimension. La base de données (40) stocke les données relatives aux mesures qui sont générées par les éléments nodaux (30). La station de travail (50) agit en tant qu'interface utilisateur afin d'accéder à la base de données (40) via la service d'application (46) en vue de configurer le système et de reporter les données relatives aux mesures. Le daemon service (60) fait interface avec le réseau nodal (20) et la base de données (40). Ce service (60) donne également la consigne aux éléments nodaux de créer de nouveaux vecteurs, obtient des informations de configuration de vecteur provenant de la base de données, gère les données de résultat transmises par les éléments nodaux (30) à la base de données (40). Les mesures comprennent des données d'ordonnancement par paquets destinées à des paquets reçus qui sont définis au moyen d'un algorithme à sous-séquence minimale ascendante la plus longue. Ces paquets se trouvant dans cette sous-séquence sont considérés comme étant ordonnés, et ceux qui ne s'y trouvent pas sont considérés comme étant désordonnés.
PCT/US2002/016957 2001-05-24 2002-05-24 Systeme metrique de reseau WO2002095609A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/864,929 2001-05-24
US09/864,929 US20030023710A1 (en) 2001-05-24 2001-05-24 Network metric system
US10/080,925 US20030093244A1 (en) 2001-05-24 2002-02-22 Network metric system
US10/080,925 2002-02-22

Publications (1)

Publication Number Publication Date
WO2002095609A1 true WO2002095609A1 (fr) 2002-11-28

Family

ID=26764137

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/016957 WO2002095609A1 (fr) 2001-05-24 2002-05-24 Systeme metrique de reseau

Country Status (1)

Country Link
WO (1) WO2002095609A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2477357A1 (fr) * 2011-01-12 2012-07-18 Alcatel Lucent Commande de diagnostic de délai de routage
CN105553695A (zh) * 2015-12-08 2016-05-04 南阳理工学院 一种基于两级双向哈希链表的ip数据流管理方法

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5802302A (en) * 1995-06-29 1998-09-01 International Business Machines Corporation System and method for response time measurement in high speed data transmission networks
US6097669A (en) * 1999-07-01 2000-08-01 Jordan; James R. Wavelet filtering of sodar signals
US6230312B1 (en) * 1998-10-02 2001-05-08 Microsoft Corporation Automatic detection of per-unit location constraints
US6324586B1 (en) * 1998-09-17 2001-11-27 Jennifer Wallace System for synchronizing multiple computers with a common timing reference
US6330236B1 (en) * 1998-06-11 2001-12-11 Synchrodyne Networks, Inc. Packet switching method with time-based routing
US6363421B2 (en) * 1998-05-31 2002-03-26 Lucent Technologies, Inc. Method for computer internet remote management of a telecommunication network element
US6381628B1 (en) * 1998-10-02 2002-04-30 Microsoft Corporation Summarized application profiling and quick network profiling
US6385198B1 (en) * 1998-06-11 2002-05-07 Synchrodyne Networks, Inc. Signaling for timely forwarding in packet switching network with a common time reference
US6393126B1 (en) * 1999-06-23 2002-05-21 Datum, Inc. System and methods for generating trusted and authenticatable time stamps for electronic documents

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5802302A (en) * 1995-06-29 1998-09-01 International Business Machines Corporation System and method for response time measurement in high speed data transmission networks
US6363421B2 (en) * 1998-05-31 2002-03-26 Lucent Technologies, Inc. Method for computer internet remote management of a telecommunication network element
US6330236B1 (en) * 1998-06-11 2001-12-11 Synchrodyne Networks, Inc. Packet switching method with time-based routing
US6385198B1 (en) * 1998-06-11 2002-05-07 Synchrodyne Networks, Inc. Signaling for timely forwarding in packet switching network with a common time reference
US6324586B1 (en) * 1998-09-17 2001-11-27 Jennifer Wallace System for synchronizing multiple computers with a common timing reference
US6230312B1 (en) * 1998-10-02 2001-05-08 Microsoft Corporation Automatic detection of per-unit location constraints
US6381628B1 (en) * 1998-10-02 2002-04-30 Microsoft Corporation Summarized application profiling and quick network profiling
US6393126B1 (en) * 1999-06-23 2002-05-21 Datum, Inc. System and methods for generating trusted and authenticatable time stamps for electronic documents
US6097669A (en) * 1999-07-01 2000-08-01 Jordan; James R. Wavelet filtering of sodar signals

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2477357A1 (fr) * 2011-01-12 2012-07-18 Alcatel Lucent Commande de diagnostic de délai de routage
WO2012095335A1 (fr) * 2011-01-12 2012-07-19 Alcatel Lucent Commande de diagnostic traceroute_delay
CN103563307A (zh) * 2011-01-12 2014-02-05 阿尔卡特朗讯公司 跟踪路由_延迟诊断命令
KR101459252B1 (ko) * 2011-01-12 2014-11-07 알까뗄 루슨트 Traceroute_delay 진단 커맨드
US9509582B2 (en) 2011-01-12 2016-11-29 Alcatel Lucent Traceroute—delay diagnostic command
CN105553695A (zh) * 2015-12-08 2016-05-04 南阳理工学院 一种基于两级双向哈希链表的ip数据流管理方法
CN105553695B (zh) * 2015-12-08 2018-08-24 南阳理工学院 一种基于两级双向哈希链表的ip数据流管理方法

Similar Documents

Publication Publication Date Title
US20030093244A1 (en) Network metric system
US20090161569A1 (en) System and method for facilitating carrier ethernet performance and quality measurements
AU2019214925B2 (en) Systems and methods for broadband communication link performance monitoring
EP1418705B1 (fr) Système de surveillance de réseau utilisant les numéros de séquence de paquets
EP1734690B1 (fr) Surveillance de performance de transmission de trames dans un réseau de données utillisant le protocole OAM
US6643612B1 (en) Mechanism and protocol for per connection based service level agreement measurement
US20210328856A1 (en) Scalability, fault tolerance and fault management for twamp with a large number of test sessions
US7986632B2 (en) Proactive network analysis system
US8601155B2 (en) Telemetry stream performance analysis and optimization
US7483379B2 (en) Passive network monitoring system
US9450846B1 (en) System and method for tracking packets in a network environment
Jin et al. Network characterization service (NCS)
KR20090100377A (ko) 데이터 네트워크의 성능 레벨 모니터 및 기록 방법
WO2003091893A1 (fr) Procedes, appareils et systemes facilitant la determination des mesures de trajets de reseau
US20140369218A1 (en) Measurement on a data flow in a communication network
Hendriks et al. Assessing the quality of flow measurements from OpenFlow devices
US7274663B2 (en) System and method for testing differentiated services in a value add network service
Chen Increasing the observability of Internet behavior
CN116346634A (zh) 网络管控系统的状态感知信息处理方法、装置及电子设备
WO2002095609A1 (fr) Systeme metrique de reseau
Cisco Network Monitoring Using Cisco Service Assurance Agent
Cisco Interface Configuration Commands
Cisco Interface Configuration Commands
Cisco Interface Configuration Commands
Cisco Interface Configuration Commands

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP