Network Working Group R. R. Stewart INTERNET-DRAFT Cisco Systems Inc. Q. Xie Motorola M. Stillman Nokia expires in six months May 3, 2002 Aggregate Server Access Protocol (ASAP) 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. 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 Aggregate Server Access Protocol (ASAP) in conjunction with the Endpoint Name Resolution Protocol (ENRP) [ENRP] provides a high availability data transfer mechanism over IP networks. ASAP uses a name-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server-pooling and load sharing. It also allows dynamic system scalability - members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP) [SCTP]. Each transport protocol to be used by Pool Elements (PE) and Pool Users (PU) MUST have an accompanying transports mapping document. Note that ASAP messages passed between PE's and ENRP servers MUST use SCTP. The high availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for name to address translation, load sharing Stewart-Xie [Page 1] Internet Draft Aggregate Server Access Protocol May 2002 management, and fault management while ENRP defines the high availability name translation service. Table Of Contents 1. Introduction............................................... 3 1.1 Definitions............................................ 3 1.2 Organization of this document.......................... 5 1.3 Scope of ASAP.......................................... 5 1.3.1 Extent of the Namespace.......................... 5 1.4 Conventions........................................... 5 2. Message Definitions........................................ 6 2.1 ASAP Parameter Formats................................. 6 2.2 ASAP Message Formats................................... 6 2.2.1 REGISTRATION message............................. 6 2.2.2 DEREGISTRATION message........................... 7 2.2.3 REGISTRATION_RESPONSE message.................... 7 2.2.4 NAME_RESOLUTION message.......................... 8 2.2.5 NAME_RESOLUTION_RESPONSE message................. 8 2.2.6 NAME_UNKNOWN message............................. 9 2.2.7 ENDPOINT_KEEP_ALIVE message...................... 9 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message.................. 9 2.2.9 ENDPOINT_UNREACHABLE message ....................10 2.2.10 SERVER_HUNT message ............................10 2.2.11 SERVER_HUNT_RESPONSE message....................10 3. Procedures.................................................11 3.1 Registration............................................11 3.2 Deregistration..........................................12 3.3 Name resolution.........................................13 3.4 Endpoint keep alive.....................................14 3.5 Reporting unreachable endpoints.........................14 3.6 ENRP server hunt procedures.............................14 3.7 Handle ASAP to ENRP Communication Failures..............15 3.7.1 SCTP Send Failure................................15 3.7.2 T1-ENRPrequest Timer Expiration..................15 4. The ASAP Interfaces........................................16 4.1 Registration.Request Primitive.........................16 4.2 Deregistration.Request Primitive.......................16 4.3 Cache.Populate.Request Primitive.......................17 4.4 Cache.Purge.Request Primitive..........................17 4.5 Data.Send.Request Primitive............................17 4.5.1 Sending to a Pool Handle.........................18 4.5.2 Pool Element Selection...........................19 4.5.2.1 Round Robin Policy.......................19 4.5.2.2 Least Used Policy........................19 4.5.2.3 Least Used with Degradation Policy.......20 4.5.2.4 Weighted Round Robin Policy..............20 4.5.3 Sending to a Pool Element Handle.................20 4.5.4 Send by Transport Address........................21 4.5.5 Message Delivery Options........................21 4.6 Data.Received Notification.............................22 4.7 Error.Report Notification..............................23 4.8 Examples...............................................23 4.8.1 Send to a New Pool Handle........................23 Stewart-Xie [Page 2] Internet Draft Aggregate Server Access Protocol May 2002 4.8.2 Send to a Cached Pool Handle.....................24 4.9 PE send failure........................................25 4.9.1 Translation.Request Primitive....................25 4.9.2 Transport.Failure Primitive......................25 5. Variables, Timers, and Constants...........................25 5.1 Timers.................................................25 5.2 Thresholds.............................................26 6. Security Considerations....................................26 7. References.................................................27 8. Acknowledgments............................................27 9. Authors' Addresses.........................................28 1. Introduction Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [ENRP] provides a high availability data transfer mechanism over IP networks. ASAP uses a name-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. When multiple receiver instances exist under the same name, a.k.a, a server pool, ASAP will select one Pool Element (PE), based on the current load sharing policy indicated by the server pool, and deliver the message to the selected PE. While delivering the message, ASAP monitors the reachability of the selected PE. If it is found unreachable, before notifying the sender of the failure, ASAP can automatically select another PE (if one exists) under that pool and attempt to deliver the message to that PE. In other words, ASAP is capable of transparent fail-over amongst instances of a server pool. ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a high availability name space. ASAP is responsible for the abstraction of the underlying transport technologies, load distribution management, fault management, as well as the presentation to the upper layer (i.e., the ASAP user) a unified primitive interface. When SCTP [RFC2960] is used as the transport layer protocol, ASAP can seamlessly incorporate the link-layer redundancy provided by the SCTP. This document defines the ASAP portion of the high availability server pool. ASAP depends on the services of a high availability name space a.k.a. ENRP. 1.1 Definitions This document uses the following terms: ASAP User: Either a PE or PU that uses ASAP. Operation scope: Stewart-Xie [Page 3] Internet Draft Aggregate Server Access Protocol May 2002 The part of the network visible to Pool Users by a specific instance of the reliable server pooling protocols. Server pool (or 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". Pool Element (PE): A server entity having registered to a pool. Pool User (PU): A server Pool User. Pool Element handle (PE handle): A logical pointer to a particular Pool Element in a pool, ENRP server: A server program running on a host that manages the name space collectively with its peer ENRP servers and replies to the service requests from any Pool User or Pool Element. Home ENRP server: The ENRP server to which a Pool Element currently uses. A PU or PE normally chooses the ENRP server on their local host as the home ENRP server (if one exists). A PU or PE should only have one home ENRP server at any given time. Note that the "home" ENRP server concept exists only within ASAP. ENRP servers provide no special handling of PE's or PU's. Having a "home" ENRP server only provides a mechanism to minimize the number of associations a given PE will have. ENRP client channel: The communication channel through which an ASAP User (either a PE or PU) requests ENRP namespace service. The client channel is usually defined by the transport address of the home server and a well known port number. The channel MAY make use of multi-cast or a named list of ENRP servers. ENRP server channel: Defined by a well known multicast IP address and a well known port number, OR a well known list of transport addresses for a group of ENRP servers spanning an operational scope. All ENRP servers in an operation scope can communicate with one another through this channel via either multicast OR direct point to point SCTP associations. ENRP name domain: Defined by the combination of the ENRP client channel and the Stewart-Xie [Page 4] Internet Draft Aggregate Server Access Protocol May 2002 ENRP server channel in the operation scope. Network Byte Order: Most significant byte first, a.k.a Big Endian. Transport address: A Transport Address is traditionally defined by Network Layer address, Transport Layer protocol and Transport Layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the Transport protocol). 1.2 Organization of this document Chapter 3 details ASAP message formats. In Chapter 4 we give the details of the ASAP interface, focusing on the communication primitives between the applications above ASAP and ASAP itself, and the communications primitives between ASAP and SCTP (or other transport layer). Also included in this discussion is relevant timers and configurable parameters as appropriate. Chapter 5 provides settable protocol values. 1.3 Scope of ASAP The requirements for high availability and scalability do not imply requirements on shared state and data. ASAP does not provide transaction failover. If a host or application fails during processing of a transaction this transaction may be lost. Some services may provide a way to handle the failure, but this is not guaranteed. ASAP MAY provide hooks to assist an application in building a mechanism to share state but ASAP in itself will NOT share any state. 1.3.1 Extent of the Namespace The scope of the ASAP/ENRP is NOT Internet wide. The namespace is neither hierarchical nor arbitrarily large like DNS. We propose a flat peer-to-peer model. Pools of servers will exist in different administrative domains. For example, suppose we want to use ASAP/ENRP. First, the PU may use DNS to contact an ENRP server. Suppose a PU in North America wishes to contact the server pool in Japan instead of North America. The PU would use DNS to get the list of IP addresses of the Japanese server pool domain, that is, the ENRP client channel in Japan. From there the PU would query the ENRP server and then directly contact the PE(s) of interest. 1.4 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]. Stewart-Xie [Page 5] Internet Draft Aggregate Server Access Protocol May 2002 2. 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. 2.1 ASAP Parameter Formats The basic message format and all parameter formats can be found in [ENRP-ASAP]. Note also that ALL ASAP message exchanged between the ENRP server and either a PE or PU MUST user SCTP. PE to PU data traffic MAY use any transport protocol specified by the PE during registration. 2.2 ASAP Messages This section details the individual messages used by ASAP. These messages are composed of a standard message format found in Section 4 or [ENRP-ASAP], elements and parameters. The parameter descriptions may also be found in Section 3 of [ENRP-ASAP]. The following ASAP message types are defined in this section: Type Message Name ----- ------------------------- 0x00 - (reserved by IETF) 0x01-0x06 - defined by [ENRP] 0x07 - Registration 0x08 - Deregistration 0x09 - Registration Response 0x0a - Name Resolution 0x0b - Name Resolution Response 0x0c - Name Unknown 0x0d - Endpoint Keep Alive 0x0e - Endpoint Keep Alive Acknowledgement 0x0f - Endpoint Unreachable 0x10 - Server Hunt 0x11 - Server Hunt Response 2.2.1 REGISTRATION 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 = 0x7 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart-Xie [Page 6] Internet Draft Aggregate Server Access Protocol May 2002 : Pool Element Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The pool handle parameter field specifies the name to be registered. The PE Parameter field shall be filled in by the registrant endpoint to declare its transports and addresses, server pooling policy and value, and other operation preferences. Note that the registration message MUST use SCTP and the IP addresses of the PE registered within the Pool Element Parameter MUST be a subset of the addresses of the SCTP association irrespective of the transport protocol regestered by the PE. 2.2.2 DEREGISTRATION 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 = 0x8 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PE sending the DEREGISTRATION shall fill in the pool handle and the PE identifier in order to allow the ENRP server to verify the identity of the endpoint. Note that deregistration is NOT allowed by proxy, in other words only a PE may only deregister itself. 2.2.3 REGISTRATION_RESPONSE message 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|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action code | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operational Error (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : Stewart-Xie [Page 7] Internet Draft Aggregate Server Access Protocol May 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Action: (8 bits) The message that this results code is in response to: 0x0 -- registration 0x1 -- de-registration Reserved: (24 bits) Ignored by the receiver and set to 0 by the sender. Operational Error This optional TLV parameter is included if an error occured during the registration/deregistration process. If the registration/deregistration was sucessful this parameter is not included. 2.2.4 NAME_RESOLUTION message 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This message is sent to a ENRP server via an SCTP association to request translation of the Pool Handle to a list of Pool Elements. 2.2.5 NAME_RESOLUTION_RESPONSE message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0xb |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Overall PE Selection Policy : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter 1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter N : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart-Xie [Page 8] Internet Draft Aggregate Server Access Protocol May 2002 Overall PE Selection Policy: This is a PE selection policy parameter. Indicates the overall selection policy of the pool. If not present, round-robin is assumed. Note, any load policy parameter inside the Pool Element Parameter (if present) MUST be ignored, and MUST NOT be used to determine the overall pool policy. 2.2.6 NAME_UNKNOWN message 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 = 0xc |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This message is returned by the ENRP server to indicate that the requested Pool Handle hold no registered PE's. 2.2.7 ENDPOINT_KEEP_ALIVE message 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 = 0xd |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This message is sent to a PE by the ENRP server has a "health" check. If the transport level Heart Beat mechanism is insufficient (usually this means that time outs are set for too long or heartbeats are not frequent enough), this adds heartbeat messages with the goal of determining health status in a more timely fashion. 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message 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 = 0xe |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE Identifier | Stewart-Xie [Page 9] Internet Draft Aggregate Server Access Protocol May 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This message is sent by the PE to the ENRP server has an acknowledgment to the ENDPOINT_KEEP_ALIVE message. 2.2.9 ENDPOINT_UNREACHABLE message 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PE Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A PE or PU will send this message to an ENRP server to report the unreachability of the specified PE. 2.2.10 SERVER_HUNT message 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 = 0x10 |0|0|0|0|0|0|0|0| Message Length : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This message is used by either a PE or PU to request service. It is sent on the ENRP client channel. 2.2.11 SERVER_HUNT_RESPONSE message 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 = 0x11 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This message is used by a ENRP server to respond to a PU or PE. It is sent over a specific SCTP association which is established using the IP address and Port number received by the ENRP server in the respective Server Hunt message that this message is in response to. 3. Procedures This chapter will focus on the methods and procedures used by an Stewart-Xie [Page 10] Internet Draft Aggregate Server Access Protocol May 2002 internal ASAP endpoint. Appropriate timers and recovery actions for failure detection and management are also discussed. 3.1 Registration When a PE wishes to join its server pool it MUST use the procedures outlined in this section to register. Often the registration will be triggered by a user request primitive (discussed in Section 4.1). The ASAP endpoint MUST register using an SCTP association between the ASAP endpoint and the ENRP server. If the ASAP endpoint has not established its Home ENRP server it MUST follow the procedures specified in Section 3.6 to establish its Home ENRP server. Once the ASAP endpoint has established its Home ENRP server the following procedures MUST be followed to register: R1) The SCTP endpoint used to communicate with the ENRP server MUST be bound to all IP addresses that will be used by the PE (irregardless of what protocol will be used to service user requests to the PE). R2) The ASAP endpoint MUST formulate a Registration message as defined in Section 2.2.1. In formulating the message the ASAP endpoint MUST: R2.1) Fill in the the Pool Handle to specify which server pool the ASAP endpoint wishes to join. R2.2) Fill in a PE identifier using a good quality randomly generated number ([RFC1750] provides some information on randomness guidelines). R2.3) Fill in the registration life time parameter with the number of seconds that this registration is good for. Note a PE that wishes to continue service MUST re-register after the registration expires. R2.4) Fill in a User Transport Parameter for EACH type of transport the PE is willing to support. R2.5) Fill in the preferred Member selection policy. R2.6) Fill in any optional authorization parameter, if required. R3) Send the Registration request to the Home ENRP server using SCTP. R4) Start a T2-registration timer. If the T2-registration timer expires before receiving a REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is received from the SCTP layer, the ASAP endpoint shall start the Server Hunt procedure (see Section 3.6) in an attempt to get service from a different ENRP server. After establishing a new Home ENRP server the ASAP endpoint SHOULD restart the registration procedure. At the reception of the registration response, the ASAP endpoint MUST stop the T2-Registration timer. If the response indicated success, then the PE is now registered and will be considered an Stewart-Xie [Page 11] Internet Draft Aggregate Server Access Protocol May 2002 available member of the server pool. If the registration response indicates a failure, the ASAP endpoint must either re-attempt registration after correcting the error or return a failure indication to the ASAP endpoints upper layer. The ASAP endpoint MUST NOT re-attempt registration without correcting the error condition. At any time a registered PE MAY wish to re-register to either update its member selection policy value or registration expiration time. When re-registering the PE MUST use the same PE identifier. After successful registration the PE MUST start a T4-reregistration timer. At its expiration a re-registration SHOULD be made starting at step R1 including (at completion) restarting the T4-reregistration timer. Note that an implementation SHOULD keep a record of the number of registration attempts it makes in a local variable. If repeated registration time-outs or failures occurs and the local count exceeds the Threshold 'max-reg-attempt' the implementation SHOULD report the error to its upper layer and stop attempting registration. 3.2 Deregistration In the event the PE wishes to deregister from its server pool (normally via an upper layer requests see section 4.2) it SHOULD use the following procedures. Note that an alternate method of deregistration is to NOT re-register and to allow the registration lift time to expire. When deregistering the PE SHOULD use the same SCTP association with its Home ENRP server that was used for registration. To deregister the ASAP endpoint MUST take the following actions: D1) Fill in the Pool Handle parameter of the Deregistration message (Section 2.2.2) using the same Pool Handle parameter sent during registration. D2) Fill in the PE Identifier. The identifier MUST be the same one used during registration. D3) Fill in any optional authorization parameter, if required. D4) Send the deregistration message to the Home ENRP server using the SCTP association. D5) Start a T3-Deregistration timer. If the T3-Deregistration timer expires before receiving a REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is received from the SCTP layer, the ASAP endpoint shall start the Server Hunt procedure (see Section 3.6) in an attempt to get service from a different ENRP server. After establishing a new Home ENRP server the ASAP endpoint SHOULD restart the deregistration procedure. At the reception of the deregistration response, the ASAP endpoint MUST stop the T3-deregistration timer. Stewart-Xie [Page 12] Internet Draft Aggregate Server Access Protocol May 2002 Note that after a successful deregistration the PE MAY still receive requests for some period of time. The PE MAY wish to still remain active and service these requests or may wish to ignore these requests and exit. 3.3 Name resolution At any time a PE or PU may wish to resolve a name. This usually will occur when a Endpoint sends to a Pool handle (Section 4.5) or requests a cache population (4.3) but may occur for other reasons (e.g. the internal ASAP PE wishes to know its peers for sending a message to all of them). When an Endpoint (PE or PU) wishes to resolve a name it MUST take the following actions: NR1) Fill in a NAME_RESOLUTION message (section 2.4) with the Pool Handle to be resolved. NR2) Fill in any optional authorization parameter, as required. NR2.1) If the endpoint does not have a Home ENRP server start the ENRP Server Hunt procedures specified in section 3.6 to obtain one. Otherwise proceed to step NR3. NR3) Send the NAME_RESOLUTION message to the Home ENRP server using SCTP. NR4) Start a T1-ENRPrequest timer. If the T1-ENRPrequest timer expires before receiving a response message, or a SEND.FAILURE notification is received from the SCTP layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see Section 3.6) in an attempt to get service from a different ENRP server. After establishing a new Home ENRP server the ASAP endpoint SHOULD restart the name resolution procedure. At the reception of the response message (either a NAME_RESOLUTION_RESPONSE or NAME_UNKNOWN) the endpoint MUST stop its T1-ENRPrequest timer. After stopping the T1 timer the endpoint SHOULD process the name response as appropriate (e.g. populate a local cache, give the response to the ASAP user, and/or use the response to send the ASAP users message). Note that some ASAP endpoints MAY use a cache to minimize the number of name resolutions made. If such a cache is used it SHOULD: C1) Be consulted before requesting a name resolution. C2) Have a stale timeout time associated with the cache so that even in the event of a cache-hit, if the cache is "stale" it will cause a new name_resolution to be issued to update the cache. C3) In the case of a "stale" cache the implementation may in parallel request an update and answer the request or block the user and wait for an updated cache before proceeding with the users request. C4) If the cache is NOT stale, the endpoint SHOULD NOT make a name_resolution request but instead return Stewart-Xie [Page 13] Internet Draft Aggregate Server Access Protocol May 2002 the entry from the cache. 3.4 Endpoint keep alive Periodically an ENRP server may choose to "audit" a PE. It does this by sending a ENDPOINT_KEEP_ALIVE message (Section 2.2.7). Upon reception of an ENDPOINT_KEEP_ALIVE message the following actions MUST be taken: KA1) The PE must verify that the Pool Handle is correct and matches the Pool Handle sent in its earlier Registration. If the Pool Handle does not match silently discard the message. KA2) If an authorization parameter is included the endpoint SHOULD verify that the message is authentic. If the verification fails, silently discard the message. KA3) Send a ENDPOINT_KEEP_ALIVE_ACK (section 2.2.8) by: KA3.1) Filling in the Pool Handle Parameter with the PE's Pool Handle. KA3.2) Fill in the PE Identifier that was used with this PE for registration. KA3.3) Fill in any optional authorization parameter, as required. KA3.4) Send off the ENDPOINT_KEEP_ALIVE_ACK message via the appropriate SCTP association for that ENRP server. 3.5 Reporting unreachable endpoints Occasionally an ASAP endpoint may realize that a PE is unreachable. This may occur by a specific SCTP error realized by the ASAP endpoint or via a ASAP user report via the Error.Report primitive (section 4.7). In either case the ASAP endpoint SHOULD report the unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message to its home ENRP server. The Endpoint should fill in the Pool Handle and PE identifier of the unreachable endpoint and any authorization parameter that may be required. The message MUST be sent via SCTP to the Endpoints Home ENRP server. 3.6 ENRP server hunt procedures 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 ENRP server hunt procedure to find a new home server. SH1) The PE or PU shall send a SERVER_HUNT message (Section 2.2.10) over the ENRP client channel. If the client channel is a multi-cast destination only one message is needed. If the client channel is a set of uni-cast addresses then a message SHOULD be sent to no more than three ENRP server unicast address. A Endpoint MUST NOT send to more than three at any single time. SH2) The Endpoint shall start a T5-Serverhunt timer. Stewart-Xie [Page 14] Internet Draft Aggregate Server Access Protocol May 2002 SH3) If the Endpoint receives a SERVER_HUNT_RESPONSE message the endpoint MUST stop its T5-Serverhunt timer. The Endpoint SHOULD also reset the T5-Serverhunt value to its initial value and then proceed to step SH5. SH4) If the T5-Serverhunt timer expires the following should be performed: SH4.1) The endpoint MUST double the value of the T5-Serverhunt timer. SH4.2) The endpoint SHOULD Repeat sending a server hunt message by proceeding to step SH1. Note that if the server hunt procedure are using a unicast channel the endpoint SHOULD attempt to select a different set of ENRP servers to send the SERVER_HUNT message to. SH5) 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 this new home ENRP server. Upon the reception of the SERVER_HUNT message, an ENRP server shall always reply to the PE with a SERVER_HUNT_RESPONSE message. 3.7 Handle ASAP to ENRP Communication Failures Three types of failure may occur when the ASAP endpoint at an endpoint tries to communicate with the ENRP server: A) SCTP send failure B) T1-ENRPrequest timer expiration C) Registration failure Registration failure is discussed in section 4.1. 3.7.1 SCTP Send Failure This indicates that the SCTP layer failed to deliver a message sent to the ENRP server. In other words, the ENRP server is currently unreachable. In such a case, the ASAP endpoint should not re-send the failed message. Instead, it should discard the failed message and start the ENRP server hunt procedure as described in Section 3.6. 3.7.2 T1-ENRPrequest Timer Expiration When a T1-ENRPrequest timer expires, the ASAP should re-send the original request to the ENRP server and re-start the T1-ENRPrequest timer. In parallel, a SERVER_HUNT message should be issued per Section 3.6. Stewart-Xie [Page 15] Internet Draft Aggregate Server Access Protocol May 2002 This should be repeated up to 'max-request-retransmit' times. After that, an Error.Report notification should be generated to inform the ASAP user and the ENRP request message associated with the timer should be discarded. Note that if an alternate ENRP server responds the ASAP endpoint SHOULD adopt the responding ENRP server as its new "home" server and resend the request to the new "home" server. 4. The ASAP Interfaces This chapter will focus primarily on the primitives and notifications that form the interface between the ASAP-user and ASAP and that between ASAP and its lower layer transport protocol (e.g., SCTP). An ASAP User passes primitives to the ASAP sub-layer to request certain actions. Upon the completion of those actions or upon the detection of certain events, the ASAP will notify the ASAP user. 4.1 Registration.Request Primitive Format: registration.request(poolHandle, User Transport parameter(s)) The poolHandle parameter contains a NULL terminated ASCII string of fixed length. The optional User Transport parameter(s) indicate specific transport parameters and types to register with. If this optional parameter is left off, then the SCTP endpoint used to communicate with the ENRP server is used as the default User Transport parameter. Note that any IP address contained within a User Transport parameter MUST be a bound IP address in the SCTP endpoint used to communicate with the ENRP server. The ASAP user invokes this primitive to add itself to the namespace, thus becoming a Pool Element of a pool. The ASAP user must register itself with the ENRP server by using this primitive before other ASAP users using the namespace can send message(s) to this ASAP user by Pool Handle or by PE handle (see Sections 4.5.1 and 4.5.2). In response to the registration primitive, the ASAP endpoint will send a REGISTRATION message to the home ENRP server (See Section 2.2.1 and Section 3.1), and start a T2-registration timer. 4.2 Deregistration.Request Primitive Format: deregistration.request(poolHandle) The ASAP PE invokes this primitive to remove itself from the Stewart-Xie [Page 16] Internet Draft Aggregate Server Access Protocol May 2002 Server Pool. This should be used as a part of the graceful shutdown process by the application. A DEREGISTRATION message will be sent by ASAP endpoint to the home ENRP server (see Section 2.2.2 and Section 3.2). 4.3 Cache.Populate.Request Primitive Format: cache.populate.request([Pool-Handle | Pool-Element-Handle]) If the address type is a Pool handle and a local name translation cache exists, the ASAP endpoint should initiate a mapping information query by sending a NAME.RESOLUTION message on the Pool handle and update it local cache when the response comes back from the ENRP server. If a Pool-Element-Handle is passed then the Pool Handle is unpacked from the Pool-Element-Handle and the NAME.RESOLUTION message is sent to the ENRP server for resolution. When the response message returns from the ENRP server the local cache is updated. Note that if the ASAP service does NOT support a local cache this primitive performs NO action. 4.4 Cache.Purge.Request Primitive Format: cache.purge.request([Pool-Handle | Pool-Element-Handle]) If the user passes a Pool handle and local name translation cache exists, the ASAP endpoint should remove the mapping information on the Pool handle from its local cache. If the user passes a Pool-Element-Handle then the Pool handle within is used for the cache.purge.request. Note that if the ASAP service does NOT support a local cache this primitive performs NO action. 4.5 Data.Send.Request Primitive Format: data.send.request(destinationAddress, typeOfAddress, message, sizeOfMessage, Options); This primitive requests ASAP to send a message to some specified Pool or Pool Element within the current Operational scope. Depending on the address type used for the send request, the senders ASAP endpoint may perform address translation and Pool Element selection before sending the message out. This also MAY dictate the creation of a local transport endpoint in order to meet the required transport type. The data.send.request primitive can take different forms of address Stewart-Xie [Page 17] Internet Draft Aggregate Server Access Protocol May 2002 types as described in the following sections. 4.5.1 Sending to a Pool Handle In this case the destinationAddress and typeOfAddress together indicates a pool handle. This is the simplest form of send.data.request primitive. By default, this directs ASAP to send the message to one of the Pool Elements in the specified pool. Before sending the message out to the pool, the senders ASAP endpoint MUST first perform a pool handle to address translation. It may also need to perform Pool Element selection if multiple Pool Elements exist in the pool. If the senders ASAP implementation does not support a local cache of the mapping information or if it does not have the mapping information on the pool in its local cache, it will transmit a NAME.RESOLUTION message (see Section 2.2.4 and Section 3.3) to the current home ENRP server, and MUST hold the outbound message in queue while awaiting the response from the ENRP server (any further send request to this pool before the ENRP server responds SHOULD also be queued). Once the necessary mapping information arrives from the ENRP server, the senders ASAP will: A) map the pool handle into a list of transport addresses of the destination PE(s), B) if multiple PEs exist in the pool, ASAP will choose one of them and transmit the message to it. In that case, the choice of the PE is made by ASAP endpoint of the sender based on the server pooling policy as discussed in section 4.5.2. C) Optionally create any transport endpoint that may be needed to communicate with the PE selected. D) if no transport association or connection exists towards the destination PE, ASAP will establish any needed transport state, E) send out the queued message(s) to the appropriate transport connection using the appropriate send mechanism (e.g. for SCTP the SEND primitive in [RFC2960] would be used), and, F) if the local cache is implemented, append/update the local cache with the mapping information received in the ENRP server's response. Also, record the local transport information (e.g. the SCTP association id) if any new transport state was created. For more on the ENRP server request procedures see [ENRP]. Stewart-Xie [Page 18] Internet Draft Aggregate Server Access Protocol May 2002 Optionally, the ASAP endpoint of the sender may return a Pool Element handle of the selected PE to the application after sending the message. This PE handle can then be used for future transmissions to that same PE (see Section 4.5.3). Section 4.5.5 defines the fail-over procedures for cases where the selected PE is found unreachable. 4.5.2 Pool Element Selection Each time an ASAP user sends a message to a pool that contains more than one PE, the senders ASAP endpoint must select one of the PEs in the pool as the receiver of the current message. The selection is done according to the current server pooling policy of the pool to which the message is sent. Note, no selection is needed if the ASAP_SEND_TOALL option is set (see Section 4.5.5). Together with the server pooling policy, each PE can also specify a Policy Value for itself at the registration time. The meaning of the policy value depends on the current server pooling policy of the group. A PE can also change its policy value whenever it desires, by re-registering itself with the namespace with a new policy value. Re-registration shall be done by simply sending another REGISTRATION to its home ENRP server (See section 3.1). Four basic server pooling policies are defined in ASAP, namely the Round Robin, Least Used, Least Used Degrading and Weighted Round Robin. The following sections describes each of these policies. 4.5.2.1 Round Robin Policy When a ASAP endpoint sends messages by Pool Handle and Round-Robin is the current policy of that Pool, the ASAP endpoint of the sender will select the receiver for each outbound message by round-Robining through all the registered PEs in that Pool, in an attempt to achieve an even distribution of outbound messages. Note that in a large server pool, the ENRP server MAY NOT send back all PEs to the ASAP client. In this case the client or PU will be performing a round robin policy on a subset of the entire Pool. 4.5.2.2 Least Used Policy When the destination Pool is under the Least Used server pooling policy, the ASAP endpoint of the message sender will select the PE that has the lowest policy value in the group as the receiver of the current message. If more than one PE from the group share the same lowest policy value, the selection will be done round Robin amongst those PEs. Stewart-Xie [Page 19] Internet Draft Aggregate Server Access Protocol May 2002 It is important to note that this policy means that the same PE will be always selected as the message receiver by the sender until the load control information of the pool is updated and changed in the local cache of the sender (via a cache update see section 3.3). 4.5.2.3 Least Used with Degradation Policy This policy is the same as the Least Used policy with the exception that, each time the PE with the lowest policy value is selected from the Pool as the receiver of the current message, its policy value is incremented, and thus it may no longer be the lowest value in the Pool. This provides a degradation of the policy towards round Robin policy over time. As with the Least Used policy, every local cache update at the sender will bring the policy back to Least Used with Degradation. 4.5.2.4 Weighted Round Robin Policy [TBD] 4.5.3 Sending to a Pool Element Handle In this case the destinationAddress and typeOfAddress together indicate an ASAP Pool Element handle. This requests the ASAP endpoint to deliver the message to the PE identified by the Pool Element handle. The Pool Element handle should contain the Pool Handle and a destination transport address of the destination PE or the Pool Handle and the transport type. Other implementation dependant elements may also be cached in a Pool Element handle. The ASAP endpoint shall use the transport address and transport type to identify the endpoint to communicate with. If no communication state exists with the peer endpoint (and is required by the transport protocol) the ASAP endpoint MAY setup the needed state and then invoke the SEND primitive for the particular transport protocol to send the message to the PE. In addition, if a local translation cache is supported the endpoint will: A) send out the message to the transport address (or association id) designated by the PE handle. B) determine if the Pool Handle is in the local cache. If it is NOT, the endpoint will: Stewart-Xie [Page 20] Internet Draft Aggregate Server Access Protocol May 2002 i) ask the home ENRP server for name resolution on pool handle by sending a NAME.RESOLUTION message (see Section 3.3), and ii) use the response to update the local cache. If the pool handle is in the cache, the endpoint will only update the pool handle if the cache is stale. A stale cache is indicated by it being older than the protocol parameter 'stale.cache.value' (see section 3.3). Section 3.5 and 4.9 defines the fail-over procedures for cases where the PE pointed to by the Pool Element handle is found unreachable. Optionally, the ASAP endpoint may return the actual Pool Element handle to which the message was sent (this may be different from the Pool Element handle specified when the primitive is invoked, due to the possibility of automatic fail-over). 4.5.4 Send by Transport Address In this case the destinationAddress and typeOfAddress together indicate a transport address and transport type. This directs the senders ASAP endpoint to send the message out to the specified transport address. No endpoint fail-over is support when this form of send request is used. This form of send request effectively by-passes the ASAP endpoint. 4.5.5 Message Delivery Options The Options parameter passed in the various forms of the above data.send.request primitive gives directions to the senders ASAP endpoint on special handling of the message delivery. The value of the Options parameter is generated by bit-wise "OR"ing of the following pre-defined constants: ASAP_USE_DEFAULT: 0x0000 Use default setting. ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In case where the first selected PE or the PE pointed to by the PE handle is found unreachable, this option allows the senders ASAP endpoint to re-select an alternate PE from the same pool if one exists, and silently re-send the message to this newly selected endpoint. ASAP_SEND_NO_FAILOVER: 0x0002 Stewart-Xie [Page 21] Internet Draft Aggregate Server Access Protocol May 2002 This option prohibits the senders ASAP endpoint from re-sending the message to any alternate PE in case that the first selected PE or the PE pointed to by the PE handle is found unreachable. Instead, the senders ASAP endpoint shall notify its upper layer about the unreachability with an Error.Report and return any unsent data. ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP endpoint to send the message to the same PE in the pool that the previous message destined to this pool was sent to. ASAP_SEND_TO_ALL: 0x0008 When sending by Pool Handle, this option directs the senders ASAP endpoint to send a copy of the message to all the PEs, except for the sender itself if the sender is a PE, in that pool. ASAP_SEND_TO_SELF: 0x0010. This option only applies in combination with ASAP_SEND_TO_ALL option. It permits the senders ASAP endpoint also deliver a copy of the message to itself if the sender is a PE of the pool (i.e., loop-back). ASAP_SCTP_UNORDER: 0x1000 This option requests the transport layer to send the current message using un-ordered delivery (note the underlying transport must support un-ordered delivery for this option to be effective). 4.6 Data.Received Notification Format: data.received(messageReceived, sizeOfMessage, senderAddress, typeOfAddress) When a new user message is received, the ASAP endpoint of the receiver uses this notification to pass the message to its upper layer. Along with the message being passed, the ASAP endpoint of the receiver should also indicate to its upper layer the message senders address. The senders address can be in the form of either an SCTP association id, TCP transport address, UDP transport address, or a ASAP Pool Element handle. A) If the name translation local cache is implemented at the receiver's ASAP endpoint, a reverse mapping from the senders IP address to the pool handle should be performed and if the mapping is successful, the senders ASAP Pool Element handle should be constructed and passed in the senderAddress field. B) If there is no local cache or the reverse mapping is not successful, the SCTP association id or other transport specific identification (if SCTP is not being used) should be passed in the senderAddress field. Stewart-Xie [Page 22] Internet Draft Aggregate Server Access Protocol May 2002 4.7 Error.Report Notification Format: error.report(destinationAddress, typeOfAddress, failedMessage, sizeOfMessage) An error.report should be generated to notify the ASAP user about failed message delivery as well as other abnormalities. The destinationAddress and typeOfAddress together indicates to whom the message was originally sent. The address type can be either a ASAP Pool Element handle, association id, or a transport address. The original message (or the first portion of it if the message is too big) and its size should be passed in the failedMessage and sizeOfMessage fields, respectively. 4.8 Examples These examples assume an underlying SCTP transport between the PE and PU. Other transports are possible but SCTP is utilized in the examples for illustrative purposes. Note that all communication between PU and ENRP server and PE and ENRP servers would be using SCTP. 4.8.1 Send to a New Pool This example shows the event sequence when a Pool User sends the message "hello" to a pool which is not in the local translation cache (assuming local caching is supported). ENRP Server PU new-name:PEx | | | | +---+ | | | 1 | | | 2. NAME_RESOLUTION +---+ | |<-------------------------------| | | +---+ | | | 3 | | | 4. NAME_RESOLUTION_REPONSE +---+ | |------------------------------->| | | +---+ | | | 5 | | | +---+ 6. "hello1" | | |---------------->| | | | 1) The user at PU invokes: Stewart-Xie [Page 23] Internet Draft Aggregate Server Access Protocol May 2002 data.send.request("new-name", name-type, "hello1", 6, 0); The ASAP endpoint, in response, looks up the pool "new-name" in its local cache but fails to find it. 2) The ASAP endpoint of PU queues the message, and sends a NAME_RESOLUTION request to the ENRP server asking for all information about pool "new-name". 3) A T1-ENRPrequest timer is started while the ASAP endpoint is waiting for the response from the ENRP server. 4) The ENRP Server responds to the query with a NAME_RESOLUTION_REPONSE message that contains all the information about pool "new-name". 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local cache with information on pool "new-name". 6) Based on the server pooling policy of pool "new-name", ASAP at PU selects the destination PE (PEx), sets up, if necessary, an SCTP association towards PEx (explicitly or implicitly), and send out the queued "hello1" user message. 4.8.2 Send to a Cached Pool Handle This shows the event sequence when the ASAP user PU sends another message to the pool "new-name" after what happened in Section 4.8.1. ENRP Server PU new-name:PEx | | | | +---+ | | | 1 | | | +---+ 2. "hello2" | | |---------------->| | | | 1) The user at PU invokes: data.send.request("new-name", name-type, "hello2", 6, 0); The ASAP endpoint, in response, looks up the pool "new-name" in its local cache and find the mapping information. 2) Based on the server pooling policy of "new-name", ASAP at PU selects the PE (assume EPx is selected again), and sends out "hello2" message (assume the SCTP association is already set up). Stewart-Xie [Page 24] Internet Draft Aggregate Server Access Protocol May 2002 4.9 PE send failure When the ASAP endpoint in a PE or PU attempts to send a message to a PE and fails the failed sender will report the event as described in section 3.5 Additional primitive are also defined in this section to support those user applications that do not wish to use ASAP as the actual transport. 4.9.1 Translation.Request Primitive Format: translation.request(Pool-Handle) If the address type is a Pool handle and a local name translation cache exists, the ASAP endpoint should look within its translation cache and return the current known transport types, ports and addresses to the caller. If the Pool handle does not exist in the local name cache or no name cache exists, the ASAP endpoint will send a NAME.RESOLUTION request using the Pool-Handle. Upon completion of the name resolution, the ASAP endpoint should populate the local name cache (if a local name cache is supported) and return the transport types, ports and addresses to the caller. 4.9.2 Transport.Failure Primitive Format: transport.failure(Pool-Handle, Transport-address) If an external user encounters a failure in sending to a PE and is NOT using ASAP it can use this primitive to report the failure to the ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" ENRP server in response to this primitive. Note ASAP SHOULD NOT send a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous request to the translate.request() primitive. 5. Variables, Timers, and Constants The following is a summary of the variables, timers, and pre-set protocol constants used in ASAP. 5.1 Timers T1-ENRPrequest - A timer started when a request is sent by ASAP to the ENRP server (providing application information is queued). Normally set to 15 seconds. T2-registration - A timer started when sending a registration request to the home ENRP server, normally set to 30 seconds. T3-deregistration- A timer started when sending a deregistration request to the home ENRP server, normally set to 30 seconds. T4-reregistration - This timer is started after successful Stewart-Xie [Page 25] Internet Draft Aggregate Server Access Protocol May 2002 registration into the ASAP name space and is used to cause a re-registration at a periodic interval. This timer is normally set to 10 minutes or 20 seconds less than the Life Timer parameter used in the registration request (whichever is less). T5-Serverhunt - This timer is used nto during the ENRP server hunt procedure and is normally set to 120 seconds. 5.2 Thresholds and Variables max-reg-attempt - The maximum number of registration attempts to be made before a server hunt is issued. max-request-retransmit - The maximum number of attempts to be made when requesting information from the local ENRP server before a server hunt is issued. stale.cache.value - A threshold variable that indicates how long a cache entry is valid for. 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 [SCTPIPSEC] 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 [SCTPTLS] or TLS over TCP as described in [RFC2246]. 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 Stewart-Xie [Page 26] Internet Draft Aggregate Server Access Protocol May 2002 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. 7. 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. [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, "Stream Control Transmission Protocol," RFC 2960, October 2000. [ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol", draft-ietf-rserpool-enrp-02.txt, work in progress. [SCTPAPI] R. R. Stewart, Q. Xie, L Yarroll, J. Wood, K. Poon, K. Fujita "Sockets API Extensions for SCTP", draft-ietf-tsvwg-sctpsocket-01.txt, work in progress. [SCTPTLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP", draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress. [SCTPIPSEC] S.M. Bellovin, J. Ioannidis, A. D. Keromytis, R.R. Stewart, "On the Use of SCTP with IPsec", draft-ietf-ipsec-sctp-03.txt, work in progress. [RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0", RFC 2246, January 1999. [ENRP-ASAP] - New draft. 17.1 Bibliography [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994. 8. Acknowledgments The authors wish to thank John Loughney, Lyndon Ong, and many others for their invaluable comments. Stewart-Xie [Page 27] Internet Draft Aggregate Server Access Protocol May 2002 9. Authors' Addresses Randall R. Stewart Tel: +1-815-477-2127 Cisco Systems, Inc. EMail: rrs@cisco.com 8725 West Higgins Road Suite 300 Chicago, Ill 60631 Qiaobing Xie Phone: +1-847-632-3028 Motorola, Inc. EMail: qxie1@email.mot.com 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 USA Maureen Stillman Phone: +1 607 273 0724 62 Nokia EMail: maureen.stillman@nokia.com 127 W. State Street Ithaca, NY 14850 USA Stewart-Xie [Page 28] Internet Draft Aggregate Server Access Protocol May 2002 Stewart, Xie [Page 25] Stewart-Xie [Page 29]