SECURE NETWORK ARCHITECTURE WITH QUALITY OF SERVICE

Abstract

In a wide area network arrangement composed of some number of secure local networks and an Internet service provider (ISP) back-bone, LAN hosts are able to indirectly access network routers, through an ISP quality of service (QoS) module, to request that information transmitted during certain specified sessions be given priority treatment by the network.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. Nonprovisional application Ser. No. 08/990,096, entitled “SECURE NETWORK ARCHITECTURE WITH QUALITY OF SERVICE,” filed on Dec. 12, 1997, which is specifically incorporated by reference herein for all that it discloses and teaches.

BACKGROUND OF THE INVENTION

The present invention relates generally to network communication, and more particularly to establishing dedicated and secure communication sessions over a wide area network.

Certain types of business activities create the need to transfer information in a timely and secure manner. For instance, banks periodically “backup” their computer files to a remote central database and need to know that these files were successfully copied to the remote database without having been attacked or corrupted during the process. Video conferencing is another example of an application that demands the timely and secure transmission of information (video/voice/data). Network transmission delay or the successful attack by a hacker can cause significant business problems or render applications useless.

One solution to the problem of network delay is to lease dedicated point-to-point digital data lines, such as an ISDN or T1 line, over which time critical information is sent. In addition to carrying the critical traffic, however, these lines carry traffic that is not time critical between the two end points as well. Because neither of the two traffic types is given precedence under these circumstances, time critical traffic may be delayed.

A typical solution to the precedence problem is to introduce a “priority queuing” mechanism into the network. Such queuing mechanisms give precedence to certain time critical traffic while handling the rest of the traffic on a “best effort” basis. However, both dedicated leased lines and priority queuing require a significant configuration effort, usually by the system manager. Typically, the system manager is not on site or may not even be an employee of the company using the service. As a result, the user may have no ready means to modify the configuration, which dictates that the service being provided is static in nature and not adaptable to applications where the timing of critical traffic cannot be regularly scheduled.

Another solution to the problem of network delay typically utilized by network managers is to incorporate an asynchronous transfer mode (ATM) backbone between the various local networks to handle the transfer of information. ATM was designed to provide a wide range of quality of service (QoS) capabilities. An ATM network can support some number of virtual channels (VCs) over which traffic with certain defined QoS characteristics can travel. These QoS characteristics can be used to group traffic according to precedence, and VCs can be established to transmit the different traffic types.

Using ATM interfaces to carry QoS Internet traffic, however, requires the router to map Internet protocol (IP) data flows into the VCs based on QoS characteristics. In addition, the current practice is to default to a single Permanent Virtual Channel (PVC) between routers, which does not allow for multiple service classes within the ATM net work. Although multiple PVCs are sometimes configured, there is no standard way of mapping QoS characteristics to PVCs. Also, there are no multicast PVCs, so Internet multicast traffic cannot be delivered over an equivalent PVC. Consequently, it must be duplicated and sent over separate PVCs to each multicast designation, which uses up a lot more bandwidth.

Inherently, the Internet protocol only provides for the “best effort” transmission of information. This means that all traffic is of equal precedence meaning that if there is more traffic to be transmitted than the network can handle, this traffic must be buffered in a FIFO arrangement for some period of time until it gets to the top of the buffer at which time it would be transmitted. Clearly, “best effort” transmission is not suitable for time critical traffic.

To overcome the problems of “best effort” transmission, the RSVP protocol was developed to allow an application to request QoS on the Internet and avoid delaying time critical traffic. Applications designed to employ this protocol are able to dynamically request specific QoS from a network, thereby ensuring that time critical traffic is transmitted over dedicated network resources. Specifically, the RSVP protocol reserves network bandwidth for certain traffic. Despite these benefits, the RSVP protocol is relatively new, and as a result, most applications have not been redesigned to process RSVP messages.

Security is another critical characteristic that certain types of customers demand before conducting their business over the Internet. Typically, Internet security is provided by a firewall placed between a local area network (LAN) router, or premises router, and the host computers attached to the LAN. Firewall products, such as Gauntlet, are offered commercially by TIS Co.

Because QoS-enhanced applications do not typically include security provisions, firewall type products are needed to provide application security. However, since such firewall products have not been designed to process RSVP messages, Internet security and QoS are mutually exclusive characteristics of Internet communication at the present time, even though both are desirable.

SUMMARY OF THE INVENTION

Systems and methods consistent with the present invention provide a QoS server that operates such that commercially available firewall products can be utilized by local networks to maintain security. In addition, existing commercially available IP routers can be utilized to fulfill QoS requests from secure local networks.

A server system, consistent with the present invention, includes means for receiving a session request for establishing a communication path for transmitting 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.

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

DESCRIPTION OF THE DRAWINGS

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,

FIG. 1 is a block diagram of a secure network architecture consistent with the present invention.

FIG. 2 is a block diagram of the IP/QoS module of FIG. 1.

FIGS. 3A and 3B are flowcharts showing steps, consistent with the present invention, for establishing a QoS session.

