Network architecture with event logging

[0002] This application is a continuation-in-part (CIP) application of U.S. Ser. No. 08/990,096 entitled Secure Network Architecture with Quality of Service, filed on Dec. 12, 1997, which is hereby incorporated by reference.

[0003] The present invention relates generally to network communication and, more particularly to gathering and identifying session startup/teardown information and network router state information that may be used for Internet Service Provider (ISP) billing purposes.

[0004] In order for an Internet Service Provider (ISP) to be able to charge different rates for different levels of service (i.e., sessions that request special quality of service (QoS) or multicast. service), it is necessary for the ISP to be able to collect and store information relative to user sessions. Currently, routers are not generally being designed with Management Information Bases (MIBs) that allow the ISP to monitor the state of the routers contained in a network because of the additional effort and computing resources that would be required. An MIB stores information associated with a network/internet management data.

[0005] In conventional networks, Simple Network Management Protocol (SNMP) messaging has been used to access information from certain network elements relative to the performance of the network. SNMP relates to the management aspects of the network such as fault, security, and accounting management. SNMP messages are used to access information stored in a MIB, but without an MIB. Routers do not contain a MIB, however, and therefore routers cannot store state information. For this reason, SNMP messaging cannot be used to monitor the state data of an ISP router/network.

[0006] Therefore, a need exists for a system that gathers and logs network event information using SNMP messaging. The solution should enable routers within the system to return state information so that ISPs can better track and monitor the types of services its users request.

[0007] Systems and methods consistent with the present invention provide a QoS server that stores and monitors user sessions with SNMP messages. In addition, the QoS server gathers event startup/teardown information and network router state information, and stores this information in a format that can then be easily accessed by an ISP QoS module using SNMP messaging tools.

[0008] Systems and methods consistent with the present invention provide a system for monitoring a communication session between an originating router and a destination router. The system includes: means for periodically transmitting a state query message to the originating router, the state query message including a request for internal router information data; means for receiving, at a node server coupled to the originating router, state information data from the originating router in response to the state query message; means for storing the state information data as an object; means for monitoring the object to detect a change in the state information data; and means for logging a session event when the monitoring means detects the change in the state information data.

[0009] A server system, consistent with the present invention, includes means for receiving a session request for establishing a communication path to transmit information, means for sending a message to an originating router in the communication path in response to the request, the message including a request to reserve resources for transmitting the information, and means for monitoring the originating router to determine whether all of the routers along the transmission path have sufficient resources to establish the communication path in accordance with the session request.

[0010] Both the foregoing general description and the following detailed description provide examples and explanations only. They do not restrict the claimed invention.

