RserPool Working Group J. Loughney (ed.) INTERNET DRAFT M. Stillman Nokia M. Tuexen Siemens AG Q. Xie Motorola R. Stewart Cisco L. Ong Ciena Expires May 21, 2001 November 21, 2001 Comparison of Protocols for Reliable Server Pooling Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. 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 compares some related protocols, which overlap the Reliable Server Pooling problem space. This document discusses the applicability of these protocols for Reliable Server Pooling. It intends to show why these protocols are not sufficient to accomplish the task of reliable server pooling. Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 Abstract.............................................................1 1 Introduction.......................................................3 1.1 Overview........................................................3 1.2 Terminology.....................................................3 2 Relation to Other Solutions........................................4 2.1 CORBA...........................................................4 2.2 DNS.............................................................5 2.2.1 Requirements.................................................5 2.2.2 Technical Issues.............................................5 2.2.3 Name/Address Resolution......................................7 2.3 Service Location Protocol (SLP..................................8 2.3.1 mSLP.........................................................9 3 Comparison Against Requirements....................................9 4 Security Concerns..................................................10 5 Acknowledgements...................................................10 6 References.........................................................10 7 Authors' Addresses.................................................11 Full Copyright Statement.............................................12 Loughney (editor) [Page 2] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 1 Introduction 1.1 Overview In creating a solution to provide reliable server pools [RSER-ARCH], there are a number of existing protocols, which appear to have similar properties as to what RSerPool is trying to accomplish. This document discusses why these protocols are not sufficient to meet the requirements of Reliable Server Pooling [RSER-REQ]. This study does not intend to be complete, rather intends to highlight several protocols which working group members have suggested. 1.2 Terminology This document uses the following terms: Operation scope - The part of the network visible to pool users by a specific instance of the reliable server pooling protocols. Pool - A collection of servers providing the same application functionality. Also called a Server Pool. Pool handle - A logical pointer to a pool. Each server pool will be identifiable in the operation scope of the system by a unique pool handle or "name". Also called a Pool Name. Pool element - A server entity having registered to a pool. Pool User - A server pool user. Pool Element Handle - A logical pointer to a particular pool element in a pool, consisting of the name of the pool and a destination transport address of the pool element. Also called an Endpoint Handle. Name Space - A cohesive structure of pool names and relations that may be queried by an internal or external agent. Name Server - Entity which the responsible for managing and maintaining the name space within the RSerPool operation scope. 1.3 Abbreviations DA: Directory Agent in SLP. Loughney (editor) [Page 3] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 DPE: Distributed Processing Environment CORBA: Common Object Request Broker Architecture. OMG: Object Management Group PE: Pool element PU: Pool user SA: Service Agent in SLP. SLP: Service Location Protocol. UA: User Agent in SLP. 2 Relation to Other Solutions This section is intended to discuss the applicability of some existing solutions with regards to Reliable Server Pooling requirements [RSER-REQ]. The protocols discussed have been suggested as possibly overlapping with the problems space of RSerPool. 2.1 CORBA Often referred to as a Distributed Processing Environment (DPE), CORBA was mainly designed to provide location transparency for distributed applications. However, the following limitations may exist when applying CORBA to the design of real time fault-tolerant system: CORBA has not been focused on high availability. The recent development of a high availability version of CORBA by OMG may be a step in the right direction towards improving this situation. Nevertheless, the maturity, implementability, and real-time performance of the design is yet to be proven. CORBA's distribution model encourages an object-based view, i.e., each communication endpoint is normally an object. This level of granularity is likely to be somewhat inefficient for designing real- time fault-tolerant applications. CORBA, in general, has a large signature that makes the use of it a challenge in real-time environments. Small devices with limited memory and CPU resource (e.g., H.323 or SIP terminals) will find CORBA hard to fit in. CORBA has lacked easily usable support for the asynchronous communication model, and this may be an issue in many applications. An improved API for asynchronous communication has been added to the CORBA standards recently, but many, if not most, CORBA Loughney (editor) [Page 4] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 implementations do not yet support it. There is as yet insufficient user experience with it to make conclusions regarding this feature's usability. 2.2 DNS This section will answer the question why DNS is not appropriate as the sole solution for RSerPool. In addition, it highlights specific technical differences between RSerPool and DNS. During the 49th IETF December 13, 2000 plenary meeting Randy Bush presented a talk entitled "The DNS Today: Are we overloading the Saddlebags on an Old Horse?" This talk underlined the issue that DNS is currently overloaded with extraneous tasks and has the potential to break down entirely due to a growing number of feature enhancements. One requirement to any solution proposed by RSerPool would be to avoid any additional requirements for DNS in order to support Reliable Server Pooling. Interworking between DNS and RSerPool will be considered so that additional burdens to DNS will not be added. 2.2.1 Requirements Any solution for RSerPool should meet certain requirements [RSER- REQ]. These requirements are related to DNS. Servers should be able to register to (become PEs) and deregister from a server pool transparently without an interruption in service. The RSerPool mechanisms must be able to support different server selection mechanisms. These are called server pool policies. The RSerPool architecture must be able to detect server failure quickly and be able to perform failover without service interruption. Server pools are identified by pool handles. These pool handles are only valid inside the operation scope. Interoperability between different namespaces has to be provided by other mechanisms. 2.2.2 Technical Issues This section discusses the relationship between DNS and the requirements for RserPool. 2.2.2.1 Host Resolver Problems A major issue that prevents the use of DNS as part of the RSerPool solution the issue is the architecture of host resolvers. These are Loughney (editor) [Page 5] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 stub resolvers - which means that they require their local DNS servers to do recursion for them. In turn, this implies that setting TTL low or 0 will dramatically increase the load not only on the authoritative DNS servers - but also on these third party servers. A secondary effect of this is that the authoritative DNS will not know the IP address of the DNS client - only the IP address of the local DNS. This affects the ability to do global load balancing correctly. There is no way to get around these issues unless you all hosts would be full resolvers. Putting full resolvers on newer hosts isn't sufficient because the issues would still exist for all the legacy systems, which will form the bulk of the host population for years to come. The solution is not to use third party servers. Additionally, if the client can contact the server directly, then the server knows the real IP address of the client. Since there is no third party involved, the caching TTL can be set as low as desired (even to zero). That will increase load on the server, but nowhere else. Finally, DNS is based on a recursion. This recursion presents certain difficulties for RSerPool. Even if a host resolver is not a stub resolver, it has to go to another full resolver where 2 possibilities exists: either the mapping name-IP address is found or it has to do another recursive resolution of the name, staring from that intermediate resolver, until there is a cache hit in one of the intermediate resolvers or it is resolved by its root resolver (or home DNS server). This process of recursion means that there is no end-to-end communication between the host and its server where the name-to-IP mapping resides. That also means that a lot of timers are running in intermediate systems. Any updating of the transient status of the pool element or of the pool may need to be propagated through the DNS. 2.2.2.2 Dynamic Registration Registration / de-registration of servers is needed. It can be done with DNS by NOTIFY/IXFR. However, frequent updates and replication are incompatible. This is not a DNS problem per se, but it has an effect on DNS as it is deployed. RSerPool MUST allow software server entities to register themselves with a name server dynamically. They can also de-register themselves for purposes of preventative maintenance or can be de-registered by a name server that believes the server entity is no longer Loughney (editor) [Page 6] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 operational. This is a dynamic approach, which is coordinated through servers in the pool and among RSerPool name servers. 2.2.2.3 Load Balancing RFC 2782 itself points out some of the limitations of using DNS SRV for load balancing between servers. Weight is only intended for static, not dynamic, server selection. Using SRV weight for dynamic server selection would require assigning unreasonably short TTLs to the SRV RRs, which would limit the usefulness of the DNS caching mechanism, thus increasing overall network load and decreasing overall reliability. Based on this, DNS can only really support stochastic load balancing, redirecting clients to servers randomly as various caches in various resolvers expire at random (although small) intervals. DNS offers excellent network scalability but poor control over load balance. As mentioned previously, the issue of doing DNS-based dynamic load balancing on short time scales will have impacts on third parties, due to the presence of stub resolvers. 2.2.2.4 Heartbeating / Status Monitoring DNS does not incorporate an application layer heartbeat. Heartbeating would dramatically boost traffic levels, and given the unavoidable third party dependencies of DNS, the resulting loading would be unacceptable. It is passive in the sense that it does not monitor or store information on the state of the host such as whether the host is up or down or what kind of load it is currently experiencing. RSerPool SHOULD monitor the state of each server entity on various hosts on a continual basis and can collect several state variables including up/down state and current load. If a server is no longer operational, eventually it will be dropped from the list of available servers maintained by the name server, so that subsequent application name queries will not resolve to this server address. 2.2.3 Name/Address Resolution The technical requirement for DNS name/address resolution is that given a name, find a host associated with this name and return its IP address(es). In other words, in DNS we have the following mapping: Name a host machine Loughney (editor) [Page 7] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 Address(es) IP address(es) to reach a (hardware) host machine The technical requirement for RSerPool name/address resolution is that given a name (or pool handle), find a server pool associated with this name and return a list of transport addresses (i.e., IP addresses plus port numbers) for reaching a set of currently operational servers inside the pool. In other words, in RSerPool we have the following mapping: Name a handle to a server pool, which is often distributed across multiple host machines Address IP addresses and port numbers to reach a set of functionally identical (software) server entities. 2.3 Service Location Protocol (SLP SLP is comprised of three components: User Agents (UA), Service Agents (SA) and Directory Agents (DA). User agents work on the user's behalf to contact a service. The UA retrieves service information from service agents or directory agents. A service agent works on behalf of one or more services to advertise services. A directory agent collects service advertisements. The directory agent of SLP functions simply acts as a cache and is passive in this regard. The directory agent is optional and SLP can function without it. It is incumbent upon the servers to update the cache as necessary by reregistering. The directory server is not required in small networks as the user agents can contact service agents directly using multicast. Unicast queries to SAs are possible subsequent to the UA having discovered them. User agents are encouraged to locate a directory at regular intervals if they can't find one initially, otherwise they can detect DAs by listening passively for DA advertisements. The most fundamental difference between SLP and RSerPool is that SLP is service-oriented while RSerPool is communication-oriented. More specifically, what SLP provides to its user is a mapping function from a name of a service to the location of the service provider, in the form of a URL string. The availability of the service provider is outside of the scope of SLP. How a service is accessable can be described by the SLP attribute list associated with the service URL. SLP is essentially a discovery protocol, not a transport protocol. Therefore, the granularity of SLP operation is at application service level. In contrast, RSerPool provides to its user is a mapping function from a communication destination name to a set of routable and reachable transport addresses that leads to a group of distributed software server entities registered under that name that collectively represent the named communication destination. With respect to SLP, this information could be represented in SLP Loughney (editor) [Page 8] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 attributes. RserPool, however, also has the responsibility of reliably delivering a user message to one of these server entities. What service(s) a group of servers are providing at the application level or whether the group is just a component of an application service provider is out of the scope of RSerPool. In other words, the granularity of RSerPool operation is at communication server entity level. Moreover, RSerPool requires a distributed fault-tolerance and real- time translation services. SLP does not state either of these as design requirements and thus does not attempt to fulfill them. In addition, SLP defines optional security features, which support authentication and integrity. SLP requires IPSec to fully meet the Security Requirements of RserPool. The SLP directory agent does not support fault tolerance or robustness in contrast to the name servers, which do support it. The name servers also monitor the state of the servers, which are registered in the pool, but the SLP directory agents do not perform this function. SLP relies on multicast for some functionality and in RSerPool multicast is optional. In summary, SLP meets some of the requirements needed for the name service portion of RSerPool, but would require modifications to fully support the requirements for the name service. SLP does not address the transport of user messages. 2.3.1 mSLP SLP alone does not fulfill RSERPOOL update requirements for timeliness. This is achieved through mesh-enhancements to the Service Location Protocol (mSLP) [MSLP]. These enhancements make it possible for SAs to know of only a subset of all DAs. Mesh-enhanced SAs need only forward their registrations to only one mesh-enhanced DA. The mesh takes care of forwarding the message to the other DAs. 3 Comparison Against Requirements This section attempts to create a comparison table to compare the protocols which have been suggested as applicable to the RserPool architecture. Loughney (editor) [Page 9] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 | CORBA | DNS | SLP | ASAP | ENRP | -----------------------------+-------+-----+-----+------+------+ Robustness | Y | Y | Y | Y | Y | -----------------------------+-------+-----+-----+------+------+ Failover Support | Y | P | P | Y | Y | -----------------------------+-------+-----+-----+------+------+ Communication Model | N | P | Y | Y | Y | -----------------------------+-------+-----+-----+------+------+ Processing Power | N | Y | Y | Y | Y | -----------------------------+-------+-----+-----+------+------+ Support of RSerPool | N | Y | N | N | N | Unaware Clients | | | | | | -----------------------------+-------+-----+-----+------+------+ Registering and | N | P | P | Y | Y | Deregistering | | | | | | -----------------------------+-------+-----+-----+------+------+ Naming | Y | Y | Y | Y | Y | -----------------------------+-------+-----+-----+------+------+ Name Resolution only to | Y | N | Y | Y | Y | Active Elements | | | | | | -----------------------------+-------+-----+-----+------+------+ Server Selection Policies | Y | P | P | P | P | -----------------------------+-------+-----+-----+------+------+ Timing Requirements and | N | N | Y | Y | Y | Scaling | | | | | | -----------------------------+-------+-----+-----+------+------+ Scalability | N | Y | Y | Y | Y | -----------------------------+-------+-----+-----+------+------+ Security - General | N | P | P | P | P | -----------------------------+-------+-----+-----+------+------+ Security - Name Space | N | P | P | P | P | Services | | | | | | -----------------------------+-------+-----+-----+------+------+ Y = Yes, meets requirement P = Partially meets requirement N = No, does not meet requirement N/A = Not applicable 4 Security Concerns This type of non-protocol document does not directly affect the security of the Internet. 5 Acknowledgements The authors would like to thank Bernard Aboba, Erik Guttman, Matt Holdrege, Christopher Ross and Werner Vogels for their invaluable comments and suggestions. 6 References Loughney (editor) [Page 10] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 [ASAP] Xie, Q, Stewart, R. R., "Aggregate Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-00.txt, June, 2001. A work in progress. [ENRP] Xie, Q, Stewart, R. R., "Endpoint Name Resolution Protocol (ENRP)", draft-ietf-rserpool-enrp-00.txt, June, 2001. A work inprogress. [MSLP] Zhao, W., "mSLP - Mesh-enhanced Service Location Protocol", draft-zhao-slp-da-interaction-12.txt, July, 2001. A work in progress. [RSER-ARCH] Tuexen, M. et al., "Requirements for Reliable Server Pooling" , Work in Progress, April 2001. [RSER-REQ] Tuexen, M. et al., "Requirements for Reliable Server Pooling" , Work in Progress, May 2001. [RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, September 1981. [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", RFC 959, October 1985. [RFC2026] S. Bradner, "The Internet Standards Process - Revision 3", RFC 2026, October 1996. [RFC2608] E. Guttman et al., "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC2719] L. Ong et al., "Framework Architecture for Signaling Transport", RFC 2719, October 1999. [RFC2782] A. Gulbrandsen et al., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2960] R. R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960, November 2000. 7 Authors' Addresses John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland Email: john.loughney@nokia.com Maureen Stillman Loughney (editor) [Page 11] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 Nokia 127 W. State Street Ithaca, NY 14850 USA Email: maureen.stillman@nokia.com Michael Tuexen Siemens AG ICN WN CS SE 51 D-81359 Munich Germany Email: Michael.Tuexen@icn.siemens.de Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, Il 60004 USA Email: qxie1@email.mot.com Randall Stewart Cisco Systems, Inc. 24 Burning Bush Trail Crystal Lake, Il 60012 USA Email: rrs@cisco.com Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014 USA Email: lyong@ciena.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Loughney (editor) [Page 12] Internet-Draft Comparison of Protocols for RSerPool Nov 21, 2001 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Loughney (editor) [Page 13]