FIG. 4 is a screenshot of a session request interface consistent with the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

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.

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 LANs 110, 130, and 140. WAN 150 is composed of 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 could be, 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 serve to receive packets of information from the LANs, determine whether or not the packet has been designated for QoS service, and if so, operate to transmit the packet to some destination router in a manner which provides the proper QoS.

As shown in FIG. 1, IP/QoS module 120 and associated firewall module 124 are located at a QoS hosting site of ISP 150. Firewall module 124 servers to monitor traffic to the site to ensure that all traffic comes from registered and authorized users. As mentioned previously, firewall modules are commercially available and could be composed of, 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 operating system. Firewall 124 associated with IP/QoS module 120 is connected to router 118 by a communication line, such as a T1, and IP/QoS module 120 is connected to firewall 124 via a local communication line, such as an Ethernet connection.

IP/QoS module 120 serves to provide a session reservation setup application to the user upon request, to accept requests for QoS service from users, to transmit these user QoS requests to the WAN routers, to monitor the routers to determine if the QoS request has been established or not, and then notify the user of the state of the QoS request.

As also shown in FIG. 1, premises routers 114, 126, and 134 are connected to the WAN routers 116, 118, and 122, respectively, via communication lines, such as a T1 line. The premises routers serve as the “originating/destination” routers in the network. Firewall 112 is attached to premises router 114, by a local communication line, such as a T1 line, and serves to monitor traffic into LAN 110, which is connected to firewall 112 via a local communication line, such as an Ethernet connection. LAN 110 supports some number of users, which are illustrated 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.

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 all with interconnection communications lines are the same as described above with reference to FIG. 1. IP/QoS server module 120 includes a browser user interface (BUI) 210, a session set-up server 215 with a setup applet 220, an event server 230, an RSVP node server 225, and an mSQL Database Server 240 with a corresponding database 235.

In general, IP/QoS server module 120 executes software instructions read into a main memory from another computer-readable medium. Execution of the sequences of instructions contained in main memory 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.

The term “computer-readable medium” as used herein refer 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 intra-red data communications.

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, punchcards, 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.

BUI 210 provides all the client functions, including the RSVP setup functionality, which are available to an authorized user based on the level of that user profile. 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, included in session setup server 215, 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.

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. RSVP node server 225 periodically polls routers such as router 126 and 114 to determine the state of requested sessions. The sessions supported are RSVP point-to-point or multi-point sessions. Lastly, mSQL Database Server 240 accepts all queries from the IP/QoS server modules and functions. This database is used to store all IP/QoS module information about user administration, address administration, and RSVP session tables.

As shown in FIG. 2, BUI 210 acts as an interface between the user and the IP/QoS functionality. All requests for QoS service from the user are sent to BUI 210 and all responses to these requests are then available to the user at BUI 210. 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 JAVA user interface software to the host, providing a graphic interface to BUI 210.

As also shown in FIG. 2, database module 235 provides an essential back end to IP/QoS module 120. Session setup server 215 depends upon database module 235 to provide 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 235 is first accessed when the user enters BUI 210 to verify the user's 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 235 is not necessarily required to establish a QoS session, it is more preferable than establishing each session by hand.

FIGS. 3A and 3B show steps, consistent with the present invention, for establishing a QoS session. First, IP/QoS module 120 responds to a user logon by downloading a JAVA applet to the user's host (step 305). This applet includes a page called the “Definition Wizard” that permits the user to define the parameters of a session. FIG. 4 shows a screenshot of an exemplary interface window for defining the parameters of the session, including sender information 410, receiver information 420, reservation information 430, miscellaneous information 440, and a session status 450.

Sender information 410 identifies the host IP address and port for the source of priority data. Receiver information 420 identifies the IP address and ports of recipients of the priority data. Reservation information 430 identifies the characteristics of the priority data, including bandwidth, RSVP service type and protocol type, for example. Miscellaneous information 440 identifies users who can access the session by login name, and sets the maximum duration of the session. Miscellaneous information 440 also allows sessions to be saved in the database, or reset. Finally, session status information 450 presents dynamic status on the state of the requested session.

Based on information entered in the Definition Wizard by the user, the host can send a QoS session request to IP/QoS module 120 (step 310). The session request is sent as a standard IP message, not as an RSVP message. Generally, the format of the packet for the session request is different from the host to the firewall and from the firewall to IP/QoS module 120. For example, the firewall may encrypt the session request packet before forwarding it to IP/QoS module 120.

After receiving the QoS session request, IP/QoS module 120 determines if the request was received from an authorized user (step 315). For example, IP/QoS module 120 may search database module 235 to determine whether the user requesting the service is authorized. In addition, IP/QoS module 120 determines if the resources necessary to fulfill the request are available. To determine the availability of the necessary resources, session setup server 215 runs an “expect” script to connect to the originating routers console. The originating router is often the premises router, such as premises router 114 shown in FIG. 2. In the event the bi-directional service is requested, session setup server 215 could contact both the originating/premises router and the destination router. The expect script causes a message to be sent from session setup server 215 to the originating router (step 320). This message, which includes information about the QoS reservation called for by the host, appears to the originating router to be a Telnet message not an RSVP message. The information in the message includes a request for the originating router to reserve the router resources necessary to transmit traffic from the host in accordance with the QoS session request.

