+

WO1998006200A1 - Analyseur de protocoles destine a la surveillance de reseaux de transmission numerique - Google Patents

Analyseur de protocoles destine a la surveillance de reseaux de transmission numerique Download PDF

Info

Publication number
WO1998006200A1
WO1998006200A1 PCT/US1997/009685 US9709685W WO9806200A1 WO 1998006200 A1 WO1998006200 A1 WO 1998006200A1 US 9709685 W US9709685 W US 9709685W WO 9806200 A1 WO9806200 A1 WO 9806200A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
frames
information
protocol
displaying
Prior art date
Application number
PCT/US1997/009685
Other languages
English (en)
Inventor
Craig D. Anderson
Mark B. Anderson
Ralph A. Daniels
Lee E. Wheat
Roger A. Lingle
Eugene N. Cookmeyer
Original Assignee
Wandel & Goltermann Technologies, 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 US08/742,093 external-priority patent/US5850388A/en
Application filed by Wandel & Goltermann Technologies, Inc. filed Critical Wandel & Goltermann Technologies, Inc.
Priority to AU34765/97A priority Critical patent/AU3476597A/en
Publication of WO1998006200A1 publication Critical patent/WO1998006200A1/fr

Links

Classifications

    • 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/18—Protocol analysers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324—Display of status information
    • G06F11/328—Computer systems status display
    • 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/02—Capturing of monitoring data
    • H04L43/022—Capturing of monitoring data by sampling
    • 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/02—Capturing of monitoring data
    • H04L43/028—Capturing of monitoring data by filtering
    • 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/06—Generation of reports
    • 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/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0847—Transmission error
    • 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/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894—Packet rate
    • 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
    • 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
    • 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/16—Threshold monitoring

