Network Working Group Ram Gopal.L
INTERNET DRAFT Senthil Sengodan
Nokia
Expires January, 2002 July 10, 2001
End Name Resolution Protocol Candidate (ENRP)
<draft-gopal-enrp-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 a 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 ENRP protocol and details the how it is
used in conjunction with ASAP protocol.
Table of Contents
1. Introduction..............................................3
1.1 Terminology...............................................4
1.2. Architectural view .......................................5
2 Protocol Overview.........................................7
2.1 Name Server pool..........................................7
2.2 Choosing the Name Server address for registration.........7
2.2.1 ENRP Name server Registration............ ...............7
2.2.2 Name Server List download.................................8
2.2.2.1 Choosing Name Server ID ................................8
Ram & Senthil [Page 1]
Internet Draft End Name Resolution Protocol July 2001
2.2.2.2 Choosing Care Taker Name Server...........................8
2.2.2.3 Avoiding NS-ID Collision..................................9
2.3 ENRP Name Server and PE list download ...................9
2.4 Name Server Updates .....................................9
2.4.1 Name Server Status notification..........................10
2.4.2. PE Status notification...................................10
2.5 NS deRegistration and NS update..........................10
2.6 ENRP Health check........................................10
3 Message Overview.........................................10
4 Request..................................................12
4.1 Request-Line.............................................12
4.2 Method...................................................12
4.2.1 NS-REGISTRATION..........................................13
4.2.2 HEARTBEAT................................................13
4.2.3 UPDATE...................................................13
4.2.4 NS-DOWNLOAD..............................................14
4.2.5 PE-DOWNLOAD..............................................14
5 Response Header..........................................14
5.1 Status-Line..............................................14
5.1.2 Status Codes and Reason Phrases..........................15
6 Header Field Definitions.................................16
6.1 Allow....................................................16
6.2 NS-Parameters ...........................................17
6.3 Policy...................................................17
6.4 Periodic-Update..........................................18
6.5 NS-ID....................................................18
6.6 Server-Type..............................................18
6.7 Transaction-ID...........................................19
6.8 Expires..................................................19
6.9 Security Related Headers.................................19
6.9.1 WWW-Authenticate ........................................19
6.9.2 Authorization............................................20
6.9.3 Authentication-Info......................................20
6.9.4 Encryption...............................................21
6.9.5 Require .................................................21
6.9.6 Response-Key.............................................21
7 Status Code Definitions..................................21
7.1 Successful 2xx...........................................21
7.1.1 200 OK...................................................21
7.2 Request Failure 4xx......................................22
7.2.1 400 Bad Request..........................................22
7.2.2 401 Unauthorized.........................................23
7.2.3 403 Method Not Allowed...................................22
7.2.4 404 Not Found............................................23
7.2.5 409 Request Entity Too Large.............................23
7.3 Server Failure 5xx.......................................23
7.3.1 500 Server Internal Error................................23
7.3.2 501 Not Implemented......................................23
7.3.3 502 Service Unavailable..................................23
7.3.5 503 Version Not Supported................................24
8. Behavior of Name Server..................................24
Ram & Senthil [Page 2]
Internet Draft End Name Resolution Protocol July 2001
8.1 NS - Startup and Shutdown interaction message ..........24
8.1.1 Registering Entity Resolves the Name Server with
which to Register........................................24
8.1.2 Joining Name Server needs to be registered with an NS....25.
...................................................
8.1.3 Name ServerDe-Registering itself from the Pool.......... 25
8.1.4 Download of ASAP/ENRP pool element information on
to NS.......................................... 26
8.1.4.1 Name ServerRequests list of Name Servers in NS-pool......26
8.1.4.2 Response to ENRP-DOWNLOAD message requesting
Name Server list ....................................... 26
8.1.4.3 NS requests PE list from caretaker NS................... 27
8.1.4.4 Response to NS-DOWNLOAD message requesting PE list.......27
8.2 Interaction between a pair of NS.........................28
8.2.1 NS Updates NS status to PEs and other NS in the NS-Pool..28
8.2.1.1 New NS Registration Notification ........................29
8.2.1.2 NS Registration Update...................................29
8.2.1.3 NS Heart beat Failure or NS de-Registration
Notification Update .....................................29
8.2.2 Name Server updating an PE Status to all NS .............30
8.2.2.1 PE registration notification ............................30
8.2.2.2 PE registration update ..................................31
8.2.2.3 PE de-registration or interface heartbeat
failure notification ....................................31
8.2.3 Caretaker NS sends a Heartbeat Request to other NSs in
to NS-pool...............................................32
8.2.4 NS sends Heartbeat Response to Care-Taker NS.............33
8.2.5 NS notifies all other NSs in NS-pool of a change in
caretaker NS ................................33
9 Security Considerations..................................34
9.1 Confidentiality and Privacy: Encryption..................34
9.1.1 Application-Level Encryption............... ..........34
9.1.2 Lower-Layer Encryption...................................34
9.2 Message Integrity and Access Control: Authentication.....34
9.2.1 Illustration of Digest Scheme ...........................34
A. Implementation Issues....................................35
B. Summary of Augmented BNF........................ ........35
C. Acknowledgements.........................................35
D Author's Contact Address.................................36
E Reference................................................36
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
pools.Two protocols - ASAP and ENRP - are proposed within this
architecture.In this document, we give a description of the ASAP
protocol.
Ram & Senthil [Page 3]
Internet Draft End Name Resolution Protocol July 2001
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.
Name Server Pool (NS-Pool) : Refers to ENRP Name Server pool
Application Server Pool (AS-Pool): This term refers to "Pool" in
[Arch], but is introduced here to distinguish from NS-Pool.
Care Taker Name Server: Associated with each Name Server there is
one care taker Name Server in the same pool and is responsible for
health check.
Name Server ID: A unique identifier assigned to each Name Server
after registration in an NS-Pool.
NS Handle: Refers to transport addresses) of a Name Server.
Ram & Senthil [Page 4]
Internet Draft End Name Resolution Protocol July 2001
1.2 Architectural view
Figure 1 represents the architectural view of ENRP in a Rserpool.
Communication of the different elements in this architecture is as
follows:
- ENRP Name Server (say NS 1 and NS 2 ) communicates with each
other using ENRP protocol. There may be more than one Name Server in
a Rserpool.
- ENRP Name server uses its ASAP layer to communicate to its PU or
PE.
- Name Server keeps information regarding legacy servers but does
not communicate to them.
+---------------------+ +-----------+ +-----------+
| Application Server | |Legacy | |Legacy |
| (A1) | |Server (S1)| |Server (S2)|
+---------------------+ +-----------+ +-----------+
| ASAP | || ||
| | +---------------------+
+---------------------+ | ASAP - PPE (A2) |
| Transport Layer | +---------------------+
| | | Transport Layer |
+---------------------+ +---------------------+
|| ||
|| ||
=//===================//===============================//===
||
+---------------------+ || +-------------------+
| Name Server (NS 1) | || | Pool User (P1) |
| | || | |
+----------+----------+ || | |
| ENRP | ASAP | // +-------------------+
+----------+----------+ || | |
| Transport Layer | || | ASAP |
+----------+----------+ || +-------------------+
|| || | Transport Layer |
||=====//=========|| +-------------------+
|| ||
||=====//=======
||
+---------------------+ || +--------+ +--------+
| Name Server (NS 2) | || |Legacy | |Legacy |
| | || |Client | |Client |
+---------------------+ || | (U1) | | (U2) |
| ENRP | ASAP | // +--------+ +--------+
+----------+----------+ || || ||
| Transport Layer | || || ||
+---------------------+ || +-------------------+
|| || | ASAP - PPU (P2) |
||=======//=======|| +-------------------+
|| | Transport Layer |
|| +-------------------+
Ram & Senthil [Page 5]
Internet Draft End Name Resolution Protocol July 2001
|| ||
||====//=========
//
Figure 2: Architectural view of ENRP Name servers
Based on the requirements in [Req], some of the functionality that is
provided within the protocol are:
- The Name 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 Name 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.
- Separate Registration mechanism are provided for Name Server which
is different from PE registration. This will form a pool of ENRP
Name server in a RSerPool scope. Apart from this each Name Server
discovers its care taker server just after the registration
process. (Refer Section 2.2.1 )
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.
- 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.
- Each ENRP name server keeps all state information about
each PE in the AS-Pool and about other Name Servers and
this information is always synchronized between them with
minimal message exchange.
- Use of an ASCII based message exchange (similar to HTTP, SIP)
makes the protocol simpler and easy to implement in low-
processing device.
Ram & Senthil [Page 6]
Internet Draft End Name Resolution 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 Name Server Pool
A pool of ENRP Name servers cooperate (and are synchronized) with one
another using ENRP, and are said to operate within an operational
scope. There may be more than one Name server in an operation scope
to form Name server pool. i.e. this is needed for availability and
all the Name server cooperate and synchronize themselves. The
reasons for having a cooperating/synchronized Name Serverpool
include:
o to handle the case of Name server failures
o distribute load among the Name servers: Load sharing on
heartbeat monitoring function (of PE) can be done.
(a) When an existing Name Server leaves a pool, then the PEs
that are handled by this Name Server need to be distributed
among the other Name Servers in the pool. Similarly, when a new
Name Server enters a pool, one may wish to redistribute the load
among the various Name Servers.
(b) It is uncertain if load sharing can be done for PU queries
to Name servers. PUs cannot know the list of active Name servers
in the operational scope. Their only source of info is from the
DNS (which may not be up-to-date). A possibility is that the
first time a PU contacts a Name server, that server could
download a list of then currently active Name servers, so that
the PU can use say a RR policy for subsequent queries to Name
servers.
2.2 Choosing the Name server address for registration
The Name Server that wants to be a part of a NS-pool obtains the list
of Name servers from the DNS, or possibly some local configuration
setting. This list may not be up-to-date, and some entries in the list
may not be in the NS-pool, while there may be other Name
servers in the pool that are not listed in this entry. The joining Name
Server (Say A ) picks one Name server (Say B) (could be arbitrary)
and sends its registration to this Name server B.
2.2.1 ENRP Name Server Registration
The joining Name Server (say A) after choosing the Name server from the
list ( Refer Section 2.2 ) sends the NS-REGISTRATION message to the
Ram & Senthil [Page 7]
Internet Draft End Name Resolution Protocol July 2001
Name server(say B). The Name server does the initial authentication
(depending upon the security protocol) and sends back the
NS-REGISTRATION response with the appropriate status code. A typical NS-
REGISTRATION request contains, Expire time, service policy and other
server specific information.
2.2.2 Name Server List download
After NS-REGISTRATION is completed successfully, the newly joined
Name Server (Say A) then requests for the Name server list by sending an
NS-DOWNLOAD Request to the Name server with which it completed its
registration (Say B) .
2.2.2.1 Choosing Name Server ID
Requesting Name server after receiving Name Server list, computes the
NS-ID (Name Server ID) that it assigns itself, and chooses its
Care taker Name Server.
The new Name server scans through the all Name server ID's in the list
and chooses the NS-ID which is one greater than the highest value in
the list. i.e, for example if we have five Name Servers and their NS
id are 1,4,5,6 and 15, then the new Name Server that joins the pool
will assign itself an NS-ID of 16 and its care taker Name Server will
have an NS-ID 15.
Name Server NS-ID
Server-1 1 ;Care taker for Name Server 4
Server-2 4 ;Care taker for Name Server 5
Server-3 5 ;Care taker for Name Server 6
Server-4 6 ;Care taker for Name Server 15
Server-5 15 ;Care taker for Name Server 1
Server-6 16 ; Comment Newly joined Name server
Note: The gaps in the Name server ID represents that those servers
have left the NS-pool either normally or abnormally.
Figure 4 Name Server ID Selection.
2.2.2.2 Choosing Care Taker ENRP Name Server
After computing the Name server ID, the newly registered ENRP Name
server chooses its care taker ENRP Name server whose NS-ID is one
lesser than its value. Refer Figure 4, the Care Taker Server for Name
Server 16 will be 15.
Name Server NS-ID
Server-1 1 ;Care taker for Name Server 4
Server-2 4 ;Care taker for Name Server 5
Ram & Senthil [Page 8]
Internet Draft End Name Resolution Protocol July 2001
Server-3 5 ;Care taker for Name Server 6
Server-4 6 ;Care taker for Name Server 15
Server-5 15 ;Care taker for Name Server 16
Server-6 16 ; Comment Newly joined Name server
; Care taker for Name Server1
Figure 5 Name Server Care taker Selection/Reassignment.
2.2.2.3 Avoiding NS-ID Collision
One needs to avoid the case where two or more Name servers (say, A, B,
C) wishing to join a Name server pool at reasonably close points in
time, obtain identical Name server lists, thereby computing an identical
NS-ID (say, 16 as in Figure 5) for itself. When the first ENRP
server (A) contacts its caretaker Name server (with NS-ID 15, which is
say D), then a flag at D is set. When Name Server, say B, subsequently
contacts its caretaker Name server, which is again D, D responds with an
indication that the flag is set. This implies that Name server B needs
to retry its initialization after a certain random amount of time. The
same happens to Name server C.
After Name server A has successfully updated all other Name Servers in
the pool of its joining the pool, the flag at Name Server D is reset. A
timer associated with this flag resets the flag if the update does not
occur within a certain pre-specified amount of time.
2.3 ENRP Name Server and PE list download
After determining the name server ID and Caretaker Name Server, the
newly registered Name Server requests its Caretaker Name Server for PE
list by sending PE-DOWNLOAD request.
2.4 Name Server Updates
2.4.1 Name Server Status notification
Name Server sends the UPDATE message to other Name Servers in the NS-
Pool and other PEs in the AS-Pool. This message is generated due to the
following reasons:
o After the Name Server registration, successful download of Name
Server list and PE data, new Name server sends the Name Server update
list to other Servers and to the list of PE in the pool. The Update
message contains the NS-Parameters of the newly joined Name Server.
o Care taker Name Server sends the ENRP update message due to Health
check failure or normal shutdown of Name server. The update message
contains the NS-Parameter of the failed Name Server.
Ram & Senthil [Page 9]
Internet Draft End Name Resolution Protocol July 2001
o Name Server can extend/update its registration with the NS-pool by
sending UPDATE message, the typical update could be as follows
1. wants to extend the expiry time
2. wants to change the policy and control parameters
2.4.2. PE Status notification
A Name Server sends PE updates only to other Name Servers in the NS-
Pool. These messages are generated due to the following reasons:
o PE health check failure
o PE added to the AS-pool
o PE does a registration update
2.5 NS deRegistration and NS update
An NS can deRegister itself from the NS-pool, by sending
NS_REGISTRATION message with Expires header of value 0, to care taker
NS-server. NS can also de-Register one of its transport
addresses if it is multi homed by setting the corresponding expire
value to 0.
2.6 ENRP Health check
Care taker NS (Say A) will periodically check the heartbeat of each
transport address (in case of multi homing) of NS (say B) that it takes
care of. NS B upon receiving this request, responds thereby indicating
to A that it is alive.
3 Message Overview
ENRP 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 ENRP message is either a request from a client to a server, or
a response from a server to a client.
ENRP-message = Request | Response
Both Request (section 4) and Response (section 5) messages use
the generic-message format of RFC 822 [2] for transferring
Ram & Senthil [Page 10]
Internet Draft End Name Resolution Protocol July 2001
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.
ENRP-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
ENRP.
message-header = Allow ; Section 6.1
| Expires ; Section 6.8
| NS-Parameter ; Section 6.2
| PE-Parameter ; Refer ASAP Draft
| Policy ; Section 6.3
| Periodic-Update ; Section 6.4
| Pool-Handle ; Refer ASAP Draft
| NS-ID ; Section 6.5
| Transaction-ID ; Section 6.7
| Server-Type ; Section 6.6
| 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: ENRP headers
The message syntax proposed for ASAP/ENRP satisfies the following
requirements:
- 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
Ram & Senthil [Page 11]
Internet Draft End Name Resolution Protocol July 2001
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 ENRP protocol is being considered, the Request-Line is:
Request-Line = Method SP ENRP-Version CRLF
Implementations adhering to this document MUST use ENRP/1.0 for
their ASAP-Version.
4.2 Method
The methods are defined below. The Method token is case-sensitive.
Method = "NS-REGISTRATION" | "PE-DOWNLOAD" |
|"NS-DOWNLOAD" |"HEARTBEAT" |"UPDATE"
Ram & Senthil [Page 12]
Internet Draft End Name Resolution Protocol July 2001
4.2.1 NS-REGISTRAION
The NS-REGISTRATION method is used within a Request message that is
sent by a Name Server to another Name Server which is already a
member of a pool to indicate one of the following:
(a) Name Server wishes to join an NS-pool
(b) Name Server, which has already registered itself with an ENRP
server pool and is currently a member of an Name Server pool,
extends/modifies the duration of registration.
(c) Name Server, which has already registered itself with an
Name Server pool deletes its registration.
An NS cancels an existing registration by sending a NS-
REGISTRATION request with an expiration time (Expires header) of
zero seconds for a NS handle or the wildcard Endpoint
Addr designated by a "*" for all registrations. If a Name Server
handle is already found to exist, then the NS-Parameters associated
with it are updated.
4.2.2 HEARTBEAT
Heartbeat message are sent between an NS and its caretaker NS, in
order to check whether the NS is alive.
4.2.3 UPDATE
Name 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 Name Servers to
(1) other Name Servers within the same Name Server pool, as
well as (2) to PE that are registered with this ENRP server
pool: (Refer ASAP Draft for description
of these messages)
(a) New Registration: Name Server wishes to join the server pool
(b) Registration Update: Name 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.).
(c) De-Registration: Name Server, which has already registered
itself with an Name Server pool, deletes its registration.
(c) Heartbeat Failure Notification: Name 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
Name Server within the same pool.
Ram & Senthil [Page 13]
Internet Draft End Name Resolution Protocol July 2001
2) The following update messages are sent by Name Servers to other
Name Servers:
(a) PE registration notification: Notifying a newly added
PE to the AS-pool.
(b) PE registration update: PE , which has already registered
itself with an AS-pool and is currently a member of the
pool, wants to extend/modify the registration attributes (such
as duration, policy etc.).
(c) PE de-registration: PE, which has already registered itself
with an AS-pool, deletes its registration.
(c) PE heartbeat failure notification: Name Server, detects the
failure of a PE during heartbeat check, and
notifies the other Name Servers within the NS-pool.
4.2.4 NS-DOWNLOAD
An NS after joining (registering) with the NS-pool, request the Name
Server list.
4.2.5 PE-DOWNLOAD
An NS after computing its NS-ID and identifying the
caretaker NS, requests PE-DOWNLOAD from its caretaker NS.
5 Response Header
After receiving and interpreting a request message, the recipient
responds with an ENRP response message. The response message
format is shown below:
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.
Ram & Senthil [Page 14]
Internet Draft End Name Resolution Protocol July 2001
Status-Line = Protocol-version SP Status-Code SP Reason-
Phrase CRLF
When ENRP is used, the Staus-Line is:
Status-Line = ENRP-version SP Status-Code SP Reason-
Phrase CRLF
Implementations adhering to this document MUST use ENRP/1.0 for
their ENRP-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
| 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:
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;
Ram & Senthil [Page 15]
Internet Draft End Name Resolution Protocol July 2001
Figures 3 through 5 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
| "409" ; Request Entity Too Large
Figure 4: Client error status codes
Server-Error = "500" ; Internal Server Error
| "501" ; Not Implemented
| "503" ; ASAP/ENRP Version not supported
Figure 5: Server error status codes
6 Header Field Definitions
ENRP 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.
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") ":" *("NS-REGISTRATION" |
"NS-HEARTBEAT" |"UPDATE" | "NS-DOWNLOAD"|"PE-DOWNLOAD"|
| quoted-string)
An example of the Allow header is as follows:
Allow= "NS-REGISTRATION" "PE-DOWNLOAD"
Ram & Senthil [Page 16]
Internet Draft End Name Resolution Protocol July 2001
6.2 NS-Parameters
The NS-Parameter header is defined as follows:
NS-Parameter = ( "NS-Parameter" | "e" ) ":" NS-ID; Handle
NS-ID = ("NS-ID" | "i") ":" Digit
Handle = 1*("(" transport-addr ")" [*(";"contact-params )] [comment
])
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)
comment = quoted-string
The NS-Parameter has one or more transport addresses, each of which
may optionally have contact parameters and comments associated
with them.
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
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 Name Server. It is used during registration of
an NS-server, 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.
Ram & Senthil [Page 17]
Internet Draft End Name Resolution Protocol July 2001
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 Name Server requests the NS for which it is a caretaker, to
declare its presence to the it periodically. It is used within a
response to a HEARTBEAT Request when the NS indicates whether it
supports the periodic presence notification feature or not.
For example, Care taker NS (Say A) requests a periodic-update
heartbeat by generating the HEARTBEAT request message and including
the Periodic-Update header with a value "Yes" to NS (Say B). If
the Name Server B can report its presence periodically
without getting any further request from the care taker NS (A) , then
the Name Server B 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 NS-ID
The NS-ID header field is used to convey the unique identification (ID)
of an NS within an NS-pool. The syntax is as follows:
NS-ID = ("NS-ID" | "i") ":" Digit
Example:
NS-ID=2
6.6 Server-Type
The Server-Type header field is used to convey the type of server
that is being referred to. Currently defined server types are: NS and
PE.
Server-Type = ("Server-Type" | "r") ":" ("NS"|"PE")
Ram & Senthil [Page 18]
Internet Draft End Name Resolution Protocol July 2001
Example:
Server-Type=NS
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 Name server 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.
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] )
Ram & Senthil [Page 19]
Internet Draft End Name Resolution Protocol July 2001
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"
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
auth-info = 1#(nextnonce | [ message-qop ]
| [ response-auth ] | [ cnonce ]
| [nonce-count] )
Ram & Senthil [Page 20]
Internet Draft End Name Resolution Protocol July 2001
nextnonce = "nextnonce" "=" nonce-value
response-auth = "rspauth" "=" response-digest
response-digest = <"> *LHEX <">
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:
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
Ram & Senthil [Page 21]
Internet Draft End Name Resolution Protocol July 2001
depends on the method used in the request, for example:
o ENRP_REGISTRATION: The registration has succeeded, and the ENRP
Server treats the message body of the Response message according
to
Content
o ENRP_REGISTER (Update ): The registration update has succeeded
and the Name Server end point treats the message body of the
Response message according to its Content
o ENRP_HEARTBEAT: The heartbeat has succeed, the Name Server
treats the message body according to its Content.
7.2 Request Failure 4xx
4xx responses are definite failure responses from a particular
server. The Name Server 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 Handle name".
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
(1) Name Server when the PE does registration/update/deregistration
,or
(2) When PU tries to exchange data with PE, or
(3) When PU tries to NAME-RESOLUTION request with Name Server
7.2.3 403 Method Not Allowed
The method specified in the Request-Line is not allowed for the
receipt. The response MUST include an Allow header field
containing a list of valid methods supported by the recipient.
7.2.4 404 Not Found
Ram & Senthil [Page 22]
Internet Draft End Name Resolution Protocol July 2001
The server has definitive information that the resource does not
exist. For instance, when a PU sends a NAME-RESOLUTION Request to
the Name Server and the Pool Handle contained therein does not
exist, then the Name Server returns a 404 Response.
7.2.5 409 Request Entity Too Large
The PE or Name 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.
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 Name 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 Name 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 Name server 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.
Ram & Senthil [Page 23]
Internet Draft End Name Resolution Protocol July 2001
7.3.4 503 Version Not Supported
The Name 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 Name Server
8.1 NS - Startup and Shutdown interaction Messages
This section describes the rules for Name Servers for generating
and processing requests and responses during startup.
8.1.1 Registering Entity Resolves the Name Server with which to
Register
Prior to registering an Name Server with an NS-pool, the registering
entity needs to resolve the IP address of an Name Server(s) with
which it registers.
Several mechanisms are possible, whereby the registering entity
can determine the IP address of an Name Server to register with.
For instance, (1) a registering entity may be manually configured
with a set of IP addresses of Name Servers that it may register
with, or (2) a registering entity may be configured with the DNS
address of a Name 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 Name Server to register with, or
(3) the Service Location Protocol (SLP) may be used to discover a
suitable Name Server.
We briefly describe a possible operation procedure when DNS is
used. The registering entity is configured with the DNS address of
an Name 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.
Ram & Senthil [Page 24]
Internet Draft End Name Resolution Protocol July 2001
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 Name Server.
8.1.2 Joining Name Server needs to be registered with an NS
An Name Server may register with an NS-pool by
contacting one of the NS in the pool. The registering Name Server
resolves the IP address of the Name Server to register with, as
specified in Section 8.1.1.
In order to register with the selected IP address, the Name Server
sends a Request message to the selected IP address with method
set to NS-REGISTRATION. Implementations adhering to this document
MUST set the ENRP-version field to ENRP/1.0. Hence, the Request-
line is as follows:
NS-REGISTRATION ENRP/1.0
For instance, a typical Register-Request message may look like
this:
NS-REGISTRATION ENRP/1.0
Transaction-ID=0xde34682a
Expires: 7200
Authorization:
An Name Server MUST be authenticated before it can register
with an Name Server. In order to handle such authentication, the
ENRP Registration Request message can optionally include an
Authorization header. Security procedures are described Section 9.
8.1.3 Name Server De-Registering itself from the Pool
An Name Server that wishes to withdraw its services from an NS-pool,
does so by issuing a suitable de-register message to the
Name Server(s) and also to the PE. An explicit de-
register message is not provided for the purpose. Instead, de-
registration is inferred by the use of a NS-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:
Ram & Senthil [Page 25]
Internet Draft End Name Resolution Protocol July 2001
NS-REGISTRATION ENRP/1.0
Transaction-ID=0x34ae78d
Expires: 0
Authorization:
NS-ID: 3
8.1.4 Download of ASAP/ENRP pool element information on to NS
8.1.4.1 Name Server Requests list of Name Servers in NS-pool
After NS (say A) has successfully registered itself with
an NS-pool by sending an NS-REGISTRATION request message to
an NS (say B) in the NS-pool, it needs to obtain the list of ENRP
servers in the pool. This is obtained by the NS A sending an
NS-DOWNLOAD request message to NS B (which is the NS
server that it got the registration response from.)
The format of the Request-Line of an NS-DOWNLOAD request message is
as follows
NS-DOWNLOAD ENRP/1.0
A typical message is as follows:
NS-DOWNLOAD ENRP/1.0
Transaction-ID=0x34ae78d
Authorization:
8.1.4.2 Response to NS-DOWNLOAD message requesting Name Server list
After an NS (say A) has successfully registered itself with
an NS-pool by sending an NS-REGISTRATION request message to an
NS (say B) in the NS-pool, it needs to obtain the list of NS
servers in the pool. This is obtained by the NS A sending an
NS-DOWNLOAD request message to NS B (which is the NS that it got the
registration response from.)
When NS B receives such an NS-REGISTRATION request message, it
responds by sending a sequence of NS-Parameters. The NS-Parameter
provides information on parameters such as IP addresses), policy,
timers, NS-ID etc.
An example of a successful response to an NS-DOWNLOAD message is
as follows. Here, three Name Servers (with IDs 1,2 and 3) are present
in the NS-pool. Name Server with NS-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, Name Server with NS-ID of 2 and
3, each have a single interface.
Ram & Senthil [Page 26]
Internet Draft End Name Resolution Protocol July 2001
200 ENRP/1.0
Transaction-ID=0x34ae78d
NS-Parameter:1;
172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000;
NS-Parameter:2;172.19.45.4:40;Expires:65000
NS-Parameter:3;172.20.65.45:568;Expires:42000
Policy: RR
Authorization:
After the requesting NS receives the list of NS-Parameters
based on a successful NS-DOWNLOAD request, it computes its NS-ID by
suitable navigation of the existing NS-IDs in the NS-ID list. (see Sec
2.2.2). Determination of the caretaker Name Server is also made by the
NS at this point (see Sec 2.2.2).
8.1.4.3 NS requests PE list from caretaker NS
An NS queries its caretaker NS for a list of PE, by sending an NS-
DOWNLOAD message. The Server-Type header is set to PE to denote that the
list of PE is queried
for.
An example of an NS-DOWNLOAD message is as follows:
NS-DOWNLOAD ENRP/1.0
Transaction-ID=0x34ae78d
Server-Type: PE
Authorization:
8.1.4.4 Response to NS-DOWNLOAD message requesting PE list
Upon receiving an NS-DOWLOAD request message with Server-Type set
to PE, the caretaker NS responds with a list of PE-Parameters. The PE-
Parameter includes information such as the
IP addresses), policy, timers, and NS-ID of Name
Server which is responsible for performing health check.
An example usage of this message is as follows. Here, Name Server
with NS-ID of 1 is the caretaker NS for two PEs
within the AS-pool www.foo.com. The first PE is multi-homed
with two interfaces - transport address of 172.19.134.20:568 and
172.19.134.21:568. The second PE has a single interface with transport
address of 172.19.45.4:40.
Also, illustrated in the message below is the usage of proxies. The
NS with NS-ID of 2 is the caretaker Name Server for a
legacy application server with transport address of 172.20.65.45:568,
and the proxy PE that is responsible for handling the legacy application
server has an transport address of 145.45.65.30:657.
Ram & Senthil [Page 27]
Internet Draft End Name Resolution Protocol July 2001
200 ENRP/1.0
Transaction-ID=0x34ae78d
Server-Type: PE
Pool-Handle: www.foo.com
NS-ID:1
PE-Parameter:
172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000
NS-ID:1
PE-Parameter: 172.19.45.4:40;Expires:65000
NS-ID:2
PE-Parameter: 172.20.65.45:568;Expires:42000;Proxy-
Addr:145.45.65.30:657
Policy: RR
Authorization:
8.2 Interaction between a pair of NS
The following messages are generated by Name Server in the NS-pool to
other Name Servers and to PE to notify changes of NS in the NS-pool.
8.2.1 NS Updates NS status to PEs and other NS in the NS-Pool
The following update messages are sent by Name Servers to
(1) all other Name Servers within the same NS-pool, as well
as (2) to all PE that are registered with this
NS-pool:
(a) New NS Registration Notification: When an NS (say,
A) wishes to join the NS-pool, it registers itself
with an NS (say, B) that is already in the NS-pool. NS B then
uploads suitable information (including the current list of NS in
the pool as well as the current list of PE that are managed by
this NS-pool) to Name Server A.
Name Server A then notifies all Name Servers and PE
about its new registration. (Sec 8.2.1.1)
(b) NS Registration Update: Name Server, which has already
registered itself with an NS-pool and is currently a member
of the pool, wants to extend/modify the registration
attributes (such as duration, policy etc.). (Sec 8.2.1.2)
(c) NS De-Registration Notification: Name Server, which has
already registered itself with an NS-pool, deletes
its registration by notifying its caretaker Name Server.
After receiving such de-registration message from an NS, the
caretaker NS-server notifies all other NS in the NS-pool of this
de-registration. (Sec 8.2.1.3 )
(d) Heartbeat Failure Notification: Name Server, which is currently
Ram & Senthil [Page 28]
Internet Draft End Name Resolution Protocol July 2001
a member of an NS-pool, notifies to one/more Name Servers
within the pool of the heartbeat failure of another NS within
the
same pool. (Sec 8.2.1.3 )
8.2.1.1 New NS Registration Notification
Newly added Name Server sends its update message to the other NS and
PE. This informs that the new NS is part of the NS-pool.
NS-UPDATE with Server-Type = ENRP and NS-ID refers to the
Name Server ID which has joined the pool.
For instance, NS-UPDATE message may look like this:
NS-UPDATE ENRP/1.0
Transaction-ID=0x34ae78d
Expires: 10000
Server-Type:ENRP
NS-Parameter: NS-ID:2;172.20.65.45:568;Expires:42000;
Authorization:
8.2.1.2 NS Registration Update
An Name Server that is already in an NS-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 NS-UPDATE
method.
NS-UPDATE with Server-Type = ENRP and NS-ID refers to
the NS which has updated its registration attributes.
For instance, when an NS wishes to increase its
registration expiration to a new value of 10000 seconds, then a
Request message as follows is sent:
NS-UPDATE ENRP/1.0
Transaction-ID=0x34ae78d
Server-Type:ENRP
NS-Parameter: NS-ID:2;172.20.65.45:568;Expires:10000;
Authorization:
8.2.1.3 NS Heart beat Failure or NS de-Registration Notification
Updates
Ram & Senthil [Page 29]
Internet Draft End Name Resolution Protocol July 2001
Caretaker Name Server updates all the other Name Servers and PE in
the event of Name Server heartbeat failures or de-Registration. Note
that the NS-ID represents the Name Server which has to be
removed from the NS-pool.Expires value is set to 0.
NS-UPDATE with Server-Type = ENRP and NS-ID refers to the NS which is
no more part of the NS-pool.
For instance, an NS-UPDATE may look like:
NS-UPDATE ENRP/1.0
Transaction-ID=0x34ae78d
Expires: 0
Server-Type:ENRP
NS-ID: 3
Authorization:
8.2.2 Name Server updating a PE Status to all NS
The following update messages, dealing with the update of PE, are
sent by an NS to other NS in the NS-pool:
(a) PE registration notification: Notifying a newly added
PE to the server pool.
(b) PE registration update: PE , which has
already registered itself with an AS-pool and is
currently a member of the pool, wants to extend/modify the
registration attributes (such as duration, policy etc.).
(c) PE de-registration notification: PE , which has already
registered itself with an AS-pool, deletes its registration.
(d) PE heartbeat failure notification: NS,
detects the failure of a PE during heartbeat
check, and notifies the other NSs within the NS-pool.
8.2.2.1 PE registration notification
NS updates other NS(s) regarding newly registered PE .Name
Server which has received the PE-REGISTRATION request chooses Caretaker
NS for that PE. NS-ID denotes the Caretaker NS for that PE. The
caretaker NS is responsible for health check of the PE.
An example is as follows:
NS-UPDATE ENRP/1.0
Transaction-ID=0x34ae78d
PE-Parameter:172.19.146.54:675
Ram & Senthil [Page 30]
Internet Draft End Name Resolution Protocol July 2001
Policy:LRU
Expires: 10000
NS-ID: 3
Authorization:
This implies that the PE with PE-Parameter "172.19.146.54:675" has been
assigned a caretaker NS with NS-ID of 3.
Alternatively, the application server may be a legacy application
server that does not support ASAP/ENRP protocols. Such an application
server may rely on proxy PE to act on its behalf. In this
case, the proxy PE would register the application server with the NS.
When the NS performs a registration notification to
other NSs, it then needs to include both the transport
address of the legacy application server, as well as the transport
address of the proxy PE. The transport address of the legacy application
server is needed in order to respond to a query by a PU (i.e., a NAME-
RESOLUTION REQUEST message). The transport address of the proxy PE is
needed for heartbeat check. An example is as follows:
NS-UPDATE ENRP/1.0
Transaction-ID=0x34ae78d
PE-Parameter:172.19.146.54:675;Proxy: 172.20.43.45:45
Policy:LRU
Expires: 10000
Authorization:
NS-ID: 3
This implies that the PE with PE-Parameter "172.19.146.54:675;Proxy:
172.20.43.45:45" has been assigned a caretaker NS with NS-ID of 3.
8.2.2.2 PE registration update
Caretaker NS updates other NS(s) regarding a registration update to an
already registered PE. This is invoked when the caretaker NS has
received the PE-REGISTRATION request message indicating the update.
An example of an NS-UPDATE request message is as follows:
NS-UPDATE ENRP/1.0
Transaction-ID=0x34ae78d
PE-Parameter:172.19.146.54:675
Policy:LRU
Expires: 10000
Authorization:
8.2.2.3 PE de-registration or interface heartbeat failure
notification
Ram & Senthil [Page 31]
Internet Draft End Name Resolution Protocol July 2001
An PE may have multiple interfaces by which it may be
reached. This is the case of a multi-homed PE . In such a
case, the NS needs to be aware of the availability of
each interface associated with the PE . Thus, heartbeat
check is done for each interface, and any failure of such an
interface heartbeat check is notified to all the NSs.
A multi-homed PE may de-register one/more/all of its
interfaces associated with it. The caretaker NS that
receives such a de-registration request message, also sends an
NS-UPDATE message to all the NSs notifying them of
such de-registration.
The caretaker NS updates its ENRP database and sends an
NS-UPDATE message with the Expires field set to
zero, to other NSs.
For instance, an NS-UPDATE may be as follows:
NS-UPDATE ENRP/1.0
Transaction-ID=0x34ae78d
PE-Parameter:172.19.146.54:675
Expires: 0
Authorization:
In the above example, the de-registration applies to the transport
address indicated in the PE-Parameter header. 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:
NS-UPDATE ENRP/1.0
Transaction-ID=0x34ae78d
PE-Parameter:172.19.146.54:675;expires=0
Policy:LRU
Authorization:
8.2.3 Caretaker NS sends a Heartbeat Request to other NSs in NS-Pool
Associated with each NS is a caretaker NS. The caretaker NS is
responsible for heartbeat check of the NS under its care. A
caretaker NS will send the HEARTBEAT request to the NS under its
care, to examine whether the NS is alive. The format of the
Request-Line of a HEARTBEAT request message is as follows:
HEARTBEAT ENRP/1.0
An example of a heartbeat request is as follow s:
Ram & Senthil [Page 32]
Internet Draft End Name Resolution Protocol July 2001
HEARTBEAT ENRP/1.0
Transaction-ID=0x34ae78d
Periodic-Update: Yes;600
Authorization:
The heartbeat check that a caretaker NS performs is done on
a per-interface basis for the NS under its care. If an ENRP
server is multi-homed and has several interfaces by which the ENRP
server may be reached, then the caretaker NS may need to
poll (send HEARTBEAT request to) each interface associated with the
NS under its care.
8.2.4 NS sends Heartbeat Response to Care-Taker NS
Upon receiving a Heartbeat Request from its caretaker NS, an
NS responds back to its caretaker NS with a Heartbeat Response
message. The response indicates whether a Periodic-
Update is supported or not.
The format of HEARTBEAT response message is as follows:
200 ENRP/1.0
Transaction-ID=0x34ae78d
Periodic-Update: Yes
Authorization:
The interface from which the response to the heartbeat request message
is received, is the interface that corresponds to the heartbeat
response.
8.2.5 NS notifies all other NSs in NS-pool of a change in
caretaker NS
This is the case of a change of caretaker NS notification.
When the caretaker NS of a PE changes, then such a
change needs to be notified to all NSs in the NS-pool.
NS-UPDATE ENRP/1.0
Transaction-ID=0x34ae78d
NS-ID:1;
PE-Parameter:
172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000
NS-ID:2;
PE-Parameter: 172.19.45.4:40;Expires:65000
Policy:LRU
Expires: 10000
Authorization:
This implies that the PE with PE-Parameter of
"172.19.134.20:568;Expires:5000;172.19.134.21:568;Expires:6000" is
Ram & Senthil [Page 33]
Internet Draft End Name Resolution Protocol July 2001
assigned a caretaker NS with NS-ID of 1. Similarly, the PE with PE-
Parameter of "172.19.45.4:40;Expires:65000" has been assigned a
caretaker NS with NS-ID of 2.
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 ENRP 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. Irrespective
of the type of authentication mechanism, the following procedure is
adopted:
- 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.
9.2.1 Illustration of Digest Scheme
While we illustrate the use of the Digest authentication scheme here,
Ram & Senthil [Page 34]
Internet Draft End Name Resolution Protocol July 2001
a similar approach may be followed for other authentication schemes -
Basic authentication, public-key based authentication etc.
When an NS first registers with an NS in an NS-pool:
- An NS (say, A) first registers with an NS (say B) in an NS-pool
by sending a NS-REGISTRATION Request message without the
Authorization header.
- The NS B in the NS-pool returns a 401 Response message with a
WWW-Authenticate header indicating that Digest authentication is
needed.
- The NS A sends a new NS-REGISTRATION Request message with an
Authorization header included, in order to authenticate itself.
- Upon successful authentication, the NS B returns a 200
Response message. An Authentication-Info header is included, and
this contains a session key that all the NSs in the NS-pool share.
For subsequent interactions between a pair of NS in the NS-pool:
- All messages include an Authenticating Code within the
Authorization header. The Authenticating Code is based on the
session key shared by all the NS in the NS-pool.
Appendix
A. Implementation Issues
For Implementation issues Refer ASAP draft Appendix A for more
detail.
B. Summary of Augmented BNF
Please refer to [RFC2543] for a summary.
C. Acknowledgement
We wish to thank the Maureen Stillman and John Loughney for providing
valuable comments and suggestions.
Ram & Senthil [Page 35]
Internet Draft End Name Resolution Protocol July 2001
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
[RFC2960]
R. R. Stewart et al., "Stream Control Transmission
Protocol", RFC 2960, November 2000
[ASAP-Draft]
Ram Gopal and Senthil Sengodan , "Aggregate Server Access Protocol
Candidate ",draft-gopal-asap-candidate-00.txt, July, 2001.
Ram & Senthil [Page 36]
Internet Draft End Name Resolution Protocol 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 Initiation 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.