Network Working Group Q. Xie INTERNET-DRAFT Motorola R. R. Stewart Cisco Systems Expires in six months June 1, 2001 Enpoint Name Resolution Protocol (ENRP) Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. 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 Endpoint Name Resolution Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP] to accomplish the functionality of the Reliable Server Pooling (Rserpool) requirements and architecture as defined in [RSERPOOL1] and [RSERPOOL2]. Within the operational scope of Rserpool, ENRP defines the procedures and message formats of a distributed fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. Table Of Contents 1. Introduction.................................................. 2 1.2 Definitions................................................ 3 2. Conventions................................................... 4 3. ENRP Message Definitions...................................... 4 3.1 PE Parameter Definition.................................... 4 3.2 PEER_PRESENCE message...................................... 5 3.3 PEER_NAME_TABLE_REQUEST message............................ 5 3.4 PEER_NAME_TABLE_RESPONSE message........................... 6 3.5 PEER_NAME_UPDATE message................................... 7 3.6 PEER_LIST_REQUEST message.................................. 8 3.7 PEER_LIST_RESPONSE message................................. 9 Xie, Stewart [Page 1] Internet Draft Endpoint Name Resoluton Protocol June 2001 3.8 TAKEOVER_INITIATE message..................................10 3.9 TAKEOVER_INITIATE_RESPONSE message.........................11 3.10 TAKEOVER_PEER_SERVER message..............................11 3.11 SERVER_DUMP message.......................................12 3.12 SERVER_DUMP_RESPONSE message..............................12 4. ENRP Operation Procedures.....................................14 4.1 Basic ENRP Operations......................................14 4.1.1 PE Registration........................................14 4.1.2 PE De-registration.....................................15 4.1.3 Name Translation.......................................16 4.1.4 Server Namespace Update................................16 4.1.4.1 Add a New PE.......................................16 4.1.4.2 Forceful Removal of a PE...........................17 4.1.4.3 Advisory Removal of a PE...........................17 4.1.4.4 Update PE Attributes...............................18 4.1.4.5 Claim Ownership over a PE..........................18 4.1.4.6 Report PE Communication Failure....................18 4.1.5 PE Change Policy Value.................................19 4.1.6 Server Download Namespace from a Peer Server...........19 4.1.7 Server Monitor Peer Status.............................20 4.1.8 Server Download Peer List from a Peer Server...........20 4.1.9 ENRP Server Initialization.............................21 4.2 Fault Management Operations................................21 4.2.1 Detect and Report Unreachable PE.......................21 4.2.2 ENRP Server Failure Detection by Heartbeat.............22 4.2.3 PE Home ENRP Server Hunt...............................23 4.2.4 ENRP Server Detecting and Taking-over Inactive Peer ...23 4.2.5 Registration of Remote PEs.............................25 4.3 Maintenance Operations.....................................25 4.3.1 Forceful Removal of a PE...............................25 4.3.2 Dump Home PE List......................................25 4.3.3 Dump Remote PE List....................................26 4.3.4 Dump Peer Server List..................................26 5. Variables, Time Constants, and Thresholds....................26 5.1 Variables..................................................26 5.2 Timer Constants............................................26 5.3 Thresholds.................................................27 6. References....................................................27 7. Acknowledgements..............................................27 8. Authors' Addresses...........................................27 1. Introduction Endpoint Name Resolution Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP] to accomplish the functionality of the Reliable Server Pooling (Rserpool) requirements and architecture as defined in [RSERPOOL1] and [RSERPOOL2]. Within the operation scope of Rserpool, ENRP defines the procedures and message formats of a distributed fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. Xie, Stewart [Page 2] Internet Draft Endpoint Name Resoluton Protocol June 2001 Whenever appropriate, in the rest of this document we will refer to this Rserpool registry service as ENRP namespace, or simply namespace. 1.2 Definitions 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 (or server pool): A collection of servers providing the same application functionality. Pool handle (or pool name): 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". ENRP namespace (or namespace): A cohesive structure of pool names and relations that may be queried by an internal or external agent. Pool element (PE): A server entity that runs ASAP and has registered to a pool. Pool user (PU): A server pool user that runs ASAP. Note, a PU can also be a PE if it has registered itself to a pool. ENRP namespace server (or ENRP server): Entity which runs ENRP and is responsible for managing and maintaining the namespace within the operation scope. ENRP maintenance client (or maintanance client): A special program that runs ASAP and has the additional capability of exchanging ENRP maintenance messages with an ENRP server in order to perform certain maintenance functions. Home ENRP server: The ENRP server to which a PE currently belongs. PEs normally choose the ENRP server on their local host as the home ENRP server, if one exists. A PU shall only have one home ENRP server at any given time, and both the PU and the home ENRP server shall keep track of this master/slave relationship between them. ENRP server takeover: The event that a remote ENRP server takes the ownership of Xie, Stewart [Page 3] Internet Draft Endpoint Name Resoluton Protocol June 2001 all the PEs on a node and becomes their new home ENRP server. Caretaker ENRP server: The ENRP server on a remote node which takes ownership of all PEs on the local node because of the absence of an active local ENRP server. ENRP client channel: The communication channel through which a PE requests for ENRP namespace service. The ENRP client channel is usually defined by the transport address of the home ENRP server and a well known port number. ENRP server channel: Defined by a well known multicast IP address and a well known port number. All ENRP servers in an operation scope can send multicast messages to other servers through this channel. PEs are also allowed to multicast on this channel occasionally. Network Byte Order: Most significant byte first, a.k.a Big Endian. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Message Message Definitions All messages as well as their fields described below shall be in Network Byte Order during transmission. For fields with a length bigger than 4 octets, a number in a pair of parentheses may follow the filed name to indicate the length of the field in number of octets. 3.1 PE Parameter Definition This parameter is used in multiple ENRP message to represent an ASAP endpoint (i.e., a PE in a pool) and the associated information, such as its transport address(es), load control, and other operational status information of the PE. The parameter is defined to support PEs with up to 8 different IPv4 transport addresses. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Xie, Stewart [Page 4] Internet Draft Endpoint Name Resoluton Protocol June 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address #0 | +-------------------------------+-------------------------------+ | IP address #1 | +-------------------------------+-------------------------------+ \ \ \ \ / / / / \ \ \ \ +-------------------------------+-------------------------------+ | IP address #7 | +-------------------------------+-------------------------------+ | SCTP Port | Padding | +-------------------------------+-------------------------------+ | Load sharing policy type | Policy Value | +---------------+---------------+---------------+---------------+ The total size of a PE parameter is 40 octets. 3.2 PEER_PRESENCE message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP server message identifier #1 = 0x27047729 | +-------------------------------+-------------------------------+ | ENRP server message identifier #2 = 0x53829149 | +-------------------------------+-------------------------------+ | Type = 0x100 | +-------------------------------+-------------------------------+ | sender's IP address | +-------------------------------+-------------------------------+ | sender's SCTP port | padding | +-------------------------------+-------------------------------+ | receiver's IP address | +-------------------------------+-------------------------------+ | receiver's SCTP port | padding | +-------------------------------+-------------------------------+ | Reply required | +-------------------------------+-------------------------------+ The receiving server's IP address and port do not need to be filled in if the message is being multicasted. 'Reply_required' flag shall be set to 0x1 if response to this message is required, otherwise set to 0x0. 3.3 PEER_NAME_TABLE_REQUEST message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP server message identifier #1 = 0x27047729 | Xie, Stewart [Page 5] Internet Draft Endpoint Name Resoluton Protocol June 2001 +-------------------------------+-------------------------------+ | ENRP server message identifier #2 = 0x53829149 | +-------------------------------+-------------------------------+ | Type = 0x102 | +-------------------------------+-------------------------------+ | sending server's IP address | +-------------------------------+-------------------------------+ | sender's SCTP port | padding | +-------------------------------+-------------------------------+ | receiving server's IP address | +-------------------------------+-------------------------------+ | receiver's SCTP port | padding | +-------------------------------+-------------------------------+ | Table type = (see below) | +-------------------------------+-------------------------------+ Note, the receiver's IP address and port do not need to be filled in if the message is being multicasted. The requested 'Table type' shall take one of the following values: 0x1 --- HOME_LIST: PEs owned by the receiver server. 0x2 --- REMOTE_LIST: PEs NOT owned by the receiver server. 3.4 PEER_NAME_TABLE_RESPONSE message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP server message identifier #1 = 0x27047729 | +-------------------------------+-------------------------------+ | ENRP server message identifier #2 = 0x53829149 | +-------------------------------+-------------------------------+ | Type = 0x103 | +-------------------------------+-------------------------------+ | sender's IP address | +-------------------------------+-------------------------------+ | sender's SCTP port | padding | +-------------------------------+-------------------------------+ | receiver's IP address | +-------------------------------+-------------------------------+ | receiver's SCTP port | padding | +-------------------------------+-------------------------------+ | Table type = (see below) | +-------------------------------+-------------------------------+ | More to send = (see below) | +-------------------------------+-------------------------------+ | number of pool names = n | +-------------------------------+-------------------------------+ | | | Pool entry #1 (see below) | | | Xie, Stewart [Page 6] Internet Draft Endpoint Name Resoluton Protocol June 2001 +-------------------------------+-------------------------------+ / / \ \ / / +-------------------------------+-------------------------------+ | | | Pool entry #n (see below) | | | +-------------------------------+-------------------------------+ Field 'Table type' shall take one of the following values: 0x1 --- HOME_LIST: PEs owned by the sending ENRP server. 0x2 --- REMOTE_LIST: PEs NOT owned by the sending ENRP server. Field 'More to send' flag shall be set to 0x1 if there are more pool entries to be sent for the requested table type. Otherwise, it shall be set to 0x0. Each 'Pool entry' represents an existing pool and shall consist of the following: +-------------------------------+-------------------------------+ | | | Pool handle name (32) | | | +-------------------------------+-------------------------------+ | number of PEs = m | +-------------------------------+-------------------------------+ | | | PE #1 (40) | | | +-------------------------------+-------------------------------+ / / \ ..... \ / / +-------------------------------+-------------------------------+ | | | PE #m (40) | | | +-------------------------------+-------------------------------+ 3.5 PEER_NAME_UPDATE message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP server message identifier #1 = 0x27047729 | +-------------------------------+-------------------------------+ | ENRP server message identifier #2 = 0x53829149 | +-------------------------------+-------------------------------+ Xie, Stewart [Page 7] Internet Draft Endpoint Name Resoluton Protocol June 2001 | Type = 0x104 | +-------------------------------+-------------------------------+ | sender's IP address | +-------------------------------+-------------------------------+ | sender's SCTP port | padding | +-------------------------------+-------------------------------+ | receiver's IP address | +-------------------------------+-------------------------------+ | receiver's SCTP port | padding | +-------------------------------+-------------------------------+ | | | Pool handle name (32) | | | +-------------------------------+-------------------------------+ | | | PE entry (40) | | | +-------------------------------+-------------------------------+ | Update action (see below) | +-------------------------------+-------------------------------+ The receiver's IP address and port do not need to be filled in if the message is being multicasted. Field 'Update action' shall take one of the following values: 0x0 --- ADD_ENDPOINT: add the PE as a new member to the named pool in the local copy of the namespace. 0x1 --- DELETE_ENDPOINT: delete the specified PE from the local copy of namespace _if_ the receiving server owns the PE. 0x2 --- REMOVE_ENDPOINT: remove the specified PE from the local copy of namespace, regardless who owns the PE. 0x3 --- UPDATE_ENDPOINT: replace the specified PE's attributes with the new information carried in this message. 0x4 --- ENDPOINT_FAILURE: warn the receiver that the specified PE is potentially unreachable. 0x5 --- CLAIM_ENDPOINT: inform the receiver that the sender has taken the ownership of the specified PE. 3.6 PEER_LIST_REQUEST message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP server message identifier #1 = 0x27047729 | +-------------------------------+-------------------------------+ | ENRP server message identifier #2 = 0x53829149 | +-------------------------------+-------------------------------+ | Type = 0x10b | +-------------------------------+-------------------------------+ | sender's IP address | +-------------------------------+-------------------------------+ | sender's SCTP port | padding | Xie, Stewart [Page 8] Internet Draft Endpoint Name Resoluton Protocol June 2001 +-------------------------------+-------------------------------+ | receiver's IP address | +-------------------------------+-------------------------------+ | receiver's SCTP port | padding | +-------------------------------+-------------------------------+ The receiver's IP address and port do not need to be filled in if the message is being multicasted. 3.7 PEER_LIST_RESPONSE message This message shall contain all the peer information of the sending server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP server message identifier #1 = 0x27047729 | +-------------------------------+-------------------------------+ | ENRP server message identifier #2 = 0x53829149 | +-------------------------------+-------------------------------+ | Type = 0x10c | +-------------------------------+-------------------------------+ | sender's IP address | +-------------------------------+-------------------------------+ | senders SCTP port | padding | +-------------------------------+-------------------------------+ | receiver's IP address | +-------------------------------+-------------------------------+ | receiver's SCTP port | padding | +-------------------------------+-------------------------------+ | responseIndication (see below) | +-------------------------------+-------------------------------+ | number of peers = n | +-------------------------------+-------------------------------+ | | | Peer entry 1 (see below) | | | +-------------------------------+-------------------------------+ / / \ \ / / +-------------------------------+-------------------------------+ | | | Peer entry n (see below) | | | +-------------------------------+-------------------------------+ The 'responseIndication' flag shall be set to 0x2 to indicate a rejection to the request, and no 'Peer entry' shall be attached if the request is rejected. Otherwise, the 'responseIndication' flag shall be set to 0x1 and n Xie, Stewart [Page 9] Internet Draft Endpoint Name Resoluton Protocol June 2001 'Peer entries' attached. Each 'Peer entry' shall consist of the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer's IP address | +-------------------------------+-------------------------------+ | Peer's SCTP port | padding | +-------------------------------+-------------------------------+ | Caretaker's IP address | +-------------------------------+-------------------------------+ | caretaker's SCTP port | padding | +-------------------------------+-------------------------------+ The peer's IP address and port number serve as the identification of that peer. If the peer is inactive, its caretaker's IP address and port number shall be filled in. Otherwise, the caretaker IP and port fields shall be set to zeros. 3.8 TAKEOVER_INITIATE message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP server message identifier #1 = 0x27047729 | +-------------------------------+-------------------------------+ | ENRP server message identifier #2 = 0x53829149 | +-------------------------------+-------------------------------+ | Type = 0x106 | +-------------------------------+-------------------------------+ | sending server's IP address | +-------------------------------+-------------------------------+ | sender's SCTP port | padding | +-------------------------------+-------------------------------+ | receiving server's IP address | +-------------------------------+-------------------------------+ | receiver's SCTP port | padding | +-------------------------------+-------------------------------+ | Target server's IP address | +-------------------------------+-------------------------------+ | Target server's SCTP port | padding | +-------------------------------+-------------------------------+ The receiving server's address and port do not need to be filled in if the message is being multicasted. The 'Target server's IP address and port number MUST be supplied. Xie, Stewart [Page 10] Internet Draft Endpoint Name Resoluton Protocol June 2001 3.9 TAKEOVER_INITIATE_RESPONSE message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP server message identifier #1 = 0x27047729 | +-------------------------------+-------------------------------+ | ENRP server message identifier #2 = 0x53829149 | +-------------------------------+-------------------------------+ | Type = 0x107 | +-------------------------------+-------------------------------+ | sending server's IP address | +-------------------------------+-------------------------------+ | sender's SCTP port | padding | +-------------------------------+-------------------------------+ | receiving server's IP address | +-------------------------------+-------------------------------+ | receiver's SCTP port | padding | +-------------------------------+-------------------------------+ | Target server's IP address | +-------------------------------+-------------------------------+ | Target server's SCTP port | padding | +-------------------------------+-------------------------------+ The receiving server's address and port do not need to be filled in if the message is being multicasted. The 'Target server's IP address and port number MUST be supplied. 3.10 TAKEOVER_PEER_SERVER message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP server message identifier #1 = 0x27047729 | +-------------------------------+-------------------------------+ | ENRP server message identifier #2 = 0x53829149 | +-------------------------------+-------------------------------+ | Type = 0x108 | +-------------------------------+-------------------------------+ | sending server's IP address | +-------------------------------+-------------------------------+ | sender's SCTP port | padding | +-------------------------------+-------------------------------+ | receiving server's IP address | +-------------------------------+-------------------------------+ | receiver's SCTP port | padding | +-------------------------------+-------------------------------+ | Target server's IP address | +-------------------------------+-------------------------------+ | Target server's SCTP port | padding | +-------------------------------+-------------------------------+ The receiving server's address and port do not need to be filled in if the message is being multicasted. Xie, Stewart [Page 11] Internet Draft Endpoint Name Resoluton Protocol June 2001 The 'Target server's IP address and port number MUST be supplied. 3.11 SERVER_DUMP message This is an ENRP service/maintainance message sent from an ENRP service console. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP endpoint message identifier #1 = 0x18038688 | +-------------------------------+-------------------------------+ | ENRP endpoint message identifier #2 = 0x77734683 | +-------------------------------+-------------------------------+ | Type = 0x7 | +-------------------------------+-------------------------------+ | | | Console handle name (32) | | | +-------------------------------+-------------------------------+ | Dump Type (see below) | +-------------------------------+-------------------------------+ The 'Dump Type' field shall take one of the following values: 0x0 --- HOME_LIST: dump the list of all the home PEs (i.e., PEs owned by the receiving server) from the local copy of the namespace. 0x1 --- REMOTE_LIST: dump the list of all the remote PEs (i.e., PEs NOT owned by the receiving server) from the local copy of the namespace. 0x2 --- PEER_LIST: dump the list of all the peers known to the receiving server. 3.12 SERVER_DUMP_RESPONSE message This is an ENRP service/maintainance message sent to an ENRP service console as a response to a SERVER_DUMP request. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ENRP endpoint message identifier #1 = 0x18038688 | +-------------------------------+-------------------------------+ | ENRP endpoint message identifier #2 = 0x77734683 | +-------------------------------+-------------------------------+ | Type = 0x8 | +-------------------------------+-------------------------------+ | | | Console handle name (32) | | | Xie, Stewart [Page 12] Internet Draft Endpoint Name Resoluton Protocol June 2001 +-------------------------------+-------------------------------+ | Dump Type (see below) | +-------------------------------+-------------------------------+ | Number of Entries = n (see below) | +-------------------------------+-------------------------------+ | | | Dump entry 1 (see below) | | | +-------------------------------+-------------------------------+ / / \ \ / / +-------------------------------+-------------------------------+ | | | Dump entry n (see below) | | | +-------------------------------+-------------------------------+ The 'Dump Type' fields shall take the same values as defined in Section 3.11. When the 'Dump Type' is HOME_LIST or REMOTE_LIST, the 'Number of Entries' field shall be the number of pool entries carried in the message, and each 'Dump entry' field shall contain a pool entry and shall be defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Pool handle name (32) | | | +-------------------------------+-------------------------------+ | number of PEs in pool = m | +-------------------------------+-------------------------------+ | | | PE #1 (40) | | | +-------------------------------+-------------------------------+ / / \ ..... \ / / +-------------------------------+-------------------------------+ | | | PE #m (40) | | | +-------------------------------+-------------------------------+ When the 'Dump Type' is PEER_LIST, the 'Number of Entries' field shall be the number of peer entries carried in the message, and each 'Dump entry' field shall contain a peer entry and shall be defined as: 0 1 2 3 Xie, Stewart [Page 13] Internet Draft Endpoint Name Resoluton Protocol June 2001 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer's IP address | +-------------------------------+-------------------------------+ | Peer's SCTP port | padding | +-------------------------------+-------------------------------+ | Caretaker's IP address | +-------------------------------+-------------------------------+ | caretaker's SCTP port | padding | +-------------------------------+-------------------------------+ In a peer entry, the peer's IP address and port number serve as the identification of that peer. If the peer is inactive, its caretaker's IP address and port number shall be filled in. Otherwise, the caretaker IP and port fields shall be zeroed out. 4. ENRP Operation Procedures In this section, we discuss the procedures defined by ENRP. The procedures are divided into three groups, namely the basic ENRP operations, fault management, and control/maintenance procedures. Many of the Rserpool events call for message exchanges and other activities between both a PE and an ENRP server and the ENRP server and its peers. But only the message exchanges and activities between the ENRP server and its peers are considered within the ENRP protocol definition scope Procedures and message formats for communications between a PE and ENRP servers are defined in [ASAP]. However, in order to put our discussion in context, we will give brief description of the ASAP activities whenever appropreate. 4.1 Basic ENRP Operations 4.1.1 PE Registration ENRP server <-> PE: This action is part of the ASAP protocol and is defined in [ASAP]. To register itself with the name space, a PE sends a REGISTRATION message over the ENRP client channel to its home ENRP server. In the REGISTRATION message, the PE indicates the name of the pool it wishes to join, its network access address(es) (e.g., a list of valid transport addresses with which the PE can be reached), and any load control information. The ENRP server handles the REGISTRATION message according to the following rules: Xie, Stewart [Page 14] Internet Draft Endpoint Name Resoluton Protocol June 2001 1) If the named pool does not exist in the namespace, the ENRP server will creates a new pool with that name in the namespace and add the PE to the pool as its first PE; 2) If the named pool already exists in the namespace, but the requesting PE is not currently a member of the pool, ENRP server will add the PE as a new member to the pool; 3) If the named pool already exists in the namespace AND the requesting PE is already a member of the pool, i.e., a case of duplicated registration, the ENRP server will acknowledge the registration request but will not take any further actions; 4) The ENRP server may reject the registration due to reasons such as invalid values, lack of resource, etc. In cases 1 and 2 above, the ENRP server will also assume the ownership of the requesting PE. In all cases, the ENRP server will reply to the requesting PE with a REGISTRATION_RESPONSE message, and will indicate in the message body whether the registration is granted or rejected. ENRP server <-> Its peers: If the registration request is not a duplicate and is granted, the home ENRP server MUST take the namespace modification action as described in section 4.1.4.1. Otherwise, no message shall be exchanged with its peers. 4.1.2 PE De-registration ENRP server <-> PE: This action is part of the ASAP protocol and is defined in [ASAP]. To remove itself from a pool, a PE sends a DEREGISTRATION message over the ENRP client channel to its home ENRP server. In response, the home ENRP server sends a REGISTRATION_RESPONSE message to the PE and indicates in the message body whether the request is granted or rejected. If the PE is the last one of the named pool, the home ENRP server will remove the pool from the namespace as well. The ENRP server may reject the de-registration request due to reasons such as invalid parameters, etc. It should be noted that de-registration does not stop the PE from sending or receiving messages. ENRP server <-> peers: Xie, Stewart [Page 15] Internet Draft Endpoint Name Resoluton Protocol June 2001 Once the de-registration request is granted and the PE removed from its local copy of the namespace, the home ENRP server MUST take the namespace modification action described in section 4.1.4.2. 4.1.3 Name Translation ENRP server <-> PE or PU: This action is part of the ASAP protocol and is defined in [ASAP]. A PE or PU can use the name translation service provided by the ENRP server to resolve a pool name to a list of accessible transport addresses of existing PEs. This requires the PE or PU to send a NAME_REQUEST messages to its home ENRP server and in the NAME_REQUEST message specify the pool name to be translated. If the named pool exits in the namespace, the home ENRP server will send back a NAME_INFORMATION message that shall carry all information of the PEs currently registered under that pool name. This information may include the current load control policy of the pool, policy value of each PE, transport address(es) for each PE, etc. Otherwise, the ENRP server shall respond with a NAME_UNKNOWN message. ENRP server <-> peers: None. 4.1.4 Server Namespace Update This includes a set of update operations used by an ENRP server to inform its peer(s) the addition of a new PE, removal of an existing PE, or change of pool or PE properties, etc. 4.1.4.1 Add a New PE When a new PE is granted registration to the namespace, the home ENRP server uses this procedure to inform all its peers. An ENRP server shall multicast over the ENRP server channel a PEER_NAME_UPDATE message with the appropriate flag set to indicate to its peers about the addition of the new PE to the namespace. Upon the reception of this PEER_NAME_UPDATE message, each of the peer ENRP servers shall take the following actions: Xie, Stewart [Page 16] Internet Draft Endpoint Name Resoluton Protocol June 2001 1) If the named pool under which the new PE has been registered does not exist in the peer's local copy of the namespace, the peer ENRP server shall create the named pool in its local namespace copy and add the PE to it as the first PE. It then shall copy in all other attributes of the PE carried in the message. 2) If the named pool already exists in the peer's local copy of the namespace, the peer shall add the new PE to the pool as a new PE and copy in all attributes of the PE carried in the message. 3) If the named pool exists AND the PE is already a member of the pool in its the local copy of the namespace, the peer ENRP server shall take no actions. 4) If the new PE is added to its local copy of namespace (i.e., case 1 or 2 above), the peer ENRP server shall further check whether the PE is located on the same host as the peer ENRP server itself does. If so, the peer ENRP server shall assume the ownership of the PE, and take the claim ownership actions described in section 4.1.4.5. 4.1.4.2 Forceful Removal of a PE This procedure is used by an ENRP server to inform its peer(s) to remove an existing PE, regardless of the ownership of the PE. The ENRP server shall multicast over the ENRP server channel a PEER_NAME_UPDATE message with the appropriate flag set to instruct its peers to forcefully remove the PE from their local copy of the namespace. On the reception of this PEER_NAME_UPDATE message, each peer ENRP server shall find and remove the PE from its local copy of the namespace regardless whether or not it has ownership on the PE. 4.1.4.3 Advisory Removal of a PE This operation is used by an ENRP server to instruct its peers to remove an existing PE on which the peer does not have an ownership. An ENRP server shall multicast over the ENRP server channel a PEER_NAME_UPDATE message with the appropriate flag set to instruct its peers to remove the specified PE from its local copy of the namespace _if_ the peer does not own the PE. On the reception of this PEER_NAME_UPDATE message, a peer ENRP server shall find and remove the PE from its local copy of the namespace _if_ it does not own this PE. Xie, Stewart [Page 17] Internet Draft Endpoint Name Resoluton Protocol June 2001 4.1.4.4 Update PE Attributes This operation is used by an ENRP server to inform its peers to update the attributes of an existing PE. An ENRP server shall multicast over the ENRP server channel a PEER_NAME_UPDATE message with the appropriate flag set to instruct its peers to replace the attributes of an existing PE in its local copy of the name space. On the reception of this PEER_NAME_UPDATE message, a peer ENRP server shall replace the attributes of the existing PE with the new information carried in the message if the PE exists in its local copy of the name space. If the specified PE is not found in its local name space copy, the peer server shall add the PE following the steps 1) to 2) in Section 4.1.1. 4.1.4.5 Claim Ownership over a PE This operation is used by an ENRP server to claim the ownership on a specific PE and to inform its peers about its claim. ENRP server <-> PE: This action is part of the ASAP protocol and is defined in [ASAP]. An ENRP server shall send an ASAP ENDPOINT_KEEP_ALIVE message to the PE. This message will cause the PE to adopt this ENRP server as its new home ENRP server (see section 4.10.3 in [ASAP]). ENRP server <-> Its peers: An ENRP server shall multicast over the ENRP server channel a PEER_NAME_UPDATE message with the appropriate flag set to inform its peers that it has taken the ownership of the specified PE. Upon the reception of this PEER_NAME_UPDATE message, a peer server shall check whether it is the current owner of the PE. If so, this peer server shall relinquish its ownership on that PE. Otherwise, no action is needed. 4.1.4.6 Report PE Communication Failure This operation is used by an ENRP server to warn its peers that it has noticed a potentially unreachable PE that the server does not have ownership on. An ENRP server shall multicast over the ENRP server channel a PEER_NAME_UPDATE message with the appropriate flag set to indicate that the specified PE is potentially unreachable. On the reception of this message, each peer ENRP server shall check whether it owns the specified PE. If it does, the peer server shall increase the counter of the specified PE by 1. If the value of the counter has Xie, Stewart [Page 18] Internet Draft Endpoint Name Resoluton Protocol June 2001 exceeded the protocol parameter Max-Endpoint-Report-Failures, the peer server shall remove the PE from its local namespace and take actions described in Section 4.1.4.3. If the peer server does not own the specified PE, it shall take no action. 4.1.5 PE Change Policy Value A PE can modify its load policy value at any time. Based on the number of PEs in the pool and the pool's load distrbution policy, this operation allows the PE to dynamically control its share of inbound messages received by the pool (also see section 4.5.2?? in [ASAP] for more on load control). ENRP server <-> PE: This action is part of the ASAP protocol and is defined in [ASAP]. A PE normally sends an UPDATE_POLICY_VALUE ASAP message over the ENRP client channel to its home ENRP server in order to modify its policy value. The new policy value is always indicated in the message. Upon the reception of this UPDATE_POLICY_VALUE message, the home ENRP server will replace the policy value of that PE in its local copy of the namespace with the new value indicated in the message. ENRP server <-> peers: If the above update on its local copy of the namespace is successful, the home ENRP server shall take the Update PE Attributes actions as described in Section 4.1.4.4. 4.1.6 Server Download Namespace from a Peer Server This operation allows an ENRP server to request and receive a copy of a portion of the namespace from one of its peer ENRP servers. This operation is especially useful for a newly started ENRP server to initiate its local copy of the namespace, as well as for an existing ENRP server to correct namespace inconsistency found during its operation. 1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message directly to one of its peers. In the message, it shall indicate which portion of the namespace is being requested. 2) Upon the reception of this message, the peer server shall initiate a download session in which the requested portion of the namespace shall be sent to the requesting ENRP server in one or more PEER_NAME_TABLE_RESPONSE messages. Xie, Stewart [Page 19] Internet Draft Endpoint Name Resoluton Protocol June 2001 If the sending ENRP server determines that multiple PEER_NAME_TABLE_RESPONSE messages are needed for the session, it shall set the appropriate flag in each PEER_NAME_TABLE_RESPONSE message to inform the receiving ENRP server whether or not the data in this message is the last piece of the transfer. 3) During the downloading, every time the requesting ENRP server receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer the data entries carried in the message into its local namespace database, and then check whether or not the data in this message is the last piece being transfered. If more data transfer is indicated, the requesting ENRP server shall send another PEER_NAME_TABLE_REQUEST message to the same peer to request for the next piece whenever it is ready. When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE message into its local namespace database, the requesting ENRP server shall follow the same procedures as described in section 2.1.1.4.1 when parsing through the PEs carrying in the message one by one. 4.1.7 Server Monitor Peer Status An ENRP server shall keep a record on the status of each of its known peers. If a message of any type is received from a peer, the ENRP server shall update that peers status as . If a message of any type is received from a peer previously unknown, the ENRP server shall create a record for the new peer and mark the new peer as . 4.1.8 Server Download Peer List from a Peer Server This operation allows an ENRP server to request from a peer server a copy of its internal peer list. This is useful for a new ENRP server to initiate its own peer list at startup. An ENRP server shall send a PEER_LIST_REQUEST message to a peer to request a copy of the peer list. Upon the reception of this message, the peer server shall reply with a PEER_LIST_RESPONSE message and include in the message body a copy of its peer list, consisting of all the ENRP servers known by the peer togather with their status. If the peer itself is in the process of startup, it shall response with a PEER_LIST_RESPONSE message but set the appropriate flag to indicate that it can not grant the PEER_LIST_REQUEST. In such a case, the requesting ENRP server shall select another peer and repeat the peer list request with the new peer at a later time. Xie, Stewart [Page 20] Internet Draft Endpoint Name Resoluton Protocol June 2001 4.1.9 ENRP Server Initialization This section describes the steps a new ENRP server needs to take in order to join the other existing ENRP servers for providing the namespace service in the operation scope, or initiating the namespace service if this is the first ENRP server starting in the operation scope. 1) At startup, before getting into service, the ENRP server (initiating server) shall multicast a PEER_PRESENCE message with 'Reply_required' flag set over the ENRP server channel. This is to inform any other existing peers in the operation scope about the initiating peer's presence. 2) Upon the reception of this message, a peer shall send a PEER_PRESENCE without 'Reply_required' flag back to the initiating server, in order to help the initiating server to build a peer list. 3) If no response to its PEER_PRESENCE message are received, the initiating server shall assume that it is alone in the operation scope and shall mark the initialization process as completed. The initiation server shall skip the remaining steps and start to offer the namespace services. 4) If there are responses to its PEER_PRESENCE message, the initiating server shall then take the actions described in 4.1.8 to request a peer list from one of the peers that have responded. 5) Upon the reception of the PEER_LIST_RESPONSE message from the peer, the initiating server shall use the information carried in the message to build a complete peer list, including both active and inactive peers in the operation scope. 6) Then, the initiating server shall download the HOME_LIST of the namespace from each active peer, as described in 4.1.6. Moreover, the initiating server shall also pick one of the active peers and request to download the REMOTE_LIST from that peer. These downloads once done should allow the initiating server to create a complete view of the current namespace. At this point, the initialization process is completed and the initiating server shall start to provide namespace services. 4.2 Fault Management Operations The following operations are used to detect and recover from various system faults. Xie, Stewart [Page 21] Internet Draft Endpoint Name Resoluton Protocol June 2001 4.2.1 Detect and Report Unreachable PE Two mechanisms exist to detect and report an unreachable PE: 1) Home ENRP server periodic sanity check An ENRP server shall send, in every seconds, an ENDPOINT_KEEP_ALIVE message to each of the PE it owns, and shall keep the number of consecutive failed send attempts in the counter of that PE. If the value of of a PE exceeds the pre-set threshold Max-endpoint-sanity-failures, the home ENRP server shall remove the PE from its local copy of the namespace and take the actions described in section 4.1.4.3 to inform its peers. The definition and handling of the ENDPOINT_KEEP_ALIVE message by the PE are part of ASAP and are described in sections 3.9?? and 4.10.3?? in [ASAP]. 2) Failure report by peer PE Whenever a PE finds a peer PE unreachable (e.g., via an SCTP SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the former shall send an ENDPOINT_UNREACHABLE message over the ENRP client channel to its home ENRP server. The message shall contain one of the transport addresses of the unreachable peer PE and have the 'Severity' flag set to NORMAL_REPORT in the message. The definition and procedure of ENDPOINT_UNREACHABLE message are part of ASAP and are described in [ASAP]. Upon the reception of the ENDPOINT_UNREACHABLE message, the home ENRP server shall first check whether it owns the unreachable PE. If not, the home ENRP server shall take the actions described in section 4.1.4.6. If the home ENRP server does own the unreachable PE, it shall increase an counter of the unreachable PE by 1, and if the value of the counter exceeds threshold Max-endpoint-report-failures, the server shall remove the PE from its local copy of the namespace and take actions described in 4.1.4.3. 4.2.2 ENRP Server Failure Detection by Heartbeat An ENRP server shall multicast, in every seconds, a PEER_PRESENCE message over the ENRP server channel to inform its peers that it is still operational. In the PEER_PRESENCE message, the sending ENRP server shall unset the 'Replay_required' flag to indicate that no response is required. Xie, Stewart [Page 22] Internet Draft Endpoint Name Resoluton Protocol June 2001 Occassionally, an ENRP server may also send a point-to-point PEER_PRESENCE message to a specific peer server, with the 'Replay_required' flag set in the message, indicating that a response is required. In such a case, the receiving peer server MUST immediately respond to the sender with its own point-to-point PEER_PRESENCE message without setting the 'Replay_required' flag. 4.2.3 PE or PU Home ENRP Server Hunt This action is part of ASAP protocol and is defined in [ASAP]. At its startup, or when it fails to send to (i.e., timed-out on a service request) with its current home ENRP server, a PE or PU shall initiate the following home server hunt procedure. In the home server hunt procedure, the PE or PU shall multicast a SERVER_HUNT message over the ENRP client channel, and shall repeat sending this message every seconds until a SERVER_HUNT_RESPONSE message is received from an ENRP server. Moreover, each time the 'Timeout-server-hunt' timer expires the criticality should be raised (initially criticality should be set to LOW_CRITICALITY). Then the PE or PU shall pick one of the ENRP servers that have responded as its new home ENRP server, and send all its subsequent the namespace service requests to it. Upon the reception of the SERVER_HUNT message, an ENRP server shall normally reply to the PE with a SERVER_HUNT_RESPONSE message, unless its peer status information indicates that there is a caretaker ENRP server other than itself for the node where the PE resides, AND the criticality flag in the SERVER_HUNT message is not HIGH_CRITICALITY. 4.2.4 ENRP Server Detecting and Taking-over Inactive Peer An ENRP server shall keep track the time when the last message (multicast or point-to-point) was received from each known peer. If a peer has not been heard for more than Max-time-last-heard, the ENRP server shall send a point-to-point PEER_PRESENCE with 'Reply request' to that peer. If the send fails or the peer does not reply after Max-time-no-response seconds, the ENRP server shall initiate the following server take-over procedures: 1) Initiate Server Take-over Arbitration The ENRP server (the initiating server) shall initiate a take-over arbitration on the inactive peer (the target server) by multicasting a TAKEOVER_INITIATE message over the ENRP server channel. In the message, the initiating server shall specify the identification of Xie, Stewart [Page 23] Internet Draft Endpoint Name Resoluton Protocol June 2001 the target server. After multicasting the TAKEOVER_INITIATE message, the initiating server shall wait for a TAKEOVER_INITIATE_RESPONSE message from each of its active peers. Upon the reception of this message, other peer servers shall take the following actions accordingly: A1) If the peer server finds that itself is the target server indicated in the TAKEOVER_INITIATE message, it MUST immediately multicast a PEER_PRESENCE message over the ENRP server channel in an attempt to stop the take-over process. A2) If the peer server finds that itself has also initiated a take-over process on the same target server AND its IP address is smaller in value than that of the sender of the TAKEOVER_INITIATE message, the peer server shall abort its own take-over process and perform A3) below. A3) Peers other than the target peer and the initiating peer shall mark the target server as and mark the initiating server as the caretaker of the target server and reply to the initiating server with a TAKEOVER_INITIATE_RESPONSE message. A4) Once it has received TAKEOVER_INITIATE_RESPONSE message from all of its active peers, the initiating server shall consider it won the arbitration and shall then take the actions in 2) below so as to complete the take-over. However, if it receives a PEER_PRESENCE from the target server at any point of the take-over, the initiating server shall immediately abort the take-over process and re-mark the target server as . 2) Take-over the target peer server The initiating ENRP server shall multicast a TAKEOVER_PEER_SERVER message over the ENRP server channel in order to inform all its peers about the take-over. In the message, identification of the inactive peer server targeted for the take-over MUST be included. The initiating server shall mark the target server as and mark itself as the caretaker of the target server in its own peer list. Then it shall claim ownership on each of the PEs in its local copy of the namespace that is originally owned by the target server. The procedures in x.x.x.x. shall be followed when claiming the ownership of the PEs. The server shall finally check whether there are any inactive peers Xie, Stewart [Page 24] Internet Draft Endpoint Name Resoluton Protocol June 2001 (other than the current target server) which has designated the target server as their caretaker. If so, the initiating server shall perform the above ownership take-over procedure on each one of those inactive peers as well. 4.2.5 Registration of Remote PEs When an ENRP server receives a REGISTRATION message from a PE located on a remote machine, it shall always accept and grant the registration and assume ownership of the PE. However, if the ENRP server's peer status information indicates that the peer on the remote machine is inactive AND a caretaker other than the ENRP server itself exists for that machine, the ENRP server shall reject the registration and take no further actions. If the ENRP server has no record about a peer on that remote node, it shall grant the registration as above AND then create a peer record in its local peer list about that node, mark the new peer as inactive, and initiate a take-over procedure on the new peer, as described in section 4.2.4. 4.3 Maintenance Operations The following operations are used by an ENRP maintenance client to monitor the name space data and perform maintenances on ENRP servers in an operation scope. 4.3.1 Forceful Removal of a PE In order to force the removal of PE from the namespace, a maintenance client shall send an ENDPOINT_UNREACHABLE message to an existing ENRP server, and in the message shall indicate one of the transport addresses of the target PE and have the 'Severity' flag set to FINAL_REPORT. Upon the reception of this message, the ENRP server shall immediately remove the target PE from its local copy of the namespace and take actions described in Section 4.1.4.2 to inform its peers to do the same. 4.3.2 Dump Home PE List To require a copy of the information on all the PEs owned by an ENRP server, a maintenance client shall send a SERVER_DUMP message with 'Dump type' flag set to HOME_LIST to the server. Upon receiving this message, the ENRP server shall response with a SERVER_DUMP_RESPONSE message with the 'Dump type' flag set to HOME_LIST to the maintenance client, and in the message body, Xie, Stewart [Page 25] Internet Draft Endpoint Name Resoluton Protocol June 2001 include information on all the PEs the server currently owns. 4.3.3 Dump Remote PE List To require a copy of the information on all the PEs NOT owned by an ENRP server, a maintenance client shall send a SERVER_DUMP message with 'Dump type' flag set to REMOTE_LIST to the server. Upon receiving this message, the server shall response with a SERVER_DUMP_RESPONSE message with the 'Dump type' flag set to REMOTE_LIST to the maintenance client, and in the message body, include information on all the PEs the server currently does NOT own. 4.3.4 Dump Peer Server List To require a copy of the peer list known to a specific ENRP server (this list most likely will also represent ALL the active and inactive ENPR servers in the operation scope), a maintenance client shall send a SERVER_DUMP message with the 'Dump type' flag set to PEER_SERVER_LIST to the ENRP server. Upon receiving this message, the server shall response with a SERVER_DUMP_RESPONSE message with the 'Dump type' flag set to PEER_SERVER_LIST to the maintenance client, and in the message body, include information on all the peers that server currently knows. 5. Variables, Time Constants, and Thresholds The following is a summary of the variables, time values, and pre-set thresholds used in ASAP and ENRP protocol. 5.1 Variables Endpoint-report-failures --- per registered PE, this keeps the number of unreachable reports concerning the PE. Endpoint-sanity-failures --- per registered PE; this keeps the number of failed sanity message send attempts concerning the PE. Peer-server-last-heard --- per peer ENRP server; this is a time stamp on when the last message was received from this peer server. 5.2 Timer Constants Endpoint-sanity-cycle --- the period for a home ENRP server to start a new round of PE sanity check. Peer-heartbeat-cycle ---the period for an ENRP server to send out a Xie, Stewart [Page 26] Internet Draft Endpoint Name Resoluton Protocol June 2001 heartheat message to its known peers. 5.3 Thresholds Max-endpoint-sanity-failures --- pre-set threshold for Endpoint-sanity-failures. Max-endpoint-report-failures --- pre-set threshold for Endpoint-report-failures. Max-time-last-heard --- pre-set threshold for Peer-server-last-heard. Max-time-no-response --- pre-set threshold for a peer server to answer a PEER_PRESENCE message with reply required. Timeout-server-hunt --- pre-set threshold for how long a PE will wait for the REGISTRATION_RESPONSE from its home ENRP server. 6. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol (ASAP)", , work in progress. [RSERPOOL1] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, L. Ong, J. Loughney, M. Stillman: "Requirements for Reliable Server Pooling," , work in progress. [RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server Pooling," , work in progress. [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October 2000. 7. Acknowledgements The authors wish to thank John Loughney, Lyndon Ong, and Maureen Stillman and many others for their invaluable comments. 8. Authors' Addresses Randall R. Stewart Xie, Stewart [Page 27] Internet Draft Endpoint Name Resoluton Protocol June 2001 24 Burning Bush Trail. Crystal Lake, IL 60012 USA Phone: +1-815-477-2127 EMail: rrs@cisco.com Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA Phone: +1-847-632-3028 EMail: qxie1@email.mot.com Expires in six months from June 2001 Xie, Stewart [Page 28]