Enabling a service provider to provide intranet services

A method and system allows a service provider to provide Intranet services remotely by assigning private virtual servers to customers. Each customer addresses transmissions to one or more private virtual servers using private addresses from the customer's private Intranet. The addresses of different private virtual servers do not have to be unique and may overlap. Customers exchange privately-addressed transmissions with the service provider using tunnels to traverse the local or regional network connecting the customer with the service provider. The service provider routes the transmissions to the relevant private virtual server belonging to the customer that sent the transmission. The service provider also routes privately-addressed transmissions back to individual customers using tunnels.

BACKGROUND

1. Field of Invention

the present invention relates generally to providing private networking services, e.g., Intranet services, remotely, and more particularly, to allowing a service provider to locate and manage private network servers at the service provider's location, while connecting the servers to a customer's premises such that they appear to be local and private to the customer.

2. Background of the Invention

Networked computer resources are growing more popular as the benefits of sharing computing resources becomes evident. One of the fastest-growing segments of the Internet is the private network market. A private network is an interconnected group of computing resources accessible only by the network members. Security protocols are used to ensure that only authorized users have access to the network's resources, even where the network operates on the public network infrastructure and protocols. A private network, often belonging to a corporation, may be used to store web pages and other shared information. This information is maintained in a private space, generally screened off from external sources such as the Internet by a firewall which blocks unauthorized access. Such private networks are often referred to as intranets, local area networks (LAN) or wide area networks (WAN).

In a typical LAN implementation, a single location contains a group of individual user computers, as well as one or more dedicated host computers executing server programs to maintain the network's shared information. The private LAN is screened off from the Internet by a firewall, though users may access the Internet if needed. Network traffic intended for the network is allowed through the firewall only if authorized. The resources within the LAN all may communicate using private addresses. It is not necessary to use registered IP addresses for each resource because the system is screened off from the global Internet.

This model may be extended to multiple location sites. Computer networks that span relatively large geographical distances are typically referred to as WANs. In a private WAN, individual sites must be connected in a secure manner. A secure connection between WAN sites may be accomplished using a virtual private network. A virtual private network utilizes ordinary Internet protocols and may also use public communications mediums to connect; however, privacy is ensured through features such as tunneling (data encapsulation) or the use of leased lines. A leased line is a permanent connection between two points that is always active. Resources on a WAN may communicate using only private addresses because the network is screened off from the global Internet.

Private networks contain common elements. Each generally contains a dedicated local server to maintain the shared private network data, and a communications system for providing data communication services between machines on the private network. Communication takes place using a private address space. Because the address spaces for individual private networks need only be locally unique, the address spaces among several different private networks may overlap because the networks are isolated from each other. More specifically, in private intranets, two unrelated intranets at different companies may use the same local addresses for user computers. No conflict arises since the networks are not connected.

Data communications services and servers are not easy to configure, manage, and maintain. Thus, there is an incentive for the service providers that offer access to communications facilities to provide such private network services and servers as well, thereby relieving corporations from the burden of providing these services directly. Some examples of service providers are: Internet Service Providers (ISP), Application Service Providers, Network Service Providers, and Competitive Local Exchange Carriers (CLEC).

It is not economically feasible for a service provider to remotely manage servers located on a customer's premises, and support many different customers in this fashion. Rather a service provider would prefer to offer private network services to multiple customers while keeping all of the server host computers within a location of the service provider for ease of management. Accordingly, service providers typically dedicate a physical host computer as each individual customer's server, and maintain each host computer in the centralized facility. However, this means the service provider will have to own and maintain potentially large numbers of physical host computers, at least one for each customer's server or private network However, many customers will neither require nor be amenable to paying for the use of an entire host computer. Generally, only a fraction of the processing power, storage, and other resources of a host computer will be required to meet the needs of an individual customer.

Alternatively, a service provider may utilize one physical host computer to provide commercial host services to multiple customers. Using Transmission Control Protocol (TCP) and other transport protocols, a server application executing on a single physical host can be programmed to process requests made to multiple network addresses. Such functionality is known as virtual hosting.

In virtual hosting, each customer is assigned a network address (or domain name), and is provided with resources on a single, physical host computer, effectively sharing the host with other customers. A client computer requests data from a specific customer's host by targeting communication requests to the appropriate network address (or domain name). The virtual host server can service requests to multiple network addresses or domain names. Thus, the functionality of numerous hosts is provided by a single physical host computer, servicing requests made to a plurality of network addresses and domain names by multiple customers.

