Network Working Group Internet Draft W. Wollman H. Jegers Document: draft-wollman-slbrp-00.txt The MITRE Corporation Expires: May 2004 November 2003 Server Load Balancing Registration Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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 inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines an experimental protocol called the Server Load Balancing Registration Protocol (SLBRP). This protocol permits servers to register and coordinate services with a service load balancing (SLB) application. Coordination between real servers and the SLB application will include service definition(s), Virtual IP (VIP) address support, server application health monitoring, as well as, optional support for automatic Domain Name System (DNS) and DNS- based Global Server Load Balancer (GSLB) updates. This document also describes Anycast Address Resolution Protocol (ARP) implementations that can operate with an SLB and GSLB based enterprise infrastructure. Conventions used in this document Expires - May 2004 [Page 1] Draft SLBRP November 2003 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ii]. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................3 3. Motivation and Protocol Requirements...........................5 4. Protocol Description...........................................6 4.1 Overview...................................................6 4.2 SLBRP Message Details......................................9 5. Formal Message Syntax.........................................10 5.1 General Format............................................10 5.2 Message Types.............................................10 5.3 Null Message..............................................11 5.4 Acknowledgement Message...................................11 5.5 Shutdown Notification Message.............................11 5.6 Real Server Heartbeat Update Message......................12 5.7 Real Server Registration Request Message..................12 5.8 Real Server Registration Response Message.................13 5.9 Service Address Request Message...........................14 5.10 Service Address Response Message.........................14 5.11 Service Registration Request Message.....................15 5.12 Service Delete Request Message...........................18 5.13 Real Server DNS Update Message...........................18 5.14 GSLB Service Information Request Message.................19 5.15 SLB Service Information Response Message.................19 5.16 New DNS Notification Message.............................22 5.17 GSLB DNS Notification Message............................22 5.18 Anycast ARP (AARP) Request Message.......................23 5.19 Anycast ARP Response Message.............................24 5.20 Global Anycast ARP Request Message.......................25 5.21 Global AARP Response Message.............................25 6. SLBRP Operation with GSLB Support.............................25 6.1 Real Server Registration Process..........................29 6.2 VIP Address Request.......................................29 6.3 Service Registration......................................29 6.4 Service Deletion..........................................30 6.5 Shutdown..................................................30 6.6 Real Server DNS Update....................................30 6.7 DNS Update................................................30 6.8 Service Update............................................30 6.9 Scope List................................................31 7.0 Protocol Timers.............................................31 8.0 IPv6 Support................................................31 9.0 Security Considerations.....................................32 Reference........................................................32 Acknowledgments..................................................33 Expires - May 2004 [Page 2] Draft SLBRP November 2003 Author's Addresses...............................................33 1. Introduction The Server Load Balancing Registration Protocol (SLBRP) permits servers to register services with a server load balancer (SLB) application. To support server registration the SLB must provide an application that accepts registration messages and based upon these messages, permits the SLB to automatically configure to support server load balancing. The protocol permits the SLB to accept Virtual IP (VIP) addresses from servers or assign/lease VIP addresses to servers. Optionally, the SLB can register unique server addresses with a Domain Name System (DNS), support VIP address route injection, and provide service health statistics and server registration with DNS-based Global Server Load Balancing (GSLB) applications. SLBRP allows servers to gracefully deregister services from the SLB prior to shutdown or prior to leaving the SLB network. The SLB shall also monitor the health of services registering for load balancing. As part of this, the SLB can detect servers and service failures and automatically remove servers from service after failure. The SLB shall also notify the DNS-based GSLB about server and service state changes. 2. Terminology This specification uses a number of terms that may not be familiar to the reader. This section defines some of these terms and refers to other documents for definitions of others. Real Server or Server (RS) A real server provides the services being balanced and monitored by the SLB. Virtual IP (VIP) Address A VIP address permits clients to communicate with one or more real servers using a single address. The VIP address can be used by clients to connect to a server in lieu of using any of the serverÆs real IP addresses. The server may or may not have the VIP address configured as a loopback address. If the server does not maintain the VIP address as a loopback address, the server load balancing application will support client connections to the server by Network Address Translation (NAT). If the server does maintain the VIP as a loopback address, the server can support a concept called Direct Server Return (DSR) and the SLB application does not have to support NAT for client connections. In support of DSR, the SLB application Expires - May 2004 [Page 3] Draft SLBRP November 2003 must be able to map VIP connections to serversÆ Ethernet MAC addresses. Server Load Balancer (SLB) The SLB is an application or set of applications that permits client connections to a service to be distributed across one or more servers. A service is often distinguished by the application protocol (e.g., HTTP, FTP, etc.), transport protocol used (e.g., TCP, UDP, or SCTP), the applicationÆs unique TCP, UDP, or SCTP port number, as well as the Virtual IP (VIP) address used by the service. A service can also be distinguished by a unique name or URL [iii]. Server Farm A server farm is a group of servers that provide the same or similar services. A real server can participate in separate unique server farms. Virtual Server (VS) A virtual server represents one or more real servers. Multiple real servers or a server farm can be represented as one virtual server with one VIP address. Route Health Injection A SLB application/appliance can advertise a route to the VIP address by injecting the VIP into an IP routing protocol. If the health of the service fails, the VIP route can be removed. A VIP address can be a 32 bit route. In lieu of advertising 32 bit routes within an Intranet, the SLB can be assigned a pool of addresses with clear IP subnet boundaries. The SLB can then advertise reachability to this IP address pool via an IP routing protocol. Global Server Load Balancing (GSLB) GSLB provides the ability to direct clients to one or more servers when a server/service is available at multiple geographic locations. DNS-based GSLB permits DNS responses to be based upon the availability of server farms, the approximate location of the client relative to the server farms, and the performance of the networks between the client and server farms. The specifications about the decision processing associated with directing a client to one or more geographically distributed servers is not part of this specification. Scope Expires - May 2004 [Page 4] Draft SLBRP November 2003 A set of services, typically making up a logical administrative group. This protocol leverages the same definition as defined within RFC 2608. 3. Motivation and Protocol Requirements Server Load Balancing (SLB) technology has provided a fundamental cornerstone necessary to the success of the Internet. Automating SLB configuration will decrease the time, cost, and management required to deploy SLB server farms. Automating SLB configurations will also decrease the complexity associated with network infrastructure configuration management. These productivity enhancements have the potential to permit greater use of SLB technology throughout enterprise networks. In addition, the proliferation of the local area wireless networks, powerful laptop servers, and mobile systems require that SLB technology evolve to support this new environment. In particular, a server should have the ability to roam between and among wireless cells and register its services with a SLB application within the area of responsibility for each cell. This capability allows mobile servers to easily leverage an existing SLB infrastructure without introducing new software and systems that require special management and monitoring. Requirements for a protocol that permits server load balancing registration include: The real server must be able to locate a SLB application that supports server and service registration. Messages between the real servers and the SLB device should be authenticated and verified as trustworthy. The network load used to maintain communications between the real server and the SLB device must be minimal. The computer processing requirements needed to support registration of services by the real server must be minimal. The real server should be able to detect failure of the SLB device. The real server should be able to report failure of a service to a SLB device and de-register that service from the SLB device. The SLB device should be able detect failure of the real server and/or failure of the service(s) supported by the real server. Expires - May 2004 [Page 5] Draft SLBRP November 2003 After failure detection, the SLB should be able to automatically remove the real server from the server farm. Requirements for a protocol that permit VIP address allocation include: Ability to maintain a VIP address pool for assignment to real servers Ability to identify assigned addresses Ability to identify addresses within an address pool that have not been assigned. Ability to maintain a lease history for recently assigned VIP addresses. Ability to support pre-defined static VIP address assignment for particular servers. These assignments can be based upon predefined tables or authentication techniques. In this case, the goal is to help ensure that separate server farm groups not be identified by the same VIP address unless the services offered are easily differentiated. Ability to release VIP addresses after server farm failure Ability for a real server to request a recently assigned VIP whenever necessary For DNS registration of VIP, adhere to the DNS registration standard as defined in RFC 2136 [iv] and RFC 3007 [v]. The definition and syntax associated with the scope of a service will adhere to the same definition as defined in RFC 2165, Service Location Protocol Version 2 [vi]. 4. Protocol Description 4.1 Overview The SLB Registration Protocol is a client-server protocol that leverages the Transmission Control Protocol (TCP) to support communications between the real server and the SLB device. This TCP connection is expected to remain open as long as the server would like to use the SLB services. Our initial implementation maintains the real serverÆs default router as the local SLB device. Other possibilities that will permit a server to locate a local SLB device include using an option field within the Dynamic Host Configuration Protocol (DHCP). Expires - May 2004 [Page 6] Draft SLBRP November 2003 The following table lists the messages used to implement the protocol, their sources and their destinations. These messages include communication between the RS and SLB, SLB and GSLB, as well as, SLB and DNS. Although messages between the SLB and RS are via TCP, other messages between the SLB, GSLB and DNS are UDP based. Anycast ARP (AARP) messages are exchanged between a client and SLB, as well as, a client and GSLB. AARP messages are UDP based. Each message is described in detail in Section 5. Message Source Destination Required ------- ------ ----------- -------- Acknowledgement SLB RS Yes Shutdown Notification RS, SLB RS,SLB Yes Real Server Heartbeat Update RS SLB Yes Real Server Registration Request RS SLB Yes Real Server Registration Response SLB RS Yes Service Address Request RS SLB Yes Service Address Response SLB RS Yes Service Registration Request RS SLB Yes Service Delete Request RS SLB Yes Real Server DNS Update SLB DNS No GSLB Service Information Request GSLB SLB No SLB Service Information Response SLB GSLB, SLB No New DNS Notification SLB RS No GSLB DNS Notification SLB,DNS GSLB No AARP Request Client SLB No AARP Response SLB Client No Global AARP Request Client GSLB No Global AARP Response GSLB Client No Table 1 û Messages SLB registration message exchanges between a RS, SLB, and GSLB are shown in Figure 1. Once a server has registered with the SLB and VIP address instantiation is complete, the server will register one or more services with the SLB. Next, the SLB device shall determine if the requested service is healthy and then maintains the option to inject a route to the VIP address into the network to advertise network layer reachability to the service. In addition, once a VIP instantiation and service registration process has been completed, the SLB device will register the new VIP address with the GSLB application. Since there can be more than one GSLB application within the enterprise, this registration message generated by the SLB device can be a multicast UDP datagram. The SLB device will continually monitor the state of all real servers within a server farm. Based upon the SLBÆs interpretation about the health Expires - May 2004 [Page 7] Draft SLBRP November 2003 of the service, the SLB will update the GSLB application with a score that represents the health of the SLB deviceÆs directly attached server farm. The SLB will leverage the service health information provided to it by the real server. RS SLB WAN GSLB | Server Registration | | | | -------------------> | | | | | | | | Svr Reg Response | | | | <------------------ | | | | | | | | Service Addr Request | | | | -------------------> | | | | | | | | Service Addr Response | | | | <------------------ | | | | | | | | Service Registration | | | | -------------------> | | | | | | | | Service Health Check | | | | <------------------> | | | | | | | | Service Reg. Ack | | | | <------------------ | | | | | | | | |Optional VIP | | | |Route Injection | | | |--------------> | | | | | | | | SLB Service Information Response | | | --------------------------------> | | Service Health | | | | Heartbeat | | | | -------------------> | | | | Heartbeat Ack | | | | <------------------ | | | | | | | | | GSLB Service Information Request | | | <-------------------------------- | | | | | | | SLB Service Information Response | | | -------------------------------> | | Service Health Check | | | | <------------------> | | | Figure 1. SLBRP Message Exchange Diagram Expires - May 2004 [Page 8] Draft SLBRP November 2003 The health of a service shall be represented by a number from 0 to 100. That is, if the score is 100, this service is at its maximum capacity and should not be accessed by new clients. A value of 0 indicates the service is completely available. The algorithms used to calculate this value are left up to the implementation. The actual scoring mechanism used to itemize the health of the server is beyond the scope of this specification. Some items that may be considered as part of the health score from either the real server or the SLB include overall service availability, number of active connections, WAN access bandwidth availability, health of the SLB, capability of real servers within the server farm, and any security considerations. 4.2 SLBRP Message Details The SLB Registration Protocol is a client-server protocol. Real servers will register the services that require support with the SLB device. The SLB device will load balance the services described by the real server and represent the real server(s) to the network via a VIP address. The SLB device has an option to register the service with GSLB devices within the enterprise. Once a service is registered with the GSLB, the GSLB expects periodic updates about the service health. After three or more update failures, the GSLB device will poll the SLB via UDP unicast to obtain the status about the particular service. If there is no response, the GSLB will remove the entry about the service from its database. Suggested UDP and TCP port numbers used by the SLBRP are provided in Table 2. Real servers must use the TCP SLBRP port number to register with the SLB. When the SLB device responds to the real server, it must use a destination port number that matches the source port number provided by the client in the registration message. In addition, port numbers are allocated for UDP-based SLB to GSLB communication and two different Anycast Address Resolution Protocols (AARPs). These operate with the SLB and GSLB. The following table identifies suggested port numbers. Except for DNS-based communications, these ports are considered configurable. Destination IP Address Port Type Purpose ----------------- ---- ----------- -------------- SLB Address 8101 TCP RS-SLB DNS Address 53 UDP SLB-DNS SLB WAN Address 8102 UDP Unicast AARP GSLB WAN Address 8103 UDP Unicast AARP, SLB-GSLB Multicast Group 8104 UDP Multicast SLB-GSLB Expires - May 2004 [Page 9] Draft SLBRP November 2003 Table 2 û Port Numbers 5. Formal Message Syntax This section describes all the messages used to implement the SLB Registration Protocol. Each message consists of a header and a data section. Messages shall be sent to the network using network byte order. 5.1 General Format All messages will begin with the following header: 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0x2A | 0x2A | CRC-16 for succeeding data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Version | Msg. Type | Data Length + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first two characters are used to simplify start of message recognition. The CRC-16 checksum shall be calculated to include the version, message type, data length, and all data. The message types are defined in section 5.2. This document defines Version 1 of the SLBRP. The data length shall indicate the number of data bytes following this field. The range of this length shall be 0 to 65535. The data string shall contain binary information as defined in the succeeding sections. 5.2 Message Types Value Definition 0 Null 1 Acknowledgement Response 2 Shutdown Request 3 Real Server Heartbeat Update 4 Real Server Registration Request 5 Real Server Registration Response 6 Service Address Request 7 Service Address Response 8 Service Registration Request 9 Service Delete Request 10 Real Server DNS Update Expires - May 2004 [Page 10] Draft SLBRP November 2003 11 GSLB Service Information Request 12 SLB Service Information Response 13 New DNS Notification Message 14 GSLB DNS Notification 15 AARP Request 16 AARP Response 17 Global AARP Request 18 Global AARP Response 5.3 Null Message The Null message shall not be used in the network. This value shall be used as an internal place holder for decoding or encoding actual messages. Any Null messages receives shall be ignored. This message shall only contain a data length (0) with no data. 5.4 Acknowledgement Message The Acknowledgement message shall be used to indicate the execution status of certain requests. Not all requests shall be answered by this message. Refer to each particular request message to determine the appropriate response. The Message Type field indicates which message this acknowledgement pertains to and shall have one of the values defined in section 5.2. The Success field shall indicate if the request was successful, where 0 indicates success. All other values indicate a failure and may be used to specify the error. Values for error codes depend on the message being acknowledged. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg. Type | Success | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.5 Shutdown Notification Message The Shutdown Request Message shall be sent by a RS, SLB, or GSLB to indicate a planned shutdown. Each entity shall send the shutdown request to entities that it is currently directly communicating with, except for the GSLB. For example: Entity Shutting Down Message Destination RS SLB SLB RS, GSLB Expires - May 2004 [Page 11] Draft SLBRP November 2003 No acknowledgement is required for this message. If an acknowledgement is sent, it may be ignored. The message shall contain the IP address of the entity shutting down. The SLB shall send this message via TCP to all registered RSs and via UDP to other SLB and GSLB devices. A RS will only send this message via TCP to any SLBs supporting its registered services. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.6 Real Server Heartbeat Update Message The Real Server Heartbeat Update is sent from the real server to the SLB. The intent is for the real server to provide information on the ôhealthö of a particular service. Each service supported by the real server shall send its own message. The service health is a score that ranges between 0 and 100. See section 4.1 for the definition of the health score. The SLB shall respond back to the real server with an acknowledgement message. This provides a mechanism for the real server to determine if the SLB has failed. The value of the service ID is determined by the RS when it registers the service with the SLB. The only requirement is that this ID be unique between the RS and its parent SLB. This message interval shall default to sixty seconds. A 5 second jitter timer can be implemented. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Service ID | Health Score | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.7 Real Server Registration Request Message The Real Server Registration Request message permits the real server to notify the SLB of its existence. When the real server begins execution it shall send this message to the SLB it would like to use to register its services. The SLB shall respond with a Real Server Registration Response message. SLB support for RS services can only be activated by the SLB after it receives and processes separate service registration messages. Expires - May 2004 [Page 12] Draft SLBRP November 2003 The message shall contain the unique IP address of the registering real server, its host name, and a flag indicating whether the RS should be registered with the local DNS by the SLB. The flag ôRegister with DNSö shall be 0 for a false indication and 1 if the RS should be registered by the SLB. The host name field is variable and shall contain Host Name Length characters. If the host name is not a fully qualified domain name, the SLB shall append its domain name to the server provided host name prior to registering the server with a local DNS. If the server provides a fully qualified domain name to the SLB, the SLB will register the fully qualified domain name with its local DNS if and only if the RS domain name matches one of the SLBÆs domain names. If the DNS does not accept the update or if there is a domain name mismatch, the RS will be notified of the DNS registration failure. Up to 255 ASCII characters may be provided by the real server for its host name. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + RS IP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Reg. With DNS |Host Name Len. | Host Name . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.8 Real Server Registration Response Message The Real Server Registration Response message is sent by the SLB in response to a real server registration. It supplies the real server with information about the SLB. This information may be used to help configure the real server to support the SLBÆs capabilities. The IP Address supplied in this message represents the registering real serverÆs address. The SLB Method indicates the current server load balancing method used by the SLB. Current values are: 1 û Direct Server Return 2 û Network Address Translation 3 û IP Tunneling The Status field indicates the result of the registration process. Other values may be used to indicate additional error and warning conditions. Required values shall be: 0 û Success 1 û Previously Registered (new registration request ignored) 2 û Failure 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Expires - May 2004 [Page 13] Draft SLBRP November 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RS IP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + SLB Method | Status | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.9 Service Address Request Message The Service Address Request message allows the real server to request a VIP address from the SLB. The SLB shall use a configurable pool of IP addresses to allocate VIP addresses to the servers. The SLB responds to this message with a Service Address Response message. A VIP address may be statically allocated to correspond to a specific URL name or one may be dynamically allocated from the VIP address pool. The static URL/VIP combinations and dynamic ranges shall be user configurable. An SLB shall return the same dynamic address for a specific URL name for up to a default time of 1200 seconds. This time shall be configurable. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + URL Name Len. | URL Name . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The URL Name is the text commonly used to reference a specific service. An example URL is http://www.mitre.org. This name is defined when a service is registered. Up to 255 ASCII characters may be provided. 5.10 Service Address Response Message The Service Address Response allows the SLB to provide a real server with a VIP address. The real server will then use this VIP address to register at least one service with the SLB. The URL name originally requested shall also be returned. If no service is registered by the real server after a VIP address has been allocated, the SLB maintains the option of terminating the VIP lease and unregistering the real server. Up to 255 ASCII characters may be specified. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + VIP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + URL Name Len. | URL Name . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires - May 2004 [Page 14] Draft SLBRP November 2003 5.11 Service Registration Request Message The Service Registration Request message describes the service that the real server would like the SLB to support. The SLB shall respond to the real server with an acknowledgement message indicating success or failure of the registration. If the message provides information to the SLB that the particular SLB does not support or does not require, the extra information should be ignored by the SLB. The VIP Address is the IP address being used by the server farm for the service being registered. It may be specified explicitly by the RS or it may be obtained from the SLB using a Service Address Request Message. If a specific VIP has not been provided or leased by the SLB, separate authentication and security controls can be provided prior to accepting the registration of the server. The Port Number is used by the SLB to support requests for a particular virtual service. This port number shall be configured on the SLB device to provide a port for clients for a given service. This port number is directly associated with the transport protocol being used (e.g., UDP, TCP, or SCTP). This information also allows the SLB to perform health checks on the service if requested by the real server or required based upon policy configured on the SLB. The Transport Protocol corresponds to the value specified by Internet Assigned Numbers Authority (IANA). The information is necessary for the SLB to properly perform health checks when requested and to configure the proper interface. The following is an example. Transport Protocol Value TCP 6 UDP 17 SCTP 132 The Application Protocol defines the protocol used by the VIP and port number. The actual value to be used in the field shall be the port number being used by the application protocol. Additional values may be defined and implemented as desired. Some examples of the application protocol values include: Application Protocol Value HTTP 80 HTTPS 443 DNS 53 FTP 20 Expires - May 2004 [Page 15] Draft SLBRP November 2003 The Health Check field indicates whether the real server would like the SLB to perform health checks on a service. Additional values may be defined and implemented as needed. A Layer3 health check is performed by the SLB through implementation of the ICMP echo request/echo reply protocol. The required values shall be as follows: Health Check Type Value None 0 Layer3 1 HTTP 2 The Health Check Frequency provides the interval between health checks. This indicates the period of health checks performed by the SLB only and not the checks performed by the RS on its own service. Valid values shall be between 1 and 65,535 inclusive. A value of 0 indicates no health check is performed. The default time metric is seconds. The Persistence Type determines if the connections between the clients and any real server should remain the same across multiple connections. Additional values may be defined. The required values shall be: Persistence Type Value None 0 Client Source IP 1 SSL ID 2 The Persistence Time is the time the SLB should maintain persistence data for a particular connection. The default time metric is minutes. The range of values shall be 0 to 255. The use of this field will depend upon the type of persistence being maintained between the real server, SLB, and client. For instance, if cookies are used for persistence this field may not be used. The Scheduling parameter defines the type of scheduling algorithm that should be used by the SLB to support the service. The first real server that defines a unique service not already supported by the SLB defines the scheduling algorithm. Additional real servers supporting the existing service shall use the existing algorithm. Additional values may be added. The required values shall be: Scheduling Option Value Round Robin 1 Least Connections 2 Weighted Round Robin 3 Weighted Least Connections 4 Expires - May 2004 [Page 16] Draft SLBRP November 2003 The Weight parameter defines the weight used by the SLB to distribute the server load within a particular scheduling algorithm. For instance, this field is used to support weighted round robin scheduling. The valid range of weights shall be 1 to 255. If this value is not supported by the SLB, it may scale the value to an appropriate range. The Connection Capacity field defines the maximum connections support by the real server. Once the number of connections for a real server increases beyond the requested connection capacity, the SLB will not balance any more connections to the server until the number of current connections fall below this value. The valid range shall be 0 to 65535. A value of 0 shall indicate that this metric is ignored by the SLB. The Service ID is a unique integer generated by the real server that identifies the service. This value is used within messages to communicate state changes about the service. This value is tracked by the SLB. The service ID must be unique for a given RS and SLB pair. The valid range shall be 0 to 255. This message shall define the ID of the service and shall be used in other messages to identify the particular service. The URL name uniquely qualifies a serviceÆs URL. This information can be used to populate the GSLB database. This name shall be used by the client to obtain the service. It shall be a well-known name that is provided by the real server. Up to 255 ASCII characters may be specified. The scope list is borrowed from Service Location Protocol Version 2, RFC 2608. This is an optional field that provides a list of scope names that defines an administrative group that the service is expecting to support. Network performance monitor agents that have been configured with any of the scopes will monitor the performance of the services. The SLB appliance will forward the service's scope list to these agents as part of the SLB Service Information Response Message. If this field is not part of the message, the scope is considered to be the "DEFAULT" scope. All network performance agents will monitor services with a "DEFAULT" scope, unless otherwise configured. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + VIP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Port Number + Application Protocol + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires - May 2004 [Page 17] Draft SLBRP November 2003 + Transport | Health Check | Health Freq. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Persistence |Persist. Time |Scheduling Type| Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Service ID | Connection Capacity | URL Name Len. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |URL Name. . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Scope Len. | Scope List + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.12 Service Delete Request Message The Service Delete message allows the real server to notify the SLB that it would like the SLB to discontinue supporting the service. The service to be removed by the SLB is identified by its unique Service ID. The Service ID is defined when the service is initially registered. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Service ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.13 Real Server DNS Update Message The Real Server DNS Update message shall be used by the SLB to notify any locally registered DNS server of a new real server or deleted real server. The purpose of the update is to make the real serverÆs host name and unique IP address available to external hosts. The SLB may update the DNS directly using the Dynamic DNS Update protocol as defined in RFC 2136. This is preferred as it eliminates the need for a separate DNS update message. The SLB shall register a fully qualified domain name with the local DNS as described in Section 5.7. Alternatively, a DNS server that has registered with the SLB can be notified of a new real server via its TCP connection to the SLB. The message described below provides this capability. The local DNS server shall then update its database via standardÆs based DNS update messages (e.g., defined by RFC 2136) with information about the server. The locally SLB registered DNS server shall respond with an acknowledgement message to the SLB. The IP address indicates the new real server address and the host name indicates the name of the new real server. The host name may be 1 to 255 characters in length as specified by the Host Name Length field. The Host Active field indicates if the host should be added or deleted from the local DNS. Expires - May 2004 [Page 18] Draft SLBRP November 2003 Host Active field: 0 û host failed or host shutdown 1 û host operational 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Host IP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Host Active | Host Name Len | Host Name . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Up to 255 ASCII characters may be provided for the host name. 5.14 GSLB Service Information Request Message The Service Information Request message shall be sent by the GSLB to the SLB requesting the status of one or more services. The request contains the name of the service or URL. A value of ô*ö indicates an information request for all services currently supported by the SLB. Up to 255 characters may be specified. This message may also be used by the GSLB to request the latest statistics from one or more SLBs. This message may be unicast to a specific SLB or multicast to all SLBs. When the GSLB initially executes, this message shall be multicast to gather the current SLB configuration and status and allow the GSLB to initially populate its database. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + URL Name Len. | URL Name . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.15 SLB Service Information Response Message The Service Information Response message is originated by the SLB to notify the GSLB and other SLBs of new servers that arrive or are removed. This response shall also be used to notify the GSLB of a new SLB joining the network. This message shall be sent in response to the GSLB Service Information Request, periodically at a pre-configured interval (or by Expires - May 2004 [Page 19] Draft SLBRP November 2003 default every 300 seconds), or when the SLB has detected a change in service status. For the periodic update, a jitter timer of 5% of the periodic update time shall be used. Since the periodic message is multicast, other SLB devices and infrastructure devices can register to receive this message. When responding to a Service Information Request from a GSLB, this response shall be unicast to the GSLB. The SLB can be optionally configured to only respond to predefined GSLB devices. When responding to a multicast request, the response shall be multicast. The periodic update shall also be multicast. The periodic multicast update is used to coordinate services between the SLBs and GSLBs. The SLB IP Address specifies the IP address of the sending SLB. This address is used by the GSLB to uniquely identify each SLB. This could be a loopback address on the SLB or a particular interface address. The SLB Score is the score assigned to just the SLB itself and does not include any supported services. The score ranges from 0 to 100, where 0 indicates a completely available SLB and 100 a completely loaded SLB. The purpose is to allow the GSLB to estimate the availability of the SLB itself. The extra 16 bits of filler is not defined and may be used as needed. Its purpose is to increase the efficiency of message parsing. For instance, it could be used to support a password or hashing value to allow authentication of the reporting SLB. The Service Count specifies the number of services/URLs returned by this response. Each service is described by its URL name, VIP address, application protocol, transport protocol, port number, connection type and its score. These fields shall be repeated for each service returned. The VIP Address is the virtual address used to access the service. The Port Number specifies the port number used by the service. The application protocol is defined in Section 5.11. The Transport Protocol corresponds to the value specified by Internet Assigned Numbers Authority (IANA). The information is necessary for the SLB to properly perform health checks when requested and to configure the proper interface. The following is an example. Transport Protocol Value TCP 6 UDP 17 Expires - May 2004 [Page 20] Draft SLBRP November 2003 SCTP 132 The Connection Type specifies if the connection between the RS and SLB is wired or wireless. Connection Type Value Wired 0 Wireless 1 The Service Score is calculated by the SLB for each supported service. The precise method used to calculate the score is left to the implementation. The range is 0 to 100. See section 4.1 for a description of the service score. The URL Name is the text used to reference a specific service. This name is defined when the service registers. Up to 255 ASCII characters may be provided. Each URL name can contain up to 255 characters. The scope list is borrowed from Service Location Protocol Version 2, RFC 2608. This is an optional field that provides a list of scope names that defines an administrative group that the service is expecting to support. Network and server performance monitor agents that have been configured with any of the scopes will monitor the performance of the services. The service's scope list was provided to the SLB appliance by the real server as part of the Service Registration Request Message. If this field is not part of the message, the scope is considered to be the "DEFAULT" scope. All network and server performance agents will monitor services with a "DEFAULT" scope, unless otherwise configured. The scope list can contain up to 255 characters. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + SLB WAN IP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + SLB Score | Reserved | Service Count + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Service VIP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Port Number | Transport | Connect. Type + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Application Protocol | Service Score | URL Name Len + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + URL Name . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires - May 2004 [Page 21] Draft SLBRP November 2003 |Scope Len. | Scope List + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.16 New DNS Notification Message The New DNS Notification message shall be used to notify any locally registered real servers that a new DNS server has attached to the SLB. This message is also used to notify locally registered users when a local DNS has failed or removed itself from the network. This message does not require an acknowledgement. The SLB clients should refresh their DNS configuration by performing a DHCP refresh. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + DNS IP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.17 GSLB DNS Notification Message The GSLB DNS Notification Message informs the global server load balancer of the existence of a DNS and allows the GSLB to associate the DNS with specific network/server performance monitoring agents. If the message is originated by the SLB, the Registered field shall be set to one. Also, this indicates that the second 4 bytes of the message contains the VIP address of the DNS server. In this case, the message shall provide the GSLB with the VIP and real address of a DNS that is registered to the SLB. The message can be generated by a local DNS server that has not registered with a SLB. In this case, the Registered field shall be set to zero. The value of zero in this field indicates that the second four bytes of the message is the IP address of the DNSÆs local SLB and/or local network performance monitoring device. The Active field specifies if the DNS is currently active and should be added to the GSLB or if it should be removed. A value of one indicates active and zero indicates inactive. This message is used by the GSLB to provide intelligent service selection for clients. The local SLB or network performance monitoring device will be providing performance statistics to the GSLB. When a DNS request is received by the GSLB, this message associates the DNS with network performance monitoring device. For a particular DNS, the GSLB will be able to map which SLB or local network performance monitoring device statistics to use to provide an intelligent server selection option. Expires - May 2004 [Page 22] Draft SLBRP November 2003 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + DNS IP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + DNS VIP Address or Local SLB/Performance Monitor Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Active | Registered | Reserved + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.18 Anycast ARP (AARP) Request Message The AARP Request Message shall be used to request address resolution for a VIP address from an SLB. The message can be addressed directly to the SLB or to the VIP address being probed. This message shall request a list of unique IP addresses that identify real servers supporting the requested VIP address, port, transport protocol, and application protocol. The port number helps to identify the service provided. The port number, transport protocol, and application protocol identity are used as filters for this request. A value of 0 within any of these fields indicates a wildcard request. The Transport Protocol corresponds to the value specified by Internet Assigned Numbers Authority (IANA). The following is an example. Transport Protocol Value TCP 6 UDP 17 SCTP 132 The Application Protocol defines the protocol being requested. The actual value to be used in the field shall be the port number being used by the application protocol. Some examples of the application protocol values include Application Protocol Value HTTP 80 HTTPS 443 DNS 53 FTP 20 This message may be sent to either the VIP address or to the WAN address of the SLB. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Expires - May 2004 [Page 23] Draft SLBRP November 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + VIP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Port Number | Application Protocol + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Transport | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.19 Anycast ARP Response Message The AARP Response Message shall be sent by the SLB in response to an address resolution request for a VIP. This message shall contain a list of real servers supporting the VIP/port/transport protocol/application protocol and the serviceÆs score. The Number of VIPs is equal to the number of VIPs reported within the AARP response. The VIP Address is the VIP supported by the SLB. The Service Count indicates the number of services supporting the request. For each service supported by a VIP, the application protocol, port number and transport protocol is provided. Following this information will be the SLB score and the real serverÆs unique IP address. The Score specifies the health score for the real server/service. See section 4.1 for a discussion on the health score. An example of this message is illustrated below 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Number of VIPs| VIP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + VIP ContÆd |Service Count | Application Protocol + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Port Number | Transport Pro | Score + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + RS IP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + VIP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Service Count | Application Protocol | Port Number + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Port # ContÆd | Transport Pro | Score | RS IP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + RS IP Addr ContÆd | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires - May 2004 [Page 24] Draft SLBRP November 2003 5.20 Global Anycast ARP Request Message The Global AARP Request message shall be used to request address resolution for a URL/Service name from the global server load balancer. This message requests a list of SLBs that support a given URL or service name. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + URL Name Len. | URL Name . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.21 Global AARP Response Message The Global AARP Response Message shall be sent in response to a global address resolution request for a URL. This message contains list of SLBs, VIPs, and service scores supporting the URL/service name. The URL name specified shall be the requested name. The name may contain up to 255 ASCII characters. The SLB Count indicates the number of SLBs supporting the URL. It shall define the number of SLB descriptions that follow. Each description shall contain the SLBÆs WAN address, VIP address for the URL, and the SLBÆs score for the service. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + URL Name Len. | URL Name . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + SLB Count | Reserved | Service Score + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + SLB WAN Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + VIP Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. SLBRP Operation with GSLB Support Expires - May 2004 [Page 25] Draft SLBRP November 2003 This section describes the operation of the protocol and its support for GSLB. The following diagram represents a simplified network using the SLB and GSLB system. The system contains two SLBs, each managing two real servers. In addition, each SLB has a local DNS. The DNS functionality at each SLB improves reliability of the system. The SLBs are attached to a Wide Area Network (WAN) that contains one GSLB. The GSLB is configured as authoritative for one or more unique DNS zones. Within the network there is a client and its local DNS looking for a service within a GSLB zone. Physically near the clientÆs DNS is a network/server performance monitoring device. This capability could be a separate appliance or an agent residing on a computer or IP router. The DNS will register with the GSLB and provide the GSLB with the IP address of this local network/server performance monitoring device. This allows the GSLB to associate measurement data from this performance monitoring station with request from the clientÆs DNS. When a client requires a particular service, it asks the local DNS to resolve the URL to a particular IP address. If the service requested is within GSLB DNS zone, the local DNS is configured to forward the DNS request to the GSLB. The GSLB is a DNS server that returns a response that provides an IP address to the ôbestö server available for that particular client. The definition of ôbestö is determined by the GSLB implementation. It may be based on shortest distance, lowest round trip time between the client network and server, least connections, etc. +------+ | DNS 1|--+ +------+ | | | | +------+ | +-----+ |RS 1.1|--+--|SLB 1|---+ +------+ | +-----+ | | | +------+ | | | GSLB | | | +------+ +------+ | | | |RS 1.2|--+ | | +------+ | | +-----+ | | WAN |-------+--------------+ +-----+ | +------+ | +------------+---+--------+ |RS 2.1|--+ | | | | +------+ | | | | | | | | | | Expires - May 2004 [Page 26] Draft SLBRP November 2003 | | +---+----+ +--+--+ +------+-----+ | | | Client | | DNS | |Perf Monitor| +------+ | +-----+ | +--------+ +-----+ +------------+ |RS 2.2|--+--|SLB 2|---+ +------+ | +-----+ | | | +------+ | | DNS 2|--+ +------+ Figure 2. Example Network The GSLB shall maintain a database of statistics that describes each service in its domain. There may be more than one GSLB within a network. The information is gathered by the GSLB(s) from each SLB that has registered. Local network and server performance monitoring agents may be installed to gather information about the network paths, link utilization, round trip times between local networks and key server. By subscribing to receive the SLB Service Information Response the agents can dynamically learn what services can be monitored. Pre-configured scope-lists on network and server performance monitoring agents will permit control over which service an agent should monitor. Access Control Lists can also be defined on the agents to provide additional fine-tuned control of what services are monitored. The agents or devices shall report their service monitoring and measurement findings to the GSLB. The GSLB will record this information and associate the information with the appropriate local DNS servers. Each SLB maintains the responsibility for monitoring its registered real servers. The SLB shall monitor the services provided by each real server and generate a score for each service. This score shall be periodically sent to GSLB and other SLBs using an IP multicast transmission. The GSLB shall use this message to add, delete, or update the service status in its database. In addition, the GSLB may perform a unicast poll to obtain that latest information available for a service from a SLB. Since each SLB informs the GSLB of its presence via a multicast message, a dynamically configuring system is created. As SLB appear within the network, it automatically advertises its services to any GSLB that has connectivity to it. If an SLB gracefully shuts down, it shall inform the GSLB that it is no longer in service and the GSLB shall remove all services supported by the SLB from its database. The GSLB shall also maintain staleness statistics on services and SLBs. If an entry for an SLB is determined to be stale, the GSLB may poll the SLB to obtain the latest information. If the SLB does not respond, the SLB and any Expires - May 2004 [Page 27] Draft SLBRP November 2003 information provided by the SLB shall be removed from the GSLB database. When a real server joins the network, it shall register with an SLB. This registration includes the URL name, VIP address, port number, transport protocol, application protocol, and service scope list. This combination of information uniquely defines the service. The VIP address may be obtained from a pool of addresses maintained by the SLB or specified as a standard IP address. The URL name is a text string up to 255 characters. If the URL is specified as an IP address, the real server shall not participate in global balancing. The service scope list helps to identify which network and server monitoring agents should monitor the particular service. In addition, the registration process shall specify the type of scheduling to use, type of health check to be performed by the SLB, persistence, and connection capacity for this server. To participate in global server load balancing, the VIP address at each SLB for a distributed service must be unique. If the same VIP address is allocated, the client will be provided one VIP address and it shall be up to the network routers to determine the SLB selected. After successfully registering its service, the RS shall begin periodically transmitting a heartbeat to its SLB. This message shall be used to send the results of the RS health check to the SLB and for the SLB to verify the operation of RS. The SLB shall respond with an acknowledgement to verify the operation of the SLB. If there is no acknowledgement, the RS shall drop the current connection and try to establish a new connection with SLB. After successful registration, the SLB shall advertise the new VIP route to the rest of the network. If the VIP is removed from the SLB, it shall also remove the route from the network. The service shall be advertised to the GSLB along with its score. The service shall be removed from the GSLB when there are no longer any real servers providing the service. To support the operation of the real servers that have local DNS capability, the SLB shall notify each real server it manages when a local DNS has attached. This provides a method to dynamically maintain the real serverÆs DNS configuration, thus adding to the plug-and-play capability. In addition to managing SLBs and real servers, this protocol also supports address resolution using the Anycast ARP (AARP) to obtain the unique IP address of a real server for a particular service. Two types of AARPs are supported. The first provides a method to request the real servers supporting a service at a particular SLB. A request can be sent to an SLBÆs WAN address or VIP address to obtain a list of servers that support a VIP, port number, transport protocol and application protocol. Wild cards for the port number and transport protocol may be provided to return a list of all real servers. The Expires - May 2004 [Page 28] Draft SLBRP November 2003 SLB shall send an AARP response message containing the list of real servers meeting the requested criteria. Each real server is described by the IP address, port number, transport protocol, application protocol and service score. The second AARP request can be sent to the GSLB. This AARP requests a list of SLBs that support a particular service/URL. The response shall contain the SLB WAN address, VIP address, and service score. Based on this response, the client shall select an SLB and then issue the previous reference AARP request to obtain a list of real servers. The destination of this AARP can be the SLB IP address. 6.1 Real Server Registration Process The real server announces its presence via the registration process. After successful registration, the SLB shall initiate management of the real server. This must be the first operation performed by the real server. The RS shall issue a Real Server Registration Request to its selected SLB, which is usually its default router, and waits for the Real Server Registration Response. The response shall provide information about the SLBÆs configuration and status of the request. If successful, the real server shall continue. If not, the real server may try again. 6.2 VIP Address Request Each service shall be known via a name and a VIP address. This information can be supplied by the SLB to the GSLB. Based on this information the GSLB can provide a user with one or more suppliers of a service. Each SLB maintains a database of static and dynamic VIP addresses. The VIP address pool and any static entries shall be configurable. The VIP addresses and names provided by to the GSLB should be unique within the zone supported by the GSLB. The real server shall obtain a VIP for a service using this VIP request. The VIP response shall provide the VIP to the real server. If the real server is providing a service that is associated with a static IP address, the real server should not request a VIP address. 6.3 Service Registration After obtaining a VIP address, or using a static VIP address supplied by the real server, the real server shall register the service with the SLB. Each real server may register one or more services. The service registration supplies all the information to configure the SLB. The success of this operation shall be returned via an acknowledgement. Upon successful registration, the SLB shall advertise the VIP by injecting the VIP address into a routing protocol (e.g. OSPF). The SLB shall then route users to this real Expires - May 2004 [Page 29] Draft SLBRP November 2003 server based on the serviceÆs configuration and health. Users can then access the real server using the VIP address. The VIP address and URL are advertised to the Global Server Load Balancer after successful registration. Subsequent registrations by additional real servers for the same service shall use the same VIP address for the service. 6.4 Service Deletion To delete a service from the SLB, a real server shall send the Service Delete message. The SLB shall remove the real server from its supervision. If no more real servers are supporting the VIP, the SLB shall remove the VIP address from its management and informs the GSLB that the service is no longer available from this SLB. 6.5 Shutdown This process informs the SLB, GSLB, or RS that an entity that it is connected to is terminating. For example, if an RS terminates it shall send a shutdown message to its parent SLB. All services supported by this real server shall be removed from the SLB. If no more real servers are supporting the VIP, the SLB shall remove the VIP from its management and informs the GSLB that the service is no longer available from this SLB. If an SLB is terminating, it shall send shutdown messages to its RSs and GSLBs. This provides an orderly shutdown of the system. No responses are required. 6.6 Real Server DNS Update Update the DNS registered with the SLB with information describing a real server also attached to this SLB. This shall provide access to the real servers from other points in the network. When this real server is removed the DNS entry shall also be removed. This may be done using the Dynamic DNS Update Protocol document in RFC 2136. 6.7 DNS Update Inform a real server connected to the SLB that a new DNS service has been added to this SLB. Since the real serverÆs DNS entry has been supplied by DHCP, the real server should renew its IP configuration upon receipt of this message. The real server shall receive a DNS Update Request to initiate the processing. No acknowledgement shall be required. 6.8 Service Update Expires - May 2004 [Page 30] Draft SLBRP November 2003 Inform the GSLB and other SLBs that a new service has been added to an SLB. This shall be a periodic multicast message. As long as the service exists, the SLB shall send the message. If it is no longer supported, the SLB shall send one last message informing the network that the service is no longer provided by the SLB. 6.9 Scope List The scope list is identical to the scope list defined within the Service Location Protocol, Version 2. User defined scopes can be phased into existence based upon the requirements of the network. The scope list is optional. All services that are not configured with a scope are automatically made part of the network's "DEFAULT" scope. All network and server performance monitor agents will monitor servers and services with a default scope unless specifically configured not to. A service can be configured with multiple scopes. Server and network monitor agents can also be configured with multiple scopes. These configured scopes do not have to include the "DEFAULT" scope. 7.0 Protocol Timers The configuration of the protocol timers used will impact the ability to provide the best value. The following timers can be configured by the administrator to optimize performance. Default values are provided to permit a starting point for system optimization. The configuration of these timers must consider the number of SLBs, GSLBs, and services active within the enterprise network. Description Default Timer Value Configurable -------------------------------- ------------------- ------------ Real Server Heartbeat Timer 60 Seconds Yes SLB RS Service Health Check 300 Seconds Yes RS SLB Health Detection 300 Seconds Yes GSLB Service Update Notification 300 Seconds Yes GSLB SLB Health Detection 900 Seconds Yes GSLB Stale Database 60 Seconds Yes VIP Address and Service Hold Time 1200 Seconds Yes Table 3. Protocol Timers 8.0 IPv6 Support To support IPv6 the address fields within the messages exchanged between the RS, SLB, and GSLB must be updated to support the longer Expires - May 2004 [Page 31] Draft SLBRP November 2003 length of these fields. To support IPv6 anycast, the protocol implementation should adhere to the anycast addressing restrictions defined in RFC 3513. IPv6 Anycast addresses used by the protocol must adhere to those reserved by RFC 2526. The DNS servers and GSLB must support IPV6 DNS requirements as documented in RFC 2874 and discussed in RFC 3363. 9.0 Security Considerations Since the system described within this document provides automatic configuration and update of the network infrastructure and environment it is critical to provide a level of security that is equal to the environment being supported. Security constraints include those associated with Dynamic DNS updates and support for anycast services. SLB applications can provide additional security by controlling who can access servers and by monitoring the types of requests delivered to servers. For instance, SLB devices have the potential to detect and help prevent HTTP-based worm proliferation and generic TCP and HTTPS denial of service attacks. Security can be also enhanced through implementation of a variety of well known techniques and best practices. This includes the use of authentication protocols and access control lists to help ensure that only well known trusted servers are allowed to register with the system. Message Digests can be used to help with authentication of messages exchanged between SLBs and GSLBs. The protocol timer configurations must be configured to allow efficient operation without consuming an over abundance of network bandwidth. Reference i Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. ii Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 iii Berners-Lee, Fielding, Masinter, "Uniform Resource Indicators (URI): Generic Syntax", RFC 2396, August 1998 iv Vixie, "DNS Update", RFC 2136, April 1997 v Wellington,"Secure Domain Name System Dynamic Update", RFC 3007, Expires - May 2004 [Page 32] Draft SLBRP November 2003 November 2000 vi Guttman, Perkins, Veizades, Daym "Service Location Protocol, Version 2", RFC 2608 June 1999 vii Droms, " Dynamic Host Configuration Protocol", RFC 1531, October 1993 viii Hinden, Deering, "Internet Protocol Version 6 Addressing Architecture", RFC 3513, April 2003 ix Johnson, Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999 x Crawford, Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000 xi Bush, Durand, Fink, Gudmundsson, Hain, "Representing IPv6 Adresses in the DNS", RFC 3363, August 2002 Acknowledgments We would like to thank The MITRE Corporation for providing support for the development of the Server Load Balancing Registration Protocol. Specifically we would like to thank Beth Loftus, Caleb Wan, Stuart Simpson, Carleton Jillson, and Frank Ruscil for their contributions to this effort. Author's Addresses William Wollman, Harry Jegers The MITRE Corporation 12 Christopher Way Eatontown NJ 07724 Email: wwollman@mitre.org jegers@mitre.org Expires - May 2004 [Page 33]