Network Working Group Q. Xie
INTERNET-DRAFT Motorola
R. R. Stewart
Cisco Systems
Expires in six months Nov. 20, 2001
Endpoint Name Resolution Protocol (ENRP)
<draft-ietf-rserpool-enrp-01.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Endpoint Name Resolution Protocol (ENRP) is designed to work in
conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP]
to accomplish the functionality of the Reliable Server Pooling
(Rserpool) requirements and architecture as defined in [RSERPOOL1]
and [RSERPOOL2].
Within the operational scope of Rserpool, ENRP defines the
procedures and message formats of a distributed fault-tolerant
registry service for storing, bookkeeping, retrieving, and
distributing pool operation and membership information.
Table Of Contents
1. Introduction...............................................2
1.2 Definitions............................................2
2. Conventions................................................3
3. Message Definitions........................................4
3.1 ENRP Parameter Formats.................................4
3.1.1 IPv4 Address Parameter...........................5
3.1.2 IPv6 Address Parameter ..........................5
3.1.3 Pool Element Parameter...........................6
3.1.4 Pool Handle Parameter............................6
3.1.5 Authorization Parameter..........................7
Xie, Stewart [Page 1]
Internet Draft Endpoint Name Resoluton Protocol November 2001
3.1.6 Name Server Identifier Parameter.................7
3.2 ENRP Message Formats..................................7
3.2.1 PEER_PRESENCE message...........................8
3.2.2 PEER_NAME_TABLE_REQUEST message.................9
3.2.3 PEER_NAME_TABLE_RESPONSE message................9
3.2.4 PEER_NAME_UPDATE message........................10
3.2.5 PEER_LIST_REQUEST message.......................11
3.2.6 PEER_LIST_RESPONSE message......................11
4. ENRP Operation Procedures..................................12
4.1 Basic ENRP Operations..................................12
4.1.1 PE Registration..................................12
4.1.2 PE De-registration...............................13
4.1.3 PE Re-registration...............................13
4.1.4 Name Translation.................................14
4.1.5 Server Namespace Update..........................15
4.1.5.1 Add/Update a PE..........................15
4.1.5.2 Remove a PE..............................15
4.1.6 Server Download Namespace from a Peer Server.....16
4.1.7 Server Monitor Peer Status.......................17
4.1.8 Server Download Peer List from a Peer Server.....17
4.1.9 Server Initialization............................17
4.2 Fault Management Operations............................18
4.2.1 Detect and Remove an Unreachable PE..............18
4.2.2 Server Failure Detection by Heartbeat............19
4.2.3 PE or PU Discover Home ENRP Server...............19
5. Variables and Timer Constants..............................20
5.1 Variables..............................................20
5.2 Timer Constants........................................20
6. Security COnsiderations....................................20
7. References.................................................20
8. Acknowledgements...........................................21
9. Authors' Addresses.........................................21
1. Introduction
Endpoint Name Resolution Protocol (ENRP) is designed to work in
conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP]
to accomplish the functionality of the Reliable Server Pooling
(Rserpool) requirements and architecture as defined in [RSERPOOL1]
and [RSERPOOL2].
Within the operation scope of Rserpool, ENRP defines the procedures
and message formats of a distributed fault-tolerant registry service
for storing, bookkeeping, retrieving, and distributing pool
operation and membership information.
Whenever appropriate, in the rest of this document we will refer to
this Rserpool registry service as ENRP namespace, or simply
namespace.
1.2 Definitions
Xie, Stewart [Page 2]
Internet Draft Endpoint Name Resoluton Protocol November 2001
This document uses the following terms:
Operation scope:
The part of the network visible to pool users by a specific
instance of the reliable server pooling protocols.
Pool (or server pool):
A collection of servers providing the same application
functionality.
Pool handle (or pool name):
A logical pointer to a pool. Each server pool will be
identifiable in the operation scope of the system by a unique
pool handle or "name".
ENRP namespace (or namespace):
A cohesive structure of pool names and relations that may be
queried by an internal or external agent.
Pool element (PE):
A server entity that runs ASAP and has registered to a pool.
Pool user (PU):
A server pool user that runs ASAP. Note, a PU can also be a
PE if it has registered itself to a pool.
ENRP namespace server (or ENRP server):
Entity which runs ENRP and is responsible for managing and
maintaining the namespace within the operation scope.
ENRP client channel:
The communication channel through which a PE requests for
ENRP namespace service. The ENRP client channel is usually
defined by the transport address of the home ENRP server and
a well known port number.
ENRP server channel:
Defined by a well known multicast IP address and a well
known port number. All ENRP servers in an operation scope
can send multicast messages to other servers through this
channel. PEs are also allowed to multicast on this channel
occasionally.
Network Byte Order:
Most significant byte first, a.k.a Big Endian.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[RFC2119].
Xie, Stewart [Page 3]
Internet Draft Endpoint Name Resoluton Protocol November 2001
3. Message Definitions
All messages as well as their fields described below shall be in
Network Byte Order during transmission. For fields with a length
bigger than 4 octets, a number in a pair of parentheses may follow
the filed name to indicate the length of the field in number of
octets.
3.1 ENRP Parameter Formats
ENRP parameters are defined in a Type-length-value (TLV) format as
shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Parameter Value :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 16 bits (unsigned integer)
The Type field is a 16 bit identifier of the type of parameter.
It takes a value of 0 to 65534.
The value of 65535 is reserved for IETF-defined extensions. Values
other than those defined in specific SCTP chunk description are
reserved for use by IETF.
Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Type, Parameter Length, and
Parameter Value fields. Thus, a parameter with a zero-length
Parameter Value field would have a Length field of 4. The
Parameter Length does not include any padding bytes.
Parameter Value: variable-length.
The Parameter Value field contains the actual information to be
transferred in the parameter.
The total length of a parameter (including Type, Parameter Length and
Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the Parameter
at the end (i.e., after the Parameter Value field) with all zero
bytes. The length of the padding is not included in the parameter
length field. A sender SHOULD NOT pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
Xie, Stewart [Page 4]
Internet Draft Endpoint Name Resoluton Protocol November 2001
The Parameter Types are encoded such that the highest-order two bits
specify the action that must be taken if the processing endpoint does
not recognize the Parameter Type.
00 - Stop processing this ENRP message and discard it, do not process
any further parameters within it.
01 - Stop processing this ENRP message and discard it, do not process
any further parameters within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' error.
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type'
error.
In the following sections, we define the common parameter formats
used in ENRP.
3.1.1 IPv4 Address Parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address: 32 bits (unsigned integer)
Contains an IPv4 address of the sending endpoint. It is binary
encoded.
3.1.2 IPv6 Address Parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bit (unsigned integer)
Xie, Stewart [Page 5]
Internet Draft Endpoint Name Resoluton Protocol November 2001
Contains an IPv6 address of the sending endpoint. It is binary
encoded.
3.1.3 Pool Element Parameter
This parameter is used in multiple ENRP message to represent an ASAP
endpoint (i.e., a PE in a pool) and the associated information, such
as its transport address(es), load control, and other operational
status information of the PE.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Port | Number of IP addrs=k |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP addr param #0 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP addr param #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ..... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP addr param #k :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Policy Type | Policy Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Life |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the IP address parameters in a PE parameter can be either
an IPv4 or IPv6 address parameter.
3.1.4 Pool Handle Parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Handle :
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter holds a pool handle (i.e., a pool name), defined as
a NULL terminated ASCII string.
Xie, Stewart [Page 6]
Internet Draft Endpoint Name Resoluton Protocol November 2001
3.1.5 Authorization Parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x5 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Authorization Signature :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is used to hold an authorization signature. The
signature is signed over the entire ASAP message and uses a
preconfigured public/private key pair. The receiver of a message
which includes this parameter can validate the message is
from the sender by comparing the signature to one generated
using the peers public key.
3.1.6 Name Server Identifier Parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x7 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name Server SCTP Port | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv4 or IPv6 Addr Param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a name server is multi-homed, any one of its IP addresses can
be used in its Server Identifier Parameter. This is because the
combination of any one of its IP addresses and its SCTP port
number always uniquely identifies the server.
3.2 ENRP Message Formats
The figure below illustrates the common format for all ENRP
messages. Each message is formatted with a Message
Type field, a message-specific Flag field, a Message Length field, and a
Value field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Msg Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Message Value :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Xie, Stewart [Page 7]
Internet Draft Endpoint Name Resoluton Protocol November 2001
Message Type: 8 bits (unsigned integer)
This field identifies the type of information contained in the
Message Value field. It takes a value from 0 to 254. The value
of 255 is reserved for future use as an extension field.
Message Types are encoded such that the highest-order two bits
specify the action that must be taken if the message receiver
does not recognize the Message Type.
00 - Stop processing this message and discard it.
01 - Stop processing this message and discard it, and report the
unrecognized message in an 'Unrecognized Parameter Type'
error.
10 - reserved.
11 - reserved.
Message Flags: 8 bits
The usage of these bits depends on the message type as given by
the Message Type. Unless otherwise specified, they are set to
zero on transmit and are ignored on receipt.
Message Length: 16 bits (unsigned integer)
This value represents the size of the message in bytes including
the Message Type, Message Flags, Message Length, and Message
Value fields. Therefore, if the Message Value field is
zero-length, the Length field will be set to 4. The Message
Length field does not count any padding.
Message Value: variable length
The Message Value field contains the actual information to be
transferred in the message. The usage and format of this field
is dependent on the Message Type.
The total length of a message (including Type, Length and Value
fields) MUST be a multiple of 4 bytes. If the length of the
message is not a multiple of 4 bytes, the sender MUST pad the
message with all zero bytes and this padding is not included in the
message length field. The sender should never pad with more than 3
bytes. The receiver MUST ignore the padding bytes.
3.2.1 PEER_PRESENCE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Xie, Stewart [Page 8]
Internet Draft Endpoint Name Resoluton Protocol November 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The receiving server's ID does not need to be included if the
message is being multicasted.
"Reply_required" (R) flag shall be set to '1' if response to this
message is required, otherwise set to '0'.
3.2.2 PEER_NAME_TABLE_REQUEST message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x2 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The receiving server's ID does not need to be included if the
message is being multicasted.
(Editor's note: we may not support multicast of this message).
3.2.3 PEER_NAME_TABLE_RESPONSE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 |0|0|0|0|0|0|0|M| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool entry #1 (see below) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ... :
Xie, Stewart [Page 9]
Internet Draft Endpoint Name Resoluton Protocol November 2001
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool entry #n (see below) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"More_to_send" (M) flag:
shall be set to '1' if there are more pool entries to be sent
in subsequent PEER_NAME_TABLE_RESPONSE messages. Otherwise, it
shall be set to '0'.
Pool entries:
At least one pool entry MUST be present in the message. Each
pool entry MUST start with a pool handle parameter, followed by
one or more pool element (PE) parameters, i.e.:
+---------------------------+
: Pool handle :
+---------------------------+
: PE #1 :
+---------------------------+
: PE #2 :
+---------------------------+
: ... :
+---------------------------+
: PE #n :
+---------------------------+
3.2.4 PEER_NAME_UPDATE message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool handle :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Element :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update action |
Xie, Stewart [Page 10]
Internet Draft Endpoint Name Resoluton Protocol November 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The receiving server's ID does not need to be included if the
message is being multicasted.
"Update_action" field:
shall take one of the following values:
0x0 - ADD_PE: add the PE as a new member to or update the PE in
the named pool in the namespace.
0x1 - DELETE_PE: delete the specified PE from the namespace.
3.2.5 PEER_LIST_REQUEST message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x5 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The receiving server's ID does not need to be included if the
message is being multicasted.
3.2.6 PEER_LIST_RESPONSE message
This message shall contain all the peer information of the sending
server.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x6 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ID of Peer Server #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ID of Peer Server #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Xie, Stewart [Page 11]
Internet Draft Endpoint Name Resoluton Protocol November 2001
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Reject" (R) flag:
shall be set to '1' if the sender of this message is rejecting
a peer list request. In such a case, this message MUST be sent
with no peer server ID included.
4. ENRP Operation Procedures
In this section, we discuss the procedures defined by ENRP. The
procedures are divided into two groups, namely the basic ENRP
operations and fault management procedures.
Many of the Rserpool events call for message exchange and other
activities between both a PE and an ENRP server and the ENRP server
and its peers. But only the message exchange and activities between
the ENRP server and its peers are considered within the ENRP
protocol definition scope
Procedures and message formats for communications between the PE
and ENRP servers are defined in [ASAP]. However, in order to put
our discussion in context, we will give brief description of the
ASAP activities whenever appropreate.
4.1 Basic ENRP Operations
4.1.1 PE Registration
ENRP server <-> PE:
This action is part of the ASAP protocol and is defined in [ASAP].
To register itself with the name space, a PE sends a REGISTRATION
message over the ENRP client channel to its home ENRP server.
In the REGISTRATION message, the PE indicates the name of the pool
it wishes to join in a pool handle parameter, and its port number
and network access address(es) and any load control information in
a PE parameter.
The ENRP server handles the REGISTRATION message according to the
following rules:
1) If the named pool does not exist in the namespace, the ENRP
server will creates a new pool with that name in the namespace and
add the PE to the pool as its first PE;
2) If the named pool already exists in the namespace, but the
requesting PE is not currently a member of the pool, ENRP server
will add the PE as a new member to the pool;
Xie, Stewart [Page 12]
Internet Draft Endpoint Name Resoluton Protocol November 2001
3) If the named pool already exists in the namespace AND the
requesting PE is already a member of the pool, the ENRP server
shall consider this as a re-registration case. The ENRP Server
shall replace the attributes of the existing PE with the
information carried in the received REGISTRATION message.
4) The ENRP server may reject the registration due to reasons such
as invalid values, lack of resource, etc.
In all cases, the ENRP server will reply to the requesting PE with
a REGISTRATION_RESPONSE message, and will indicate in the message
body whether the registration is granted or rejected.
ENRP server <-> Its peers:
If the registration request is granted (i.e., cases 1-3 above),
the ENRP server MUST take the namespace modification action as
described in section 4.1.5.1?. Otherwise, no message shall be
exchanged with its peers.
4.1.2 PE De-registration
ENRP server <-> PE:
This action is part of the ASAP protocol and is defined in [ASAP].
To remove itself from a pool, a PE sends a DEREGISTRATION message
over the ENRP client channel to its home ENRP server.
In response, the home ENRP server sends a REGISTRATION_RESPONSE
message to the PE and indicates in the message body whether the
request is granted or rejected.
If the PE is the last one of the named pool, the home ENRP server
will remove the pool from the namespace as well.
The ENRP server may reject the de-registration request due to
reasons such as invalid parameters, etc.
It should be noted that de-registration does not stop the PE from
sending or receiving application messages.
ENRP server <-> peers:
Once the de-registration request is granted and the PE removed from
its local copy of the namespace, the home ENRP server MUST take the
namespace modification action described in Section 4.1.5.2.
4.1.3 PE Re-registration
A PE may re-register itself to the namespace with a new set of
Xie, Stewart [Page 13]
Internet Draft Endpoint Name Resoluton Protocol November 2001
attributtes in order to, for example, extend its registration
life, change its load policy value.
However, an existing PE MUST NOT change its access address list
via re-registration. Instead, to change its address list a PE
shall de-register itself first and then register with the
namespace as a new PE.
A PE can modify its load policy value at any time via
re-registration. Based on the number of PEs in the pool and the
pool's load distrbution policy, this operation allows the PE to
dynamically control its share of inbound messages received by the
pool (also see Section 4.5.2 in [ASAP] for more on load control).
ENRP server <-> PE:
This action is part of the ASAP protocol and is defined in [ASAP].
To perform a re-registration, a registered PE shall simply send
a new REGISTRATION message with a new set of attributes over the
ENRP client channel to its home ENRP server.
Upon the reception of this REGISTRATION message, the home ENRP
server shall follow the same procedures described in Section
4.1.1.
ENRP server <-> peers:
If the REGISTRATION message is accepted, the home ENRP server
shall take the action described in Section 4.1.5.1?. Otherwise, no
message shall be exchanged with its peers.
4.1.4 Name Translation
ENRP server <-> PE or PU:
This action is part of the ASAP protocol and is defined in [ASAP].
A PE or PU can use the name translation service provided by the ENRP
server to resolve a pool name to a list of accessible transport
addresses of existing PEs.
This requires the PE or PU to send a NAME_RESOLUTION messages to its
home ENRP server and in the NAME_RESOLUTION message specify the pool
name to be translated in a Pool Handle parameter.
If the named pool exits in the namespace, the home ENRP server will
send back a NAME_RESOLUTION_RESPONSE message that shall carry a
list of PE parameters containing all information of the PEs
currently registered under that pool name. This information may
include the current load control policy of the pool, policy value
of each PE, transport address(es) for each PE, etc.
Xie, Stewart [Page 14]
Internet Draft Endpoint Name Resoluton Protocol November 2001
Otherwise, the ENRP server shall respond with a NAME_UNKNOWN
message.
ENRP server <-> peers:
None.
4.1.5 Server Namespace Update
This includes a set of update operations used by an ENRP server to
inform its peer(s) about the addition of a new PE, removal of an
existing PE, or change of pool or PE properties.
4.1.5.1 Add/Update a PE
When a new PE is granted registration to the namespace or an
existing PE is granted a re-registration, the home ENRP server
uses this procedure to inform all its peers.
An ENRP server shall multicast over the ENRP server channel a
PEER_NAME_UPDATE message with the Update_action field set to
ADD_PE, indicating the addition of the new PE or the update of an
existing PE to the namespace. The PE and the pool its belongs to
shall be indicated in the message with a PE parameter and a Pool
Handle parameter, respectively (see Section 3.2.4).
Upon the reception of this PEER_NAME_UPDATE message, each of the
peer ENRP servers shall take the following actions:
1) If the named pool under which the PE has been registered (or
re-registered) does not exist in the peer's local copy of the
namespace, the peer ENRP server shall create the named pool in its
local namespace copy and add the PE to it as the first PE. It then
shall copy in all other attributes of the PE carried in the
message.
2) If the named pool already exists in the peer's local copy of the
namespace AND the PE does not exist, the peer shall add the PE to
the pool as a new PE and copy in all attributes of the PE carried
in the message.
3) If the named pool exists AND the PE is already a member of the
pool in its the local copy of the namespace, the peer ENRP server
shall replace the attributes of the PE with the new information
carried in the message.
4.1.5.2 Remove a PE
This procedure is used by an ENRP server to inform its peer(s) to
remove an existing PE.
Xie, Stewart [Page 15]
Internet Draft Endpoint Name Resoluton Protocol November 2001
An ENRP server shall multicast over the ENRP server channel a
PEER_NAME_UPDATE message with the Update_action field set to
DELETE_PE, indicating the removal of an existing PE from the
namespace. The PE and the pool its belongs to shall be indicated
in the message with a PE parameter and a Pool Handle parameter,
respectively.
On the reception of this PEER_NAME_UPDATE message, each peer ENRP
server shall find and remove the PE from its local copy of the
namespace. If the peer does not find the PE in its local copy of
the namespace, it SHOULD take no action.
4.1.6 Server Download Namespace from a Peer Server
This operation allows an ENRP server to request and receive a copy
of the current namespace from one of its peer ENRP servers.
This operation is especially useful for a newly started ENRP server
to initiate its local copy of the namespace, as well as for an
existing ENRP server to correct namespace inconsistency found during
its operation.
1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message
directly to one of its peers.
2) Upon the reception of this message, the peer server shall
initiate a download session in which the namespace shall be sent
to the requesting ENRP server in one or more
PEER_NAME_TABLE_RESPONSE messages.
If the sending ENRP server determines that multiple
PEER_NAME_TABLE_RESPONSE messages are needed for the session, it
shall use the M flag in each PEER_NAME_TABLE_RESPONSE message to
inform the receiving ENRP server whether or not the data
in this message is the last piece of the namespace transfer.
3) During the downloading, every time the requesting ENRP server
receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer the
data entries carried in the message into its local namespace
database, and then check whether or not the data in this message is
the last piece being transfered. If more data transfer is indicated,
the requesting ENRP server shall send another
PEER_NAME_TABLE_REQUEST message to the same peer to request for the
next piece whenever it is ready.
When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE
message into its local namespace database, the requesting ENRP
server shall handle each PE by the following steps:
1) If the named pool does not exist in the local namespace, the
ENRP server will creates a new pool with that name in the
namespace and add the PE to the pool as the first PE;
Xie, Stewart [Page 16]
Internet Draft Endpoint Name Resoluton Protocol November 2001
2) If the named pool already exists in the local namespace, but
the PE is not currently a member of the pool, ENRP server shall
add the PE as a new member to the pool;
3) If the named pool already exists in the local namespace AND
the requesting PE is already a member of the pool, the ENRP
server may skip this PE.
4.1.7 Server Monitor Peer Status
An ENRP server shall keep a record on the status of each of its
known peers. This record is referred to as the "Peer list" of the
server.
An interanl variable <Peer-last-heared> is kept for each peer on
the peer list and its value updated to the current local time each
time a message of any type is received from the peer.
If a message of any type is received from a peer previously
unknown, the ENRP server shall create a record for the new peer
and add it to the peer list.
4.1.8 Server Download Peer List from a Peer Server
This operation allows an ENRP server to request from a peer server
a copy of its peer list. This is useful for a new ENRP server to
initiate its own peer list at startup.
An ENRP server shall send a PEER_LIST_REQUEST message to a peer to
request a copy of the peer list.
Upon the reception of this message, the peer server shall reply
with a PEER_LIST_RESPONSE message and include in the message body
a list of server IDs of all known peers.
If the peer itself is in the process of startup and not ready to
provide a good peer list, it shall response with a
PEER_LIST_RESPONSE message but set the R flag in the message to
'1' to indicate that it can not grant the PEER_LIST_REQUEST. In
such a case, the requesting ENRP server shall select another peer
and repeat the peer list request with the new peer at a later
time.
4.1.9 Server Initialization
This section describes the steps a new ENRP server needs to take in
order to join the other existing ENRP servers for providing the
namespace service in the operation scope, or initiating the
namespace service if this is the first ENRP server starting in the
operation scope.
Xie, Stewart [Page 17]
Internet Draft Endpoint Name Resoluton Protocol November 2001
1) At startup, before getting into service, the ENRP server
(initiating server) shall multicast a PEER_PRESENCE message with
'Reply_required' flag set over the ENRP server channel. This is to
inform any other existing peers in the operation scope about the
initiating peer's presence.
2) Upon the reception of this message, a peer shall send a
PEER_PRESENCE without 'Reply_required' flag back to the initiating
server, in order to help the initiating server to build a peer list.
3) If no response to its PEER_PRESENCE message are received after
<MAX-TIME-SERVER-HUNT> seconds, the initiating server shall assume
that it is alone in the operation scope and shall mark the
initialization process as completed. The initiation server shall
skip the remaining steps and start to offer the namespace
services.
4) If there are responses to its PEER_PRESENCE message, the
initiating server shall then take the actions described in 4.1.8 to
request a peer list from one of the peers that have responded.
5) Upon the reception of the PEER_LIST_RESPONSE message from the
peer, the initiating server shall use the information carried in the
message to build a complete peer list.
6) Then, the initiating server shall request to download a copy of
the namespace from one of the peer, as described in 4.1.6.
At this point, the initialization process is completed and the
initiating server shall start to provide namespace services.
4.2 Fault Management Operations
The following operations are used to detect and recover from
various system faults.
4.2.1 Detect and Remove an Unreachable PE
Whenever a PE finds a peer PE unreachable (e.g., via an SCTP
SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the
former shall send an ENDPOINT_UNREACHABLE message over the ENRP
client channel to its home ENRP server. The message shall contain
the pool handle and one of the transport addresses of the
unreachable peer PE in a PE parameter.
Note: The definition and procedure of ENDPOINT_UNREACHABLE message
are part of ASAP and are described in [ASAP].
Upon the reception of the ENDPOINT_UNREACHABLE message, the home
ENRP server shall immediately send an ENDPOINT_KEEP_ALIVE message
to the PE that is reported as unreachable. If this
ENDPOINT_KEEP_ALIVE fails (i.e., it results in an SCTP
Xie, Stewart [Page 18]
Internet Draft Endpoint Name Resoluton Protocol November 2001
SEND.FAILURE notification), the ENRP server shall consider the PE
as truly unreachable and shall remove the PE from its local copy
of the namespace and take actions described in 4.1.5.2.
Note: The definition and handling of the ENDPOINT_KEEP_ALIVE
message by the PE are part of ASAP and are described in Sections
3.2.8? and 4.9.3? in [ASAP].
4.2.2 Server Failure Detection by Heartbeat
An ENRP server shall multicast, in every <PEER-HEARTBEAT-CYCLE>
seconds, a PEER_PRESENCE message over the ENRP server channel to
inform its peers that it is still operational. In the multicasted
PEER_PRESENCE message, the sending ENRP server shall set the
'Replay_required' flag to '0' indicating that no response is
required.
An ENRP server shall keep track the time when the last message
(multicast or point-to-point) was received from each known peer in
the internal variable <Peer-last-heared>.
If a peer has not been heard for more than <MAX-TIME-LAST-HEARD>
seconds, the ENRP server shall send a point-to-point PEER_PRESENCE
with 'Reply_request' flag set to '1' to that peer.
If the send fails or the peer does not reply after
<MAX-TIME-NO-RESPONSE> seconds, the ENRP server shall consider
the peer server dead and shall remove the peer from its peer list.
When an ENRP server receives a PEER_PRESENCE message with
'Reply_request' flag set to '1', it MUST immediately respond to
the sender with its own point-to-point PEER_PRESENCE message
without setting the 'Replay_required' flag.
4.2.3 PE or PU Discover Home ENRP Server
This action is part of ASAP protocol and is defined in [ASAP].
At its startup, or when it fails to send to (i.e., timed-out on a
service request) with its current home ENRP server, a PE or PU shall
initiate the following procedure to find a new home server.
In the home server hunt procedure, the PE or PU shall multicast a
SERVER_HUNT message over the ENRP client channel, and shall repeat
sending this message every <TIMEOUT-SERVER-HUNT> seconds until a
SERVER_HUNT_RESPONSE message is received from an ENRP server.
Then the PE or PU shall pick one of the ENRP servers that have
responded as its new home ENRP server, and send all its subsequent
the namespace service requests to this new home server.
Upon the reception of the SERVER_HUNT message, an ENRP server shall
Xie, Stewart [Page 19]
Internet Draft Endpoint Name Resoluton Protocol November 2001
reply to the PE with a SERVER_HUNT_RESPONSE message.
5. Variables and Time Constants
5.1 Variables
<Peer-last-heared> - the local time that a peer server was last
heard (via receiving either a multicast or
point-to-point message from the peer).
5.2 Timer Constants
<PEER-HEARTBEAT-CYCLE> - the period for an ENRP server to send out a
heartheat message to its known peers.
(Default=30 secs.)
<MAX-TIME-LAST-HEARD> - pre-set threshold for how long an ENRP
server will wait before considering a
silent peer server potentially dead.
(Default=61 secs.)
<MAX-TIME-NO-RESPONSE> - pre-set threshold for how long a message
sender will wait for a response after
sending out a message. (Default=5 secs.)
<TIMEOUT-SERVER-HUNT> - pre-set threshold for how long a sender
will wait before sending another
SERVER_HUNT message out. (Default=5 secs.)
6. Security COnsiderations
[TBD]
7. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol
(ASAP)", <draft-ietf-rserpool-asap-00.txt>, work in progress.
[RSERPOOL1] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore,
L. Ong, J. Loughney, M. Stillman: "Requirements for Reliable Server
Pooling," <draft-ietf-rserpool-reqts-03.txt>, work in progress.
[RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore,
L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server
Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress.
Xie, Stewart [Page 20]
Internet Draft Endpoint Name Resoluton Protocol November 2001
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and,
V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October
2000.
8. Acknowledgements
The authors wish to thank John Loughney, Lyndon Ong, and Maureen
Stillman and many others for their invaluable comments.
9. Authors' Addresses
Randall R. Stewart
24 Burning Bush Trail.
Crystal Lake, IL 60012
USA
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
Expires in six months from Nov. 2001
Xie, Stewart [Page 21]
Internet Draft Endpoint Name Resoluton Protocol November 2001
Xie, Stewart [Page 22]
