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]