`
`PCT/U592/02995
`
`-53..
`
`a
`
`Segment Local Area Network" filed on January 14, 1991
`
`(Attorney Docket No. 13283-NE.APP),
`
`incorporated herein
`
`by reference.
`A
`In normal operation, each station in the network
`
`5
`
`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.
`
`10
`
`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
`
`15 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 sequence of events following the detection of
`20 a new node is:
`
`1.
`
`the location of the node is determined
`
`automatically for the user.
`
`2.
`
`the Monitor generates an alarm for the
`
`user indicating the new node and providing‘
`
`some or all of the following information:
`mac address of node
`
`ip address of node
`
`segment that the node is believed to
`be
`
`located on
`
`Monitor to be responsible for the
`node
`
`3.
`
`the user must select the segment and add
`
`the node manually using the SNM editor
`
`25
`
`30
`
`—
`
`-
`
`Page 501 of 1000
`
`LG Electronics Exhibit 1022
`
`
`
`W0 92/ 19054
`
`PCIYUSEUBZE
`
`4.
`
`The update to the SNM database will be
`
`detected and the file reread.
`
`The
`
`Workstation database is reconstructed and
`
`the parse control records for the Monitors
`
`updated if required.
`
`5.
`
`The Monitor responsible for the new node
`
`has its parse control record updated via
`
`SNMP set request(s).
`
`An internal record of new nodes is required for
`
`10 the autotopology. when a new node is reported by a
`
`Network Monitor,
`
`the Management workstation needs to have
`
`the previous location information in order to know which
`
`Network monitors to involve in autotopology.
`
`For
`
`example.
`
`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.
`
`Before a new Honitor can communicate with the
`
`Management workstation Via SNHP it needs to be added to
`
`the SNH system files. As the SNH files are cached in the
`
`15
`
`20
`
`the file must be updated and the Sun system
`database,
`forced to reread it.
`
`Thus, on the detection of a new Honitor the
`
`following events need to occur in order to add the
`
`25
`
`Monitor to the workstation:
`
`1.
`
`The Monitor issues a trap to the
`
`Hanagement Workstation software and
`
`requests code to be loaded from the Sun
`
`Hicrosystems boot/load server.
`
`30
`
`2.
`
`The code load fails as the Monitor is not
`
`known to the unix networking software at
`
`this time.
`
`3.
`
`The workstation confirms that the new
`
`Monitor does not exceed the configured
`
`35
`
`system limits (e.g. 5 Monitors per
`
`Page 502 of 1000
`
`
`
`WO 92/19054
`
`PC!‘I US92/02995
`
`- 55 -
`
`Workstation) and terminates the
`
`initialization sequence if limits are
`
`'
`
`An alarm is issued to the user
`exceeded.
`indicating the presence of the new Monitor
`
`5
`
`and whether it can be supported.
`
`4.
`
`The user adds the Monitor to the
`
`10
`
`15
`
`20
`
`25
`
`SNHP.HOSTS file of the SN! system, to the
`
`etc/hosts file of the Unix networking
`
`system and to the SN! map.
`
`when the files have been updated the user
`
`resets the Monitor using the set tool
`
`(described later).
`
`6.
`
`The Monitor again issues a trap to the
`
`Management Workstation software and
`
`requests code to be loaded from the sun
`
`boot/load server.
`
`7.
`
`The code load takes place and the Monitor
`
`issues a trap requesting data from the
`
`Management Workstation.
`
`8.
`
`The Monitor data is issued using SNH set
`
`I
`
`requests.
`
`Note that on receiving the set request,
`
`the SNMP proxy
`
`rereads in the (updated) SNH.HOSTS file which now
`
`includes the new Monitor. Also note that the SNHP'hosts
`
`file need only contain the Monitors, not the entire list
`
`of nodes in the systen.
`
`9.
`
`on completion of the set request(s) the Monitor
`
`run command is issued by the workstation to bring
`
`the Monitor on line.
`
`The user is responsible for entering data into the
`
`SNM database manually. During operation,
`
`the workstation
`
`monitors the file write date for the SNH database. when
`
`this is different from the last date read,
`
`the SNH
`
`database is reread and the Workstation database
`
`35
`
`reconstructed.
`
`In this manner, user updates to the SNM
`
`Page 503 of 1000
`
`
`
`“K)9Lfl9MM
`
`PC17US9bM2%E
`
`database are incorporated into the Workstation database
`
`as quickly as possible without need for the user to take
`
`any action.
`When the Workstation is loaded,
`
`_
`
`the database is
`
`created from the data in the SHE 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 Been.
`
`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 SNH
`
`system. They consist of additional display tools (i.e.,
`
`sumsry 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.
`
`As a result of the monitoring process, the Monitor
`
`makes a large number of statistics available to the
`
`operator. These are available for examination via the
`
`workstation tools that are provided.
`
`In addition,
`
`the
`
`Monitor statistics (or a selected subset thereof) can be
`
`made visible to any SNH manager by providing it with
`
`knowledge of the extended HIB.
`
`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
`
`appropriate to the protocol layer - IP address, port
`
`number,
`
`...) and per connection basis.
`
`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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`Page 504 of 1000
`
`
`
`\V()92/19054
`
`PCT/US92/02995
`
`_ 57 _
`
`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,
`to node traffic for
`H
`
`then summing the node
`
`1 -> 20,2l,22
`
`2 —> 2o,21,22
`
`3 -> 20}21,22
`
`produces the required result.
`
`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 are reported to the user in the following
`
`ways:
`
`1.
`
`2.
`
`3.
`
`Alarms received are logged in a Workstation log.
`
`The node which the alarm relates to is highlighted
`
`on the map.
`
`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 Sun.
`
`Summary Tool
`
`After the user has selected an object from the map
`
`and invokes the display tools,
`
`the sumary 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
`
`Monitor for the data required by the summary Tool display
`screens.
`
`screen such as is shown in Fig.
`
`The Summary Tool displays a basic summary tool
`18.
`
`The summary tool
`
`screen has three panels, namely, a control panel 602, a
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`Page 505 of 1000
`
`
`
`wo 92/19054
`
`"CT’“592’°2995
`
`-53-
`
`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
`
`5 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
`
`properties of objects.
`
`-The tools button invokes a tools
`
`10 menu which provides access to the other Workstation
`
`tools, e.g. Values Tool.
`
`The Update Interval field allows the user to
`
`spciry the frequency at which the displayed statistics
`
`are updated by polling the Monitor.
`
`The Update Once
`
`15 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
`
`automatically set to "none".
`
`The type field enables the user to specify the
`
`20 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
`
`25 can then be selected from the (scrolling) list and it
`
`will be entered in the name field of the sumary tool
`
`when the apply button is invoked. Alternatively,
`
`the
`
`user may enter the name directly in the summary tool name
`
`field.
`
`'
`
`30
`
`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
`
`35 selection menu is shown in Fig. 19.
`
`It displays the
`
`Page 506 of 1000
`
`
`
`W0 92/ 1 9054
`
`PCJ7US9Lm2%H
`
`_ 59 -
`
`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
`protocol family and then the particular layer within that
`
`family.
`
`As indicated by the protocol trees shown in Fig.
`
`19,
`
`the capabilities of the Monitor can be readily
`
`extended to handle other protocol families.
`
`The
`
`particular ones which are implenented depend upon the
`
`needs of the particular network environent in which the
`
`Honitor will operate.
`
`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
`
`_
`selected. The reset button is used to undo the
`selections and restore them to their values at the last
`
`apply operation.
`
`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. Pigs. 20a-g present examples of the types
`
`of statistical variables which are displayed for the DLL,
`
`IP, UDP, TCP,
`
`ICM, NPS, and ARP/RARP protocols,
`
`respectively.
`
`The meaning of the values display fields
`
`are described in Appendix I, attached hereto.
`
`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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`Page 507 of 1000
`
`
`
`“K)EUIN54
`
`PCH7US9ZNH995
`
`Past and Present based upon the returned state of the
`
`connection.
`
`For certain dialogs, such as TCP and NPS
`
`there is an associated direction to the dialog,
`over UDP,
`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.
`
`Values Tool
`
`10
`
`15
`
`20
`
`25
`
`30
`
`The values tool provides the user with the ability
`
`to look at the statistical database for a network object
`
`in detail. when 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.
`
`In rate values and count values panels 620 and
`
`622, value tools presents the monitored rate and count
`
`statistics, respectively, for a selected protocol.
`
`The
`
`parameters which are displayed for the different
`
`protocols (i.e., different groups) are listed in Appendix
`
`II.
`
`In general, 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.
`
`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
`
`parameters) by scrolling down.
`
`Page 508 of 1000
`
`
`
`WO 92/19054
`
`PCTIUS92/ 02995
`
`-61-
`
`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
`
`each threshold trigger and thus gives on
`
`reset following
`
`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 itsns where this is predictable and
`useful.
`
`It is maintained in the workstation database and
`
`is modifiable by the user using the set tool.
`
`An
`
`Accumulated Count field reports the current accumulated
`A Hax value field
`
`value of the item or the current rate.
`
`reports the highest value recently seen for the item.
`
`This value is reset at intervals defined by a user
`This is not a
`
`adjustable parameter (default 30 minutes).
`
`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.
`
`A Percent
`variables:
`
`(%) field reports only for the following
`
`10
`
`15
`
`20
`
`25
`
`off seg counts:
`
`10o(in count / total off seg count)
`
`l00(out count
`
`/ total off seg count)
`
`100(transit count / total off seg count)
`
`l00(local count
`
`/ total off seg count)
`
`off seq rates
`1oo(transit rate / total off seg rate), etc.
`
`35
`
`protocols
`
`Page 509 of 1000
`
`
`
`wo 92/19054
`
`PCT/US92l0299S
`
`1OD(frame_rate this protocol / total frame
`
`rate)
`
`on the right half of the basic display,
`there the
`following addtional fieldsi a High Threshold field and a
`
`5 Sample period for rates field.
`
`Set Tool
`
`The set tool provides the user with the ability to
`
`modify the parameters controling the operation of the
`
`Monitors and the Hanagaent Workstation. These
`
`10 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
`15 values.
`
`The monitoring control variables specify the
`
`actions of the segment Hoitors and each Monitor can have
`
`a distinct set of control variables (e.g.,
`
`the parse
`
`control records that are described elsewhere).
`
`The user
`
`20 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
`
`Honitors on the same segment can divide up the total
`
`25 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.
`
`30 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.
`
`Note that the above descriptions of the tools
`
`available through the Hanagement Workstation are not
`
`35 meant to imply that other choices may not be made
`
`Page510of1000
`
`
`
`“K)RN1MB4
`
`PCT/U592/02995
`
`-63-
`
`regarding the particular information which is displayed
`
`and the manner in which it is displayed.
`
` =
`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.
`
`I Referring the Fig. 24,
`
`the details of the training
`
`procedure for adaptively setting the Network Monitor
`
`thresholds are as follows.
`
`To begin training,
`
`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
`
`10
`
`15
`
`20
`
`25
`
`to periodically send data for a predefined set of network
`parameters to the Hanagement_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.
`
`Throughout the learning period,
`
`the Network
`
`Monitor sends "snapshots" of the network's performance to
`
`the Workstation which,
`
`in turn, stores the data in a
`The network
`
`performance history database 306 (step 304).
`
`35
`
`manager sets the length of the learning period.
`
`Page 511 of 1000
`
`
`
`VV()92/19054
`
`_PC17US9N®2%
`
`-54-
`
`Typically, it should be_1ong 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.
`
`After the learning period has expired,
`
`the network
`
`manager,
`
`through the Hanagement workstation, sends a stop
`
`learning comand 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
`
`sophisticated statistical analysis of the data, such as
`
`computing means, standard deviations, maximum and minimum
`
`values, or using curve fitting to compute rates and other“
`
`pertinent parameter values.
`
`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
`
`he used to compute thresholds are:
`
`*
`
`Highest value seen during learning period;
`
`10
`
`15
`
`20
`
`25
`
`30
`
`Page512of1000
`
`
`
`W0 92/ 1 9054
`
`PCTIU592/02995.
`
`_ 5 5 _
`
`*
`
`*
`
`*
`
`*
`
`*
`
`*
`
`Highest value seen during learning period +
`105:
`
`Highest value seen during learning period +
`5 0% ,-
`’
`
`Highest value seen during learning period +
`user-defined percent;
`
`Any value of the parameter other than zero;
`
`Average value seen during learning period +
`
`50%; and
`
`Average value seen during learning period +
`
`user-defined percent.
`
`As should be evident from these examples,
`
`there is a
`
`broad range of possibilities regarding how to compute a
`
`particular threshold.
`
`The choice, however, should
`
`reflect the paraneter's importance in signaling serious
`
`network problems and its normal expected behavior (as may
`
`be evidenced from the performance history acquired for
`
`the parameter during the learning mode).
`
`‘
`
`5
`
`10
`
`15
`
`the Workstation
`After the thresholds are computed,
`loads them into the Honitor and instructs the Monitor to
`
`20
`
`revert to normal monitoring using the new thresholds
`
`(step 314).
`
`This procedure provides a mechanism enabling the
`
`network manager to adaptively reset thresholds in
`
`25
`
`response to changing conditions on the network, shifting
`
`usage patterns and evolving network topology. As the
`
`network changes over time,
`
`the network manager merely
`
`invokes the adaptive threshold setting feature and
`
`updates the thresholds to reflect those changes.
`
` :
`
`The Hanagement 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
`
`35
`
`actually be distributed among the Workstation and the
`
`Page513of1000
`
`
`
`W0 92/190541
`
`PC!‘IU592 I02995
`
`Network Monitors which_are active on the network.
`
`In
`
`principle,
`
`the diagnostic analyzer module includes the
`
`following ¢lements for performing its fault detection and
`
`analysis functions.
`
`H
`
`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
`
`performance can be compared so as to diagnose and analyze
`
`potential problems.
`
`The Network Homitor (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
`
`indicative of the onset or the presence of particular
`
`network problems.
`
`During monitoring, when a Monitor threshold is
`
`exceeded,
`
`thereby indicating a potential problem (e.g.
`
`in
`
`a TCP connection),
`
`the Network Monitor alerts the
`
`Workstation by sending an alarm. The workstation
`
`notifies the user and Ptesents 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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`Page 514 of 1000
`
`
`
`“K)EU]flB4
`
`FKHVUSBLMZEE
`
`_ 57 _
`
`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
`
`illustrated in Fig. 25.
`
`It includes
`
`three segments
`
`labelled S1, S2, and 83, a router R1
`
`connecting S1 to S2,
`
`a router R2 connecting S2 to S3, and
`node A on 51 which communicates with
`
`at least two nodes,
`node B on 53.
`on
`
`each segment there is also a Network
`
`Monitor 324 to
`
`10
`
`observe the performance of its segment in the manner
`
`described earlier.
`
`A Management Workstation 320 is also
`
`located on 51 and it includes a diagnostic analyzer
`
`module 322. For this example,
`
`the sympton of the network
`
`problem is degraded peformance of a TCP connection
`
`15
`
`between Nodes A and B.
`
`A TCP connection problem may manifest itself in a
`
`number of ways,
`
`including,
`
`for example, excessively high
`
`20
`
`25
`
`numbers for any of the following:
`€I'I'OI'S
`
`packets with bad sequence numbers
`
`packets retransmitted
`
`bytes retransmitted
`
`out of order packets
`
`out of order bytes
`
`packets after window closed
`
`bytes after window closed
`
`average and maximum round trip times
`
`or by an unusually low value for the current window size.
`
`By setting the appropriate thresholds,
`
`the Monitor is
`
`programmed to recognize any one or more of these
`
`symptons.
`
`the Monitor sends an alarm to the Workstation.
`
`If any one of of the thresholds is exceeded,
`The
`
`workstation is programmed to recognize the particular
`
`alarm as related to an event which can be further
`
`35
`
`analyzed by its diagnostic analyzer module 322. Thus,
`
`Page 515 of 1000
`
`
`
`, W0 92/19954
`
`PCTIU592/02995
`
`-68-
`
`the workstation presents the user with the option of
`
`invoking its diagnostic capabilities (or automatically
`
`invokes the diagnostic capabilities).
`
`In general terms, when the diagnostic analyzer is
`
`5
`
`invoked, it looks at the performance data that the
`
`segment Honitors 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
`
`10 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
`
`performance, the network circuit involved in
`
`15 comunications 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.
`
`The overall structure of the diagnostic algorithm
`
`20 400 is shown in Fig. 26. 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
`
`25 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).
`
`30
`
`If node A does not appear to be experiencing a TCP
`
`problem when acting as a source node, 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
`
`35 analyzer algorithm.470 shown in Fig. 23.
`
`If a problem is
`
`Page516of1000
`
`
`
`WO 92/19054
`
`PCT/US92/02995
`
`-59-
`
`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).
`
`Note that source and sink nodes are concepts which
`
`apply to those dialogs for which a direction of the
`
`communication can be defined.
`
`For example,
`
`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
`
`10
`
`node.
`
`If node B does not appear to be experiencing a TCP
`
`problem when acting as a 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
`
`identified, the Workstation reports that there is a high
`
`probability that a TC? problem exists on the link and it
`
`reports the results of the investigation performed by
`
`link analysis algorithm 550_(step 412).
`
`If the link does not appear to be experiencing a
`
`TCP problem, 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 8.
`
`If a problem is identified,
`
`the workstation reports that there is a medium
`
`probability that node B is causing a TCP problem when
`
`operating as a source node and it reports the results of
`
`the investigation performed by algorithm 450 (step 416).
`
`If node B does not appear to be experiencing a TCP
`
`problem when acting as a source node, 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
`
`15
`
`20
`
`25
`
`30
`
`35
`
`Page517of1000
`
`
`
`WO 92/19054
`
`PCI‘I U592/02995
`
`-70-
`
`algorithm 470 for Node A.
`
`If a problem is identified,
`
`the Network Honitor reports that there is a medium
`
`probability that node A is causing a Tc? problem when
`operating as a sink node and it reports the results of
`
`the investigation performed by algorithm 470 (step 420).
`
`Finally,
`
`if node A does not appear to be
`
`experiencing a TCP problem when acting as a sink node,
`
`diagnostic analyzer 322 reports that it was not able to
`
`isolate the cause of a TCP problem (step 422).
`
`The algorithms which are called from within the
`
`above-described diagnostic algorithm will now be
`
`described. Referring to Fig. 27, 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 TC? 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
`
`10
`
`15
`
`20
`
`25
`
`whereas the reverse is not true.
`
`-
`
`In accordance with this approach, 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
`
`30
`
`35
`
`Page518of1000
`
`
`
`VWD92H905d
`
`PC!‘I U592}02995
`
`_ 71 _
`
`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 455).
`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 {act is reported (step 462).
`
`If
`
`10
`
`no IP problems are found, algorithm 450 checks whether
`
`any other TCP connection in which the node participates
`If another TCP
`
`as a s