Realtime High Speed Data Capture in Response to an Event

1. Technical Field

The invention disclosed broadly relates to the extraction of information from large bodies of data for high speed communication facilities. The invention is particularly directed to the realtime high speed data capture in response to an event.

2. Related Patent Applications

This patent application is related to the copending U.S. patent application Ser. No. 08/024,572, filed Mar. 1, 1993, entitled "Information Collection Architecture and Method for a Data Communications Network," now U.S. Pat. No. 5,375,070 by J. G. Waclawsky, et al., assigned to the IBM Corporation and incorporated herein by reference.

This patent application is also related to the copending U.S. patent application Ser. No. 08/024,575, filed Mar. 1, 1993, entitled "Event Driven Interface for a System for Monitoring and Controlling a Data Communications Network," now U.S. Pat. No. 5,365,514, by P. C. Hershey, et al., assigned to the IBM Corporation and incorporated herein by reference.

This patent application is also related to the copending U.S. patent application Ser. No. 08/024,542, filed Mar. 1, 1993, entitled "System and Method for Configuring an Event Driven Interface and Analyzing Its Output for Monitoring and Controlling a Data Communications Network," by J. G. Waclawsky, et al., assigned to the IBM Corporation and incorporated herein by reference.

This patent application is also related to the copending U.S. patent application Ser. No. 08/138,045, filed Oct. 15, 1993, entitled "System and Method for Adaptive, Active Monitoring of a Serial Data Stream Having a Characteristic Pattern," by P. C. Hershey, et al., assigned to the IBM Corporation and incorporated herein by reference.

Another related copending patent application is by J. G. Waclawsky, et al., entitled "Automated Benchmarking With Self Customization," Ser. No. 08/173,530, filed Dec. 23, 1993, assigned to the IBM Corporation and incorporated herein by reference.

Another related copending patent application is by J. G. Waclawsky, et al., entitled "Intelligent Realtime Monitoring," Ser. No. 08/172,701, filed Dec. 23, 1993, assigned to the IBM Corporation and incorporated herein by reference.

3. Background Information

The above cited Hershey, et al. patent application described an Event Driven Interface which is a pattern recognition technique applied to serial communications media to identify predefined bit patterns on the medium. Sometimes it is desirable to not only identify the occurrence of a particular bit pattern in the serial bit stream, but also to capture the actual bit pattern for subsequent analysis or processing.

It is therefore an object of the invention to capture data from a high speed communications network in realtime.

These and other objects, features and advantages are accomplished by the invention. An Event Driven Interface has its input coupled to a serial communications medium. The Event Driven Interface is programmed to identify predefined patterns of binary bits on the medium. In accordance with the invention, a capture buffer has its input coupled through a gate to the data communications network. A control connection is established between an output of the Event Driven Interface and the gate controlling the connection between the capture buffer and the data communications network. In accordance with the invention, when the preprogrammed Event Driven Interface identifies a particular pattern of bits on the data communications medium, which is intended as a triggering pattern for the capture of data from the network, the Event Driven Interface outputs an enabling signal to the gate coupling the input of the capture buffer to the data communications network, thereby enabling the capture buffer to be loaded with a prespecified portion of the serial bit stream on the data communications network.

The contents of the capture buffer can be used in a number of ways. Contents of the capture buffer may be used as an operand for further processing at the capturing node. Alternately, the contents or a portion of the contents of the capture buffer may be concatenated or otherwise combined with the event vector output from the Event Driven Interface, for use in analyzing the behavior or characteristics of the data communications network. The analysis of the properties of the data communications network can be done by means of an expert system analyzer, such as is described in the above cited Hershey, et al. patent application.

In this manner, realtime high speed data can be captured from a data communications network in response to events which are predefined as triggering bit patterns on the data communications network.

This invention also extends the architecture of the previous Information Collection Architecture (ICA) patent application Ser. Nos. 08/024,572, 08/024,575 and 08/024,542 to include the capability to capture data based on station location in a communications system. Such a communications system could be a single network or a number of different networks with different protocols that communicate with each other. By using this invention a network management facility can assess the effect of a single station on communications system network performance and quickly identify stations that are causing problems. A key advantage of this invention is that very little data need to be captured to assess network performance. Therefore, high speed application is possible. This invention also provides a framework within which the optimal location of ICA devices may be determined in order to maximize the benefit and minimize the cost of incorporating ICA technology into communications systems.

These and other objects, features and advantages will be more fully appreciated with reference to the accompanying figures.

FIG. 1 is a schematic block diagram of the Event Driven Interface and capture buffer, in accordance with the invention.

FIG. 2 illustrates the data frame format.

FIG. 3 illustrates ICA device location for a single network.

FIG. 4 illustrates the ICA device location for multiple networks.

FIG. 5 illustrates the ICA device hierarchy.

The problem solved in this invention is how to capture the actual sequence of bits in a field to be analyzed from a high speed frame of serial bits, in response to the detection of an event.

This invention relates to invention disclosure BT8-93-0054 and it also relates to the Event Driven Interface described in the above cited patent application Ser. No. 08/024,575. The figure shows an example field of information which is a frame as for example in a token ring LAN. The frame includes a beginning portion 12, a length field 26, whose value determines the length of a routing field 22 in the frame 10.

