throbber
wo 92/19054
`
`PCT /US92/02995
`
`- 53 -
`
`segment Local Area Net~ork" filed on January 14, 1991
`(Attorney Docket No. 13283-NE.APP), incorporated herein
`by reference.
`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.
`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.
`
`10
`
`2.
`
`The sequence of events following the detection of
`20 a new node is:
`the location of the node is determined
`1.
`automatically for the user.
`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
`
`25
`
`30
`
`located on
`Monitor to be responsible for the
`node
`the user must select the segment and add
`the node manually using the SNM editor
`
`3.
`
`SKY PE-N2P00284056
`
`Cisco - Exhibit 1022 - Page 501
`
`

`
`W092/19054
`
`PCf/US92/0l995
`
`- 54 -
`
`5
`
`.)
`
`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
`15 separate segments of the network. The history makes
`possible the correlation of the addresses and it makes
`possible duplicate address detection.
`Before a new Monitor can communicate with the
`Management Workstation via SNMP it needs to be added to
`20 the SNM system files. As the SNM files are cached in the
`database, the file must be updated and the SNM system
`forced to reread it.
`Thus, on the detection of a new Monitor the
`following events need to occur in order to add the
`25 Monitor to the Workstation:
`1. The Monitor issues a trap to the
`Management Workstation software and
`requests code to be loaded from the sun
`Microsystems boot/load server.
`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
`system limits (e.g. 5 Monitors per
`
`30
`
`35
`
`SKYPE-N2P00284057
`
`Cisco - Exhibit 1022 - Page 502
`
`

`
`wo 92/19054
`
`PCf/US92102995
`
`5
`
`10
`
`- 55 -
`Workstation) a~d terminates the
`initialization sequence if limits are
`exceeded. An alarm is issued to the user
`indicating the presence of the new Monitor
`and whether it can be supported.
`4 • The user adds the Monitor to the
`SNMP.HOSTS file of the SNM system, to the
`etc/hosts file of the Unix networking
`system and to the SNM map.
`5. 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
`boottload 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 SNMP set
`requests.
`Note that on receiving the set request, the SNMP proxy
`rereads in the (updated) SNMP.HOSTS file which now
`includes the new Monitor. Also note that the sHMP· hosts
`25 file need only contain the Monitors, not the entire list
`of nodes in the system.
`on completion of the set request(s) the Monitor
`9.
`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 SNM database. When
`this is different from the last date read, the SNM
`database is reread and the Workstation database
`35 reconstructed.
`In this manner, user updates to the SNM
`
`15
`
`20
`
`30
`
`SKYPE-N2P00284058
`
`Cisco - Exhibit 1022 - Page 503
`
`

`
`wo 92/19054
`
`PCf/US92102995
`
`- 56 -
`
`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
`5 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
`~0 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
`15 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 loq in which all alarms are recorded.
`As a result of the monitoring process, the Monitor
`20 makes a l~rge 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 SNMP manager by providing it with
`25 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
`30 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
`35 to node and segment to segment basis.
`
`SK YPE-N2P00284059
`
`Cisco - Exhibit 1022 - Page 504
`
`

`
`W092/19054
`
`PCf /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
`5 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
`1 -> 20,21,22
`2 -> 20,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
`
`10
`
`15
`
`ways:
`1.
`2.
`
`20 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 SNM.
`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
`30 selected node or segment). The Workstation polls the
`Monitor for the data required by the Summary Tool display
`screens.
`The Summary Tool displays a basic summary tool
`screen such as is shown in Fig. 18. The summary tool
`35 screen has three panels, namely, a control panel 602, a
`
`25
`
`SKYPE-N2P00284060
`
`Cisco - Exhibit 1022 - Page 505
`
`

`
`W092/19054
`
`PCT/US92/02995
`
`- 58 -
`
`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 rnterval field allows the user to
`specify 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.,
`seqment 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 summary 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
`
`SKYPE-N2P00284061
`
`Cisco - Exhibit 1022 - Page 506
`
`

`
`"
`
`W092/190S4
`
`PCf/US92102995
`
`- 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
`5 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 implemented depend upon the
`10 needs of the particular network environment in which the
`Monitor 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
`15 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
`20 set is displayed in values panel 604. The members of the
`sets differ depending upon, for example, what protocol
`was selected. Figs. 20a-q present examples of the types
`of statistical variables which are displayed for the DLL,
`IP, UDP, TCP, ICMP, NFS, and ARP/RARP protocols,
`25 respectively. The meaninq 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
`30 lists are maintained per node, per supported protocol.
`When connections are displayed, they are sorted on 11Last
`Seen 11 with the most current displayed first. A single
`list returned from the Monitor contains all current
`connection. For TCP, however, each connection also.
`35 contains a state and TCP connections are displayed as
`
`SKY P £-N2P00284062
`
`Cisco - Exhibit 1022 - Page 507
`
`

`
`W092/l9054
`
`PCT/US92/02995
`
`- 60 -
`
`10
`
`Past and Present based ~pon the returned state of the
`connection. For certain di~logs, 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).
`5 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
`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
`15 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
`20 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
`25 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
`30 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.
`
`SKY PE-N2P00284063
`
`Cisco - Exhibit 1022 - Page 508
`
`

`
`W092119054
`
`PCT/US92/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
`5 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
`10 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. An
`15 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
`20 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
`25 manner as Max Value field and is used only for rates.
`A Percent (%) field reports only for the following
`variables:
`off seg counts:
`100(in count 1 total off seg count)
`100(out count 1 total off seg count)
`lOO(transit count I total off seg count)
`100(local count I total off seg count)
`off seq rates
`100(transit rate 1 total off seg rate), etc.
`protocols
`
`30
`
`35
`
`SKYPE-N2P00284064
`
`Cisco - Exhibit 1022 - Page 509
`
`

`
`W092/19054
`
`PCf/US92/0l995
`
`- 62 -
`100(frame.rate this protocol J total frame
`rate)
`On the right half of the basic display, there the
`following addtional fields: 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 controlinq the operation of the
`Monitors and the Management 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 Monitors 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
`Monitors 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
`to modify the operation of the segment Monitor in a
`user
`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 Management Workstation are not
`35 meant to imply that other choices may not be made
`
`SKY PE-N2P00284065
`
`Cisco - Exhibit 1022 - Page 510
`
`