However, virtual hosting it is commonly performed today does not provide many of beneficial features of private networks. Service providers will have to be able to provide certain features of private networks before customers will be willing to outsource services related to the operation and maintenance of their private network. First, customers will want to ensure that their private data is inaccessible to other customers sharing the same host computers. For instance, if a service provider provides email outsourcing for both Company A and Company B on the same computer, Company A will want to ensure that the directories in which its email is stored are not accessible to Company B, and vice versa.

Additionally, customers will want to ensure that their services are not compromised due to problems originating with another customer. If a service provider uses a single host computer to provide server resources for both Company A and Company B, steps must be taken to ensure that overuse of the resources by Company A does not impact Company B's service. Additionally, faults, crashes, or similar problems caused by one customer must not compromise the service provided to another customer. Such performance degradation issues must be contained by the service provider to impact only the customer responsible for the problem, and not to impact any other customers.

Finally, companies A and B will want their servers to have IP addresses that belong to their own private address spaces. Using addresses from each company's own private address space offers more security because private IP addresses are not reachable over the public Internet. The use of private IP addresses guards against private servers becoming accessible from the public Internet by accidental misconfiguration of equipment. Also, public IP addresses are a limited resource; there is insufficient address space for private networks to consume addresses from the public address space. Furthermore, if a company connects a number of servers or corporate locations together they will wish to establish a virtual private network. To run the routing protocols required for communications within a virtual private network requires a coherent addressing scheme. Such a virtual private network is easier to manage from a private address space.

However, the use of private address schemes creates difficulties for the service provider. The service provider may now have several virtual servers assigned to the same IP address, because companies A and B may have overlapping address spaces, as is typical in private networks. This address overlap can cause the communication network to fail. Typically, one of the virtual servers would become unreachable due to this address overlap error.

Thus in order to satisfy customers' needs, a service provider desiring to provide private network services must be able to guarantee four different kinds of isolation. Functional isolation separates the data and functionality of each customer. Fault isolation protects one customer from the faults created by another customer. Performance isolation allows each customer to receive a performance commitment independent of the behavior of other customers. Address isolation allows each customer to choose the virtual server IP address that it wants to be associated with, independent of other customers.

Virtual hosting currently cannot provide these beneficial features of ordinary private servers. This is due to the inability of a virtual host to allocate appropriate amounts of computer resources of the physical host computer to servicing client requests made to specific virtual hosts, and hence to specific customers. A private virtual server, by contrast, is able to provide the functional, fault, and performance isolation that an ordinary virtual server cannot. A method for creating such a private virtual server is disclosed in the related application identified above, U.S. patent Ser. No. 09/452,286, entitled “Providing Quality of Service Guarantees to Virtual Hosts.”

However, a method and system is still needed to allow customers to use their own private address spaces to communicate with a remotely-located private virtual server maintained by a service provider, where the private virtual server addresses may overlap.

SUMMARY OF THE INVENTION

The present invention allows providers of virtual servers to properly differentiate and route transmissions using private addresses on a common host server. The term “private virtual server” as used herein is a virtual server that supports a private address space wherein the private address spaces of different private virtual servers may overlap.

Customers exchange privately-addressed transmissions with a service provider using tunnels to traverse the local or regional network connecting the customer with the service provider. The service provider receives the transmissions at a gateway into the service provider's data center. The service provider then routes the transmission to the private virtual server belonging to the customer that sent the transmission. The service provider also routes privately-addressed transmissions back to individual customers using tunnels. In this way, the service provider is able to implement a separate routing context on behalf of each individual customer.

The present invention allows for flexibility in designing a private virtual server that suits an individual customer's needs. For example, an individual customer may have multiple physical sites all utilizing the same private virtual server. Optionally, an individual customer may be assigned more than one private virtual server, for instance, if different divisions of an organization each wish to maintain their own private servers while making all the data available to the organization at large.

In one embodiment, the present invention comprises a multiplexing/demultiplexing mechanism capable of routing signals to and from one or more private virtual servers located on a physical host computer. Each private virtual server is associated with only one private network. The multiplexing/demultiplexing mechanism receives a privately addressed transmission and routes it to the private virtual server with which it is associated. The privately addressed transmission may then be processed within the private virtual server in the same manner as if the server was actually a physical server resident within a LAN. The multiplexing/demultiplexing mechanism also receives an outgoing transmission from a private virtual server and routes it back to the private network associated with it. Incoming and outgoing transmissions are addressed using a tunneling scheme. Tunneling allows privately-addressed transmissions to be transported over a network that uses global addresses and allows customers to address their private virtual server using a non-unique private address. As a result, all transmissions to and from a customer are sent only to the customer's respective private virtual server.