The problem to be solved is how to trap the contents of any field for subsequent analysis. This is done by means of the Event Driven Interface (EDI) 18 shown in the figure. The EDI 18 will perform pattern recognition in the manner described in the above cited patent application by Hershey, et al. The EDI 18 will recognize the pattern of an event and will activate a gate 28 to store the contents of the field in a capture buffer 30. A length value can be loaded as a count in a counter which will determine the number of subsequent bits which are to be loaded into an capture buffer 30 from the incoming serial bit stream from the network.

In accordance with the invention, the EDI 18 will continue to perform pattern matching as required, until the value in the length field 26 has been reached in the counter counting the bits being loaded into the capture buffer 30. Then, the EDI 18 can issue a signal which will dump the contents of the capture buffer 30 as a part of an event vector E(i) which is being formulated for the pattern recognition operation by the EDI in an event buffer 33, and that event vector can be transmitted to an expert system 34 for the appropriate analysis.

Thus, the event vector E(i) which is produced by the EDI 18, and which is sent to the expert system for analysis, can have two different parts; a first part 36 is the accumulated counts of the respective patterns detected by the EDI, and a second part 38 is the trapped data from the input data stream which was captured by the capture buffer 30. In this manner, a detailed analysis of the contents of an information field, for example the information field 14, can be analyzed in the expert system, along with the heuristic information from the counters counting the patterns in the network. This information can be used as a basis to control the network. For example if invalid account numbers are detected in the data bits, then the address of the data's origin as well as the invalid account number can be used in a message to a network control location. Alternately, a special frame can be sent to the origin of the data to force it to stop transmitting (i.e., a token ring "death frame" which forces device adapters to disconnect from the ring).

One potential usage of this particular invention is the ability to be able to trace activity on network links in realtime without the need to post-process data and without having extensive amounts of memory required to accomplish this process. The EDI mechanism provides a super efficient way of identifying specific events that we may wish to capture data on. By capturing data we mean, capturing some amount of bits from the media either predefined amount of bits or bits that are defined from the information on the data media itself. In other words, using something similar to indirect addressing Ser. No. 08/024,542, filed Mar. 1, 1993, and we can refer to another invention disclosure on that. For example, if you look at current trace techniques today, they usually trace the header as well as the customer's data that's embedded in a frame. The efficiency of the architecture such as SNA for example, says that when a customer has a lot of data to send the header represents only a few percentage points of the total amount or total volume of data transmitted, where the customer's data or the pay load of the frame represents 90 to 95 percent typically of the data flowing over the media. Currently today, most programs try to capture as much as they possibly can from the media, which means including the header and customer data. With this invention disclosure, we're enabling you to, in realtime, identify the header and trace only the header, in which case you can reduce the amount of data collected typically by 95 percent. In other words, a 95 percent reduction in the amount of data that's actually collected and returned to a location. Also, the same technique can be carried to even finer levels of detail and granularity by the EDI identifying that a specific event occurs, in which case we can capture specific fields, specific bytes or even specific bits of information and return only that to some location in the network to either reconstruct something of a flow of data over a period of time, or to do some kind of analysis or control the network environment. This data capturing facility invention coupled with the EDI provides us with extreme selectivity of the data that we capture from individual bits up to as much data as it goes across the media as you want.

The location of the ICA device in the network can be critical to achieving meaningful performance results. For example, assume that one wishes to use a single ICA device to measure performance for an IEEE 802.5 token ring network [1]. FIG. 3 depicts a possible ICA device location for this example. If the selected performance measure requires parameters such as Address Not Recognized, Not Frame Copied, Source Address, and Destination Address, then different results will be obtained depending on the location of the ICA device relative to the input or output of the network adapter within the ICA host station. If one wishes to assess the utilization of the token ring network, one possible utilization measure requires token rotation count as the only parameter that needs to be collected. For this example the ICA device location does not affect the results. For some applications, it can be useful to have one ICA device at the adapter input and one ICA device at the adapter output. Alternatively, we could design a dual ICA adapter to collect information at both the adaptor input and output.

Consider the example of simultaneously collecting data from multiple networks and protocols such as IEEE 802.5 [1], CSMA/CD [2], and FDDI [3], [4]. Ser. No. 08/187,950, filed Jan. 26, 1994 Disclosure BT993037 describes the use of the ICA for this scenario. Then the proper location of the ICA device would be in the bridge, router, or hub as shown in 4.

Because not all network data passes through these higher layer devices, a better approach would be to locate an ICA device within each network and have the ICA device located at the hub monitor the ICA devices. An advantage of this ICA hierarchy is that rather than requiring one ICA device with enormous memory, we can distribute the data collection task amongst numerous ICA devices. Each of these devices requires less memory, and in fact could be a generic device applicable to all locations. FIG. 5 shows a possible ICA hierarchy.

1. IEEE Standard 802.5, Token Ring Access Method, New York, N.Y., 1989.

2. ISO/IEC 8802-3, ANSI/IEEE Std 802.3, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, New York, N.Y., 1992.

3. ANSI, Inc., ANSI Standard X3.139, Fiber Distributed Data Interface (FDDI) Token Ring Access Control (MAC), New York, N.Y., 1987.

4. ANSI, Inc., ANSI Standard X3T9/90-X3T9.5/88-139, Fiber Distributed Data Interface (FDDI) Media Access Control (MAC-2), New York, N.Y., Oct. 1990.

Although a specific embodiment of the invention has been disclosed, it will be understood by those having an extraordinary skill in the art, that changes can be made to that specific embodiment without departing from the spirit and the scope of the invention.