[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, explain the advantages and principles of the invention. In the drawings,

[0012] FIG. 1 is a block diagram of a network architecture consistent with the present invention;

[0013] FIG. 2 is a block diagram of the IP/QoS module of FIG. 1; and

[0014] FIG. 3 is a flowchart showing steps, consistent with the present invention, for provision event logging.

[0015] Reference will now be made to preferred embodiments of this invention, examples of which are shown in the accompanying drawings and will be obvious from the description of the invention. In the drawings, the same reference numbers represent the same or similar elements in the different drawings whenever possible.

[0016] FIG. 1 is a block diagram of secure network 100 consistent with the present invention. An Internet Service Provider (ISP) maintains a wide area network (WAN) 150 to which are attached several local area networks LANs 110, 130, and 140. WAN 150 includes a number of interconnected WAN routers 116, 118, and 122, typically referred to as a “Backbone,” and at least one IP/QoS module 120 with an associated firewall 124. WAN routers 116, 118, and 122 are RSVP-capable and might include, for instance, Cisco 7507 routers running the Cisco 11.2 Internet Operating System (IOS). In addition to providing standard best-effort Internet Protocol Service, the WAN routers receive packets of information from the LANs, determine whether the packets have been designated for QoS, and if so, transmit the packets to a destination router in a manner that provides the proper QoS.

[0017] As shown in FIG. 1, IP/QoS module 120 and associated firewall module 124 are located at a QoS hosting site of the ISP. Firewall module 124 monitors traffic to the site, ensuring that all traffic comes from registered and authorized users. Firewall modules are commercially available and could be, for instance, an IBM/PC with IP security software (IPSEC). IP/QoS module 120 could be any workstation running, for example, the Solaris 2.5 or similar operating system. Firewall 124, associated with IP/QoS module 120, connects to router 118 by a communication line, such as a T1, and to IP/QoS module 120 via a local communication line, such as an Ethernet connection.

[0018] IP/QoS module 120 provides a session reservation setup application to the user upon request, accepts requests for QoS from users, transmits these user QoS requests to the WAN routers, monitors the routers to determine whether the QoS request has been established, and then notifies the user of the state of the QoS request. In addition, as explained in detail below, IP/QoS module 120 monitors router state information data and provides MIB format objects that can be retrieved via SNMP messaging. This feature allows the ISP to monitor the conditions of the routers within the network and the activities performed by users of the system.

[0019] As also shown in FIG.1, premises router 114, 126, and 134 are connected to the WAN routers 116, 118, and 122, respectively, via communication lines, such as T1 lines. The premises routers serve as the “originating/destination” routers in the network. Firewall 112 connects to premises router 114, by a local communication line, such as a T1 line, and monitors LAN 110 via a local communication line, such as an Ethernet connection, to monitor traffic into the LAN. LAN 110 supports some number of users, such as hosts 102, 104, and 106 in FIG. ÿ1. Each host platform could be any personal computer or workstation computer running browser software, such as Netscape 3.0 or Internet Explorer 3.0 software. Firewalls 128 and 136 are similarly attached to premises routers 126 and 134, respectively, and monitor traffic into LANs 130 and 140, respectively. LANs 130 and 140 are shown as supporting hosts 132 and 138, respectively, although more hosts could be supported.

[0020] FIG. 2 shows a block diagram of IP/QoS module 120 along with certain WAN and LAN elements. The LAN, hosts, firewalls, premises router, and WAN router include the interconnection communications lines described above with reference to FIG. 1. For purposes of illustration, router 114 has been depicted as a premises router, while router 126 is depicted as a destination router. IP/QoS module 120 includes a browser user interface (BUI) 210, a session setup server 215 with a setup applet 220, an RSVP node server 225, an event server 230, an event logger 232, and a database server 235 with a corresponding database module 240.

[0021] In general, IP/QoS module 120 executes software instructions read into a main memory from another computer-readable media. Execution of the sequences of instructions contained in the main memory (not shown) causes module 120 to perform the process steps described herein. In an alternative embodiment, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

[0022] The term “computer-readable medium” as used herein refers to any media that participates in providing instructions for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks. Volatile media includes dynamic memory. Transmission media includes coaxial cables, copper wire and fiber optics. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infrared data communications.

[0023] Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk. magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, papertape, any other physical medium with patterns of holes, a RAM, PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

[0024] BUI 210 provides all the client functions, including the RSVP setup functionality, which are available to an authorized user based on the level of the user profile. RSVP setup functionality is described in detail in commonly assigned application Ser. No. 990,096, which was previously incorporated by reference. Session setup server 215 accepts and executes requests from the host to add or remove sessions. The sessions supported include RSVP point-to-point or multi-point sessions. Session setup applet 220 specifically enables an authorized user to setup and tear down RSVP sessions. The level of functionality within the applet depends upon the user type and realm (i.e., a logical grouping of customer sites of which the user is part).

[0025] Event Server 230 is a daemon that collects events from other QoS servers, such as RSVP node server 225, and forwards those events to other servers or client functions. Event Server 230 handles user, router and multicast event types and gathers event messages from session setup server 215 and RSVP node server 225. Further, event server 230 transmits SNMP messages to RSVP node server 225. Event Logger 232 logs or stores the router event information used to monitor the state of the routers within system 100. RSVP node server 225 periodically polls routers, such as destination router 126 and premises router 114, to determine the state of requested sessions. The sessions supported are RSVP point-to-point or multi-point sessions. Lastly, database server 235 accepts all queries from the IP/QoS server modules and functions. This database stores all IP/QoS module 120 information about user administration, address administration, and RSVP session tables.

[0026] As shown in FIG. 2, BUI 210 acts as an interface between the user and the IP/QoS to functionality, including the event logging functionality. The user sends all requests for QoS functionality to BUI 210 and BUI 210 makes all responses to these requests available to the user. Running within BUI 210, session setup server 215 permits authorized users to log onto IP/QoS module 120 and to make reservation requests. Running within session setup server 215, session setup applet 220 downloads user interface software in an object-oriented computer language such as the JAVA™ programming language to the host, providing a graphic interface to BUI 210.

[0027] As also shown in FIG. 2, database module 240 provides an essential back end to IP/QoS module 120. Session, setup server 215 uses database module 240 to provide, via database server 235, user information such as user name, password, user level (e.g., desktop user, system analyst, network operation center), access level (none, some, all), domain name, and other relevant information. Database module 240 is first accessed when the user enters BUI 210 to verify the users name, password, user level, etc. and then again when the user submits a QoS request, to identify the domain, router names, session definitions, etc. Although database module 240 is not necessarily required to establish a QoS session, it is more preferable than establishing each session by hand.

[0028] FIG. 3 is a flow chart showing steps of a method for logging event information data that occurs during a communication session for use with the systems and methods consistent with the present invention. First, session setup server 215, residing on the ISP/QoS module 120, runs an expect script that generates Telnet messages (step 310). The Telnet messages are sent, at regular intervals, to the network routers to query the routers (e.g., premises router, 114), referred to as network nodes, to request node data of interest to the ISP. This node data could be, for example, the identity of a flow's source and destination or the reservation sizes and packets through “flows” that have been reserved in the router.

[0029] Next, the routers return the node data is returned to ISP/QoS module 120 (step 320), ISP/QoS module 120 then converts the node data to a special “MIB-like” object and stores it in database 240 (step 330). To accomplish this feature, RSVP node server 225 processes data received from the nodes as a result of running the expect script and organizes this data for temporary storage in the MIB-like object. The data in this object can then be accessed by SNMP messages generated by Event Server 230 (step 340).

[0030] The MIB-like object serves as a temporary storage location for the node data and the data is continually updated as it is stored in the object. Once this object is created, SNMP messages generated by Event Server 230 are transmitted to Node Server 225 for regularly queries to the object to determine if the state of the node data has changed (step 350). A change in state data could be indicated when a new source or destination is established or new RSVP request setup messages are received. If the state data has changed, the state information is time-stamped by Node Server 225 and then transmitted to Event Server 230 for processing (step 360). Finally, the state information can then be stored by Event Server 230 in Event Logger 235 (step 370). The logged data may then be accessed by the ISP for billing purposes or by the user to monitor the state of their sessions. If the state has not changed, the SNMP messages from Event Server 230 regularly query Node Server 225 until the data in the: MIB-like object is altered or changed in some manner (steps 340 and ÿ350).

[0031] It will be apparent to those skilled in the art that various modifications and variations can be made to disclosed embodiments of the present invention without departing from the scope or spirit of the invention. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments of the invention disclosed herein. The specification and examples should be considered exemplary, with the true scope and spirit of the invention being indicated by the following claims and their full range of equivalents.