In another embodiment, the present invention includes more than one physical host computer. Each physical host computer contains one or more private virtual servers. Privately-addressed incoming transmissions are sent to the service provider's data center. The transmissions are placed on tunnels to traverse the local or regional network connecting the customer with the service provider. A tunnel switching mechanism is used to forward transmissions received at the service provider's data center to the proper physical host computer.

In another embodiment, the present invention is a method for locating and managing private network services in a data center location remote from private network users. The method comprises receiving a transmission addressed using a private address of a recipient, and routing the transmission to a private virtual server. The correct private virtual server is determined from the address of either the sender or the recipient of the transmission.

The foregoing merely summarizes aspects of the invention. The present invention is more completely described with respect to the following drawings and detailed description.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference will now be made in detail to several embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever practicable, the same reference numbers will be used throughout the drawings to refer to the same or like parts. The figures depict preferred embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

FIG. 1is an illustration of an embodiment of a private virtual server system, which replaces multiple private Intranet servers. A private virtual server system100includes a service provider gateway152that connects to a service provider data center150. System100is connected to multiple customer sites110via an access network120. Customers, e.g.112and114, are located in potentially any global location, although frequently customers are located within the regional access network of the service provider. As will be evident to one of skill in the art, any number of customers may be supported by the private virtual server system100. Only the resources of the physical servers owned by the service provider limit the number of customers supported. Furthermore, a service provider may add additional physical servers as required to support additional customers.

As used herein, the terms “customer”, “user”, and “private network user” refer to individuals or groups of individuals accessing the same private virtual server. Typically, a private virtual server “user” is a group of individuals with a shared association. For example, “user” may collectively refer to the employees of a company, or to certain employees within a division of a company. One company (a “customer”) may have several different users, each corresponding to a different group within the company. Additionally, a “user” may also refer to a single individual.

In the present invention, customers send and receive data using a network. In one embodiment, the protocol used within each customer's network will be IP (Internet Protocol). The IP addressing format will also be assumed herein for purposes of illustration. However, it will be evident to one of skill in the art that a different network protocol could be used instead of IP within a customer's private network, for example, Open Systems Interconnection (OSI), Internetwork Packet Exchange (IPX), System Network Architecture (SNA), and Asynchronous Transfer Mode (ATM).

Data from customers112and114may optionally be aggregated130before being sent out over a local or regional network140. Aggregation130is not required, but generally is done to concentrate data traffic for more efficient transmission over a network. For example, a customer site may aggregate the multiple data streams coming from various different users (clients) within the site before transmitting data onto a public network.

Aggregation130may also take place between customers and non-customers. This may occur when data transmission sites are located physically close together, to consolidate traffic flow onto the local or regional network140. In another example, aggregation is also common in digital subscriber line (DSL) systems. A digital subscriber line access multiplexer (DSLAM) concentrates data traffic from multiple DSL loops onto the backbone network before connection to the rest of the local or regional network140. Data directed to different destinations will be separated and individually routed within the local or regional network140.

The local or regional network140connects a customer with a private virtual server system100. The local or regional network140may be comprised of different types of interconnected networks. System100is capable of functioning with a wide variety of different local or regional networks140, as will be evident to one of skill in the art.

Traffic from each individual customer112and114is aggregated130and transported across the local or regional network140until it reaches a service provider gateway152. The service provider gateway152provides the connection into the service provider data center150. The service provider gateway152direct traffic from each customer to the private virtual servers it owns and prevents traffic from reaching private virtual servers a customer does not own.

The service provider gateway152connects to a physical server machine160. The physical server machine160may be any kind of computer adapted to support private virtual servers. It is to be understood that a service provider data center150will typically contain more than one physical server machine160.

Located on the physical server machine160is a group of private virtual servers162. In one embodiment, each private virtual server162is capable of implementing quality of service guarantees to individual customers. A service provider may implement different quality of service guarantees by allocating different percentages of the physical server machine160to servicing each of the private virtual servers162. Thus the private virtual servers162may each consume a different percentage of the resources of physical server machine160. This resource allocation may be dynamically changed by the service provider as required.

In one embodiment, the IP network address of each private virtual server162corresponds to a private address from the private address space of the respective customer assigned to the private virtual server. A private address is any locally-assigned address, which does not have to be unique within the global Internet. Conversely, a global address is a registered IP address that is unique within the public network system of communications. Generally, connecting a private network to a public network requires network address translation, which maps global addresses onto private addresses at the public/private network boundary. Private addresses are not routable in the public network, therefore transmissions cannot be sent to the private virtual servers162across the public network120using only their private addresses.

