Network Working Group Ram Gopal.L
INTERNET DRAFT Senthil Sengodan
Nokia
Expires January, 2002 July 10, 2001
Aggregate Server Access Protocol Candidate (ASAP)
<draft-gopal-asap-candidate-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 = *<TEXT-UTF8, excluding CR, LF>
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.