Network Working Group Q. Xie Internet-Draft Motorola Expires: March 4, 2003 R. Stewart Cisco M. Stillman Nokia September 3, 2002 Endpoint Name Resolution Protocol (ENRP) draft-ietf-rserpool-enrp-04.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 March 4, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Endpoint Name Resolution Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (Rserpool) requirements and architecture. 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. Xie, et al. Expires March 4, 2003 [Page 1] Internet-Draft Endpoint Name Resolution Protocol September 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 3. ENRP Message Definitions . . . . . . . . . . . . . . . . . 7 3.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 7 3.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 8 3.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 9 3.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 11 3.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 12 3.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 3.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 3.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 15 3.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 16 3.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . . 16 3.11 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 18 4. ENRP Operation Procedures . . . . . . . . . . . . . . . . 19 4.1 Methods for Communicating amongst ENRP Servers . . . . . . 19 4.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 20 4.2.1 Generate a Server Identifier . . . . . . . . . . . . . . . 21 4.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . . . 21 4.2.3 Download ENRP Namespace Data from Mentor Peer . . . . . . 23 4.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 25 4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . . . 26 4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 27 4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28 4.6 Server Namespace Update . . . . . . . . . . . . . . . . . 28 4.6.1 Announcing Addition or Update of PE . . . . . . . . . . . 29 4.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . . . 29 4.7 Detecting and Removing Unreachable PE . . . . . . . . . . 30 4.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 31 4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 31 4.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . . . 31 4.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . . . 32 4.9.3 Detecting Peer Server Failure . . . . . . . . . . . . . . 32 4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . . 32 4.10.1 Initiate Server Take-over Arbitration . . . . . . . . . . 32 4.10.2 Take-over Target Peer Server . . . . . . . . . . . . . . . 33 4.11 Namespace Data Auditing and Re-synchronization . . . . . . 34 4.11.1 Auditing Prodecures . . . . . . . . . . . . . . . . . . . 34 4.11.2 Re-synchronization Prodecures . . . . . . . . . . . . . . 34 4.12 Handling Unrecognized Message or Unrecognized Parameter . 35 5. Variables and Time Constants . . . . . . . . . . . . . . . 36 5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 Timer Constants . . . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . 37 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 38 Xie, et al. Expires March 4, 2003 [Page 2] Internet-Draft Endpoint Name Resolution Protocol September 2002 Normative References . . . . . . . . . . . . . . . . . . . 39 Informative References . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 Full Copyright Statement . . . . . . . . . . . . . . . . . 41 Xie, et al. Expires March 4, 2003 [Page 3] Internet-Draft Endpoint Name Resolution Protocol September 2002 1. Introduction ENRP is designed to work in conjunction with ASAP [1] to accomplish the functionality of Rserpool as defined by its requirements [2] and architecture [3]. 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. Whenever appropriate, in the rest of this document we will refer to this Rserpool registry service as ENRP namespace, or simply namespace. 1.1 Definitions This document uses the following terms: Operation scope: See [3]; Pool (or server pool): See [3]; Pool handle (or pool name): See [3]; Pool element (PE): See [3]; Pool user (PU): See [3]; Pool element handle: See [3]; ENRP namespace (or namespace): See [3]; ENRP namespace server (or ENRP server): See [3]; 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; Home ENRP server: The ENRP server to which a PE or PU currently belongs. A PE MUST only have one home ENRP server at any given time and both the PE and its home ENRP server MUST keep track of Xie, et al. Expires March 4, 2003 [Page 4] Internet-Draft Endpoint Name Resolution Protocol September 2002 this master/slave relationship between them. A PU SHOULD select one of the available ENRP servers as its home ENRP server, but the ENRP server does not need to know, nor does it need to keep track of this relationship. Xie, et al. Expires March 4, 2003 [Page 5] Internet-Draft Endpoint Name Resolution Protocol September 2002 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 [5]. Xie, et al. Expires March 4, 2003 [Page 6] Internet-Draft Endpoint Name Resolution Protocol September 2002 3. ENRP Message Definitions In this section, we defines the format of all ENRP messages. These are messages sent and received amongst ENRP servers in an operation scope. Messages sent and received between a PE/PU and an ENRP server are part of ASAP and are defined in [1]. A common format, defined in [10], is used for all ENRP and ASAP messages. Most ENRP messages contains a combination of fixed fields and TLV parameters. The TLV parameters are also defined in [10]. All messages, as well as their fields/parameters described below, MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., the most significant byte first). For ENRP, the following message types are defined: Type Message Name ----- ------------------------- 0x0 - (reserved by IETF) 0x1 - PEER_PRESENCE 0x2 - PEER_NAME_TABLE_REQUEST 0x3 - PEER_NAME_TABLE_RESPONSE 0x4 - PEER_NAME_UPDATE 0x5 - PEER_LIST_REQUEST 0x6 - PEER_LIST_RESPONSE 0x7 - PEER_INIT_TAKEOVER 0x8 - PEER_INIT_TAKEOVER_ACK 0x9 - PEER_TAKEOVER_SERVER 0xa - PEER_OWNERSHIP_CHANGE 0xb - PEER_ERROR 0xc-0xFF - (reserved by IETF) 3.1 PEER_PRESENCE message This ENRP message is used to announce (periodically) the presence of an ENRP server, or to probe the status of a peer ENRP sever. Xie, et al. Expires March 4, 2003 [Page 7] Internet-Draft Endpoint Name Resolution Protocol September 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Server Information Param (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R (reply_required) flag: 1 bit Set to '1' if the sender requires a response to this message, otherwise set to '0'. Sender Server's ID: 32 bit (unsiged integer) This is the ID of the ENRP server which sends the message. Receiver Server's ID: 32 bit (unsiged integer) This is the ID of the ENRP server to which the message is intended. If the message is not intended to an individual server (e.g., the message is multicasted to a group of servers), this field MUST be set with all 0's. Server Information Parameter: If present, contains the server information of the sender of this message (Server Information Parameter is defined in [10]). This parameter is optional. However, if this message is sent in response to a received "reply required" PEER_PRESENCE from a peer, the sender then MUST include its server information. Note, at startup an ENRP server MUST pick a randomly generated, non- zero 32-bit unsigned integer as its ID and MUST use this same ID for its entire life. 3.2 PEER_NAME_TABLE_REQUEST message An ENRP server sends this message to one of its peers to request a copy of the namespace data. This message is normally used during server initialization or namespace re-synchronization. Xie, et al. Expires March 4, 2003 [Page 8] Internet-Draft Endpoint Name Resolution Protocol September 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2 |0|0|0|0|0|0|0|W| Message Length = 0xC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ W (oWn-children-only) flag: 1 bit Set to '1' if the sender of this message is only requesting information about the PEs owned by the message receiver. Otherwise, set to '0'. Sender Server's ID: See Section 3.1. Receiver Server's ID: See Section 3.1. 3.3 PEER_NAME_TABLE_RESPONSE message Xie, et al. Expires March 4, 2003 [Page 9] Internet-Draft Endpoint Name Resolution Protocol September 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x3 |0|0|0|0|0|0|R|M| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Pool entry #1 (see below) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : ... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Pool entry #n (see below) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R (Reject) flag: 1 bit MUST be set to '1' if the sender of this message is rejecting a namespace request. In such a case, this message MUST be sent with no pool entries included. M (More_to_send) flag: 1 bit Set to '1' if the sender has more pool entries to sent in subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set to '0'. Message Length: 16 bits (unsigned integer) Indicates the entire length of the message in number of octets. Note, the value in Message Length field will NOT cover any padding at the end of this message. Sender Server's ID: See Section 3.1. Receiver Server's ID: Xie, et al. Expires March 4, 2003 [Page 10] See Section 3.1. Pool entry #1-#n: If R flag is '0', at least one pool entry SHOULD be present in the message. Each pool entry MUST start with a pool handle parameter as defined in section 3.1.7, followed by one or more pool element parameters, i.e.: +---------------------------+ : Pool handle : +---------------------------+ : PE #1 : +---------------------------+ : PE #2 : +---------------------------+ : ... : +---------------------------+ : PE #n : +---------------------------+ 3.4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Update Action | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool handle : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Length: 16 bits (unsigned integer) Indicates the entire length of the message in number of octets. Note, the value in Message Length field will NOT cover any padding at the end of this message. Xie, et al. Expires March 4, 2003 [Page 11] Internet-Draft Endpoint Name Resolution Protocol September 2002 Update Action: 16 bits (unsigned integer) This field indicates what act is requested to the specified PE. It MUST take one of the following values: 0x0 - ADD_PE: add or update the specified PE in the ENRP namespace 0x1 - DEL_PE: delete the specified PE from the ENRP namespace. Other values are reserved by IETF and MUST not be used. Reserved: 16 bits MUST be set to 0's by sender and ignored by the receiver. Sender Server's ID: See Section 3.1. Receiver Server's ID: See Section 3.1. Pool handle: Specifies to which the PE belongs. Pool Element: Specifies the PE. 3.5 PEER_LIST_REQUEST message This ENRP message is used to request a copy of the current known ENRP peer server list. This message is normally sent from a newly started ENRP server to an existing ENRP server as part of the initialization process of the new server. Xie, et al. Expires March 4, 2003 [Page 12] Internet-Draft Endpoint Name Resolution Protocol September 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length = 0xC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sender Server's ID: See Section 3.1. Receiver Server's ID: See Section 3.1. 3.6 PEER_LIST_RESPONSE message This message is used to respond a PEER_LIST_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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Server Info Param of Peer #1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Server Info Param of Peer #n : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R (Reject) flag: 1 bit MUST be set to '1' if the sender of this message is rejecting a peer list request. In such a case, this message MUST be sent Xie, et al. Expires March 4, 2003 [Page 13] Internet-Draft Endpoint Name Resolution Protocol September 2002 with no peer server ID included. Message Length: 16 bits (unsigned integer) Indicates the entire length of the message in number of octets. Note, the value in Message Length field will NOT cover any padding at the end of this message. Sender Server's ID: See Section 3.1. Receiver Server's ID: See Section 3.1. Server Information Parameter of Peer #1-#n: Each contains a Server Information Parameter of a peer known to the sender. The Server Information Parameter is defined in [10]. 3.7 PEER_INIT_TAKEOVER message This message is used by an ENRP server (the takeover initiator) to declare its intention of taking over a specific peer ENRP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sender Server's ID: See Section 3.1. Xie, et al. Expires March 4, 2003 [Page 14] Internet-Draft Endpoint Name Resolution Protocol September 2002 Receiver Server's ID: See Section 3.1. Target Server's ID: Contains the 32-bit server ID of the peer ENRP that is the target of this takeover attempt. 3.8 PEER_INIT_TAKEOVER_ACK message This message is used to acknowledge the takeover initiator that the sender of this message received the PEER_INIT_TAKEOVER message and that it does not object to the takeover. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sender Server's ID: See Section 3.1. Receiver Server's ID: See Section 3.1. Target Server's ID: Contains the 32-bit server ID of the peer ENRP that is the target of this takeover attempt. Xie, et al. Expires March 4, 2003 [Page 15] Internet-Draft Endpoint Name Resolution Protocol September 2002 3.9 PEER_TAKEOVER_SERVER message This message is used by the takeover initiator to declare that a takeover is underway. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x9 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sender Server's ID: See Section 3.1. Receiver Server's ID: See Section 3.1. Target Server's ID: Contains the 32-bit server ID of the peer ENRP that is the target of this takeover operation. 3.10 PEER_OWNERSHIP_CHANGE message This message is used by the ENRP server, normally after a successful takeover, to declare that it is now the new home ENRP server of the listed PEs in the listed pools. Xie, et al. Expires March 4, 2003 [Page 16] Internet-Draft Endpoint Name Resolution Protocol September 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xa |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool handle #1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Param #1 of pool #1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Param #k of pool #1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : ... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool handle #M : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Param #1 of pool #M : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Param #n of pool #M : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sender Server's ID: See Section 3.1. Receiver Server's ID: See Section 3.1. Pool handles and PE Identifier parameters: Each listed pool handle is followed by a list of PE Identifier parameters, indicating that the sender of this message is taking ownership of the listed PEs in the pool. Xie, et al. Expires March 4, 2003 [Page 17] Internet-Draft Endpoint Name Resolution Protocol September 2002 3.11 PEER_ERROR message This message is used by an ENRP server to report an operation error to one of its peers. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xb |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Server's ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Operation Error Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sender Server's ID: See Section 3.1. Receiver Server's ID: See Section 3.1. Operation Error Parameter: This parameter, defined in [10], indicates the type of error(s) being reported. Xie, et al. Expires March 4, 2003 [Page 18] Internet-Draft Endpoint Name Resolution Protocol September 2002 4. ENRP Operation Procedures In this section, we discuss the operation procedures defined by ENRP. An ENRP server MUST following these procedures when sending, receiving, or processing ENRP messages. Many of the Rserpool events call for both server-to-server and PU/PE- to-server message exchanges. Only the message exchanges and activities between an ENRP server and its peer(s) are considered within the ENRP scope and are defined in this document. Procedures for exchanging messages between a PE/PU and ENRP servers are defined in [1]. 4.1 Methods for Communicating amongst ENRP Servers Within an Rserpool operation scope, ENRP servers need to communicate with each other in order to exchange information such as the pool membership changes, namespace data synchronization, etc. Two types of communications are used amongst ENRP servers: o point-to-point message exchange from one ENPR server to a specific peer server, and o announcements from one server to all its peer servers in the operation scope. Point-to-point communication is always carried out over an SCTP associaiton between the sending server and the receiving server. Announcements are communicated out with one of the following two approaches: 1. The sending server sends the announcement message to a well-known RSERPOOL IP multicast channel that its peer servers subscribe to. Note: Because IP multicast is not reliable, this approach does not gaurrantee that all the peers will receive the announcement message. Moreover, since IP multicast is not secure, this approach cannot provide any security to the communication. 2. The sending server sends multiple copies of the announcement, one to each of its peer servers, over a set of point-to-point SCTP associations between the sending server and the peers. This approach gaurrantees the reliabe receiption of the message. When needed, data security can be achieved by using IP security Xie, et al. Expires March 4, 2003 [Page 19] Internet-Draft Endpoint Name Resolution Protocol September 2002 mechanisms such as IPsec [9] or TLS [8]. In order to maximize inter-operability of ENRP servers, the following rules MUST be followed: 1. At the startup time, a new ENRP server SHOULD make a decision on whether it will enable IP multicast for ENRP announcements. This decision should be based on factors such as the availability of IP multicast and the security requirements from the user of Rserpool. 2. If an ENRP server disables multicast, it then: A. MUST NOT subscribe to the well-known server multicast channel, i.e., it only receives peer announcements over SCTP associations, and B. MUST transmit all its out-going announcements over point-to- point SCTP associations with its peers. 3. If an ENRP server enables itself to use multicast, it then: A. MUST subcribe to the well-known server multicast channel to ready itself for receiving peers' multicast announcements, B. MUST also be prepared to receive peer announcements over point-to-point SCTP associations from peers. C. MUST track internally which peers are multicast-enabled and which are not. Note: A peer is always assumed to be multicast-disabled until/unless an ENRP message of any type is received from that peer over the well-known server multicast channel. D. when sending out an announcement, MUST send a copy to the well-known server multicast channel AND a copy to each of the peers that are marked as multicast-disabled over a point-to- point SCTP association. 4.2 ENRP Server Initialization This section describes the steps a new ENRP server needs to take in order to join the other existing ENRP servers, or to initiate the namespace service if it is the first ENRP server started in the operation scope. Xie, et al. Expires March 4, 2003 [Page 20] Internet-Draft Endpoint Name Resolution Protocol September 2002 4.2.1 Generate a Server Identifier A new ENRP server MUST generate a non-zero, 32-bit server Id that is as unique as possible in the operation scope and this server Id MUST remain unchanged for the lifetime of the server. Normally, a good 32-bit random number will be good enough as the server Id ([11] provides some information on randomness guidelines). 4.2.2 Acquire Peer Server List At startup, the ENRP server (initiating server) will first attempt to learn all existing peer ENRP servers in the same operation scope, or to determine that it is along in the scope. The initiating server uses an existing peer server to bootstrap itself into service. We call this peer server the mentor server. 4.2.2.1 Find the mentor server If the initiating server is told about an existing peer server through some administrative means (such as DNS query, configuration database, startup scripts, etc), the initiating server SHOULD then use this peer server as its mentor server and SHOULD skip the remaining steps in this subsection. If multiple existing peer servers are specified, the initiating server SHOULD pick one of them as its mentor peer server, keep the others as its backup menter peers, and skip the remaining steps in this subsection. If no existing peer server is specified to the initiating server AND if multicast is available in the operation scope, the following mentor peer discovery procedures SHOULD be followed: 1. The initiating server SHOULD first join the well-known ENRP server multicast channel. 2. Then the initiating server SHOULD send a PEER_PRESENCE message, with the 'Reply_required' flag set, over the multicast channel. Upon the reception of this PEER_PRESENCE message, a peer server MUST send a PEER_PRESENCE, without the 'Reply_required' flag, back to the initiating server. 3. When the first response to its original PEER_PRESENCE arrives, the initiating server SHOULD take the sender of this received response as its mentor peer server. This completes the discovery of the mentor peer server. Xie, et al. Expires March 4, 2003 [Page 21] Internet-Draft Endpoint Name Resolution Protocol September 2002 If responses are also received from other peers (a likely event when multiple peers exist in the operation scope at the time the new server started), the initiating server SHOULD keep a list of those responded as its backup mentor peers (see below). 4. If no response to its PEER_PRESENCE message are received after TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat steps 2) and 3) for up to MAX-TIME-SERVER-HUNT times. After that, if there is still no response, the initiating server MUST assume that it is alone in the operation scope. 5. If the initiating server determined that it is alone in the scope, it MUST skip the procedures in Section 4.2.2.2 and Section 4.2.3 and MUST consider its initialization completed and start offering ENRP services. Note, if multicast is not available (or not allowed for reasons such as security concerns) in the operation scope, at least one peer server MUST be specified to the initiating server through administrative means, unless the initiation server is the first server to start in the operation scope. Note, if the administratively specified menter peer(s) fails, the initiating server SHOULD use the auto-discover procedure defined in steps 1-5 above. 4.2.2.2 Request complete server list from mentor peer Once the initiating server finds its mentor peer server (by either discovery or administrative means), the initiating server MUST send a PEER_LIST_REQUEST message to the mentor peer server to request a copy of the complete server list maintained by the mentor peer (see Section 4.9 for maintaining server list). Upon the reception of this request, the mentor peer server SHOULD reply with a PEER_LIST_RESPONSE message and include in the message body all existing ENRP servers known by the mentor peer. Upon the reception of the PEER_LIST_RESPONSE message from the mentor peer, the initiating server MUST use the server information carried in the message to initialize its own peer list. However, if the mentor itself is in the process of startup and not ready to provide a peer server list (for example, the mentor peer is waiting for a response to its own PEER_LIST_REQUEST to another server), it MUST rejest the request by the initiating server and respond with a PEER_LIST_RESPONSE message with the R flag set to '1', and with no server information included in the response. Xie, et al. Expires March 4, 2003 [Page 22] Internet-Draft Endpoint Name Resolution Protocol September 2002 In the case where its PEER_LIST_REQUEST is rejected by the mentor peer, the initiating server SHOULD either wait for a few seconds and re-send the PEER_LIST_REQUEST to the mentor server, or if there is a backup mentor peer available, select another mentor peer server and send the PEER_LIST_REQUEST to the new mentor server. 4.2.3 Download ENRP Namespace Data from Mentor Peer After a peer list download is completed, the initiating server MUST request a copy of the current namespace data from its mentor peer server, by taking the following steps: 1. The initiating server MUST first send a PEER_NAME_TABLE_REQUEST message to the mentor peer, with W flag set to '0', indicating that the entire namespace is requested. 2. Upon the reception of this message, the mentor peer MUST start a download session in which a copy of the current namespace data maintained by the mentor peer is sent to the initiating server in one or more PEER_NAME_TABLE_RESPONSE messages. If more than one PEER_NAME_TABLE_RESPONSE message are used during the download, the mentor peer MUST use the M flag in each PEER_NAME_TABLE_RESPONSE message to indicate whether this message is the last one for the download session. In particular, the mentor peer MUST set the M flag to '1' in the outbound PEER_NAME_TABLE_RESPONSE if there is more data to be transferred and MUST keep track of the progress of the current download session. The mentor peer MUST set the M flag to '0' in the last PEER_NAME_TABLE_RESPONSE for the download session and close the download session (i.e., removing any internal record of the session) after sending out the last message. 3. During the downloading, every time the initiating server receives a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data entries carried in the message into its local namespace database, and then check whether or not this message is the last one for the download session. If the M flag is set to '1' in the just processed PEER_NAME_TABLE_RESPONSE message, the initiating server MUST send another PEER_NAME_TABLE_REQUEST message to the mentor peer to request for the next PEER_NAME_TABLE_RESPONSE message. 4. When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE message into its local namespace database, the initiating server MUST handle each pool entry carried in the message using the following rules: Xie, et al. Expires March 4, 2003 [Page 23] Internet-Draft Endpoint Name Resolution Protocol September 2002 A. If the pool does not exist in the local namespace, the initiating server MUST creates the pool in the local namespace and add the PE(s) in the pool entry to the pool. When creating the pool, the initiation server MUST set the overall member selection policy type of the pool to the policy type indicated in the first PE. B. If the pool already exists in the local namespace, but the PE(s) in the pool entry is not currently a member of the pool, the initiating server MUST add the PE(s) to the pool. C. If the pool already exists in the local namespace AND the PE(s) in the Pool entry is already a member of the pool, the initiating server server SHOULD replace the attributes of the existing PE(s) with the new information. 5. When the last PEER_NAME_TABLE_RESPONSE message is received from the mentor peer and unpacked into the local namespace, the initialization process is completed and the initiating server SHOULD start to provide ENRP services. Under certain circumstances, the mentor peer itself may not be able to provide a namespace download to the initiating server. For example, the mentor peer is in the middle of initializing its own namespace database, or it has currently too many download sessions open to other servers. In such a case, the mentor peer MUST rejest the request by the initiating server and respond with a PEER_NAME_TABLE_RESPONSE message with the R flag set to '1', and with no pool entries included in the response. In the case where its PEER_NAME_TABLE_REQUEST is rejected by the mentor peer, the initiating server SHOULD either wait for a few seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server, or if there is a backup mentor peer available, select another mentor peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor server. A started namespace download session may get interrupted for some reason. To cope with this, the initiating server SHOULD start a timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST to its mentor peer. If this timer expires without receiving a response from the mentor peer, the initiating server SHOULD abort the current download session and re-start a new namespace download with a backup mentor peer, if one is available. Xie, et al. Expires March 4, 2003 [Page 24] Internet-Draft Endpoint Name Resolution Protocol September 2002 Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the mentor peer has still more data to send, it SHOULD start a session timer. If this timer expires without receiving another request from the initiating server, the mentor peer SHOULD abort the session, cleaning out any resource and record of the session. 4.3 Handle PE Registration To register itself with the namespace, a PE sends a REGISTRATION message to its home ENRP server. The format of REGISTRATION message and rules of sending it are defined in [1]. In the REGISTRATION message, the PE indicates the name of the pool it wishes to join in a pool handle parameter, and its complete transport information and any load control information in a PE parameter. The ENRP server handles the REGISTRATION message according to the following rules: 1. If the named pool does not exist in the namespace, the ENRP server MUST creates a new pool with that name in the namespace and add the PE to the pool as its first PE; When a new pool is created, the overall member selection policy of the pool MUST be set to the policy type indicated by the first PE. 2. If the named pool already exists in the namespace, but the requesting PE is not currently a member of the pool, the ENRP server will add the PE as a new member to the pool; After adding the PE to the pool, the server MUST check if the policy type indicated by the PE is the same as the overall policy type of the pool. If different, the ENRP server MUST attempt to override the PE's policy and make it the same as the overall policy. A. If no additional policy-related information are required to perform the override (e.g., overriding Least-used with Round- robin does not require additional policy-related information), the ENRP server MUST replace the PE's policy type with the overall policy type. B. If additional policy information is required (e.g., overriding Round-robin with Least-load will require the knowledge of the load factor of the PE), the ENRP server MUST reject the regirstration with an error code "Pooling policy inconsistent". Xie, et al. Expires March 4, 2003 [Page 25] Internet-Draft Endpoint Name Resolution Protocol September 2002 3. If the named pool already exists in the namespace AND the requesting PE is already a member of the pool, the ENRP server SHOULD consider this as a re-registration case. The ENRP Server SHOULD replace the attributes of the existing PE with the information carried in the received REGISTRATION message. 4. After accepting the registration, the ENRP server MUST assgin itself the owner of this PE. If this is a re-registration, the ENRP server MUST take over ownership of this PE regardless of whether the PE was previously owned by the server or by a peer of it. 5. The ENRP server may reject the registration due to reasons such as invalid values, lack of resource, authentication failure, etc. In all above cases, the ENRP server MUST reply to the requesting PE with a REGISTRATION_RESPONSE message. If the registration is rejected, the ENRP server MUST indicate the rejection by including the proper Operation Error parameter in the REGISTRATION_RESPONSE message. If the registration is granted with a polcy override (see Step 2a above), in the REGISTRATION_RESPONSE message the ENRP server SHOULD also send back the registrant PE the new policy, in a Member Selection Policy Parameter, so as to inform the PE that a policy override is performed. If the registration is granted (i.e., one of cases 1-3 above), the ENRP server MUST assign itself to be the home ENRP server of the PE, i.e., to "own" the PE. Implementation note: for better performance, the ENRP server may find it both efficient and convenient to internally maintain two separate PE lists or tables - one is for the PEs that are "owned" by the ENRP server and the other for all the PEs owned by its peer(s). Moreover, if the registration is granted, the ENRP server MUST take the namespace update action as described in Section 4.6 to inform its peers about the change just made. If the registration is denied, no message will be sent to its peers. 4.3.1 Rules on PE Re-registration A PE may re-register itself to the namespace with a new set of attributtes in order to, for example, extend its registration life, change its load factor value, etc. Xie, et al. Expires March 4, 2003 [Page 26] Internet-Draft Endpoint Name Resolution Protocol September 2002 A PE may modify its load factor value at any time via re- registration. Based on the number of PEs in the pool and the pool's overall policy type, this operation allows the PE to dynamically control its share of inbound messages received by the pool (also see Section ???? in [1] for more on load control). Moreover, when re-registering, the PE MUST NOT change its policy type. The server MUST reject the re-registration if the PE attempt to change its policy type. In the rejection, the server SHOULD attach an error code "Pooling Policy Inconsistent". Regardless whether it is the current owner of the PE, if the re- registration is granted to the PE, the ENRP server MUST assign itself to be the new home ENRP server of the PE. Moreover, if the re-registration is granted, the ENRP server MUST take the namespace update action as described in Section 4.6 to inform its peers about the change just made. If the re-registration is denied, no message will be sent to its peers. 4.4 Handle PE De-registration To remove itself from a pool, a PE sends a DEREGISTRATION message to its home ENRP server. The complete format of DEREGISTRATION message and rules of sending it are defined in [1]. In the DEREGISTRATION message the PE indicates the name of the pool it belongs to in a pool handle parameter and provides its PE identifer. Upon receiving the message, the ENRP server SHALL remove the PE from its namespace. Moreover, if the PE is the last one of the named pool, the ENRP server will remove the pool from the namespace as well. If the ENRP server fails to find any record of the PE in its namespace, it SHOULD consider the de-registration granted and completed. The ENRP server may reject the de-registration request for various reasons, such as invalid parameters, authentication failure, etc. In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE message to the PE. If the de-registration is rejected, the ENRP server MUST indicate the rejection by including the proper Operation Error parameter. It should be noted that de-registration does not stop the PE from Xie, et al. Expires March 4, 2003 [Page 27] Internet-Draft Endpoint Name Resolution Protocol September 2002 sending or receiving application messages. Once the de-registration request is granted AND the PE removed from its local copy of the namespace, the ENRP server MUST take the namespace update action described in Section 4.6 to inform its peers about the change just made. Otherwise, NO message SHALL be send to its peers. 4.5 Pool Handle Translation A PU uses the pool handle translation service of an ENRP server to resolve a pool handle to a list of accessible transport addresses of the member PEs of the pool. This requires the PU to send a NAME_RESOLUTION message to its home ENRP server and in the NAME_RESOLUTION message specify the pool handle to be translated in a Pool Handle parameter. Complete defintion of the NAME_RESOLUTION message and the rules of sending it are defined in [1]. An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests from PUs either over an SCTP associaiton on the well-know SCTP port, or over a TCP connection on the well-know TCP port. Upon reception of the NAME_RESOLUTION message, the ENRP server MUST first look up the pool handle in its namespace. If the pool exits, the home ENRP server MUST compose and send back a NAME_RESOLUTION_RESPONSE message to the requesting PU. In the response message, the ENRP server MUST list all the PEs currently registered in this pool, in a list of PE parameters. The ENRP server MUST also include a pool member selection policy parameter to indicate the overall member selection policy for the pool, if the current pool member selection policy is not round-robin (if the overall policy is round-Robin, this parameter MAY be omitted?). If the named pool does not exist in the namespace, the ENRP server MUST respond with a NAME_UNKNOWN message. The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN messages and the rules of receiving them are defined in [1]. 4.6 Server Namespace Update This includes a set of update operations used by an ENRP server to inform its peers when its local namespace is modified, e.g., addition of a new PE, removal of an existing PE, change of pool or PE Xie, et al. Expires March 4, 2003 [Page 28] Internet-Draft Endpoint Name Resolution Protocol September 2002 properties. 4.6.1 Announcing Addition or Update of PE When a new PE is granted registration to the namespace or an existing PE is granted a re-registration, the home ENRP server uses this procedure to inform all its peers. This is an ENRP announcement and is sent to all the peer of the home ENRP server. See Section 4.1 on how annoucements are sent. An ENRP server MUST announce this update to all its peers in a PEER_NAME_UPDATE message with the Update Action field set to ADD_PE, indicating the addition of a new PE or the modification of an existing PE. The complete new information of the PE and the pool its belongs to MUST be indicated in the message with a PE parameter and a Pool Handle parameter, respectively. The home ENRP server SHOULD fill in its server Id in the Sender Server's ID field and leave the Receiver Server's ID blank (i.e., all 0's). When a peer receives this PEER_NAME_UPDATE message, it MUST take the following actions: 1. If the named pool indicated by the pool handle does not exist in its local copy of the namespace, the peer MUST create the named pool in its local namespace and add the PE to the pool as the first PE. It MUST then copy in all other attributes of the PE carried in the message. When the new pool is created, the overall member selection policy of the pool MUST be set to the policy type indicated by the PE. 2. If the named pool already exists in the peer's local copy of the namespace AND the PE does not exist, the peer MUST add the 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, the peer MUST replace the attributes of the PE with the new information carried in the message. 4.6.2 Announcing Removal of PE When an existing PE is granted de-registration or is removed from its namespace for some other reasons (e.g., purging an unreachable PE, Xie, et al. Expires March 4, 2003 [Page 29] Internet-Draft Endpoint Name Resolution Protocol September 2002 see Section 4.7), the ENRP server MUST uses this procedure to inform all its peers about the change just made. This is an ENRP announcement and is sent to all the peer of the home ENRP server. See Section 4.1 on how annoucements are sent. An ENRP server MUST announce the PE removal to all its peers in a PEER_NAME_UPDATE message with the Update Action field set to DEL_PE, indicating the removal of an existing PE. The complete information of the PE and the pool its belongs to MUST be indicated in the message with a PE parameter and a Pool Handle parameter, respectively. [editor's note: only the pool handle and the PE's id are needed, it should reduce the size of the message] The sending server MUST fill in its server ID in the Sender Server's ID field and leave the Receiver Server's ID blank (i.e., set to all 0's). When a peer receives this PEER_NAME_UPDATE message, it MUST first find pool and the PE in its own namespace, and then remove the PE from its local namespace. If the removed PE is the last one in the pool, the peer MUST also delete the pool from its local namespace. If the peer fails to find the PE or the pool in its namespace, it SHOULD take no further actions. 4.7 Detecting and Removing Unreachable PE Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE Notification, see section 10.2 of [7]), the PU SHOULD send an ENDPOINT_UNREACHABLE message to its home ENRP server. The message SHOULD contain the pool handle and the PE Id of the unreachable PE. Upon the reception of an ENDPOINT_UNREACHABLE message, a server MUST immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the PE in question. If this ENDPOINT_KEEP_ALIVE fails (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP server MUST consider the PE as truly unreachable and MUST remove the PE from its namespace and take actions described in Section 4.6.2. If the ENDPOINT_UNREACHABLE message is transmitted successfully to the PE, the ENRP server MUST retain the PE in its namespace. Moreover, the server SHOULD keep a counter to record how many ENDPOINT_UNREACHABLE messages it has received reporting reachability problem relating to this PE. If the counter exceeds the protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE Xie, et al. Expires March 4, 2003 [Page 30] Internet-Draft Endpoint Name Resolution Protocol September 2002 from its namespace and take actions described in Section 4.6.2. Optionally, an ENRP server may also periodically send point-to-point ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP server in order to check their reachability status. If the send of ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the PE as unreachable and MUST remove the PE from its namespace and take actions described in Section 4.6.2. Note, if an ENRP server owns a large number of PEs, the implementation should pay attention not to flood the network with bursts of ENDPOINT_KEEP_ALIVE messages. Instead, the implementation should try to smooth out the ENDPOINT_KEEP_ALIVE message traffic over time. The complete definition and rules of sending ENDPOINT_UNREACHABLE and receiving ENDPOINT_KEEP_ALIVE messages are described in [1]. 4.8 Helping PE and PU to Discover Home ENRP Server At its startup time, or whenever its current home ENRP server is not providing services, a PE or PU will attempt to find a new home server. The PE or PU will either multicast or send a point-to-point SERVER_HUNT message to one or more ENRP servers in the operation scope. For the complete procedure of this, see Section ???? in [1]. To support this procedure, whenever a SERVER_HUNT message is received an ENRP server SHOULD immediately respond to the sending PE or PU with a SERVER_HUNT_RESPONSE message. 4.9 Maintaining Peer List and Monitoring Peer Status An ENRP server MUST keep an internal record on the status of each of its known peers. This record is referred to as the server's "peer list" 4.9.1 Discovering New Peer If a message of any type is received from a previously unknown peer, the ENRP server MUST consider this peer a new peer in the operation scope and add it to the peer list. The ENRP server MUST send a PEER_PRESENCE message with the Reply- required flag set to '1' to the source address found in the arrived message. This will force the new peer to reply with its own PEER_PRESENCE containing its full server information (see Section 3.1). [editor's note: should we ask for a peer list from the new peer? this may help mending two splitted networks.] Xie, et al. Expires March 4, 2003 [Page 31] Internet-Draft Endpoint Name Resolution Protocol September 2002 4.9.2 Server Sending Heartbeat Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its continued presence to all its peer with a PEER_PRESENCE message. In the PEER_PRESENCE message, the ENRP server MUST set the 'Replay_required' flag to '0', indicating that no response is required. The arrival of this periodic PEER_PRESENCE message will cause all its peers to update their internal variable "Peer-last-heared" for the sending server (see Section 4.9.3 for more details). 4.9.3 Detecting Peer Server Failure An ENRP server MUST keep an interanl variable "Peer-last-heared" for each of its known peers and the value of this variable MUST be updated to the current local time everytime a message of any type (point-to-point or announcement) is received from the cooresponding peer. If a peer has not been heard for more than MAX-TIME-LAST-HEARD seconds, the ENRP server MUST immediately send a point-to-point PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer. If the send fails or the peer does not reply after MAX-TIME-NO- RESPONSE seconds, the ENRP server MUST consider the peer server dead and SHOULD initiate the takeover procedure defined in Section 4.10. 4.10 Taking-over a Failed Peer Server In the following descriptions, We call the ENRP server that detects the failed peer server and initiates the take-over the "initiating server" and the failed peer server the "target server." 4.10.1 Initiate Server Take-over Arbitration The initiating server SHOULD fisrt start a take-over arbitration process by announcing a PEER_INIT_TAKEOVER message to all its peer servers. See Section 4.1 on how annoucements are sent. In the message, the initiating server MUST fill in the Sender Server's ID and Target Server's ID. After announcing the PEER_INIT_TAKEOVER message, the initiating server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_ of its known peers, except of the target server. [editor's note: how long should it wait?] Each of the peer servers that receives the PEER_INIT_TAKEOVER message Xie, et al. Expires March 4, 2003 [Page 32] Internet-Draft Endpoint Name Resolution Protocol September 2002 from the initiating server SHOULD take the following actions: 1. If the peer server finds that itself is the target server indicated in the PEER_INIT_TAKEOVER message, it MUST immediately announce a PEER_PRESENCE message to all its peer ENRP servers in an attempt to stop this take-over process. This indicates a false failure detection case by the initiating server. 2. If the peer server finds that itself has already started its own take-over arbitration process on the same target server, it MUST perform the following arbitration: A. if the peer's server ID is smaller in value than the Sender Server's ID in the arrived PEER_INIT_TAKEOVER message, the peer server SHOULD immediately abort its own take-over attempt. Moreover, the peer SHOULD mark the target server as "not active" on its internal peer list so that its status will no longer be monitored by the peer, and reply the initiating server with a PEER_INIT_TAKEOVER_ACK message. B. Otherwise, the peer MUST ignore the PEER_INIT_TAKEOVER message and take no action. 3. If the peer finds that it is neither the target server nor is in its own take-over process, the peer SHOULD: a) mark the target server as "not active" on its internal peer list so that its status will no longer be monitored by this peer, and b) reply to the initiating server with a PEER_INIT_TAKEOVER_ACK message. Once the initiating server has received PEER_INIT_TAKEOVER_ACK message from _all_ of its currently known peers (except for the target server), it SHOULD consider that it has won the arbitration and SHOULD proceed to complete the take-over, following the steps described in Section 4.10.2. However, if it receives a PEER_PRESENCE from the target server at any point in the arbitration process, the initiating server SHOULD immediately abort the take-over process and mark the status of the target server as "active". 4.10.2 Take-over Target Peer Server The initiating ENRP server SHOULD first send, via an announcement, a PEER_TAKEOVER_SERVER message to inform all its active peers that the take-over is enforced. The target server's ID MUST be filled in the message. The initiating server SHOULD then remove the target server from its internal peer list. Xie, et al. Expires March 4, 2003 [Page 33] Internet-Draft Endpoint Name Resolution Protocol September 2002 [editor's note: peers should remove the target server from their list upon receiving this message. Do we really need this message? we can consolidate this with the ownership_change msg.] Then it SHOULD examine its local copy of the namespace and claim ownership of each of the PEs originally owned by the target server, by following these steps: 1. mark itself as the home ENRP server of each of the PEs originally owned by the target server; 2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the PEs. This will trigger the PE to adopt the initiating sever as its new home ENRP server; 3. after claiming the ownership of all the PEs originally owned by the target server, announce the ownership changes of all the affected PEs in a PEER_OWNERSHIP_CHANGE message to all the currently known peers. Note, if the list of affected PEs is long, the sender MAY announce the ownership changes in multiple PEER_OWNERSHIP_CHANGE messages. When a peer receives the PEER_OWNERSHIP_CHANGE message from the initiating server, it SHOULD find each of the reported PEs in its local copy of the namespace and update the PE's home ENRP server to be the sender of the message (i.e., the initiating server). 4.11 Namespace Data Auditing and Re-synchronization Message losses or certain temporary breaks in network connectivity may result in data inconsistency in the local namespace copy of some of the ENRP servers in an operation scope. Therefore, each ENRP server in the operation scope SHOULD periodically verify that its local copy of namespace data is still in sync with that of its peers. This section defines the auditing and re-synchronization procedures for an ENRP server to maintain its namespace data consistency. 4.11.1 Auditing Prodecures [TBD] 4.11.2 Re-synchronization Prodecures Once an ENRP server determines that there is inconsistancy between its local namespace data and a peer's namespace data with regarding to the PEs owned by that peer, it SHOULD perform the following steps to re-synchronize the data: Xie, et al. Expires March 4, 2003 [Page 34] Internet-Draft Endpoint Name Resolution Protocol September 2002 1. The ENRP server SHOULD first "mark" every PE it knows about that is owned by the peer in its local namespace database; 2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST message with W flag set to '1' to the peer to request a complete list of PEs owned by the peer; 3. Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag set to '1', the peer server SHOULD immediately respond with a PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned by the peer. 4. Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP server SHOULD transfer the PE entries carried in the message into its local namespace database. If an PE entry being transferred already exists in its local database, the ENRP server MUST replace the entry with the copy found in the message and remove the "mark" from the entry. 5. After transferring all the PE entries from the received PEER_NAME_TABLE_RESPONSE message into its local database, the ENRP server SHOULD check whether there are still PE entries that remain "marked" in its local namespace. If so, the ENRP server SHOULD silently remove those "marked" entries. Note, similar to what is described in Section 4.2.3, the peer may reject the PEER_NAME_TABLE_REQUEST or use more than one PEER_NAME_TABLE_RESPONSE message to respond. 4.12 Handling Unrecognized Message or Unrecognized Parameter When an ENRP server receives an ENRP message with an unknown message type or a message of known type that contains an unknow parameter, it SHOULD handle the unknow message or the unknown parameter according to the unrecognized message and parameter handling rules defined in Sections 3 and 4 in [10]. According to the rules, if an error report to the message sender is needed, the ENRP server that discovered the error SHOULD send back an ENRP_ERROR message with proper error cause code. Xie, et al. Expires March 4, 2003 [Page 35] Internet-Draft Endpoint Name Resolution Protocol September 2002 5. Variables and Time Constants 5.1 Variables Peer-last-heared - the local time that a peer server was last heard (via receiving either a multicast or point-to-point message from the peer). 5.2 Timer Constants MAX-TIME-SERVER-HUNT - the maximal number of attempts a sender will make to contact an ENRP server (Default=3 times). TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will wait for a response from an ENRP server (Default=5 secends). PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a heartheat message to all its known peers. (Default=30 secs.) MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server will wait before considering a silent peer server potentially dead. (Default=61 secs.) MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message sender will wait for a response after sending out a message. (Default=5 secs.) MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a PE that an ENRP server will allow before purging this PE from the namespace. (Default=3) Xie, et al. Expires March 4, 2003 [Page 36] Internet-Draft Endpoint Name Resolution Protocol September 2002 6. Security Considerations Due to varying requirements and multiple use cases of Rserpool, we point out two basic security protocols, IPsec and TLS. We specifically do not discuss whether one security protocol would be preferred over the other. This choice will be made by designers and network architects based on system requirements. For networks that demand IPsec security, implementations MUST support [9] which describes IPsec-SCTP. IPsec is two layers below RSerPool. Therefore, if IPsec is used for securing Rserpool, no changes or special considerations need to be made to Rserpool to secure the protocol. For networks that cannot or do not wish to use IPsec and prefer instead TLS, implementations MUST support TLS with SCTP as described in [8] or TLS over TCP as described in [6]. When using TLS/SCTP we must ensure that RSerPool does not use any features of SCTP that are not available to an TLS/SCTP user. This is not a difficult technical problem, but simply a requirement. When describing an API of the RSerPool lower layer we have also to take into account the differences between TLS and SCTP. This is also not difficult, but it is in contrast to the IPsec solution which is transparently layered below Rserpool. Support for security is required for the ENRP server and the PEs. Security support for the Rserpool end user is optional. Note that the end user implementation contains a piece of the Rserpool protocol -- namely ASAP -- whereby the pool handle is passed for name resolution to the ENRP server and IP address(es) are returned. The argument for optional end user security is as follows: If the user doesn't require security protection for example, against eavesdropping for the request for pool handle resolution and response, then they are free to make that choice. However, if the end user does require security, they are guaranteed to get it due to the requirement for security support for the ENRP server. It is also possible for the ENRP server to reject an unsecured request from the user due to its security policy in the case that it requires enforcement of strong security. But this will be determined by the security requirements of the individual network design. Xie, et al. Expires March 4, 2003 [Page 37] Internet-Draft Endpoint Name Resolution Protocol September 2002 7. Acknowledgements The authors wish to thank John Loughney, Lyndon Ong, and many others for their invaluable comments. Xie, et al. Expires March 4, 2003 [Page 38] Internet-Draft Endpoint Name Resolution Protocol September 2002 Normative References [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-04 (work in progress), July 2002. [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J. and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002. [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J. and M. Stillman, "Architecture for Reliable Server Pooling", draft-ietf-rserpool-arch-03 (work in progress), July 2002. [4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November 2001. [9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On the Use of SCTP with IPsec", draft-ietf-ipsec-sctp-03 (work in progress), February 2002. [10] Stewart, R. and Q. Xie, "Aggregate Server Access Protocol (ASAP) and Endpoint Name Resolution (ENRP) common parameters document", draft-ietf-rserpool-common-param-00 (work in progress), July 2002. Xie, et al. Expires March 4, 2003 [Page 39] Internet-Draft Endpoint Name Resolution Protocol September 2002 Informative References [11] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. Authors' Addresses Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 US Phone: +1-847-632-3028 EMail: qxie1@email.mot.com Randall R. Stewart Cisco 24 Burning Bush Trail Crystal Lake, IL 60012 US Phone: +1-815-477-2127 EMail: rrs@cisco.com Maureen Stillman Nokia 127 W. State Street Ithaca, NY 14850 US Phone: +1 607 273 0724 62 EMail: maureen.stillman@nokia.com Xie, et al. Expires March 4, 2003 [Page 40] Internet-Draft Endpoint Name Resolution Protocol September 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. Xie, et al. Expires March 4, 2003 [Page 41]