The network addresses for the private virtual servers are chosen to correspond to each customer's private address space. The private address spaces of customers112and114may overlap. Therefore, the network addresses for these customers' assigned virtual private servers may not be unique. It is possible for private virtual servers162to all be assigned the same network address.

Thus the use of private addresses for the private virtual servers creates two different problems: such private addresses cannot be used to transmit data directly across a public network, and there may be address overlap among the private virtual servers.

A solution to the problem of transporting privately-addressed transmissions is shown in FIG.2.FIG. 2is an illustration of an embodiment of a private virtual server system200that uses individual tunnels to connect between each customer and a service provider. The tunnels provide a means to transmit privately-addressed data across a public network.

FIG. 2shows a private virtual server system200. The private virtual server system200includes a service provider gateway252that connects to a service provider data center250. A physical server machine260contains three private virtual servers262. These private virtual servers may have overlapping private IP addresses. Private virtual server262A is assigned to a customer220, while private virtual server262B is assigned to a customer210. Customers210and220are connected to the private virtual server system200via a local or regional network240.

Customers210and220use tunnels to allow privately-addressed data transmissions to traverse the local or regional network240. Customer210has a single tunnel212from customer210's site to the service provider gateway252. Similarly, customer220has a single tunnel222from customer220's site to the service provider gateway252. A tunnel is created by encapsulating a data transmission within a second type of addressing protocol. Transmissions, which use addresses that are unique only within a narrow scope, may thus be transported across a second network within a wider address scope. In this way, private IP addresses that are only unique within a private IP network are encapsulated for transport across the global public Internet. The origination of the tunnel, on the customer's side, must occur before traffic from multiple customers is aggregated. The numbers of customers and private virtual servers shown inFIG. 2is merely representative. It is to be understood that a service provider may have more or fewer customers. Furthermore, a physical host machine may contain more or fewer private virtual servers.

System200demonstrates how a customer can be communicatively coupled to a private virtual server system using privately-addressed transmissions. However, once privately-addressed transmissions are routed across a public network, the problem of potential address overlap among the destination private virtual servers still remains.FIG. 3demonstrates a method for routing transmissions to private virtual servers, where the private virtual servers may have overlapping address spaces.

FIG. 3is an illustration of an embodiment of a private virtual server system300including a multiplexing/demultiplexing mechanism350. Private virtual server system300provides a separate routing context on behalf of each user to route privately-addressed transmissions between the users and the private virtual servers. System300is connected to three customer sites310,320and330. Each customer uses a tunnel to traverse the local or regional network340and arrive at a physical server machine360within the private virtual server system300. Customer site310uses a tunnel312, customer site320uses a tunnel322, and customer site330uses a tunnel332. Each tunnel is a different data encapsulation. Multiple tunnels may be carried on the same physical medium connecting to the multiplexing/demultiplexing mechanism350.

In another embodiment, the tunnels312,322, and332could be replaced with dedicated leased lines. A leased line is a permanent connection between two points set up by a telecommunications common carrier. A leased line is not part of the global public network, and therefore may carry privately-addressed traffic.

The physical server machine360contains three private virtual servers362, as well as a multiplexing/demultiplexing mechanism350. Incoming tunnels312,322, and332communicatively couple to the multiplexing/demultiplexing mechanism350. The private virtual servers362may have overlapping IP addresses. A set of internal pointers314is used to direct traffic from the multiplexing/demultiplexing mechanism350to the correct private virtual server362, thereby communicatively coupling the multiplexing/demultiplexing mechanism350to the private virtual servers362.

The multiplexing/demultiplexing mechanism350performs the functions of separating incoming communication streams back into their original constituent streams, and merging multiple separate communication streams onto a single physical communications medium. In one embodiment, the multiplexing/demultiplexing mechanism350is implemented in the network interface card of the physical server machine360. The multiplexing/demultiplexing mechanism350may be implemented in an application specific integrated circuit (ASIC) on the network interface card, or on the software driver.

Incoming tunneled transmissions are sent on a physical medium as packet flows. When the multiplexing/demultiplexing mechanism350demultiplexes an incoming set of packet flows, incoming packets are stored in a buffer and one of the fields in the packet header is used to select the incoming packet queue to which the buffer should be linked. An incoming packet queue is a list of pointers wherein each pointer points to a packet buffer. Thus packets arriving with different tunnel identifiers are linked to different incoming packet queues. There is one incoming packet queue per tunnel.

