SELF PREDICTING COMMUNICATIONS NETWORKS

Abstract: The invention provides a self-predicting communications network and method, that is, a computer network configured to act as a communications medium and a simulator simultaneously. Such a computer network comprises at least one source unit configured to generate messages, at least one destination unit configured to receive messages, and at least one intermediate device coupled to both the source unit and the destination unit for passing the messages therebetween. The intermediate device is configured to respond to the messages so as to provide future state information of at least a portion of the computer network.

Description: SELF PREDICTING COMMUNICATIONS NETWORKS CROSS REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of the filing date of Provisional Application Serial No. 60/103,936, filed October 13,1998 entitled "ACTIVE NETWORK MANAGEMENT", and of Provisional Application Serial No. 60/105464 filed October 23, 1998 entitled "ACTIVE NETWORK MANAGEMENT" both of which are incorporated herein by reference in their entirety. The U.S. Government may have certain rights in this invention pursuant to contract number F30602-98-0230 awarded by the Department of the Air Force. BACKGROUND OF THE INVENTION The present invention relates generally to communications networks and in particular to a communications network capable of modeling and predicting its own behavior by acting as a communications medium and a simulator simultaneously. Vast global communications architectures are emerging as a result of networking millions of computers via the Internet. Wireline, wireless, and satellite technologies now interconnect hundreds of millions of diverse processors, also referred to herein as network users. The goal of network management is to allocate network resources in order to meet a specified operational objective, for example, to provide the best quality of service possible for all user flows within the network. The problems of managing these vast networks, and the challenges of designing and implementing new network architectures are rapidly compounding. The problem of allocating network resources is greatly aided by knowledge of future network usage. One approach to managing complex networks is to employ simulators to model the behavior of the network and predict the future performance of the network based on the modeled behavior. The models and predictions generated by such simulators are utilized to configure network resources, i.e., components such as processors, routers, etc. such that bottlenecks are avoided and network performance is optimized. To that end a number of techniques for simulating the behavior of computer networks have been developed. For example, the field of parallel discrete event simulation (PDES) has grown over the past fifteen years to accommodate the need for simulating complex networks. Various PDES-based tools have been developed to simulate and predict network behavior under a variety of conditions so that optimum network designs and implementations can be realized. The tools for performing such simulations typically comprise a plurality of dedicated parallel, distributed processors programmed to carry out discrete event simulation algorithms. However, these processor clusters are typically dedicated to the simulation task and generally are not configured to simultaneously execute network user applications. Typically, the simulators themselves are much less vast, and less complex, than the actual networks they attempt to simulate. For that reason, such simulators have disadvantages limiting their usefulness in modeling the performance of "real world" networks. For example, scaling problems often occur when solutions and predictions based on simulator models are applied to vastly more complex real world situations. Current network modeling tools and simulation techniques have not readily scaled to systems having the complexity, for example, of the Internet. Therefore, a need exists for improved methods and apparatus for modeling and predicting the behavior of communications networks and for managing those networks based on the predictions. BRIEF SUMMARY OF THE INVENTION The invention provides a self-predicting communications network and method, that is, a computer network configured to act as a communications medium and a simulator simultaneous!) . Such a computer network comprises at least one source unit configured to generate messages, at least one destination unit configured to receive messages, and at least one intermediate device coupled to both the source unit and the destination unit for passing the messages therebetween. The intermediate device is configured to respond to the messages so as to provide future state information of at least a portion of the computer network. BRIEF DESCRIPTION OF THE DRAWINGS FIGURE 1 is a pictorial diagram showing a general configuration of a computer network. FIGURE 2 is a block diagram of a source unit of the present invention. FIGURE 3 is a block diagram of an intermediate device of the present invention. FIGURE 4 depicts a message packet structure according to an embodiment of the present invention. FIGURE 5 depicts an active message packet structure according to an embodiment of the invention. FIGURE 6 is a block diagram representing the configuration of software components of the present invention DETAILED DESCRIPTION OF THE INVENTION FIGURE 1 is a pictorial diagram showing the overall structure of a typical computer network 100. Network 100 comprises one or more source units 102, one or more destination unιtsl03 and one or more intermediate devices 101. For purposes of explanation and clarification, source units 102 and destination units 103 are depicted separately in FIG. 1. However, it is understood that network units are generally configured to operate as both source and destination components, and can both send and receive messages over the network. For purposes of this specification, the term "configured" means "including suitable components comprising software components and hardware components, workably programmed and assembled". Source and destination units 102 and 103 typically compπse a variety of processors and computers (including personal computers, main frame computers, minicomputers and lap top computers) Typical intermediate devices include routers, switches repeaters, hubs and the like Network units 102 and 103, and intermediate devices 101 are interconnected via netwoik 104 A netwoik is defined to be two or more computers connected for the purpose of exchanging messages and sharing data and system resources In one embodiment of the invention network 104 represents the Internet The Internet is a wide aiea network (WAN) that connects a plurality (for example, thousands) of networks in a plurality of countπes, for example, the U S , Canada, Europe, and Asia Generally, the Internet provides global communications between computeis on networks selected from, but not limited to, the group consisting of government, educational, and industπal networks Alternative embodiments of the invention include those in which network 104 compπses a Local Area Network, interconnected private or dedicated network lines, a Wide Area Network and combinations thereof As shown in FIG 1 communication ι- accomplished by relaying messages between units 102 and 103 via network 104 In one embodiment of the invention a "packet switching" architecture is employed to relay messages The term "packet-switched" descπbes the type ot network in which messages compπse relatively small units of data called packets, and die touted thiough a netwoik based on the destination address contained withm each packet Breaking communication down into packets allows the same data path to be shared among many users in the network Packets typically compπse at least a field containing routing information and a field containing the data representing at least a portion of a message Packets are routed between source and destination components in accordance with a predetei ined communication protocol Examples of common communications piotocols include Tiansmission Control Protocol/Internet Protocol (TCP/IP) and Open Systems Interconnection (OSI) protocol Also shown in FIG 1 is a conventional simulator 105 Simulator 105 is programmed to simulate netwoik 100 using a simulation technique known in the art. One example of such a technique is parallel discrete event simulation. Simulator 105 is shown separated from network 100 to illustrate the fact that in a typical prior art system, the simulation occurs independently of network operation. Simulator 105 bases its simulation upon knowledge of the network 100 supplied by an operator or upon data gathered by a program designed to collect network data. In accordance with the present invention, at least one source unit 102 is configured as illustrated in FIG. 2. In one embodiment of the invention at least one source unit 102 is a computer, for example, a personal computer connected to the Internet. In another embodiment of the invention at least one source unit 102 is a dedicated processor connected to a Local Area Network. As those of ordinary skill in the art will recognize source unit 102 can be selected from a group consisting of a wide variety of processors and computers in various network configurations. In the embodiment shown in FIG. 2 source unit 102 comprises conventional computer components such as processor 402, memory 403, and terminal Input Output (I/O) unit 405 coupled to display and keyboard 406. Data bus 407 interconnects the components such that data and commands may be passed therebetween. Line control unit (LCU) 420 interconnects source unit 102 with network 104 (also illustrated in FTG.l). However, unlike conventional computer components, processor 402 of source unit 102 includes a driving unit 416 and a virtual message generator 415. Driving unit 416 is a processor configured to execute a "driving program". For purposes of this specification, a "driving program" is a program that monitors network user applications and the resources these applications consume during their execution. Driving programs gather statistics related to the user applications and associated processes executing on a given processor 402 of source component 102. Examples of such statistics include, but are not limited to, message flow rates, message types, size, time, etc. Driving programs use these statistics to make projections about the processes which will run on processor 402 in the future, including future message traffic and resource utilization information. A number of commonly used network traffic prediction techniques are suitable for use in the present invention. For example, a suitable technique is described by S. Ma and C. Ji, "Wavelet Domain Modeling of VBR Video Traffic" IEEE/ACM MFOCOM, 1998, and C. Hood and C. Ji, "Pro-active Network Fault Detection/' Proc. IEEE/ACM INFOCOM, 1997. Examples of commercially available driving programs suitable for use in the present invention include COMNET EH™, available from CACI Products Company 3333 N. Torrey Pines Ct La Jolla, CA 92037. Virtual message generator 415 is a processor programmed to carry out the driving process algorithm described in Table 1. In accordance with the driving process algorithm, virtual message generator 415 communicates with driving unit 416. Based upon the information it collects from driving unit 416, virtual message generator 415 generates virtual messages. For purposes of this specification the term "virtual message" refers to messages including data and destination information related to logical processes. Logical processes are processes that represent and emulate, in the present time, physical processes expected to execute at some future time. A "physical process" is an executing task defined by program code. Examples of physical processes include updating a field in a table of a database, incrementing a counter, and computing a beam table for a beam angle in a beam-formed communication system. Logical processes typically maintain their own private notion of time, known in the simulation art as Local Virtual Time (LVT). While a logical process emulates a physical process in the present time, the processor must maintain knowledge of the time the corresponding physical process is expected to run. This time is Local Virtual Time (LVT). Therefore, a logical process comprises the physical process plus additional data structures and instructions for maintaining message order and correct operation as the system executes ahead of real time. As those of ordinary skill in the simulation arts will recognize, it is possible for such logical processes to "rollback" because of violations of causality or "out of order" messages. A discussion of rollback as a causality avoidance technique is provided by Jefferson and Sowizral, in "Fast Concurrent Simulation Using the Time Warp Mechanism," Distributed Simulation, 1985, The Society for Computer Simulation Multiconference, San Diego, Calif. This paper teaches a technique in which each unit of a simulated network is allowed to execute ahead of real time at its own risk. When a message arrives that would have caused some events not to have executed, a rollback is executed to undo the simulation that took place. Rollback of a unit is not necessarily difficult. However, the fact that the simulated events that need to be rolled back may have caused messages to be sent to other units complicates the task substantially. To achieve the rollback, Jefferson et al. describe the use of "anti- messages," which are messages that parallel the original messages, except that they cause the performance of some action that "undoes" the original action. Rollback techniques are sometimes employed in discrete event simulations. Though the techniques have not typically been employed in communications networks, the technique is suitable for use in the network of the present invention. Because each unit and device depicted in network 100 operates according to its own notion of time, i.e., LVT, determining the latest virtual time, i.e., the furthest into the future, that each unit of the entire network has emulated is important in managing the network. The latest virtual time that all units of the entire network have emulated is known as Global Virtual Time (GVT). The term "realtime" message (RT) refers to messages which are generated and time stamped with the current time, i.e., "wall clock" time. RT messages are typically generated by network components in the course of executing network user application programs. As outlined in Table 1, virtual message generator 415 performs the following steps to communicate with driving unit 416 and generate virtual message 400. First, at (2), virtual message generator 415 determines that GVT has not exceeded look-ahead time. That is, it checks that GVT is sufficiently close (within A) to real time (t) such that the virtual messages it generates will execute close enough to real time such that network performance does not degrade unacceptably. In other words A is a "look-ahead" time which limits how far in the future the simulation will run. In one embodiment of the invention, A is set to 200 seconds. However, it will be recognized by those of ordinary skill in the art that A is highly variable and depends on a number of conditions. In some situations it is desirable to have a simulation run days into the future, and in other situations weeks or more into the future. In contrast, some highly dynamic networks will run a simulation only milliseconds into the future. If the GVT of network 100 is within A of real time, virtual message generator 415 queries driving unit 416 for message contents M at a desired time in the future (LVT + Δ) . Message content M is information corresponding to some aspect of predicted message traffic, e.g., flow rate. Next, the receive time RT of the virtual message is set to correspond to a desired future time (LVT + Δ) . Finally, the newly created virtual message is sent. TABLE 1. FIG. 3 illustrates an intermediate device 101 in accordance with the present invention. Intermediate device 101 is selected from the group of network devices and components consisting of: routers, switches, hubs and repeaters and the like. Regardless of the selected device type, intermediate device 101 typically comprises conventional components such as processor 202 and memory 203 interconnected via data bus 207. Memory 203 stores therein programs, data and messages for transmission and reception. However, in contrast to conventional components intermediate device 101 of the present invention further comprises network management unit 204 and logical processor 208. While real-time processor 209 of processor 202 acts as a typical network component processor, that is, it responds to real-time messages being communicated via network 104, logical processor 208 is configured to execute logical processes in local virtual time. In addition, logical processor 208 is programmed to carry out the logical process algorithm described in Table 3 in response to virtual messages received by intermediate unit 101. For purposes of this discussion real-time processor 207 and virtual processor 208 are presented and discussed separately. However, those of ordinary skill in the art will recognize that a single processor can be programmed to perform the operations of both logical processor 208 and real-time processor 207 In further contrast with conventional intermediate devices, memory 203 of intermediate device 101 includes real-time memory 210 and virtual memory 212. Real time memory 210 stores present state information related to intermediate device 101 as physical processes aie executed by processor 202 Virtual memory 212 stores future state information about intermediate device 101 as logical processes are executed by processoi 202 For pui poses ol this specification, the term "state' means a set of parameters characteπzing the operational status of a unit at a given time, usually upon execution of a process. The tabulated parameter set is stored in memory in the form of a "state table". The term "computation" in simulation applications, and for purposes of this specification, refers to a set of operations, called "event computations", which modify the "state" of a unit A prior state is stored in memory before the state is modified by a subsequent e\ ent computation. Upon rollback, the pnor state is restored by copying back the sa\ ed value One embodiment of the invention utilizes real time memory 210 and virtual memory 212 to determine the accuracy of an event computation simulation Thus a measure of how well a logical process has simulated its corresponding physical process can be obtained Attei a logical piocess has executed on processor 202 intermediate unit 101, the state of unit 101 is stored in virtual memory 212. Subsequently, when processor 202 of intermediate unit 101 executes the corresponding physical process the state of unit 101 is stored in real time memory 210. The two states are then compared to determine how closely they match. If the states are identical the simulation was correct. In one embodiment of the invention, intermediate device 101 further includes netwoik management unit (NMU) 204. NMU 204 comprises a management information base (MIB) residing in a memory of intermediate device 101 A MIB is a virtual information store thiough which managed objects are accessed As those of ordinary skill in the art will recognize, and for purposes of this specification, an "object" is a data representation that describes a portion of a unit. The unit represented may be physical, e.g. intermediate unit 101, or may be a software object. An OBJECT IDENTIFIER, an administratively assigned name, applies a respective unique identifying name to each object type. The object type together with an object instance serves to uniquely identify an instantiation of the object For human convenience, a textual string, termed the descriptor, is used to refer to the object type. MLBS are commonly used to manage network objects However, in contrast to typical MIB object types, the MIB of NML 204 comprises object types relating to future states of network 100. Further, the MDB of NMU 204 gathers information from virtual message packets as they are routed through intermediate device 101. In one embodiment of the invention, at least one active message packet 500, including a code portion 510, is deployed to gather information about the network from the MLB of NMU 204. Code portion 510 is programmed to query the MIB for the information the MIB has gathered from other message packets which have previously passed through intermediate device 101 In response to the query, active message packet 500 receives information from the MLB and embeds the information within active message packet 500. Accordingly, the contents of active message packet 500 are changed as packet 500 passes through intermediate device 101. In the configuration described above, code portion 510 acts as a traveling simple network management protocol (SNMP) client, while the MIB acts as an SNMP agent. As will be appreciated by those of ordinary skill in the art, active messages 500 in accordance with the invention, need not be restπcted to use in simulation applications. Active messages 500 can be deployed to query a typical MLB for information related to present states of network 100, thus providing network 100 with traveling SNMP client capability. In one embodiment of the invention active messages 500 are deployed to query a MIB adapted in accordance with the present invention. Such a MLB compπses information gathered from virtual messages related to future states of Network 100. An example of an MIB suitable for use in such an application is described in Table 4. As shown in Table 4, the MLB of the present invention defines three novel managed object types, the MIB itself (AvnmpMIB), packets (AvnmpPacket), and logical Processes (logical process), according to one embodiment of the present invention. While these objects are managed via the well-known Simple Network Management Protocol (SNMP), the object types themselves represent one embodiment of the present invention. As shown in FIG. 3 virtual messages are provided to logical processor 208. Table 2 illustrates structural elements of logical processor 208 according to the invention including the following: a receive queue (QR) for storing messages in order of receive time (TR), a send queue (QS) for storing messages in order of send time (TS), an LVT table, a current state table for storing the current state of the logical and physical processes, a state queue (SQ) for periodically saving states, a sliding look- ahead window (A) value and a tolerance value representing the allowable deviation between real time and LVT. TABLE 2. Logical processor 208 is further programmed to carry out the steps of the algorithm outlined in Table 3. As shown in Table 3, logical processor 208 initially keeps time by carrying out steps 1 and 2. That is, logical processor 208 sets LVT to 0. Then, logical processor 208 sets real time "t" in accordance with wall clock time. In the embodiment of the invention described in Table 2, wall clock time is obtained from a global positioning system (GPS). Other means of obtaining wall clock time are commercially available and will be readily apparent to those of ordinary skill in the art. Step 3 repeats the first two steps indefinitely as long as no messages are available in the receive queue (QR). When messages are present in the receive queue, step 4 reads in the message with the lowest receive time (TR) Step 5 updates the current state based upon the message value read in step 4 In step 6, it is determined if the message is real and if it is out of tolerance If so, a lollback is initiated Step 7 checks whether the message occurred in the past relative to the local virtual time. If so, a rollback is initiated. If the message is real and the prediction was within tolerance, then step 8 invokes any irreversible actions that must be taken in order to execute the process. Step 9 checks if a logical process has not exceeded its look-ahead. If not, then the logical process is executed based on the following steps Step 10 updates the state queue based upon the input message and the current local virtual time. Step 11 sets the time to local virtual time. Step 12 generates a new virtual output message, if necessary, based upon the current input message and local virtual time Step 14 saves a copy of the output message in the send queue in case of future rollbacks Step 15 sends the new virtual message. TABLE 3. TABLE 4. Simple Network Management MLB The following Simple Network Protocol Management Information Base is used for Network Management Prediction Logical Processes and Virtual Messages. AvnmpMIB OBJECT IDENTIFIER ::= { expeπmental ncp(75) 4 } AvnmpPacket OBJECT IDENTIFIER ::= { experimental ncp(75) 5 } logicalProcess OBJECT IDENTIFIER ::= { AvnmpMIB 1 } — Logical Process Table logicalProcess OBJECT IDENTIFIER ::= { AvnmpMIB 1 } logicalProcessTable OBJECT-TYPE SYNTAX SEQUENCE OF LogicalProcessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of AVNMP LP information." ::= { logicalProcessTable 1 } logicalProcessTable OBJECT-TYPE SYNTAX LogicalProcessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of AVNMP LP information." INDEX { logicalProcessID } ::= { logicalProcessTable 1 } LogicalProcessEntry ::= SEQUENCE { logicalProcessID DisplayString, logicalProcessLVT INTEGER, logicalProcessQRSize INTEGER, logicalProcessQSSize INTEGER, logicalProcessRollbacks INTEGER, logicalProcessSQSize INTEGER, logicalProcessTolerance INTEGER, logicalProcessGVT INTEGER, logicalProcessLookAhead INTEGER, logicalProcessGvtUpdate INTEGER logicalProcessID OBJECT-TYPE SYNTAX DisplayStπng MAX-ACCESS read-only STATUS current DESCRIPTION "The LP identifier " • = { logicalProcessEntry 1 } logicalProcessLVT OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the LP Local Virtual Time." ::= { logicalProcessEntry 2 } logicalProcessQRSize OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX- ACCESS read-only STATUS current DESCRIPTION "This is the LP Receive Queue Size." "= { logicalProcessEntry 3 } logicalProcessQSSize OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the LP Send Queue Size." : • = { logicalProcessEntry 4 } logicalProcessRollbacks OBJECT-TYPE SYNTAX INTEGER (O 2147483647) MAX-ACCESS lead-only STATUS current DESCRIPTION "This is the number of rollbacks this LP has suffered." ::= { logicalProcessEntry 5 } logicalProcessSQSize OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the LP State queue size." ::= { logicalProcessEntry 6 } logicalProcessTolerance OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the allowable deviation between process's predicted state and the actual state." :.= { logicalProcessEntrv 7 } logicalProcessGVT OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is this system's notion of Global Virtual Time." ::= { logicalProcessEntry 8 } logicalProcessLookAhead OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is this system ' s maximum time into w ich it can predict." ::= { logicalProcessEntry 9 } logicalProcessGvtUpdate OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the GVT update rate." ::= { logicalProcessEntry 10 } logicalProcessStepSize OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the time until next virtual message." ::= { logicalProcessEntry 11 } — Avnmp Packet Table avnmpPacketData OBJECT IDENTIFIER ::= { AvnmpPacket 1 } packetTable OBJECT-TYPE SYNTAX SEQUENCE OF PacketEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of AVNMP LP information." ::= {avnmpPacketData 1 } packetEntry OBJECT-TYPE SYNTAX AvnmpPacketEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of AVNMP LP information." INDEX { avnmpPacketlndex } ::= { packetTable 1 } avnmpPacketEntry ::= SEQUENCE { avnmpPacketlndex INTEGER, avnmpSource DisplayStπng, avnmpRcvTime INTEGER, avnmpDestination DisplayStπng, avnmpSndTime INTEGER, avnmpPayload INTEGER } avnmpPacketlndex OBJECT-TYPE SYNTAX INTEGER (O.2147483647) MAX-ACCESS iead-only STATUS current DESCRIPTION "The packet identifier/' • • = { packetEntry 1 } avnmpSource OJBECT-TYPE SYNTAX DisplayStπng FIG. 4 illustrates a message packet format 400 according to one embodiment of the present invention. In one embodiment of the invention message packet format 400 is used for both virtual and real messages In another embodiment message packet 400 is used for virtual messages and a simplified format, that is, a format not including fields used for virtual time keeping, is used foi real messages Field 401 is a typical header field which includes information about the source and destination of the message. Field 402 indicates send time (TS). TS is the LVT of the sending process at the time message 400 is sent. Field 403 indicates receive time (TR). TR is the time message 400 is scheduled to be received by a receiving process of a destination unit. Field 404 identifies message 400 as either a message or an "anti- message". An anti-message is a message which causes a receiving process to rollback due to an out of tolerance, or causality, condition. Such an error would occur, for example, if the TS of message 400 were earlier than the LVT of its receiving process, as explained below. Field 405 indicates M, the actual contents of the message, and 406 indicates real time, or the clock time at which the message originated. In one embodiment of the invention, clock time is determined by a global positioning system. In one embodiment of the invention, at least one of the messages describe above is an "active" message, as illustrated in FIG. 5. An "active" message 500 is a message whose packet contains an executable code portion 510 in addition to at least one of the fields illustrated in the packet format of FIG. 4. In one embodiment of the invention executable code portion 510 of active packet 500 is general purpose code, implemented in the JAVA programming language, and executed by processor 202 of intermediate device 101 as packet 500 flows to its destination unit 103. As packet 500 travels through the network, executable code portion 510 gathers information about the network from network management unit 204 of the intermediate devices 101 it passes through. Thus packet 500 provides information for management of network 100, and allows network 100 to configure itself to accommodate future traffic conditions. FIG. 6 illustrates the interaction of the software portions of the present invention according to one embodiment of the invention. Upon initial power up, network 100 begins to generate real messages RT. Driving program 302 begins to predict future events and driving process 303 generates virtual messages based on the predicted events. Logical process 307 receives both virtual and real messages. Logical process 307 examines each incoming message and determines whether it is virtual or real by examining the RT field of the message. If the message is a virtual message, logical process 307 examines the send time (TS ) of message. The send time of the message is the LVT of the sending process at the time the message was sent. Logical process 307 compares the TS filed of the virtual message with the LVT of logical process 307. If the message has not arrived in the past relative to the LVT of logical process 307, the message enters the receive Queue (QR) in order of receive lime (TR). Logical process 307 then takes the next message from the receive queue, updates its LVT and processes the message. If an outgoing message is generated, a copy of the message is saved in the Send Queue, RT is set, and the send time (ST) is set to the current LVT. The outgoing message is then sent to the destination logical process 308. If virtual message 400 had aπ ved out of order, that is, with TS in the past relative to the LVT of logical process 307, logical process 307 would have had to rollback in order to restore the last recorded state before time TS. In one embodiment of the invention, virtual messages are stored in a memory, for example a cache memory, of intermediate device 101 as they travel to their destination logical process 308. The virtual messages are indexed and stored according to a key comprising source-destination address of each message they pass through intermediate device 101. When a subsequent message with a key (source- destination addresses) matching a stored key passes through intermediate device 101, the newer message is compared with the stored message. If the stored message has a larger time stamp value (RT), a violation of causality will likely occur when the newer message reaches its destination process. In that case a rollback will be indicated. Thus, early detection of potential rollback conditions is provided to network 100 allowing network 100 to respond appropriately to mitigate the rollback consequences. For example, if many such rollback conditions occur in the same path, the destination process can be slowed. Alternatively, the destination process can be moved to a new destination processor in order to mitigate the temporal effects of a causality violation. After the comparison, the older message is replaced in the queue by the newer message. While only certain preferred features of the invention have been illustrated and described, many modifications and changes will occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.

