idnits 2.17.1 draft-jeya-virtual-server-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 16, 1997) is 9810 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 254, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 258, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 261, but no explicit reference was found in the text Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT I. Jeyasubramanian 2 Expires December 1997 FSPL 3 June 16, 1997 5 Virtual Server Protocol 7 draft-jeya-virtual-server-00.txt 9 Status of This Memo 11 This document is an Internet-Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as 19 reference material, or to cite them other than as a ``working draft'' 20 or ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the internet-drafts 24 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Abstract 30 This document specifies a protocol termed the "Virtual server 31 protocol", which makes an end-user automatically connect to a 32 least loaded Server among the list of Mirror/alternate Servers 33 available for a particular Service, advertised in the Internet. 34 Using this protocol, the clients accessing the Internet no longer 35 need to know the existence of mirror servers available for a 36 particular service. The clients instead may refer to the virtual 37 server Name assigned to the Band of Servers (including the Primary 38 Server & Mirror Servers) for accessing the Service. This protocol is 39 transparent to the end-user and avoid prompting the end-user with the 40 list of mirror servers. This protocol proves its importance, as the 41 Geographical and Load attributes of the Associated Band of Servers 42 may not be available for the end-users in deciding amongst the above 43 Band of Servers. 45 1. Introduction 47 The Virtual Server protocol suggests an automatic way of providing an 48 end-user with the Least Loaded and geographically nearest Server from 49 a list of mirror servers available for a particular service being 50 attempted by the end-user. This protocol is transparent to the 51 end-user and resides at the Primary Server of the Service advertised. 52 It shares with the Primary Server, the Mirror Servers list available 53 for the Service. It interacts with the Primary Server and the Mirror 54 Servers periodically and maintains an Attributes Database comprising 55 of the Load, Geographical location etc.,. Right now the mechanism 56 for deciding the Optimum Server among the existing Primary and Mirror 57 Servers based on the attributes is being thought about. The protocol 58 on the other hand interacts with the DNS (Domain Name Servers) 59 widespread in the Internet and updates the IP Address equivalent for 60 the Virtual Server Name present in the DNS entry with the IP address 61 of the Optimum Server decided at the Virtual Server. Due to this, 62 the IP address equivalent of the Virtual Server Name is always the IP 63 address of an Optimum Server. 65 The end-users are advertised with the Virtual Server Name of the Band 66 of Servers available for a particular Service. When the end-user 67 specifies the Virtual Server Name the DNS returns the IP address, 68 which is updated by the Virtual Server protocol and the end-user thus 69 always gets connected to the Optimum server. 71 2. Motivation 73 In many cases, the information servers provide many mirror servers on 74 the Internet to reduce the traffic and hence the load handled by the 75 single server and its network. The server usually adopts a 76 conventional method of prompting the users and the users have to 77 decide and identify the suitable server among the list of servers in 78 a trial and error method. This is an inefficient method of 79 identifying a server and there is a scope of automating this 80 selection procedure and making it transparent to the end-user. 82 The technical reasons behind the development of the Virtual Server 83 Protocol: 85 o There is no way the end-user can find the traffic and load 86 handled by Primary/Mirror server and the network. 88 o There is no way to identify the status (up/down) of the 89 mirror servers. 91 o Consequently there is no room for the end-user in deciding 92 the optimum server in a single-shot. 94 These are the advantages of using this protocol: 96 o All Primary/Mirror sites are identified by a single virtual 97 server name. 99 o The Client always get connected to the optimum server 100 (considering the server load, network traffic and 101 geographical location). 103 o The whole process is transparent to the end-user. 105 3. Virtual Server Protocol 107 Virtual Server protocol performs the following operations: 109 1. Sends periodic requests to the list of mirror servers and 110 collects their attributes (Load, traffic, location, hop count) 111 from their responses. 113 2. Selects the optimum server from the list. Actual selection 114 procedure is up to the implementation. 116 3. Updates the name servers periodically with optimum server 117 address for the virtual server name. 119 3.1. Topology 121 Primary Mirror 122 Server Servers 124 Virtual +......+------+ +------+ +------+ 125 Server : Sv | S1 | | S2 | | S3 | 126 Protocol +......+------+ +------+ +------+ 127 \ | / 128 \ --------- / 129 ( ) 130 ( Internet ) 131 ( ) 132 / --------- \ 133 / \ 134 +--------+ +-------------+ 135 | Client | | Name Server | 136 +--------+ +-------------+ 137 3.2. Packet Format 139 All VSP messages must be encapsulated within an Ipv4 packet and must 140 be sent to the IP address of servers. The protocol field in the IP 141 header must contain the value 120 (decimal) indicating that the IP 142 packet contains a VSP message. 144 VSP message structures are the following: 146 Server Status Request Message 147 ----------------------------- 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Version | Op Code | Max Ack Intvl | Reserved | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Server Name | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Server IP Address | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Server Status Response Message 160 ------------------------------ 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Version | Op Code | Hop Count | Reserved | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Server Name | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Server IP Address | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Server Load Metric | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Network Traffic Metric | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Geographical Location Identifier | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Version 179 The VSP protocol version number. The current Version = 1. 181 Op Code 182 Specifies the function of the message. Two Op codes are defined. 184 VSP_REQUEST: Op Code = 0 185 VSP_RESPONSE: Op Code = 1 187 Max Ack Intvl 188 Maximum Acknowledgement Interval is the maximum amount of time the 189 sender of the message will wait for the response. If the response is 190 not received within this interval the receiver is assumed to be DOWN. 192 Server Name 193 Name of the mirror server. 195 Server IP Address 196 IP address of the mirror server. 198 Server Load Metric 199 Mirror server's Load is represented by the total number of TCP 200 connections handled by the server. 202 Network Traffic Metric 203 Network traffic of the Mirror server can be found by the traffic 204 handled by the router connected to that network. 206 Geographical Location Identifier 207 Country code can be used for this purpose. 209 Hop Count 210 Hop count for this server. 212 3.3 Procedure 214 The VSP protocol operation is described by the procedure given in 215 this section. 217 The virtual server protocol assumed to be present in one of the 218 servers is called the Primary Server. The Primary Server provides the 219 list of mirror servers to the virtual server protocol. 221 Client to Name Server Interactions 222 ---------------------------------- 224 1. The Client asks for connection to a Virtual server. 226 2. The Name Server replies with the IP address stored in its 227 cache. 229 Virtual Server Protocol to Name Server Interactions 230 --------------------------------------------------- 232 1. The VSP sends the Server Status Request message periodically 233 to all the mirror servers found in the mirror server list. 235 2. The VSP receives Server Response messages from most of the 236 mirror sites. The Maximum Acknowledgement Interval allows it 237 to find the servers which are not functioning properly. The 238 response messages give the server the attributes (Server Load, 239 Network traffic and Geographical location) of all mirror 240 servers. 242 3. The VSP selects the optimum server from the list. The memo 243 does not discuss the selection procedure for selecting the 244 optimum server from the list. 246 4. The VSP protocol sends the optimum mirror server address to 247 the name server. 249 5. Name server provides the IP address to the client, which is 250 updated by the VSP. 252 4. References 254 [1] [RFC 2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and 255 J.Bound, "Dynamic updates in the Domain Name system (DNS 256 UPDATE)", RFC 2136, April 1997. 258 [2] [RFC 1035] Mockapetris, P., "Domain names - implementation and 259 specification", STD 13, RFC 1035, November 1987. 261 [3] [RFC 1034] Mockapetris, P., "Domain names - concepts and 262 facilities", STD 13, RFC 1034, November 1987. 264 5. Security Considerations 266 Security issues are not discussed in this memo. 268 6. Author's Address 270 I.Jeyasubramanian 271 Future Software Private Limited. 272 Madras - 600 035, INDIA. 273 Phone: +91-44-4340323 274 Fax: +91-44-4344157 275 Email: jeyai@future.futsoft.com 277 Table of Contents 279 1. Introduction ............................................... 2 280 2. Motivation .................................................. 2 281 3. Virtual Server Protocol..................................... 3 282 3.1. Topology ................................................. 3 283 3.2. Packet Format ............................................ 4 284 3.3. Procedure................................................. 5 285 4. References ................................................. 6 286 5. Security Considerations .................................... 6 287 6. Author's Address ........................................... 7