Network Working Group R. R. Stewart INTERNET-DRAFT Cisco Systems Inc. Q. Xie Motorola expires in six months November 19,2001 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]. 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 management, and fault management while ENRP defines the high availability name translation service. Stewart, Xie [Page 1] Internet Draft Aggregate Server Access Protocol November 2001 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 2. Conventions................................................5 3. Message Definitions........................................5 3.1 ASAP Parameter Formats.................................6 3.1.1 IPv4 Address Parameter...........................7 3.1.2 IPv6 Address Parameter ..........................7 3.1.3 Pool Element Parameter...........................7 3.1.4 Pool Handle Parameter............................8 3.1.5 Authorization Parameter..........................8 3.2 ASAP Message Formats...................................9 3.2.1 REGISTRATION message.............................10 3.2.2 DEREGISTRATION message...........................10 3.2.3 REGISTRATION_RESPONSE message....................11 3.2.4 NAME_RESOLUTION message..........................11 3.2.5 NAME_RESOLUTION_RESPONSE message.................12 3.2.6 NAME_UNKNOWN message.............................12 3.2.7 ENDPOINT_KEEP_ALIVE message......................12 3.2.8 ENDPOINT_UNREACHABLE message ....................12 3.2.9 SERVER_HUNT message .............................13 3.2.10 SERVER_HUNT_RESPONSE message....................13 4. The ASAP Interfaces........................................13 4.1 Registration.Request Primitive.........................13 4.2 Deregistration.Request Primitive.......................14 4.3 Cache.Populate.Request Primitive.......................14 4.4 Cache.Purge.Request Primitive..........................14 4.5 Data.Send.Request Primitive............................14 4.5.1 Sending to a Pool Handle.........................15 4.5.2 Pool Element Selection...........................16 4.5.2.1 Round Robin Policy.......................16 4.5.2.2 Least Used Policy........................17 4.5.2.3 Least Used with Degradation Policy.......17 4.5.2.4 Weighted Round Robin Policy..............17 4.5.3 Sending to a Pool Element Handle.................17 4.5.4 Send by Transport Address........................18 4.5.5 Message Delivery Options........................18 4.6 Data.Received Notification.............................19 4.7 Error.Report Notification..............................20 4.8 Examples...............................................20 4.8.1 Send to a New Pool Handle........................20 4.8.2 Send to a Cached Pool Handle.....................21 4.9 Handle ASAP to ENRP Communication Failures.............22 4.9.1 SCTP Send Failure................................22 4.9.2 T1-ENRPrequest Timer Expiration..................22 4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages..............22 4.9.4 Home ENRP Server Hunt............................23 5. Variables, Timers, and Constants...........................23 5.1 Timers.................................................23 5.2 Thresholds.............................................23 6. Security Considerations....................................24 7. References.................................................24 Stewart, Xie [Page 2] Internet Draft Aggregate Server Access Protocol November 2001 8. Acknowledgements...........................................24 9. Authors' Addresses.........................................24 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 availiablity 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: 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. Stewart, Xie [Page 3] Internet Draft Aggregate Server Access Protocol November 2001 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. 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. 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. ENRP name domain: Defined by the combination of the ENRP client channel and the 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). Stewart, Xie [Page 4] Internet Draft Aggregate Server Access Protocol November 2001 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 IP address of the Japanese server pool domain, that is, the address of an ENRP server(s) in Japan. From there the PU would query the ENRP server and then directly contact the PE(s) of interest. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Message 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. Stewart, Xie [Page 5] Internet Draft Aggregate Server Access Protocol November 2001 3.1 ASAP Parameter Formats ASAP parameters are defined in a Type-length-value (TLV) format as shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Parameter Value : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Parameter Type: 16 bits (unsigned integer) The Type field is a 16 bit identifier of the type of parameter. It takes a value of 0 to 65534. The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific SCTP chunk description are reserved for use by IETF. Parameter Length: 16 bits (unsigned integer) The Parameter Length field contains the size of the parameter in bytes, including the Parameter Type, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes. Parameter Value: variable-length. The Parameter Value field contains the actual information to be transferred in the parameter. The total length of a parameter (including Type, Parameter Length and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the Parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is not included in the parameter length field. A sender SHOULD NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. The Parameter Types are encoded such that the highest-order two bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type. 00 - Stop processing this ASAP message and discard it, do not process any further parameters within it. 01 - Stop processing this ASAP message and discard it, do not process Stewart, Xie [Page 6] Internet Draft Aggregate Server Access Protocol November 2001 any further parameters within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' error. 10 - Skip this parameter and continue processing. 11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' error. In the following sections, we define the common parameter formats used in ASAP. 3.1.1 IPv4 Address Parameter 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Address: 32 bits (unsigned integer) Contains an IPv4 address of the sending endpoint. It is binary encoded. 3.1.2 IPv6 Address Parameter 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x2 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Address: 128 bit (unsigned integer) Contains an IPv6 address of the sending endpoint. It is binary encoded. 3.1.3 Pool Element Parameter This parameter is used in multiple ASAP message to represent an ASAP endpoint (i.e., a PE in a pool) and the associated information, such as its transport address(es), load control, and other operational Stewart, Xie [Page 7] Internet Draft Aggregate Server Access Protocol November 2001 status information of the 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 = 0x3 | Length=variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCTP Port | Number of IP addrs=k | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IP addr param #0 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IP addr param #1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : ..... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IP addr param #k : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Load Policy Type | Policy Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Life | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each of the IP address parameters in a PE parameter can be either an IPv4 or IPv6 address parameter. 3.1.4 Pool Handle Parameter 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x4 | Length=variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Pool Handle : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This parameter holds a pool handle that is a NULL terminated ASCII string. 3.1.5 Authorization Parameter 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x5 | Length=variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Authorization Signature : Stewart, Xie [Page 8] Internet Draft Aggregate Server Access Protocol November 2001 : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This parameter is used to hold an authorization signature. The signature is signed over the entire ASAP message and uses a preconfigured public/private key pair. The receiver of a message which includes this parameter can validate the message is from the sender by comparing the signature to one generated using the peers public key. 3.2 ASAP Message Formats The figure below illustrates the common format for all ASAP messages. Each message is formatted with a Message Type field, a message-specific Flag field, a Message Length field, and a Value field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Msg Flags | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Message Value : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type: 8 bits (unsigned integer) This field identifies the type of information contained in the Message Value field. It takes a value from 0 to 254. The value of 255 is reserved for future use as an extension field. Message Types are encoded such that the highest-order two bits specify the action that must be taken if the message receiver does not recognize the Message Type. 00 - Stop processing this message and discard it. 01 - Stop processing this message and discard it, and report the unrecognized message in an 'Unrecognized Parameter Type' error. 10 - reserved. 11 - reserved. Message Flags: 8 bits The usage of these bits depends on the message type as given by the Message Type. Unless otherwise specified, they are set to zero on transmit and are ignored on receipt. Stewart, Xie [Page 9] Internet Draft Aggregate Server Access Protocol November 2001 Message Length: 16 bits (unsigned integer) This value represents the size of the message in bytes including the Message Type, Message Flags, Message Length, and Message Value fields. Therefore, if the Message Value field is zero-length, the Length field will be set to 4. The Message Length field does not count any padding. Message Value: variable length The Message Value field contains the actual information to be transferred in the message. The usage and format of this field is dependent on the Message Type. The total length of a message (including Type, Length and Value fields) MUST be a multiple of 4 bytes. If the length of the message is not a multiple of 4 bytes, the sender MUST pad the message with all zero bytes and this padding is not included in the message length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes. 3.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 = 0x1 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 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 transport addresses, server pooling policy and value, and other operation preferences. 3.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 = 0x2 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter : Stewart, Xie [Page 10] Internet Draft Aggregate Server Access Protocol November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PE sending the DEREGISTRATION shall fill in the pool handle and the PE Parameter in order to allow the ENRP server to verify the identity of the endpoint. 3.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 | Result code | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Action: (8 bits) The message that this results code is in response to: 0x0 -- registration 0x1 -- de-registration Result code: (8 bits) 0x0 -- request granted 0x1 -- request denied, unspecifed 0x2 -- request denied, authorization failure 0x3 -- request denied, invalid values Reserved: (16 bits) Ignored by the receiver and set to 0 by the sender. 3.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 = 0x4 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart, Xie [Page 11] Internet Draft Aggregate Server Access Protocol November 2001 3.2.5 NAME_RESOLUTION_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 = 0x5 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter 1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter N : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.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 = 0x6 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.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 = 0x8 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.8 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 = 0x9 |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Handle Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Pool Element Parameter : Stewart, Xie [Page 12] Internet Draft Aggregate Server Access Protocol November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.9 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 = 0xa |0|0|0|0|0|0|0|0| Message Length : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.10 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 = 0xb |0|0|0|0|0|0|0|0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Authorization Parameter (optional) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. The ASAP Interfaces This chapter will focus primarily on the primitives and notifications that form the interface between the ASAP-user and the ASAP and that between ASAP and its lower layer transport protocol (e.g., SCTP). Appropriate timers and recovery actions for failure detection and management are also discussed. 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) where the poolHandle parameter contains a NULL terminated ASCII string of fixed length. 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). Stewart, Xie [Page 13] Internet Draft Aggregate Server Access Protocol November 2001 In response to the registration primitive, the ASAP layer will send a REGISTRATION message to the home ENRP server (See section 3.2.1), and 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 layer shall start the Server Hunt procedure (see Section 4.9.4) in an attempt to get service from a different ENRP server. 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 by the application. A DEREGISTRATION message will be sent by ASAP layer to the home ENRP server (see Section 3.2.2). 4.3 Cache.Populate.Request Primitive Format: cache.populate.request(destinationAddress, typeOfAddress) If the address type is a Pool handle and a local name translation cache exists, the ASAP layer 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. The destinationAddress field contains the address for which the cache needs to be populated. The typeOfAddress indicates the address type. Allowable types are Pool handle and Pool Element handle. In the case of a Pool Element handle, the Pool handle is extracted from the Pool Element handle and used to form a NAME.RESOLUTION message (see Section 3.5). 4.4 Cache.Purge.Request Primitive Format: cache.purge.request(destinationAddress, typeOfAddress) If the address type is a Pool handle and local name translation cache exists, the ASAP layer should remove the mapping information on the Pool handle from its local cache. 4.5 Data.Send.Request Primitive Format: data.send.request(destinationAddress, typeOfAddress, Stewart, Xie [Page 14] Internet Draft Aggregate Server Access Protocol November 2001 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 sender's ASAP layer may perform address translation and Pool Element selection before sending the message out. 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 sender's ASAP layer 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 sender's 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 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 sender's 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 layer of the sender based on the server pooling policy as discussed in section 4.5.2. C) if no transport association exists towards the destination PE, ASAP will establish a new transport association, NOTE: if the underlying SCTP implementation supports implicit association setup, this step is not needed (see [SCTP-API]). D) send out the queued message(s) to the SCTP association using the SEND primitive (see [RFC2960]), and, Stewart, Xie [Page 15] Internet Draft Aggregate Server Access Protocol November 2001 E) 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 SCTP association id, if a new association was created. For more on the ENRP server request procedures see [ENRP]. Optionally, the ASAP layer 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 sender's ASAP layer 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). When joining a pool, along with its registration each PE specifies its preferred server pooling policy for receiving messages sent to this pool. But only the server pooling policy specified by the first PE joining the pool will become the current server pooling policy of the group. Moreover, 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. Note, if this first PE removes itself from the pool (e.g., by de-registration from the name space) and the remaining PEs have specified conflicting server pooling policies at their corresponding registrations, it is implementation specific to determine the new current server pooling policy. 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 Stewart, Xie [Page 16] Internet Draft Aggregate Server Access Protocol November 2001 When a ASAP endpoint sends messages by Pool Handle and Round-Robin is the current policy of that Pool, the ASAP layer 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 layer 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. 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 (see section ?). 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 layer to deliver the message to the PE identified by the Pool Element handle. The Pool Element handle should contain the poolHandle and a Stewart, Xie [Page 17] Internet Draft Aggregate Server Access Protocol November 2001 destination transport address of the destination PE or the poolHandle and the SCTP 'association id'. The ASAP layer shall use the transport address to identify the SCTP association (or to setup a new one if necessary) and then invoke the SCTP SEND primitive 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 name resolution on pool handle by sending a NAME.RESOLUTION message, 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'. Section 4.5.5? defines the fail-over procedures for cases where the PE pointed to by the Pool Element handle is found unreachable. Optionally, the ASAP layer may return the actual Pool Elment 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 an SCTP transport address. This directs the sender's ASAP layer 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 layer. 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 sender's ASAP layer on special handling of the message delivery. The value of the Options parameter is generated by bit-wise Stewart, Xie [Page 18] Internet Draft Aggregate Server Access Protocol November 2001 "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 sender's ASAP layer to re-select an alternate PE from the same pool if one exists, and silently re-send the message to this newly selected endpoint. Endpoint unreachable is normally indicated by the SCTP COMMUNICATION.LOST or SEND.FAILURE notification. ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the sender's ASAP layer 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 sender's ASAP layer 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 sender's ASAP layer 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 sender's ASAP layer 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 sender's ASAP layer also deliver a copy of the message to itself if the sender is a PE of the pool (i.e., loopback). ASAP_SCTP_UNORDER: 0x1000 This option instructs the SCTP transport layer to send the current message using un-ordered delivery. 4.6 Data.Received Notification Format: data.received(messageReceived, sizeOfMessage, senderAddress, typeOfAddress) Stewart, Xie [Page 19] Internet Draft Aggregate Server Access Protocol November 2001 When a new user message is received, the ASAP layer of the receiver uses this notification to pass the message to its upper layer. Along with the message being passed, the ASAP layer of the receiver should also indicate to its upper layer the message sender's address. The sender's address can be in the form of either an SCTP association id, or a ASAP Pool Element handle. A) If the name translation local cache is implemented at the receiver's ASAP layer, a reverse mapping from the sender's IP address to the pool handle should be performed and if the mapping is successful, the sender's 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 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 (see Section ? for details). 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 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 +---+ | |<-------------------------------| | Stewart, Xie [Page 20] Internet Draft Aggregate Server Access Protocol November 2001 | +---+ | | | 3 | | | 4. NAME_RESOLUTION_REPONSE +---+ | |------------------------------->| | | +---+ | | | 5 | | | +---+ 6. "hello1" | | |---------------->| | | | 1) The user at PU invokes: data.send.request("new-name", name-type, "hello1", 6, 0); The ASAP layer, in response, looks up the pool "new-name" in its local cache but fails to find it. 2) The ASAP layer 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 layer 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: Stewart, Xie [Page 21] Internet Draft Aggregate Server Access Protocol November 2001 data.send.request("new-name", name-type, "hello2", 6, 0); The ASAP layer, 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). 4.9 Handle ASAP to ENRP Communication Failures Three types of failure may occur when the ASAP layer 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.9.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 layer 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 ?. 4.9.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 ?. 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. 4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages At times, an ASAP endpoint may receive ENDPOINT_KEEP_ALIVE messages (see Section 3.2.7?) from the ENRP server. This message requires no response and should be silently discarded by the ASAP layer. Stewart, Xie [Page 22] Internet Draft Aggregate Server Access Protocol November 2001 4.9.4 Home ENRP Server Hunt 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. The PE or PU shall multicast a SERVER_HUNT message over the ENRP client channel, and shall repeat sending this message every seconds until a SERVER_HUNT_RESPONSE message is received from an ENRP server. Then the PE or PU shall pick one of the ENRP servers that have responded as its new home ENRP server, and send all its subsequent the namespace service requests to 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. 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-registration-reattempt - If the registration cycle does not complete, this timer is begun to restart the registration process. Normal value for this timer is 10 minutes. T4-reregistration - This timer is started after successful 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. 5.2 Thresholds Timeout-registration - pre-set threshold; how long an PE will wait for the REGISTRATION_RESPONSE from its home ENRP server. Timeout-server-hunt - pre-set threshold; how long a PE will wait for the REGISTRATION_RESPONSE from its home ENRP server. Stewart, Xie [Page 23] Internet Draft Aggregate Server Access Protocol November 2001 num-of-serverhunts - The current count of server hunt messages that have been transmitted. registration-count - The current count of attempted registrations. 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. 6. Security Considerations To be determined. 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," , October 2000. [ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol", draft-ietf-rserpool-enrp-01.txt, work in progress. [SCTP-API] 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. 8. Acknowledgements The authors wish to thank John Loughney, Lyndon Ong, and Maureen Stillman and many others for their invaluable comments. 9. Authors' Addresses Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012 USA Phone: +1-815-477-2127 EMail: rrs@cisco.com Stewart, Xie [Page 24] Internet Draft Aggregate Server Access Protocol November 2001 Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA Phone: +1-847-632-3028 EMail: qxie1@email.mot.com Stewart, Xie [Page 25]