`
`W092/19054
`
`PCf/US92/02995
`
`- 63 -
`
`regarding the particu~ar information which is displayed
`and the manner in which it is displayed.
`Adaptiyely setting Network Monitor Tbresholds:
`The Workstation sets the thresholds in the Network
`5 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
`10 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
`15 out over time and model tends to accurately reflect
`normal network behavior.
`Referring the Fig. 24, the details of the training
`procedure for adaptively setting the Network Monitor
`thresholds are as follows. To begin training, the
`20 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
`25 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
`30 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
`performance history database 306 (step 304). The network
`35 manager sets the length of the learning period.
`
`SKYPE-N2P00284066
`
`Cisco - Exhibit 1022 - Page 511
`
`

`
`W09l/19054
`
`PCf/US92/0l995
`
`- 64 -
`
`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
`5 overload or faulty behavior do not distort the resulting
`averages.
`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
`10 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
`15 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
`20 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
`25 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
`30 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:
`Highest value seen during learning period;
`*
`
`!
`
`SKYPE-N2P00284067
`
`Cisco - Exhibit 1022 - Page 512
`
`

`
`W09Z/l9054
`
`PCf/US92/0299S.
`
`- 65 -
`
`*
`
`*
`
`*
`*
`
`*
`
`5
`
`10
`
`Highest value seen during learning period +
`10,;
`Highest value seen during learning period +
`SO%;
`Highest value seen during learning period +
`user-defined percent;
`Any value of the parameter other than zero;
`Average value seen during learning period +
`sot; 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
`15 reflect the parameter'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).
`After the thresholds are computed, the Workstation
`20 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
`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.
`30 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
`35 actually be distributed among the Workstation and the
`
`SKYPE-N2P00284068
`
`Cisco - Exhibit 1022 - Page 513
`
`

`
`W092119054
`
`PCI'/US9Z/02995
`
`- 66 -
`
`5
`
`In
`Network Monitors which are active on the network.
`principle, 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
`10 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 Monitor (in particular,
`the STATS module) includes alarm thresholds on a selected
`15 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
`20 exceeded, thereby ingicating 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 presents the user with the option
`of either ignoring the alarm or invoking a diagnostic
`25 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
`30 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.
`
`SKYPE-N2P00284069
`
`Cisco - Exhibit 1022 - Page 514
`
`

`
`W092/J90S4
`
`PCT/US92/02995
`
`- 67 -
`
`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
`5 illustrated in Fig. 25. It includes three segments
`labelled Sl, S2, and SJ, a router Rl connecting Sl to s2,
`a router R2 connecting 52 to SJ, and at least two nodes,
`node A on Sl which communicates with node B on S3. 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 Sl 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
`numbers for any of the following:
`errors
`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
`30 programmed to recognize any one or more of these
`symptons.
`If any one of of the thresholds is exceeded,
`the Monitor sends an alarm to the Workstation. 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,
`
`20
`
`25
`
`..
`
`SKY PE-N2P00284070
`
`Cisco - Exhibit 1022 - Page 515
`
`

`
`. wo 92/19054
`
`PCT/US92/02995
`
`- 68 -
`
`5
`
`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
`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
`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 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.
`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).
`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. 28.
`If a problem is
`
`30
`
`SKYPE-N2P00284071
`
`Cisco - Exhibit 1022 - Page 516
`
`

`
`wo 92/19054
`
`PCT/US92/02995
`
`- 69 -
`
`5
`
`identified, the Workst~tion 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
`15 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 TCP problem exists on the link and it
`reports the results of the investigation performed by
`20 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
`25 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
`probability that node B is causing a TCP problem when
`operating as a source node and it reports the results of
`30 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,
`35 diagnostic algorithm 400 invokes sink node analyzer
`
`SKYPE-N2P00284072
`
`Cisco - Exhibit 1022 - Page 517
`
`

`
`W09l/19054
`
`PCI'/US92/0l99S
`
`- 70 -
`
`10
`
`If a problem is identified,
`algorithm 470 for Node A.
`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
`5 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
`15 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
`20 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
`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
`30 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
`35 that are okay, it moves up through the protocol stack
`
`SK YPE-N2P00284073
`
`Cisco - Exhib

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket