Network Working Group Ram Gopal.L INTERNET DRAFT Senthil Sengodan Nokia Expires January, 2002 July 10, 2001 Aggregate Server Access Protocol Candidate (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. 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. Abstract The goal is to develop Reliable server pooling protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. This document describes the ASAP protocol and details the how it is used in conjunction with ENRP protocol. Table of Contents 1. Introduction..............................................3 1.1 Terminology...............................................4 1.2 Architectural ............................................4 2 Protocol Overview.........................................7 2.1 Choosing the ENRP server address for registration.........7 2.2 PE Registration, update and deRegistration................7 2.3 PE Health check...........................................8 2.4 NAME-RESOLUTION Request...................................8 2.4.1 PU query load distribution................................8 2.5 Communication between PE and PU .........................8 3 Message Overview..........................................8 4 Request..................................................10 Ram & Senthil [Page 1] Internet Draft Aggregate Server Access Protocol July 2001 4.1 Request-Line.............................................10 4.2 Method...................................................10 4.2.1 PE-REGISTRATION..........................................11 4.2.2 NAME-RESOLUTION..........................................11 4.2.3 HEARTBEAT................................................11 4.2.4 UPDATE...................................................11 4.2.5 NS-DOWNLOAD..............................................12 4.2.6 DATA.....................................................12 5 Response ...............................................12 5.1 Status-Line..............................................13 5.1.2 Status Codes and Reason Phrases..........................13 6 Header Field Definitions.................................14 6.1 Allow....................................................15 6.2 PE-Parameters ...........................................15 6.3 Policy...................................................16 6.4 Periodic-Update..........................................16 6.5 Pool-Handle..............................................16 6.6 NS-Parameter.............................................17 6.7 Transaction-ID...........................................17 6.8 Expires..................................................17 6.9 Security Related Headers.................................17 6.9.1 WWW-Authenticate.........................................17 6.9.2 Authorization............................................18 6.9.3 Authentication-Info......................................19 6.9.4 Encryption...............................................19 6.9.5 Require..................................................19 6.9.6 Response-Key.............................................19 7 Status Code Definitions..................................20 7.1 Successful 2xx...........................................20 7.1.1 200 OK...................................................20 7.2 Request Failure 4xx......................................20 7.2.1 400 Bad Request..........................................20 7.2.2 401 Unauthorized.........................................20 7.2.3 403 Method Not Allowed...................................21 7.2.4 404 Not Found............................................21 7.2.5 406 Request Timeout......................................21 7.2.6 408 Gone.................................................21 7.2.7 409 Request Entity Too Large.............................21 7.3 Server Failure 5xx.......................................22 7.3.1 500 Server Internal Error................................22 7.3.2 501 Not Implemented......................................22 7.3.3 502 Service Unavailable..................................22 7.3.4 503 Version Not Supported................................22 8. Behavior of PE ..........................................22 8.1 Interaction between PE and ENRP Server...................22 8.1.1 Registering Entity Resolves the ENRP server with which to Register........................................23 8.1.2 PE needs to be registered with an ENRP server............23 8.1.3 PE De-Registering itself with an ENRP server............24 8.1.4 PE Updating Registration with ENRP server...............25 Ram & Senthil [Page 2] Internet Draft Aggregate Server Access Protocol July 2001 8.1.5 ENRP Server sends a Heartbeat Request to PE..............25 8.1.6 PE responding to the Heartbeat Request...................26 8.1.7 ENRP Server receives an PE registration message ........26 8.1.8 ENRP Server Updates ENRP server status to PE ...........27 8.1.8.1 New ENRP Registration Notification.......................28 8.1.8.2 ENRP Registration Update.................................28 8.1.8.3 ENRP Heart beat Failure or ENRP de-Registration Notification Updates.....................................28 8.2 Behavior of Pool Users and ENRP servers..................29 8.2.1 Pool User Resolves ENRP server address for initial contact..........................................29 8.2.2 PU requests list of ENRP servers in the pool.............29 8.2.3 Response to NS-DOWNLOAD request message requesting ENRP server list..............................29 8.2.4 Resolving PE server. addresses...........................30 8.2.5 ENRP Server response to NAME-RESOLUTION request..........30 8.2.6 DATA exchange between PU and PE .......................31 8.3 . API ....................................................31 8.3.1 Register ASAP endpoint...................................31 8.3.2 Update Registration API..................................33 8.3.2.2 Registration Update - PE Policy .........................34 8.3.2.3 Registration Update - PE Expiration Timer................34 8.3.3 DeRegister PE............................................35 8.3.4 User (Pool User ) opens a connection to its PE...........36 8.3.5 PU wishes to close the connection to its ASAP layer......37 8.3.6 Resolving PE endpoint addresses (Name Resolution ).......37 8.3.7 PU sends data via the ASAP layer.........................38 8.3.8 PU wishes to receive data obtained from PE..............39 9 Security Considerations..................................40 9.1 Confidentiality and Privacy: Encryption..................40 9.1.1 Application-Level Encryption.............................40 9.1.2 Lower-Layer Encryption...................................40 9.2 Message Integrity and Access Control: Authentication.....40 9.2.1 Illustration of Digest Scheme.............................41 A. Implementation Issues....................................42 A.1 Transport Protocol Support...............................42 A.2 Timer....................................................42 A.3 PU Caching...............................................42 A.4 Multicasting Support.....................................42 B. Summary of Augmented BNF................................42 C. Acknowledgements.........................................43 D Author's Contact Address.................................43 E Reference................................................43 1 Introduction [Req] discusses requirements for the management and operation of reliable server pools which may be needed for certain applications,and for the client access mechanism to a server pool. [Arch] describes an architecture for achieving such reliable server Ram & Senthil [Page 3] Internet Draft Aggregate Server Access Protocol July 2001 pools. Two protocols - ASAP and ENRP - are proposed within this architecture. In this document, we give a description of the ASAP protocol. 1.1. Terminology In addition to the terminology defined in [Req][Arch], the following terms are defined here: Reliability: As stated in [Papoulis], the reliability of a system is defined as the probability that the system functions at a certain time 't'. In mathematical terms, we have R(t) = P{x>t} where R(t) = system reliability P{.} = Probability of occurrence of the specified event x = Random Variable (RV) denoting "time to failure" of a system t = time A typical metric for determining the reliability of a system is the mean time to failure. The larger this value, the more reliable the system is. Availability: As stated in [Mullender], the availability of a system is defined as the probability that the system provides correct service delivery at a certain time 't'. It is a measure of correct service delivery with respect to the alternation of correct and incorrect service, measured by the probability A(t) that the system is ready to provide the service at a point in time t. ENRP Server: Identical to Name Server [Arch][Req] Proxy PE (PPE): Proxy PE refers to a PE which acts on behalf of application servers, specifically legacy application servers. Proxy PU (PPU): Proxy PU refers to a PU which acts on behalf of a user of a server pool, specifically a legacy user of a server pool. 1.2 Architectural View Figure 1 represents the architectural view of ASAP in a RServerpool. Ram & Senthil [Page 4] Internet Draft Aggregate Server Access Protocol July 2001 Communication of the different elements in this architecture is as follows: - Pool Element (PE) (say A1) uses ASAP layer to communicate with the ENRP server and also with any pool users (PU) in the pool. - P1 is a PU and it directly communicates with the ENRP server and the PE using P1's ASAP layer. - Communication between legacy clients (U1, U2) and PPU follows the application protocol that the legacy client supports, and PPU acts as a relay between the Rserpool system and the legacy client. - Communication between the legacy servers (S1,S2) and PPE follows the application protocol that the legacy server supports, and PPE acts as a relay between the Rserpool system and the legacy server. +---------------------+ +-----------+ +-----------+ | Application Server | |Legacy | |Legacy | | (A1) | |Server (S1)| |Server (S2)| +---------------------+ +-----------+ +-----------+ | ASAP | || || | | +---------------------+ +---------------------+ | ASAP - PPE (A2) | | Transport Layer | +---------------------+ | | | Transport Layer | +---------------------+ +---------------------+ || || || || =//===================//===============================//=== || +---------------------+ || +-------------------+ | ENRP Server | || | Pool User (P1) | | | || | | +----------+----------+ || | | | ENRP | ASAP | // +-------------------+ +----------+----------+ || | | | Transport Layer | || | ASAP | +----------+----------+ || +-------------------+ || || | Transport Layer | ||=====//=========|| +-------------------+ || || ||=====//======= || || +--------+ +--------+ || |Legacy | |Legacy | || |Client | |Client | || | (U1) | | (U2) | // +--------+ +--------+ Ram & Senthil [Page 5] Internet Draft Aggregate Server Access Protocol July 2001 || || || || || || || +-------------------+ || | ASAP - PPU (P2) | || +-------------------+ || | Transport Layer | || +-------------------+ || || ||====//========= // Figure 2: Architectural view of ASAP PU and PE Based on the requirements in [Req], some of the functionality that is provided within the protocol are: - The ENRP server discovery mechanism does not rely on multicast technologies. Instead, a set of mechanisms are described, any of which may be used. (Refer 2.1) - The use of Expires header for initial registration, registration modification or deletion of PE with ENRP server, permits automatic cache invalidation at the PU. This implies that the PU does not have to initiate queries to a PE to determine whether the PE is active, if it already knows that the PE is not active because its registration has expired. Some key characteristics of the architecture of Figure 1 are: - It does not assume any underlying transport protocols, and may use UDP, TCP, SCTP, RDP etc. - A programming interface (API) is provided to the PU user layer for communicating with the PE. - All communication between any two entities in the Rserpool is secured - it provides confidentiality, data origin authenticity and replay attack prevention. - The protocol does not rely on multicast, and works both in a unicast and multicast environment. - Use of an ASCII based message exchange (similar to HTTP, SIP) makes the protocol simpler and easy to implement. - Introduction of PPE facilitates the use of legacy application servers. Ram & Senthil [Page 6] Internet Draft Aggregate Server Access Protocol July 2001 - Load balancing is provided at three levels: - Across Name Servers for PU Queries - Across PEs for PU Queries - Across Name Servers for PE heartbeat 2 Protocol Overview 2.1 Choosing the ENRP server address for registration The PE obtains the list of ENRP servers from either the DNS, possibly some local configuration setting, multicast mechanisms or other means. This list may not be up-to-date, and some entries in the list may not be active in the ENRP server pool, while there may be other ENRP servers in the pool that are not listed in this entry. The PE picks one ENRP server (could be arbitrary) from the list and sends its registration to this ENRP server. It is assumed that at least one ENRP server in the list is active in the pool, so that if a ENRP server that the PE picked is not active, another ENRP server can be chosen from the list. 2.2 PE Registration, update and deRegistration The PE after choosing the ENRP server from the list ( Refer Section 2.1 ) sends the PE_REGISTRATION message to the ENRP server, the ENRP server does the initial authentication (depending upon the security protocol ) and sends back the PE_REGISTRATION response with status code. The typical registration request contains the server transport addresses), registration expiry time, service policy and other server specific information. From now on the PE is active in the server pool and will be monitored by one of the ENRP server. At any given point PE can extend its registration by sending the PE_REGISTRAION (update ) message, this is similar to the registration , but now the ENRP server treats this registration as an update and overwrites the existing parameters. Update message is typically used by PE to inform one of the following o wants to extend the expire time o wants to change the policy and control parameters PE can deRegister itself from the Server pool, by sending PE_REGISTRATION message with the registration expiry value set to 0. PE server pool can also de-register one of its transport addresses) if it is multi-homed by setting corresponding expire value to 0. Ram & Senthil [Page 7] Internet Draft Aggregate Server Access Protocol July 2001 2.3 PE Health check After successful registration, PE is declared active in the server pool. One of the ENRP server will periodically check whether the pool element handle and all of transport address(s) ( in case of multi homing ) is active. The PE upon receiving this request, does the reply similar to echo. Based on ENRP server load-balancing constraints, a different ENRP server may be assigned to perform the PE health check. This may also happen if the ENRP server that is currently performing health check either de-registers or fails. 2.4 Name Resolution Request Pool user sends the NAME_RESOLUTION request to ENRP server(s) through its ASAP layer. Name resolution request contains the pool handle. Upon receiving the request the ENRP server sends back the list of pool element handles. PU chooses ENRP server address similar to how PE chooses ENRP server address for PE_REGISTRATION request. 2.4.1 PU query load distribution The query that a PU sends to an ENRP server also needs to be distributed among the ENRP servers so that only one/handful of ENRP servers do not end up being overloaded. This can be done by sending a list of active ENRP servers in the pool to the PU when a query is made. The PU can then use either the policy included for 'PU Query load distribution' or if no such policy exists then the default may be taken to be RR. This is used to determine which ENRP server to send a subsequent query to. PUs do not have to be updated about the changing members in the ENRP server pool. If the queried ENRP server is not in the pool anymore, no response will be received, and the PU can query a different ENRP server. 2.5 Communication between PE and PU Pool user after resolving the PE handle, can send and receive data to/from PE. All the communication between the PE and PU are suitably authenticated and authorized by exchanging tokens between PE and PU. PU receives the token from the ENRP server in response to name resolution. 3 Message Overview ASAP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279). Senders MUST terminate lines with a CRLF, but receivers MUST also interpret CR and LF by themselves as line terminators. An ASAP message is either a request from a client to a server, or a response from a server to a client. Ram & Senthil [Page 8] Internet Draft Aggregate Server Access Protocol July 2001 ASAP-message = Request | Response Both Request (section 4) and Response (section 5) messages use the generic-message format of RFC 822 [2] for transferring entities (the body of the message). Both types of messages consist of a start-line, one or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the carriage-return line-feed (CRLF)) indicating the end of the header fields, and an optional message-body. ASAP-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line | ;Section 4.1 Status-Line ;Section 5.1 Table 2 provides a snapshot of the various headers within ASAP. message-header = Allow ; Section 6.1 | Expires ; Section 6.8 | NS-Parameter ; Section 6.6 | PE-Parameter ; Section 6.2 | Policy ; Section 6.3 | Periodic-Update ; Section 6.4 | Pool-Handle ; Section 6.5 | Transaction-ID ; Section 6.7 | WWW-Authenticate ; Section 6.9.1 | Authorization ; Section 6.9.2 | Authorization-Info ; Section 6.9.3 | Encryption ; Section 6.9.4 | Require ; Section 6.9.5 | Response-Key ; Section 6.9.6 Table 3: ASAP headers The message syntax proposed satisfies the following requirements: Ram & Senthil [Page 9] Internet Draft Aggregate Server Access Protocol July 2001 - The message structure is based on well-known structures that have been used in protocols that have widespread deployment. - Ease of extensibility of the message structures - Facilitate code reuse where possible, when other protocol parsers use similar message structures - Efficient parsing of the message structures - Limited processing power requirements, facilitating use of the protocol in small devices. 4 Request The syntax of request messages is as follows: Request = Request-Line *message-header CRLF [message-body] 4.1 Request-Line The Request-Line contains a method token, followed by the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF are allowed except in the final CRLF sequence. Request-Line = Method SP Protocol-Version CRLF When the ASAP protocol is being considered, the Request-Line is: Request-Line = Method SP ASAP-Version CRLF Implementations adhering to this document MUST use ASAP/1.0 for their ASAP-Version. 4.2 Method The methods are defined below. The Method token is case-sensitive. Method = "PE-REGISTRATION" | "NAME-RESOLUTION" | "PE-HEARTBEAT" |"UPDATE" | "NS-DOWNLOAD" | "DATA" Ram & Senthil [Page 10] Internet Draft Aggregate Server Access Protocol July 2001 4.2.1 PE-REGISTRATION The PE-REGISTRATION method is used within a Request message that is sent by a PE to an ENRP server to indicate one of the following: (a) PE wishes to join a server pool (b) PE , which has already registered itself with an ENRP server and is currently a member of a server pool, extends/modifies the registration parameters. (c) PE, which has already registered itself with an ENRP server and is currently a member of a server pool, deletes its registration. PE cancels an existing registration by sending a PE-REGISTRATION request with an expiration time (Expires header) of zero seconds for a particular PE handle or the wildcard PE handle designated by a "*" for all registrations. If a PE handle is already found to exist, then the PE-Parameters associated with it are updated. 4.2.2 NAME-RESOLUTION The NAME-RESOLUTION method indicates that an application client wishes to resolve the pool handle to PE handle (i.e. transport address). The request message is sent by an application client (typically PU) to its ENRP server. 4.2.3 HEARTBEAT HEARTBEAT message are sent between an ENRP server and a PE, to check that the PE is alive. 4.2.4 UPDATE ENRP server updates its database and sends the UPDATE to other servers.UPDATE message can be classified into two categories according to the type of updates. 1) The following update messages are sent by ENRP servers to (1) other ENRP servers within the same ENRP server pool, as well as (2) to PE that are registered with this ENRP server pool: (a) New Registration: ENRP server wishes to join the server pool (b) Registration Update: ENRP server, which has already registered itself with an ENRP pool and is currently a member of the pool, wants to extend/modify the NS-Parameters (such as duration, policy etc.). Ram & Senthil [Page 11] Internet Draft Aggregate Server Access Protocol July 2001 (c) De-Registration: ENRP server, which has already registered itself with an ENRP server pool, deletes its registration. (c) Heartbeat Failure Notification: ENRP server, which is currently a member of an ENRP pool, notifies to one/more ENRP servers within the pool of the heartbeat failure of another ENRP server within the same pool. 2) The following update messages are sent by ENRP servers to other ENRP servers: (Refer ENRP Draft for description of these messages) (a) PE registration notification: Notifying a newly added PE handle to the server pool. (b) PE server registration update: PE , which has already registered itself with a server pool and is currently a member of the pool, wants to extend/modify the PE-Parameters (such as duration, policy etc.). (c) PE server de-registration: PE , which has already registered itself with an ENRP server pool, deletes its registration. (c) PE heartbeat failure notification: ENRP server, detects the failure of a PE's handle during heartbeat check, and notifies the other ENRP servers within the ENRP server pool. 4.2.5 NS-DOWNLOAD The NS-DOWNLOAD method is used within a Request message to request a list of active ENRP servers. This Request message is sent by a PU to a ENRP server. 4.2.6 DATA DATA message are sent between the PE and the PU and is application specific data which is being exchanged between two endpoints. 5 Response After receiving and interpreting a request message, the recipient responds with an ASAP response message. The response message format is shown below: Ram & Senthil [Page 12] Internet Draft Aggregate Server Access Protocol July 2001 Response = Status-Line *message-header CRLF [ message-body ] 5.1 Status-Line The first line of a Response message is the Status-Line,consisting of the protocol version (Section 8.1.2 ) followed by a numeric Status-Code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Status-Line = Protocol-version SP Status-Code SP Reason- Phrase CRLF When ASAP is used, the Status-Line is: Status-Line = ASAP-version SP Status-Code SP Reason- Phrase CRLF Implementations adhering to this document MUST use ASAP/1.0 for their ASAP-Version. 5.1.2 Status Codes and Reason Phrases The Status-Code is a 3-digit integer result code that indicates the outcome of the attempt to understand and satisfy the request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase. Status-Code = Success ;Fig. 3 | Client-Error ;Fig. 4 | Server-Error ;Fig. 5 | Global-Failure ;Fig. 6 | extension-code extension-code = 3DIGIT Reason-Phrase = * We provide an overview of the Status-Code below, and provide full definitions in Section 7. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. ASAP/ENRP/1.0 allows 4 values for the first digit: Ram & Senthil [Page 13] Internet Draft Aggregate Server Access Protocol July 2001 2xx: Success -- the action was successfully received, understood, and accepted; 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server; 5xx: Server Error -- the server failed to fulfill an apparently valid request; 6xx: Global Failure -- the request cannot be fulfilled at any server. Figures 3 through 6 present the individual values of the numeric response codes. Success = "200" ; OK Figure 3: Success status codes Client-Error = "400" ; Bad Request | "401" ; Unauthorized | "403" ; Method Not Allowed | "404" ; Not Found | "406" ; Request Timeout | "408" ; Gone | "409" ; Request Entity Too Large Figure 4: Client error status codes Server-Error = "500" ; Internal Server Error | "501" ; Not Implemented | "502" ; Service Unavailable | "503" ; ASAP/ENRP Version not supported Figure 5: Server error status codes 6 Header Field Definitions ASAP header fields are similar to SIP or HTTP header fields in both syntax and semantics. Some of these headers may be present in both request and response messages, while others may be present in only either a request or a response message. The subsections below describing each of the headers, also mentions their applicability within a request/response message. Ram & Senthil [Page 14] Internet Draft Aggregate Server Access Protocol July 2001 6.1 Allow The Allow header field is used to indicate the list of methods that are supported by the responding server. Allow = ("Allow" | "l") ":" *("PE-REGISTRATION" | "NAME- RESOLUTION" | "PE-HEARTBEAT" |"UPDATE" | "DATA" | quoted-string) An example of the Allow header is as follows: Allow:"PE-REGISTRATION" "NAME-RESOLUTION" 6.2 PE-Parameters The PE-Parameter header is defined as follows: PE-Parameter = ( "PE-Parameter" | "e" ) ":" Handle Handle = 1*("(" transport-addr ")" [*(";"contact-params )] [ comment ]) [";" proxy-addr] transport-addr = IPv4|IPv6 IPv4 = digit "." digit "." digit "." digit *(":" port-number) IPv6 = ( (digit ":" digit ":" digit ":" digit ":" digit ":" digit ":" digit ":" digit) |(":" digit ":" digit ":" digit ":" digit ":" digit ":" digit ":" digit) |(":" ":" digit ":" digit ":" digit ":" digit ":" digit ":" digit) |(":" ":" ":" digit ":" digit ":" digit ":" digit ":" digit)) *(":" port-number) port-number = digit contact-params = "q" "=" qvalue | "Expires" "=" delta-seconds | "Policy" "=" ("LRU"|"RR"|token) proxy-addr = "proxy-addr" ":" 1*transport-addr comment = quoted-string The PE-Parameter has one or more transport addresses, each of which may optionally have contact parameters and comments associated with them. For the case, where the transport addresses belong to legacy servers, the transport address(es) of the proxy PE are also indicated. q: The "qvalue" indicates the relative preference among the locations given. "qvalue" values are decimal numbers from 0 to 1, with higher values indicating higher preference. This could Ram & Senthil [Page 15] Internet Draft Aggregate Server Access Protocol July 2001 be used for the case of a multi-homed host where the same service may be available at different transport addresses, and a preference exists for certain transport addresses. 6.3 Policy The Policy header field is used to indicate the preferred load policy of the PE. It is used during registration of a PE , or when the policy associated with a registration needs to be updated. Policy = ("Policy" | "p") ":" ("LRU"|"RR"|token) Usually, when the Policy header is specified, then an Expires header is included as well. This indicates the expiration time associated with the policy. An example of the Policy header is as follows: Policy="RR" 6.4 Periodic-Update The Periodic-Update header may be used within a HEARTBEAT Request as well as Response message. It is used within a HEARTBEAT request when an ENRP server requests the PE to declare its presence to the examining server periodically. It is used within a response to a HEARTBEAT Request when the PE indicates whether it supports the periodic presence notification feature or not. For example, ENRP server request the heartbeat by generating the HEARTBEAT request message and including the Periodic-Update header with a value "Yes". If the PE can report its presence periodically without getting any further request from the ENRP server, then the PE can respond to the HEARTBEAT Request by including a Periodic-Update header with value of "Yes". Periodic-Update = ("Periodic-Update" | "u") ":" "Yes" ";" An example of the Periodic-Update header is as follows: Periodic-Update="Yes" 6.5 Pool-Handle The Pool-Handle header is used to denote the pool handle. Ram & Senthil [Page 16] Internet Draft Aggregate Server Access Protocol July 2001 Pool-Handle= ("Pool-Handle" | "n") ":" ( name-addr) name-addr = quoted-string 6.6 NS-Parameters The NS-Parameters header field is used to convey the ENRP Server Parameters. This may be used by an ENRP server when it responds to a NAME-RESOLUTION Request from a PU. NS-Parameters = ("NS-Parameters" | "i") ":" Handle 6.7 Transaction-ID The Transaction-ID header field is used to associate a set of messages to the same transaction. Initial request messages MUST carry a locally unique transaction-ID. Responses and subsequent requests that are related to this request, MUST use the same Transaction-ID. Transaction-ID = ("Transaction-ID" | "t") ":" UUID Example: Transaction-ID= "124F-AB12-874-2344-2344-1234-2345-9EDE" 6.8 Expires The "Expires" parameter indicates how long the PE handle is valid. The parameter is a number indicating seconds. When not present, the default value is taken to be the maximum, which is 2**32-1. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. Expires =("Expires" | "x") ":" delta-seconds Example: Expires = 1000 6.9 Security Related Headers 6.9.1 WWW-Authenticate The WWW-Authenticate header, typically included within a 401 Response message, is used to indicate that the Requesting entity needs to be authenticated. Ram & Senthil [Page 17] Internet Draft Aggregate Server Access Protocol July 2001 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge Based on RFC2617, when Digest Authentication is used, the challenge is as follows: challenge = "Digest" digest-challenge digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] ) domain = "domain" "=" <"> quoted-string <"> nonce = "nonce" "=" nonce-value nonce-value = quoted-string opaque = "opaque" "=" quoted-string stale = "stale" "=" ( "true" | "false" ) algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | token ) qop-options = "qop" "=" <"> 1#qop-value <"> qop-value = "auth" | "auth-int" | token 6.9.2 Authorization The Authorization header is included within a Request message, so that the Requesting entity may authenticate itself to the receiver. Authorization = "Authorization" ":" credentials Based on RFC2617, when Digest authentication is used, the Authorization header is as follows: credentials = "Digest" digest-response digest-response = 1#( username | realm | nonce | response | [ algorithm ] | [cnonce] | [opaque] | [message-qop] | [nonce-count] | [auth-param] ) username = "username" "=" username-value username-value = quoted-string message-qop = "qop" "=" qop-value cnonce = "cnonce" "=" cnonce-value cnonce-value = nonce-value nonce-count = "nc" "=" nc-value nc-value = 8LHEX response = "response" "=" request-digest request-digest = <"> 32LHEX <"> LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" Ram & Senthil [Page 18] Internet Draft Aggregate Server Access Protocol July 2001 6.9.3 Authentication-Info The Authentication-Info, typically included in a 200 Response message, conveys any optional information following successful authentication. The Authentication-Info based on RFC2617 is modified by appending a token field to carry the authorization token: AuthenticationInfo = "Authentication-Info" ":" auth-info [authtoken] auth-info = 1#(nextnonce | [ message-qop ] | [ response-auth ] | [ cnonce ] | [nonce-count] ) nextnonce = "nextnonce" "=" nonce-value response-auth = "rspauth" "=" response-digest response-digest = <"> *LHEX <"> authtoken = quoted-string This header is used to carry a token that an ENRP server sends to the PU, which the PU may use when communicating with a PE. 6.9.4 Encryption The Encryption header is used in Requests and Responses, when encryption is employed. The message body and all headers following a blank line are encrypted. As specified in RFC2543bis3: Encryption = "Encryption" ":" encryption-scheme 1*SP #encryption-params encryption-scheme = token encryption-params = generic-param 6.9.5 Require The Require header is used to indicate that the recipient needs to support the specified option. As specified in RFC2543: Require = "Require" ":" 1#option-tag When an entity requires the recipient to encrypt the messages, it includes the Require header with the following option-tag: Require: org.ietf.asap.encrypt-response 6.9.6 Response-Key The Response-Key header is used within a Request to indicate that the responder SHOULD use the enclosed key to encrypt responses. As specified in RFC2543: Ram & Senthil [Page 19] Internet Draft Aggregate Server Access Protocol July 2001 Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param key-scheme = token key-param = generic-param 7 Status Code Definitions 7.1 Successful 2xx The request was successful and MUST terminate a search. 7.1.1 200 OK The request has succeeded. The information returned with the response depends on the method used in the request, for example: o PE_REGISTRATION: The registration has succeeded, and the PE treats the message body of the Response message according to its Content o PE_REGISTRATION (Update ): The registration update has succeeded and the PE treats the message body of the Response message according to its Content o PE_HEARTBEAT: The heartbeat of a PE has succeeded, and the ENRP server treats the message body according to its Content. o NAME-RESOLUTION: The NAME-RESOLUTION request is success and the PE or PU treats the message body according to its Content. 7.2 Request Failure 4xx 4xx responses are definite failure responses from a particular server. The PU or PE SHOULDNOT retry the same request without modification (e.g., adding appropriate authorization). However,the same request to a different server might be successful. 7.2.1 400 Bad Request The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, e.g., "Missing PE Handle". 7.2.2 401 Unauthorized The request requires user authentication. This could occur either when the request did not contain an Authorization header (non- compliant client), or when the Authorization header is invalid. This response is issued by Ram & Senthil [Page 20] Internet Draft Aggregate Server Access Protocol July 2001 (1) ENRP server when the PE does registration/update/deregistration ,or (2) When PU tries to exchange data with PE , or (3) When PU sends a NAME-RESOLUTION request to the ENRP server 7.2.3 403 Method Not Allowed The method specified in the Request-Line is not allowed by the recipient. The response MUST include an Allow header field containing a list of valid methods supported by the recipient. 7.2.4 404 Not Found The server has definitive information that the resource does not exist. For instance, when a PU sends a NAME-RESOLUTION Request to the ENRP server and the Pool Handle contained therein does not exist, then the ENRP server returns a 404 Response. 7.2.5 406 Request Timeout The PE could not produce a response within a suitable amount of time, for example a DATA request sent by PU to the legacy PE via proxy PE. The client MAY repeat the request without modifications at any later time. 7.2.6 408 Gone Gone is used to denote that the PE indicated in the Request message is no longer active in the pool. For example, if a DATA request is sent by PU to a legacy PE via proxy PE and if the legacy PE is not available, then the proxy PE will generate this message to indicate that the legacy PE is no longer available. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. 7.2.7 409 Request Entity Too Large The PE or ENRP server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. The requesting entity may retry the request at a later time. Ram & Senthil [Page 21] Internet Draft Aggregate Server Access Protocol July 2001 7.3 Server Failure 5xx 5xx responses are failure responses given when a server itself has errored. They are not definitive failures, and the requesting entity MUST NOT terminate a search if other possible locations remain untried. 7.3.1 500 Server Internal Error The PE or ENRP server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition, and MAY retry the request after several seconds. The client may retry the request at a later time. 7.3.2 501 Not Implemented The PE or ENRP server does not support the functionality required to fulfill the request. This is the appropriate response when it does not recognize the request method and is not capable of supporting it. 7.3.3 502 Service Unavailable The ENRP or PE is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. Note: The existence of the 502 status code does not imply that a server has to use it when becoming overloaded. Some servers MAY wish to simply refuse the connection. 7.3.4 503 Version Not Supported The PE or ENRP server does not support, or refuses to support, the ASAP/ENRP protocol version that was used in the request message. The PE is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. 8. Behavior of PE 8.1 Interaction between PE and ENRP Server This section describes the rules for PE (also known as an ASAP Application Servers ) for generating and processing requests and responses. Ram & Senthil [Page 22] Internet Draft Aggregate Server Access Protocol July 2001 8.1.1 Registering Entity Resolves the ENRP server with which to Register There exists two different entities that may register a PE with an ENRP server - (1) the PE itself, and (2) a proxy on behalf of the legacy PE . We refer to this entity as the "registering entity". Prior to registering a PE with an ENRP server, the registering entity needs to NAME-RESOLUTION the IP address of an ENRP server(s) with which it registers. Several mechanisms are possible, whereby the registering entity can determine the IP address of an ENRP server to register with. For instance, (1) an registering entity may be manually configured with a set of IP addresses of ENRP servers that it may register with, or (2) an registering entity may be configured with the DNS address of an ENRP server(s) that it may register with following which it uses a DNS query and local policy to determine the specific IP address of the ENRP server to register with, or (3) the Service Location Protocol (SLP) may be used to discover a suitable ENRP server. We briefly describe a possible operation procedure when DNS is used. The registering entity is configured with the DNS address of an ENRP server(s)that it may register with. It performs a DNS query which returns a set of IP addresses corresponding to the queried DNS address. Based on this returned list of IP addresses and any local policies, the registering entity selects an IP address for registration. While the selection of IP address is implementation specific, a sample procedure for selection of IP address is indicated below: (a) Selection criterion is based on the order of returned IP addresses. In other words, the first IP address in the list could be used for registration. If the registration fails, the next IP address in the list is tried, and so on. (b) Selection criterion is based on a random selection of returned IP addresses from the DNS query. It may be noted that the above specified mechanisms are outside the scope of the ASAP/ENRP protocol itself, and that the above specified mechanisms are possible ways of resolving the IP address of the ENRP server. 8.1.2 PE needs to be registered with an ENRP server An PE may make its services available by registering with an ENRP server. The registration could be done either by the PE itself, or by a proxy on behalf of the PE The registering entity (PE or proxy for a legacy PE ) resolves the IP address of the ENRP server to register with, as specified in Section 8.1.1 . Ram & Senthil [Page 23] Internet Draft Aggregate Server Access Protocol July 2001 In order to register with the selected IP address, the PE sends a Request message to the selected IP address with method set to PE-REGISTER. Implementations adhering to this document MUST set the ASAP-version field to ASAP/1.0. Hence, the Request- line is as follows: PE-REGISTRATION ASAP/1.0 When the PE registers by itself, then the optional PE-Parameter header is omitted. This implies that the entity that is registering the PE is the PE itself. If a proxy were registering the PE, then the From header provides information about the Proxy, while the PE-Parameter header provides information about the PE itself. For instance, a typical Register-Request message may look like this: PE-REGISTRATION ASAP/1.0 Transaction-ID: 0x23532ed PE-Parameters:172.19.134.20:568; Proxy=172.19.146.54:675 Pool-Handle: asap://ftp.foo.com Policy:LRU Expires: 7200 Authorization: An application server MUST be authenticated before it can register with an ENRP server. In order to handle such authentication, the PE Registration Request message can optionally include an Authorization header. 8.1.3 PE De-Registering itself with an ENRP server An PE that wishes to withdraw its services from a server pool, does so by issuing a suitable de-register message to the ENRP server that it is registered with. An explicit de-register message is not provided for the purpose. Instead, de-registration is inferred by the use of a PE-REGISTRATION message with an Expires header field of value 0. For instance, a typical Register-Request message that is used for De-Registration purposes may look like this: PE-REGISTRATION ASAP/1.0 Transaction-ID=0x34ae78d PE-Parameter:172.19.134.20:568; Proxy=172.19.146.54:675 Pool-Handle: ftp.foo.com Policy:LRU Expires: 0 Authorization: Ram & Senthil [Page 24] Internet Draft Aggregate Server Access Protocol July 2001 In the above example, the de-registration applies to the transport address indicated in the PE-Parameter field. Alternatively, the Expires field within the PE-Parameter header may be set to zero in order to indicate de-registration. For instance, an example of the usage of this would be: PE-REGISTRATION ASAP/1.0 Transaction-ID=0x34ae78d PE-Parameter:172.19.134.20:568;expires=0; Proxy=172.19.146.54:675 Pool-Handle: ftp.foo.com Policy:LRU Authorization: 8.1.4 PE Updating Registration with ENRP server An PE that is already in a server pool may update its registration with an ENRP server. Such update could include modification of the expiration of the registration and/or modification of the policy associated with the registration. Registration updates are performed using a Request message with the PE-REGISTRATION method. In other words, a registration update is identical to a new registration. PE must update its registration with the ENRP server from where it receives the last heart beat request. For instance, when an PE wishes to increase its registration expiration by 10000 seconds, then a Request message as follows is sent: PE-REGISTRATION ASAP/1.0 Transaction-ID=0x6967ed84 PE-Parameter:172.19.134.20:568;Proxy=172.19.146.54:675 Pool-Handle: ftp.foo.com Policy:LRU Expires: 10000 Authorization: The ENRP server examines the PE-Parameter header to see if an entry exists within its database. If this is the case, it means that there is an existing registration, and the expiration associated with this registration is changed to 10000. On the other hand, if such an entry does not exist, then this implies that this is a new registration. 8.1.5 ENRP Server sends a Heartbeat Request to PE An ENRP server may need to examine whether an PE within an application server pool is alive. In order to do this, a heartbeat request message is sent. The format of the Request-Line of a heartbeat request message is as follows: PE-HEARTBEAT ASAP/1.0 Ram & Senthil [Page 25] Internet Draft Aggregate Server Access Protocol July 2001 The PE-Parameter header is useful in the case of a Proxy handling several legacy application servers. The PE-Parameter header transport address (pool handle + PE handle) refers to the transport address of the legacy application server whose heartbeat needs to be monitored. An example of a heartbeat request is as follows: PE-HEARTBEAT ASAP/1.0 Transaction-ID=0x85634bc7 PE-Parameter:172.19.146.54:675 Authorization: Periodic-Update: Yes;600 8.1.6 PE responding to the Heartbeat Request PE will respond to the ENRP Server HEARTBEAT request in the response message. When the PE-HEARTBEAT REQUEST message contains a periodic update header, then the PE needs to determine whether it can perform a periodic update and the PE can notify the periodic update in the response message. The PE-Parameter header is useful in the case of a Proxy handling several legacy application servers. The PE-Parameter header transport address (endpoint name + endpoint handle) refers to the transport address of the legacy application server representing its status. An example of a heartbeat request is as follows: PE with Periodic Update: ASAP/1.0 200 Transaction-ID=0x34ae78d Periodic-Update: Yes;600 PE with no Periodic Update: ASAP/1.0 200 Transaction-ID=0x34ae78d 8.1.7 ENRP Server receives an PE registration message Upon receiving a REGISTRATION message from an PE, an ENRP server sends a response back to the PE with the appropriate status code. The "Status Code" in the "Status-Line" has a value of 200 to indicate OK (Success), 400 to indicate Bad Request, 401 to indicate Unauthorized, etc. Ram & Senthil [Page 26] Internet Draft Aggregate Server Access Protocol July 2001 ASAP/1.0 200 Transaction-ID=0x34ae78d ASAP/1.0 401 Transaction-ID=0x34ae78d WWW-Authenticate:Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" 8.1.8 ENRP Server Updates ENRP server status to PE The following update messages are sent by ENRP servers to (1) all other ENRP servers within the same ENRP server pool, as well as (2) to all PE that are registered with this ENRP server pool: (a) New ENRP Registration Notification: When an ENRP server (say, A) wishes to join the ENRP server pool, it registers itself with an ENRP server (say, B) that is already in the ENRP server pool. ENRP server B then uploads suitable information (including the current list of ENRP servers in the pool as well as the current list of PE in server pool and pool entities that are managed by this ENRP pool) to ENRP server A. ENRP server A then notifies all ENRP servers and PE in this pool about its new registration. (Sec 8.1.8.1 ) (b) ENRP Registration Update: ENRP server, which has already registered itself with an ENRP pool and is currently a member of the pool, wants to extend/modify the registration attributes (such as duration, policy etc.). ( Sec 8.1.8.2 ) (c) ENRP De-Registration Notification: ENRP server, which has already registered itself with an ENRP server pool, deletes its registration by notifying its caretaker ENRP server. After receiving such de-registration message from an ENRP server, the caretaker ENRP server notifies all other ENRP servers in the pool of this de-registration.(Sec 8.1.8.3 ) (d) Heartbeat Failure Notification: ENRP server, which is currently a member of an ENRP pool, notifies to one/more ENRP servers within the pool of the heartbeat failure of another ENRP server within the same pool. (Sec 8.1.8.3 ) Ram & Senthil [Page 27] Internet Draft Aggregate Server Access Protocol July 2001 8.1.8.1 New ENRP Registration Notification Newly added ENRP Server sends its update message to the other ENRP servers and PE. This informs that the newly ENRP server is part of the pool. ENRP-UPDATE with Server-Type = ENRP and ENRP-SERVER-ID refers to the ENRP server ID which has joined the pool. For instance, a ENRP-UPDATE may look like this: ENRP-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d NS-Parameters:208.19.134.20:568 Expires: 10000 Authorization: 8.1.8.2 ENRP Registration Update An ENRP server that is already in an ENRP server pool may update its registration. Such update could include modification of registration attributes (e.g. expiration time of the registration, policy associated with the registration etc.). Registration updates are performed using a Request message with the ENRP-UPDATE method. For instance, when an ENRP server wishes to increase its registration expiration to a new value of 10000 seconds, then a Request message as follows is sent: ENRP-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d NS-Parameters:208.19.134.20:568 Expires: 10000 Authorization: 8.1.8.3 ENRP Heart beat Failure or ENRP de-Registration Notification Updates Caretaker ENRP server updates all the other ENRP servers and ASAP endpoint servers in the event of ENRP server heartbeat failures or de-Registration. Expires value is set to 0. The NS-Parameter indicates the ENRP server that is no more part of the pool. For instance, an ENRP-UPDATE may look like: ENRP-UPDATE ENRP/1.0 Transaction-ID=0x34ae78d NS-Parameters:208.19.134.20:568 Expires: 0 Authorization: Ram & Senthil [Page 28] Internet Draft Aggregate Server Access Protocol July 2001 8.2 Behavior of Pool Users and ENRP servers This section describes the rules for Pool Users and ENRP servers for generating and processing requests and responses. 8.2.1 Pool User resolves ENRP server address for initial contact When a Pool User (PU) wishes to initiate communication with an application server, the PU needs to NAME-RESOLUTION the transport address of the particular ENRP server to contact. The mechanism used by the PU for this purpose is similar to that used by an PE for the same purpose (see Sec 8.1.1). In other words, several possible mechanisms exist, one of which is the use of DNS. 8.2.2 PU requests list of ENRP servers in the pool After a PU has obtained the transport address of the ENRP server (say A) that it may contact (see Sec 8.2.1 ), it needs to obtain the list of active ENRP servers in the pool. The PU does this by sending an NS-DOWNLOAD request message to the ENRP server A. If the request fails, the PU queries other transport address based on the selection policy. The list of the transport addresses of ENRP servers that are available to the PU for query is obtained as in Sec 8.2.1. The format of the Request-Line of a ENRP server list download request message is as follows NS-DOWNLOAD ASAP/1.0 An example usage is as follows: NS-DOWNLOAD ASAP/1.0 Transaction-ID=0x34ae78d Authorization: 8.2.3 Response to NS-DOWNLOAD request message requesting ENRP server list When an ENRP server receives an NS-DOWNLOAD request message from a PU, it responds by sending a sequence of NS-Parameters. The NS- Parameters header provides information on parameters such as IP address(s), policy, timers, etc. Ram & Senthil [Page 29] Internet Draft Aggregate Server Access Protocol July 2001 An example of an NS-DOWNLOAD message is as follows. Here, ENRP server with ENRP-SERVER-ID 1 is a multi-homed server with two interfaces - one with transport address 172.19.134.20:568 and the other with transport address 172.19.134.21:568. On the other hand, ENRP server with ENRP-SERVER-ID of 2 and 3, each have a single interface. 200 ASAP/1.0 Transaction-ID=0x34ae78d NS-Parameter: 172.19.134.20:568;Expires:5000; 172.19.134.21:568;Expires:6000; NS-Parameter: 172.19.45.4:40;Expires:65000 NS-Parameter: 172.20.65.45:568;Expires:42000 Policy: RR Authorization: 8.2.4 Resolving PE server addresses In order for a PU to communicate with an PE , it needs to obtain the list of PE endpoint handle within an server pool. . The PU does this by sending an NAME-RESOLUTION request message to the appropriate ENRP server (based on certain policies - see Sec 8.2.3 ). The format of the NAME-RESOLUTION Request-line is as follows: NAME-RESOLUTION ASAP/1.0 The Pool-Handle header denotes the Pool Handle that the ENRP server needs to NAME-RESOLUTION and for which the PU needs to obtain a list of transport addresses. For instance, a typical NAME-RESOLUTION request message may be as follows: NAME-RESOLUTION ASAP/1.0 Transaction-ID=0x34ae78d Pool-Handle: www.foo-asap-server.com Authorization: 8.2.5 ENRP Server response to NAME-RESOLUTION request When an ENRP server receives the NAME-RESOLUTION request message from a PU, it needs to formulate a response. The response contains a list of PE's pool element handle . The PE pool element handle includes information such as the IP address(es), policy,timers etc. Ram & Senthil [Page 30] Internet Draft Aggregate Server Access Protocol July 2001 An example usage of this message is as follows. Here, the ASAP server pool contains three PE - one which is a multi-homed endpoint with two interfaces (transport address of 172.19.134.20:568 and 172.19.134.21:568), and the other two with single interfaces of transport address of 172.19.45.4:40 and 172.20.65.45:568 respectively. 200 ASAP/1.0 Transaction-ID=0x34ae78d PE-Parameter: 172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000 PE-Parameter: 172.19.45.4:40;Expires:65000 PE-Parameter: 172.20.65.45:568;Expires:42000 Policy: RR Authorization: 8.2.6 DATA Exchange between PU and PE A PU communicates with PE and sends the application specific data to the PE. ASAP-DATA message is generated by the PU or PE in order to send the application specific data. The token field is the authorization which implies that PU has got the ASAP transport addresses through the ENRP server pool only and not by any other means. All the data is encrypted and provides confidentiality. For instance, when an PU wants to send data to PE ASAP-DATA ASAP/1.0 Transaction-ID=0x3e4ae78d DATA: Authorization: 8.3. API The ASAP layer provides set of API to the user applications, and both PE and PU uses these API to communicate in server pool. 8.3.1 Register ASAP endpoint Pool Element registers with ENRP server pool by invoking register PE API. The PE user layer passes information like Name server pool name, policy, and list of transport addresses along with authorization information. Ram & Senthil [Page 31] Internet Draft Aggregate Server Access Protocol July 2001 Usage: This API is used by PE Prototype: int registerPE (char *NSname , char *peEndpointName, char *peTransportAddr, char *policy, char *authorization, unsigned long timer char *response ); Arguments: 1) NSname: End name of the name server with which PE wants to register. 2) peEndpointName: End point name of the PE 3) peTranportAddress: The list of transport address on which the PE will process PU's request 3) Policy: PE server policy 4)authorization: Authorization information required for PE registration process 5 )timer: how long the PE wants to be active in the ENRP server poll, its value is in seconds. Return value: The status of the operation is returned as function returns value. 0 means operation successful and response value refers to the application Handle which is a unique string to identify the PE's user application, and it will be used by the PE user layer for further communication. Application Handle uniquely identifies the PE's user layer, and a ENRP server. If the status of operation is other than 0 meaning error in registration and the response parameter describes the details of the error. See section 7 for details. Ram & Senthil [Page 32] Internet Draft Aggregate Server Access Protocol July 2001 8.3.2 Update Registration API PE which is already a element of a pool can extend its registration at any time. Typically application server extends its registration for any of the following reasons: o Wants to inform changes in the transport address (Endpoint-Addr ) (Sec 8.3.2.1) o Wants to change the policy (Sec 8.3.2.2 ) o Wants to increase the Expiration time (Sec 8.3.2.3) NOTE: PE cannot change the Endpoint Name. 8.3.2.1 Registration Update - PE Transport Address Usage: This API is invoked by the PE and is provided by PE's user layer. Prototype: The prototype of the API is as follows: int updatePETranportAddress(char *appHandle, char *authorization, char *transportAddress, char *response); Arguments: 1) appHandle : Application handle returned during the registration message. 2) authorization: Authorization information required for PE registration process 3) transportAddress: New list of transport address for PE Return value: The status of the operation is returned as function returns value. 0 means operation successful and the registration update is complete. If the status of operation is other than 0 meaning error during registration update and the response parameter describes the details of the error. See section 7 for details of error code . Ram & Senthil [Page 33] Internet Draft Aggregate Server Access Protocol July 2001 8.3.2.2 Registration Update - PE Policy Usage: This API is invoked by the PE and is provided by PE user layer. Prototype: int updatePEPolicy(char *appHandle, char *authorization, char *policy, char *response); Arguments: 1) appHandle : Application handle return during the registration message. 2)authorization: Authorization information required for PE registration process 3 )policy : new policy Return value: The status of the operation is returned as function returns value. 0 means operation successful and the registration update is complete. If the status of operation is other than 0 meaning error during registration update and the response parameter describes the details of the error. See section 7 for details of error code . 8.3.2.3 Registration Update - PE Expiration Timer Usage: This API is invoked by the PE user layer. Prototype: int updatePETimer(char *appHandle, char *authorization, unsigned long timer, char *response); Ram & Senthil [Page 34] Internet Draft Aggregate Server Access Protocol July 2001 Arguments: 1) appHandle : Application handle return during the registration message. 2)authorization: Authorization information required for PE registration process 3 )timer: new timer value in seconds. Return value: The status of the operation is returned as function returns value. 0 means operation successful and the registration update is complete. If the status of operation is other than 0 meaning error during registration update and the response parameter describes the details of the error. See section 7 for details of error code . 8.3.3 DeRegister PE PE which is already a element of a pool can deRegister at any time. Usage: This API is invoked by the PE's user layer and is provided by PE-ASAP layer. Prototype: int deRegisterPE(char *appHandle char *authorization); Argument: 1) appHandle: PE's user layer handle returned during registration process. 2) authorization: Authorization information required for PE registration process Return value: The status of the operation is returned as function returns value. 0 means operation successful. If the status of operation is other than 0 meaning error in deRegistration and the response parameter describes the details of the error. See section 7 for details. Ram & Senthil [Page 35] Internet Draft Aggregate Server Access Protocol July 2001 8.3.4 User (Pool User ) opens a connection to its PE User before starts communicating with the PE, will have to get authorized by the pool, this is done by using the open API by which the user (or client) gets authorized and becomes a pool user of the server pool. Usage: This API is invoked by the client and is provided by PU's ASAP layer. (PE can also this api if it had registered with the pool ) Prototype: int open(char *NSname, char *authorization, unsigned int timer, char *response); Arguments: 1) NSname: End name of the name server with which PE wants to register. 2)authorization: Authorization information required for validating the pool user. 3 )timer: how long the client wants to be active , its value is in seconds. Return value: The status of the operation is returned as function returns value. 0 means operation successful and response value refers to the application Handle which is a unique string to identify the ASAP user application,and it will be used by the ASAP user layer for further communication. Application Handle uniquely identifies the ASAP user layer, and a ENRP name server. Ram & Senthil [Page 36] Internet Draft Aggregate Server Access Protocol July 2001 If the status of operation is other than 0 meaning error in open and the response parameter describes the details of the error. See section 7 for details. 8.3.5 Pool User wishes to close the connection to its ASAP layer User can close the session with pool at any time, close API terminates the session and disconnects the client from the pool. Usage: This API is invoked by the client and is provided by ASAP PU layer. (PE can also this api if it had registered with the pool ) Prototype: int close(char *appHandle, char *authorization); Arguments: 1) appHandle : Application handle return during the open process . 2)authorization: Authorization information required for closing the connection. Return value: The status of the operation is returned as function returns value.0 means operation successful. If the status of operation is other than 0 meaning error during close operation and the response parameter describes the details of the error.See section 7 for error code description. 8.3.6 Resolving PE endpoint addresses (Name Resolution ) Client application can request the ENRP name server to resolve names of PE Client specifies the pePoolname along with the authorization. Ram & Senthil [Page 37] Internet Draft Aggregate Server Access Protocol July 2001 Usage: This API is invoked by the client and is provided by ASAP PU layer. (PE can also use this api if it had registered with the pool ) Prototype: int NAME-RESOLUTION( char *appHandle, char *pePoolName , char *authorization, char *response); Arguments: 1) appHandle : Application handle return during the open process . 2) pePoolName: Name of the pool . 3)authorization: Authorization information required for closing the connection. Return value: The status of the operation is returned as function returns value. 0 means operation successful and the PE pool name is valid the list of PE which is returned by the ENRP name server is kept inside the ASAP layer and is not returned to the user layer application. If the status of operation is other than 0 meaning error during NAME-RESOLUTION operation and the response parameter describes the details of the error. See section 7 for error code description. 8.3.7 PU sends data via the ASAP layer Client sends the data to the PE and this method is blocking call. Usage: This API is invoked by the client and is provided by ASAP PU layer. (PE can also this api if it had registered with the pool ) Ram & Senthil [Page 38] Internet Draft Aggregate Server Access Protocol July 2001 Prototype: int sendto (char *appHandle, char *pePoolName , void *data, unsigned int dataSize); Arguments: 1) appHandle : Application handle return during the open process . 2) pePoolName : Name of the pool 3) data: data which has to be sent to the PE. 4) dataSize: size of the data in bytes. Return value: The status of the operation is returned as function returns value. 0 means operation successful. If the status of operation is other than 0 meaning error during sendto operation and the response parameter describes the details of the error. See section 7 for error code description. 8.3.8 PU wishes to receive data obtained from PE Client can receive data from the PE , client invokes this method and is a blocking call. Usage: This API is invoked by the client and is provided by ASAP PU layer. (PE can also use this api if it had registered with the pool ) Prototype: int receivefrom(char *appHandle, char *pePoolName , void *data, unsigned int dataSize); Ram & Senthil [Page 39] Internet Draft Aggregate Server Access Protocol July 2001 Arguments: 1) appHandle : Application handle return during the open process . 2) pePoolName: Name of the Pool 3) data: data which has been received from the PE. 4) dataSize: size of the data in bytes. Return value: The status of the operation is returned as function returns value.0 means operation successful. If the status of operation is other than 0 meaning error during receivefrom operation and the response parameter describes the details of the error. See section 7 for error code description. 9 Security Considerations 9.1 Confidentiality and Privacy: Encryption 9.1.1 Application-Level Encryption Using public-key or shared-key based mechanisms, some or all headers as well as the message body within a Request and/or Response may be encrypted. The Encryption header is included to indicate the encryption mechanism employed. A blank line is used to indicate the start of encryption, and all headers following the blank line and the message body are encrypted. The mechanism follows that in RFC2543. 9.1.2 Lower-Layer Encryption In addition or instead of application layer encryption techniques, lower layer encryption techniques (e.g.IPSec, TLS, or link layer) may be employed. Such encryption may provide certain benefits, such as better protection against traffic analysis attacks (e.g. using link layer encryption). 9.2 Message Integrity and Access Control: Authentication The ASAP protocol utilizes mechanisms provided within HTTP and SIP for message integrity and/or authentication purposes. The Basic and Digest authentication schemes may be used for authentication. In addition, public-key based mechanisms may also be used. The use of the Extensible Authentication Protocol (EAP) within HTTP/SIP (and hence ASAP/ENRP) permits the use of several authentication mechanisms transparently. Irrespective of the type of authentication mechanism, the following procedure is adopted: Ram & Senthil [Page 40] Internet Draft Aggregate Server Access Protocol July 2001 - The WWW-Authenticate header is used within a 401 Response message, by the authenticator in order to indicate the authenticating mechanism and possibly the challenge. - The Authorization header is used within a re-issued Request message, in order to pass the authenticating information to the Authenticator. - The Authentication-Info header is used within a 200 Response message, by the authenticator in order to pass any token that may be needed by the entity that sent the Request message. Typically, all communication needs to be authenticated. Use of authentication for all communication and the inclusion of a token when a PU communicates with a PE, ensure the mitigation of DOS attacks. This is true when rapid authentication of the included authenticator is done by the verifier. Other mechanisms that are employed to combat DOS attacks - such as identifying source parameters for rapid filtering etc. - may also be employed. 9.2.1 Illustration of Digest Scheme While we illustrate the use of the Digest authentication scheme here, a similar approach may be followed for other authentication schemes - Basic authentication, public-key based authentication etc. When a PE first registers with an ENRP server: - A PE first registers with an ENRP server by sending a PE- REGISTRATION Request message without the Authorization header. - The ENRP server returns a 401 Response message with a WWW- Authenticate header indicating that Digest authentication is needed. - The PE sends a new PE-REGISTRATION Request message with an Authorization header included, in order to authenticate itself. - Upon successful authentication, the ENRP server returns a 200 Response message. An Authentication-Info header is included, and this contains a session key that the PE shares with the ENRP server pool. (As part of the ENRP protocol, this ENRP server needs to securely distribute the session key to all other ENRP servers in the ENRP server pool.) For subsequent interactions between a PE and ENRP server: - All messages include an Authenticating Code within the Authorization header. The Authenticating Code is based on the session key shared between the PE and ENRP server pool. For PU - ENRP server interactions: - When a PU sends a Request message without a suitable Authorization header to an ENRP server, the ENRP server returns a 401 message with a WWW-Authenticate header indicating that Digest Authentication is needed. - The PU sends a new Request message with a suitable Authorization header. - Upon successful authentication, the ENRP server returns a 200 Response message containing an Authentication-Info header. The Authentication-Info header contains a token that the PU can include while communicating with a PE. The token is used so that the PE can ensure that the PU has been authorized by an ENRP server. The token Ram & Senthil [Page 41] Internet Draft Aggregate Server Access Protocol July 2001 has to be encrypted using the session key that the ENRP server shares with the PE. For PU - PE interactions: - PU - PE communications use a Request message with a DATA method, and a suitable response. An Authorization header, which contains the token that the PU obtains from the ENRP server, is included in all such communications. Appendix A. Implementation Issues A.1 Transport Protocol Support ENRP Server , ASAP PE and ASAP PU may maintain states and can support UDP or TCP or SCTP transport protocols. All the transport level communication and errors are handled by the ASAP and ENRP layer itself. A.2 Timers It is preferred to keep health check time out values to be same for both ASAP and ENRP server. It is better that both ASAP and ENRP does periodic update to their care taker servers. A.3 PU Caching ASAP PU layer should cache the data of the PE handles until its expiration time. If by any means PE extends its lifetime, ASAP PU will not get update notification for this reason it is better that ASAP PU can perform NAME- RESOLUTION request to get the new ASAP end point list. A.4 Multicasting Support After a new ENRP server gets registered with the pool it request for ENRP server list, from the service control parameters field ENRP server can get information such as whether all ENRP server supports multicast, and it can subscribe to the muticast channels. If multicast is supported by ENRP server and also by PE then all the unicast update message will be sent over the muticast channel. B. Summary of Augmented BNF Please refer to [RFC2543] for a summary. Ram & Senthil [Page 42] Internet Draft Aggregate Server Access Protocol July 2001 C. Acknowledgement We wish to thank the Maureen Stillman and John Loughney for providing valuable comments and suggestions. D. Author's Contact Address Ram Gopal.L Senthil Sengodan Nokia Research Center 5 Wayside Road Burlington, MA 01803 USA email: ram.gopal@nokia.com senthil.sengodan@nokia.com E. Reference [RFC 822 ] D. Crocker, "Standard for the format of ARPA Internet text messages," Request for Comments 822, Internet Engineering Task Force,Aug. 1982. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC 2234] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax specifications: ABNF," Request for Comments 2234, Internet Engineering Task Force, Nov. 1997 [RFC 2279 ] F. Yergeau, "UTF-8, a transformation format of ISO 10646," Request for Comments 2279, Internet Engineering Task Force, Jan. 1998. [RFC2616] R. Fielding et al. Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, Internet Engineering Task Force, June 1999 [RFC 2617] J. Franks et al, HTTP Authentication: Basic and Digest Access Authentication, RFC 2617 Internet Engineering Task Force, June 1999 Ram & Senthil [Page 43] Internet Draft Aggregate Server Access Protocol July 2001 [RFC2960] R. R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960, November 2000 [ENRP ] Ram Gopal and Senthil Sengodan , "End Name Resolution Protocol Candidate ",draft-gopal-asap-candidate-00.txt, July, 2001. [Papoulis] A.Papoulis, Probability, Random Variables, and Stochastic Processes, 3rd Edition, McGraw Hill Publication. [Mullender] Sape Mullender , Distributed Systems, 2nd Edition, Addison-Wesley [Rser-Arch] M. Tuexen, "Architecture for Reliable Server Pooling", Internet Draft,draft-ietf-rserpool-arch-00.txt, April, 2001. [Rser-Comp] J. Loughney, "Comparison of Protocols for Reliable Server Pooling", Internet draft,draft-ietf-rserpool-comp-00.txt, May 1,2001 [Rser-req] M. Tuexen,"Requirements for Reliable Server Pooling", Internet draft,draft-ietf-rserpool-reqts-03.txt,May 9 2001 [SIP Draft] Handley, "Session Inttiation Protocol",Internet draft, draft-ietf-sip-rfc2543bis-02.txt, Nov 2000. [Stevens] W. R. Stevens, TCP/IP illustrated: the protocols , Vol. 1. Reading, Massachusetts: Addison-Wesley, 1994.