Outgoing transmissions sent by the various private virtual servers are also packet flows. Each private virtual server has its own outgoing packet queue. These packet queues are again implemented as lists of pointers to packet buffers. The scheduler in the network interface card selects which of the non-empty outgoing packet queues it should serve next. The scheduler takes the pointer from the head of the selected queue and transmits the packet from the buffer that is pointed to by the pointer.

The tunnel switching operations of the mutiplexing/demultiplexing mechanism350are shown in more detail inFIGS. 4 and 5.FIG. 4is a block diagram illustrating the tunnel-to-private virtual server traffic switching functions of a multiplexing/demultiplexing mechanism.FIG. 5is a block diagram illustrating the private virtual server-to-tunnel traffic switching functions of a multiplexing/demultiplexing mechanism.

FIG. 4shows an embodiment of a physical host computer400including three private virtual servers420A,420B, and420C. Each private virtual server includes an associated IP stack422. An IP stack is a set of software processes that together manage the transfer of information in packets according to Internet protocols. Internet protocols define the rules and conventions for exchanging information across the Internet. The number of private virtual servers shown is merely illustrative. It is to be understood that a physical host computer may include more or fewer private virtual servers.

The physical host computer400also includes a multiplexing/demultiplexing mechanism410. Multiplexing/demultiplexing mechanism410has an internal pointer430directed at each IP stack422. Multiplexing/demultiplexing mechanism410includes a lookup table412that includes a list of incoming tunnel identifiers and pointers to their associated IP stacks within the physical host computer400. Lookup table412is created by software residing on the physical host computer400, which associates each IP stack with a particular customer, and ensures that transmissions sent from a particular customer are only directed to that particular customer's private virtual server.

A data packet452enters the multiplexing/demultiplexing mechanism410using an incoming tunnel450. The tunnel450is not an individual physical connection, but is a means of encapsulating the packet452to permit routing across a public network. Although only one incoming tunnel450is shown inFIG. 4, this is merely illustrative. It is to be understood that there may be multiple different tunnels entering the multiplexing/demultiplexing mechanism410.

The tunnel identifying information of the incoming packet452identifies which customer sent the packet452. Packet452's incoming tunnel identifying information is stripped446, and the tunnel identifying information is presented444to the lookup table412. Lookup table412returns442an internal pointer430for the appropriate IP stack422. Packet452is then routed440to the identified IP stack422using the internal pointer430.

An alternative embodiment is to embed the internal pointer430in the control data structure that controls the operation of the tunnel. The control data structure is typically located on the network interface card. The network interface card is typically located on the physical server machine400.

FIG. 5is a block diagram illustrating an embodiment of the private virtual server-to-tunnel traffic switching operations for the physical host computer400. Multiplexing/demultiplexing mechanism410contains a lookup table512that consists of a list of IP stacks in the physical host computer400and their associated outgoing tunnel identifiers. Multiplexing/demultiplexing mechanism410ensures that packets sent from a customer's private virtual server are routed back to that customer on the correct outgoing tunnel.

A packet552is originally sent from the IP stack422of one of the private virtual servers420. The packet552is directed530to the multiplexing/demultiplexing mechanism410. Upon arrival at the multiplexing/demultiplexing mechanism410, the internal tunnel IP stack identifier is read540, and this identifier is presented542to lookup table512.

Lookup table512returns544the associated outgoing tunnel identifying information. The outgoing tunnel identifier is added546to packet552. Packet552is then sent out using the appropriate outgoing tunnel550. The outgoing tunnel550is associated with the customer assigned to the private virtual server420, which originally sent the packet552. Although only one outgoing tunnel is shown inFIG. 5, this is merely illustrative. It should be understood that there may be multiple different outgoing tunnels. Each tunnel is not a separate physical connection; it is a specific encapsulation of data allowing the data to be separated out from other data sent on a physical connection.

An alternative embodiment is for the IP stack422of each private virtual server420to encapsulate the packet552with the proper outgoing tunnel header and tunnel identifier, thereby creating the tunnel550. In this embodiment, the lookup table512is not used. The multiplexer/demultiplexer mechanism410merges the encapsulated and identified packet streams together, and sends them out.

A service provider will typically own and manage multiple physical server machines. Additionally, customers may wish to purchase more than one private virtual server, for example, for separate divisions within the same company. A customer may also have multiple physical customer sites using the same private virtual server, wherein each customer site uses a different tunnel to communicate with the service provider. A tunnel switch supports these different configurations in a private virtual server system.