Claims: WHAT IS CLAIMED IS: 1. A computer network comprising: at least one source unit configured to generate messages; at least one destination unit configured to receive messages; at least one intermediate device for passing said messages from said at least one source unit to said at least one destination unit, said intermediate device coupled to said at least one source unit and to said at least one destination unit; said at least one intermediate device configured to respond to said messages so as to provide future state information of at least a portion of said computer network. 2. The computer network of claim 1 wherein said messages include both real messages and virtual messages and wherein said source unit includes a virtual message generator. 3. The computer network of claim 1 wherein said messages are active messages. 4. The computer network of claim 3 wheiein said active messages include code portions, said code portions being executed on said intermediate unit. 5. The computer network of claim 4 wherein the contents of said active messages are changed based upon the execution of said code portions of said active messages. 6. The computer network of claim 2 wherein said source unit further includes a driving unit for predicting network conditions, said virtual message generator coupled to said driving unit so as to generate virtual messages based upon said predicted network conditions. 7. The computer network of claim 6 wherein said driving unit comprises a network traffic prediction program. 8. The computer network of claim 1 wherein said intermediate device is selected from the group consisting of: routers, switches, hubs and repeaters. 9. The computer network of claim 1 wherein said source unit, said destination unit and said intermediate device are interconnected via the Internet. 10. The computer network of claim 2 wherein said intermediate device further includes a logical processor for executing logical processes in response to said virtual messages. 11. The computer network of claim 8 wherein said intermediate device further includes a virtual memory for storing states of said intermediate device coπesponding to executed logical processes. 12. The computer network of claim 8 wherein said intermediate device further comprises a network management unit (NMU) for collecting and storing information based upon the contents of said virtual messages. 13. The computer network of claim 12 wherein said network management unit includes a management information base (MLB) configured to include packets as managed objects. 14. The computer network of claim 13 wherein said network management unit includes a MLB configured to include logical processes as managed objects. 15. A computer network comprising: at least one source unit including a driving unit for predicting usage of said source unit and a virtual message generator configured to provide virtual messages based upon said predicted usage; at least one intermediate unit including: a logical processor for executing logical processes in response to said virtual messages; a network management unit for providing, based upon said virtual messages, information related to future states of said network 16 The network of claim 15 wherein said messages include a code portion and a data portion 17 A computer network comprising a source unit including means for predicting usage of said source unit and means for generating first virtual messages based on said predicted usage; a destination unit including means for executing logical processes in response to said first virtual messages, an intermediate unit including means for executing logical processes in response to said first virtual messages, and for generating second virtual messages based upon said executed logical processes 18 A method for determining the accurac) of an event computation simulation comprising the steps of executing a logical process on a unit including a processor, generating a first state table including state vaπable values representing the state of said unit resulting from the execution of said logical process of the previous step, storing said first state table in memory, executing on said unit including a processor, a physical process corresponding to said logical process, generating a second state table including state vaπable values representing the state of said unit lesulting from said execution of said physical process, comparing said first and said second state tables to determine differences in said state variable values. 19. In a communications network comprising a plurality of interconnected units for sending and receiving messages, and at least one intermediate device for passing said messages therebetween, a method for predicting future states of said network comprising the steps of: generating, by a first unit, virtual messages based on projections of future network usage; executing logical processes on said intermediate device in response to said virtual messages, said logical processes emulating future usage of said network; storing in memory, states of said second unit relating to said logical processes, said stored states representing future states of said second unit. 20. The method of claim 19 including first steps of monitoring network usage of said first unit, and projecting future network usage of said first unit based on said monitored usage. 21. A method for managing a network comprising the steps of: gathering information related to states of the network from messages traveling in said network and storing said information in a MIB; querying said MLB for the information stored therein: managing the network based on the results of the query. 22. The method of claim 21 wherein said MLB contains information related to future states of said network. 23. The method of claim 22 wherein said query is accomplished by executing code contained in a code portion of an active message packet 24. The method of claim 23 wherein said active message packet is a virtual message packet.

Inventors: BUSH STEVEN FRANCIS, BUSH, STEVEN, FRANCIS
Applicants: GEN ELECTRIC, GENERAL ELECTRIC COMPANY
Application year: 1999
Main classification: H04L12
IPC codes: G06F13, G06F19, G06Q10, H04L12, H04Q3