W0921t9054
`
`e PCf/US92102995
`
`;
`
`- 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 strateqy 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 prob~em 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 ~kay, it moves up through the protocol stack
`
`SONY EXHIBIT 1027- Page 415
`
`FH_000415
`
`
`
`e PCf/US92102995
`
`;
`
`- 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 strateqy 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 prob~em 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 ~kay, it moves up through the protocol stack
`
`SONY EXHIBIT 1027- Page 415
`
`FH_000415
`
`
`
`- 71 -
`
`9
`
`In this case, it then
`checking each level for a problem.
`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).
`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
`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
`15 466).
`If no other TCP connections where the node is
`acting as a source node can be found, algorithm 450
`exits.
`
`Referring to Fig. 28, sink node analyzer algorithm
`470 checks whether a particular node is causing a TCP
`20 problem when operating as a sink node.
`It first
`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,
`25 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 A~tir.q ~s
`30 a sink node by calling DLL problem checking routine 510
`(step 476).
`If a DLL problem is found',
`that fact 'is
`reported (step 478).
`If no DLL problems are found,
`algorithm 470 checks for an IP problem at the node when
`it is acting as a sink by calling IP problem checking
`35 routine 490 (step 480).
`If an IP problem is found,
`that
`
`•
`SONY EXHIBIT 1027- Page 416
`
`FH_000416
`
`
`
`WO 92/19054
`
`-
`
`PCf/US92102995
`
`;;
`
`- 72 -
`
`5
`
`If no IP problems are
`fact is reported (step 482).
`found, algorithm 470 checks whether any other TCP
`connection in which the node participates as a sink is
`not okay (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.
`Referring to Fig •. 31,
`IP problem checking routine
`10 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
`15 496).
`If no significant deviations are noted,· it reports
`that there is no IP problem at the node (step 498).
`As revealed by examining Fig. 30, DLL problem
`checking routine 510 operates in a similar manner to IP
`problem checking routine 490, with the exception that it
`,
`20 examines a different set of parameters (i.e., DLL
`parameters) for significant deviations.
`Referring the Fig. 29,
`link analysis, logic 550
`first determines whether any other TCP connection for the
`link is operating properly (step 552).
`If a properly
`25 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
`30 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.
`
`SONY EXHIBIT 1027- Page 417
`
`FH_000417
`
`
`
`- 73 -
`
`10
`
`The decomposition of the 1ink 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
`5 up the link between nodes A and B include in order:
`segment S1, router R1, segment S2, router R2, and segment
`53.
`The IP data for these various components are
`analyzed in the following order:
`IP data for segment 81
`IP data for address R1
`IP data for source node to R1
`IP data for 51 to 52
`IP data for 52
`IP data for address R2
`IP data for 83
`IP ~ata for S2 to 83
`IP data for 51 to 53
`As shown in Fiq. 32,
`IP link component p~pblem
`checking routine ~70 compares IP statistics for the link
`20 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).
`25 otherwise, it reports that it found no IP problem (step
`578).
`
`15
`
`Referring back to Fig. 29, after completing the IP
`problem analysis for all of the link components,
`logic
`550 then invokes a DLL link component problem checking
`30 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
`35 the link to the reference model (step 582)
`to determine
`
`SONY EXHIBIT 1027- Page 418
`
`FH_000418
`
`
`
`WO 92/19054
`
`PCfIUS92102995
`
`- 74 -
`
`whether network performance at the DLL deviates
`significantly from that specified by the model (step
`If significant deviations are detected, routine
`584).
`580 reports that there is a DLL problem at the link
`5 component (step 58-6).
`otherwise, ·it reports that no DLL
`problems were found (step 588).
`Referring back to Fig. 29, after completing the
`DLL problem analysis for all of the link components,
`lO9'ic 550 checks whether· there is any other TCP on the
`10 link (step 560).
`If another TCP exists on the link
`(which implies that the other TCP is also not operating
`properly),
`lO9'ic 550 reports that there is a TCP problem
`on the link (step 562). Otherwise,
`loqic 550 reports
`that there was not enough information from the existing
`15 packet traffic to determine whether there was a link
`problem (step 564)
`If the analysis of the link components does not
`isolate the source of the problem and if there were
`components for which sufficient informa~ion was not
`20 available (due possibly to lack of traffic over through
`that component),
`the user may send test messages to those
`components to generate the information needed to evaluate
`its performance.
`The reference model against which comparisons
`25 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
`ofoperati~n. During those periods of operation, average
`values and maximum excursions (or standard deviations)
`30 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
`35 actual malfunctions or imminent malfunctions and the
`
`SONY EXHIBIT 1027- Page 419
`
`FH_000419
`
`
`
`- 75
`
`5
`
`reference model can be revised to reflect the new
`experience.
`What constitutes a significant deviation from the
`reference model depends upon the particular parameter
`involved.
`Some parameters will not deviate from the
`expected norm and thus any deviation would be considered
`to be significant, for example, consider ICMP messages of
`type "destination unreachable," IP errors, TCP errors.
`Other parameters will no~ally vary within a wide range
`10 of acceptable values, and only if they move outside of
`that range should the deviation be considered
`significant.
`The acceptable ranges of variation can be
`determined by watching network performance over a
`, sustained period of operation.
`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.
`
`15
`
`~ e
`
`rror rate
`header byte rate
`packets retransmitted
`bytes retransmitted
`packets after window closed
`bytes after window closed
`
`error rate
`header byte rate
`
`IP
`error rate
`header byte rate
`fragmentation rate
`all ICMP messages of type destination
`
`20
`
`25
`
`30
`
`SONY EXHIBIT 1027- Page 420
`
`FH_000420
`
`
`
`WO 92/19054
`
`-
`
`PCT/US92/02995
`
`;
`
`- 76 -
`
`unreachable, parameter problem,
`redirection
`
`5
`
`QUt
`error rate
`runts
`the above(cid:173)
`For diagnosing network segment problems,
`identified parameters are also useful with the addition
`of the alignment rate an~ the COllision rate at the DLL.
`Allor some SUbset of these parameters may be included
`10 among the set of parameters which are examined during the
`diagnostic procedure to detect and isolate network
`problems.
`The above-described technique can be applied to a
`wide range of problems on the network,
`including among
`15 others, the following:
`TCP Connection fails to establish
`UDP Connection performs poorly
`UDP not working at all
`IP poor performance/high error rate
`IP not working at all
`DLL poor performance/high error rate
`DLL not working at all
`For each of these problems,
`the diagnostic approach would
`be similar to that described above, using, of course,
`25 different parameters to identify the potential problem
`and isolate its cause.
`The Event Timing Module
`the RTP is programmed
`Referring again to Fig. 5,
`to detect the occurrence of certain transactions for
`30 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
`
`20
`
`SONY EXHIBIT 1027- Page 421
`
`FH_000421
`
`
`
`- 77 -
`
`5
`
`at the Network Monitor, are parsed by the RTP and then
`passed to Event Timing Module (ETM) for pro~essing. 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
`transaction time).
`The transaction time provides a
`useful measure of network performance and if measured at
`10 various times throughout the day under different load
`conditions qives 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.
`In general, when the RTP detects an event", it
`transfers contr~ 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 tr~nccction
`time.
`
`15
`
`20
`
`Event timing database 300 is an array of records
`Each record 302 includes a dialog field 304 for
`25 302.
`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
`30 storing the arrival time of the initiating event and an
`average delay time field 310 for storing the computed
`average delay for the transactions. A more detailed
`description of the operation of the ETM follows.
`Referring to Fig. 35, when the RTP detects the
`35 arrival of a packet of the type for which timing
`
`SONY EXHIBIT 1027- Page 422
`
`FH_000422
`
`
`
`,,:.-_...
`
`WO 92/19054
`
`-
`
`PCf/US9U02995
`
`,;
`
`- 78 -
`
`5
`
`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 then determines whether it is to keep timing
`information for that particular event by checking the
`event timing database (step 322).
`Since each event type
`can have mUltiple occurrences (i.e., there can be
`mUltiple dialogs at a given layer),
`the dialoq identifier
`is used to distinguish between events of the same type
`10 for different dialoqs and to identify those for which
`information has been requested. All of the dialoq/events
`of interest are identified in the event timing database.
`If the current dialog and event appear in the event
`indicating that the event should be
`timing database,
`15 tillled,
`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
`20 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
`specified in the packet being parsed.
`For example, if
`the event is a file read a start time is stored.
`If the
`25 event is the read completion it represents an end time.
`In general, each protocol event will have its own
`intrinsic meaning for how to determine start and end
`times.
`
`Note that the arrival time is only an estimate of
`30 the actual arrival time due to possible queuing and other
`processing delays. Nevertheless,
`the delays are
`generally so small in comparison to the transaction times
`being measured that they are of little consequence.
`In step 324, if the event represents a start time,
`35 the ETM gets the current time from the kernal and stores
`
`SONY EXHIBIT 1027- Page 423
`
`FH_000423
`
`
`
`•
`
`- 79 -
`
`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
`5 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
`10 event (step 330).
`Anyone of many different methods can be used to
`compute the running average transaction time.
`For
`example,
`the following formula can be used:
`New Avg. = [(5 * Stored Avg.) + Transaction
`15 Time]/6.
`the computed new
`After six transaction have been timed,
`average becomes a running average for the transaction
`times.
`The ETM stores this computed average in the
`appropriate record of event timing database 300,
`20 replacing the previous average transaction time stored in
`, that record, and it clears start time entry field 308 for
`that record in preparation for timing the next
`transaction.
`After processing the event in steps 322, 326, and
`the ETM checks the age of all of the start time
`25 330,
`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
`30 partner event has not.occurred within ..a reasonable period
`of time,
`the ETM deletes the old start tim~ entry. for
`that dialog/event (step 334). This insures that a missed
`packet for a partner event does not result in an
`erroneously large transaction time which throws off the
`3S running average for that event.
`
`SONY EXHIBIT 1027- Page 424
`
`FH_000424
`
`
`
`~ L_.
`
`.
`
`WO 92/19054
`
`I
`
`- PCf/US92102995
`
`- 80 -
`
`If the average transaction time increases beyond a
`prese~ected threshold set for timing events, an a~arm is
`sent to the Workstation.
`Two examp~es wi~l now be described to illustrate
`5 the operation of the ETM for spec!f ic event types.
`In
`the first example, 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 seqment as node A, but this is not a
`10 requirement. When 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
`15 at Which the read was initiated.
`After some delay, caused by the transmission
`de~aysof 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 ~n returning the
`20 read response,
`the Network Monitor receives the second
`packet for the event. At the time,
`the ETM recoqnizes
`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 E'l'M' then
`25 compares the average transaction time with the thresho~d
`for this event and if it has been exceeded,
`issues an
`alarm to the Workstation.
`In the second example, node A is communicating
`with Node B using the Telnet protocol. Telnet is a
`30 virtual terminal protocol.
`The events of interest take
`place long after the initial connection has been .
`(VT100
`established. Node A is typing at a standard ASCII
`class) terminal which is logically (through the network)
`connected to Node B. Node B has an application which is
`35 receiving the characters being typed on Node A and, at
`
`SONY EXHIBIT 1027- Page 425
`
`FH_000425
`
`
`
`•
`
`- 81 -
`
`15
`
`indicated by the logic of the
`appropriate times,
`applications, sends characters back to the terminal
`located on Node A.
`Thus, every time node A sends
`characters to B,
`the Network Monitor sees the
`5 transmission.
`there are several transaction times
`In this case,
`, which could provide useful network performance
`information. They include,
`for example,
`the amount of
`time it takes t~ echo characters typed at the keyboard
`10 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.
`In this example,
`the particular time being
`measured is the ~ime 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
`20 acknowledge end-to-end time delays.
`Note that this is a design choice of the
`implementation and that all events visible to the Network
`Monitor by virtue of the fact that information is in the
`packet could be measured.
`the
`When Node A transmits a data packet to Node B,
`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
`30 timing database and returns control to the RTP after
`checking for aging.
`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
`35 ETM, which recognizes it as an end time event.
`The ETM
`
`25
`
`",
`
`SONY EXHIBIT 1027- Page 426
`
`FH_000426
`
`
`
`~I;-I--
`
`WO 92/19054
`
`I
`
`e PCT/US92102995
`
`f '•
`
`- 82 -
`
`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
`5 exceeded,
`the ETM'issues an alarm 'to the Workstation.
`Note that this example is measuring something very
`different than the previous example.
`The first example
`measures the time it takes to traverse the network,
`perfora an action and return that result to the
`10 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
`15 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
`associated with network traffic, but no~ anything having
`20 to do with non-network processing.
`the ETM
`As can be seen from the above examples,
`can measure a broad range of events.
`Each of these
`events can be measured passively and without the
`cooperation of the nodes that are actually participating
`25 in the transmission.
`The Address Tracker Module (AtM)
`Address tracker module (ATM) 43, one of the
`software modules in the Network Monitor (see Fig. 5),
`operates on networks on which the node addresses for
`30 partiCUlar node ~o node connections are assigned
`dynamically. An AppletalkGD Network, developed by Apple
`Computer Company,
`is an example of a network which uses
`dynamic node addressing.
`In such networkS,
`the dynamic
`change in the address of a particular service causes
`35 diffiCUlty trOUbleshooting the network because the
`
`SONY EXHIBIT 1027- Page 427
`
`FH_000427
`
`
`
`•
`
`•
`
`- 83 -
`
`15
`
`network manager may not know where the various nodes are
`and what they are called.
`In addition,
`foreign network
`addresses (e.g.,
`the IP addresses used by that rc~~ for
`communication over an IP network to which if is
`5 connected) can not be relied upon to point to a
`particular node.
`ATM 43 solves this problem by passively
`monitoring the network traffic and collecting a table
`showing the node address to node name mappings.
`In the following description,
`the network on which
`10 the Monitor is located is assumed to be an Appletalk~
`Network. Thus, as background for the following
`discussion,
`the manner in which the dynamic node
`addressing mechanism operates on that network will first
`be described.
`When a node is activated on the Appletalke
`Network, it esta~lishes its own node address in
`accordance with protocol referred to as the Local Link
`Access Protocol
`(LLAP). That is,
`the node guesses its
`own node address and then verifies that no other node on
`20 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 particul~r address
`unless another node responds that the address has already
`25 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
`30 node finds an unused address.
`When the first node wants to communicate with a
`'second node, it must determine the dynamically a~signed
`node address of the second node.
`It does this in
`accordance with -another protocol referred to as the Name
`35 Binding Protocol
`(NBP).
`The Name Binding Protocol is
`
`SONY EXHIBIT 1027- Page 428
`
`FH_000428
`
`
`
`WO 92119054
`
`PCf/US92102995,
`
`•
`
`i
`
`- 84 -
`
`used to map or bind human understandable node names with
`machine understandable node addresses.
`The NSP allows
`nodes to dynamically translate a string of characters
`(i.e., ~ node name)
`into a node address.
`The node
`5 needing to communicate with another node broadcasts an
`NaP 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
`10 original requesting node.
`The first node then uses that
`address its current communications with the second node.
`Referring to Fig. 36,
`the network includes an
`Appletalk~ Network segment 702 and a TCP/IP segment 704,
`each of which are connected to a larger network 706
`15 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 seqment 702 along with other nodes 711. A
`Management Workstation 716 is located on segment 704.
`20 is assumed that Monitor 7io has the features and
`capabilities previously described;
`therefore,
`those
`features not specifically related to the dynamic node
`addressing capability will not be repeated here but
`rather the reader is referred to the earlier discussion.
`25 Suf~ice it to say that 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 AppletalkS family of protocols
`and to communicate the information which it extracts from
`30 the network to Management Workstation 716 located on
`seqment 704.
`Within Monitor 710, 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
`35 name field 724, a node address field 726, an IP address
`
`It
`
`SONY EXHIBIT 1027- Page 429
`
`FH_000429
`
`
`
`••
`
`•
`
`- 85 -
`
`ATM 714 uses Name Table
`field 728, and a time field 729.
`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
`5 the folloWing description of how ATM 714 operates.
`In general, Monitor 710 operates as previously
`described. That ~s, it passively monitors all packet
`traffic over segment 702 and sends all packets to RTP 712
`for parsing.
`When RTP 712 recognizes an Appletalk
`10 packet, it transfers control to ATM 714 which analyzes
`the packet for the presence of address mapping
`information.
`The operation of ATM 714 is shown in greater
`detail in the flow diagram of Fig. 38. When ATM 714
`15 receives control from RTP 712, it takes the packet (step
`, 730 and strips o~f the lower layers of the protocol until
`it determines whether there is a Name Binding Protocol
`message inside ~e packet (step 732).
`If it is a NBP
`message, OATH 714 then determines whether it is new name
`20 Lookup message (step 734).
`If it is a new name Lookup
`message, ATH 714 extracts the name from the message
`(i.e.,
`the name for which a node address is being
`requested) and adds the name to the node name field 724
`of a record 722 in Naae Table 720 (step 736).
`If the message is an NBP message but it is not a
`LookUp 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
`30 the message and adds this information to Name Table 720.
`ATM 714 does this by aearching 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
`
`25
`
`35
`
`!
`
`SONY EXHIBIT 1027- Page 430
`
`FH_000430
`
`
`
`"'l
`
`WO 92119054
`
`•
`
`-
`
`PCf/US92102995
`
`- 86 -
`
`5
`
`field 729 to record the time at which the message was
`1:\rocessed.
`After ATK 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).
`ATK 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
`~o awaits the next packet from RTP 712.
`As ATM 714 is processing each a packet and it
`determines either that it does not contain an NaP message
`(step 732) or it does not contain a Lookup Reply message
`(step 738), ATK 714 branches to step 742 to perform the
`15 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
`2 0 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
`25 thUS,
`they can not easily track down problems created by
`the particular node.
`ATM 714 can use passive monitorinq of the IP
`address assignment mechanisms to provide the network
`manager a Name-to-IP address mapping.
`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
`35 is a response to an IP address request (step 750).
`IP
`
`30
`
`SONY EXHIBIT 1027- Page 431
`
`FH_000431
`
`
`
`•
`
`•
`
`- 87
`
`address requests are typically implied by an NSP 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 NSP
`5 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).
`After storing the- IP address assignment
`10 information, ATM 714 locates all other records 722 in
`Name 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
`15 records (step 756). After doing this cleanup step, ATM
`714 returns contr.ol to RTP 712.
`other embodiments are within the following claims.
`For example,
`the Network Monitor can be adapted to
`identify node types by analyzing the type of packet
`20 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
`25 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.
`
`SONY EXHIBIT 1027- Page 432
`
`FH_000432
`
`
`
`WO 92/19054
`
`. ~
`
`PCfIUS92102995
`
`- 88 (cid:173)
`APPENDIX I
`
`SNMP MIBSubset suppor~ed
`
`This is the subset of the standard MIB which can be
`obtained by monitoring.
`
`Refer to'RFC 1066 Management Information Base for an
`explanation on the·items which follow.
`
`System group:
`none
`
`Interfaces group
`ifType
`ifPhysAddress
`ifOperstatus
`iflnOctets
`iflnUcastPkts
`iflnNUcastPkts
`i
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