After receiving the message from session setup server 215, the originating router checks to see if it can provide the requested resources for the QoS session request (step 325). For example, the originating router checks if it has sufficient bandwidth available to provide the requested service. In addition, the originating router transmits messages to the next router along the transmission path to see if it has the resources to provide the requested QoS service (step 330). Each of the other routers along the transmission path determines whether it has the available resources for the QoS service and returns a message to the originating router if the router has insufficient resources (step 335).

At the same time these messages are received by the routers of the transmission path, RSVP node server 225 monitors the routers to determine the RSVP state of the routers along the transmission path, i.e., to see if the QoS service is available and was enabled (step 340). This state information is then passed to event server 230 (step 345), which in turn passes state information to session setup server 215 (step 350). If all the resources necessary for establishing the QoS session are available, the user will be notified that their QoS session request has been granted and that they can begin their session (step 355). If granted, the session proceeds, and the routers handle all traffic associated with that session according to the QoS parameters included in the QoS session request (step 360).

A network communication system, consistent with the present invention, provides for QoS sessions while maintaining network security using commercially available firewall products. In addition, QoS requests from secure local networks can be fulfilled using existing commercially available IP routers.

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.

Claims

1. A method comprising:

receiving parameters defining a quality of service (QoS) session from a user via an applet provided at a host machine of the user; and

setting up the QoS session on a transmission path between an originating router and a destination router according to the parameters of the QoS session provided by the user;

wherein a QoS module performs the setting up of the QoS session and is located at a QoS hosting site that is communicably coupled to the originating and destination routers.

2. The method of claim 1, wherein the applet includes inputs for at least one of sender information, receiver information, reservation information, miscellaneous information, and session status.

3. The method of claim 1, wherein the parameter definitions are sent to the QoS module from the user as a standard Internet Protocol (IP) message.

4. The method of claim 1, wherein the QoS session establishes a pre-determined service level between the originating router and the destination router by setting the parameters for the routers to maintain during the QoS session.

5. The method of claim 2, wherein the sender information identifies a host Internet Protocol (IP) address and a port for a source of priority data sent via the QoS session.

6. The method of claim 2, wherein the receiver information identifies the Internet Protocol (IP) address and ports of recipients of priority data sent via the QoS session sent via the QoS session.

7. The method of claim 2, wherein the reservation information identifies the characteristics of priority data, and includes at least one of bandwidth, RSVP service type, and protocol type.

8. A quality of service (QoS) module to set up a QoS session between an originating router and a destination router, comprising:

a browser user interface module to provide a session set-up applet to a user at a host machine, the applet including QoS session parameters to be defined by the user; and

a session setup server communicably coupled to the browser user interface module to: receive the defined QoS session parameters via the applet from the user; and set up the QoS session on a transmission path between the originating router and the destination router according to the defined QoS session parameters;

wherein the QoS module is located at a QoS hosting site that is communicably coupled to the originating and destination routers.

9. The method of claim 1, wherein the applet includes inputs for at least one of sender information, receiver information, reservation information, miscellaneous information, and session status.

10. The QoS module of claim 8, wherein the defined QoS parameter definitions are sent to the session setup server from the user as a standard Internet Protocol (IP) message.

11. The QoS module of claim 8, wherein the QoS session establishes a pre-determined service level between the originating router and the destination router by setting the parameters for the routers to maintain during the QoS session.

12. The QoS module of claim 9, wherein the miscellaneous information identifies users that can access the QoS module by login name, sets a maximum duration of the QoS session, allows the QoS session to be saved in a database, and allows the QoS session to be reset.

13. The QoS module of claim 9, wherein the session status information presents dynamic status on a state of a requested QoS session.

14. An article of manufacture, comprising a computer-readable medium including data that, when accessed by a computer, cause the computer to perform operations comprising:

receiving parameters defining a quality of service (QoS) session from a user via an applet provided to the user at a host machine; and

setting up the QoS session on a transmission path between an originating router and a destination router according to the parameters of the QoS session provided by the user;

wherein a QoS module performs the setting up of the QoS session and is located at a QoS hosting site that is communicably coupled to the originating and destination routers.

15. The article of manufacture of claim 14, wherein the applet includes inputs for at least one of sender information, receiver information, reservation information, miscellaneous information, and session status.

16. The article of manufacture of claim 14, wherein the parameter definitions are sent to the QoS module from the user as a standard Internet Protocol (IP) message.

17. The article of manufacture of claim 14, wherein the QoS session establishes a pre-determined service level between the originating router and the destination router by setting the parameters for the routers to maintain during the QoS session.

18. The article of manufacture of claim 15, wherein the sender information identifies a host Internet Protocol (IP) address and port for a source of priority data sent via the QoS session.

19. The article of manufacture of claim 15, wherein the receiver information identifies the Internet Protocol (IP) address and ports of recipients of priority data sent via the QoS session.

20. The article of manufacture of claim 15, wherein the reservation information identifies the characteristics of priority data sent via the QoS session, including at least one of bandwidth, RSVP service type, and protocol type.