HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:20:50 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 17 Mar 1998 16:31:00 GMT ETag: "323efd-34fc-350ea544" Accept-Ranges: bytes Content-Length: 13564 Connection: close Content-Type: text/plain INTERNET DRAFT I. Jeyasubramanian Expires December 1997 FSPL June 16, 1997 Virtual Server Protocol draft-jeya-virtual-server-00.txt Status of This Memo This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document specifies a protocol termed the "Virtual server protocol", which makes an end-user automatically connect to a least loaded Server among the list of Mirror/alternate Servers available for a particular Service, advertised in the Internet. Using this protocol, the clients accessing the Internet no longer need to know the existence of mirror servers available for a particular service. The clients instead may refer to the virtual server Name assigned to the Band of Servers (including the Primary Server & Mirror Servers) for accessing the Service. This protocol is transparent to the end-user and avoid prompting the end-user with the list of mirror servers. This protocol proves its importance, as the Geographical and Load attributes of the Associated Band of Servers may not be available for the end-users in deciding amongst the above Band of Servers. Jeyasubramanian Expires December, 1997 [Page 1] Internet Draft Virtual Server Protocol June 1997 1. Introduction The Virtual Server protocol suggests an automatic way of providing an end-user with the Least Loaded and geographically nearest Server from a list of mirror servers available for a particular service being attempted by the end-user. This protocol is transparent to the end-user and resides at the Primary Server of the Service advertised. It shares with the Primary Server, the Mirror Servers list available for the Service. It interacts with the Primary Server and the Mirror Servers periodically and maintains an Attributes Database comprising of the Load, Geographical location etc.,. Right now the mechanism for deciding the Optimum Server among the existing Primary and Mirror Servers based on the attributes is being thought about. The protocol on the other hand interacts with the DNS (Domain Name Servers) widespread in the Internet and updates the IP Address equivalent for the Virtual Server Name present in the DNS entry with the IP address of the Optimum Server decided at the Virtual Server. Due to this, the IP address equivalent of the Virtual Server Name is always the IP address of an Optimum Server. The end-users are advertised with the Virtual Server Name of the Band of Servers available for a particular Service. When the end-user specifies the Virtual Server Name the DNS returns the IP address, which is updated by the Virtual Server protocol and the end-user thus always gets connected to the Optimum server. 2. Motivation In many cases, the information servers provide many mirror servers on the Internet to reduce the traffic and hence the load handled by the single server and its network. The server usually adopts a conventional method of prompting the users and the users have to decide and identify the suitable server among the list of servers in a trial and error method. This is an inefficient method of identifying a server and there is a scope of automating this selection procedure and making it transparent to the end-user. The technical reasons behind the development of the Virtual Server Protocol: o There is no way the end-user can find the traffic and load handled by Primary/Mirror server and the network. o There is no way to identify the status (up/down) of the mirror servers. Jeyasubramanian Expires December, 1997 [Page 2] Internet Draft Virtual Server Protocol June 1997 o Consequently there is no room for the end-user in deciding the optimum server in a single-shot. These are the advantages of using this protocol: o All Primary/Mirror sites are identified by a single virtual server name. o The Client always get connected to the optimum server (considering the server load, network traffic and geographical location). o The whole process is transparent to the end-user. 3. Virtual Server Protocol Virtual Server protocol performs the following operations: 1. Sends periodic requests to the list of mirror servers and collects their attributes (Load, traffic, location, hop count) from their responses. 2. Selects the optimum server from the list. Actual selection procedure is up to the implementation. 3. Updates the name servers periodically with optimum server address for the virtual server name. 3.1. Topology Primary Mirror Server Servers Virtual +......+------+ +------+ +------+ Server : Sv | S1 | | S2 | | S3 | Protocol +......+------+ +------+ +------+ \ | / \ --------- / ( ) ( Internet ) ( ) / --------- \ / \ +--------+ +-------------+ | Client | | Name Server | +--------+ +-------------+ Jeyasubramanian Expires December, 1997 [Page 3] Internet Draft Virtual Server Protocol June 1997 3.2. Packet Format All VSP messages must be encapsulated within an Ipv4 packet and must be sent to the IP address of servers. The protocol field in the IP header must contain the value 120 (decimal) indicating that the IP packet contains a VSP message. VSP message structures are the following: Server Status Request Message ----------------------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Op Code | Max Ack Intvl | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Server Status Response Message ------------------------------ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Op Code | Hop Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Load Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Traffic Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Geographical Location Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The VSP protocol version number. The current Version = 1. Jeyasubramanian Expires December, 1997 [Page 4] Internet Draft Virtual Server Protocol June 1997 Op Code Specifies the function of the message. Two Op codes are defined. VSP_REQUEST: Op Code = 0 VSP_RESPONSE: Op Code = 1 Max Ack Intvl Maximum Acknowledgement Interval is the maximum amount of time the sender of the message will wait for the response. If the response is not received within this interval the receiver is assumed to be DOWN. Server Name Name of the mirror server. Server IP Address IP address of the mirror server. Server Load Metric Mirror server's Load is represented by the total number of TCP connections handled by the server. Network Traffic Metric Network traffic of the Mirror server can be found by the traffic handled by the router connected to that network. Geographical Location Identifier Country code can be used for this purpose. Hop Count Hop count for this server. 3.3 Procedure The VSP protocol operation is described by the procedure given in this section. The virtual server protocol assumed to be present in one of the servers is called the Primary Server. The Primary Server provides the list of mirror servers to the virtual server protocol. Client to Name Server Interactions ---------------------------------- 1. The Client asks for connection to a Virtual server. Jeyasubramanian Expires December, 1997 [Page 5] Internet Draft Virtual Server Protocol June 1997 2. The Name Server replies with the IP address stored in its cache. Virtual Server Protocol to Name Server Interactions --------------------------------------------------- 1. The VSP sends the Server Status Request message periodically to all the mirror servers found in the mirror server list. 2. The VSP receives Server Response messages from most of the mirror sites. The Maximum Acknowledgement Interval allows it to find the servers which are not functioning properly. The response messages give the server the attributes (Server Load, Network traffic and Geographical location) of all mirror servers. 3. The VSP selects the optimum server from the list. The memo does not discuss the selection procedure for selecting the optimum server from the list. 4. The VSP protocol sends the optimum mirror server address to the name server. 5. Name server provides the IP address to the client, which is updated by the VSP. 4. References [1] [RFC 2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J.Bound, "Dynamic updates in the Domain Name system (DNS UPDATE)", RFC 2136, April 1997. [2] [RFC 1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] [RFC 1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. 5. Security Considerations Security issues are not discussed in this memo. Jeyasubramanian Expires December, 1997 [Page 6] Internet Draft Virtual Server Protocol June 1997 6. Author's Address I.Jeyasubramanian Future Software Private Limited. Madras - 600 035, INDIA. Phone: +91-44-4340323 Fax: +91-44-4344157 Email: jeyai@future.futsoft.com Table of Contents 1. Introduction ............................................... 2 2. Motivation .................................................. 2 3. Virtual Server Protocol..................................... 3 3.1. Topology ................................................. 3 3.2. Packet Format ............................................ 4 3.3. Procedure................................................. 5 4. References ................................................. 6 5. Security Considerations .................................... 6 6. Author's Address ........................................... 7 Jeyasubramanian Expires December, 1997 [Page 7]