Multiplex communications – Diagnostic testing – Determination of communication parameters
Reexamination Certificate
2000-06-30
2004-08-03
Chin, Wellington (Department: 2731)
Multiplex communications
Diagnostic testing
Determination of communication parameters
C370S386000
Reexamination Certificate
active
06771607
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates to a method of measuring and recording various parameters of traffic at nodes in a data transmission network. It also relates to the provision of a sampling circuit for the measurement and recording of such traffic parameters.
FIELD OF THE INVENTION
Any data transmission network comprises switches or routers in which traffic is carried in flows defined by identifiers, which may be VC/VP pairs in an ATM switch, source or destination address pairs in an IP router or a logical prefix-based aggregations of source or destination addresses. Traffic management schemes are based on measurement of traffic load and for such schemes to work effectively, the measurement must be accurate. The most fundamental form of measurement is a sample of the bit-rate of the traffic and the timescale over which such a measurement is made determines how much information can be deduced from it. If the timescale is relatively long such as the order of hours or days, then all that can be deduced is the average traffic load and the measurement tells nothing whatsoever of the typical delays or indeed packet-drop rates. In order to deduce the latter, sampling of the traffic rate must take place using a timescale at which packet queuing occurs, namely, that of the order of tens of milliseconds. Making accurate rate-measurements in such timescales is extremely challenging and difficult. Current networking hardware can count various quantities relating to traffic streams, such as the number of arriving packets and arriving bytes. In order to make bit-rate measurements, software within the switch or router operating system must poll the byte counter, read the system time, set the software timeout and then read the byte counter and system time again. The bit-rate sample is then calculated as the ratio of
final byte-count
-
initial byte-count
final time
-
initial time
Unfortunately, with a software-based system, there are a number of serious problems.
Firstly, it can be difficult to arrange for software times to expire accurately at a timescale of 10 ms. Even if such software timers are accurate, the architecture does not scale well. If the counting process is handling many counts at once, it needs to use its timer many times, namely, once for each count. When the counter periods overlap, the actual timeout periods may be much shorter than the timescale of the count, namely, 10 ms, mentioned already, for any individual count. Thus, in practice, many counts will interfere with each other in software leading to reduced accuracy for all the counts.
A further problem is that even if the number of counts is such that they can be handled correctly, it is virtually impossible to guarantee that the times in which the byte counters are read will be recorded or clocked accurately. Effectively, any process embodied in software will be programmed to poll the byte counter and then immediately read the system clock. However, there is no guarantee that the actual process will not be preempted by another process having a higher priority or by a hardware interrupt between polling the counter and reading the clock. Obviously, if the counting process is preempted, it makes the current count unusably inaccurate. A further problem is that typically there will be no record of this interrupt and thus the process cannot discard that particular faulty count and reject it but it will be used for further processing.
Finally, a major drawback inherent in using software alone is that even if the counting and timing could be carried out accurately, there is a limitation in that, in effect, rate samples can only be taken over specified periods of time. It is important in some applications to be able to time, for example, how long it takes for a fixed number of bytes to arrive which latter is impossible to achieve in software without a busy loop constantly polling the bye counter, which would effectively leave the CPU unusable for any other purpose. Accordingly, carrying out such a task by way of software alone is relatively useless for traffic management.
OBJECTS
The present invention is directed towards providing a method and apparatus for rate sampling by measuring and recording various parameters of traffic at at least some of the nodes in a data transmission network.
SUMMARY OF THE INVENTION
According to the invention, there is provided a method of measuring and recording various parameters of traffic at at least some of the nodes in a data transmission network in a rate sampling piece of hardware. Such nodes would be network switch routers, destination addresses, and so on. At least some of the nodes in the data transmission network are connected to at least one system counter provided in software. In this case, the method comprises enabling a group of counters; counting various individual activities of the traffic at the node as separate system activity counts; and providing a simultaneous real time count. The method comprises causing each counter to be disabled on a pre-set activity condition being sensed at the node; reading the count recorded at the node for the real time between the enabling and disabling of the counter; reading the real time elapsed during said count; storing the count and time read as traffic data; and re-enabling the counter to continue with the next count.
Carrying out the invention in hardware overcomes all the problems in present software solutions.
Ideally, on disabling a counter, one or more are disabled and the traffic data for the or each of said counters is stored. Many pre-set activity count condition sensed can be used such as the real time elapsed since enabling the counter, the number of bytes counted since enabling the counter, and the number of data packets counted since enabling the counter.
Ideally, all the system activity counts are carried out simultaneously at the node by disabling all counters connected to the node once one counter is disabled and enabling all the counters connected to the node when any of the counters connected to the node is enabled.
Alternatively, all the system activity counts are carried out simultaneously over the same time period by disabling all counters on any one of a number of pre-set activity count conditions being sensed at the nodes and enabling all counters simultaneously when any one counter is enabled.
It will be appreciated that the method will also include computing traffic data from the traffic parameters and storing the traffic data for subsequent retrieval. The amount of computation used will depend entirely on the hardware being used.
Further, the invention provides a sampling circuit for the measurement and recording of traffic parameters as system activity counts at a node in a data transmission network comprising:
a plurality of separately operable hardware counters, each for counting a specific system activity count at the node;
a time counter having an input signal in the form of a clock operating at fixed interval;
operating circuit means for enabling and disabling the operation of each counter;
recording circuit means for the individual counts read at the counter for the real time between the enabling and disabling of each counter; and
storage circuit means for the individual counts.
There is also provided computational circuit means for calculating traffic parameters for the network.
The operating recording and storage circuit means is carried out by a programmable control circuit.
The counters may be combined into a counter assembly comprising at least one system counter but more likely at least two system counters. Ideally these are a system counter for counting bytes and a system counter for counting packets and always a time counter. It is envisaged that dedicated multiplexors may be used for monitoring and detecting the output of each system counter measured in the number of bits. Such as system counter will ideally be provided by an addressable register.
In one embodiment of the invention, the sampling circuit comprises:
a plurality of addressable registers forming a time counter
Dowse Ian Edward
Russell Raymond Philip
Chin Wellington
Jacobson & Holman PLLC
Pham Brenda
LandOfFree
Measure and recording of traffic parameters in data... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Measure and recording of traffic parameters in data..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Measure and recording of traffic parameters in data... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3331223