Definitions

  • the present invention relates generally to the field of computer and data communications networks and systems and more particularly to protocol analyzers for monitoring and analyzing digital transmission networks.
  • WANs Wide area computer networks
  • Distributed computing resources such as personal computers, workstations, servers and printers
  • LANs Local area networks
  • LANs allow increased productivity and utilization of distributed computers or stations through the sharing of resources, the transfer of information and the processing of data at the most efficient locations.
  • network applications such as electronic mail, file transfer, host access and shared databases have been developed as means to increase user productivity. This increased sophistication, together with the growing number of distributed computing resources, has resulted in a rapid expansion in the number of installed LANs.
  • network topologies or “networks”
  • Ethernet a LAN that employs a bus topology where the computing resources are connected to a single cable
  • Token Ring a LAN that employs a ring topology where the computing resources are connected to a single closed loop cable
  • FDDI Fiber Distributed Data Interface
  • ATM Asynchronous Transfer Mode
  • Digital data are usually transmitted over a network in frames (also referred to as “data frames” or “packets”) which can be of fixed or variable length depending upon the number of bits in the data portion of the frame.
  • Frames usually have headers (e.g., addresses) and footers on the two ends of the frame, with the conveyed data bits being in the middle.
  • headers e.g., addresses
  • footers on the two ends of the frame, with the conveyed data bits being in the middle.
  • the structure of a frame is discussed in more detail below in the section entitled Frame Analysis.
  • the nature and content of the headers and footers are usually dictated by the type of network.
  • Each layer in one network computer carries on a conversation with the corresponding layer in another computer with which communication is taking place, in accordance with a protocol defining the rules of communication.
  • information is transferred down from layer to layer in one computer, then through the communication channel medium and back up the successive layers in the other computer. To facilitate understanding, however, it is easier to consider each of the layers as communicating with its counterpart at the same level, in a horizontal direction.
  • the hierarchy of network layers is illustrated in Figure 1.
  • the highest network layer is the Application Layer 7. It is the level through which user applications access network services.
  • the Presentation Layer 6 translates data from the Application Layer 7 into an intermediate format and provides data encryption and compression services.
  • the Session Layer 5 allows two applications on different computers to communicate by establishing a dialog control between the two computers that regulates which side transmits, when each side transmits, and for how long.
  • the Transport Layer 4 is responsible for error recognition and recovery, repackaging of long messages into small packages of information, and providing an acknowledgment of receipt.
  • the Network Layer 3 addresses messages, determines the route along the network from the source to the destination computer, and manages traffic problems, such as switching, routing, and controlling the congestion of data transmissions.
  • the Data Link Layer 2 packages raw bits into logical structured packets or frames.
  • the Physical Layer 1 is responsible for transmitting bits from one computer to another by regulating the transmission of a stream of bits over a physical medium. This layer defines how the cable is attached to the network interface card within the station computer and what transmission technique is used to send data over the cable. As a message is passed down through the layers, each layer may or may not add protocol information to the message.
  • Network performance can suffer due to a variety of causes, such as the transmission of unnecessarily small frames of information, inefficient or incorrect routing of information, improper network configurations and superfluous network traffic.
  • Specific network hardware and software systems may also contain design flaws which affect network performance or limit access by users to certain of the resources on the network.
  • Network analyzers monitor the digital traffic or bit stream so as to identify and examine principally the headers and footers of each frame in order to analyze the health of the digital network. Hence, they are often called network protocol analyzers. The period of time during which a network is being analyzed is referred to as a "network monitoring session.” Typically, protocol analyzers are designed to identify, analyze and resolve interoperability and performance problems across the principal configurations of LAN and WAN topologies and protocols.
  • the protocol analyzers enable computer network users to perform a wide variety of network analysis tasks, such as counting errors, filtering frames, generating traffic and triggering alarms.
  • digital network transmission protocol analyzer instruments There are many examples of digital network transmission protocol analyzer instruments.
  • One such example is shown in U.S. Patent No. 4,792,753, granted to Iwai on December 20, 1988.
  • Another digital network transmission protocol analyzer directed particularly to Token Ring networks, collects several types of information about a network, including statistics, events, and network attributes by analyzing sequences of control frame transmissions and is shown in U.S. Patent No. 5,097,469, granted to Douglas on March 17, 1992.
  • Many of the protocol analyzer instruments are combined with user interfaces having display and keyboard and/or other input capability. The generation and display of certain message traffic characteristics are addressed in U.S.
  • U.S. Patent No. 4,775,973, granted to Toberlin, et al.. on October 4, 1988 discloses a method and apparatus for monitoring protocol portions of digital network transmissions and displaying a matrix of traffic from transmitting stations and to destination stations.
  • U.S. Patent No. 5,375,126 granted to Wallace on December 20, 1994 discloses a system for testing digital data telecommunication networks, with display of fault analysis, comparative viewing of fault-free benchmark data and with provision to offer suggestions as to probable causes of faults. In the network communications monitor of U.S. Patent No.
  • Protocol analyzers are produced in two general types. One is larger, less portable and more comprehensive in the scope of tests which it can perform. This type is used primarily by developers and manufacturers of network systems. The other type is smaller, more portable, and often easier to operate and lower-priced, albeit often with some limitations as to the scope of its testing capability. This latter type of protocol analyzer is produced primarily for field service technicians who maintain computer network systems.
  • a protocol analyzer's monitoring, diagnostic and problem resolution activities are usually under software control. Such software control is exercised by a main central processing unit (CPU), which is usually one or more microprocessors contained within the protocol analyzer itself.
  • CPU central processing unit
  • the protocol analyzer may also utilize a separate computer controller, such as a "laptop,” to facilitate human interface.
  • the software which protocol analyzers use may be characterized as expert system software which facilitates isolation of problems on a network being analyzed.
  • This expert system software may be contained in the protocol analyzer's internal memory or in the separate computer controller.
  • protocol analyzers of the prior art provide reasonable diagnostic capability, they do not guide the field technician through event analysis and the appropriate solutions. In general, these limitations combine to prevent effective guidance to the field technician in actually analyzing and solving the network problem.
  • the operation of a protocol analyzer includes one or more of the following: monitoring, in real time, the transmission of data packets having protocol portions and data portions; identifying the protocol portions of said packets in real time; analyzing, in real time, the protocol portions of said packets to ascertain relevant information; storing said information to a database in real time; sorting said information in real time, according to station level parameters; statistically analyzing said sorted information in real time to obtain statistical information; displaying said statistical information in real-time reports, displaying said statistical information in report formats selected by an operator; displaying real time performance of the network simultaneously with baseline network performance; simultaneously displaying statistical information gathered from a plurality of protocol analyzer instruments; pre-programming the monitoring of the transmission of data packets wherein the operator may select the duration of the network monitoring session; monitoring in real time one or more selected and assorted network parameters and comparing the results of said analysis with arbitrary threshold values for said parameters to determine if the transmission on the network is exceeding said threshold so as to constitute an event; analyzing
  • the operation of a protocol analyzer includes one or more of the following: monitoring, in real time, the transmission of data packets having protocol portions and data portions; identifying the protocol portions of said packets in real time; analyzing, in real time, the protocol portions of said packets to ascertain relevant information; storing said information to a database in real time; sorting said information according to protocol distribution criteria; statistically analyzing said sorted information; and displaying said statistical information.
  • the operation of a protocol analyzer includes one or more of the following: monitoring, in real time, the transmission of data packets having protocol portions and data portions; identifying the protocol portions of said packets in real time; analyzing, in real time, the protocol portions of said packets to ascertain relevant information; storing said information to a database in real time; sorting said information according to ISO layer; sorting said information according to protocol sub-families; statistically analyzing said sorted information; and displaying said statistical information in a protocol-tree format.
  • This and other objects of the present invention are achieved by use of a RISC (Reduced Instruction Set Computer)processor to analyze the protocol portion of each frame, in real time, followed by contemporaneous statistical analysis of the RISC (Reduced Instruction Set Computer)processor analysis of the protocols of several successive frames, followed by substantially simultaneous storage and display of the statistical analysis results.
  • RISC Reduced Instruction Set Computer
  • This and other objects of the present invention are achieved by use of an object oriented database and object oriented application programming to access said object oriented database.
  • This and other objects of the present invention are achieved by recognizing, in a protocol analyzer instrument, the occurrence of an event, periodically polling the protocol analyzer instrument for, among other information, a record of events that occurred since the last polling, transmitting, to a user interface, a message containing information about the events that occurred since the last polling, receiving the new event information in an event target ("target" is a term used to identify a software device to which data can be sent for storage, forwarding, or processing), storing the new event information in an event log object in an event log database class, informing a document of receipt of new event information, the document informing an event log view of receipt of new information, obtaining confirmation of new event log information and a pointer thereto in the database, and incorporating the new event information into a display of event log information.
  • target is a term used to identify a software device to which data can be sent for storage, forwarding, or processing
  • Figure 1 is an illustration of the hierarchy of network protocol layers
  • Figure 2 is a diagram describing the structure of an Ethernet data frame
  • Figure 3 is a diagram which illustrates the flow of data, analysis, and control in accordance with the present invention
  • Figure 4 is a flowchart illustrating the process by which statistics for individual stations on a network (station-level statistics) are calculated;
  • Figure 5 is a diagram illustrating the structure of an entry in the protocol distribution array within a digital memory
  • Figure 6 is a diagram illustrating the structure of the message for a protocol distribution update
  • Figure 7 is a flowchart illustrating the method by which protocol distribution is calculated
  • Figure 8 is a flowchart illustrating the method by which the Network Statistic "Network Frames Received" is calculated
  • Figure 9 is a flowchart illustrating the method by which Network Statistic "Analyzer Frames Received" is calculated; Figure 10 is omitted;
  • Figure 11 illustrates the structure of an entry in the Event Log Array
  • Figure 12 illustrates the structure of an Event Update Message
  • Figure 13 illustrates the structure of a Network Statistics Update Message
  • Figure 14 illustrates the structure of the user interface
  • Figure 15 is a scenario diagram for a station-level statistics update
  • Figure 16 is a scenario diagram for a network statistics update
  • Figure 17 is a scenario diagram for a protocol distribution update
  • Figure 18 is a scenario diagram for an event update
  • Figure 19 illustrates the visual appearance of an example of a split-screen display of station- level statistics
  • Figure 20 illustrates three examples of the appearance of chart display formats for network level statistics
  • Figure 21 illustrates an example of the appearance of a split-screen display of protocol distribution
  • Figure 22 illustrates the appearance of a display screen listing of events.
  • Ethernet is intended only to provide consistency in order to facilitate understanding and is not meant to indicate a limitation of the suitability of the present invention for analyzing other network topologies such as token ring, FDDI, frame relay, etc. II. Overview of the Implementation of the Invention
  • the preferred embodiment of the present invention comprises a hardware implementation and a software implementation.
  • the software implementation of the present invention performs two functions. The first is to perform meaningful statistical calculations on the protocol information retrieved from the network. The portion of the software implementation responsible for performing these calculations will be referred to hereinafter as the "embedded code.”
  • the second function performed by the software implementation of the invention is to provide the software with means for interaction between the protocol analyzer and the operator. Such interaction includes the displaying of the data calculated by the embedded code as well as responding to operator commands.
  • the portion of the software implementation which performs this function will hereinafter be referred to as the "user interface" or "UI.”
  • the user interface is preferably coded in the Microsoft Visual C++ programming language produced by Microsoft Corporation at One Microsoft Way, Redmond, WA 98052-9953, and operates in the Microsoft Windows 3.1 and Microsoft Windows 95 operating systems, also produced by Microsoft Corporation.
  • the hardware implementation of the present invention likewise performs two functions. First, it provides a physical platform for execution of the embedded code and for interfacing with the network being monitored. This portion of the hardware implementation of the invention will hereinafter be referred to as the "protocol analyzer instrument.”
  • the present invention may comprise a plurality of protocol analyzer instruments (see FIG. 3), each having at least one RISC processor and each monitoring a different network or segment of a network or monitoring the same network or segment but at a different port or station on the network.
  • the second function performed by the hardware implementation is to provide the physical means for the operation of the user interface.
  • Such means include input devices (such as a keyboard, a mouse, a trackball, etc.) and a display device (such as a cathode ray tube monitor or a liquid crystal display).
  • this second function is performed by a laptop personal computer (PC) containing an Intel 80486 or Pentium processor operating at 25 MHz or faster, preferably eight megabytes or more of random access memory, a hard disk drive with at least about forty-five megabytes of free disk space, a 3.5 inch floppy disk drive, a bi-directional parallel communication port, a keyboard, and a pointing device such as a trackball, joystick, or mouse.
  • PC personal computer
  • the PC is connected to one or more protocol analyzer instruments through the PC's parallel communication port.
  • the software implementation (both the embedded code and the user interface) of the invention is stored in a storage device (such as a hard disk drive, a magnetic tape drive, or other similar medium) on the PC.
  • a storage device such as a hard disk drive, a magnetic tape drive, or other similar medium
  • an initialization process takes place in which the embedded code is downloaded from the PC's storage device through the parallel communication port to the protocol analyzer instrument(s).
  • the protocol analyzer instrument can be similar to the hardware implementations of conventional protocol analyzers. See US Patent No. 4,792,753 (mentioned above).
  • the protocol analyzer instrument is a DominoLAN DA-320 Internetwork Analyzer manufactured by Wandel &
  • DominoLAN is a trademark of Wandel & Goltermann Technologies
  • the protocol analyzer instrument preferably comprises two hardware modules, a network interface (NI) module and a protocol analysis (PA) module which preferably occupy the same convenient physical cabinet.
  • NI network interface
  • PA protocol analysis
  • Each module is controlled by its own INMOS T425 transputer processor operating at 25 MHz and using a 32-bit word RISC (Reduced Instruction Set Computer) architecture ("RISC processor"), manufactured by SGS Thompson Corporation, INMOS, Ltd., 1000 Aztec West, Almondsbury, Bristol. BS 12 4SQ, UK.
  • RISC processor Reduced Instruction Set Computer
  • RISC processors are responsible for execution of the embedded code when the protocol analyzer instrument is in use.
  • a processor with a limited instruction set such as a RISC processor, results in increased processing speed.
  • This increased processing speed allows both the NI and PA modules of the protocol analyzer instrument to perform real time analysis of the network transmissions.
  • the preferred embodiment utilizes RISC processors to achieve the desired processing speed, alternatives such as the Intel 960 processor manufactured by Intel Corporation, 2200 Mission College Blvd.. Santa Clara, California 95052; and the PowerPC processor manufactured by Motorola. Inc.. P.O. Box 20912, Phoenix Arizona 85036, will be readily apparent to a person having ordinary skill in the art. The scope of the invention, therefore, should not be limited to the description of the preferred hardware implementation contained herein.
  • the NI module is preferably equipped with 512 kilobytes of static random access memory (SRAM), while the PA module preferably has four megabytes of dynamic random access memory (DRAM) and is expandable to sixteen megabytes.
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • the preferred protocol analyzer instrument also contains a LAN card printed circuit pack (part number 82C581 ), which conprises two LAN chips (part number 82C585), purchased from 3Com ⁇ Address, etc. ; info requested
  • PowerPC is a registered trademark of International Business Machines Corporation. from Jim Brewer via e-mail> and a plurality of hardware counters used to count the number of frames and bytes detected on the network.
  • FIG. 3 illustrates an overview of the flow of information about the operation of a network 301.
  • Data-bearing frames (see FIG. 2) are transmitted over the Network 301 and are received and analyzed by Embedded Code 302 executed by a Protocol Analyzer Instrument 304 using its one or more RISC processors 314 and hard-wired analyzer circuits within the Protocol Analyzer Instrument.
  • the results of that protocol analysis are then available to be sent, as commanded by the user, to a software-based User Interface 303 running on the PC 305 for storage and presentation to the user.
  • the User Interface 303 also passes the user's commands (e.g., network parameters to be monitored, sampling rate, etc.) to the Embedded Code 302.
  • Figure 3 also illustrates that the PC 305 contains a mass memory device 317, sometimes referred to as a direct access storage device.
  • This is the hard disc drive of the preferred embodiment of the PC 305 that is used, inter alia, to implement the preferred embodiment of the present invention.
  • the User Interface 303 works with a POET object-oriented database program 310 selectively to store, on the mass memory or hard drive 317, the results of the analyses that are performed by the Protocol Analyzer Instrument 304 and which are then periodically uploaded to the PC 305.
  • the format of a data frame varies slightly depending on the network type (i.e. token ring network, ethernet, etc.) but the analysis of the frame is basically the same.
  • the format of an ethernet network data frame is illustrated in Figure 2.
  • the frame begins with an eight-byte Preamble field 208 which is used for synchronization. This is followed by the Destination address 209 (the address of the station which is to receive the data frame). Next is the Source address field 210 (the address of the station which sent the data frame).
  • the address fields contain the Medium Access Control ("MAC") addresses of the source and destination stations.
  • the MAC address is a unique address hard wired into the station's network interface card (NIC). Each address field is six bytes in length.
  • the Type field 211 which follows the address information, is a two-byte field that specifies the higher layer protocol used in the Data field.
  • the Data field 212 which is the only variable-length field, is next and ranges from 46 to 1500 bytes. It contains the higher level protocols currently in use as well as the data being transmitted.
  • Last is a four-byte Frame Check Sequence ("FCS") field 213, which is used for error detection.
  • FCS Frame Check Sequence
  • frame length refers to the total number of bytes contained in the frame less the number of bytes in the Preamble 208. The contents of each field are identified by the embedded code executed on the protocol analyzer instrument. The exact method by which relevant information is extracted from a frame would be readily apparent to a person having ordinary skill in the art of programming software for protocol analyzers.
  • frame analysis is performed by the embedded code executed by the protocol analyzer instrument.
  • the protocol analyzer instrument which preferably contains two RISC processors
  • the analysis of the frames can be accomplished in real-time.
  • the contents of each frame received during a network monitoring session are temporarily stored in the memory located on the protocol analyzer instrument.
  • the portion of this memory which stores the contents of received frames will be referred to hereinafter as the "capture buffer.”
  • the frames stored in the capture buffer will be referred to hereinafter as “captured frames.”
  • the contents of the capture buffer are continuously updated. When the buffer is filled, the oldest captured frames are discarded and replaced with newly captured frames.
  • Filtering is the process by which the user can select certain types of frames to be analyzed.
  • the user can specify certain parameters that frames must meet before the frames are sent to the NI module.
  • Filtering is preferably accomplished using a hardware filter, contained within the NI module, such as the filter disclosed in a copending U.S. patent application serial number 08/384,855, filed on February 7, 1995, in the name of Bradley Anderson, which is incorporated by reference to the same extent as if fully reproduced herein.
  • the hardware filter compares incoming bit sequences to the bit sequence which corresponds to the user-defined parameters and only frames containing bit sequences which match the bit sequence corresponding to the user defined parameters are sent to the NI module of the protocol analyzer instrument. These frames are the only frames which are analyzed.
  • only frames addresses to station A are to be analyzed and/or only frames transmitted by station B are to be analyzed.
  • Station-level statistics such as, but not limited to, number of bytes transmitted, number of frames transmitted, number of bytes received, number of frames received, and total number of errors generated by that station are all calculated by the embedded code running on the protocol analyzer instrument.
  • station-level statistics for each station operating on the network are calculated, they are stored in an array called the "station list array" in the memory of the protocol analyzer instrument.
  • An array is a data structure used to store data. Many other data structures, which can also be used to store data, are well known to persons having ordinary skill in the art of programming. The use of the term "array" throughout this specification is not meant to be limited strictly to arrays; because, many of these other data structures would also suffice.
  • the station list array contains: the station address, traffic statistics (bytes received, bytes transmitted, frames received, and frames transmitted, etc.), and error statistics for each station which is or has been active on the network during the network monitoring session.
  • the type of error statistics calculated will vary depending on the type of network.
  • FIG. 4 illustrates the process by which station-level statistics are calculated for an ethernet network.
  • Station-level statistics which are unique to other network topologies, such as FDDI, Token Ring, frame relay, etc., are calculated in a manner which is analogous to the process described below.
  • receipt of a frame is recognized at programming step 402 by the protocol analyzer instrument.
  • the address information of each frame is used preferably to identify the destination address at programming step 403 and to identify the source address at programming step 404 for each data frame sent over the network.
  • the destination address portion 209 (see FIG. 2) of the frame is identified, and the bytes contained in that portion of the frame are examined in order to ascertain the destination station to which the frame has been addressed.
  • the source address portion 210 of the frame is identified, and the bytes contained in that portion of the frame are examined in order to ascertain the source station from which the frame was sent.
  • the next step in the calculation of station-level statistics is programming step 405 in which the value of the Frame Check Sequence ("FCS") field 21 is identified in programming step 405.
  • FCS Frame Check Sequence
  • the FCS is contained in the last four bytes of the frame.
  • the FCS is a four-byte cyclic redundancy check ("CRC") or checksum which is calculated by the source station.
  • the source station calculates the FCS by performing a well-known mathematical function on the bits in the Destination 209, Source 210, Type 21 1. and Data 212 fields of the frame.
  • the FCS is used for purposes of error detection.
  • the length of the frame is preferably determined in programming step 406 by summing the total number of bytes in the Destination 209, Source 210, Type 211, Data 212 and FCS 213 fields.
  • the next step 407 is to determine whether there is an entry corresponding to the destination address of the frame in the station list array in the memory of the protocol analyzer instrument. If that particular destination station has previously received or sent any frames during the network monitoring session, there will be an entry corresponding to that destination station's address in the station list array. If that destination station has not yet received or sent any frames during the network monitoring session, there is no entry for that destination address in the station list array. If there is no entry corresponding to that particular destination address in the station list array, an entry corresponding to that destination address is created by programming step 408. The frames_received array variable of the station list array entry corresponding to the destination address is incremented by one at the programming step 409.
  • an underscore within a term denotes a variable name as opposed to a value or definition.
  • an array is a memory structure.
  • the bytes received array variable of the station list array entry corresponding to the destination address is incremented in step 410 by the frame length of the current frame.
  • the step 411 determines whether there is an entry corresponding to the source address of the frame in the station list array. If the source station has previously received or sent any frames during the network monitoring session, there will be an entry corresponding to the source station's address in the station list array. If the source station has not yet received or sent any frames, there is no entry for the source address in the station list array. If there is no entry corresponding to the source address in the station list array, an entry corresponding to the source address is created by step 412.
  • the frames transmitted array variable of the station list array entry corresponding to the source address is incremented by one at programming step 413.
  • the bytes transmitted array variable of the station list array entry corresponding to the source address is incremented by the frame length of the current frame in step 414.
  • the next steps involve updating the error statistics array variable of the entry in the station list array corresponding to the source address.
  • the error statistics array variable is actually a subarray whose length depends upon the number of types of errors detected for the particular network topology. It contains the error id and the number of errors for each type of error detected for the corresponding station.
  • the error id is an arbitrary, predefined code which represents one of several types of errors that the protocol analyzer instrument is equipped to
  • the first step 415 in updating the error statistics subarray of the entry in the station list array corresponding to the source address of the current frame is to determine whether the length of the current frame is greater than the maximum 1518 bytes permitted in an Ethernet frame. Such overly-long frames are commonly referred to as jabbers. Jabbers originate from a source station that will not stop transmitting. If a frame's length is greater than 1518 bytes, it is likely that the source station is defective. If the current frame is a jabber, the error statistics subarray of the entry in the station list array corresponding to the source address is updated accordingly at programming step 416.
  • Step 417 determines whether the frame length of the current frame is less than 64 bytes.
  • Runts are short frames which may also indicate that the source station is defective. If the current frame is a runt, the error statistics subarray of the entry in the station list array corresponding to the source address is updated accordingly in step 418.
  • Programming step 419 determines whether the current frame is byte-aligned.
  • a frame is said to be byte aligned if the frame size in bits is evenly divisible by eight.
  • the frame size is said to be equal to frame length (expressed in bits) plus the length of the preamble
  • the determination of whether a frame is byte-aligned is done by the LAN chip on the protocol analyzer instrument (mentioned above under Protocol Analyzer Instrument! If the current frame is not byte aligned, an alignment error has occurred.
  • the error statistics subarray, of the entry in the station list array corresponding to the source address, is updated accordingly by programming step 420.
  • the source station calculates the FCS by performing a mathematical function on the bits in the Destination, Source, Type, and Data fields of the data frame.
  • the LAN chip also discussed above, performs the same mathematical function and compares the results to the contents of the FCS. If the two do not match, an FCS error has occurred, indicating that the frame is corrupt.
  • Step 421 examines the results of that calculation and comparison by the LAN chip in order to determine whether one or more bits of the current frame may have been corrupted in transmission.
  • the error stati sites subarray of the entry in the station list array corresponding to the source address is updated accordingly in step 422.
  • the final step involves transmitting the information stored in the station list array to the PC for use by the user interface. This transmission is facilitated through the use of a "message,” which is the preferred method of communication among the various hardware and software components of the preferred embodiment of the present invention.
  • the message for station-level statistics consists of a header and the contents of the station list array.
  • the header identifies the destination for the message and the type of message, in much the same format as the messages illustrated in Figures 6, 12, and 13. In this case, the message would be a station-level statistics update message.
  • the contents of the station list array are placed in the message in the order in which they were initially placed in the station list array.
  • UI User Interface
  • the message is sent from the protocol analyzer instrument to the PC for use by the user interface.
  • Network Statistics Statistics based upon network performance as a whole will be referred to hereinafter as "network statistics.” Network statistics are calculated by the embedded code running on the protocol analyzer instrument. Network statistics may be cumulative (calculated over the entire network monitoring session, which might typically be a twenty-four-hour period) or per sampling period (calculated over a sampling period specified by the user, which might typically be a one-second period).
  • Network statistics may also vary somewhat between the various network topologies.
  • network statistics calculated for an ethernet network include number of Network Frames Received, Network Frame Rate, number of Analyzer Frames Received, Analyzer Frame Rate, Peak Analyzer Frame Rate, Peak Frame Rate Timestamp, Average Frame Rate, Average 32-Second Frame Rate, Utilization. Average Utilization, Peak Utilization, Peak Utilization Timestamp, number of Broadcast Frames Received, number of Multicast Frames Received, Frame Size Distribution-Cumulative. Frame Size Distribution-Sample, number of Network Collisions, number of Alignment Errors and the numbers of Jabber, Runt, and FCS Errors. Each of these statistics is discussed below.
  • the number of Network Frames Received is calculated by a hardware counter on the protocol analyzer instrument.
  • the protocol analyzer instrument detects receipt of a network frame in programming step 802.
  • the hardware counter is connected directly to the network line and is able to count every frame traveling over the network, i.e. Network Frames Received. For each frame detected, the hardware counter is incremented in step 803. This process is repeated until the sampling period has expired, step 804.
  • the network monitoring session ends at some point after or to coincide with the expiration of a sampling period.
  • the number of Network Frames Received is then obtained from the hardware counter by the Embedded Code software in the protocol analyzer instrument, step 805, for later uploading to the PC.
  • the Network Frame Rate is the number of Network Frames Received, preferably over a one second interval, as monitored by a hardware counter, and is calculated every second.
  • the NI module of the protocol analyzer instrument receives frames, these frames are transmitted to the PA module of the protocol analyzer instrument, where the frames are processed.
  • the Network Frame Rate is extremely high, some of the frames may not be sent to the PA module for processing. In this situation, some of the frames will still be counted as having been received by the NI module but may never be processed or analyzed by the PA module, see discussion above regarding Frame Analysis for a discussion of some of the types of frame analyses that may be performed by the PA module.
  • the user has the option of choosing to monitor only certain types of frames, see discussion above under Filtering.
  • all of the frames that are received by the NI module will still be counted as having been received, in order to arrive at the number of Network Frames Received.
  • only frames which meet the user-defined parameters are passed to the PA module. Therefore, in these situations when only selected types of frames are passed to the PA module for analysis, the number of frames actually sent to the PA module is different from the value of Network Frames Received.
  • the number of frames actually sent to the PA module is referred to as the Analyzer Frames
  • the Analyzer Frames Received are calculated by the program shown in FIG. 9. From the Start step 901, the PA module of the protocol analyzer instrument receives a frame from the NI module in step 902. Another hardware counter is incremented accordingly in step 903. The process is repeated until the sampling period has expired, step 904. The final count is then obtained by the Embedded Code from the counter in step 905 for later uploading by the PA module to the PC.
  • Analyzer Frame Rate is the number of Analyzer Frames Received, preferably over a one second interval and is calculated every second.
  • the highest frame rate (in frames per second) detected during the network monitoring session by the analyzer for any single sampling period and the time at which it occurred represents Peak Analyzer Frame Rate and Peak Frame Rate Timestamp.
  • the current Analyzer Frame Rate is compared to the Peak Analyzer Frame Rate. If the current Analyzer Frame Rate is greater than the Peak Analyzer Frame Rate, the Peak Analyzer Frame Rate is replaced with the current Analyzer Frame Rate. The Peak Frame Rate Timestamp is then replaced with the current time.
  • the Average Frame Rate is calculated in a manner similar to the Analyzer Frame Rate except that the Average Frame Rate is averaged over the time elapsed during the Network Monitoring Session rather than over one second.
  • the Average 32-Second Frame Rate represents the Average Frame Rate over the past 32 seconds as opposed to the entire Network Monitoring Session. Therefore, for the first thirty-one seconds of a monitoring session, there will be no value for Average 32-Second Frame Rate.
  • the Average 32-Second Frame Rate is recalculated every second on a rolling basis (the frame rate is averaged over the most recent thirty-two second time span).
  • the embedded code calculates Network Utilization every second in the following manner. First, the total number of bytes represented by the Preamble 208, Destination 209, Source 210, Type 211, Data 212 and FCS 213 fields of each frame (see FIG. 2) received during the second are summed. To this is added an additional twelve bytes for each frame received during a sampling period to represent quiet time. Quiet time is a 9.6 microsecond interval that follows each frame, during which no data are sent over the line. At a ten megabaud transmission rate, that 9.6 microseconds is equivalent to ninety-six bits or twelve eight-bit bytes. Therefore, quiet time is the equivalent of twelve byte times.
  • Average Utilization is an average of all Utilization values over the duration of the network monitoring session. Peak Utilization represents the highest percentage of network capacity used during the current session and Peak Utilization Timestamp represents the time at which the peak utilization was detected. For each sampling period, the current Utilization is compared to the Peak Utilization. If the current Utilization is greater than the Peak Utilization, the Peak Utilization is replaced with the current Utilization. The Peak Utilization Timestamp is then replaced with the current time.
  • Frame Size Distribution is the network statistic that represents the number of frames, classified by size range, that were received by the protocol analyzer instrument since the analyzer was started for the monitoring session (Frame Size Distribution-Cumulative) or during a specified sampling period (Frame Size Distribution-Sample).
  • Frame Size Distribution is calculated through the use of two memory arrays which store information on frame size distribution. One array stores frame size distribution on a cumulative basis and the other array stores frame size distribution on a sampling period basis. There are positions in both arrays corresponding to arbitrary size ranges (e.g. the value for the number of frames detected with lengths between 167 and 255 bytes is stored in position 2 of each array).
  • the above process is summarized as follows: The frame length of each frame (see Frame Analysis above) is examined. Next, the appropriate memory-array position of the cumulative array is incremented by one to reflect the occurrence of a frame in that particular size range. If the frame was detected during the sampling period, the appropriate array position of the sampling period array is also incremented by one.
  • the protocol analyzer instrument includes a commercially-obtained LAN chip.
  • the LAN chip is responsible for calculating Broadcast Frames Received, Multicast Frames Received and Network Collisions.
  • a broadcast frame is a frame sent from one station to all other stations on the network.
  • a broadcast frame's destination address contains an address (referred to as a "broadcast address”) that all other stations recognize as being addressed to them.
  • a multicast frame is a frame sent to a selected group of stations on a LAN.
  • a multicast frame contains an address (referred to as a "multicast address") that the selected group of stations recognize as being addressed to them.
  • the respective counter corresponding to either broadcast frames or multicast frames on the NI module is incremented by one. These counts represent the Broadcast Frames Received and Multicast Frames Received statistics.
  • CSMA/CD Carrier Sense Multiple Access/Collision Detection
  • An Ethernet station listens to the network to determine whether any traffic is present. When the network is clear, it transmits and then listens again to see if the data collides with traffic from any other station. If all is clear, the transmission is complete. If a collision occurs, the station waits a short, random amount of time and retransmits.
  • the LAN chip detects collisions by performing the standard CSMA CD algorithm when a frame is received. 1 f a collision is detected, a collision counter is incremented by one. This counter is pail of the LAN chip.
  • the present invention also calculates network-wide statistics for errors such as Alignment Errors, Jabbers, Runts, and FCS Errors (see Station Level Statistics above for detailed definitions of these errors). These errors are detected by the LAN chip on the protocol analyzer instrument in a manner similar to that described above.
  • Information on all network statistics are stored into an array ("network statistics array").
  • the information stored for each statistic varies depending on the type of statistic, but basically, the value of each statistic is stored into an array along with a timestamp.
  • the information stored in the network statistics array is sent to the PC for use by the user interface. This transmission is facilitated through the use of a message.
  • the structure of a network statistics update message is shown in Figure 13.
  • the message for network statistics consists of a header 1301 and the contents of the network statistics array 1302.
  • the header identifies the destination for the message and the type of message (network statistics update message in this case).
  • the contents of the network statistics array are placed in the message in the order in which they were initially placed in the network statistics array.
  • protocol distribution The distribution and percentage distribution of the various protocols present in data frames are hereinafter referred to as "protocol distribution".
  • the calculation of protocol distribution is performed by the embedded code executed by the protocol analyzer instrument.
  • Step 703 next determines the first protocol present in the frame received by the protocol analyzer instrument. For an ethernet frame, this is done by looking at the Type field 211 (see FIG. 2) of the frame.
  • the Type field 211 of an ethernet frame designates the first protocol present in the Data field 212 of the frame. If the Type field 211 contains a value greater than hexadecimal 500, the first protocol present is the Ethernet Version 2 (EthernetV2) protocol, otherwise the first protocol present is the IEEE 802.3 protocol. This first protocol (either the EthernetV2 protocol or IEEE 802.3 protocol) is found in the data portion 212 of the frame.
  • the protocol being decoded at any particular time is referred to as the current protocol.
  • the next step 705 involves storing information for the current protocol. Information on the current protocol is stored in a memory array. An entry in this array is shown in Figure 5 ("protocol distribution array entry") and contains: the protocoled 501, statistics_for_the_protocol 502, array_position 503, number of children 504, and a children_table 505. Each of these array variables is discussed below. Array information for a protocol is updated whenever that particular protocol is detected in a received frame.
  • the protocol distribution array is stored in the memory of the protocol analyzer instrument and is maintained for the duration of the network monitoring session.
  • the protocol id 501 array variable is a programmer defined, arbitrary number used by the embedded code to identify the current protocol.
  • the protocol id 501 is used to help identify the protocol in the protocol distribution array and has no relationship to the "next layer protocol identification field" defined above.
  • the "next layer protocol identification field” contains a value which is used to identify the protocol directly encapsulated within the current protocol. When this encapsulated protocol is placed into the array, it will be assigned a protocol id 501 distinct from the value which was in the "next layer protocol identification field" (the value used to initially identify the encapsulated protocol).
  • the statistics_for_the_protocol 502 includes four entries: (1 ) the number of frames received
  • the array_position 503 indicates the position, in the protocol distribution array, where the information on the current protocol is stored.
  • the number of children 504 for a particular protocol (the "parent") represents the total number of unique children detected for the parent protocol since the network monitoring session began.
  • a "child" of a parent protocol is any protocol which is encapsulated directly (immediately follows) within the parent.
  • the children table 505 is a subarray containing information for all of the children of the parent. This information includes the protocol id 506 of the child and the array_position 507 of the child.
  • the next step (step 706) in calculating protocol distribution is to determine if there is another protocol (the "next protocol") encapsulated within the current protocol. If there is a next protocol encapsulated within the data portion 212 of the current protocol or frame, there are two methods used to identify it.
  • Most protocols contain a "next layer protocol identification field" which is much like the Type field 211 of the Ethernet frame and contains a numerical identification code corresponding to the next protocol present in the frame (i.e., the protocol encapsulated directly within the first protocol).
  • the exact location and contents of the "next layer protocol identification field" within a protocol can vary depending on the standards for that type of protocol.
  • the IEEE 802.3 protocol is defined by the Institute of Electronics and Electrical Engineers' standard 802.3.
  • Step 707 determines whether the current protocol is conversation-dependent.
  • next layer protocol identification field is preferably used in conjunction with a lookup table in step 708A to identify the next
  • Step 707 the current protocol is a conversation-dependent protocol
  • the unknown next protocol encapsulated within the current protocol is detected in step 708B by comparing bit sequences of the unknown next protocol to known bit patterns from the protocols which can be encapsulated within the current protocol. These known bit patterns can be obtained by referencing the standard defining the protocol.
  • the UDP protocol is defined by Request for Comments (RFC) number 768, promulgated by the Institute of Electronics and Electrical Engineers.
  • the TCP protocol is defined by Request for Comments (RFC) number 793, promulgated by the Institute of Electronics and Electrical Engineers.
  • the known patterns are preferably contained in a lookup table which is used to map known bit patterns to corresponding protocols. As an example, if the current protocol is UDP. the bits in the unknown next protocol would be compared to bit patterns known to exist in the DHCP (Dynamic Host Configuration Protocol), BootP (Bootstrap Protocol), NetBIOS DGM (Datagram Protocol), RIP (Routing Information Protocol), RWHO (Remote Unix WHO Protocol). TACACS . SNMP (Simple Network Management Protocol) Version 2, and NTP (Network Time Protocol) protocols, all of which can be encapsulated within the UDP protocol.
  • DHCP Dynamic Host Configuration Protocol
  • BootP BootP
  • the protocol corresponding to the known pattern is deemed to be the unknown next protocol and is detected as such.
  • Step 706 The above processes are performed iteratively (due to Step 706) for each protocol present in the frame until all protocols present in the frame have been decoded. The entire process is repeated for all frames detected during the sampling period (step 709) or detected during the network monitoring session (step 711), as specified by the user. Upon the expiration of a sampling period, the statistics_for_the_protocol which are calculated per sampling period are reset in step 710.
  • the information stored in the protocol distribution array is transmitted to the PC for use by the user interface. This transmission is facilitated through the use of a message.
  • the structure of a protocol distribution update message is shown in Figure 6.
  • the message for protocol distribution consists of a header 601 and the contents of the protocol distribution array 602.
  • the header identifies the destination for the message and the type of message (protocol distribution update message in this case).
  • the contents of the protocol distribution array are placed in the message in the order in which they were initially placed in the protocol distribution array.
  • the message is sent from the PA module of the protocol analyzer instrument to the PC for use by the user interface.
  • the embedded code is also capable of detecting and logging "events" in real-time during network monitoring sessions.
  • An “event” occurs when a parameter being monitored on the network exceeds a predefined or user-defined threshold. That user-defined threshold can even be a number of occurrences on the network of some specific phenomenon, during a sampling period.
  • the threshold specifies a value (e.g. number of occurrences, in the case of parameters such as runts, jabbers, etc., or percentage, in the case of a parameter such as Network Utilization) per specified time period and the number of consecutive time periods for which the value must be exceeded to constitute an event.
  • Ethernet events detected include: High Utilization, High Frame Rate, High Broadcast Rate, High Multicast Rate, Network Collisions, Alignment Errors, FCS Errors, Runts, Jabbers, and Illegal Source Address. Events which are unique to other network topologies, such as FDDI, Token Ring, frame relay, etc., are detected in a manner which is analogous to the process for detecting ethernet events described below.
  • An Illegal Source Address error occurs when a frame containing an illegal MAC source address is received.
  • An illegal MAC source address field might contain all binary ones.
  • Such illegal MAC addresses can be caused by a malfunctioning network interface card ("NIC") or NIC driver, they can be artificially produced by some type of traffic generator, or they might be the result of a collision.
  • An Illegal Source Address event occurs when any Illegal Source Address error is detected by the protocol analyzer instrument (i.e., the threshold for this event is usually zero).
  • IP events include: Duplicate IP Address, Illegal Source IP Address, and Zeros Broadcast Address. The errors which are the bases of these events only occur if the IP "protocol" is currently in use. The presence, if any, of the IP “protocol” in a frame is detected during the protocol decode process described in detail above in Protocol Distribution.
  • the IP "protocol” contains a field identifying the IP Source Address. This field will be referred to as the "IP Source Address field.”
  • the IP “protocol” also contains a field identifying the IP Destination Address. This field will be referred to as the "IP Destination Address field.”
  • a Duplicate IP Address error occurs when two stations try to use the same network IP address.
  • IP station list A memory array or other data structure
  • MAC station list An array or other data structure
  • IP station list An array or other data structure
  • IP station list An array or other data structure
  • MAC station list is used to store information on MAC addresses.
  • An Illegal Source IP Address error occurs when the IP Source Address field of the IP "protocol" contains invalid data such as all zeros, a broadcast address, or a multicast address. This error is detected by analyzing the IP Source Address field of the IP "protocol.”
  • An Illegal Source IP Address event occurs whenever an Illegal Source IP Address error has been detected by the protocol analyzer instrument (i.e., the threshold for this event is also zero).
  • a Zeros Broadcast Address error occurs when a sending station has used all zeroes to represent a broadcast address in the portion (IP Destination Address) of the IP "protocol" containing the IP destination address. This error is detected by analyzing IP Destination Address field of the IP "protocol.” The IP Destination Address should be all ones when used to designate a broadcast address.
  • a Zeros Broadcast Address event occurs whenever the number of Zeros Broadcast Address errors detected by the protocol analyzer instrument exceeds the defined threshold defined for this event.
  • ICMP (Internet Control Message Protocol) events include: Host Unreachable, ICMP Redirect, ICMP Parameter Error, Network Unreachable, Port Unreachable, Source Quench, and Time-to-Live Exceeded.
  • the messages which are the bases of these events only occur if the ICMP "protocol" is currently in use.
  • the presence, if any, of the ICMP "protocol" in a frame is detected during the protocol decode process described in detail above in Protocol Distribution.
  • a Host Unreachable message (a network message not related to a "message" sent by the PA to the UI) is sent by a router to notify the sender of a frame that the router cannot forward that frame to the appropriate destination.
  • a router is a software or hardware connection between two or more networks that enables traffic to be routed from one network to another based upon the intended destinations of the traffic.
  • the appropriate field of the ICMP "protocol" is analyzed to determine whether a Host Unreachable message has been received.
  • a Host Unreachable event occurs when the number of Host Unreachable messages received by the protocol analyzer instrument exceeds the defined threshold for this event.
  • An ICMP Parameter Error is a message (another network message) indicating that a frame has been discarded due to a problem in its header portion.
  • the appropriate field of the ICMP "protocol" is analyzed to determine whether an ICMP Parameter Error message has been received.
  • An ICMP Parameter Error event occurs when the number of ICMP Parameter Error messages received by the protocol analyzer instrument exceeds the defined threshold for this event.
  • An ICMP Redirect message (also another network message) occurs when a sending station addresses a frame to a default router because it does not know any other route for that particular destination. If the default router sees that it must transmit the frame out of the same port on which it was received, the router sends the host an ICMP Redirect message advising the sending station of a better router for that destination. The appropriate field of the ICMP "protocol" is analyzed to determine whether an ICMP Redirect message has been received. An ICMP Redirect event occurs when the number of ICMP Redirect messages received by the protocol analyzer instrument exceeds the defined threshold for this event.
  • a Network Unreachable message (another network message) is sent from a router to the sender of a frame when the router does not have a route or a default route to which to forward the data frame.
  • the appropriate field of the ICMP "protocol" is analyzed to determine whether a Network Unreachable message has been received.
  • a Network Unreachable event occurs when the number of Network Unreachable messages received by the protocol analyzer instrument exceeds the defined threshold for this event.
  • a Port Unreachable message (another network message) is sent by a destination station to inform the source station that the port indicated by the source station is not currently in use by any process.
  • the appropriate field of the ICMP "protocol" is analyzed to determine whether a Port Unreachable message has been received.
  • a Port Unreachable event occurs when the number of Port Unreachable messages received by the protocol analyzer instrument exceeds the defined threshold for this event.
  • a Source Quench message (another network message) is sent, by a router or a host, stating that it is receiving so many data frames that its buffers are overflowing. The message is sent back to the source of the excess data frames instructing that source station to slow the flow of data.
  • the appropriate field of the ICMP "protocol" is analyzed to determine whether a Source Quench message has been received.
  • a Source Quench event occurs when the number of Source Quench messages received by the protocol analyzer instrument exceeds the defined threshold for this event.
  • a Time-to-Live Exceeded message is generated by a router which has received and discarded a transmission which has exceeded its allowable lifetime.
  • routing loops form between routers that cause a frame to be forwarded endlessly through the same set of routers over and over.
  • IP IP
  • the TTL field prevents such an occurrence.
  • TTL time-to-live
  • the router transmits a Time-to-Live Expired message back to the source to notify the source about the discard.
  • the appropriate field of the ICMP "protocol" is analyzed to determine whether a Time-to-Live Expired message has been received.
  • a T ime-to-Live Expired event occurs when the number of Time-to-Live Expired messages received by the protocol analyzer instrument exceeds the defined threshold for this event.
  • event log array As events are detected, information on the events including event id, timestamp, byte_length, and parameters are stored in a circular array (event log array).
  • Event log array information on the events including event id, timestamp, byte_length, and parameters.
  • Event_id 1101 is the variable name used to refer to the programmer-defined id code of the event.
  • Timestamp 1102 is the date and time at which the specific event occurred.
  • Byte length 1103 is the total number of bytes in the parameter 1104 portion of the array entry.
  • Parameter 1104 contains information on each event. This parameter information is used by the UI portion to construct a detailed event message for display or reporting of the event to the user. For example, if the error was Duplicate IP Address Detected, there would be three parameters, namely the MAC addresses of the two stations using the same IP address as well as the IP address itself.
  • the event update message contains a header 1201 and a portion of the event log array 1202.
  • the information sent from the event log array is the event id 1101, timestamp 1102, byte length 1103 and parameters 1104 for the entries in the event log array 1202 since the last update sent to the UI.
  • the user interface is the portion of the software implementation of the present invention that is executed by the PC.
  • the user selects which network parameters are to be monitored. Each of these parameters, including station-level statistics, network statistics, event information and protocol distribution is discussed in detail above.
  • the User Interface is capable of displaying any station-level statistic, network statistic, event information, and protocol distribution (discussed above) which the user requests to see and which the protocol analyzer instrument can capture and report to the UI.
  • Figure 14 illustrates the general structure of the user interface (UI).
  • the UI sends request messages to the Embedded Code 302 seeking update information about the various network parameters ("network information").
  • a message is a preferred method of communication among the various hardware and software components of the present invention.
  • the message contains a header portion which identifies the destination for the message and the type of message (e.g., Network Statistics Request Message, Network Statistics Update Message, etc.).
  • the message also contains the data being transmitted (e.g., the updated network statistics themselves).
  • the user can select how often network information is updated, i.e. how often the UI requests updates from the embedded code on these parameters.
  • the operation of the UI is largely software controlled using custom software (the design of which is disclosed herein) and also uses off-the-shelf software tools.
  • the custom software is preferably designed using a technique known as "object-oriented programming" which is described in a text entitled Object Oriented Design with Applications, by Grady Booch, copyright 1991 , from Benjamin Cummings Publishing Co., Inc., Redwood City, California, which is incorporated by reference as though fully reproduced herein.
  • the portion of the UI software that is responsible for sending update request messages is referred to as the "Document" 1402 (FIG. 14).
  • the Document 1402 is the portion of the software that is responsible for managing the flow of data for the UI.
  • the Embedded Code 302 sends the updated network information to an appropriate software "Target" 1401 via an Update Message.
  • the word "target” refers to a software device that is used to accept data for storage, forwarding, or processing.
  • the Target 1401 is responsible for receiving updated network information, storing the information in a Database 1403 (discussed in detail below) located on the PC's storage device, and providing the Document 1402 with a pointer to the memory location containing the updated network information.
  • Views 1404 are the portions of the UI software that are responsible for presenting network information, in the form of charts, tables, tree formats, etc., to the user via the PC's display device, e.g., a color cathode ray tube.
  • network Statistics Chart View which presents network statistics in a graphical or chart format.
  • a plurality of views can be used at the same time to present network information to the user in several formats simultaneously. If the user is viewing network information in real-time ( i.e...
  • the Document 1402 informs the appropriate View 1404 of the receipt of some update from the embedded code 302.
  • the View 1404 gets from the Document 1402 the pointer to the memory location (in the PC's RAM or random access memory) that contains the updated network information.
  • the View 1404 then presents this information in the appropriate format to the user via the PC's display device.
  • the View 1404 gathers relevant information from the Database 1403 and presents the information in the appropriate format to the user via the PC's display device. Simultaneous display of a plurality of network parameters, either all real time, or all from the database, or mixed is accomplished through the use of well-known features and capability inherent in the Microsoft Windows operating system. Therefore, information on a plurality of network parameters can be displayed simultaneously. Also, nothing has been incorporated into the present invention that limits or disables these well known features and capabilities.
  • the various Views are programmed to present the network information to the user in the forms of charts, graphs, tables and trees as mentioned above.
  • Off-the-shelf products are used to present the network information to the user.
  • ChartFx (Version 3.0), marketed by Software FX, Inc. at 7100 West Camino Real, Boca Raton, FL 33060, is used to display network information in the form of charts and graphs. Network information on station-level statistics, network statistics and protocol distribution in preferably displayed in the form of charts and/or graphs.
  • the User's Manual for ChartFx is hereby incorporated by reference as if fully reproduced herein.
  • the product SpreadVBX++ (Ver. 2.0), marketed by FarPoint Technologies, Inc. at 133 South Center Court, Suite 1000, Morrisville, NC 27560, is used to display network information in the form of tables and spreadsheets. Network information relating to station-level statistics, network statistics and event information is preferably displayed in the form of tables and/or spreadsheets.
  • the User's Manual for SpreadVBX++ is hereby incorporated by reference as if fully reproduced herein.
  • the product TreeControl (Version 1), marketed by Premia Creative Controls Corp. at 1075
  • MFC Microsoft Foundation Class
  • the preferred embodiment of the present invention utilizes an object-oriented (OO) database application.
  • the database application used is the 5 POET database product (Ver. 3.0), marketed by Poet Software Corp. at 999 Baker Way, Suite 100, San Mateo, CA 94404.
  • the Reference Manual for POET 3.0 is hereby incorporated by reference as if fully reproduced herein.
  • POET 3.0 is an OO database application which uses a C++ programming language Application Program Interface (API).
  • API Application Program Interface
  • Other database applications which use a C++ API would 0 also be appropriate for use in the present invention.
  • the present invention could also utilize
  • ODBC Open Database Connectivity
  • SQL Structured Query Language
  • An object-oriented database such as POET stores C++ objects in a database and allows the programmer to retrieve them using the database operations.
  • the objects read from the database look and act just like the objects stored because an object- oriented database knows how to read C++ class declarations and therefore, manage C++ objects.
  • the database may be saved to a storage device 0 for use as a "baseline" against which future network monitoring sessions may be compared.
  • FIG 15 is a "scenario diagram" depicting the process by which station-level statistics are 5 displayed to the user in real time.
  • the Document 1402 requests an update of station-level statistics from the Embedded Code 302.
  • the Station-Level Statistics Target 1501 receives the updated station-level statistics (i.e. the station-level statistics update message discussed above under Station-Level Statistics).
  • the Station-Level Statistics class 1502 is initialized. By “initialized” is meant that a new instance is created of that POET object of the station-level-statistic type, for storing the new data.
  • the Station-Level Statistics class is a class in the POET database which contains information on station-level statistics.
  • the Station-Level Statistics Target 1501 decodes the Station-Level Statistics
  • the Station-Level Statistics Target 1501 begins this decoding process by reading the message header and the station list array from the update message. Next, it determines which type of station-level statistics are contained in the update message (i.e., ethernet statistics, token ring statistics, FDDI statistics, frame relay statistics, etc.). Finally, the Station-Level Statistics Target 1501 places each of the station-level statistics obtained from the decoded update message in a POET data object for storage and later access.
  • step five the Station-Level Statistics Target 1501 informs the Document 1402 that the
  • Target 1501 has received some kind of an update.
  • a pointer to the POET data objects containing the updated station-level statistics is sent from the Target 1501 to the Document 1402.
  • a pointer is an address which identifies or "points to" the memory location in RAM that contains the data.
  • the Document 1402 informs the Station List View 1503 and the Station Details View 1504 that the views may have to be updated. That is, the Document 1402 informs the Views 1503 and 1504 that some new data has been received but not the exact type and content of the new data.
  • the Station List View 1503 controls the display of a listing of MAC addresses and other information about activity at those MAC address stations.
  • the Station Details View 1504 controls the display of sortings and other detailing of the stations to highlight such factors as which stations are transmitting the most frames, which are receiving the most frames, which are involved with the most error messages, etc.
  • the scope and nature of the details displayed is arbitrary to the user.
  • the Station List View 1503 and the Station Details View 1504 request verification from the Document 1402 that there is new data which should, in fact, be added to the Station List View 1503 and Details View 1504. This step is useful because the user has initially selected how often information on station-level statistics was to updated, and it is possible that there was no new station-level statistic information between the last update and the present update. In this case, there are no new data to be added to the views.
  • the Station List View 1503 and the Station Details View 1504 receive a pointer or address to the location in the random-access memory (RAM) of the PC that contains the new data from the Document 1402. The views then obtain the object containing the new data or information.
  • RAM random-access memory
  • Steps thirteen and fourteen involve presenting all of the updated station-level statistics to the user in the form of tables and charts.
  • the views use the pointers passed to them to gather the new data from its memory location for presentation in the appropriate format.
  • the Station List View 1503 is responsible for displaying the data in the form of a table. This is accomplished through the off-the-shelf product Spread VBX++, discussed above under User Interface— Overview.
  • the Station Details View 1504 is responsible for displaying station-level statistics in the form of piecharts indicating top transmitting, receiving, and error producing stations. This is accomplished through use of the off-the-shelf product ChartFx, discussed above under User Interface— Overview.
  • FIG. 19 illustrates an example of a display screen arrangement for displaying station statistics to the user.
  • the list can show "top talkers” and “top listeners” as well as a host of other catagories of information, the desirability and usefulness of which will be readily evident to a person having ordinary skill in the art of digital network transmission analyzers.
  • a split-screen display is also available with Microsoft Windows to show that the desired statistics can be shown in any number of formats, including the pie chart illustrated in FIG. 19.
  • Figure 16 is a scenario diagram depicting the process by which information on network statistics is displayed to the user in real time.
  • the Network Statistics class 1602 is initialized.
  • the Network Statistics class is a class in the POET database which contains information on network statistics.
  • One instance of the Network Statistics class is Ethernet Network Statistics which contains network statistic information particular to an Ethernet network.
  • the Network Statistics Target 1601 decodes the Network Statistic Update Message.
  • the Network Statistics Target 1601 begins this decoding process by reading the Header 1301 and the Network Statistics Array 1302 from the update message.
  • the Network Statistics Target 1601 determines which type of network statistics are contained in the update message (i.e., ethernet statistics, token ring statistics, FDDI statistics, frame relay statistics, etc.).
  • the Network Statistics Target 1601 places each of the network statistics obtained from the decoded update message in a POET data object for storage and later access. If the user has selected to store information on network statistics to a database on the PC's storage device for later use as a baseline, this information is stored in the appropriate location in the POET database in step five.
  • the appropriate storage location in the POET database is based upon the relevant class (i.e., Ethernet Network Statistics, Token Ring Network Statistics, etc.).
  • the Network Statistics Target 1601 informs the Document 1402 that the Target 1601 has received an update.
  • a pointer to the data objects containing the updated network statistics is sent from the Target 1601 to the Document 1402.
  • step seven the Document 1402 informs the Network Statistics Table View 1603 and/or the Network Statistics Chart View 1604 (depending on which view(s) the user is using) that the views may have to be updated.
  • step eight the Network Statistics Table View 1603 and/or Network Statistics Chart View 1604 request verification from the Document 1402 that there is, in fact, new data which should be added to the chart and/or table views. This step is useful because the user has selected how often information on network statistics was to be updated, and it is possible that there was no new network statistic information between the last update and the present update. In this case, there are no new data to be added to the charts and/or tables.
  • the Network Statistics Table View 1603 and/or the Network Statistics Chart View 1604 receive a pointer to the new data from the Document 1402.
  • Step ten involves presenting all of the updated network statistics to the user in the form of tables and charts.
  • the views use the pointers passed to them to gather the new data from their RAM memory location for presentation in the appropriate format.
  • the Network Statistics Table View 1603 is responsible for displaying the data in the form of tables, and this is accomplished through the off-the-shelf product SpreadVBX++, discussed above under User Interface—Overview.
  • the Network Statistics Chart View 1604 is responsible for displaying network statistics in the form of charts and graphs, and this is accomplished through use of the off-the-shelf product ChartFx, discussed above under User Interface— Overview.
  • FIG. 20 illustrates three examples of display screen display formats useful for showing network statistics to the user.
  • FIG. 20 ⁇ illustrates how a network utilization chart might look.
  • FIG. 20B illustrates how a network frame rate chart might look, and
  • FIG. 20C illustrates how a frame size distribution chart might look. While charts are shown, a person having ordinary skill in the programming art, and a person having ordinary skill in the digital network transmission art will be the aware that may other other formats of display can readily be substituted for charts.
  • E. Protocol Distribution User Interface Figure 17 is a scenario diagram depicting the process by which cumulative protocol distribution information is displayed to the user in real time. The process by which protocol distribution that is calculated per sampling period is displayed to the user is analogous to this process. First the Document 1402 requests an update of protocol distribution from the Embedded
  • the Protocol Distribution (Cumulative) Target 1701 receives the updated protocol distribution information (i.e. the Protocol Distribution Update Message discussed above under Protocol Distrihution
  • the Protocol Distribution class 1702 is a class in the POET database which contains information on protocol distribution.
  • Protocol Distribution which contains protocol distribution information on a cumulative basis, i.e. since the network monitoring session began, and Protocol Distribution (Sample), which contains information on protocol distribution for the user-defined sampling period.
  • Protocol Distribution (Cumulative) Target 1701 decodes the Protocol
  • the Protocol Distribution (Cumulative) Target 1701 begins this decoding process by reading the Header 601 (Fig. 6) of the "message" and Protocol Distribution Array information or data array or portion 602 of the message, that was taken from the Protocol Distribution Array of the memory of the protocol analyzer instrument. As discussed above under Protocol Distribution, each entry in the Protocol Distribution
  • Protocol Distribution (Cumulative) Target 1701 builds a hierarchical protocol distribution structure (tree structure). If the user has chosen to view protocol distribution in a percentage format, the appropriate statistics_for_the_protocol are converted to a percentage (i.e., the total number of bytes received for the protocol is divided by the total number of bytes received and then multiplied by one hundred). Finally, the Protocol Distribution (Cumulative) Target 1701 places each element of the newly created hierarchical protocol distribution structure in a POET data object for later storage and access.
  • Protocol Distribution (Cumulative)
  • step six the Protocol Distribution (Cumulative) Target 1701 informs the Document 1402 that the Target 1701 has received an update.
  • a pointer to the location, in the PC's RAM memory, of the POET data objects that contain the updated hierarchical protocol distribution structure is sent from the Target 1701 to the Document 1402.
  • step seven the Document 1402 informs the Protocol Distribution Tree View 1703 that the view should perhaps be updated.
  • the Protocol Distribution Tree View 1703 requests verification from the Document 1402 that there is new data which should be added to the tree-type display of protocol distribution. This step is used because the user selected how often information on protocol distribution was updated. It is possible that, while there were some new data received, there may have been no new protocol distribution information contained in the new data received from the time of the last update and the present update. In this case, there are no new data to be added to the tree.
  • the Protocol Distribution Tree View 1703 receives a pointer to the new data (in RAM) from the Document 1402.
  • step ten the Document 1402 informs the Protocol Distribution Chart View 1704 that the view should be updated.
  • step eleven the Protocol Distribution Chart View 1704 receives a pointer to the new data from the Protocol Distribution Tree View 1703.
  • Steps twelve and thirteen involve presenting the data to the user in a tree format and a chart format.
  • the views use the pointers passed to them to gather the new data from its memory location in the RAM of the PC for presentation in the appropriate format.
  • the Protocol Distribution Tree View 1703 is responsible for displaying the data in a tree format. It builds a tree structure based upon the hierarchical protocol distribution structure. An off-the-shelf product entitled TreeControl (discussed above under User Interface— Overview) is used to display the tree structure.
  • the Protocol Distribution Chart View 1704 is responsible for displaying protocol distribution in a pie-chart format. This is accomplished through use of the off-the-shelf product ChartFx, discussed above under User Interface— Overview.
  • FIG. 21 illustrates how a split-screen display can be used to highlight one ISO protocol layer, instantly revealing usage by the protocols detected on the network.
  • Figure 18 is a scenario diagram depicting the process by which event information is displayed to the user in real time.
  • step three the Event Log database class 1802 is initialized.
  • the Event Log class is a class in the POET database which contains event information.
  • step four the Event Target 1801 decodes the Event Update Message.
  • the Event Target 1801 begins this decoding process by reading the message header and the portion of the event log array. It then places information relating to each event, as contained in the portion of the event log array of the memory of the protocol analyzer instrument into a POET data object in RAM storage of the PC for later storage and access.
  • the information is stored in the appropriate location in the POET database in step five.
  • step six the Event Target 1801 informs the Document 1402 that the Target 1801 has received an update.
  • a pointer to the POET data objects containing the updated event information is sent from the Target 1801 to the Document 1402.
  • step seven the Document 1402 informs the Event Log View 1803 that the view should perhaps be updated.
  • step eight the Event Log View 1803 requests verification from the Document 1402 that there is, in fact, new data which should be added to the Event Log View. This step is useful because the user had selected how often event information was updated, and it is possible that there was no new event information from the time of the last update to the time of the present update. In this case, there are no new data to be added to the view.
  • the Document 1402 responds that there is indeed new data, i.e. there is new information in the event log array in the memory of the PC, then these new data are obtained by the Event Log View 1803 in step nine.
  • the Event Log View 1803 receives from the Document 1402, a pointer to the new data now stored in the PC's RAM.
  • Step ten involves presenting all of the updated event information to the user in a table format.
  • the event log view uses the pointer passed to it to gather the new event information from its memory location in the PC's RAM for presentation in the appropriate format.
  • the Event Log View 1803 presents the name of the event (derived from the event id), the time of the event, and a brief description of the event (derived from the event parameters) in the form of a table. Presentation of event information in a table format is accomplished through the off-the-shelf product Spread VBX ⁇ -t . discussed above under User Interface— Overview.
  • FIG. 22 illustrates a preferred example of how detected events can be sorted and displayed with timestamps, on the PC's display device so as to enhance the user's ability to find information quickly.
  • the user interface is also capable of displaying detailed information about a particular event and the possible causes of the event in a hypertext format.
  • Hypertext in conjunction with the present invention allows a user to access detailed explanations through use of the PC's pointing device.
  • the user can obtain detailed definitions of statistics and events as well as possible causes of each type of event by double-clicking the PC's pointing device on the event or statistic displayed by the user interface.
  • a "window" is opened on a display containing a detailed definition of the event or statistic as well as a brief discussion of the possible causes and ramifications of the event. This information is contained in a standard Microsoft Windows context-sensitive help file format.
  • the user interface is also capable of displaying step-by-step troubleshooting information in a hypertext format which assists the user in solving problems on a network by posing increasingly specific queries until a solution is reached.
  • This information is likewise contained in a standard Microsoft Windows help file format.
  • the exact method by which the above data are displayed would be readily apparent to a person having ordinary skill in the art of software programming and in the art of network analyzing.
  • the text of the troubleshooting information can be created and written specifically for the UI by a person having ordinary skill in the digital data transmission art; or troubleshooting information for Ethernet and Token Ring networks can be examined in a textbook entitled Ethernet and Token Ring Optimization, by Daniel J. Nassar, Copyright 1996, Henry Holt & Co., Inc., New York, New York., which is hereby incorporated by reference as though fully reproduced herein.
  • transmission information concerning Protocol Distribution, Station- Level Statistics. Network Statistics and Events are displayed for the user in the form of graphs and charts.
  • the transmission information can also be used to create customized reports. These customized reports provide the transmission information in a presentation quality format.
  • the invention also allows the user to specify the time span which the report will cover.
  • Reports may be printed on a standard printer connected to the PC or displayed on the PC's display device. Reports also may be previewed and modified on-line prior to printing. The reporting feature is implemented using an off-the-shelf reporting application entitled ReportFX
  • the present invention is also capable of saving the contents of the capture buffer to a capture file on a storage device (see Frame Analysis above for discussion of capture buffer).
  • the present invention can then display information about specific frames stored in the capture file.
  • the user interface allows the user to examine a captured frame, search the capture file for filter criteria, view the protocols present in a frame, specific frames, view only those frames which meet specific and print the contents of the frame on a printer attached to the PC. Analysis of captured frames is accomplished by use of a software application entitled Examine which is marketed by Wandel & Goltermann Technologies, Inc. at 1030 Swabia Court, Research Triangle Park, NC 27709-3585.
  • the data portion of the message conveying that event information to the PC will include any MAC addresses that were involved in that event.
  • the user can request reporting or displaying of any combination of further information about that MAC address that might be pertinent to that event.
  • the transmitting stations and receiving stations can be displayed as sorted according to the number of messages transmitted or received. This will immediately disclose which stations are transmitting the most (top talkers)and which stations are receiving the most (top listeners).
  • the station statistics for the top talker or top listener can then be queried by protocol used. If a large number of the frames for a station carry the IP (internet protocol), it could mean that the employee using that station is either gathering a lot of needed project information from the internet or that the employee is "surfing" the internet on company time. Therefore, some supervisory involvement may be in order to ascertain if that employee should be switched to a more lightly-loaded network or should be admonished about wasting company time.
  • IP internet protocol

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Abstract

L'invention concerne un analyseur nouveau et perfectionné (304, 305) de protocoles, destiné à surveiller des réseaux (301) de transmission numérique. Cet analyseur peut afficher des statistiques de paramètres de niveau des stations, des statistiques de paramètres de réseau, des informations sur des événements en temps réel ainsi que sur une répartition des protocoles. Il est en outre capable de créer des informations de base relatives au comportement des réseaux et d'afficher ces informations en même temps que des informations de comportement en temps réel, de préprogrammer des sessions de surveillance et de produire des rapports de qualité de présentation conjointement avec une analyse des réseaux de transmission numérique, le tout en temps réel.
PCT/US1997/009685 1996-08-02 1997-06-04 Analyseur de protocoles destine a la surveillance de reseaux de transmission numerique WO1998006200A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU34765/97A AU3476597A (en) 1996-08-02 1997-06-04 Protocol analyzer for monitoring digital transmission networks

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
US2345996P 1996-08-02 1996-08-02
US60/023,459 1996-08-02
US08/742,093 1996-10-31
US08/742,093 US5850388A (en) 1996-08-02 1996-10-31 Protocol analyzer for monitoring digital transmission networks
US74312596A 1996-11-01 1996-11-01
US74271596A 1996-11-01 1996-11-01
US74293596A 1996-11-01 1996-11-01
US74369796 1996-11-01
US08/743,697 1996-11-01
US08/742,935 1996-11-01
US08/743,125 1996-11-01
US08/742,715 1996-11-01

Publications (1)

Publication Number Publication Date
WO1998006200A1 true WO1998006200A1 (fr) 1998-02-12

Family

ID=27556009

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/009685 WO1998006200A1 (fr) 1996-08-02 1997-06-04 Analyseur de protocoles destine a la surveillance de reseaux de transmission numerique

Country Status (2)

Country Link
AU (1) AU3476597A (fr)
WO (1) WO1998006200A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0948234A1 (fr) * 1998-04-03 1999-10-06 Deutsche Telekom AG Analyse de réseau de données ATM
WO2000024223A1 (fr) * 1998-10-21 2000-04-27 Celogic Procede de qualification des informations et d'aide a la localisation de defauts sur reseau numerique de telecommunication
FR2785115A1 (fr) * 1998-10-21 2000-04-28 Celogic Procede de qualification des informations pertinentes pour calculer au moins un critere de qualite et/ou de performance dans un reseau numerique de telecommunication
EP1772992A1 (fr) * 2005-10-06 2007-04-11 Alcatel Lucent Dispositif et procédé pour analyser des trains de données par paquets
WO2008124947A1 (fr) * 2007-04-16 2008-10-23 Neuralitic Systems Procédé et système de filtrage d'un trafic ip dans des réseaux ip mobiles
WO2018164355A1 (fr) * 2017-03-10 2018-09-13 엘지전자 주식회사 Procédé et dispositif de transmission/réception de signal en multidiffusion

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5097469A (en) * 1989-05-19 1992-03-17 Concord Communications, Inc. Passive monitor for broadcast communication network
US5317725A (en) * 1991-03-12 1994-05-31 Hewlett-Packard Company Landmark data abstraction paradigm to diagnose data communication networks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5097469A (en) * 1989-05-19 1992-03-17 Concord Communications, Inc. Passive monitor for broadcast communication network
US5317725A (en) * 1991-03-12 1994-05-31 Hewlett-Packard Company Landmark data abstraction paradigm to diagnose data communication networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MILCOM '89: BRIDGING THE GAP, 1989, WEAVER ALFRED C. and McNABB JAMES F., "A Real-Time Monitor for Token Ring Networks", pages 794-798. *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0948234A1 (fr) * 1998-04-03 1999-10-06 Deutsche Telekom AG Analyse de réseau de données ATM
WO2000024223A1 (fr) * 1998-10-21 2000-04-27 Celogic Procede de qualification des informations et d'aide a la localisation de defauts sur reseau numerique de telecommunication
FR2785115A1 (fr) * 1998-10-21 2000-04-28 Celogic Procede de qualification des informations pertinentes pour calculer au moins un critere de qualite et/ou de performance dans un reseau numerique de telecommunication
FR2785117A1 (fr) * 1998-10-21 2000-04-28 Celogic Procede de qualification des informations et d'aide a la localisation de defauts sur reseau numerique de telecommunication
EP1772992A1 (fr) * 2005-10-06 2007-04-11 Alcatel Lucent Dispositif et procédé pour analyser des trains de données par paquets
WO2008124947A1 (fr) * 2007-04-16 2008-10-23 Neuralitic Systems Procédé et système de filtrage d'un trafic ip dans des réseaux ip mobiles
WO2018164355A1 (fr) * 2017-03-10 2018-09-13 엘지전자 주식회사 Procédé et dispositif de transmission/réception de signal en multidiffusion
EP3595254A4 (fr) * 2017-03-10 2020-12-30 LG Electronics Inc. -1- Procédé et dispositif de transmission/réception de signal en multidiffusion

Also Published As

Publication number Publication date
AU3476597A (en) 1998-02-25

Similar Documents

Publication Publication Date Title
US5850388A (en) Protocol analyzer for monitoring digital transmission networks
US5850386A (en) Protocol analyzer for monitoring digital transmission networks
EP0613270B1 (fr) Méthode d'analyse de réseau
US7729245B1 (en) Method and system of monitoring the receipt of multicast traffic
US7065571B2 (en) System, method and computer program product for policy-based billing in a network architecture
US6483812B1 (en) Token ring network topology discovery and display
EP2255494B1 (fr) Système et procédé pour exporter des données structurées dans un environnement de gestion de réseau
EP2486698B1 (fr) Procédé et système de reconstruction de transactions dans un réseau de communication
US6219705B1 (en) System and method of collecting and maintaining historical top communicator information on a communication device
WO1998006200A1 (fr) Analyseur de protocoles destine a la surveillance de reseaux de transmission numerique
Waldbusser et al. Introduction to the remote monitoring (RMON) family of MIB modules
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载