WO1992019054A1 - Systeme de controle de reseau de communication - Google Patents

Systeme de controle de reseau de communication Download PDF

Info

Publication number
WO1992019054A1
WO1992019054A1 PCT/US1992/002995 US9202995W WO9219054A1 WO 1992019054 A1 WO1992019054 A1 WO 1992019054A1 US 9202995 W US9202995 W US 9202995W WO 9219054 A1 WO9219054 A1 WO 9219054A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
node
packets
protocol
mibcount32
Prior art date
Application number
PCT/US1992/002995
Other languages
English (en)
Inventor
Engel Ferdinand
Kendall S. Jones
Kary Robertson
David M. Thompson
Gerard White
Original Assignee
Concord Communications, 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
Application filed by Concord Communications, Inc. filed Critical Concord Communications, Inc.
Publication of WO1992019054A1 publication Critical patent/WO1992019054A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the invention relates to monitoring and managing communication networks for computers.
  • These networks often span large geographic areas ranging from a campus-like setting to world wide networks. While the network itself can be used by many different types of organizations, the purpose of these networks is to move information between computers. Typical applications are electronic mail, transaction processing, remote database, query, and simple file transfer. Usually, the
  • Network management is the task of planning, engineering, securing and operating a network.
  • the Network Manager has some obvious needs. First, the Network
  • the Network Manager must trouble shoot problems. As the errors develop in a running network, the Network Manager must have some tools that notify him of the errors and allow him to diagnose and repair these errors. Second, the Network Manager needs to configure the network in such a manner that the network loading characteristics provide the best service possible for the network users. To do this the Network Manager must have tools that allow him visibility into access patterns, bottlenecks and general loading. With such data, the Network Manager can
  • routers can be, but are not limited to: routers, bridges, PC's, workstations, minicomputers, supercomputers, printers, file servers, switches and pbx's.
  • Each component provides a protocol for reading and writing the management variables in the machine. These variables are usually defined by the component vendor and are usually referred to as a
  • MIB Management Information Base
  • the software in other computers can manage or control the component.
  • the software in the component that provides remote access to the MIB variables is usually called an agent.
  • an agent an individual charged with the MIB variables
  • the invention features monitoring communications which occur in a network of nodes, each communication being effected by a
  • the communication information derived from the packet contents is associated with multiple layers of at least one of the protocols.
  • the invention features monitoring communication dialogs which occur in a network of nodes, each dialog being effected by a transmission of one or more packets among two or more communicating nodes, each dialog complying with a
  • predefined communication protocol selected from among protocols available in the network.
  • Information about the states of dialogs occurring in the network and which comply with different selected protocols available in the network is derived from the packet contents.
  • a current state is maintained for each dialog, and the current state is updated in response to the detected contents of transmitted packets.
  • a history of events is maintained based on information derived from the contents of packets, and the history of events is analyzed to derive information about the dialog.
  • the analysis of the history includes counting events and gathering statistics about events.
  • the history is monitored for dialogs which are inactive, and dialogs which have been inactive for a predetermined period of time are purged.
  • the current state is updated to data state in response to observing the transmission of at least two data related packets from each node. Sequence numbers of data related packets stored in the history of events are analyzed and
  • the retransmissions are detected based on the sequence numbers.
  • the the current state is updated based on each new packet associated with the dialog; if an updated current state cannot be determined, information about prior packets associated with the dialog is consulted as an aid in updating the state.
  • the history of events may be searched to identify the initiator of a dialog.
  • updating the current state in response to the detected contents of transmitted packets includes generating a current state (e.g., "unknown") which may not conform to the true state.
  • the current state may be updated to the true state based on information about prior packets transmitted in the dialog.
  • Each communication may involve multiple dialogs corresponding to a specific protocol.
  • Each protocol layer of the communication may be parsed and analyzed to isolate each dialog and statistics may be kept for each dialog.
  • the protocols may include a connectionless-type protocol in which the state of a dialog is implicit in transmitted packets, and the step of deriving information about the states of dialogs includes inferring the states of the dialogs from the packets. Keeping statistics for protocol layers may be temporarily suspended when parsing and statistics gathering is not rapid enough to match the rate of packets to be parsed.
  • the invention features monitoring the operation of the network with respect to specific items of performance during normal operation, generating a model of the network based on the monitoring, and setting acceptable threshold levels for the specific items of performance based on the model.
  • the operation of the network is monitored with respect to the specific items of
  • the invention features the combination of a monitor connected to the network medium for passively, and in real time,
  • the workstation for receiving the information about dialogs from the monitor and providing an interface to a user.
  • the workstation includes means for enabling a user to observe events of active dialogs.
  • the invention features apparatus for monitoring packet communications in a network of nodes in which communications may be in accordance with multiple protocols.
  • the apparatus includes a monitor connected to a communication medium of the network for passively, and in real time, monitoring transmitted packets of different protocols and storing information about communications associated with the packets, the communications being in accordance with different protocols, and a workstation for receiving the information about the communciations from the monitor and providing an interface to a user.
  • the monitor and the workstation include means for relaying the information about multiple protocols with respect to communication in the different protocols from the monitor to the
  • the invention features diagnosing communication problems between two nodes in a network of nodes interconnected by links.
  • the operation of the network is monitored with respect to specific items of performance during normal operation.
  • a model of normal operation of the network is generated based on the monitoring.
  • Acceptable threshold levels are set for the specific items of performance based on the model.
  • the operation of the network is monitored with respect to the specific items of performance during periods which may include abnormal operation.
  • the problem is diagnosed by separately analyzing the
  • the invention features a method of timing the duration of a transaction of interest occurring in the course of communication between nodes of a network, the beginning of the
  • packets transmitted in the network are monitored passively and in real time.
  • the beginning time of the transaction is determined based on the appearance of the first packet.
  • a determination is made of when the other packet has been transmitted.
  • the timing of the duration of the transaction is ended upon the appearance of the other packet.
  • the invention features, tracking node address to node name mappings in a network of nodes of the kind in which each node has a possibly nonunique node name and a unique node address within the network and in which node addresses can be assigned and reassigned to node names dynamically using a name binding protocol message incorporated within a packet.
  • packets transmitted in the network are monitored, and a table linking node names to node addresses is updated based on information contained in the name binding protocol messages in the packets.
  • One advantage of the invention is that it enables a network manager to passively monitor multi-protocol networks at multiple layers of the communications. In addition, it organizes and presents network performance statistics in terms of dialogs which are occurring at any desired level of the communication. This technique of organizing and displaying network performance statistics provides an effective and useful view of network
  • Fig. 1 is a block diagram of a network
  • Fig. 2 shows the layered structure of a network communication and a protocol tree within that layered environment
  • Fig. 3 illustrates the structure of an
  • Fig. 4 illustrates the different layers of a communication between two nodes
  • Fig. 5 shows the software modules within the
  • FIG. 6 shows the structure of the Monitor software in terms of tasks and intertask communication mechanisms
  • Figs. 7a-c show the STATS data structures which store performance statistics relating to the the data link layer
  • Fig. 8 is a event/state table describing the operation of the state machine for a TCP connection
  • Fig. 9a is a history data structure that is identified by a pointer found in the appropriate dialog statistics data within STATS;
  • Fig. 9b is a record from the history table
  • Fig. 10 is a flow diagram of the
  • Fig. 11 is a flow diagram of the
  • Fig. 12 is a flow diagram of the
  • Fig. 13 is a diagram of the major steps in processing a frame through the Real Time Parser (RTP);
  • Fig. 14 is a diagram of the major steps in the processing a statistics threshold event
  • Fig. 15 is a diagram of the major steps in the processing of a database update
  • Fig. 16 is a diagram of the major steps in the processing of a monitor control request
  • Fig. 17 is a logical map of the network as displayed by the Management Workstation
  • Fig. 18 is a basic summary tool display screen
  • Fig. 19 is a protocol selection menu that may be invoked through the summary tool display screen
  • Figs. 20a-g are examples of the statistical variables which are displayed for different protocols
  • Fig. 21 is an example of information that is displayed in the dialogs panel of the summary tool display screen
  • Fig. 22 is a basic data screen presenting a rate values panel, a count values panel and a protocols seen panel;
  • Fig. 23 is a traffic matrix screen
  • Fig. 24 is a flow diagram of the algorithm for adaptively establishing network thresholds based upon actual network performance
  • Fig. 25 is a simple multi-segment network
  • Fig. 26 is a flow diagram of the operation of the diagnostic analyzer algorithm
  • Fig. 27 is a flow diagram of the source node analyzer algorithm
  • Fig. 28 is a flow diagram of the sink node analyzer algorithm
  • Fig. 29 is a flow diagram of the link analysis logic
  • Fig. 30 is a flow diagram of the DLL problem checking routine
  • Fig. 31 is a flow diagram of the IP problem checking routine
  • Fig. 32 is a flow diagram of the IP link component problem checking routine
  • Fig. 33 is a flow diagram of the DLL link component problem checking routine
  • Fig. 34 shows the structure of the event timing database
  • Fig. 35 is a flow diagram of the operation of the event timing module (ETM) in the Network Monitor;
  • Fig. 36 is a network which includes an Appletalk ® segment
  • Fig. 37 is a Name Table that is maintained by the Address Tracking Module (ATM);
  • Fig. 38 is a flow diagram of the operation of the ATM; and
  • Fig. 39 is a flow diagram of the operation of the ATM.
  • Appendix I identifies the SNMP MIB subset that is supported by the Monitor and the Management Workstation (2 pages);
  • Appendix II defines the extension to the standard MIB that are supported by the Monitor and the Management Workstation (25 pages);
  • Appendix III is a summary of the protocol variables for which the Monitor gathers statistics and a brief description of the variables, where appropriate (17 pages);
  • Appendix IV is a list of the Summary Tool Values Display Fields with brief descriptions (2 pages).
  • Appendix V is a description of the actual screens for the Values Tool (34 pages).
  • a typical network such as the one shown in Fig. 1, includes at least three major components, namely, network nodes 2, network elements 4 and communication lines 6.
  • Network nodes 2 are the individual computers on the network. They are the very reason the network exists. They include but are not limited to workstations (WS), personal computers (PC), file servers (FS), compute servers (CS) and host computers (e.g., a VAX), to name but a few.
  • WS workstations
  • PC personal computers
  • FS file servers
  • CS compute servers
  • host computers e.g., a VAX
  • network elements 4 are anything that participate in the service of providing data movement in a network, i.e., providing the basic communications.
  • Bridges serve as connections between different network segments. They keep track of the nodes which are
  • Gateways generally provide
  • Nodes send packets to routers so that they may be directed over the appropriate segments to the intended destination node.
  • network or communication lines 6 are the components of the network which connect nodes 2 and elements 4 together so that communicatons between nodes 2 may take place. They can be private lines, satellite lines or Public Carrier lines. They are expensive resources and are usually managed as separate entities. Often networks are organized into segments 8 that are connected by network elements 4. A segment 8 is a section of a LAN connected at a physical level (this may include repeaters). Within a segment, no protocols at layers above the physical layer are needed to enable signals from two stations on the same segment to reach each other (i.e., there are no routers, bridges,
  • LAN local area network
  • Network Monitor 10 (referred to hereinafter simply as Monitor 10) is the data collection module which is attached to the LAN. It is a high performance real time front end processor which collects packets on the network and performs some degree of analysis to search for actual or potential problems and to maintain statistical
  • Management Workstation 12 is the operator interface. It collects and presents troubleshooting and performance information to the user. It is based on the SunNet Manager (SNM) product and provides a graphical network-map-based interface and sophisticated data presentation and analysis tools. It receives information from Monitor 10, stores it and displays the information in various ways. It also instructs Monitor 10 to perform certain actions. Monitor 10, in turn, sends responses and alarms to Management Workstation 12 over either the primary LAN or a backup serial link 14 using SNMP with the MIB extensions defined later.
  • SNM SunNet Manager
  • These devices can be connected to each other over various types of networks and are not limited to
  • communication over the network is organized as a series of layers or levels, each one built upon the next lower one, and each one specified by one or more protocols (represented by the boxes).
  • Each layer is responsible for handling a different phase of the communication between nodes on the network.
  • the protocols for each layer are defined so that the services offered by any layer are relatively independent of the services offered by the neighbors above and below.
  • the identities and number of layers may differ depending on the network (i.e., the protocol set defining communication over the network), in general, most of them share a similar structure and have features in common.
  • OSI Open Systems Interconnection
  • the OSI model developed by the International Organization for Standardization, includes seven layers. As indicated in Fig. 2, there is a physical layer, a data link layer (DLL), a network layer, a transport layer, a session layer, a presentation layer and an application layer, in that order. As background for what is to follow, the function of each of these layers will be briefly
  • the physical layer provides the physical medium for the data transmission. It specifies the electrical and mechanical interfaces of the network and deals with bit level detail.
  • the data link layer is responsible for ensuring an error-free physical link between the
  • the network layer determines how packets are routed within the network.
  • the transport layer accepts data from the layer above it (i.e., the session layer), breaks the packets up into smaller units, if required, and passes these to the network layer for transmission over the network. It may insure that the smaller pieces all arrive properly at the other end.
  • the session layer is the user's interface into the network. The user must interface with the session layer in order to negotiate a connection with a process in another machine.
  • the presentation layer provides code conversion and data reformatting for the user's application.
  • the application layer selects the overall network service for the user's application.
  • Fig. 2 also shows the protocol tree which is implemented by the described embodiment.
  • a protocol tree shows the protocols that apply to each layer and it identifies by the tree structure which protocols at each layer can run "on top of” the protocols of the next lower layer.
  • Protocol stack generally refers to the protocol
  • FTP/TCP/IP/LLC is a protocol that is used when sending a message over a network.
  • FTP/TCP/IP/LLC is a protocol that is used when sending a message over a network.
  • a protocol family is a loose association of protocols which tend to be used on the same network (or derive from a common source).
  • the TCP/IP family includes IP, TCP, UDP, ARP, TELNET and FTP.
  • the Decnet family includes the protocols from Digital Equipment Corporation.
  • the SNA family includes the protocols from IBM.
  • the relevant protocol stack defines the structure of each packet that is sent over the network.
  • Fig. 3 which shows an TCP/IP packet, illustrates the typical structure of a packet.
  • each level of the protocol stack takes the data from the next higher level and adds header information to form a protocol data unit (PDU) which it passes to the next lower level. That is, as the data from the application is passed down through the protocol layers in preparation for transmission over the network, each layer adds its own information to the data passed down from above until the complete packet is assembled.
  • PDU protocol data unit
  • the PDU includes a destination address (DEST MAC ADDR), a source address (SRC MAC ADDR), a type (TYPE) identifying the protocol which is running on top of this layer, and a DATA field for the PDU from the IP layer.
  • DEST MAC ADDR destination address
  • SRC MAC ADDR source address
  • TYPE type identifying the protocol which is running on top of this layer
  • DATA field for the PDU from the IP layer.
  • the PDU for the IP layer includes an IP header plus a DATA field.
  • the IP header includes a type field (TYPE) for indicating the type of service, a length field (LGTH) for specifying the total length of the PDU, an identification field (ID), a protocol field (PROT) for identifying the protocol which is running on top of the IP layer (in this case, TCP), a source address field (SRC ADDR) for specifying the IP address of the sender, a destination address field (DEST ADDR) for specifying the IP address of the destination node, and a DATA field.
  • TYPE type field
  • LGTH for specifying the total length of the PDU
  • ID identification field
  • PROT protocol field
  • SRC ADDR source address field
  • DEST ADDR destination address field
  • the PDU built by the TCP protocol also consists of a header and the data passed down from the next higher layer.
  • the header includes a source port field (SRC PORT) for specifying the port number of the sender, a destination port field (DEST PORT) for
  • SEQ NO. sequence number field
  • ACK NO. acknowledgment number field
  • WINDOW window size field
  • a packet conveys meaning between the sender and the receiver and is part of a larger framework of packet exchanges.
  • dialog is a communication between a sender and a receiver, which is composed of one or more packets being transmitted between the two.
  • senders and receivers There can be multiple senders and receivers which can change roles.
  • most dialogs involve exchanges in both
  • a dialog is the exchange of messages and the associated meaning and state that is inherent in any particular exchange at any layer. It refers to the exchange between the peer entities
  • any particular message exchange could be viewed as belonging to multiple dialogs.
  • Nodes A and B are exchanging packets and are engaged in multiple dialogs.
  • Layer 1 in Node A has a dialog with Layer 1 in Node B.
  • this is the data link layer and the nature of the dialog deals with the message length, number of messages, errors and perhaps the guarantee of the delivery.
  • Layer n of Node A is having a dialog with Layer n of node B.
  • this is an application layer dialog which deals with virtual terminal connections and response rates.
  • connections or virtual circuits there are explicit primitives that deal with the dialog and they are generally referred to as connections or virtual circuits.
  • dialogs exist even in stateless and connectionless protocols. Two more examples will be described to help clarify the concept further, one dealing with a connection oriented protocol and the other dealing with a connectionless protocol.
  • Node A sends a connection request (CR) message to Node B.
  • the CR is an explicit request to form a connection. This is the start of a particular dialog, which is no different from the start of the connection. Nodes A and B could have other dialogs active simultaneously with this particular dialog. Each dialog is seen as unique.
  • a connection is a particular type of dialog.
  • Node A sends Node B a message that is a datagram which has no
  • connection paradigm in fact, neither do the protocol (s) at higher layers.
  • the application protocol designates this as a request to initiate some action.
  • a file server protocol such as Sun Microsystems' Network File System (NFS) could make a mount request.
  • NFS Sun Microsystems' Network File System
  • a dialog comes into existence once the communication between Nodes A and B has begun. It is possible to determine that communication has occurred and to determine the actions being requested. If in fact there exists more than one communication thread between Nodes A and B, then these would represent separate, different dialogs.
  • Monitor 10 includes a MIPS R3000 general purpose microprocessor (from MIPS Computer Systems, Inc.) running at 25 MHz. It is capable of providing 20 mips processing power. Monitor 10 also includes a 64Kbyte instruction cache and a 64Kbyte data cache, implemented by SRAM.
  • Monitor 10 The major software modules of Monitor 10 are implemented as a mixture of tasks and subroutine
  • Monitor 10 Among the major modules which make up Monitor 10 is a real time kernel 20, a boot/load module 22, a driver 24, a test module 26, an SNMP Agent 28, a Timer module 30, a real time parser (RTP) 32, a Message Transport Module (MTM) 34, a statistics database (STATS) 36, an Event Manager (EM) 38, an Event Timing Module (ETM) 40 and a control module 42.
  • RTP real time parser
  • MTM Message Transport Module
  • STATS statistics database
  • EM Event Manager
  • ETM Event Timing Module
  • Real Time Kernel 20 takes care of the general housekeeping activities in Monitor 10. It is responsible for scheduling, handling intertask communications via queues, managing a potentially large number of timers, manipulating linked lists, and handling simple memory management.
  • Boot/Load Module 22 which is FProm based, enables Monitor 10 to start itself when the power is turned on in the box. It initializes functions such as diagnostics, and environmental initialization and it initiates down loading of the Network Monitor Software including program and configuration files from the Management Workstation. Boot/load module 22 is also responsible for reloading program and/or configuration data following internal error detection or on command from the Management
  • boot/load module 22 uses the Trivial File Transfer Protocol (TFTP).
  • TFTP Trivial File Transfer Protocol
  • Device Driver 24 manages the network controller hardware so that Monitor 10 is able to read and write packets from the network and it manages the serial interface. It does so both for the purposes of
  • the communication occurs through the network controller hardware of the physical network (e.g. Ethernet).
  • the drivers for the LAN controller and serial line interface are used by the boot load module and the MTM. They provide access to the chips and isolate higher layers from the hardware
  • Test module 26 performs and reports results of physical layer tests (TDR, connectivity,%) under control of the Management Workstation. It provides traffic load information in response to user requests identifying the particular traffic data of interest. The load information is reported either as a percent of available bandwidth or as frame size(s) plus rate.
  • SNMP Agent 28 translates requests and information into the network management protocol being used to communicate with the Management Workstation, e.g., the Simple Network Management Protocol (SNMP).
  • SNMP Simple Network Management Protocol
  • Control Module 42 coordinates access to monitor control variables and performs actions necessary when these are altered.
  • monitor control variables which it handles are the following:
  • set reset monitor - transfer control to reset logic set time of day - modify monitor hardware clock and generate response to Management Workstation; get time of day - read monitor hardware clock and generate response to Workstation; set trap permit - send trap control ITM to EM and generate response to Workstation; get trap permit - generate response to
  • Control module 42 also updates parse control records within STATS when invoked by the RTP (to be described) or during overload conditions so that higher layers of parsing are dropped until the overload situation is resolved. When overload is over it restores full
  • Timer 30 is invoked periodically to perform general housekeeping functions. It pulses the watchdog timer at appropriate intervals. It also takes care of internal time stamping and kicking off routines like the EM routine which periodically recalculates certain numbers within the statistical database (i.e., STATS).
  • Real Time Parser (RTP) 32 sees all frames on the network and it determines which protocols are being used and interprets the frames.
  • the RTP includes a protocol parser and a state machine.
  • the protocol parser parses a received frame in the "classical" manner, layer-by-layer, lowest layer first. The parsing is performed such that the statistical objects in STATS (i.e., the network parameters for which performance data is kept) are maintained. Which layers are to have statistics stored for them is determined by a parse control record that is stored in STATS (to be described later). As each layer is parsed, the RTP invokes the appropriate functions in the statistics module (STATS) to update those statistical objects which must be changed.
  • STATS the statistical objects in STATS
  • the state machine within RTP 32 is responsible for tracking state as appropriate to protocols and
  • connection connections It is responsible for maintaining and updating the connection oriented statistical elements in STATS.
  • the RTP invokes a routine within the state machine. This routine determines the state of a connection based on past observed frames and keeps track of sequence numbers. It is the routine that determines if a connection is in data transfer state and if a retransmission has occurred.
  • the objectives of the state machine are to keep a brief history of events, state transitions, and sequence numbers per connection; to detect data transfer state so that sequence tracking can begin; and to count
  • RTP 32 also performs overload control by
  • STATS 36 is where Monitor 10 keeps information about the statistical objects it is charged with monitoring.
  • a statistical object represents a network parameter for which performance information is gathered. This information is contained in an extended MIB (Management Information Base), which is updated by RTP 32 and EM 38.
  • MIB Management Information Base
  • STATS updates statistical objects in response to RTP invocation.
  • Each statistical object is implemented as appropriate to the object class to which it belongs. That is, each statistical object behaves such that when invoked by RTP 32 it updates and then generates an alarm if its value meets a preset threshold. (Meets means that for a high threshold the value is equal to or greater than the threshold and for a low threshold the value is equal to or less than the threshold. Note that a single object may have both high and low thresholds.)
  • STATS 36 is responsible for the maintenance and initial analysis of the database. This includes
  • STATS 36 is also responsible for tracking events of interest in the form of various statistical
  • Examples are counters, rate meters, and rate of change of rate meters. It initiates events based on particular statistics reaching configured limits, i.e., thresholds. The events are passed to the EM which sends a trap (i.e., an alarm) to the Management Workstation. The statistics within STATS 36 are readable from the Management Workstation on request.
  • STATS performs lookup on all addressing fields. It assigns new data structures to address field values not currently present. It performs any hashing for fast access to the database. More details will be presented later in this document.
  • Event Manager (EM) 38 extracts statistics from STATS and formats it in ways that allow the Workstation to understand it. It also examines the various
  • EM 38 gets the data from STATS and sends it to the Workstation. It also performs some level of analysis for statistical,
  • EM 38 is also responsible for controlling the delivery of events to the Management Workstation, e.g., it performs event filtering.
  • the action to be taken on receipt of an event (e.g. threshold exceeded in STATS) is specified by the event action associated with the threshold.
  • the event is used as an index to select the defined action (e.g. report to Workstation, run local routine xxxx, ignore).
  • the action can be modified by commands from the Management Workstation (e.g., turn off an alarm) or by the control module in an overload situation.
  • An update to the event action does not affect events previously processed even if they are still waiting for transmission to the Management Workstation. Discarded events are counted as such by EM 38.
  • EM 38 also implements a throttle mechanism to limit the rate of delivery of alarms to the console based on configured limits. This prevents the rapid generation of multiple alarms. In essence. Monitor 10 is given a maximum frequency at which alarms may be sent to the Workstation. Although alarms in excess of the maximum frequency are discarded, a count is kept of the number of alarms that were discarded.
  • EM 38 invokes routines from the statistics module (STATS) to perform periodic updates such as rate
  • EM 38 requests for access to monitor control variables are passed to the control module.
  • EM 38 checks whether asynchronous traps (i.e., alarms) to the Workstation are permitted before
  • EM 38 receives database update requests from the Management Workstation and invokes the statistics module (STATS) to process these.
  • Message Transport Module (MTM) 34 which is DRAM based, has two distinct but closely related functions. First, it is responsible for the conversion of
  • Workstation commands and responses from the internal format used within Monitor 10 to the format used to communicate over the network. It isolates the rest of the system from the protocol used to communicate within Management Workstation. It translates between the internal representation of data and ASN.1 used for SNMP. It performs initial decoding of Workstation requests and directs the requests to appropriate modules for
  • MTM 34 is responsible for the delivery and reception of data to and from the Management Workstation using the protocol appropriate to the network.
  • Primary and backup communication paths are provided transparently to the rest of the monitor modules (e.g. LAN and dial up link). It is capable of full duplex delivery of messages between the console and monitoring module.
  • the messages carry event, configuration, test and statistics data.
  • Event Timing Module (ETM) 40 keeps track of the start time and end times of user specified transactions over the network. In essence, this module monitors the responsiveness of the network at any protocol or layer specified by the user.
  • Address Tracking Module 42 keeps track of the node name to node address bindings on networks which implement dynamic node addressing protocols.
  • Memory management for Monitor 10 is handled in accordance with following guidelines. The available memory is divided into four blocks during system
  • One block includes receive frame buffers. They are used for receiving LAN traffic and for receiving secondary link traffic. These are organized as linked lists of fixed sized buffers.
  • a second block includes system control message blocks. They are used for intertask messages within Monitor 10 and are
  • a third block includes transmit buffers. They are used for creation and transmission of workstation alarms and responses and are organized as a linked list of fixed sized buffers.
  • a fourth block is the statistics. This is allocated as a fixed size area at system
  • the structure of the Monitor in terms of tasks and intertask messages is shown in Fig. 6.
  • the rectangular blocks represent interrupt service routines, the ovals represent tasks and the circles represent input queues.
  • Each task in the system has a single input queue which it uses to receive all input. All inter-process communications take place via messages placed onto the input queue of the destination task. Each task waits on a (well known) input queue and processes events or intertask messages (i.e., ITM's) as they are received. Each task returns to the kernel within an appropriate time period defined for each task (e.g. after processing a fixed number of events).
  • ITM intertask messages
  • Interrupt service routines run on receipt of hardware generated interrupts. They invoke task level processing by sending an ITM to the input queue of the appropriate task.
  • the kernel scheduler acts as the base loop of the system and calls any runnable tasks as subroutines.
  • the determination of whether a task is runnable is made from the input queue, i.e., if this has an entry the task has work to perform.
  • the scheduler scans the input queues for each task in a round robin fashion and invokes a task with input pending.
  • Each task processes items from its input queue and returns to the scheduler within a defined period.
  • the scheduler then continues the scan cycle of the input queues. This avoids any task locking out others by processing a continuously busy input queue.
  • a task may be given an effectively higher priority by providing it with multiple entries in the scan table.
  • Database accesses are generally performed using access routines. This hides the internal structure of the database from other modules and also ensures that appropriate interlocks are applied to shared data.
  • the EM processes a single event from the input queue and then returns to the scheduler.
  • the MTM Xmit task processes a single event from its input queue and then returns control to the
  • the MTM Recv task processes events from the input queue until it is empty or a defined number (e.g. 10) events have been processed and then returns control to the scheduler.
  • the timer task processes a single event from the input queue and then returns control to the scheduler.
  • RTP continues to process frames until the input queue is empty or it has processed a defined number (e.g. 10) frames. It then returns to the scheduler.
  • the functions of the statistics module are:
  • stats_age e.g. stats_age, stats_incr and stats_rate;
  • RTP Real Time Parser
  • EM Event Manager
  • STATS defines the database and it contains subroutines for updating the statistics which it keeps.
  • STATS contains the type definitions for all statistics records (e.g. DLL, IP, TCP statistics). It provides an initialization routine whose major function is to allocate statistics records at startup from
  • Each type of statistics record has its own lookup routine (e.g. lookup_ip_address) which returns a pointer to a statistics record of the
  • STATS provides the routines to manipulate those statistics. For example, there is a routine to update counters. After the counter is incremented/decremented and if there is a non-zero threshold associated with the counter, the internal routine compares its value to the threshold. If the threshold has been exceeded, the Event Manager is signaled in order to send a trap to the
  • a count is a continuously incrementing variable which rolls around to 0 on overflow. It may be reset on command from the user (or from software).
  • a threshold may be applied to the count and will cause an alarm when the threshold count is reached. The threshold count fires each time the counter increments past the threshold value. For example, if the threshold is set to 5, alarms are generated when the count is 5, 10,-15,...
  • a rate is essentially a first derivative of a count variable. The rate is calculated at a period appropriate to the variable. For each rate variable, a minimum, maximum and average value is maintained.
  • Thresholds may be set on high values of the rate.
  • the maximums and minimums may be reset on command.
  • the threshold event is triggered each time the rate
  • the % is calculated at a period appropriate to the variable. For each % variable a minimum, maximum and average value is maintained. A threshold may be set on high values of the %. The threshold event is triggered each time the % calculated is in the threshold region.
  • a meter is a variable which may take any discrete value within a defined range. The current value has no correlation to past or future values.
  • a threshold may be set on a maximum and/or minimum value for a meter.
  • the rate and % fields of network event variables are updated differently than counter or meter fields in that they are calculated at fixed intervals rather than on receipt of data from the network.
  • Structures for statistics kept on a per address or per address pair basis are allocated at initialization time. There are several sizes for these structures.
  • Structures of the same size are linked together in a free pool. As a new structure is needed, it is obtained from a free queue, initialized, and linked into an active list. Active lists are kept on a per statistics type basis.
  • RTP code calls an appropriate lookup routine.
  • the lookup routine scans active statistics structures to see if a structure has already been
  • the lookup routine examines the appropriate parse control records to determine whether statistics should be kept, and, if so, it
  • the RTP updates statistics within the data base as it runs. This is done via macros defined for the RTP.
  • the macros call on internal routines which know how to manipulate the relevant statistic. If the pointer to the statistics structure is NULL, the internal routine will not be invoked.
  • the EM causes rates to be calculated.
  • the STATS module supplies routines (e.g. stats_rate) which must be called by the EM in order to perform the rate
  • TCP packets bytes, errors, retransmitted packets, retransmitted bytes, acks, rsts
  • the hourly rate is calculated from a sum of the last twelve 5 minute readings, as obtained from the buckets for the pertinent parameter. Each new reading replaces the oldest of the twelve values maintained.
  • STATS There are a number of other internal routines in STATS. For example, all statistical data collected by the Monitor is subject to age out. Thus, if no activity is seen for an address (or address pair) in the time period defined for age out, then the data is discarded and the space reclaimed so that it may be recycled. In this manner, the Monitor is able to use the memory for active elements rather than stale data. The user can select the age out times for the different components. The EM periodically kicks off the aging mechanism to perform this recycling of resources. STATS provides the routines which the EM calls, e.g. stats_age.
  • stats_de-allocate The allocate routine is called when stations and dialogs are picked up by the Network
  • the de-allocate routine is called by the aging routines when a structure is to be recycled.
  • Figs. 7a-c The general structure of the database within STATS is illustrated by Figs. 7a-c, which shows information that is maintained for the Data Link Layer (DLL) and its organization.
  • DLL Data Link Layer
  • a set of data structures is kept for each address associated with the layer.
  • there are three relevant addresses namely a segment address, indicating which segment the node is on, a MAC address for the node on the segment, and an address which
  • the dialog address is the combination of the MAC addresses for the two nodes which make up the dialog.
  • the overall data structure has three identifiable components: a segment address data structure (see Fig. 7a), a MAC address data structure (see Fig. 7b) and a dialog data structure (see Fig. 7c).
  • the segment address structure includes a doubly linked list 102 of segment address records 104, each one for a different segment address.
  • Each segment address record 104 contains a forward and backward link (field 106) for forward and backward pointers to neighboring records and a hash link (field 108).
  • the segment address records are accessed by either walking down the doubly linked list or by using a hashing
  • Each record also contains the address of the segment (field 110) and a set of fields for other information. Among these are a flags field 112, a type field 114, a parse_control field 116, and an EM_control field 118.
  • Flags field 112 contains a bit which indicates whether the identified address corresponds to the address of another Network Monitor. This field only has meaning in the MAC address record and not in the segment or dialog address record. Type field 114 identifies the MIB group which applies to this address. Parse control field 116 is a bit mask which indicates what subgroups of
  • Flags field 112, type field 114 and parse control field 116 make up what is referred to as the parse control record for this MAC address.
  • the Network Monitor uses a default value for parse control field 116 upon initialization or whenever a new node is detected. The default value turns off all statistics gathering. The statistics gathering for any particular address may subsequently be turned on by the Workstation through a Network Monitor control command that sets the appropriate bits of the parse control field to one.
  • EM_control field 118 identifies the subgroups of statistics within the MIB group that have changed since the EM last serviced the database to update rates and other variables. This field is used by the EM to
  • Each segment address record 104 also contains three fields for time related information. There is a start_time field 120 for the time that is used to perform some of the rate calculations for the underlying
  • the last_seen time is used to age out the data structure if no activity is seen on the segment after a preselected period of time elapses.
  • the first_seen time is a statistic which may be of interest to the network manager and is thus retrievable by the Management Workstation for display.
  • each segment address record includes a stats_pointer field 126 for a pointer to a DLL segment statistics data structure 130 which contains all of the statistics that are maintained for the segment address. If the bits in parse_control field 116 are all set to off, indicating that no statistics are to be maintained for the address, then the pointer in stats_pointer field 126 is a null pointer.
  • the list of events shown in data structure 130 of Fig. 7a illustrates the type of data that is collected for this address when the parse control field bits are set to on.
  • Some of the entries in DLL segment statistics data structure 130 are pointers to buckets for historical data. In the case where buckets are maintained, there are twelve buckets each of which represents a time period of five minutes duration and each of which generally contains two items of information, namely, a count for the corresponding five minute time period and a MAX rate for that time period. MAX rate records any spikes which have occurred during the period and which the user may not have observed because he was not viewing that
  • protocol_Q pointer 132 At the end of DLL segment statistics data structure 130, there is a protocol_Q pointer 132 to a linked list 134 of protocol statistics records 136 identifying all of the protocols which have been detected running on top of the DLL layer for the segment. Each record 136 includes a link 138 to the next record in the list, the identity of the protocol (field 140), a frames count for the number of frames detected for the
  • the MAC address data structure is organized in a similar manner to that of the segment data structure (see Fig. 7b).
  • a pointer 150 at the end of each MAC address record 148 points to a DLL address statistics data structure 152, which like the DLL segment address data structure 130, contains fields for all of the statitics that are gathered for that DLL MAC address.
  • Protocol statistics records 164 have the same structure and contain the same categories of information as their counterparts hanging off of DLL segment statistics data structure 130.
  • dialog record 172 includes the same categories of information as its counterpart in the DLL segment address data structure and the MAC address data structure.
  • the address field 174 contains the addresses of both ends of the dialog
  • the first and second addresses within the single address are arbitrarily designated nodes 1 and 2, respectively.
  • the stats_pointer field 176 there is a pointer to a dialog statistics data structure 178 containing the relevant statistics for the dialog.
  • the entries in the first two fields in this data structure i.e., fields 180 and 182 are designated protocol entries and protocols. Protocol entries is the number of different protocols which have been seen between the two MAC addresses. The protocols that have been seen are enumerated in the protocols field 182.
  • DLL dialog statistics data structure 178 illustrated by Fig. 7c, includes several additional fields of information which only appear in these
  • TCP connection structures for dialogs for which state information can be kept (e.g. TCP connection).
  • the additional fields identify the transport protocol (e.g., TCP) (field 184) and the application which is running on top of that protocol (field 186). They also include the identity of the initiator of the connection (field 188), the state of the connection (field 190) and the reason that the connection was closed, when it is closed (field 192).
  • a state_pointer (field 194) which points to a history data structure that will be described in greater detail later. Suffice it to say, that the history data structure contains a short history of events and states for each end of the dialog.
  • the state machine uses the information contained in the history data structure to loosely determine what the state of each of the end nodes is throughout the course of the connection. The qualifier "loosely" is used because the state machine does not closely shadow the state of the connection and thus is capable of recovering from loss of state due to lost packets or missed
  • RTP Real Time Parser
  • the RTP runs as an application task. It is scheduled by the Real Time Kernel scheduler when received frames are detected.
  • the RTP parses the frames and causes statistics, state tracking, and tracing operations to be performed.
  • the functions of the RTP are:
  • the design of the RTP is straightforward. It is a collection of routines which perform protocol parsing.
  • the RTP interfaces to the Real Time Kernel in order to perform RTP initialization, to be scheduled in order to parse frames, to free frames, to obtain and send an ITM to another task; and to report fatal errors.
  • the RTP is invoked by the scheduler when there is at least one frame to parse.
  • the appropriate parse routines are executed per frame. Each parse routine invokes the next level parse routine or decides that parsing is done.
  • Termination of the parse occurs on an error or when the frame has been completely parsed.
  • parse routine is a separately compilable module. In general, parse routines share very little data. Each knows where to begin parsing in the frame and the length of the data remaining in the frame.
  • This routine handles Ethernet, IEEE 802.3, IEEE 802.2, and SNAP; See RFC 1010, Assigned Numbers for a description of SNAP (Subnetwork Access Protocol).
  • ARP is parsed as specified in RFC 826.
  • IP Version 4 is parsed as specified in RFC 791 as amended by RFC 950, RFC 919, and RFC 922.
  • ICMP is parsed as specified in RFC 792.
  • UDP is parsed as specified in RFC 768.
  • TCP is parsed as specified in RFC 793.
  • SMTP is parsed as specified in RFC 821.
  • FTP is parsed as specified in RFC 959.
  • the Telnet protocol is parsed as specified in RFC 854.
  • the NFS protocol is parsed as specified in RFC 1094.
  • the RTP calls routines supplied by STATS to look up data structures. By calling these lookup routines, global pointers to data structures are set up. Following are examples of the pointers to statistics data
  • ip_src_segment ip_dst_segment, ip_this_segment, ip_src, ip_dst, ip_dialog
  • the mac_src and mac_dst routines return pointers to the data structures within STATS for the source MAC address and the destination MAC address, respectively.
  • the lookup_mac_dialog routine returns a pointer to the data structure within STATS for the dialog between the two nodes on the MAC layer.
  • the other STATS routines supply similar pointers for data structures relevant to other protocols.
  • the RTP routines are aware of the names of the statistics that must be manipulated within the data base (e.g. frames, bytes) but are not aware of the structure of the data.
  • the RTP routine invokes a macro which manipulates the
  • the macros use the global pointers which were set up during the lookup process described above.
  • the RTP routine examines the destination mac and ip addresses. If either of the addresses is that of the Network Monitor, RTP obtains a low priority ITM, initializes it, and sends the ITM to the MTM task. One of the fields of the ITM contains the address of the buffer containing the frame.
  • the RTP must hand some received frames to the EM in order to accomplish the autotopology function
  • the RTP routine examines the source mac and ip addresses. If either of the addresses is that of another Network
  • RTP obtains a low priority ITM, initializes it and sends the ITM to the EM task.
  • the address data structure (in particular, the flags field of the parse control record) within STATS for the MAC or the IP address indicates whether the source address is that of another Network Monitor.
  • One of the fields of the ITM contains the address of the buffer containing the frame.
  • the RTP receives traffic frames from the network for analysis.
  • RTP operation may be modified by sending control messages to the Monitor.
  • RTP first parses these messages, then detects that the messages are destined for the Monitor and passes them to the MTM task. Parameters which affect RTP operation may be changed by such control messages.
  • the state machine determines and keeps state for both addresses of all TCP connections.
  • TCP is a connection oriented transport protocol, and TCP clearly defines the connection in terms of states of the connection.
  • connectionless protocols such as NFS.
  • connection oriented protocol the principles are
  • the RTP parses the information for that layer to identify the event associated with that packet. It then passes the
  • the state machine determines what the current state of the node is.
  • the code within the state machine determines the state of a connection based upon a set of rules that are illustrated by the event/state table shown in Fig. 8.
  • the interpretation of the event/state table is as follows.
  • the top row of the table identifies the six possible states of a TCP connection. These states are not the states defined in the TCP protocol specification.
  • the left most column identifies the eight events which may occur during the course of a connection.
  • Within the table is an array of boxes, each of which sits at the intersection of a particular event/state combination. Each box specifies the actions taken by the state machine if the identified event occurs while the connection is in the identified state. When the state machine receives a new event, it may perform three types of action. It may change the recorded state for the node.
  • close timer expires and inactivity timer expires.
  • the close timer which is specified by TCP, is started at the end of a connection and it
  • the inactivity timer is not specified by TCP but rather is part of the Network Monitor's resource management functions. Since keeping statistics for dialogs (especially old dialogs) consumes resources, it is desirable to recycle resources for a dialog if no activity has been seen for some period of time.
  • the inactivity timer provides the mechanism for accomplishing this. It is restarted each time an event for the
  • connection is received. If the inactivity timer expires (i.e., if no event is received before the timer period ends), the connection is assumed to have gone inactive and all of the resources associated with the dialog are recycled. This involves freeing them up for use by other dialogs.
  • the other states and events within the table differ from but are consistent with the definitions provided by TCP and should be self evident in view of that protocol specification.
  • the event/state table can be read as follows.
  • node 1 is in DATA state and the RTP receives another packet from node 1 which it
  • the state machine determines to be a TCP FIN packet. According to the entry in the table at the intersection of FIN/DATA (i.e., event/state), the state machine sets the state of the connection for node 1 to CLOSING, it decrements the active connections counter and it starts the close timer. When the close timer expires, assuming no other events over that connection have occurred, the state machine sets node 1's state to CLOSED and it starts the
  • the state machine sets node 1's state to
  • the Network Monitor When a connection is first seen, the Network Monitor sets the state of both ends of the connection to UNKNOWN state. If some number of data and acknowledgment frames are seen from both connection ends, the states of the connection ends may be promoted to DATA state. The connection history is searched to make this determination as will be described shortly.
  • a history data structure 200 which the state machine uses to remember the current state of the connection, the state of each of the nodes participating in the
  • History data structure 200 is identified by a state_pointer found at the end of the associated dialog statistics data structure in STATS (see Fig. 7c). within history data structure 200, the state machine records the current state of node 1 (field 202), the current state of node 2 (field 206) and other data relating to the
  • the other data includes, for example, the window size for the receive and transmit communications, the last detected sequence numbers for the data and acknowledgment frames, and other data transfer information.
  • History data structure 200 also includes a history table (field 212) for storing a short history of events which have occurred over the connection and it includes an index to the next entry within the history table for storing the information about the next received event (field 210).
  • the history table is implemented as a circular buffer which includes sufficient memory to store, for example, 16 records.
  • Each record shown in Fig. 9b, stores the state of the node when the event was detected (field 218), the event which was detected (i.e., received) (field 220), the data field length (field 222), the sequence number (field 224), the acknowledgment sequence number (field 226) and the identity of the initiator of the event, i.e., either node 1 or node 2 or 0 if neither (field 228).
  • promiscuous mode it may occasionally fail to detect or it may, due to overload, lose a packet within a
  • the state machine may not be able to accurately determine the state of the
  • the state machine uses one of the two previously mentioned routines, namely,
  • Look_for_Data_State routine 230 searches back through the history one record at a time until it finds evidence that the current state is DATA state or until it reaches the end of the circular buffer (step 232).
  • Routine 230 detects the existence of DATA state by determining whether node 1 and node 2 each have had at least two data events or two acknowledgment combinations with no intervening connect, disconnect or abort events (step 234). If such a sequence of events is found within the history, routine 230 enters both node 1 and node 2 into DATA state (step 236), it increments the active connections counter (step 238) and then it calls a Look_for_Initiator routine to look for the initiator of the connection (step 240). If such a pattern of events is not found within the history, routine 230 returns without changing the state for the node (step 242).
  • Look_for_Initiator routine 240 also searches back through the history to detect a telltale event pattern which identifies the actual initiator of the connection (step 244). More
  • routine 240 determines whether nodes 1 and 2 each sent connect-related packets. If they did, routine 240 identifies the initiator as the first node to send a connect-related packet (step 246). If the search is not successful, the identity of the connection
  • the Look_at_History routine is called to check back through the history to determine whether data transmissions have been repeated. In the case of
  • the routine calls a
  • Routine 250 searches back through the history (step 252) and checks whether the same initiator node has sent data twice (step 254). It detects this by comparing the current sequence number of the packet as provided by the RTP with the sequence numbers of data packets that were previously sent as reported in the history table. If a retransmission is spotted, the retransmission counter in the dialog
  • the Network Monitor Even if frames are missed by the Network Monitor, because it is not directly "shadowing" the connection, the Network Monitor still keeps useful statistics about the connection. If inconsistencies are detected the Network Monitor counts them and, where appropriate, drops back to UNKNOWN state. Then, the Network Monitor waits for the connection to stabilize or deteriorate so that it can again determine the appropriate state based upon the history table.
  • the transactions which represent the major portion of the processing load within the Monitor include monitoring, actions on threshold alarms, processing database get/set requests from the Management
  • a statistics threshold event i.e., an alarm event
  • Fig. 14 The major steps which follow a statistics threshold event (i.e., an alarm event) are shown in Fig. 14. The steps are as follows:
  • a database update request i.e., a get/set request
  • the steps are as follows:
  • LAN ISR receives frame from network and passes it to RTP for parsing
  • MTM Recv processes protocol stack.
  • MTM Recv sends database update request ITM to EM.
  • Fig. 16 The major steps in processing of a monitor control request from the Management Workstation are shown in Fig. 16. The steps are as follows:
  • MTM Recv sends request ITM to EM.
  • Control performs requested operation and generates response to EM.
  • Management Workstation is based on the SNMP definition (RFC 1089 SNMP; RFC 1065 SMI; RFC 1066 SNMP MIB - Note: RFC means Request for Comments). All five SNMP PDU types are supported:
  • the SNMP MIB extensions are designed such that where possible a user request for data maps to a single complex MIB object. In this manner, the get-request is simple and concise to create, and the response should contain all the data necessary to build the screen. Thus, if the user requests the IP statistics for a segment this maps to an IP Segment Group.
  • the data in the Monitor is keyed by addresses (MAC, IP) and port numbers (telnet, FTP).
  • addresses MAC, IP
  • port numbers telnet, FTP
  • the user may wish to relate his data to physical nodes entered into the network map.
  • the mapping of addresses to physical nodes is controlled by the user (with support from the Management Workstation system where possible) and the Workstation retains this information so that when a user requests data for node 'Joe' the Workstation asks the Monitor for the data for the appropriate address(es).
  • the node to address mapping need not be one to one.
  • TFTP Trivial File Transfer Protocol
  • the Monitor to Workstation interface follows the SNMP philosophy of operating primarily in a polled mode.
  • the Workstation acts as the master and polls the Monitor slaves for data on a regular (configurable) basis.
  • the information communicated by the SNMP is represented according to that subset of ASN.1 (ISO 8824 Specification of ASN.1) defined in the Internet standard Structure of Management Information (SMI - RFC 1065).
  • MIB Management Information Base
  • Workstation is defined in Appendix III.
  • the added value provided by the Workstation is encoded as enterprise specific extensions to the MIB as defined in Appendix IV.
  • the format for these extensions follows the SMI
  • x is an enterprise specific node identifier assigned by the IAB.
  • the Management Workstation :
  • the Management Workstation is a SUN Sparcstation (also referred to as a Sun) available from Sun
  • Microsystems, Inc. It is running the Sun flavor of Unix and uses the Open Look Graphical User Interface (GUI) and the SunNet Manager as the base system. The options required are those to run SunNet Manager with some additional disk storage requirement.
  • GUI Open Look Graphical User Interface
  • the network is represented by a logical map illustrating the network components and the relationships between them, as shown in Fig. 17.
  • a hierarchical network map is supported with navigation through the layers of the hierarchy, as provided by SNM.
  • Management Workstation determines the topology of the network and informs the user of the network objects and their connectivity so that he can create a network map. To assist with the map creation process, the Management Workstation attempts to determine the stations connected to each LAN segment to which a Monitor is attached.
  • each station in the network is monitored by a single Monitor that is located on its local segment.
  • the initial determination of the Monitor responsible for a station is based on the results of the autotopology mechanism. The user may override this initial default if required.
  • the user is informed of new stations appearing on any segment in the network via the alarm mechanism. As for other alarms, the user may select whether stations appearing on and disappearing from the network segment generate alarms and may modify the times used in the aging algorithms. When a new node alarm occurs, the user must add the new alarm to the map using the SNM tools. In this manner, the SNM system becomes aware of the nodes.
  • the Management Workstation needs to have the previous location information in order to know which Network Monitors to involve in autotopology. For
  • two nodes with the same IP address may exist in separate segments of the network.
  • the history makes possible the correlation of the addresses and it makes possible duplicate address detection.
  • the Monitor issues a trap to the
  • An alarm is issued to the user indicating the presence of the new Monitor and whether it can be supported.
  • the Monitor data is issued using SNMP set
  • the SNMP proxy rereads in the (updated) SNMP.HOSTS file which now includes the new Monitor. Also note that the SNMP hosts file need only contain the Monitors, not the entire list of nodes in the system.
  • the user is responsible for entering data into the SNM database manually.
  • the Workstation monitors the file write date for the SNM database. When this is different from the last date read, the SNM database is reread and the Workstation database
  • the database is created from the data in the SNM file system (which the user has possibly updated). This data is checked for consistency and for conformance to the limits imposed by the Workstation at this time and a warning is generated to the user if any problems are seen. If the data errors are minor the system continues operation; if they are fatal the user is asked to correct them and Workstation operation terminates.
  • the monitoring functions of the Management Workstation are provided as an extension to the SNM system. They consist of additional display tools (i.e., summary tool, values tool, and set tool) which the user invokes to access the Monitor options and a Workstation event log in which all alarms are recorded.
  • additional display tools i.e., summary tool, values tool, and set tool
  • the Monitor makes a large number of statistics available to the operator. These are available for examination via the Workstation tools that are provided.
  • the Monitor statistics (or a selected subset thereof) can be made visible to any SNMP manager by providing it with knowledge of the extended MIB. A description of the statistics maintained are described elswhere.
  • Network event statistics are maintained on a per network, per segment and per node basis. Within a node, statistics are maintained on a per address (as
  • Per network statistics are always derived by the Workstation from the per segment variables maintained by the Monitors.
  • Subsets of the basic statistics are maintained on a node to node and segment to segment basis. If the user requests displays of segment to segment traffic, the Workstation calculates this data as follows.
  • the inter segment traffic is derived from the node to node statistics for the intersecting set of nodes. Thus, if segment A has nodes 1, 2, and 3 and segment B has nodes 20, 21, and 22, then summing the node to node traffic for
  • On-LAN/off-LAN traffic for segments is calculated by a simply summing node to node traffic for all stations on the LAN and then subtracting this from total segment counts.
  • Alarms received are logged in a Workstation log.
  • the node status change is propagated up through the (map) hierarchy to support the case where the node is not visible on the screen. This is as provided by SNM.
  • the summary tool After the user has selected an object from the map and invokes the display tools, the summary tool generates the user's initial screen at the Management Workstation. It presents a set of statistical data selected to give an overview of the operational status of the object (e.g., a selected node or segment) .
  • the Workstation polls the
  • the Summary Tool displays a basic summary tool screen such as is shown in Fig. 18.
  • the summary tool screen has three panels, namely, a control panel 602, a values panel 604, and a dialogs panel 606.
  • the control panel includes the indicated mouse activated bottons.
  • the functions of each of the buttons is as follows.
  • the file button invokes a traditional file menu.
  • the view button invokes a view menu which allows the user to modify or tailor the visual protperties of the tool.
  • the properties button invokes a properties menu containing choices for viewing and sometimes modifying the
  • the tools button invokes a tools menu which provides access to the other Workstation tools, e.g. Values Tool.
  • the Update Interval field allows the user to specify the frequency at which the displayed statistics are updated by polling the Monitor.
  • the Update Once button enables the user to retrieve a single screen update. When the Update Once button is invoked not only is the screen updated but the update interval is
  • the type field enables the user to specify the type of network objects on which to operate, i.e., segment or node.
  • the name button invokes a pop up menu containing an alphabetical list of all network objects of the type selected and apply and reset buttons.
  • the required name can then be selected from the (scrolling) list and it will be entered in the name field of the summary tool when the apply button is invoked.
  • the user may enter the name directly in the summary tool name field.
  • the protocol button invokes a pop up menu which provides an exclusive set of protocol layers which the user may select. Selection of a layer copies the layer name into the displayed field of the summary tool when the apply operation is invoked.
  • An example of a protocol selection menu is shown in Fig. 19. It displays the available protocols in the form of a protocol tree with multiple protocol familes. The protocol selection is two dimensional. That is, the user first selects the
  • the user invokes the apply button to indicate that the selection process is complete and the type, name, protocol, etc. should be applied. This then updates the screen using the new parameter set that the user
  • the reset button is used to undo the
  • the set of statistics for the selected parameter set is displayed in values panel 604.
  • the members of the sets differ depending upon, for example, what protocol was selected.
  • Figs. 20a-g present examples of the types of statistical variables which are displayed for the DLL, IP, UDP, TCP, ICMP, NFS, and ARP/RARP protocols,
  • Dialogs panel 606 contains a display of the connection statistics for all protocols for a selected node. Within the Management Workstation, connection lists are maintained per node, per supported protocol. When connections are displayed, they are sorted on "Last Seen" with the most current displayed first. A single list returned from the Monitor contains all current connection. For TCP, however, each connection also contains a state and TCP connections are displayed as Past and Present based upon the returned state of the connection. For certain dialogs, such as TCP and NFS over UDP, there is an associated direction to the dialog, i.e., from the initiator (source) to the receiver (sink). For these dialogs, the direction is identified in a DIR. field. A sample of information that is displayed in dialogs panel 606 is presented in Fig. 21 for current connections.
  • the values tool provides the user with the ability to look at the statistical database for a network object in detail.
  • the user invokes this tool he may select a basic data screen containing a rate values panel 620, a count values panel 622 and a protocols seen panel 626, as shown in Fig. 22, or he may select a traffic matrix screen 628, as illustrated in Fig. 23.
  • value tools presents the monitored rate and count statistics, respectively, for a selected protocol. The parameters which are displayed for the different
  • Appendix II protocols (i.e., different groups) are listed in Appendix II.
  • a data element that is being displayed for a node shows up in three rows, namely, a total for the data element, the number into the data element, and the number out of the data element. Any exceptions to this are identified in Appendix II. Data elements that are displayed for segments, are presented as totals only, with no distinction between Rx and Tx.
  • the Values Tool When invoked the Values Tool displays a primary screen to the user.
  • the primary screen contains what is considered to be the most significant information for the selected object.
  • the user can view other information for the object (i.e., the statistics for the other
  • the displayed information for the count values and rate values panels 620 and 622 includes the following.
  • An alarm field reports whether an alarm is currently active for this item. It displays as "*" if active alarm is present.
  • a Current Value/Rate field reports the current rate or the value of the counter used to generate threshold alarms for this item. This is reset following each threshold trigger and thus gives an idea of how close to an alarm threshold the variable is.
  • a Typical Value field reports what this item could be expected to read in a "normal" operating situation. This field is filled in for those items where this is predictable and useful. It is maintained in the Workstation database and is modifiable by the user using the set tool.
  • Accumulated Count field reports the current accumulated value of the item or the current rate.
  • a Max Value field reports the highest value recently seen for the item.
  • This value is reset at intervals defined by a user adjustable parameter (default 30 minutes). This is not a rolling cycle but rather represents the highest value since it was reset which may be from 1 to 30 minutes ago (for a rest period of 30 minutes). It is used only for rates.
  • a Min Value field reports the lowest value recently seen for the item. This operates in the same manner as Max Value field and is used only for rates.
  • the set tool provides the user with the ability to modify the parameters controling the operation of the Monitors and the Management Workstation.
  • parameters affect both user interface displays and the actual operation of the Monitors.
  • the parameters which can be operated on by the set tool can be divided into the following categories: alarm thresholds, monitoring control, segment Monitor administration, and typical values.
  • the monitoring control variables specify the actions of the segment Monitors and each Monitor can have a distinct set of control variables (e.g., the parse control records that are described elsewhere).
  • the user is able to define those nodes, segments, dialogs and protocols in which he is interested so as to make the best use of memory space available for data storage.
  • This mechanism allows for load sharing, where mulitple Monitors on the same segment can divide up the total number of network objects which are to be monitored so that no duplication of effort between them takes place.
  • the monitor administration variables allow the user to modify the operation of the segment Monitor in a more direct manner than the monitoring control variables. Using the set tool, the user can perform those operations such as reset, time changes etc. which are normally the prerogative of a system administrator.
  • the Workstation sets the thresholds in the Network Monitor based upon the performance of the system as observed over an extended period of time. That is, the Workstation periodically samples the output of the
  • Network Monitors and assembles a model of a normally functioning network. Then, the Workstation sets the thresholds in the Network Monitors based upon that model. If the observation period is chosen to be long enough and since the model represents the "average" of the network performance over the observation period, temporary undesired deviations from normal behavior are smoothed out over time and model tends to accurately reflect normal network behavior.
  • the details of the training procedure for adaptively setting the Network Monitor thresholds are as follows. To begin training, the
  • the Workstation sends a start learning command to the Network Monitors from which performance data is desired (step 302).
  • the start learning command disables the thresholds within the Network Monitor and causes the Network Monitor to periodically send data for a predefined set of network parameters to the Management Workstation. (Disabling the thresholds, however, is not necessary. One could have the learning mode operational in parallel with monitoring using existing thresholds.)
  • the set of parameters may be any or all of the previously mentioned parameters for which thresholds are or may be defined.
  • the Network Monitor sends "snapshots" of the network's performance to the Workstation which, in turn, stores the data in a performance history database 306 (step 304).
  • the network manager sets the length of the learning period. Typically, it should be long enough to include the full range of load conditions that the network experiences so that a representative performance history is generated. It should also be long enough so that short periods of overload or faulty behavior do not distort the resulting averages.
  • the network manager After the learning period has expired, the network manager, through the Management Workstation, sends a stop learning command to the Monitor (step 308).
  • the Monitor ceases automatically sending further performance data updates to the Workstation and the Workstation processes the data in its performance history database (step 310).
  • the processing may involve simply computing averages for the parameters of interest or it may involve more
  • the Workstation After the Workstation has statistically analyzed the performance data, it computes a new set of thresholds for the relevant performance parameters (step 312). To do this, it uses formulas which are appropriate to the particular parameter for which a threshold is being computed. That is, if the parameter is one for which one would expect to see wide variations in its value during network monitoring, then the threshold should be set high enough so that the normal expected variations do not trigger alarms. On the other hand, if the parameter is of a type for which only small variations are expected and larger variations indicate a problem, then the
  • threshold should be set to a value that is close to the average observed value. Examples of formulae which may be used to compute thresholds are:
  • the Workstation loads them into the Monitor and instructs the Monitor to revert to normal monitoring using the new thresholds (step 314).
  • This procedure provides a mechanism enabling the network manager to adaptively reset thresholds in
  • the network manager merely invokes the adaptive threshold setting feature and updates the thresholds to reflect those changes.
  • the Diagnostic Analyzer Module is the Diagnostic Analyzer Module
  • the Management Workstation includes a diagnostic analyzer module which automatically detects and diagnoses the existence and cause of certain types of network problems.
  • the functions of the diagnostic module may actually be distributed among the Workstation and the Network Monitors which are active on the network.
  • the diagnostic analyzer module includes the following elements for performing its fault detection and analysis functions.
  • the Management Workstation contains a reference model of a normally operating network.
  • the reference model is generated by observing the performance of the network over an extended period of time and computing averages of the performance statistics that were observed during the observation period.
  • the reference model provides a reference against which future network
  • the Network Monitor (in particular, the STATS module) includes alarm thresholds on a selected set of the parameters which it monitors. Some of those thresholds are set on parameters which tend to be
  • the Network Monitor alerts the Network Monitor.
  • the Workstation by sending an alarm.
  • the Workstation
  • the Workstation notifies the user and presents the user with the option of either ignoring the alarm or invoking a diagnostic algorithm to analyze the problem. If the user invokes the diagnostic algorithm, the Workstation compares the current performance statistics to its reference model to analyze the problem and report its results. (Of course, this may also be handled automatically so as to not require user intervention.) The Workstation obtains the data on current performance of the network by retrieving the relevant performance statistics from all of the segment Network Monitors that may have information useful to diagnosing the problem. The details of a specific example involving poor TCP connection performance will now be described. This example refers to a typical network on which the
  • diagnostic analyzer resides, such as the network
  • Fig. 25 It includes three segments labelled S1, S2, and S3, a router R1 connecting S1 to S2, a router R2 connecting S2 to S3, and at least two nodes, node A on S1 which communicates with node B on S3.
  • a Management Workstation 320 is also located on S1 and it includes a diagnostic analyzer module 322. For this example, the sympton of the network problem is degraded peformance of a TCP connection between Nodes A and B.
  • a TCP connection problem may manifest itself in a number of ways, including, for example, excessively high numbers for any of the following:
  • the Monitor is programmed to recognize any one or more of these
  • the Monitor sends an alarm to the Workstation.
  • Workstation is programmed to recognize the particular alarm as related to an event which can be further
  • the Workstation presents the user with the option of invoking its diagnostic capabilities (or automatically invokes the diagnostic capabilities).
  • the diagnostic analyzer when invoked, it looks at the performance data that the segment Monitors produce for the two nodes, for the dialogs between them and for the links that interconnect them and compares that data to the reference model for the network. If a significant divergence from the reference model is identified, the diagnostic analyzer informs the Workstation (and the user) about the nature of the divergence and the likely cause of the problem. In conducting the comparison to "normal" network
  • communications between nodes A and B is decomposed into its individual components and diagnostic analysis is performed on each link individually in the effort to isolate the problem further.
  • diagnostic algorithm 400 When invoked for analyzing a possible TCP problem between nodes A and B, diagnostic analyzer 322 checks for a TCP problem at node A when it is acting as a source node (step 402). To perform this check, diagnostic algorithm 400 invokes a source node analyzer algorithm 450 shown in Fig. 27. If a problem is identified, the Workstation reports that there is a high probability that node A is causing a TCP problem when operating as a source node and it reports the results of the investigation performed by algorithm 450 (step 404).
  • diagnostic analyzer 322 checks for evidence of a TCP problem at node B when it is acting as a sink node (step 406). To perform this check, diagnostic algorithm 400 invokes a sink node analyzer algorithm 470 shown in Fig. 28. If a problem is identified, the Workstation reports that there is a high probability that node B is causing a TCP problem when operating as a sink node and it reports the results of the investigation performed by algorithm 470 (step 408).
  • source and sink nodes are concepts which apply to those dialogs for which a direction of the communication can be defined.
  • the source node may be the one which initiated the dialog for the purpose of sending data to the other node, i.e., the sink node.
  • diagnostic analyzer 322 checks for evidence of a TCP problem on the link between Node A and Node B (step 410). To perform this check, diagnostic algorithm 400 invokes a link analysis algorithm 550 shown in Fig. 29. If a problem is
  • the Workstation reports that there is a high probability that a TCP problem exists on the link and it reports the results of the investigation performed by link analysis algorithm 550 (step 412).
  • diagnostic analyzer 322 checks for evidence of a TCP problem at node B when it is acting as a source node (step 414). To perform this check, diagnostic algorithm 400 invokes the previously mentioned source algorithm 450 for Node B. If a problem is identified, the Workstation reports that there is a medium
  • diagnostic analyzer 322 checks for a TCP problem at node A when it is acting as a sink node (step 418). To perform this check, diagnostic algorithm 400 invokes sink node analyzer algorithm 470 for Node A. If a problem is identified, the Network Monitor reports that there is a medium probability that node A is causing a TCP problem when operating as a sink node and it reports the results of the investigation performed by algorithm 470 (step 420).
  • diagnostic analyzer 322 reports that it was not able to isolate the cause of a TCP problem (step 422).
  • source node analyzer algorithm 450 checks whether a particular node is causing a TCP problem when operating as a source node.
  • the strategy is as follows. To determine whether a TCP problem exists at this node which is the source node for the TCP connection, look at other connections for which this node is a source. If other TCP connections are okay, then there is probably not a problem with this node. This is an easy check with a high probability of being correct. If no other good connections exist, then look at the lower layers for possible reasons. Start at DLL and work up as problems at lower layers are more fundamental, i.e., they cause problems at higher layers whereas the reverse is not true.
  • algorithm 450 first determines whether the node is acting as a source node in any other TCP connection and, if so, whether the other connection is okay (step 452). If the node is performing satisfactorily as a source node in another TCP connection, algorithm 450 reports that there is no problem at the source node and returns to diagnostic algorithm 400 (step 454). If algorithm 450 cannot identify any other TCP connections involving this node that are okay, it moves up through the protocol stack checking each level for a problem. In this case, it then checks for DLL problems at the node when it is acting as a source node by calling an DLL problem checking routine 510 (see Fig. 30) (step 456).
  • step 458 If a DLL problem is found, that fact is reported (step 458). If no DLL problems are found, algorithm 450 checks for an IP problem at the node when it is acting as a source by calling an IP problem checking routine 490 (see Fig. 31) (step 460). If an IP problem is found, that fact is reported (step 462). If no IP problems are found, algorithm 450 checks whether any other TCP connection in which the node participates as a source is not okay (step 464). If another TCP connection involving the node exists and it is not okay, algorithm 450 reports a TCP problem at the node (step 466). If no other TCP connections where the node is acting as a source node can be found, algorithm 450 exits.
  • sink node analyzer algorithm 470 checks whether a particular node is causing a TCP problem when operating as a sink node. It first
  • step 472 determines whether the node is acting as a sink node in any other TCP connection and, if so, whether the other connection is okay (step 472). If the node is performing satisfactorily as a sink node in another TCP connection, algorithm 470 reports that there is no problem at the source node and returns to diagnostic algorithm 400 (step 474). If algorithm 470 cannot identify any other TCP connections involving this node that are okay, it then checks for DLL problems at the node when it is acting as a sink node by calling DLL problem checking routine 510 (step 476). If a DLL problem is found, that fact is reported (step 478).
  • algorithm 470 checks for an IP problem at the node when it is acting as a sink by calling IP problem checking routine 490 (step 480). If an IP problem is found, that fact is reported (step 482). If no IP problems are found, algorithm 470 checks whether any other TCP
  • step 484 If another TCP connection involving the node as a sink exists and it is not okay, algorithm 470 reports a TCP problem at the node (step 486). If no other TCP connections where the node is acting as a sink node can be found, algorithm 470 exits.
  • IP problem checking routine 490 checks for IP problems at a node. It does this by comparing the IP performance statistics for the node to the reference model (steps 492 and 494). If it detects any significant deviations from the reference model, it reports that there is an IP problem at the node (step 496). If no significant deviations are noted, it reports that there is no IP problem at the node (step 498).
  • DLL problem checking routine 510 operates in a similar manner to IP problem checking routine 490, with the exception that it examines a different set of parameters (i.e., DLL
  • link analysis logic 550 first determines whether any other TCP connection for the link is operating properly (step 552). If a properly operating TCP connection exists on the link, indicating that there is no link problem, link analysis logic 550 reports that the link is okay (step 554). If a properly operating TCP connection cannot be found, the link is decomposed into its constituent components and an IP link component problem checking routine 570 (see Fig. 32) is invoked for each of the link components (step 556). IP link component problem routine 570 evaluates the link component by checking the IP layer statistics for the relevant link component. The decomposition of the link into its components arranges them in order of their distance from the source node and the analysis of the components proceeds in that order. Thus, for example, the link components which make up the link between nodes A and B include in order:
  • IP data for these various components are
  • IP link component problem checking routine 570 compares IP statistics for the link component to the reference model (step 572) to determine whether network performance deviates significantly from that specified by the model (step 574). If significant deviations are detected, routine 570 reports that there is an IP problem at the link component (step 576).
  • logic 550 then invokes a DLL link component problem checking routine 580 (see Fig. 33) for each link component to check its DLL statistics (step 558).
  • DLL link problem routine 580 is similar to IP link problem routine 570. As shown in Fig. 33, DLL link problem checking routine 580 compares DLL statistics for the link to the reference model (step 582) to determine whether network performance at the DLL deviates
  • routine 580 reports that there is a DLL problem at the link component (step 586). Otherwise, it reports that no DLL problems were found (step 588).
  • logic 550 checks whether there is any other TCP on the link (step 560). If another TCP exists on the link
  • logic 550 reports that there is a TCP problem on the link (step 562). Otherwise, logic 550 reports that there was not enough information from the existing packet traffic to determine whether there was a link problem (step 564)
  • the user may send test messages to those components to generate the information needed to evaluate its performance.
  • the reference model against which comparisons are made to detect and isolate malfunctions may be generated by examining the behavior of the network over an extended period of operation or over multiple periods of operation. During those periods of operation, average values and maximum excursions (or standard deviations) for observed statistics are computed. These values provide an initial estimate of a model of a properly functioning system. As more experience with the network is obtained and as more historical data on the various statistics is accumulated the thresholds for detecting actual malfunctions or imminent malfunctions and the reference model can be revised to reflect the new
  • the acceptable ranges of variation can be determined by watching network performance over a
  • the parameters which tend to provide useful information for identifying and isolating problems at the node level for the different protocols and layers include the following.
  • the above- identified parameters are also useful with the addition of the alignment rate and the collision rate at the DLL. All or some subset of these parameters may be included among the set of parameters which are examined during the diagnostic procedure to detect and isolate network problems.
  • the RTP is programmed to detect the occurrence of certain transactions for which timing information is desired.
  • the transactions typically occur within a dialog at a particular layer of the protocol stack and they involve a first event (i.e., an initiating event) and a subsequent partner event or response.
  • the events are protocol messages that arrive at the Network Monitor, are parsed by the RTP and then passed to Event Timing Module (ETM) for processing.
  • ETM Event Timing Module
  • a transaction of interest might be, for example, a read of a file on a server. In that case, the initiating event is the read request and the partner event is the read response.
  • the time of interest is the time required to receive a response to the read request (i.e., the
  • the transaction time provides a useful measure of network performance and if measured at various times throughout the day under different load conditions gives a measure of how different loads affect network response times.
  • the layer of the communicaton protocol at which the relevant dialog takes place will of course depend upon the nature of the event.
  • the RTP when the RTP detects an event, it transfers control to the ETM which records an arrival time for the event. If the event is an initiating event, the ETM stores the arrival time in an event timing database 300 (see Fig. 34) for future use. If the event is a partner event, the ETM computes a difference between that arrival time and an earlier stored time for the initiating event to determine the complete transaction time.
  • Event timing database 300 is an array of records 302.
  • Each record 302 includes a dialog field 304 for identifying the dialog over which the transactions of interest are occurring and it includes an entry type field 306 for identifying the event type of interest.
  • Each record 302 also includes a start time field 308 for storing the arrival time of the initiating event and an average delay time field 310 for storing the computed average delay for the transactions.
  • the RTP detects the arrival of a packet of the type for which timing information is being kept, it passes control to the ETM along with relevant information from the packet, such as the dialog identifier and the event type (step 320).
  • the ETM determines whether it is to keep timing
  • each event type can have multiple occurrences (i.e., there can be
  • the dialog identifier is used to distinguish between events of the same type for different dialogs and to identify those for which information has been requested. All of the dialog/events of interest are identified in the event timing database. If the current dialog and event appear in the event timing database, indicating that the event should be timed, the ETM determines whether the event is a starting event or an ending event so that it may be processed properly (step 324). For certain events, the absence of a start time in the entry field of the appropriate record 302 in event timing database 300 is one indicator that the event represents a start time; otherwise, it is an end time event. For other events, the ETM determines if the start time is to be set by the event type as
  • each protocol event will have its own
  • the arrival time is only an estimate of the actual arrival time due to possible queuing and other processing delays. Nevertheless, the delays are
  • step 324 if the event represents a start time, the ETM gets the current time from the kernal and stores it in start time field 308 of the appropriate record in event timing database 300 (step 326). If the event represents an end time event, the ETM obtains the current time from the kernel and computes a difference between that time and the corresponding start time found in event timing database 300 (step 328). This represents the total time for the transaction of interest. It is combined with the stored average transaction time to compute a new running average transaction time for that event (step 330).
  • New Avg. [(5 * Stored Avg.) + Transaction Time]/6.
  • the computed new average becomes a running average for the transaction times.
  • the ETM stores this computed average in the appropriate record of event timing database 300,
  • the ETM After processing the event in steps 322, 326, and 330, the ETM checks the age of all of the start time entries in the event timing database 300 to determine if any of them are too “old” (step 332). If the difference between the current time and any of the start times exceeds a preselected threshold, indicating that a partner event has not occurred within a reasonable period of time, the ETM deletes the old start time entry for that dialog/event (step 334). This insures that a missed packet for a partner event does not result in an
  • Node A of Fig. 25 is communicating with Node B using the NFS protocol.
  • Node A is the client while Node B is the server.
  • the Network Monitor resides on the same segment as node A, but this is not a
  • Node A issues a read request to Node B
  • the Network Monitor sees the request and the RTP within the Network Monitor transfers control to the ETM. Since it is a read, the ETM stores a start time in the Event Timing Database. Thus, the start time is the time at which the read was initiated.
  • node B After some delay, caused by the transmission delays of getting the read message to node B, node B performs the read and sends a response back to node A. After some further transmission delays in returning the read response, the Network Monitor receives the second packet for the event. At the time, the ETM recognizes that the event is an end time event and updates the average transaction time entry in the appropriate record with a new computed running average. The ETM then
  • node A is communicating with Node B using the Telnet protocol.
  • Telnet is a virtual terminal protocol. The events of interest take place long after the initial connection has been
  • Node A is typing at a standard ASCII (VT100 class) terminal which is logically (through the network) connected to Node B.
  • Node B has an application which is receiving the characters being typed on Node A and, at appropriate times, indicated by the logic of the
  • information include, for example, the amount of time it takes to echo characters typed at the keyboard through the network and back to the display screen, the delay between typing an end of line command and seeing the completion of the application event come back or the network delays incurred in sending a packet and receiving acknowledgment for when it was received.
  • the particular time being measured is the time it takes for the network to send a packet and receive an acknowledgement that the packet has arrived. Since Telnet runs on top of TCP, which in turn runs on top of IP, the Network Monitor monitors the TCP acknowledge end-to-end time delays.
  • Node A When Node A transmits a data packet to Node B, the Network Monitor receives the packet.
  • the RTP recognizes the packet as being part of a timed transaction and passes control to the ETM.
  • the ETM recognizes it as a start time event, stores the start time in the event timing database and returns control to the RTP after checking for aging.
  • Node B When Node B receives the data packet from Node A, it sends back an acknowledgment packet. When the Network Monitor sees that packet, it delivers the event to the ETM, which recognizes it as an end time event. The ETM calculates the delay time for the complete transaction and uses that to update the average transaction time.
  • the ETM then compares the new average transaction time with the threshold for this event. If it has been exceeded, the ETM issues an alarm to the Workstation.
  • the first example measures the time it takes to traverse the network, perform an action and return that result to the
  • requesting node It measures performance as seen by the user and it includes delay times from the network as well as delay times from the File Server.
  • the second example is measuring network delays without looking at the service delays. That is, the ETM is measuring the amount of time it takes to send a packet to a node and receive the acknowledgement of the receipt of the message. In this example, the ETM is measuring transmissions delays as well as processing delays
  • the ETM can measure a broad range of events. Each of these events can be measured passively and without the
  • the Address Tracker Module (ATM)
  • ATM Address tracker module 43, one of the software modules in the Network Monitor (see Fig. 5), operates on networks on which the node addresses for particular node to node connections are assigned
  • An Appletalk ® Network developed by Apple Computer Company, is an example of a network which uses dynamic node addressing.
  • the dynamic change in the address of a particular service causes difficulty troubleshooting the network because the network manager may not know where the various nodes are and what they are called.
  • foreign network addresses e.g., the IP addresses used by that node for communication over an IP network to which if is
  • ATM 43 solves this problem by passively monitoring the network traffic and collecting a table showing the node address to node name mappings.
  • the network on which the Monitor is located is assumed to be an Appletalk ® Network.
  • LLAP Local Link Access Protocol
  • the node guesses its own node address and then verifies that no other node on the network is using that address.
  • the node verifies the uniqueness of its guess by sending an LLAP Enquiry control packet informing all other nodes on the network that it is going to assign itself a particular address unless another node responds that the address has already been assigned. If no other node claims that address as its own by sending an LLAP acknowledgment control packet, the first node uses the address which it has selected. If another node claims the address as its own, the first node tries another address. This continues until, the node finds an unused address.
  • LLAP Local Link Access Protocol
  • the first node When the first node wants to communicate with a second node, it must determine the dynamically assigned node address of the second node. It does this in
  • the Name Binding Protocol is used to map or bind human understandable node names with machine understandable node addresses.
  • the NBP allows nodes to dynamically translate a string of characters (i.e., a node name) into a node address.
  • the node needing to communicate with another node broadcasts an NBP Lookup packet containing the name for which a node address is being requested.
  • the node having the name being requested responds with its address and returns a Lookup Reply packet containing its address to the
  • the first node uses that address its current communications with the second node.
  • the network includes an Appletalk ® Network segment 702 and a TCP/IP segment 704, each of which are connected to a larger network 706 through their respective gateways 708.
  • a Monitor 710 including a Real Time Parser (RTP) 712 and an Address Tracking Module (ATM) 714, is located on Appletalk network segment 702 along with other nodes 711.
  • RTP Real Time Parser
  • ATM Address Tracking Module
  • Management Workstation 716 is located on segment 704. It is assumed that Monitor 710 has the features and
  • Monitor 710 is, of course, adapted to operate on Appletalk Network segment 702, to parse and analyze the packets which are transmitted over that segment according to the Appletalk ® family of protocols and to communicate the information which it extracts from the network to Management Workstation 716 located on segment 704.
  • ATM 714 maintains a name table data structure 730 such as is shown in Fig. 37.
  • Name Table 720 includes records 722, each of which has a node name field 724, a node address field 726, an IP address field 728, and a time field 729.
  • ATM 714 uses Name Table 720 to keep track of the mappings of node names to node address and to IP address. The relevance of each of the fields of records 722 in Name Table 720 are explained in the following description of how ATM 714 operates.
  • Monitor 710 operates as previously described. That is, it passively monitors all packet traffic over segment 702 and sends all packets to RTP 712 for parsing. When RTP 712 recognizes an Appletalk packet, it transfers control to ATM 714 which analyzes the packet for the presence of address mapping
  • ATM 714 receives control from RTP 712, it takes the packet (step 730 and strips off the lower layers of the protocol until it determines whether there is a Name Binding Protocol message inside the packet (step 732). If it is a NBP message, ATM 714 then determines whether it is new name Lookup message (step 734). If it is a new name Lookup message, ATM 714 extracts the name from the message
  • ATM 714 determines whether it is a Lookup Reply (step 738). If it is a Lookup Reply, signifying that it contains a node name/node address binding, ATM 714 extracts the name and the assigned node address from the message and adds this information to Name Table 720. ATM 714 does this by searching the name fields of records 722 in Name Table 720 until it locates the name. Then, it updates the node address field of the identified record to contain the node address which was extracted from the received NBP packet. ATM 714 also updates time field 72 9 to record the time at which the message was processed.
  • ATM 714 After ATM 714 has updated the address field of the appropriate record, it determines whether any records 722 in Name Table 720 should be aged out (step 742). ATM 714 compares the current time to the times recorded in the time fields. If the elapsed time is greater than a preselected time period (e.g. 48 hours), ATM 714 clears the record of all information (step 744). After that, it awaits the next packet from RTP 712.
  • a preselected time period e.g. 48 hours
  • ATM 714 As ATM 714 is processing each a packet and it determines either that it does not contain an NBP message (step 732) or it does not contain a Lookup Reply message (step 738), ATM 714 branches to step 742 to perform the age out check before going on to the next packet from RTP 712.
  • the Appletalk to IP gateways provide services that allow an Appletalk Node to dynamically connect to an IP address for communicating with IP nodes. This service extends the dynamic node address mechanism to the IP world for all Appletalk nodes. While the flexibility provided is helpful to the users, the network manager is faced with the problem of not knowing which Appletalk Nodes are currently using a particular IP address and thus, they can not easily track down problems created by the particular node.
  • ATM 714 can use passive monitoring of the IP address assignment mechanisms to provide the network manager a Name-to-IP address mapping.
  • ATM 714 If ATM 714 is also keeping IP address information, it implements the additional steps shown in Fig. 39 after completing the node name to node address mapping steps.
  • ATM 714 again checks whether it is an NBP message (step 748). If it is an NBP message, ATM 714 checks whether it is a response to an IP address request (step 750). IP address requests are typically implied by an NBP Lookup request for an IP gateway. The gateway responds by supplying the gateway address as well as an IP address that is assigned to the requesting node. If the NBP message is an IP address response, ATM 714 looks up the requesting node in Name Table 720 (step 752) and stores the IP address assignment in the IP address field of the appropriate record 722 (step 754).
  • ATM 714 locates all other records 722 in
  • IP address Table 720 which contain that IP address. Since the IP address has been assigned to a new node name, those old entries are no longer valid and must be eliminated. Therefore, ATM 714 purges the IP address fields of those records (step 756). After doing this cleanup step, ATM 714 returns control to RTP 712.
  • the Network Monitor can be adapted to identify node types by analyzing the type of packet traffic to or from the node. If the node being monitored is receiving mount requests, the Monitor would report that the node is behaving like node a file server. If the node is issuing routing requests, the Monitor would report that the node is behaving like a router. In either case, the network manager can check a table of what nodes are permitted to provide what functions to determine whether the node is authorized to function as either a file server or a router, and if not, can take appropriate action to correct the problem.
  • MibTimeOfDay typedef struct mib_count32_type ⁇
  • MibCount32 typedef struct mib_count64_type ⁇
  • MibAverageMeter typedef struct mib_percent_type ⁇
  • MibPercent typedef struct mib_rolling_rate_type ⁇
  • MibMostActiveEntry typedef struct mib_most_active_table_type ⁇
  • MibProtocolEntry typedef struct mib_protocol_table_type ⁇
  • MibTransportType typedef struct mib_dialog_entry_type ⁇

Abstract

L'invention concerne le contrôle de communication ayant lieu dans un réseau de noeuds (2), chaque communication étant effectuée par une transmission d'un ou de plusieurs paquets entre deux ou plusieurs noeuds de communication (2), chaque communication respectant un protocole de communication prédéfini sélectionné parmi des protocoles disponibles dans le réseau. Les contenus des paquets sont détectés de manière passive et en temps réel, les informations de communication (130, 152, 178) associées aux protocoles multiples sont dérivées des contenus des paquets.
PCT/US1992/002995 1991-04-12 1992-04-10 Systeme de controle de reseau de communication WO1992019054A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US68469591A 1991-04-12 1991-04-12
US684,695 1991-04-12

Publications (1)

Publication Number Publication Date
WO1992019054A1 true WO1992019054A1 (fr) 1992-10-29

Family

ID=24749175

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1992/002995 WO1992019054A1 (fr) 1991-04-12 1992-04-10 Systeme de controle de reseau de communication

Country Status (1)

Country Link
WO (1) WO1992019054A1 (fr)

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997014234A2 (fr) * 1995-09-25 1997-04-17 Netspeak Corporation Protocole internet de type point a point
EP0800299A2 (fr) * 1996-04-02 1997-10-08 Hewlett-Packard Company Méthode et dispositif pour déterminer automatiquement les données d'un réseau local dans une trame d'un réseau de grande extension
EP0853399A1 (fr) * 1997-01-13 1998-07-15 Hewlett-Packard Company Régulation de débit d'un train de données de rapport
FR2771238A1 (fr) * 1997-11-19 1999-05-21 Deutsche Telekom Ag Procede et dispositif de mesure pour des reseaux de communication de donnees
EP0790723A3 (fr) * 1996-02-19 1999-11-17 Fujitsu Limited Méthode et appareil de contrÔle de dépassement d'un compteur
US6009469A (en) * 1995-09-25 1999-12-28 Netspeak Corporation Graphic user interface for internet telephony application
EP1014621A2 (fr) * 1994-01-28 2000-06-28 Cabletron Systems, Inc. Méthode de gestion de réseau
US6185184B1 (en) 1995-09-25 2001-02-06 Netspeak Corporation Directory server for providing dynamically assigned network protocol addresses
US6226678B1 (en) 1995-09-25 2001-05-01 Netspeak Corporation Method and apparatus for dynamically defining data communication utilities
WO2001041366A2 (fr) * 1999-12-01 2001-06-07 British Telecommunications Public Limited Company Appareil d'evaluation pour materiel de communication
WO2001056326A1 (fr) * 2000-01-28 2001-08-02 Nokia Corporation Structure de donnes statistiques pouvant etre configuree
EP1128685A1 (fr) * 2000-02-22 2001-08-29 Lucent Technologies Inc. Inhibition du transfert pour des appels en temps réel dans des systèmes de GPRS
EP1198083A2 (fr) * 2000-10-05 2002-04-17 Matsushita Electric Industrial Co., Ltd. Système et dispositif pour la transmission de données comportant plusieurs noeuds, ou au moins un de ces noeuds est capable de sélectionner un procédé de transmission, pour corriger les temps d'arrivé des donnés à deux ou plusieur noeuds
AU764522B2 (en) * 1995-09-25 2003-08-21 Netspeak Corporation Point-to-point internet protocol
US6947985B2 (en) 2001-12-05 2005-09-20 Websense, Inc. Filtering techniques for managing access to internet sites or other software applications
US7185015B2 (en) 2003-03-14 2007-02-27 Websense, Inc. System and method of monitoring and controlling application files
US7194464B2 (en) 2001-12-07 2007-03-20 Websense, Inc. System and method for adapting an internet filter
US7529754B2 (en) 2003-03-14 2009-05-05 Websense, Inc. System and method of monitoring and controlling application files
WO2010081222A1 (fr) * 2009-01-16 2010-07-22 Neuralitic Systems Procédé et système de surveillance de base d'abonnés dans des réseaux de données ip
US8978140B2 (en) 2006-07-10 2015-03-10 Websense, Inc. System and method of analyzing web content
US9003524B2 (en) 2006-07-10 2015-04-07 Websense, Inc. System and method for analyzing web content
US9117054B2 (en) 2012-12-21 2015-08-25 Websense, Inc. Method and aparatus for presence based resource management
US9130972B2 (en) 2009-05-26 2015-09-08 Websense, Inc. Systems and methods for efficient detection of fingerprinted data and information
US9356899B2 (en) 1996-01-26 2016-05-31 Simpleair, Inc. System and method for transmission of data
US9378282B2 (en) 2008-06-30 2016-06-28 Raytheon Company System and method for dynamic and real-time categorization of webpages
US9473439B2 (en) 2007-05-18 2016-10-18 Forcepoint Uk Limited Method and apparatus for electronic mail filtering
US9565235B2 (en) 2000-01-28 2017-02-07 Websense, Llc System and method for controlling access to internet sites
US9654495B2 (en) 2006-12-01 2017-05-16 Websense, Llc System and method of analyzing web addresses

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4817080A (en) * 1987-02-24 1989-03-28 Digital Equipment Corporation Distributed local-area-network monitoring system
US4887260A (en) * 1987-02-17 1989-12-12 Hewlett-Packard Company X.25 Wide area network channel status display
US5025491A (en) * 1988-06-23 1991-06-18 The Mitre Corporation Dynamic address binding in communication networks
US5101402A (en) * 1988-05-24 1992-03-31 Digital Equipment Corporation Apparatus and method for realtime monitoring of network sessions in a local area network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4887260A (en) * 1987-02-17 1989-12-12 Hewlett-Packard Company X.25 Wide area network channel status display
US4817080A (en) * 1987-02-24 1989-03-28 Digital Equipment Corporation Distributed local-area-network monitoring system
US5101402A (en) * 1988-05-24 1992-03-31 Digital Equipment Corporation Apparatus and method for realtime monitoring of network sessions in a local area network
US5025491A (en) * 1988-06-23 1991-06-18 The Mitre Corporation Dynamic address binding in communication networks

Cited By (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1014621A2 (fr) * 1994-01-28 2000-06-28 Cabletron Systems, Inc. Méthode de gestion de réseau
EP1014621A3 (fr) * 1994-01-28 2001-07-18 Cabletron Systems, Inc. Méthode de gestion de réseau
US6185184B1 (en) 1995-09-25 2001-02-06 Netspeak Corporation Directory server for providing dynamically assigned network protocol addresses
WO1997014234A2 (fr) * 1995-09-25 1997-04-17 Netspeak Corporation Protocole internet de type point a point
US6226678B1 (en) 1995-09-25 2001-05-01 Netspeak Corporation Method and apparatus for dynamically defining data communication utilities
AU764521B2 (en) * 1995-09-25 2003-08-21 Netspeak Corporation Point-to-point internet protocol
US6009469A (en) * 1995-09-25 1999-12-28 Netspeak Corporation Graphic user interface for internet telephony application
WO1997014234A3 (fr) * 1995-09-25 1998-04-30 Netspeak Corp Protocole internet de type point a point
AU764522B2 (en) * 1995-09-25 2003-08-21 Netspeak Corporation Point-to-point internet protocol
US6108704A (en) * 1995-09-25 2000-08-22 Netspeak Corporation Point-to-point internet protocol
US6131121A (en) * 1995-09-25 2000-10-10 Netspeak Corporation Point-to-point computer network communication utility utilizing dynamically assigned network protocol addresses
AU727702B2 (en) * 1995-09-25 2000-12-21 Netspeak Corporation Point-to-point internet protocol
US9380106B2 (en) 1996-01-26 2016-06-28 Simpleair, Inc. System and method for transmission of data
US9356899B2 (en) 1996-01-26 2016-05-31 Simpleair, Inc. System and method for transmission of data
EP0790723A3 (fr) * 1996-02-19 1999-11-17 Fujitsu Limited Méthode et appareil de contrÔle de dépassement d'un compteur
EP0800299B1 (fr) * 1996-04-02 2003-06-11 Agilent Technologies, Inc. (a Delaware corporation) Méthode et dispositif pour déterminer automatiquement les données d'un réseau local dans une trame d'un réseau de grande extension
EP0800299A2 (fr) * 1996-04-02 1997-10-08 Hewlett-Packard Company Méthode et dispositif pour déterminer automatiquement les données d'un réseau local dans une trame d'un réseau de grande extension
EP0853399A1 (fr) * 1997-01-13 1998-07-15 Hewlett-Packard Company Régulation de débit d'un train de données de rapport
US6088622A (en) * 1997-01-13 2000-07-11 Hewlett-Packard Company Report stream data rate regulation
FR2771238A1 (fr) * 1997-11-19 1999-05-21 Deutsche Telekom Ag Procede et dispositif de mesure pour des reseaux de communication de donnees
WO2001041366A2 (fr) * 1999-12-01 2001-06-07 British Telecommunications Public Limited Company Appareil d'evaluation pour materiel de communication
WO2001041366A3 (fr) * 1999-12-01 2002-05-10 British Telecomm Appareil d'evaluation pour materiel de communication
US6697751B2 (en) 1999-12-01 2004-02-24 British Telecommunications Apparatus for assessing communication equipment
US9565235B2 (en) 2000-01-28 2017-02-07 Websense, Llc System and method for controlling access to internet sites
WO2001056326A1 (fr) * 2000-01-28 2001-08-02 Nokia Corporation Structure de donnes statistiques pouvant etre configuree
US7277385B2 (en) 2000-01-28 2007-10-02 Nokia Corporation Configurable statistical data structure
US6928284B2 (en) 2000-02-22 2005-08-09 Lucent Technologies Inc. Inhibiting handover to a new serving GPRS support node during a real-time call in a telecommunication system
EP1128685A1 (fr) * 2000-02-22 2001-08-29 Lucent Technologies Inc. Inhibition du transfert pour des appels en temps réel dans des systèmes de GPRS
EP1198083A3 (fr) * 2000-10-05 2003-11-26 Matsushita Electric Industrial Co., Ltd. Système et dispositif pour la transmission de données comportant plusieurs noeuds, ou au moins un de ces noeuds est capable de sélectionner un procédé de transmission, pour corriger les temps d'arrivé des donnés à deux ou plusieur noeuds
EP1198083A2 (fr) * 2000-10-05 2002-04-17 Matsushita Electric Industrial Co., Ltd. Système et dispositif pour la transmission de données comportant plusieurs noeuds, ou au moins un de ces noeuds est capable de sélectionner un procédé de transmission, pour corriger les temps d'arrivé des donnés à deux ou plusieur noeuds
US6947985B2 (en) 2001-12-05 2005-09-20 Websense, Inc. Filtering techniques for managing access to internet sites or other software applications
US7483982B2 (en) 2001-12-05 2009-01-27 Websense, Inc. Filtering techniques for managing access to internet sites or other software applications
US7194464B2 (en) 2001-12-07 2007-03-20 Websense, Inc. System and method for adapting an internet filter
US9503423B2 (en) 2001-12-07 2016-11-22 Websense, Llc System and method for adapting an internet filter
US9342693B2 (en) 2003-03-14 2016-05-17 Websense, Inc. System and method of monitoring and controlling application files
US7185015B2 (en) 2003-03-14 2007-02-27 Websense, Inc. System and method of monitoring and controlling application files
US9692790B2 (en) 2003-03-14 2017-06-27 Websense, Llc System and method of monitoring and controlling application files
US7529754B2 (en) 2003-03-14 2009-05-05 Websense, Inc. System and method of monitoring and controlling application files
US9253060B2 (en) 2003-03-14 2016-02-02 Websense, Inc. System and method of monitoring and controlling application files
US9680866B2 (en) 2006-07-10 2017-06-13 Websense, Llc System and method for analyzing web content
US8978140B2 (en) 2006-07-10 2015-03-10 Websense, Inc. System and method of analyzing web content
US9003524B2 (en) 2006-07-10 2015-04-07 Websense, Inc. System and method for analyzing web content
US9723018B2 (en) 2006-07-10 2017-08-01 Websense, Llc System and method of analyzing web content
US9654495B2 (en) 2006-12-01 2017-05-16 Websense, Llc System and method of analyzing web addresses
US9473439B2 (en) 2007-05-18 2016-10-18 Forcepoint Uk Limited Method and apparatus for electronic mail filtering
US9378282B2 (en) 2008-06-30 2016-06-28 Raytheon Company System and method for dynamic and real-time categorization of webpages
US8321504B2 (en) 2009-01-16 2012-11-27 Jean-Philippe Goyet Method and system for subscriber base monitoring in IP data networks
WO2010081222A1 (fr) * 2009-01-16 2010-07-22 Neuralitic Systems Procédé et système de surveillance de base d'abonnés dans des réseaux de données ip
US9130972B2 (en) 2009-05-26 2015-09-08 Websense, Inc. Systems and methods for efficient detection of fingerprinted data and information
US9117054B2 (en) 2012-12-21 2015-08-25 Websense, Inc. Method and aparatus for presence based resource management
US10044715B2 (en) 2012-12-21 2018-08-07 Forcepoint Llc Method and apparatus for presence based resource management

Similar Documents

Publication Publication Date Title
US6115393A (en) Network monitoring
WO1992019054A1 (fr) Systeme de controle de reseau de communication
US6216163B1 (en) Method and apparatus providing for automatically restarting a client-server connection in a distributed network
US6754705B2 (en) Enterprise network analyzer architecture framework
US6496866B2 (en) System and method for providing dynamically alterable computer clusters for message routing
US7522531B2 (en) Intrusion detection system and method
US7062783B1 (en) Comprehensive enterprise network analyzer, scanner and intrusion detection framework
US6941358B1 (en) Enterprise interface for network analysis reporting
US5710885A (en) Network management system with improved node discovery and monitoring
US6263361B1 (en) Method for calculating capacity measurements for an internet web site
Apisdorf et al. OC3MON: Flexible, Affordable, High Performance Staistics Collection.
US6714513B1 (en) Enterprise network analyzer agent system and method
US6789117B1 (en) Enterprise network analyzer host controller/agent interface system and method
US7693742B1 (en) System, method and computer program product for a network analyzer business model
US6297823B1 (en) Method and apparatus providing insertion of inlays in an application user interface
Gusella The analysis of diskless workstation traffic on an Ethernet
Stine FYI on a network management tool catalog: Tools for monitoring and debugging TCP/IP internets and interconnected devices
an Goldszmidt et al. Load Distribution for Scalable Web Servers: Summer Olympics 1996-A Case Study
WO2004061550A2 (fr) Systeme et procede de co-processeur d'analyse de reseau
Cisco Glossary
Cisco Glossary
Cisco Glossary
Cisco Network Management
Cisco Monitoring the Router and Network
Cisco Manual Pages

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP

AL Designated countries for regional patents

Kind code of ref document: A1

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

NENP Non-entry into the national phase

Ref country code: CA