Network Working Group R. Stewart Internet-Draft Cisco Systems, Inc. Intended status: Experimental Q. Xie Expires: March 25, 2008 Motorola, Inc. M. Stillman Nokia M. Tuexen Muenster Univ. of Applied Sciences September 22, 2007 Aggregate Server Access Protocol (ASAP) draft-ietf-rserpool-asap-17.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Stewart, et al. Expires March 25, 2008 [Page 1] Internet-Draft Aggregate Server Access Protocol September 2007 Abstract Aggregate Server Access Protocol (ASAP) in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP) [9] provides a high availability data transfer mechanism over IP networks. ASAP uses a handle-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) RFC2960 [3]. Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between PE's and ENRP servers MUST use the SCTP transport protocol. The high availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for pool handle to address translation, load sharing management, and fault management while ENRP defines the high availability pool handle translation service. Stewart, et al. Expires March 25, 2008 [Page 2] Internet-Draft Aggregate Server Access Protocol September 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Organization of this document . . . . . . . . . . . . . . 6 1.3. Scope of ASAP . . . . . . . . . . . . . . . . . . . . . . 7 1.3.1. Extent of the Handlespace . . . . . . . . . . . . . . 7 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 2. Message Definitions . . . . . . . . . . . . . . . . . . . . . 8 2.1. ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 2.2. ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. ASAP_REGISTRATION message . . . . . . . . . . . . . . 9 2.2.2. ASAP_DEREGISTRATION message . . . . . . . . . . . . . 9 2.2.3. ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10 2.2.4. ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 11 2.2.5. ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message . . . . . . . 12 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 14 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 15 2.2.9. ASAP_ENDPOINT_UNREACHABLE message . . . . . . . . . . 15 2.2.10. ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . . 16 2.2.11. ASAP_COOKIE message . . . . . . . . . . . . . . . . . 16 2.2.12. ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . . 17 2.2.13. ASAP_BUSINESS_CARD message . . . . . . . . . . . . . . 17 2.2.14. ASAP_ERROR message . . . . . . . . . . . . . . . . . . 18 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Deregistration . . . . . . . . . . . . . . . . . . . . . . 21 3.3. Handle resolution . . . . . . . . . . . . . . . . . . . . 22 3.4. Endpoint keep alive . . . . . . . . . . . . . . . . . . . 23 3.5. Reporting unreachable endpoints . . . . . . . . . . . . . 24 3.6. ENRP server hunt procedures . . . . . . . . . . . . . . . 24 3.7. Handling ASAP Endpoint to ENRP Server Communication Failures . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.7.1. SCTP Send Failure . . . . . . . . . . . . . . . . . . 26 3.7.2. T1-ENRPrequest Timer Expiration . . . . . . . . . . . 26 3.7.3. Registration Failure . . . . . . . . . . . . . . . . . 27 3.8. Cookie handling procedures . . . . . . . . . . . . . . . . 27 3.9. Business Card handling procedures . . . . . . . . . . . . 27 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . . . 29 4.1. Registration.Request Primitive . . . . . . . . . . . . . . 29 4.2. Deregistration.Request Primitive . . . . . . . . . . . . . 29 4.3. CachePopulateRequest Primitive . . . . . . . . . . . . . . 30 4.4. CachePurgeRequest Primitive . . . . . . . . . . . . . . . 30 4.5. DataSendRequest Primitive . . . . . . . . . . . . . . . . 30 4.5.1. Sending to a Pool Handle . . . . . . . . . . . . . . . 31 4.5.2. Pool Element Selection . . . . . . . . . . . . . . . . 32 4.5.3. Sending to a Pool Element Handle . . . . . . . . . . . 33 Stewart, et al. Expires March 25, 2008 [Page 3] Internet-Draft Aggregate Server Access Protocol September 2007 4.5.4. Send by Transport Address . . . . . . . . . . . . . . 34 4.5.5. Message Delivery Options . . . . . . . . . . . . . . . 34 4.6. Data.Received Notification . . . . . . . . . . . . . . . . 35 4.7. Error.Report Notification . . . . . . . . . . . . . . . . 36 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.8.1. Send to a New Pool . . . . . . . . . . . . . . . . . . 36 4.8.2. Send to a Cached Pool Handle . . . . . . . . . . . . . 38 4.9. PE send failure . . . . . . . . . . . . . . . . . . . . . 38 4.9.1. Translation.Request Primitive . . . . . . . . . . . . 38 4.9.2. Transport.Failure Primitive . . . . . . . . . . . . . 39 5. Timers, Variables, and Thresholds . . . . . . . . . . . . . . 40 5.1. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6.1. A New Table for ASAP Message Types . . . . . . . . . . . . 42 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 7.1. Summary of Rserpool Security Threats . . . . . . . . . . . 43 7.2. Implementing Security Mechanisms . . . . . . . . . . . . . 44 7.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 45 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1. Normative References . . . . . . . . . . . . . . . . . . . 48 9.2. Informative References . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . . . . 51 Stewart, et al. Expires March 25, 2008 [Page 4] Internet-Draft Aggregate Server Access Protocol September 2007 1. Introduction The Aggregate Server Access Protocol (ASAP) when used in conjunction with Endpoint Name Resolution Protocol [9] provides a high availability data transfer mechanism over IP networks. ASAP uses a handle-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 handle (a.k.a, a server pool),an ASAP endpoint will select one Pool Element (PE), based on the current load sharing policy indicated by the server pool, and deliver its message to the selected PE. While delivering the message, ASAP can be used to monitor the reachability of the selected PE. If it is found unreachable, before notifying the message sender (an ASAP user) 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 PE instances within a server pool. ASAP depends on ENRP which provides a high availability pool handle space. ASAP is responsible for the abstraction of the underlying transport technologies, load distribution management, fault management, as well as presentation to the upper layer (aka an ASAP user) via a unified primitive interface. When SCTP RFC2960 [3] is used as the transport layer protocol, ASAP can seamlessly incorporate the link-layer redundancy provided by SCTP. This document defines the ASAP portion of the high availability server pool. 1.1. Definitions This document uses the following terms: ASAP user: Either a PE or PU that uses ASAP. Operational scope: The part of the network visible to pool users by a specific instance of the reliable server pooling protocols. Stewart, et al. Expires March 25, 2008 [Page 5] Internet-Draft Aggregate Server Access Protocol September 2007 Pool (or server pool): A collection of servers providing the same application functionality. Pool handle: A logical pointer to a pool. Each server pool will be identifiable in the operational scope of the system by a unique pool handle. Pool element: A server entity having registered to a pool. Pool user: A server pool user. Pool element handle (or endpoint handle): A logical pointer to a particular pool element in a pool, consisting of the pool handle and a destination transport address of the pool element. Handle space: A cohesive structure of pool handles and relations that may be queried by an internal or external agent. Home ENRP server: The ENRP server to which a PE or PU currently sends all namespace service requests. A PE MUST only have one home ENRP server at any given time and both the PE and its home ENRP server MUST know and keep track of this relationship. A PU SHOULD select one of the available ENRP servers as its Home ENRP server but the collective ENRP servers may change this by the sending or a ASAP_ENDPOINT_KEEP_ALIVE message. ENRP client channel: The communication channel through which an ASAP User sends all namespace service requests. The client channel is usually defined by the transport address of the Home ENRP server and a well known port number. The channel MAY make use of multicast or a named list of ENRP servers. 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 Section 2 details the ASAP message formats. In Section 3 we provide detailed ASAP procedures for for the ASAP implementer. In Section 4 we give details of the ASAP interface, focusing on the communication primitives between ASAP the applications above ASAP and ASAP itself, and the communications primitives between ASAP and SCTP (or other transport layers). Also included in this discussion are relevant Stewart, et al. Expires March 25, 2008 [Page 6] Internet-Draft Aggregate Server Access Protocol September 2007 timers and configurable parameters as appropriate. Section 5 provides threshold and protocol variables. 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 the 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 does NOT share any state. 1.3.1. Extent of the Handlespace The scope of ASAP/ENRP is NOT Internet wide. The handlespace is neither hierarchical nor arbitrarily large like DNS. A flat peer-to- peer model is detailed. Pools of servers will exist in different administrative domains. For example, suppose the use of ASAP and ENRP is wanted. First, the PU may use DNS to contact an ENRP server. Suppose a PU in North America wishes to contact a 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, that is, the ENRP client channel in Japan. From there the PU would query the Home ENRP server it established and then directly contact the PE(s) of interest. 1.4. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. Stewart, et al. Expires March 25, 2008 [Page 7] Internet-Draft Aggregate Server Access Protocol September 2007 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 bytes, a number in a pair of parentheses may follow the field name to indicate the length of the field in number of bytes. 2.1. ASAP Parameter Formats The basic message format and all parameter formats can be found in ENRP-ASAP [8]. Note also that ALL ASAP messages exchanged between an ENRP server and a PE MUST use SCTP as transport, while ASAP messages exchanged between an ENRP server and a PU MUST use either SCTP or TCP as transport. 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 of ENRP-ASAP [8]. The parameter descriptions can be found in Section 3 of ENRP-ASAP [8]. The following ASAP message types are defined in this section: Type Message Name ----- ------------------------- 0x00 - (reserved by IETF) 0x01 - ASAP_REGISTRATION 0x02 - ASAP_DEREGISTRATION 0x03 - ASAP_REGISTRATION_RESPONSE 0x04 - ASAP_DEREGISTRATION_RESPONSE 0x05 - ASAP_HANDLE_RESOLUTION 0x06 - ASAP_HANDLE_RESOLUTION_RESPONSE 0x07 - ASAP_ENDPOINT_KEEP_ALIVE 0x08 - ASAP_ENDPOINT_KEEP_ALIVE_ACK 0x09 - ASAP_ENDPOINT_UNREACHABLE 0x0a - ASAP_SERVER_ANNOUNCE 0x0b - ASAP_COOKIE 0x0c - ASAP_COOKIE_ECHO 0x0d - ASAP_BUSINESS_CARD 0x0e - ASAP_ERROR Figure 1 Stewart, et al. Expires March 25, 2008 [Page 8] Internet-Draft Aggregate Server Access Protocol September 2007 2.2.1. ASAP_REGISTRATION message The REGISTRATION message is sent by a PE to its Home ENRP Server to either create a new pool or to add itself to an existing pool. The PE sending the ASAP_REGISTRATION message MUST fill in the Pool Handle parameter and the Pool Element parameter. The Pool Handle parameter specifies the name to be registered. The Pool Element parameter MUST be filled in by the registrant as outlined in Section 3.1. Note that the PE sending the registration message MUST send the message using an SCTP association. Furthermore the IP address(es) of the PE that is registered within the Pool Element parameter MUST be a subset of the IP address(es) used in the SCTP association regardless of the registered transport protocol 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 = 0x01 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pool Handle Parameter: See [8] section 3.7 Pool Element Parameter: See [8] section 3.8 2.2.2. ASAP_DEREGISTRATION message The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP Server to remove itself from a pool to which it registered. 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 = 0x02 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ Pool Handle Parameter: Stewart, et al. Expires March 25, 2008 [Page 9] Internet-Draft Aggregate Server Access Protocol September 2007 See [8] section 3.7 PE Identifier Parameter: See [8] section 3.12 The PE sending the ASAP_DEREGISTRATION MUST fill in the pool handle and the PE identifier parameter 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 a PE may only deregister itself. 2.2.3. ASAP_REGISTRATION_RESPONSE message The ASAP_REGISTRATION_RESPONSE message is sent in response by the Home ENRP Server to the PE that sent a ASAP_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 = 0x03 |0|0|0|0|0|0|0|R| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Operational Error (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R (Reject) Flag: When set to '1', this flag indicates that the ENRP server sending this message has rejected the registration. Otherwise when this flag is set to '0', this indicates the registration has been granted. Pool Handle Parameter: See [8] section 3.7. PE Identifier Parameter: See [8] section 3.12 Operational Error Parameter (optional): See [8] section 3.10 This parameter is included if an error or some atypical events occurred during the registration process. When the R flag is set to Stewart, et al. Expires March 25, 2008 [Page 10] Internet-Draft Aggregate Server Access Protocol September 2007 '1', this parameter, if present, indicates the cause of the rejection. When the R flag is set to '0', this parameter, if present, serves as a warning to the registering PE, informing it that some of its registration values may have been modified by the ENRP server. If the registration was successful and there is no warning, this parameter is not included. 2.2.4. ASAP_DEREGISTRATION_RESPONSE message The ASAP_DEREGISTRATION_RESPONSE message is returned by the Home ENRP Server to a PE in response to a ASAP_DEREGISTRATION message or due to the expiration of the registration life of the PE in the pool 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 = 0x04 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Operational Error (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pool Handle Parameter: See [8] section 3.7. PE Identifier Parameter: See [8] section 3.12. Operational Error: See [8] section 3.10. This parameter is included if an error or some atypical events occurred during the deregistration process. If the deregistration was successful this parameter is not included. 2.2.5. ASAP_HANDLE_RESOLUTION message The ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to its Home ENRP Server to resolve a pool handle into a list of pool elements that are members of the pool indicated by the pool handle. Stewart, et al. Expires March 25, 2008 [Page 11] Internet-Draft Aggregate Server Access Protocol September 2007 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 = 0x05 |0|0|0|0|0|0|0|S| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'S' bit: The 'S' bit, if set to '1', requests the Home ENRP server to send updates to this Pool dynamically when the Pool changes. Dynamic updates to the pool will consist of additional ASAP_HANDLE_RESOLUTION_RESPONSE messages, without the user needing to send in a ASAP_HANDLE_RESOLUTION. If the 'S' bit is set to '0' no dynamic updates are requested. Note that if a new Home ENRP server is adopted any 'dynamic update request' will need to be resent to the new Home ENPR server if the endpoint would like to continue to recieve updates. In other words, the ENRP servers do NOT share state regarding which of its PU's are requesting automatic update of state. Thus upon change of Home ENRP Server the PU will need to resend a ASAP_HANDLE_RESOLUTION message with the 'S' bit set to 1. Note also, that the 'S' bit will only cause dynamic update of a Pool when the Pool exists. If a negative response is returned, no further updates to the Pool (when it is created) will occur. Pool Handle parameter: See [8] section 3.7. 2.2.6. ASAP_HANDLE_RESOLUTION_RESPONSE message The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by the Home ENRP server of the PU or PE that sent a ASAP_HANDLEE_RESOLUTION message or periodically upon Pool changes if the PU as requested Dynamic updates. Stewart, et al. Expires March 25, 2008 [Page 12] Internet-Draft Aggregate Server Access Protocol September 2007 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 = 0x06 |0|0|0|0|0|0|0|A| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Overall PE Selection Policy (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter 1 (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter N (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Operational Error (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A bit: This bit is set to '1' if the ENRP server accepts the request to send automatic updates (i.e. the S bit was set on the request). If this bit is set to '0' either the ENRP server does NOT support automatic update, it has resource issues and cannot supply this feature or the user did not request it. Pool Handle parameter: See [8] section 3.7. Overall PE Selection Policy (optional): See [8] section 3.6. This parameter can be present when the response is positive. If present, it indicates the overall pool member selection policy of the pool. If not present, a round robin overall pool member selection policy is assumed. This parameter is not present when the response is negative. Note, any load policy parameter within a Pool Element Parameter (if present) MUST be ignored, and MUST NOT be used to determine the overall pool member selection policy. Pool Element Parameters (optional): See [8] section 3.10. Stewart, et al. Expires March 25, 2008 [Page 13] Internet-Draft Aggregate Server Access Protocol September 2007 When the response is positive, an array of PE parameters are included, indicating the current information about the PEs in the named pool. At least one PE parameter MUST be present. When the response is negative, no PE parameters are included. Operational Error (optional): See [8] section 3.10. The presence of this parameter indicates that the response is negative (the handle resolution request was rejected by the ENRP server). The cause code in this parameter (if present) will indicate the reason the handle resolution request was rejected (e.g., the requested pool handle was not found). The absence of this parmaeter indicates that the response is positive. 2.2.7. ASAP_ENDPOINT_KEEP_ALIVE message The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP Server to a PE. The ASAP_ENDPOINT_KEEP_ALIVE message is used to verify that the PE is reachable and requires the PE to adopt the sending server as its new Home ENRP Server if the H bit is set to 1. Regardless of the setting of the H bit, an ASAP endpoint MUST respond with an ASAP_ENDPOINT_KEEP_ALIVE_ACK to any ASAP_ENDPOINT_KEEP_ALIVE messages that arrive. 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 = 0x07 |0|0|0|0|0|0|0|H| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H (Home ENRP server) flag When set to '1', indicate that the ENRP server that sends this message want to be the home ENRP server of the receiver of this message. Server Identifier: 32 bit (unsigned integer) This is the ID of the ENRP server, as discussed in Section 3.2.1 of ENRP [9]. Pool Handle parameter: Stewart, et al. Expires March 25, 2008 [Page 14] Internet-Draft Aggregate Server Access Protocol September 2007 See [8] section 3.7. 2.2.8. ASAP_ENDPOINT_KEEP_ALIVE_ACK message The ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent by a PE in response to an ASAP_ENDPOINT_KEEP_ALIVE message sent by an 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 = 0x08 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pool Handle parameter: See [8] section 3.7. PE Identifier parameter: See [8] section 3.12. 2.2.9. ASAP_ENDPOINT_UNREACHABLE message The ASAP_ENDPOINT_UNREACHABLE message is sent by either a PE or PU to its Home ENRP Server to report an unreachable PE. 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 = 0x09 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PE Identifier Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pool Handle parameter: See [8] section 3.7. PE Identifier parameter: See [8] section 3.12. Stewart, et al. Expires March 25, 2008 [Page 15] Internet-Draft Aggregate Server Access Protocol September 2007 2.2.10. ASAP_SERVER_ANNOUNCE message The ASAP_SERVER_ANNOUNCE message is sent by an ENRP Server such that PUs and PEs know the transport information necessary to connect to the 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 = 0x0a |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Transport param #1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Transport param #2 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : ..... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Transport param #n : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Server Identifier: 32 bit (unsigned integer) This is the ID of the ENRP server, as discussed in Section 3.2.1 in ENRP [9]. Transport parameters (optional): See [8] seections 3.3 and 3.4 for the SCTP and TCP Transport parameters respectively. Only SCTP and TCP Transport parameters are allowed for use within the SERVER_ANNOUNCE message. 2.2.11. ASAP_COOKIE message The ASAP_COOKIE message is sent by a PE to a PU allowing the PE to convey information it wishes to share using a control channel. 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 = 0x0b |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Cookie Parameter : Stewart, et al. Expires March 25, 2008 [Page 16] Internet-Draft Aggregate Server Access Protocol September 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cookie Parameter : See [8] section 3.11. 2.2.12. ASAP_COOKIE_ECHO message The ASAP_COOKIE_ECHO message is sent by a PU to a new PE when it detects a failure with the current PE to aid in failover. The Cookie Parameter sent by the PE is the latest one received from the failed PE. 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 = 0x0c |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Cookie Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cookie Parameter: See [8] section 3.11. 2.2.13. ASAP_BUSINESS_CARD message The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE to a PU using a control channel to convey the pool handle and a preferred failover ordering. 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 = 0x0d |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter-1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : .. : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter-N : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pool Handle parameter: Stewart, et al. Expires March 25, 2008 [Page 17] Internet-Draft Aggregate Server Access Protocol September 2007 See [8] section 3.7. Pool Element parameters: See [8] section 3.8. 2.2.14. ASAP_ERROR message The ASAP_ERROR message is sent in response by an ASAP endpoint receiving an unknown message or an unknown parameter to the sending ASAP endpoint to report the problem or issue. 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 = 0x0e |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Operational Error Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Operation Error parameter: See [8] section 3.10 When an ASAP endpoint receives an ASAP message with an unknown message type or a message of known type that contains an unknown parameter, it SHOULD handle the unknown message or the unknown parameter according to the unrecognized message and parameter handling rules defined in Section 3. According to the rules, if an error report to the message sender is needed, the ASAP endpoint that discovered the error SHOULD send back an ASAP_ERROR message which includes an Operation Error parameter with the proper cause code, cause length, and case specific information. Stewart, et al. Expires March 25, 2008 [Page 18] Internet-Draft Aggregate Server Access Protocol September 2007 3. Procedures This section will focus on the methods and procedures used by an internal ASAP endpoint. Appropriate timers and recovery actions for failure detection and management are also discussed. Also please note that ASAP messages, sent between a PE and PU are identified by an SCTP Payload Protocol Identifier (PPID) (or equivilant mapped function if using TCP). 3.1. Registration When a PE wishes to initiate or join a server pool it MUST use the procedures outlined in this section for registration. Often, the registration will be triggered by a user request primitive (discussed in Section 4.1). The PE MUST register using an SCTP association established between itself and the Home ENRP server. If the PE has not established its Home ENRP server, it MUST follow the procedures specified in Section 3.6. Once the PE's ASAP endpoint has established its Home ENRP server the following procedures MUST be followed to register: R1) The PE's SCTP endpoint used to communicate with the Home ENRP server MUST be bound to all IP addresses that will be used by the PE (irregardless of what transport protocol will be used to service user requests to the PE). R2) The PE's ASAP endpoint MUST formulate an ASAP_REGISTRATION message as defined in Section 2.2.1. In formulating the message, the PE MUST: R2.1) Fill in the Pool Handle Parameter to specify which server pool the ASAP endpoint wishes to join. R2.2) Fill in the PE identifier using a good quality randomly generated number (RFC4086 [11] provides some information on randomness guidelines). R2.3) Fill in the Registration Life time parameter with the number of seconds that this registration is valid for. Note a PE that wishes to continue service MUST re-register after the registration expires. R2.4) Fill in a User Transport Parameter to specify the type of transport and the data/control channel usage the PE is willing to support. Note, in joining an existing server pool, the PE MUST follow the overall transport type and overall data/control channel usage of the pool. Otherwise, the registration may be Stewart, et al. Expires March 25, 2008 [Page 19] Internet-Draft Aggregate Server Access Protocol September 2007 rejected by the ENRP server. R2.5) Fill in the preferred Pool Member Selection Policy parameter. R3) Send the Registration message to the Home ENRP server using SCTP. R4) Start a T2-registration timer. Note: the PE does not need to fill in the optional ASAP transport parameter. The ASAP transport parameter will be filled in and used by the home ENRP server. If the T2-registration timer expires before receiving an ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is received from the SCTP layer, the PE 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 PE SHOULD restart the registration procedure. At the reception of the registration response, the PE MUST stop the T2-Registration timer. If the response indicates success, the PE is registered and will be considered an available member of the server pool. If the registration response indicates a failure, the PE must either re-attempt registration after correcting the error or return a failure indication to the PE's upper layer. The PE 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 (and reregistration) attempts it makes in a local variable that gets set to zero before the initial registration attempt to the Home ENRP server or after a successful re- registration.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. Stewart, et al. Expires March 25, 2008 [Page 20] Internet-Draft Aggregate Server Access Protocol September 2007 3.2. Deregistration In the event a PE wishes to deregister from its server pool (normally via an upper layer requests see Section 4.2), it SHOULD use the following procedure. It should be noted that an alternate method of deregistration is to NOT re-register and to allow the registration life of the PE to expire. In this case a ASAP_DEREGISTRATION_RESPONSE message is sent to the PE's ASAP endpoint to indicate the removal of the PE from the pool it registered. When deregistering the PE SHOULD use the SCTP association that was used for registration with its Home ENRP server. To deregister, the PE's ASAP endpoint MUST take the following actions: D1) Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION message ( Section 2.2.2) using the same Pool Handle parameter sent during registration. D2) Fill in the PE Identifier parameter of the ASAP_DEREGISTRATION message. The identifier MUST be the same as used during registration. The use of the same Pool Handle and Pool Identifier parameters used in registration allows the identity of the PE ASAP endpoint be verified before deregisteration can occur. D3) Send the ASAP_DEREGISTRATION message to the Home ENRP server using the PE's SCTP association. D4) Start a T3-Deregistration timer. If the T3-Deregistration timer expires before receiving either a ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification from the PE's SCTP endpint, the PE's ASAP endpoint shall start the ENRP Server Hunt procedure (see Section 3.6) in an attempt to get service from another ENRP server. After establishing a new Home ENRP server, the ASAP endpoint SHOULD restart the deregistration procedure. At the reception of the ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP endpoint MUST stop the T3-deregistration timer. It should be noted that after a successful deregistration the PE MAY still receive requests for some period of time. The PE MAY wish to remain active and service these requests or to exit and ignore these requests. Stewart, et al. Expires March 25, 2008 [Page 21] Internet-Draft Aggregate Server Access Protocol September 2007 3.3. Handle resolution At any time a PE or PU may wish to resolve a handle. This usually will occur when a ASAP Endpoint sends to a Pool handle ( Section 4.5.1) to its home ENRP server or requests a cache population (Section 4.3). It may also 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 ASAP Endpoint (PE or PU) wishes to resolve a pool handle to a list of accesible transport addresses of the member PEs of the pool, it MUST take the following actions: NR1) Fill in an ASAP_HANDLE_RESOLUTION message ( Section 2.2.5) with the Pool Handle to be resolved. NR2) 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) If a PE, send the ASAP_HANDLE_RESOLUTION message to the home ENRP server using SCTP or if a PU, send the ASAP_HANDLE_RESOLUTION message to the Home ENRP server using either TCP or SCTP. If sent from a PE, the SCTP association used for registration SHOULD be used. NR4) Start a T1-ENRPrequest timer. If the T1-ENRPrequest timer expires before receiving a response message, the ASAP endpoint SHOULD take the steps described in Section 3.7.2. If a SEND.FAILURE notification is received from the SCTP or TCP 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 handle resolution procedure. At the reception of the ASAP_HANDLE_RESOLUTION_RESPONSE message the ASAP endpoint MUST stop its T1-ENRPrequest timer. After stopping the T1-ENRPrequest timer the ASAP endpoint SHOULD process the message 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 handle resolutions sent. If a cache is used, it SHOULD: C1) Be consulted before sending a handle resolution. Stewart, et al. Expires March 25, 2008 [Page 22] Internet-Draft Aggregate Server Access Protocol September 2007 C2) Have a stale timeout timer associated with the cache. If the cache is determined to be stale upon a cache hit, a handle resolution message SHOULD be sent so the cache can be updated. C3) In the case of a stale cache the implementation may in parallel update the cache and answer the request or it may 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 send a handle resolution request but instead SHOULD use the entry from the cache. 3.4. Endpoint keep alive The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a PE in order to verify it is reachable. If the transport level heart beat mechanism is insufficient, this message can be used in a heart beat mechanism for the ASAP level whose goal is determining the health status of the ASAP level in a timely fashion. (The transport level heart beat mechanism may be insufficient due to either the time outs or the heart beat interval being set too long, or, that the transport level heart beat mechanism's coverage is limited only to the transport level at the two ends.) Additionally, the ASAP_ENDPOINT_KEEP_ALIVE message has value in the reliability of fault detection if the SCTP stack is in the kernel. In such a case, while SCTP level heartbeat monitors the end-to-end connectivity between the two SCTP stacks, the ASAP level heartbeat monitors the end-to-end liveliness of the ASAP layer above it. The use of the ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7) and the ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below. Upon reception of an ASAP_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 ASAP_REGISTRATION message. If the Pool Handle does not match, the PE MUST silently discard the message. KA2) Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) as follows: Stewart, et al. Expires March 25, 2008 [Page 23] Internet-Draft Aggregate Server Access Protocol September 2007 KA2.1) Fill in the Pool Handle Parameter with the PE's Pool Handle. KA2.2) Fill in the PE Identifier parameter using the PE identifier used by this PE for registration. KA2.3) Send the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the appropriate SCTP association for the ENRP server which sent the ASAP_ENDPOINT_KEEP_ALIVE message. KA2.4) If the 'H' flag in the received ASAP_ENDPOINT_KEEP_ALIVE message is set, and the Server Identifier in the message is NOT the identity of your Home ENRP server (or it is not set e.g you have a no Home ENRP server) adopt the sender of the ASAP_ENDPOINT_KEEP_ALIVE message as the new home ENRP server. 3.5. Reporting unreachable endpoints Occasionally, an ASAP endpoint may realize a PE is unreachable. This may occur by a specific SCTP error realized by the ASAP endpoint or via an ASAP user report via the Transport.Failure Primitive (Section 4.9.2). In either case, the ASAP endpoint SHOULD report the unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE message to its Home ENRP server. Before sending the ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in the Pool Handle parameter and PE identifier parameter of the unreachable endpoint. If the sender is a PE, the message MUST be sent via SCTP. It should be noted that an ASAP endpoint MUST report no more than once each time it encounters such an event. Additionally, when processing a Transport.Failure Primitive (Section 4.9.2) the ASAP endpoint MUST NOT send an ASAP_ENDPOINT_UNREACHABLE message unless the user has made a previous request to send data to the PE specified by the primitive. 3.6. ENRP server hunt procedures Each PU and PE manages a list of transport addresses of ENRP servers it knows about. If multicast capabilities are used within the operational scope an ENRP server MUST send periodically every T6-Serverannounce an ASAP_SERVER_ANNOUNCE message (Section 2.2.10) which includes all the transport addresses available for ASAP communication on the multicast ENRP client channel. If an ASAP_SERVER_ANNOUNCE message is received by a PU or PE, it SHOULD insert all new included transport addresses into its list of ENRP server addresses and start a T7-ENRPoutdate timer for each Stewart, et al. Expires March 25, 2008 [Page 24] Internet-Draft Aggregate Server Access Protocol September 2007 address. For all already known included transport addresses, the T7- ENRPoutdate timer MUST be restarted for each address. If no transport parameters are included in the ASAP_SERVER_ANNOUNCE message, the SCTP transport protocol is assumed to be used and the source IP address and the IANA registered ASAP port number is used for communication with the ENRP server. If a T7-ENRPoutdate timer for a transport address expires, the corresponding address is deleted from the managed list of transport addresses of the PU or PE. If multicast capabilities are not used within the operational scope, each PU and PE MUST have a configured list of transport addresses of ENRP servers. At its startup or when it fails to communicate with its home ENRP server (i.e., timed-out on a ENRP request), a PE or PU MUST establish a new Home ENRP server (i.e. setup a TCP connection or SCTP association with a different ENRP server). To establish a home ENRP server the following rules MUST be followed: SH1) The PE or PU SHOULD try to establish an association or connection with no more than three ENRP server's. An ASAP endpoint MUST NOT establish more than three associations or connections. SH2) The ASAP endpoint shall start a T5-Serverhunt timer. SH3) If the ASAP endpoint establishes an association or connection it MUST stop its T5-Serverhunt timer. The ASAP Endpoint SHOULD also reset the T5-Serverhunt timer to its initial value and then proceed to step SH6. SH4) If an association or connection establishment fails, the ASAP endpoint SHOULD try to establish an association or connection using a different transport address. SH5) If the T5-Serverhunt timer expires the following should be performed: SH5.1) The ASAP endpoint MUST double the value of the T5- Serverhunt timer. Note that this doubling is capped at the value RETRAN.max SH5.2) The ASAP endpoint SHOULD stop the establishment of associations and connections with the transport addresses selected in step SH1. Stewart, et al. Expires March 25, 2008 [Page 25] Internet-Draft Aggregate Server Access Protocol September 2007 SH5.2) The ASAP endpoint SHOULD repeat trying to establish an association or connection by proceeding to step SH1. It SHOULD attempt to select a different set of transport addresses with which to connect. SH6) The PE or PU shall pick one of the ENRP servers with which it was able to establish an association or connection, and send all subsequent ENRP request messages to this new Home ENRP server. 3.7. Handling ASAP Endpoint to ENRP Server Communication Failures Three types of failure may occur when the ASAP endpoint at ether PE or PU tries to communicate with an ENRP server: A) SCTP send failure B) T1-ENRPrequest timer expiration C) Registration failure 3.7.1. SCTP Send Failure This communication failure indicates that the SCTP layer was uanble to deliver a message sent to an ENRP server. In other words, the ENRP server is unreachable. In such a case, the ASAP endpoint should not re-send the undeliverable message. Instead, it should discard the message and start the ENRP server hunt procedure as described in Section 3.6 . After finding a new Home ENRP server, the ASAP endpoint should reconstruct and retransmit the request. Note that an ASAP endpoint MAY also choose to NOT discard the message, but to queue it for retransmission after a new Home ENRP server is found. If an ASAP endpoint does choose to discard the message, after a new Home ENRP server is found, the ASAP endpoint MUST be capable of reconstructing the original request. 3.7.2. T1-ENRPrequest Timer Expiration When the T1-ENRPrequest timer expires, the ASAP endpoint should resend the original request to the ENRP server and restart the T1- ENRPrequest timer. In parallel, the ASAP endpoint should begin the ENRP server hunt procedures described in Section 3.6. 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 T1- Stewart, et al. Expires March 25, 2008 [Page 26] Internet-Draft Aggregate Server Access Protocol September 2007 ENRPrequest timer should be discarded. It should be noted that if an alternate ENRP server responds the ASAP endpoint SHOULD adopt the responding ENRP server as its new Home ENRP server and resend the request to the new Home ENRP server. 3.7.3. Registration Failure Registration failure is discussed in Section 3.1. 3.8. Cookie handling procedures Whenever a PE wants, and a control channel exists, it can send an ASAP_COOKIE message to a PU via the control channel. The PU's ASAP endpoint stores the Cookie parameter and discards an older cookie if it is previously stored. Note: a control channel is a communication channel between a PU and PE that does not end in data passed to the user. This is accomplished with SCTP by using a PPID to seperate the ASAP messages (Cookie and Business Card) from normal data messages. If the PU's ASAP endpoint detects a failure and initiates a failover to a different PE, it SHOULD send the lastest received cookie parameter in an ASAP_COOKIE_ECHO message to the new PE. Upper layers may be involved in the failover procedure. The cookie handling procedure can be used for state sharing. Therefore a cookie should be signed by the sending PE ASAP endpoint and the cookie should be verified by the receiving PE's ASAP endpoint. The details of the verification procedure are out of scope for this document. It is only important that the PU always stores the last received Cookie Parameter and sends that back unmodified in case of a PE failure. 3.9. Business Card handling procedures When communication begins between a PU and a PE either of which could be part of a PU/PE combination (i.e. a message is sent between the entities), a PE should always send a ASAP_BUSINESS_CARD message to a PU. A PU should send a ASAP_BUSINESS_CARD message to a PE only if it is part of a PU/PE combination. A ASAP_BUSINESS_CARD message MUST ONLY be sent if a control channel exists between a PU and PE. After communication as been established between a PE and PU, a new ASAP_BUSINESS_CARD message may be sent at any time by either entity to update its failover order. The ASAP_BUSINESS_CARD message serves two purposes. First it lists the pool handle. For a PU which is part of a PU/PE combination which Stewart, et al. Expires March 25, 2008 [Page 27] Internet-Draft Aggregate Server Access Protocol September 2007 is contacting a PE this is essential so that the PE learns the pool handle of the PU/PE combination requesting service. Secondly the ASAP_BUSINESS_CARD message tells the receiving entity a failover order that is recommended to follow. This should facilitate rendezvous between entities that have been working togehter as well to control the load redistribution upon the failure of any PE. Upon receipt of an ASAP_BUSINESS_CARD message (see Section 2.2.13) the receiving ASAP endpoint SHOULD: BC1) Unpack the message and if no entry exists in the translation cache of the receiving ASAP endpoint for the pool handle listed within the ASAP_BUSINESS_CARD message perform a ASAP_HANDLE_RESOLUTION for that pool handle. If the translation cache does hold an entry for the pool handle, then it may be necessary to update the peer endpoint. BC2) Unpack the message and populate a preferred list for failover order. If the peers PE should fail this preferred list will be used guide the ASAP endpoint in the selection of an alternate PE. Stewart, et al. Expires March 25, 2008 [Page 28] Internet-Draft Aggregate Server Access Protocol September 2007 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). Note, the following primitive and notification descriptions are shown for illustrative purposes. We believe that including these descriptions in this document is important to the understanding of the operation of many aspects of ASAP. But an ASAP implementation is not required to use the exact syntax described in this section. 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 layer 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 handlespace, 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 handlespace can send message(s) to this ASAP user by Pool Handle or by PE handle (see Section 4.5.1 and Section 4.5.3). In response to the registration primitive, the ASAP endpoint will send an ASAP_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 Server Pool. This should be used as a part of the graceful shutdown process Stewart, et al. Expires March 25, 2008 [Page 29] Internet-Draft Aggregate Server Access Protocol September 2007 by the application. A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the home ENRP server (see Section 2.2.2 and Section 3.2). 4.3. CachePopulateRequest Primitive Format: cache_populate_request([Pool-Handle | Pool-Element-Handle]) If the address type is a Pool handle and a local handle translation cache exists, the ASAP endpoint should initiate a mapping information query by sending an ASAP_HANDLE_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 ASAP_HANDLE_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. CachePurgeRequest Primitive Format: cache_purge_request([Pool-Handle | Pool-Element-Handle]) If the user passes a Pool handle and local handle 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. DataSendRequest 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 Stewart, et al. Expires March 25, 2008 [Page 30] Internet-Draft Aggregate Server Access Protocol September 2007 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 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 ASAP_HANDLE_RESOLUTION message (see Section 2.2.5 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, Stewart, et al. Expires March 25, 2008 [Page 31] Internet-Draft Aggregate Server Access Protocol September 2007 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 [3] 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 [9]. 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 3.7 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 handlespace with a new policy value. Re-registration shall be done by simply sending another ASAP_REGISTRATION to its home ENRP server (See Section 2.2.1). One basic policy is defined in this document, others can be found in [7] 4.5.2.1. Round Robin Policy When an 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 Stewart, et al. Expires March 25, 2008 [Page 32] Internet-Draft Aggregate Server Access Protocol September 2007 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.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 dependent 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: i) ask the home ENRP server for handle resolution on pool handle by sending an ASAP_HANDLE_RESOLUTION message (see Section 2.2.5), 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 5.2). Section 3.5 and Section 4.9 defines the fail-over procedures for cases where the PE pointed to by the Pool Element handle is found Stewart, et al. Expires March 25, 2008 [Page 33] Internet-Draft Aggregate Server Access Protocol September 2007 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, the sender's ASAP endpoint SHOULD re- select an alternate PE from the same pool if one exists, and silently re-send the message to this newly selected endpoint. Note that this is a best-effort service. Applications should be aware that messages can be lost during the failover process, even if the underlying transport supports retrieval of unacknowledged data (e.g. SCTP) (Example: messages acknowledged by the SCTP layer at a PE, but not yet read by the PE when a PE failure occurs.) In the case where the underlying transport does not support such retrieval (e.g. TCP), any data already submitted by ASAP to the transport layer MAY be lost upon failover. Stewart, et al. Expires March 25, 2008 [Page 34] Internet-Draft Aggregate Server Access Protocol September 2007 ASAP_SEND_NO_FAILOVER: 0x0002 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 an ASAP Pool Element handle. A) If the handle 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. Stewart, et al. Expires March 25, 2008 [Page 35] Internet-Draft Aggregate Server Access Protocol September 2007 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. 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). Stewart, et al. Expires March 25, 2008 [Page 36] Internet-Draft Aggregate Server Access Protocol September 2007 ENRP Server PU new-handle:PEx | | | | +---+ | | | 1 | | |2. ASAP_HANDLE_RESOLUTION +---+ | |<-------------------------------| | | +---+ | | | 3 | | |4. ASAP_HANDLE_RESOLUTION_RSP +---+ | |------------------------------->| | | +---+ | | | 5 | | | +---+ 6. "hello1" | | |---------------->| | | | 1) The user at PU invokes: data_send_request("new-handle", handle-type, "hello1", 6, 0); The ASAP endpoint, in response, looks up the pool "new-handle" in its local cache but fails to find it. 2) The ASAP endpoint of PU queues the message, and sends an ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all information about pool "new-handle". 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 an ASAP_HANDLE_RESOLUTION_RESPONSE message that contains all the information about pool "new-handle". 5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local cache with information on pool "new-handle". 6) Based on the server pooling policy of pool "new-handle", 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. Stewart, et al. Expires March 25, 2008 [Page 37] Internet-Draft Aggregate Server Access Protocol September 2007 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-handle" after what happened in Section 4.8.1. ENRP Server PU new-handle:PEx | | | | +---+ | | | 1 | | | +---+ 2. "hello2" | | |---------------->| | | | 1) The user at PU invokes: pdata_send_request("new-handle", handle-type, "hello2", 6, 0); The ASAP endpoint, in response, looks up the pool "new-handle" in its local cache and find the mapping information. 2) Based on the server pooling policy of "new-handle", ASAP at PU selects the PE (assume EPx is selected again), and sends out "hello2" message (assume the SCTP association is already set up). 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 handle 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 handle cache or no Stewart, et al. Expires March 25, 2008 [Page 38] Internet-Draft Aggregate Server Access Protocol September 2007 handle cache exists, the ASAP endpoint will send an ASAP_HANDLE_RESOLUTION request using the Pool handle. Upon completion of the handle resolution, the ASAP endpoint should populate the local handle cache (if a local handle 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 an ASAP_ENDPOINT_UNREACHABLE to the "home" ENRP server in response to this primitive. Note ASAP SHOULD NOT send a ASAP_ENDPOINT_UNREACHABLE UNLESS the user has actually made a previous request to send data to the PE. Stewart, et al. Expires March 25, 2008 [Page 39] Internet-Draft Aggregate Server Access Protocol September 2007 5. Timers, Variables, and Thresholds The following is a summary of the timers, variables, 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 an ASAP_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 registration into the ENRP handle 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 during the ENRP server hunt procedure and is normally set to 10 seconds. T6-Serverannounce - This timer gives the time between the sending of consecutive ASAP_SERVER_ANNOUNCE messages. It is normally set to 1 second. T7-ENRPoutdate - This timer gives the time a server announcement is valid. It is normally set to 5 seconds. 5.2. Variables stale_cache_value - A threshold variable that indicates how long a cache entry is valid for. 5.3. Thresholds MAX-REG-ATTEMPT - The maximum number of registration attempts to be made before a server hunt is issued. The default value of this is set to 2. 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. The default value for this is 2. Stewart, et al. Expires March 25, 2008 [Page 40] Internet-Draft Aggregate Server Access Protocol September 2007 RETRAN-MAX - This value represents the maximum time between registration attmempts and puts a ceiling on how far the registration timer will back-off. The default value for this is normally set to 60 seconds. Stewart, et al. Expires March 25, 2008 [Page 41] Internet-Draft Aggregate Server Access Protocol September 2007 6. IANA Considerations [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you assign this document. ] This document (RFCXXX) is the reference for all registrations described in this section. All registrations need to be listed on an RSerPool specific page. 6.1. A New Table for ASAP Message Types ASAP Message Types have to be maintained by IANA. Fourteen initial values should be assigned by IANA as described in Figure 1. This requires a new table "ASAP Message Types": Type Message Name Reference ----- ------------------------- --------- 0x00 (reserved by IETF) RFCXXXX 0x01 ASAP_REGISTRATION RFCXXXX 0x02 ASAP_DEREGISTRATION RFCXXXX 0x03 ASAP_REGISTRATION_RESPONSE RFCXXXX 0x04 ASAP_DEREGISTRATION_RESPONSE RFCXXXX 0x05 ASAP_HANDLE_RESOLUTION RFCXXXX 0x06 ASAP_HANDLE_RESOLUTION_RESPONSE RFCXXXX 0x07 ASAP_ENDPOINT_KEEP_ALIVE RFCXXXX 0x08 ASAP_ENDPOINT_KEEP_ALIVE_ACK RFCXXXX 0x09 ASAP_ENDPOINT_UNREACHABLE RFCXXXX 0x0a ASAP_SERVER_ANNOUNCE RFCXXXX 0x0b ASAP_COOKIE RFCXXXX 0x0c ASAP_COOKIE_ECHO RFCXXXX 0x0d ASAP_BUSINESS_CARD RFCXXXX 0x0e ASAP_ERROR RFCXXXX 0x0b-0xff (reserved by IETF) RFCXXXX For registering at IANA an ASAP Message Type in this table a request has to be made to assign such a number. This number must be unique. The "Specification Required" policy of RFC2434 [2] MUST be applied. Stewart, et al. Expires March 25, 2008 [Page 42] Internet-Draft Aggregate Server Access Protocol September 2007 7. Security Considerations We present a summary of the of the threats to the Rserpool architecture and describe security requirements in response to mitigate the threats. Next we present the security mechanisms, based on TLS, that are implementation requirements in response to the threats. Finally, we present a chain of trust argument that examines critical data paths in Rserpool and shows how these paths are protected by the TLS implementation. 7.1. Summary of Rserpool Security Threats Threats Introduced by Rserpool and Requirements for Security in Response to Threats [10] describes the threats to the Rserpool architecture in detail lists the security requirements in response to each threat. From the threats described in this document, the security services required for the Rserpool protocol are enumerated below. Threat 1) PE registration/deregistration flooding or spoofing ----------- Security mechanism in response: ENRP server authenticates the PE Threat 2) PE registers with a malicious ENRP server ----------- Security mechanism in response: PE authenticates the ENRP server Threat 1 and 2 taken together results in mutual authentication of the ENRP server and the PE. Threat 3) Malicious ENRP server joins the ENRP server pool ----------- Security mechanism in response: ENRP servers mutually authenticate Threat 4) A PU communicates with a malicious ENRP server for handle resolution ----------- Security mechanism in response: The PU authenticates the ENRP server Threat 5) Replay attack ----------- Security mechanism in response: Security protocol which has protection from replay attacks Threat 6) Corrupted data which causes a PU to have misinformation concerning a pool handle resolution ----------- Security mechanism in response: Security protocol which supports Stewart, et al. Expires March 25, 2008 [Page 43] Internet-Draft Aggregate Server Access Protocol September 2007 integrity protection Threat 7) Eavesdropper snooping on handlespace information ----------- Security mechanism in response: Security protocol which supports data confidentiality Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to ENRP server ----------- Security mechanism in response: ASAP must control the number of ASAP endpoint unreachable messages transmitted from the PU to the ENRP server. Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from the ENRP server ----------- Security mechanism in response: ENRP server must control the number of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE To summarize the threats 1-7 require security mechanisms which support authentication, integrity, data confidentiality, protection from replay attacks. For Rserpool we need to authenticate the following: PU <---- ENRP Server (PU authenticates the ENRP server) PE <----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication) 7.2. Implementing Security Mechanisms We do not define any new security mechanisms specifically for responding to threats 1-7. Rather we use an existing IETF security protocol, specifically [4], to provide the security services required. TLS supports all these requirements and MUST be implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a minimum by implementors of TLS for Rserpool. For purposes of backwards compatibility, ENRP SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other IETF approved ciphersuites. ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must support mutual authentication. ENRP servers must support mutual authentication among themselves. PUs MUST authenticate ENRP servers. ENRP servers and PEs SHOULD possess a site certificate whose subject corresponds to their canonical hostname. PUs MAY have certificates Stewart, et al. Expires March 25, 2008 [Page 44] Internet-Draft Aggregate Server Access Protocol September 2007 of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use. All Rserpool elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates comparable to those that issue root certificates for web browsers). Implementations MUST support TLS with SCTP as described in [5] 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. Threat 8 requires the ASAP protocol to limit the number of ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in this document) to the ENRP server. Threat 9 requires the ENRP protocol to limit the number of ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see [9]). 7.3. Chain of trust Security is mandatory to implement in Rserpool and is based on TLS implementation in all three architecture components that comprise Rserpool -- namely PU, PE and ENRP server. We define an ENRP server that uses TLS for all communication and authenticates ENRP peers and PE registrants to be a secured ENRP server. Here is a description of all possible data paths and a description of the security. PU <---> secured ENRP Server (authentication of ENRP server; queries over TLS) PE <---> secured ENRP server (mutual authentication; registration/deregistration over TLS) secured ENRP server <---> secured ENRP server (mutual authentication; database updates using TLS) If all components of the system authenticate and communicate using TLS, the chain of trust is sound. The root of the trust chain is the ENRP server. If that is secured using TLS, then security will be enforced for all ENRP and PE components that try to connect to it. Summary of interaction between secured and unsecured components: If Stewart, et al. Expires March 25, 2008 [Page 45] Internet-Draft Aggregate Server Access Protocol September 2007 the PE does not use TLS and tries to register with a secure ENRP server, it will receive an error message response indicated as error due to security considerations and the registration will be rejected. If an ENRP server which does not use TLS tries to update the database of a secure ENRP server, then the update will be rejected. If an PU does not use TLS and communicates with a secure ENRP server, it will get a response with the understanding that the response is not secure as the response can be tampered with in transit even if the ENRP database is secured. The final case is the PU sending a secure request to ENRP. It might be that ENRP and PEs are not secured and this is an allowable configuration. The intent is to secure the communication over the Internet between the PU and the ENRP server. Summary: Rserpool architecture components can communicate with each other to establish a chain of trust. Secured PE and ENRP servers reject any communications with unsecured ENRP or PE servers. If the above is enforced, then a chain of trust is established for the Rserpool user. Stewart, et al. Expires March 25, 2008 [Page 46] Internet-Draft Aggregate Server Access Protocol September 2007 8. Acknowledgments The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, Thomas Dreibholz, and many others for their invaluable comments and feedback. Stewart, et al. Expires March 25, 2008 [Page 47] Internet-Draft Aggregate Server Access Protocol September 2007 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [3] 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. [4] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002. [5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002. [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [7] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies", draft-ietf-rserpool-policies-05 (work in progress), July 2007. [8] Stewart, R., "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", draft-ietf-rserpool-common-param-12 (work in progress), July 2007. [9] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", draft-ietf-rserpool-enrp-16 (work in progress), July 2007. [10] Gopal, R., Guttman, E., Holdrege, M., Sengodan, S., and M. Stillman, "Threats Introduced by Rserpool and Requirements for Security in response to Threats", draft-ietf-rserpool-threats-08 (work in progress), September 2007. Stewart, et al. Expires March 25, 2008 [Page 48] Internet-Draft Aggregate Server Access Protocol September 2007 9.2. Informative References [11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. Stewart, et al. Expires March 25, 2008 [Page 49] Internet-Draft Aggregate Server Access Protocol September 2007 Authors' Addresses Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA Phone: Email: rrs@cisco.com Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA Phone: Email: qxie1@email.mot.com Maureen Stillman Nokia 127 W. State Street Ithaca, NY 14850 USA Phone: Email: maureen.stillman@nokia.com Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany Email: tuexen@fh-muenster.de Stewart, et al. Expires March 25, 2008 [Page 50] Internet-Draft Aggregate Server Access Protocol September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stewart, et al. Expires March 25, 2008 [Page 51]