[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]