Network Working Group P. Conrad Internet-Draft Temple University Expires: November 24, 2002 P. Lei Cisco Systems, Inc. May 26, 2002 Services Provided By Reliable Server Pooling draft-conrad-rserpool-service-01.txt 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. This Internet-Draft will expire on November 24, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract RSerPool [1] is a framework to provide highly available services between clients and servers. This is achieved by grouping servers into pools, each with an identifier and pooling policy. Three classes of entities are defined: Pool Users (clients), Pool Elements (servers), and Name Servers. This memo defines the services provided by this framework to upper layer protocols and applications for Pool Users and Pool Elements. It describes two modes in which RSerPool can provide these services: nameservice mode, and failover mode. Conrad & Lei Expires November 24, 2002 [Page 1] Internet-Draft Services Provided by RSerPool May 2002 It also describes the framework by which upper layer protocols using a variety of transports (SCTP, TCP, UDP, or others) can be mapped onto the RSerPool framework. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . 5 3. Application Scenarios . . . . . . . . . . . . . . . . . . . 5 3.1 Example Scenario for Failover without RSerPool . . . . . . . 5 3.2 Example Scenario for RSerPool Nameservice Mode . . . . . . . 6 3.3 Example Scenario for RSerPool Failover Mode . . . . . . . . 7 4. Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Nameservice Mode . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Nameservice Pool User Service Primitives . . . . . . . . . . 9 5.2 Nameservice Pool Element Service Primitives . . . . . . . . 9 5.3 TBD items . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Failover Mode . . . . . . . . . . . . . . . . . . . . . . . 10 6.1 Mapping Transport Protocols to RSerPool Failover Mode Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1.1 Failover Mode Mapping: Mandatory Requirements . . . . . . . 11 6.1.2 Failover Mode Mapping: Optional Requirements . . . . . . . . 12 6.1.3 Failover Mode Mapping: Other Requirements . . . . . . . . . 12 6.2 Failover Service . . . . . . . . . . . . . . . . . . . . . . 12 6.3 Failover Callback Function . . . . . . . . . . . . . . . . . 13 6.4 Failover Service Primitives . . . . . . . . . . . . . . . . 14 6.4.1 Failover Pool User Service Primitives . . . . . . . . . . . 14 6.4.2 Failover Pool Element Service Primitives . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 Conrad & Lei Expires November 24, 2002 [Page 2] Internet-Draft Services Provided by RSerPool May 2002 1. Introduction The Reliable Server Pooling architecture is defined in [1]. The architecture provides highly available services by defining three classes of entities: pool users (clients), pool elements (servers), and name servers. Pool elements are grouped into server pools and can be used by pool users via its pool name (pool handle) and following a specific pool selection policy. This memo describes how an upper layer protocol or application for a pool user or pool element uses this architecture and associated protocols to achieve these goals described in that document. Specifically, it describes how the ASAP protocol [7] and transport protocols (SCTP, TCP, UDP, etc) can be utilized to realize highly available services between pool users and pool elements. There are tradeoffs between the amount of application modification required, the features and restrictions that the underlying transport is required to support, and the richness of the feature set provided by RSerPool. In order to provide support for both existing/legacy (non-RSerPool) and new applications, two modes are defined in which an upper layer protocol can interact with the RSerPool framework: "nameservice mode", offering a limited subset of RSerPool services, and "failover mode" offering the full set of RSerPool services. Nameservice mode provides the capability for legacy upper layer software to use RSerPool services with relatively minor modifications, and allows a broad range of underlying transport protocols to be supported. However, in nameservice mode, a limited set of RSerPool services is provided. Failover mode requires more substantial modifications to the upper layer software and places certain requirements and restrictions on the transport layers that can be supported. However, in failover mode, the complete set of RSerPool services is provided. Note that both modes are expected to operate over the full RSerPool framework and are defined only to operate over full implementations of the RSerPool protocols. This document assumes that the upper layer protocol/ application is operating on a platform that has a full implmentation of ASAP. In particular, though nameservice mode requires only a "subset" of the features of the ASAP protocol at the application/upper layer, it MUST be implemented over a full implmentation of ASAP. The following figure illustrates the protocol stacks when operating in failover mode (note that data exchange and transfer is performed via the ASAP API): Conrad & Lei Expires November 24, 2002 [Page 3] Internet-Draft Services Provided by RSerPool May 2002 +--------------------------------------+ | Application/Upper Layer Protocol | +--------------------------------------+ | ASAP API | | (PE selection) (data exchange) | +-----------------+--------------------+ | ASAP protocol | | +-----------------+ | | shim layer | +--------------------------------------+ | ASAP transport protocol | +--------------------------------------+ Similarly, the following figure illustrates the protocol stacks when operating in nameservice mode: +--------------------------------------+ | Application/Upper Layer Protocol | +--------------------------------------+ | ASAP API | Alternate API | | (PE selection) | (data exchange) | +-----------------+ | | ASAP protocol | | +-----------------+--------------------+ | shim layer | Alternate | +-----------------+ transport | | ASAP transport | protocol | | protocol | | +-----------------+--------------------+ [OPEN TBD: as part of the transition mechanism, the ASAP "send by transport address" API could be recommended as well.] The purpose of this document is to describe: 1. the precise services provided by RSerPool to the upper layer in both nameservice and failover mode, 2. the tradeoffs in choosing between these two modes of service, 3. how applications must be designed for each of these modes, 4. how applications written over various transports (SCTP, TCP, UDP, and others) can be mapped into these two modes. Conrad & Lei Expires November 24, 2002 [Page 4] Internet-Draft Services Provided by RSerPool May 2002 2. Conventions Used In This Document 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 [2]. 3. Application Scenarios To illustrate the differences among an application without RSerPool, an application using RSerPool in "nameservice mode", and an application using RSerPool in "failover mode", this section provides an informal description of how failover may be handled in each of these cases. This section is intended only as non-normative introductory material; the formal normative definition of these modes appears in Section 5 and Section 6. 3.1 Example Scenario for Failover without RSerPool Consider a typical client/server application that does not use a reliable server pooling framework of any kind. Typically, the server is specified by a DNS name. At some point, the application translates this name to an IP address (via DNS), and subsequently makes initial contact with the server to begin a session, via SCTP, TCP, UDP, or some other protocol. If the client loses contact or fails to make contact with the server (either due to server failure, or a failure in the network) the client must either abandon the session, or try to contact another server. In this scenario, the client must first determine that a failure took place. There are several ways that a client application may determine that a server failed, including the following: 1. The client may have sent a request to the server, and may time out waiting for a response, or may receive a message such as "no route to host", "port not available", or "connection refused". 2. The client may have sent a request to the server, or may have tried to initiate a connection or association and may have received a connection/association failure error. 3. The client may already have established a connection to server, but at some point receives an indication from the transport layer that the connection failed. Suppose that the client application has a feature by which the user can enter the hostname of a secondary server to contact in the event of failure. Once the application determines that a failure took place on the primary server, the application can then attempt to Conrad & Lei Expires November 24, 2002 [Page 5] Internet-Draft Services Provided by RSerPool May 2002 resolve the hostname of the secondary server, and contact the secondary server to establish a session there. This process can be iterated to a tertiary server, and so forth. A limitation of this model is that there is no provision (other than static client configuration, plus the capabilities of DNS) to determine which server to contact initially (other than DNS) or which server to contact next in the event of server failure. (See [3] for a discussion of the limitations of using DNS for this purpose.) 3.2 Example Scenario for RSerPool Nameservice Mode Now consider the same client/server application mentioned in Section 3.1. First we describe what the application programmer must do to modify the code to use the RSerPool nameservice mode. We then describe the benefits that these modifications provide. For pool user ("client") applications, there are typically only three modifications are required along with adding ASAP: 1. Instead of specifying the hostnames of primary, secondary, tertiary servers, etc., the application user specifies a pool handle (or pool name). 2. Instead of using a DNS based service (e.g. the Unix library function gethostbyname()) to translate from a hostname to an IP address, the application will invoke an RSerPool service primitive "IPAddressOfPrimaryServer" that takes as input a pool handle, and returns the IP address of the primary server. The application then uses that IP address just as it would have used the IP address returned by the DNS in the previous scenario. 3. In nameservice mode, failure detection is application specific just as in the previous scenario. However, when failure is detected on the primary server, instead of invoking DNS translation again on the hostname of a secondary server, the application invokes the service primitive "IPAddressOfNextServer", which has a dual meaning. First it indicates to the RSerPool layer the failure of the server returned by a previous "IPAddressOfPrimaryServer" or "IPAddressOfNextServer" call. Second, it provides the IP address of the next server that should be contacted, according to the best information available to the RSerPool layer at the present time. For pool element ("server") applications, two additions in are required along with adding ASAP: Conrad & Lei Expires November 24, 2002 [Page 6] Internet-Draft Services Provided by RSerPool May 2002 1. The server should invoke the REGISTER service primitive upon startup to add itself into the server pool using an appropriate pool handle. This also includes the address(es) protocol or mapping id, port (if required by the mapping), and pooling policy(s). 2. The server should invoke the DEREGISTER service primitive to remove itself from the server pool when shutting down. When using RSerPool service in this mode, RSerPool provides benefits that are limited (as compared to failover mode, described in Section 3.3), but nevertheless quite useful as compared to not using RSerPool at all (as in Section 3.1). First, the client user need only supply a single string, i.e. the pool handle, rather than a list of servers. Second, the decision as to which server is to be used can be determined dynamically by the server selection mechanism (i.e. a "pool policy" performed by ASAP; see [1]). Finally, when failures occur, these are reported to the pool via signaling present in ASAP [7]) and ENRP [6], other clients will eventually know (once this failure is confirmed by other elements of the RSerPool architecture) that this server has failed. Nameservice mode is most useful for applications built over connectionless protocols such as UDP that cannot easily be adapted to the transport layer requirements for RSerPool failover mode (see section Section 6.1) or for an expedient way to provide some of the benefits of RSerPool to legacy applications (regardless of the transport protocol used). However, to take full advantage of the RSerPool framework, the failover mode described in the next section is recommended. 3.3 Example Scenario for RSerPool Failover Mode Finally, consider the same client/server application as in Section 3.1, but this time, modified to use RSerPool in failover mode. As in the Section 3.2, we first describe the modifications needed, then we describe the benefits provided. When the RSerPool failover mode is used, all communication between the client and the server is mediated by the RSerPool layer, including not only session establishment and teardown, but also the sending and receiving of data. Thus, to use failover mode, it is necessary to modify the application to use the service primitives (i.e. the API) provided by RSerPool, rather than the transport layer primitives provided by UDP, TCP, SCTP, or whatever transport protocol is being used. The RSerPool abstract transport layer interface provides features Conrad & Lei Expires November 24, 2002 [Page 7] Internet-Draft Services Provided by RSerPool May 2002 similar to those provided by the transport layer protocol SCTP, with the following differences: 1. Sessions (rather than connections or associations) are established, and the destination endpoint is specified as a pool handle rather than as a list of IP addresses with a port number. 2. Failover from one server to another is automatic, and can be transparent to the application. The application can provide a callback function (described in Section 6.3) that is invoked in the case of a failover. This callback function can execute any application specific failover code, such as generating a special message (or sequence of messages) that helps the new server construct any state needed to continue an in-process session. Retrofitting an existing application to this mode of RSerPool requires significantly more effort on the part of the application programmer than retrofitting an application to use nameservice mode, since all use of the transport layer's primitives (e.g. the calls to the sockets API) must be modified to use the RSerPool primitives (e.g. the RSerPool API). This can be mitigated by making the API for RSerPool as close to existing transport APIs as possible. However, the benefits provided by RSerPool in this mode exceed those of nameservice mode, since failure detection and failover is automated in this mode. Furthermore, since the primitives provided by RSerPool are similar to those of existing transport protocols (and, it is hoped, the APIs will be also) for developers of new applications, writing to the RSerPool failover mode primitives is not significantly different in terms of programmer effort or learning curve than writing the same applications over existing transport layer primitives. 4. Mappings In order to support the RSerPool framework (nameservice and failover modes) over a variety of transport protocols and configurations, several mappings are defined to provide RSerPool services over a given transport protocol. Each mapping, or "adaption layer" or "shim layer", translates the requirements of the RSerPool framework onto the capabilities of the transport protocol desired (e.g. SCTP, TCP, UDP, etc.). Initially, three mappings are defined: NO_MAPPING (0x00): Nameservice mode. With this mapping, the application specific communication between a pool user and the pool element is out of scope of RSerPool. However, pool elements can register the application specific communication "protocol" and "port", and thus can be provided to pool users. See Section 5 for Conrad & Lei Expires November 24, 2002 [Page 8] Internet-Draft Services Provided by RSerPool May 2002 details. SCTP (0x01): Failover mode, using SCTP transport for services. This is the preferred mapping for failover mode. TCP (0x02): Failover mode, using TCP transport for services See Section 6.1 for details on failover mode mappings. A particular pool element might support any combination of these mappings in order to support a variety of pool users with different capabilities (i.e. different mapping support). In this case, pool elements should register each mapping that it supports with its pool(s). 5. Nameservice Mode In this section, the service primitives provided by RSerPool when operating in nameservice mode are described. [Open Issue TBD: Describe this perhaps using notation similar to that used in Section 10 of RFC2960.] 5.1 Nameservice Pool User Service Primitives For the Pool User ("client"): "IPAddressOfPrimaryServer", that takes as input a pool handle and returns the IP address of the primary server. "IPAddressOfNextServer", which has a dual meaning. First it indicates to the RSerPool layer the failure of the server returned by a previous "IPAddressOfPrimaryServer" or "IPAddressOfNextServer" call. Second, it provides the IP address of the next server that should be contacted, according to the best information available to the RSerPool layer at the present time. The appropriate pool policy for server selection for the pool should be used for selecting the next server. [OPEN TBD: should this be described as allowing the PU to ask for the next server and get {IP address, transport protocol, and transport protocol port} rather than just {IP address}] 5.2 Nameservice Pool Element Service Primitives For the Pool Element ("server"): REGISTER, to add the pool element into a server pool using {pool Conrad & Lei Expires November 24, 2002 [Page 9] Internet-Draft Services Provided by RSerPool May 2002 handle, mapping mode, protocol or mapping id, port, policy info} where mapping mode is NO_MAPPING, which is nameservice mode. A response result code is returned. DEREGISTER, to remove the pool element from a server pool using {pool handle, mapping mode, protocol or mapping id, port, policy info} where mapping mode is NO_MAPPING, which is nameservice mode. A response result code is returned. TBD: if REGISTER also returns an opaque instance id, the application can just use that id for DEREGISTER, instead of passing in the (same) parameters used in REGISTER. 5.3 TBD items Some of the details to note include the following: If the RSerPool implementation on a particular endpoint supports multiple server selection algorithms (pool policies) how does the application indicate which one should be used? (This is probably in the primitive for a PE to register itself.) In nameservice mode, do we want to just have the application supply a callback function that will be given an unsorted list of policy values, and return a sorted list of policy values, so that the application can implement its own server selection algorithm by a callback function? When the application invokes "IPAddressOfNextServer", should the application be able to (optionally) signal to the RSerPool layer that it wants the ASAP entity to recontact the name server to refresh its list of servers before responding with a next server? Or do we always just go with whatever information is most current in the ASAP layer at that moment in time? 6. Failover Mode This section describes the details of the service provided by RSerPool in failover mode. Section 6.1 describes the way in which various transport protocols (SCTP, TCP, etc.) are mapped onto the requirements for failover mode. Section 6.2 describes the service provided by RSerPool to the application in failover mode. 6.1 Mapping Transport Protocols to RSerPool Failover Mode Requirements While SCTP is the preferred transport layer protocol for applications Conrad & Lei Expires November 24, 2002 [Page 10] Internet-Draft Services Provided by RSerPool May 2002 built for RSerPool failover mode (for reasons explained shortly), it is also possible to use other transport protocols as well (e.g. TCP) if an SCTP implementation is not available on the client and/or server. However, there are certain features present in SCTP that are required if the RSerPool framework is to function in failover mode. When a transport protocol other than SCTP is used, these features must be provided by an "adaptation layer" (also called a "shim protocol") that sits between the base transport protocol (e.g. TCP), and the RSerPool layer. Following the nomenclature used in the BEEP framework (RFC3080: [4] and RFC3081 [5]) we refer to these "adaptation layers" or "shim protocols" as "mappings"; the idea is that the requirements of the RSerPool framework are "mapped" onto the capabilities of the underlying protocol (e.g., SCTP or TCP). This section describes why such mappings are needed, and how they are constructed. The original motivation for providing mappings was to allow client/ server protocols built over TCP to take advantage of the RSerPool framework, not just those built over SCTP. Therefore, we begin by listing features crucial to RSerPool failover mode that are present in SCTP, but lacking in TCP. Note that the mapping architecture that results can be used to extend the benefits of RSerPool to protocols other than TCP as well; TCP is used only for illustrative purposes. 6.1.1 Failover Mode Mapping: Mandatory Requirements These features MUST be present in any mapping of RSerPool failover mode requirements to TCP (or any other transport protocol): 1. Message orientation, which facilitates application re- synchronization during failover. Messages must be "framed" in order to allow for undelivered message retrieval. 2. A heartbeat mechanism to monitor the health of an association or connection. 3. A retrieval mechanism to allow an application to retrieve unsent or unacknowledged data upon failover. 4. [Open issue TBD: Are there others to be included here?] 5. [Open TBD: should we also list the basic requirements that SCTP/ TCP have that UDP doesn't (reliable transfer, congestion control, etc); e.g. or recommend against mapping over UDP?] Conrad & Lei Expires November 24, 2002 [Page 11] Internet-Draft Services Provided by RSerPool May 2002 6.1.2 Failover Mode Mapping: Optional Requirements There are several additional features that are lacking in TCP and present in SCTP. While these features are not crucial to RSerPool, providing them in the mapping layer makes it easier for an application layer programmer to write to a single API. This single API can then be mapped over both SCTP and TCP, as well as any other transport protocol for which a mapping is provided. Since these features are not essential for RSerPool, they are optional in any transport layer mapping. However, appropriate error messages or indications that these features are not available should be provided. These features include: 1. Support for multiple streams 2. Support for unordered delivery of messages 3. [Open issue TBD: Are there others to be included here?] 6.1.3 Failover Mode Mapping: Other Requirements There are some features of SCTP that a mapping document may not be able to provide, because they would require access to transport layer internals, or modifications in the transport layer itself. The service provided by the RSerPool layer to the application should therefore provide mechanisms for the upper layer to access these features when present (e.g. in SCTP), but also provide appropriate error messages or indications that these features are not available when they cannot be provided. These feature include: 1. Application access to the RTT and RTO estimates 2. Application access to the Path MTU value 3. [Open issue TBD: Are there others to be included here?] 6.2 Failover Service [Open issue TBD: In this section, describe the service provided by RSerPool to the application in failover mode. In particular, describe:] o Describe how a new pool element is selected, and a new transport layer connection/association is established. o Describe how failures are detected: send failures, heartbeats Conrad & Lei Expires November 24, 2002 [Page 12] Internet-Draft Services Provided by RSerPool May 2002 o Describe how an alternate server is selected after failure o Describe how retrieval is used to retrieve unsent/unacked messages and forward them on to the new server o Note that state synchronization is out of scope of RSerPool o Any other salient points "in general" about how failover works from the perspective of interactions with the application above, or with the transport layer below. 6.3 Failover Callback Function The charter of the RSerPool Working Group specifically states that transaction failover is out of scope for RSerPool, i.e. "if a server fails during processing of a transaction this transaction may be lost. Some services may provide a way to handle the failure, but this is not guaranteed." Accordingly, failover mode provides a "hook" for applications to provide their own application-specific failover mechanism. Specifically, an application using RSerPool in failover mode can specify a callback function that is invoked whenever a failover has taken place. This callback function is invoked immediately after the new transport layer connection/association is established with a new server, and gives the application the opportunity to send one or more messages that may help the server to resume any transaction or session that was in progress when the first server failed. As a simple example of how such a callback is useful, consider a file transfer service built using RSerPool. Let us assume that some FTP mirroring software is used to maintain mirrored sites, and that the actual mirroring is out of scope. However, we would like to use RSerPool to select a server from among the available mirror sites, and to failover in the middle of a file transfer if a primary server fails. For this example, assume that a simple request/response protocol is used, where one request message results in one or more response messages. Each request message contains the filename, and the offset desired within the file, (default zero.) Each response message contains some portion of the file, along with the offset, length of the portion in this message, and the length of the entire file. A single request results is sufficient to result in a sequence of response messages from the requested offset to the end of the file. For simplicity, assume that the response messages are delivered by Conrad & Lei Expires November 24, 2002 [Page 13] Internet-Draft Services Provided by RSerPool May 2002 the underlying transport strictly in order (although this requirement could be relaxed if a small amount of extra complexity were introduced.) In this protocol, all that is needed for failover is for the application to keep track of the number of bytes that it has read from the server, and to provide a callback function that reissues the request to the new server, replacing the offset with this number. When there is no failover, only one request message is sent and the minimum number of response messages are returned; in the event of failover(s), single new request message is sent for each failover that occurs. While this is a simple example, for more complex application requirements, the failover callback could be used in a variety of ways: The client might send security credentials for authentication by the server, and/or to provide a "key" by which the server could locate and setup state by accessing some application-specific (and out-of-scope) state sharing mechanism used by the servers. The client might keep track of various synchronization points in the transaction, and use the failover callback to replay message from a recent synchronization point. [Open Issue TBD: Are there others to add to this list?] 6.4 Failover Service Primitives In this section, the service primitives provided by RSerPool when operating in nameservice mode are described. [Open Issue TBD: Describe this perhaps using notation similar to that used in Section 10 of RFC2960.] 6.4.1 Failover Pool User Service Primitives For the Pool User ("client"): establishing a new session tearing down a session sending messages receiving messages Conrad & Lei Expires November 24, 2002 [Page 14] Internet-Draft Services Provided by RSerPool May 2002 6.4.2 Failover Pool Element Service Primitives For the Pool Element ("server"): registering to a pool deregistering from a pool sending messages receiving messages 7. Security Considerations [Open Issue TBD: Security issues are not discussed in this memo at this time, but will be added in a later version of this draft.] 8. IANA Considerations [Open Issue TBD: Will there be an enumeration of the various transport layer mappings that must be registered with IANA?] 9. Acknowledgements References [1] Ong, L., Shore, M., Stillman, M., Xie, Q., Loughney, J., Tuexen, M. and R. Stewart, "Architecture for Reliable Server Pooling", draft-ietf-rserpool-arch-02 (work in progress), April 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Loughney, J., "Comparison of Protocols for Reliable Server Pooling", draft-ietf-rserpool-comp-03 (work in progress), March 2002. [4] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [5] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001. [6] Stillman, M., Xie, Q. and R. Stewart, "Enpoint Name Resolution Protocol (ENRP)", draft-ietf-rserpool-enrp-03 (work in progress), April 2002. Conrad & Lei Expires November 24, 2002 [Page 15] Internet-Draft Services Provided by RSerPool May 2002 [7] Stillman, M., Xie, Q. and R. Stewart, "Aggregate Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-03 (work in progress), May 2002. Authors' Addresses Phillip T. Conrad Temple University CIS Department Room 303, Computer Building (038-24) 1805 N. Broad St. Philadelphia, PA 19122 US Phone: +1 215 204 7910 EMail: conrad@acm.org URI: http://www.cis.temple.edu/~conrad Peter Lei Cisco Systems, Inc. 955 Happfield Dr. Arlington Heights, IL 60004 US Phone: +1 847 870 7201 EMail: peterlei@cisco.com Conrad & Lei Expires November 24, 2002 [Page 16] Internet-Draft Services Provided by RSerPool May 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. 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. Conrad & Lei Expires November 24, 2002 [Page 17]