A tunnel switch comprises one or more physical interfaces, with each interface capable of carrying many multiplexed tunnels. A tunnel switch will typically be capable of supporting a number of different physical interface technologies and a number of different types of tunnels for each type of physical interface. A tunnel switch performs two separate services: switching tunnels, and switching packets within a tunnel.

In a switching tunnels service, all packets arriving on one incoming tunnel are forwarded to an outgoing tunnel. This may be implemented without looking into the headers of the packets themselves. The tunnel switch notes which tunnel and physical interface the packet arrived on. Given the identifier of the incoming tunnel and the incoming physical interface, the tunnel switch uses a lookup table to specify the outgoing tunnel and physical interface.

In a switching packets service, incoming tunnels are terminated at the tunnel switch. The packets within each tunnel are extracted and switched individually based upon the incoming physical interface, the incoming tunnel, and information from the header of the packet. A private virtual server system supporting multiple physical servers, multiple private virtual servers per customer, and multiple customer sites per private virtual server will support such a switching packets service in addition to supporting a switching tunnels service.

FIG. 6is an illustration of an embodiment of a private virtual server system containing a tunnel switch. Private virtual server system600provides a separate routing context on behalf of each customer to route between the customer and each customer's associated private virtual server. A private virtual server system600is communicatively coupled to three customer sites612,614, and616across a local or regional network620. The number of customers, physical servers, and private virtual servers shown inFIG. 6is merely representative. It is to be understood that a service provider may have more or fewer customers and more or fewer physical servers. Furthermore, a physical server may contain more or fewer private virtual servers.

Each customer site is connected to the system600via an external tunnel that traverses the local or regional network620and communicatively couples to a tunnel switch632. Customer site612uses external tunnel622, customer site614uses external tunnel624, and customer site616uses external tunnel626. A tunnel switch632operates as the gateway to physical servers640and650, and supports tunnels on multiple physical interfaces. Tunnel switch632is communicatively coupled to physical server640via a set of tunnels634. Tunnel switch632is communicatively coupled to physical server650via a set of tunnels636. Physical server640contains a multiplexing/demultiplexing mechanism642, which is linked via a set of internal pointers662to a set of private virtual servers660. Physical server650contains a multiplexing/demultiplexing mechanism652, which is linked via a set of internal pointers682to a set of private virtual servers680.

FIG. 7is a block diagram of an embodiment of the functions of a tunnel switch. A tunnel switch700is connected to a set of physical interfaces712and714. Each physical interface712and714is capable of carrying a set of external tunnels. Physical interface712carries tunnels710A,710B,710C,710D,710E and710F. Physical interface714carries tunnels716A and716B.

Tunnel switch700also includes a set of outgoing physical interfaces732carrying a set of outgoing tunnels730to a set of physical host computers720. Physical interface732A carries tunnels730A and730B to physical host computer720A. Physical interface732B carries tunnel730C to physical host computer720B. Physical interface732C carries tunnels730D and730E to physical host computer720C. The tunnel switch700includes a customer lookup table800and a set of customer forwarding tables900. The features of the customer lookup table and customer forwarding tables will be discussed in more detail before fully explaining the functions of the tunnel switch700.

FIG. 8is an embodiment of a customer lookup table800, andFIG. 9is an embodiment of a set of customer forwarding tables900. Together, table800and set of tables900are suitable for switching a set of transmissions from an incoming physical interface and tunnel to an outgoing physical interface and tunnel. An incoming transmission may be arriving at the tunnel switch either from a customer, or from a private virtual server. Similarly, an outgoing transmission may be directed towards a private virtual server or a customer. Tables800and900operate to switch transmissions in both directions. Customer lookup table800is used as an index into the correct customer forwarding table from the set of customer forwarding tables900.

The customer lookup table800associates external tunnel and physical interface identifiers with a particular customer. Each customer listed in the customer lookup table800has an associated customer forwarding table. For example, customer1's information is contained in customer forwarding table910, and customer2's information is contained in customer forwarding table920. When a customer communicates with a private virtual server, each data transmission will arrive on a particular physical interface using a particular tunnel.

Customer lookup table800contains four fields: incoming physical interface, incoming tunnel identifier, service, and customer identifier. Each incoming physical interface and incoming tunnel identifier entry will reference a unique customer identifier. This customer identifier provides an index to the correct customer forwarding table associated with this physical interface/tunnel identifier pair. For example, a transmission arriving on physical interface712and incoming tunnel710B would be indexed to customer1's customer forwarding table (table910from FIG.9). In another example in the opposite direction, a transmission arriving on physical interface732A and incoming tunnel730B would also be indexed to customer1's customer forwarding table.

Each customer forwarding table910,920and930contains three fields: destination IP address, outgoing tunnel identifier, and outgoing physical interface. Based upon the destination IP address of a particular transmission, the proper outgoing tunnel and outgoing physical interface is determined. Using customer lookup table910as an example, transmissions with a destination IP address of the “main server” for customer I would be placed on outgoing tunnel730A on physical interface732A. In the opposite direction, transmissions with a destination IP address of “site1” for customer1would be placed on outgoing tunnel710E on physical interface712.

The information in the customer forwarding tables900is segregated by customer because the private address spaces of different customers may overlap, and therefore the destination IP addresses on each individual customer forwarding table are not unique within the set of all customer forwarding tables. For example, “main server” of customer1and “server” of customer2may have the same IP address.

The service field in the customer lookup table800identifies whether only a tunnel switching service (TS) is required, or a packet switching service (PS) is required. If only a tunnel switching service is required, the associated customer forwarding table will contain only a single entry specifying the proper outgoing tunnel and outgoing physical interface. For example, customer lookup table800indexes transmissions arriving on physical interface712and incoming tunnel710C to customer2, and identifies these transmissions as requiring only a tunnel switching service Customer lookup table920associated with customer2directs all traffic to outgoing tunnel730D on physical interface732C.

The customer lookup table800and customer forwarding tables900allow the tunnel switch700to support a variety of different private network configurations. For example, customer lookup table800shows that customer1uses two different incoming tunnels:710A and710B. Customer forwarding table910shows that customer I also has two different destination IP addresses corresponding to two different private virtual servers: “main server” and “backup server.” Additionally, customer1has two different destination IP addresses corresponding to two different customer sites: “site1” and “site2.” However, customer forwarding table920shows that customer2has only one private virtual server (“server”). The example private network configurations referred to herein are merely illustrative. It will be understood by one of skill in the art that many different configurations are possible.

Referring back toFIG. 7,FIG. 7shows the steps associated with switching a packet between an external tunnel (in one embodiment, from a customer site) and a private virtual server. A physical interface712connects a set of external tunnels710to the tunnel switch700. A packet718arrives on one of the external tunnels710B. The incoming physical interface and tunnel identification information is read740from the packet718, and presented744to a customer lookup table800.

The customer lookup table800uses the physical interface and tunnel identifier to return748the correct customer forwarding table (910) for use with the packet718. A group of customer forwarding tables900contains a customer forwarding table910that is associated with the customer that uses physical interface712and tunnel710B. Packet718's destination IP address, for example, “main server” is presented750to customer forwarding table910.

From the information contained in customer forwarding table910, the correct outgoing physical interface and tunnel identifier for packet718is identified754. Referring toFIG. 9, destination IP address “main server” corresponds to outgoing tunnel730A and physical interface732A. Packet718is then placed on tunnel730A that will transport it to the physical host computer720A.

Customers utilizing a private virtual server system may also be accessing the global Internet. In this case, both the private virtual server communications traffic and the Internet communications traffic are sent out on a public network. A method for separating the two traffic streams is required.

In one embodiment, shown inFIG. 10A, Internet traffic is separated out at the customer's site.FIG. 10Ashows a system1000for separating Internet and private virtual server traffic. In system1000, a traffic separation mechanism1012is located at the customer site1010. A tunnel1022is created for sending private virtual server traffic across the local or regional network1020. Internet traffic1024is separated out before reaching the local or regional network1020and sent separately to the Internet1030.

FIG. 10Bshows another embodiment of a system for separating Internet and private virtual server traffic. System1050separates Internet traffic out after all customer traffic has reached a private virtual server system1040. A customer site1010sends both Internet and private virtual server traffic out on a tunnel1026across the local or regional network1020. All traffic arrives at the private virtual server system1040through a tunnel switch1060.

Within the tunnel switch1060, traffic addressed to the Internet is segregated out from traffic directed to the customer's private virtual server(s). The Internet traffic is sent out to the Internet1030via a public communications channel1064. Internet responses back to the customer are returned in the same way that they were sent. The tunnel switch1060sends private virtual server traffic out on an internal tunnel1062to the physical server machine1070that holds the customer's private virtual server.

A variety of tunneling protocols may be used to create the tunnels used in the present invention. It is preferable to use a layer2tunneling protocol for security purposes. Layer2tunnels provide solid circuits that make it difficult to “spoof” a fake source address. Packets using a layer3tunneling protocol may be created with a fake IP address, allowing a packet to appear to come from a customer when in fact it was sent by an unauthorized third party. Tunnels using a layer3tunneling protocol require encryption so that an intruder cannot decode the information. Encryption is also required to protect against accidentally routing the traffic to an incorrect destination, because the encryption will prevent mis-directed traffic from being decoded. Preference for tunnel type depends upon the service provider's network architecture.

Typical examples of tunnel protocols include Asynchronous Transfer Mode virtual circuits (ATM VCs), frame relay virtual circuits (FR VCs), the Point-to-Point Protocol (PPP) across the Layer2Tunneling Protocol (L2TP), and IP security protocol (IPsec). ATM or frame relay virtual circuits may be delivered to a customer using Digital Subscriber Line (DSL) access. However, it will be evident to one of skill in the art that other tunneling protocols may be used to implement the tunnels of the present invention.

FIG. 11is an illustration of an embodiment of a private virtual server system using ATM layer2tunneling with DSL access. A system1100spans a customer site1110, a local or regional network1140, and a service provider1150.

The customer site1110contains a group of computers1112A,1112B, and1112C. The computers1112are representative of the customer's on-site private network. Such a private network could be comprised of more or fewer individual computers, as well as other types of equipment such as storage devices.

Components within a customer's on-site private network communicate using a private IP addressing scheme. A packet1114is a privately-addressed transmission sent using the local IP protocol of the customer site1110. Packet1114is sent from customer1110to customer1110's private virtual server. Packet1114has a destination address corresponding to a private virtual server of service provider1150.

The on-site private network of devices1112is connected to a customer premise equipment box (CPE)1120. Packet114is routed to CPE1120. The CPE connects the customer site1110to a tunnel1132, established between the customer site1110and the service provider site1150. The tunnel functions as a bi-directional data pipe, and is typically established when a customer subscribes to a service provider providing a tunneling service. A fixed ATM tunnel is referred to as a permanent virtual circuit. The CPE divides the data of packet1114into cells (or packets) of a fixed size designated by the ATM protocol, and encapsulates them with a Virtual Channel Identifier (VCI) used to direct the cells through the data pipe. An ATM cell1118is created from the division and encapsulation of packet1114.

Tunnel1132terminates at a tunnel switch1160of the service provider1150. Tunnel switch1160is connected via a set of bi-directional ATM tunnels1172to a set of physical servers1170. In another embodiment, two sets of unidirectional tunnels are used to provide a two-way connection between customer site1110and service provider1150.

FIG. 12shows an embodiment of the traffic flow of an ATM cell from a tunnel to a private virtual server. The system ofFIG. 12presents in more detail the functions of the service provider data service center1150shown in FIG.11. InFIG. 12, the service provider data service center1150contains the tunnel switch1160and a physical host computer1170. It is to be understood that more than one physical host computer1170may be included in system1150.

A set of incoming external tunnels1132terminates at the tunnel switch1160. Tunnel1132B carries the incoming ATM cell1118. Referring back toFIG. 11, ATM cell1118is created by the ATM CPE1120on the customer site1110. ATM cell1118is created from a privately-addressed IP packet1114originally sent by one of the computers1112.

InFIG. 12, the VCI identifying the incoming tunnel of ATM cell1118is read1212, and presented1214to a customer lookup table1230. Customer lookup table1230returns1216the correct customer forwarding table (1232B). Table1232B is accessed from a set of customer forwarding tables1232.

Customer forwarding table1232B returns1218the identity of the outgoing tunnel required to reach the correct private virtual server destination (1250A) for ATM cell1118. ATM cell1118is then placed1220on an internal tunnel1172to reach the private virtual server1250A. Internal tunnel1172terminates at a multiplexing/demultiplexing mechanism1290of the physical host computer1170, which contains private virtual server1250A.

The VCI of ATM cell1118is stripped1252, and the VCI is presented1254to lookup table1260. The rest of the ATM cell1118, including the original source/destination addresses and payload, is held until the original IP packet1114sent by a customer1112can be reassembled. The ATM protocol uses relatively small cells compared to other transmission protocols. Therefore multiple ATM cells may be required to reassemble the original pre-ATM-encapsulation packet1114.

Once the original IP packet1114has been reassembled1262, the location of the IP stack of the destination private virtual server1250A is retrieved1256from lookup table1260. Packet1114is routed1280to the IP stack of private virtual server1250A.

Although the invention has been described in considerable detail with reference to certain embodiments, other embodiments are possible. As will be understood by those of skill in the art, the invention may be embodied in other specific forms without departing from the essential characteristics thereof For example, different protocols may be used to create tunnels. Accordingly, the present invention is intended to embrace all such alternatives, modifications and variations as fall within the spirit and scope of the appended claims and equivalents.