draft-ietf-rserpool-enrp-00.txt   draft-ietf-rserpool-enrp-01.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
INTERNET-DRAFT Motorola INTERNET-DRAFT Motorola
R. R. Stewart R. R. Stewart
Cisco Systems Cisco Systems
Expires in six months June 1, 2001 Expires in six months Nov. 20, 2001
Enpoint Name Resolution Protocol (ENRP) Endpoint Name Resolution Protocol (ENRP)
<draft-ietf-rserpool-enrp-00.txt> <draft-ietf-rserpool-enrp-01.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 1, line 42 skipping to change at page 1, line 42
(Rserpool) requirements and architecture as defined in [RSERPOOL1] (Rserpool) requirements and architecture as defined in [RSERPOOL1]
and [RSERPOOL2]. and [RSERPOOL2].
Within the operational scope of Rserpool, ENRP defines the Within the operational scope of Rserpool, ENRP defines the
procedures and message formats of a distributed fault-tolerant procedures and message formats of a distributed fault-tolerant
registry service for storing, bookkeeping, retrieving, and registry service for storing, bookkeeping, retrieving, and
distributing pool operation and membership information. distributing pool operation and membership information.
Table Of Contents Table Of Contents
1. Introduction.................................................. 2 1. Introduction...............................................2
1.2 Definitions................................................ 3 1.2 Definitions............................................2
2. Conventions................................................... 4 2. Conventions................................................3
3. ENRP Message Definitions...................................... 4 3. Message Definitions........................................4
3.1 PE Parameter Definition.................................... 4 3.1 ENRP Parameter Formats.................................4
3.2 PEER_PRESENCE message...................................... 5 3.1.1 IPv4 Address Parameter...........................5
3.3 PEER_NAME_TABLE_REQUEST message............................ 5 3.1.2 IPv6 Address Parameter ..........................5
3.4 PEER_NAME_TABLE_RESPONSE message........................... 6 3.1.3 Pool Element Parameter...........................6
3.5 PEER_NAME_UPDATE message................................... 7 3.1.4 Pool Handle Parameter............................6
3.6 PEER_LIST_REQUEST message.................................. 8 3.1.5 Authorization Parameter..........................7
3.7 PEER_LIST_RESPONSE message................................. 9 3.1.6 Name Server Identifier Parameter.................7
3.8 TAKEOVER_INITIATE message..................................10 3.2 ENRP Message Formats..................................7
3.9 TAKEOVER_INITIATE_RESPONSE message.........................11 3.2.1 PEER_PRESENCE message...........................8
3.10 TAKEOVER_PEER_SERVER message..............................11 3.2.2 PEER_NAME_TABLE_REQUEST message.................9
3.11 SERVER_DUMP message.......................................12 3.2.3 PEER_NAME_TABLE_RESPONSE message................9
3.12 SERVER_DUMP_RESPONSE message..............................12 3.2.4 PEER_NAME_UPDATE message........................10
4. ENRP Operation Procedures.....................................14 3.2.5 PEER_LIST_REQUEST message.......................11
4.1 Basic ENRP Operations......................................14 3.2.6 PEER_LIST_RESPONSE message......................11
4.1.1 PE Registration........................................14 4. ENRP Operation Procedures..................................12
4.1.2 PE De-registration.....................................15 4.1 Basic ENRP Operations..................................12
4.1.3 Name Translation.......................................16 4.1.1 PE Registration..................................12
4.1.4 Server Namespace Update................................16 4.1.2 PE De-registration...............................13
4.1.4.1 Add a New PE.......................................16 4.1.3 PE Re-registration...............................13
4.1.4.2 Forceful Removal of a PE...........................17 4.1.4 Name Translation.................................14
4.1.4.3 Advisory Removal of a PE...........................17 4.1.5 Server Namespace Update..........................15
4.1.4.4 Update PE Attributes...............................18 4.1.5.1 Add/Update a PE..........................15
4.1.4.5 Claim Ownership over a PE..........................18 4.1.5.2 Remove a PE..............................15
4.1.4.6 Report PE Communication Failure....................18 4.1.6 Server Download Namespace from a Peer Server.....16
4.1.5 PE Change Policy Value.................................19 4.1.7 Server Monitor Peer Status.......................17
4.1.6 Server Download Namespace from a Peer Server...........19 4.1.8 Server Download Peer List from a Peer Server.....17
4.1.7 Server Monitor Peer Status.............................20 4.1.9 Server Initialization............................17
4.1.8 Server Download Peer List from a Peer Server...........20 4.2 Fault Management Operations............................18
4.1.9 ENRP Server Initialization.............................21 4.2.1 Detect and Remove an Unreachable PE..............18
4.2 Fault Management Operations................................21 4.2.2 Server Failure Detection by Heartbeat............19
4.2.1 Detect and Report Unreachable PE.......................21 4.2.3 PE or PU Discover Home ENRP Server...............19
4.2.2 ENRP Server Failure Detection by Heartbeat.............22 5. Variables and Timer Constants..............................20
4.2.3 PE Home ENRP Server Hunt...............................23 5.1 Variables..............................................20
4.2.4 ENRP Server Detecting and Taking-over Inactive Peer ...23 5.2 Timer Constants........................................20
4.2.5 Registration of Remote PEs.............................25 6. Security COnsiderations....................................20
4.3 Maintenance Operations.....................................25 7. References.................................................20
4.3.1 Forceful Removal of a PE...............................25 8. Acknowledgements...........................................21
4.3.2 Dump Home PE List......................................25 9. Authors' Addresses.........................................21
4.3.3 Dump Remote PE List....................................26
4.3.4 Dump Peer Server List..................................26
5. Variables, Time Constants, and Thresholds....................26
5.1 Variables..................................................26
5.2 Timer Constants............................................26
5.3 Thresholds.................................................27
6. References....................................................27
7. Acknowledgements..............................................27
8. Authors' Addresses...........................................27
1. Introduction 1. Introduction
Endpoint Name Resolution Protocol (ENRP) is designed to work in Endpoint Name Resolution Protocol (ENRP) is designed to work in
conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP] conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP]
to accomplish the functionality of the Reliable Server Pooling to accomplish the functionality of the Reliable Server Pooling
(Rserpool) requirements and architecture as defined in [RSERPOOL1] (Rserpool) requirements and architecture as defined in [RSERPOOL1]
and [RSERPOOL2]. and [RSERPOOL2].
Within the operation scope of Rserpool, ENRP defines the procedures Within the operation scope of Rserpool, ENRP defines the procedures
skipping to change at page 3, line 41 skipping to change at page 3, line 34
A server entity that runs ASAP and has registered to a pool. A server entity that runs ASAP and has registered to a pool.
Pool user (PU): Pool user (PU):
A server pool user that runs ASAP. Note, a PU can also be a A server pool user that runs ASAP. Note, a PU can also be a
PE if it has registered itself to a pool. PE if it has registered itself to a pool.
ENRP namespace server (or ENRP server): ENRP namespace server (or ENRP server):
Entity which runs ENRP and is responsible for managing and Entity which runs ENRP and is responsible for managing and
maintaining the namespace within the operation scope. maintaining the namespace within the operation scope.
ENRP maintenance client (or maintanance client):
A special program that runs ASAP and has the additional
capability of exchanging ENRP maintenance messages with an
ENRP server in order to perform certain maintenance
functions.
Home ENRP server:
The ENRP server to which a PE currently belongs. PEs
normally choose the ENRP server on their local host as the
home ENRP server, if one exists. A PU shall only have one
home ENRP server at any given time, and both the PU and the
home ENRP server shall keep track of this master/slave
relationship between them.
ENRP server takeover:
The event that a remote ENRP server takes the ownership of
all the PEs on a node and becomes their new home ENRP
server.
Caretaker ENRP server:
The ENRP server on a remote node which takes ownership of
all PEs on the local node because of the absence of an
active local ENRP server.
ENRP client channel: ENRP client channel:
The communication channel through which a PE requests for The communication channel through which a PE requests for
ENRP namespace service. The ENRP client channel is usually ENRP namespace service. The ENRP client channel is usually
defined by the transport address of the home ENRP server and defined by the transport address of the home ENRP server and
a well known port number. a well known port number.
ENRP server channel: ENRP server channel:
Defined by a well known multicast IP address and a well Defined by a well known multicast IP address and a well
known port number. All ENRP servers in an operation scope known port number. All ENRP servers in an operation scope
can send multicast messages to other servers through this can send multicast messages to other servers through this
skipping to change at page 4, line 35 skipping to change at page 4, line 5
Network Byte Order: Network Byte Order:
Most significant byte first, a.k.a Big Endian. Most significant byte first, a.k.a Big Endian.
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Message Message Definitions 3. Message Definitions
All messages as well as their fields described below shall be in All messages as well as their fields described below shall be in
Network Byte Order during transmission. For fields with a length Network Byte Order during transmission. For fields with a length
bigger than 4 octets, a number in a pair of parentheses may follow 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 the filed name to indicate the length of the field in number of
octets. octets.
3.1 PE Parameter Definition 3.1 ENRP Parameter Formats
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.
The parameter is defined to support PEs with up to 8 different IPv4 ENRP parameters are defined in a Type-length-value (TLV) format as
transport addresses. shown below.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #0 | | Parameter Type | Parameter Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #1 | : :
+-------------------------------+-------------------------------+ : Parameter Value :
\ \ \ \ : :
/ / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
+-------------------------------+-------------------------------+
| IP address #7 |
+-------------------------------+-------------------------------+
| SCTP Port | Padding |
+-------------------------------+-------------------------------+
| Load sharing policy type | Policy Value |
+---------------+---------------+---------------+---------------+
The total size of a PE parameter is 40 octets. Parameter Type: 16 bits (unsigned integer)
3.2 PEER_PRESENCE message The Type field is a 16 bit identifier of the type of parameter.
It takes a value of 0 to 65534.
0 1 2 3 The value of 65535 is reserved for IETF-defined extensions. Values
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 other than those defined in specific SCTP chunk description are
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved for use by IETF.
| ENRP server message identifier #1 = 0x27047729 |
+-------------------------------+-------------------------------+
| ENRP server message identifier #2 = 0x53829149 |
+-------------------------------+-------------------------------+
| Type = 0x100 |
+-------------------------------+-------------------------------+
| sender's IP address |
+-------------------------------+-------------------------------+
| sender's SCTP port | padding |
+-------------------------------+-------------------------------+
| receiver's IP address |
+-------------------------------+-------------------------------+
| receiver's SCTP port | padding |
+-------------------------------+-------------------------------+
| Reply required |
+-------------------------------+-------------------------------+
The receiving server's IP address and port do not need to be filled Parameter Length: 16 bits (unsigned integer)
in if the message is being multicasted.
'Reply_required' flag shall be set to 0x1 if response to this The Parameter Length field contains the size of the parameter in
message is required, otherwise set to 0x0. 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.
3.3 PEER_NAME_TABLE_REQUEST message Parameter Value: variable-length.
The Parameter Value field contains the actual information to be
transferred in the parameter.
The total length of a parameter (including Type, Parameter Length and
Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the Parameter
at the end (i.e., after the Parameter Value field) with all zero
bytes. The length of the padding is not included in the parameter
length field. A sender SHOULD NOT pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
The Parameter Types are encoded such that the highest-order two bits
specify the action that must be taken if the processing endpoint does
not recognize the Parameter Type.
00 - Stop processing this 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
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #1 = 0x27047729 | | Type = 0x1 | Length = 8 |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #2 = 0x53829149 | | IPv4 Address |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x102 |
+-------------------------------+-------------------------------+
| sending server's IP address |
+-------------------------------+-------------------------------+
| sender's SCTP port | padding |
+-------------------------------+-------------------------------+
| receiving server's IP address |
+-------------------------------+-------------------------------+
| receiver's SCTP port | padding |
+-------------------------------+-------------------------------+
| Table type = (see below) |
+-------------------------------+-------------------------------+
Note, the receiver's IP address and port do not need to be filled in
if the message is being multicasted.
The requested 'Table type' shall take one of the following values: IPv4 Address: 32 bits (unsigned integer)
0x1 --- HOME_LIST: PEs owned by the receiver server. Contains an IPv4 address of the sending endpoint. It is binary
0x2 --- REMOTE_LIST: PEs NOT owned by the receiver encoded.
server.
3.4 PEER_NAME_TABLE_RESPONSE message 3.1.2 IPv6 Address Parameter
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #1 = 0x27047729 | | Type = 0x2 | Length = 20 |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #2 = 0x53829149 |
+-------------------------------+-------------------------------+
| Type = 0x103 |
+-------------------------------+-------------------------------+
| sender's IP address |
+-------------------------------+-------------------------------+
| sender's SCTP port | padding |
+-------------------------------+-------------------------------+
| receiver's IP address |
+-------------------------------+-------------------------------+
| receiver's SCTP port | padding |
+-------------------------------+-------------------------------+
| Table type = (see below) |
+-------------------------------+-------------------------------+
| More to send = (see below) |
+-------------------------------+-------------------------------+
| number of pool names = n |
+-------------------------------+-------------------------------+
| |
| Pool entry #1 (see below) |
| | | |
+-------------------------------+-------------------------------+ | IPv6 Address |
/ /
\ \
/ /
+-------------------------------+-------------------------------+
| | | |
| Pool entry #n (see below) |
| | | |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field 'Table type' shall take one of the following values: IPv6 Address: 128 bit (unsigned integer)
Contains an IPv6 address of the sending endpoint. It is binary
encoded.
0x1 --- HOME_LIST: PEs owned by the sending ENRP server. 3.1.3 Pool Element Parameter
0x2 --- REMOTE_LIST: PEs NOT owned by the sending ENRP
server.
Field 'More to send' flag shall be set to 0x1 if there are more pool This parameter is used in multiple ENRP message to represent an ASAP
entries to be sent for the requested table type. Otherwise, it shall endpoint (i.e., a PE in a pool) and the associated information, such
be set to 0x0. as its transport address(es), load control, and other operational
status information of the PE.
Each 'Pool entry' represents an existing pool and shall consist of 0 1 2 3
the following: 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.
| Pool handle name (32) |
| |
+-------------------------------+-------------------------------+
| number of PEs = m |
+-------------------------------+-------------------------------+
| |
| PE #1 (40) |
| |
+-------------------------------+-------------------------------+
/ /
\ ..... \
/ /
+-------------------------------+-------------------------------+
| |
| PE #m (40) |
| |
+-------------------------------+-------------------------------+
3.5 PEER_NAME_UPDATE message 3.1.4 Pool Handle Parameter
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #1 = 0x27047729 | | Type = 0x4 | Length=variable |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #2 = 0x53829149 | : :
+-------------------------------+-------------------------------+ : Pool Handle :
| Type = 0x104 | : :
+-------------------------------+-------------------------------+ : :
| sender's IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------------------+-------------------------------+
| sender's SCTP port | padding |
+-------------------------------+-------------------------------+
| receiver's IP address |
+-------------------------------+-------------------------------+
| receiver's SCTP port | padding |
+-------------------------------+-------------------------------+
| |
| Pool handle name (32) |
| |
+-------------------------------+-------------------------------+
| |
| PE entry (40) |
| |
+-------------------------------+-------------------------------+
| Update action (see below) |
+-------------------------------+-------------------------------+
The receiver's IP address and port do not need to be filled in if
the message is being multicasted.
Field 'Update action' shall take one of the following values:
0x0 --- ADD_ENDPOINT: add the PE as a new member to the named pool This parameter holds a pool handle (i.e., a pool name), defined as
in the local copy of the namespace. a NULL terminated ASCII string.
0x1 --- DELETE_ENDPOINT: delete the specified PE from the local copy
of namespace _if_ the receiving server owns the PE.
0x2 --- REMOVE_ENDPOINT: remove the specified PE from the local copy
of namespace, regardless who owns the PE.
0x3 --- UPDATE_ENDPOINT: replace the specified PE's attributes with
the new information carried in this message.
0x4 --- ENDPOINT_FAILURE: warn the receiver that the specified PE
is potentially unreachable.
0x5 --- CLAIM_ENDPOINT: inform the receiver that the sender has
taken the ownership of the specified PE.
3.6 PEER_LIST_REQUEST message 3.1.5 Authorization Parameter
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #1 = 0x27047729 | | Type = 0x5 | Length=variable |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #2 = 0x53829149 | : :
+-------------------------------+-------------------------------+ : Authorization Signature :
| Type = 0x10b | : :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's IP address |
+-------------------------------+-------------------------------+
| sender's SCTP port | padding |
+-------------------------------+-------------------------------+
| receiver's IP address |
+-------------------------------+-------------------------------+
| receiver's SCTP port | padding |
+-------------------------------+-------------------------------+
The receiver's IP address and port do not need to be filled in if
the message is being multicasted.
3.7 PEER_LIST_RESPONSE message 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.
This message shall contain all the peer information of the sending 3.1.6 Name Server Identifier Parameter
server.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #1 = 0x27047729 | | Type = 0x7 | Length=variable |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #2 = 0x53829149 | | Name Server SCTP Port | (reserved) |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x10c | : IPv4 or IPv6 Addr Param :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's IP address |
+-------------------------------+-------------------------------+
| senders SCTP port | padding |
+-------------------------------+-------------------------------+
| receiver's IP address |
+-------------------------------+-------------------------------+
| receiver's SCTP port | padding |
+-------------------------------+-------------------------------+
| responseIndication (see below) |
+-------------------------------+-------------------------------+
| number of peers = n |
+-------------------------------+-------------------------------+
| |
| Peer entry 1 (see below) |
| |
+-------------------------------+-------------------------------+
/ /
\ \
/ /
+-------------------------------+-------------------------------+
| |
| Peer entry n (see below) |
| |
+-------------------------------+-------------------------------+
The 'responseIndication' flag shall be set to 0x2 to indicate a When a name server is multi-homed, any one of its IP addresses can
rejection to the request, and no 'Peer entry' shall be attached if be used in its Server Identifier Parameter. This is because the
the request is rejected. combination of any one of its IP addresses and its SCTP port
number always uniquely identifies the server.
Otherwise, the 'responseIndication' flag shall be set to 0x1 and n 3.2 ENRP Message Formats
'Peer entries' attached.
Each 'Peer entry' shall consist of the following fields: 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
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's IP address | | Message Type | Msg Flags | Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's SCTP port | padding | : :
+-------------------------------+-------------------------------+ : Message Value :
| Caretaker's IP address | : :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| caretaker's SCTP port | padding | Message Type: 8 bits (unsigned integer)
+-------------------------------+-------------------------------+
The peer's IP address and port number serve as the identification of This field identifies the type of information contained in the
that peer. If the peer is inactive, its caretaker's IP address and Message Value field. It takes a value from 0 to 254. The value
port number shall be filled in. Otherwise, the caretaker IP and port of 255 is reserved for future use as an extension field.
fields shall be set to zeros.
3.8 TAKEOVER_INITIATE message 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.
0 1 2 3 00 - Stop processing this message and discard it.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #1 = 0x27047729 |
+-------------------------------+-------------------------------+
| ENRP server message identifier #2 = 0x53829149 |
+-------------------------------+-------------------------------+
| Type = 0x106 |
+-------------------------------+-------------------------------+
| sending server's IP address |
+-------------------------------+-------------------------------+
| sender's SCTP port | padding |
+-------------------------------+-------------------------------+
| receiving server's IP address |
+-------------------------------+-------------------------------+
| receiver's SCTP port | padding |
+-------------------------------+-------------------------------+
| Target server's IP address |
+-------------------------------+-------------------------------+
| Target server's SCTP port | padding |
+-------------------------------+-------------------------------+
The receiving server's address and port do not need to be filled in 01 - Stop processing this message and discard it, and report the
if the message is being multicasted. unrecognized message in an 'Unrecognized Parameter Type'
error.
The 'Target server's IP address and port number MUST be supplied. 10 - reserved.
3.9 TAKEOVER_INITIATE_RESPONSE message 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
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #1 = 0x27047729 | | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #2 = 0x53829149 | : Sender's Server ID param :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x107 | : Receiver's Server ID param (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sending server's IP address | : Authorization Parameter (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's SCTP port | padding |
+-------------------------------+-------------------------------+
| receiving server's IP address |
+-------------------------------+-------------------------------+
| receiver's SCTP port | padding |
+-------------------------------+-------------------------------+
| Target server's IP address |
+-------------------------------+-------------------------------+
| Target server's SCTP port | padding |
+-------------------------------+-------------------------------+
The receiving server's address and port do not need to be filled in The receiving server's ID does not need to be included if the
if the message is being multicasted. message is being multicasted.
The 'Target server's IP address and port number MUST be supplied. "Reply_required" (R) flag shall be set to '1' if response to this
message is required, otherwise set to '0'.
3.10 TAKEOVER_PEER_SERVER message 3.2.2 PEER_NAME_TABLE_REQUEST message
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #1 = 0x27047729 | | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP server message identifier #2 = 0x53829149 | : Sender's Server ID param :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x108 | : Receiver's Server ID param (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sending server's IP address | : Authorization Parameter (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's SCTP port | padding |
+-------------------------------+-------------------------------+
| receiving server's IP address |
+-------------------------------+-------------------------------+
| receiver's SCTP port | padding |
+-------------------------------+-------------------------------+
| Target server's IP address |
+-------------------------------+-------------------------------+
| Target server's SCTP port | padding |
+-------------------------------+-------------------------------+
The receiving server's address and port do not need to be filled in
if the message is being multicasted.
The 'Target server's IP address and port number MUST be supplied. The receiving server's ID does not need to be included if the
message is being multicasted.
3.11 SERVER_DUMP message (Editor's note: we may not support multicast of this message).
This is an ENRP service/maintainance message sent from an ENRP 3.2.3 PEER_NAME_TABLE_RESPONSE message
service console.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x3 |0|0|0|0|0|0|0|M| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : Sender's Server ID param :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x7 | : Receiver's Server ID parameter :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | : :
| Console handle name (32) | : Pool entry #1 (see below) :
| | : :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dump Type (see below) | : :
+-------------------------------+-------------------------------+ : ... :
The 'Dump Type' field shall take one of the following values: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool entry #n (see below) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x0 --- HOME_LIST: dump the list of all the home PEs (i.e., PEs "More_to_send" (M) flag:
owned by the receiving server) from the local copy of the
namespace.
0x1 --- REMOTE_LIST: dump the list of all the remote PEs (i.e., PEs
NOT owned by the receiving server) from the local copy of
the namespace.
0x2 --- PEER_LIST: dump the list of all the peers known to the
receiving server.
3.12 SERVER_DUMP_RESPONSE message 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'.
This is an ENRP service/maintainance message sent to an ENRP service Pool entries:
console as a response to a SERVER_DUMP request.
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
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #1 = 0x18038688 | | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENRP endpoint message identifier #2 = 0x77734683 | : Sender's Server ID param :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x8 | : Receiver's Server ID param (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | : :
| Console handle name (32) | : Pool handle :
| | : :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dump Type (see below) | : :
+-------------------------------+-------------------------------+ : Pool Element :
| Number of Entries = n (see below) | : :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Update action |
| Dump entry 1 (see below) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | : Authorization Parameter (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ \
/ /
+-------------------------------+-------------------------------+
| |
| Dump entry n (see below) |
| |
+-------------------------------+-------------------------------+
The 'Dump Type' fields shall take the same values as defined in The receiving server's ID does not need to be included if the
Section 3.11. message is being multicasted.
When the 'Dump Type' is HOME_LIST or REMOTE_LIST, the 'Number of "Update_action" field:
Entries' field shall be the number of pool entries carried in the
message, and each 'Dump entry' field shall contain a pool entry and shall take one of the following values:
shall be defined as:
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
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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length |
| Pool handle name (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | : Sender's Server ID param :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of PEs in pool = m | : Receiver's Server ID param (optional) :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | : Authorization Parameter (optional) :
| PE #1 (40) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-------------------------------+-------------------------------+
/ /
\ ..... \
/ /
+-------------------------------+-------------------------------+
| |
| PE #m (40) |
| |
+-------------------------------+-------------------------------+
When the 'Dump Type' is PEER_LIST, the 'Number of Entries' field The receiving server's ID does not need to be included if the
shall be the number of peer entries carried in the message, and each message is being multicasted.
'Dump entry' field shall contain a peer entry and shall be defined
as: 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
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's IP address | | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length |
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's SCTP port | padding | : Sender's Server ID param :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Caretaker's IP address | : Receiver's Server ID parameter :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| caretaker's SCTP port | padding | : ID of Peer Server #1 :
+-------------------------------+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ID of Peer Server #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In a peer entry, the peer's IP address and port number serve as the "Reject" (R) flag:
identification of that peer. If the peer is inactive, its
caretaker's IP address and port number shall be filled shall be set to '1' if the sender of this message is rejecting
in. Otherwise, the caretaker IP and port fields shall be zeroed out. a peer list request. In such a case, this message MUST be sent
with no peer server ID included.
4. ENRP Operation Procedures 4. ENRP Operation Procedures
In this section, we discuss the procedures defined by ENRP. The In this section, we discuss the procedures defined by ENRP. The
procedures are divided into three groups, namely the basic ENRP procedures are divided into two groups, namely the basic ENRP
operations, fault management, and control/maintenance procedures. operations and fault management procedures.
Many of the Rserpool events call for message exchanges and other Many of the Rserpool events call for message exchange and other
activities between both a PE and an ENRP server and the ENRP server activities between both a PE and an ENRP server and the ENRP server
and its peers. But only the message exchanges and activities between and its peers. But only the message exchange and activities between
the ENRP server and its peers are considered within the ENRP the ENRP server and its peers are considered within the ENRP
protocol definition scope protocol definition scope
Procedures and message formats for communications between a PE and Procedures and message formats for communications between the PE
ENRP servers are defined in [ASAP]. However, in order to put our and ENRP servers are defined in [ASAP]. However, in order to put
discussion in context, we will give brief description of the ASAP our discussion in context, we will give brief description of the
activities whenever appropreate. ASAP activities whenever appropreate.
4.1 Basic ENRP Operations 4.1 Basic ENRP Operations
4.1.1 PE Registration 4.1.1 PE Registration
ENRP server <-> PE: ENRP server <-> PE:
This action is part of the ASAP protocol and is defined in [ASAP]. 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 To register itself with the name space, a PE sends a REGISTRATION
message over the ENRP client channel to its home ENRP server. message over the ENRP client channel to its home ENRP server.
In the REGISTRATION message, the PE indicates the name of the pool In the REGISTRATION message, the PE indicates the name of the pool
it wishes to join, its network access address(es) (e.g., a list of it wishes to join in a pool handle parameter, and its port number
valid transport addresses with which the PE can be reached), and any and network access address(es) and any load control information in
load control information. a PE parameter.
The ENRP server handles the REGISTRATION message according to the The ENRP server handles the REGISTRATION message according to the
following rules: following rules:
1) If the named pool does not exist in the namespace, the ENRP 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 server will creates a new pool with that name in the namespace and
add the PE to the pool as its first PE; add the PE to the pool as its first PE;
2) If the named pool already exists in the namespace, but the 2) If the named pool already exists in the namespace, but the
requesting PE is not currently a member of the pool, ENRP server requesting PE is not currently a member of the pool, ENRP server
skipping to change at page 15, line 12 skipping to change at page 13, line 4
The ENRP server handles the REGISTRATION message according to the The ENRP server handles the REGISTRATION message according to the
following rules: following rules:
1) If the named pool does not exist in the namespace, the ENRP 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 server will creates a new pool with that name in the namespace and
add the PE to the pool as its first PE; add the PE to the pool as its first PE;
2) If the named pool already exists in the namespace, but the 2) If the named pool already exists in the namespace, but the
requesting PE is not currently a member of the pool, ENRP server requesting PE is not currently a member of the pool, ENRP server
will add the PE as a new member to the pool; will add the PE as a new member to the pool;
3) If the named pool already exists in the namespace AND the 3) If the named pool already exists in the namespace AND the
requesting PE is already a member of the pool, i.e., a case of requesting PE is already a member of the pool, the ENRP server
duplicated registration, the ENRP server will acknowledge the shall consider this as a re-registration case. The ENRP Server
registration request but will not take any further actions; 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 4) The ENRP server may reject the registration due to reasons such
as invalid values, lack of resource, etc. as invalid values, lack of resource, etc.
In cases 1 and 2 above, the ENRP server will also assume the In all cases, the ENRP server will reply to the requesting PE with
ownership of the requesting PE. a REGISTRATION_RESPONSE message, and will indicate in the message
body whether the registration is granted or rejected.
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: ENRP server <-> Its peers:
If the registration request is not a duplicate and is granted, the If the registration request is granted (i.e., cases 1-3 above),
home ENRP server MUST take the namespace modification action as the ENRP server MUST take the namespace modification action as
described in section 4.1.4.1. Otherwise, no message shall be described in section 4.1.5.1?. Otherwise, no message shall be
exchanged with its peers. exchanged with its peers.
4.1.2 PE De-registration 4.1.2 PE De-registration
ENRP server <-> PE: ENRP server <-> PE:
This action is part of the ASAP protocol and is defined in [ASAP]. 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 To remove itself from a pool, a PE sends a DEREGISTRATION message
over the ENRP client channel to its home ENRP server. over the ENRP client channel to its home ENRP server.
skipping to change at page 15, line 55 skipping to change at page 13, line 44
message to the PE and indicates in the message body whether the message to the PE and indicates in the message body whether the
request is granted or rejected. request is granted or rejected.
If the PE is the last one of the named pool, the home ENRP server If the PE is the last one of the named pool, the home ENRP server
will remove the pool from the namespace as well. will remove the pool from the namespace as well.
The ENRP server may reject the de-registration request due to The ENRP server may reject the de-registration request due to
reasons such as invalid parameters, etc. reasons such as invalid parameters, etc.
It should be noted that de-registration does not stop the PE from It should be noted that de-registration does not stop the PE from
sending or receiving messages. sending or receiving application messages.
ENRP server <-> peers: ENRP server <-> peers:
Once the de-registration request is granted and the PE removed from 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 its local copy of the namespace, the home ENRP server MUST take the
namespace modification action described in section 4.1.4.2. namespace modification action described in Section 4.1.5.2.
4.1.3 Name Translation 4.1.3 PE Re-registration
A PE may re-register itself to the namespace with a new set of
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: ENRP server <-> PE or PU:
This action is part of the ASAP protocol and is defined in [ASAP]. 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 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 server to resolve a pool name to a list of accessible transport
addresses of existing PEs. addresses of existing PEs.
This requires the PE or PU to send a NAME_REQUEST messages to its This requires the PE or PU to send a NAME_RESOLUTION messages to its
home ENRP server and in the NAME_REQUEST message specify the pool home ENRP server and in the NAME_RESOLUTION message specify the pool
name to be translated. name to be translated in a Pool Handle parameter.
If the named pool exits in the namespace, the home ENRP server will If the named pool exits in the namespace, the home ENRP server will
send back a NAME_INFORMATION message that shall carry all send back a NAME_RESOLUTION_RESPONSE message that shall carry a
information of the PEs currently registered under that pool list of PE parameters containing all information of the PEs
name. This information may include the current load control policy currently registered under that pool name. This information may
of the pool, policy value of each PE, transport address(es) for each include the current load control policy of the pool, policy value
PE, etc. of each PE, transport address(es) for each PE, etc.
Otherwise, the ENRP server shall respond with a NAME_UNKNOWN Otherwise, the ENRP server shall respond with a NAME_UNKNOWN
message. message.
ENRP server <-> peers: ENRP server <-> peers:
None. None.
4.1.4 Server Namespace Update 4.1.5 Server Namespace Update
This includes a set of update operations used by an ENRP server to This includes a set of update operations used by an ENRP server to
inform its peer(s) the addition of a new PE, removal of an existing inform its peer(s) about the addition of a new PE, removal of an
PE, or change of pool or PE properties, etc. existing PE, or change of pool or PE properties.
4.1.4.1 Add a New PE 4.1.5.1 Add/Update a PE
When a new PE is granted registration to the namespace, the home When a new PE is granted registration to the namespace or an
ENRP server uses this procedure to inform all its peers. 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 An ENRP server shall multicast over the ENRP server channel a
PEER_NAME_UPDATE message with the appropriate flag set to indicate PEER_NAME_UPDATE message with the Update_action field set to
to its peers about the addition of the new PE to the namespace. 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 Upon the reception of this PEER_NAME_UPDATE message, each of the
peer ENRP servers shall take the following actions: peer ENRP servers shall take the following actions:
1) If the named pool under which the new PE has been registered does 1) If the named pool under which the PE has been registered (or
not exist in the peer's local copy of the namespace, the peer ENRP re-registered) does not exist in the peer's local copy of the
server shall create the named pool in its local namespace copy and namespace, the peer ENRP server shall create the named pool in its
add the PE to it as the first PE. It then shall copy in all other local namespace copy and add the PE to it as the first PE. It then
attributes of the PE carried in the message. 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 2) If the named pool already exists in the peer's local copy of the
namespace, the peer shall add the new PE to the pool as a new PE and namespace AND the PE does not exist, the peer shall add the PE to
copy in all attributes of the PE carried in the message. 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 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 pool in its the local copy of the namespace, the peer ENRP server
shall take no actions. shall replace the attributes of the PE with the new information
carried in the message.
4) If the new PE is added to its local copy of namespace (i.e., case
1 or 2 above), the peer ENRP server shall further check whether the
PE is located on the same host as the peer ENRP server itself
does. If so, the peer ENRP server shall assume the ownership of the
PE, and take the claim ownership actions described in section
4.1.4.5.
4.1.4.2 Forceful Removal of a PE 4.1.5.2 Remove a PE
This procedure is used by an ENRP server to inform its peer(s) to This procedure is used by an ENRP server to inform its peer(s) to
remove an existing PE, regardless of the ownership of the PE. remove an existing PE.
The ENRP server shall multicast over the ENRP server channel a
PEER_NAME_UPDATE message with the appropriate flag set to instruct
its peers to forcefully remove the PE from their local copy of the
namespace.
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 regardless whether or not it has ownership on the PE.
4.1.4.3 Advisory Removal of a PE
This operation is used by an ENRP server to instruct its peers to
remove an existing PE on which the peer does not have an ownership.
An ENRP server shall multicast over the ENRP server channel a An ENRP server shall multicast over the ENRP server channel a
PEER_NAME_UPDATE message with the appropriate flag set to instruct PEER_NAME_UPDATE message with the Update_action field set to
its peers to remove the specified PE from its local copy of the DELETE_PE, indicating the removal of an existing PE from the
namespace _if_ the peer does not own the PE. 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, a peer ENRP 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 server shall find and remove the PE from its local copy of the
namespace _if_ it does not own this PE. namespace. If the peer does not find the PE in its local copy of
the namespace, it SHOULD take no action.
4.1.4.4 Update PE Attributes
This operation is used by an ENRP server to inform its peers to
update the attributes of an existing PE.
An ENRP server shall multicast over the ENRP server channel a
PEER_NAME_UPDATE message with the appropriate flag set to instruct
its peers to replace the attributes of an existing PE in its local
copy of the name space.
On the reception of this PEER_NAME_UPDATE message, a peer ENRP
server shall replace the attributes of the existing PE with the new
information carried in the message if the PE exists in its local
copy of the name space. If the specified PE is not found in its
local name space copy, the peer server shall add the PE following
the steps 1) to 2) in Section 4.1.1.
4.1.4.5 Claim Ownership over a PE
This operation is used by an ENRP server to claim the ownership on a
specific PE and to inform its peers about its claim.
ENRP server <-> PE:
This action is part of the ASAP protocol and is defined in [ASAP].
An ENRP server shall send an ASAP ENDPOINT_KEEP_ALIVE message to the
PE. This message will cause the PE to adopt this ENRP server as its
new home ENRP server (see section 4.10.3 in [ASAP]).
ENRP server <-> Its peers:
An ENRP server shall multicast over the ENRP server channel a
PEER_NAME_UPDATE message with the appropriate flag set to inform its
peers that it has taken the ownership of the specified PE.
Upon the reception of this PEER_NAME_UPDATE message, a peer server
shall check whether it is the current owner of the PE. If so, this
peer server shall relinquish its ownership on that PE. Otherwise, no
action is needed.
4.1.4.6 Report PE Communication Failure
This operation is used by an ENRP server to warn its peers that it
has noticed a potentially unreachable PE that the server does not
have ownership on.
An ENRP server shall multicast over the ENRP server channel a
PEER_NAME_UPDATE message with the appropriate flag set to indicate
that the specified PE is potentially unreachable.
On the reception of this message, each peer ENRP server shall check
whether it owns the specified PE. If it does, the peer server shall
increase the <endpoint-report-failures> counter of the specified PE
by 1. If the value of the <endpoint-report-failures> counter has
exceeded the protocol parameter Max-Endpoint-Report-Failures, the
peer server shall remove the PE from its local namespace and take
actions described in Section 4.1.4.3.
If the peer server does not own the specified PE, it shall take no
action.
4.1.5 PE Change Policy Value
A PE can modify its load policy value at any time. 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].
A PE normally sends an UPDATE_POLICY_VALUE ASAP message over the
ENRP client channel to its home ENRP server in order to modify its
policy value. The new policy value is always indicated in the
message.
Upon the reception of this UPDATE_POLICY_VALUE message, the home
ENRP server will replace the policy value of that PE in its local
copy of the namespace with the new value indicated in the message.
ENRP server <-> peers:
If the above update on its local copy of the namespace is
successful, the home ENRP server shall take the Update PE Attributes
actions as described in Section 4.1.4.4.
4.1.6 Server Download Namespace from a Peer Server 4.1.6 Server Download Namespace from a Peer Server
This operation allows an ENRP server to request and receive a copy This operation allows an ENRP server to request and receive a copy
of a portion of the namespace from one of its peer ENRP servers. of the current namespace from one of its peer ENRP servers.
This operation is especially useful for a newly started ENRP server This operation is especially useful for a newly started ENRP server
to initiate its local copy of the namespace, as well as for an to initiate its local copy of the namespace, as well as for an
existing ENRP server to correct namespace inconsistency found during existing ENRP server to correct namespace inconsistency found during
its operation. its operation.
1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message 1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message
directly to one of its peers. In the message, it shall indicate directly to one of its peers.
which portion of the namespace is being requested.
2) Upon the reception of this message, the peer server shall 2) Upon the reception of this message, the peer server shall
initiate a download session in which the requested portion of the initiate a download session in which the namespace shall be sent
namespace shall be sent to the requesting ENRP server in one or more to the requesting ENRP server in one or more
PEER_NAME_TABLE_RESPONSE messages. PEER_NAME_TABLE_RESPONSE messages.
If the sending ENRP server determines that multiple If the sending ENRP server determines that multiple
PEER_NAME_TABLE_RESPONSE messages are needed for the session, it PEER_NAME_TABLE_RESPONSE messages are needed for the session, it
shall set the appropriate flag in each PEER_NAME_TABLE_RESPONSE shall use the M flag in each PEER_NAME_TABLE_RESPONSE message to
message to inform the receiving ENRP server whether or not the data inform the receiving ENRP server whether or not the data
in this message is the last piece of the transfer. in this message is the last piece of the namespace transfer.
3) During the downloading, every time the requesting ENRP server 3) During the downloading, every time the requesting ENRP server
receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer the receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer the
data entries carried in the message into its local namespace data entries carried in the message into its local namespace
database, and then check whether or not the data in this message is 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 last piece being transfered. If more data transfer is indicated,
the requesting ENRP server shall send another the requesting ENRP server shall send another
PEER_NAME_TABLE_REQUEST message to the same peer to request for the PEER_NAME_TABLE_REQUEST message to the same peer to request for the
next piece whenever it is ready. next piece whenever it is ready.
When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE
message into its local namespace database, the requesting ENRP message into its local namespace database, the requesting ENRP
server shall follow the same procedures as described in section server shall handle each PE by the following steps:
2.1.1.4.1 when parsing through the PEs carrying in the message one
by one. 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;
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 4.1.7 Server Monitor Peer Status
An ENRP server shall keep a record on the status of each of its An ENRP server shall keep a record on the status of each of its
known peers. known peers. This record is referred to as the "Peer list" of the
server.
If a message of any type is received from a peer, the ENRP server An interanl variable <Peer-last-heared> is kept for each peer on
shall update that peers status as <active>. If a message of any the peer list and its value updated to the current local time each
type is received from a peer previously unknown, the ENRP server time a message of any type is received from the peer.
shall create a record for the new peer and mark the new peer as
<active>. 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 4.1.8 Server Download Peer List from a Peer Server
This operation allows an ENRP server to request from a peer server a This operation allows an ENRP server to request from a peer server
copy of its internal peer list. This is useful for a new ENRP server a copy of its peer list. This is useful for a new ENRP server to
to initiate its own peer list at startup. initiate its own peer list at startup.
An ENRP server shall send a PEER_LIST_REQUEST message to a peer to An ENRP server shall send a PEER_LIST_REQUEST message to a peer to
request a copy of the peer list. request a copy of the peer list.
Upon the reception of this message, the peer server shall reply with Upon the reception of this message, the peer server shall reply
a PEER_LIST_RESPONSE message and include in the message body a copy with a PEER_LIST_RESPONSE message and include in the message body
of its peer list, consisting of all the ENRP servers known by the a list of server IDs of all known peers.
peer togather with their status.
If the peer itself is in the process of startup, it shall response If the peer itself is in the process of startup and not ready to
with a PEER_LIST_RESPONSE message but set the appropriate flag to provide a good peer list, it shall response with a
indicate that it can not grant the PEER_LIST_REQUEST. In such a PEER_LIST_RESPONSE message but set the R flag in the message to
case, the requesting ENRP server shall select another peer and '1' to indicate that it can not grant the PEER_LIST_REQUEST. In
repeat the peer list request with the new peer at a later time. 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 ENRP Server Initialization 4.1.9 Server Initialization
This section describes the steps a new ENRP server needs to take in This section describes the steps a new ENRP server needs to take in
order to join the other existing ENRP servers for providing the order to join the other existing ENRP servers for providing the
namespace service in the operation scope, or initiating the namespace service in the operation scope, or initiating the
namespace service if this is the first ENRP server starting in the namespace service if this is the first ENRP server starting in the
operation scope. operation scope.
1) At startup, before getting into service, the ENRP server 1) At startup, before getting into service, the ENRP server
(initiating server) shall multicast a PEER_PRESENCE message with (initiating server) shall multicast a PEER_PRESENCE message with
'Reply_required' flag set over the ENRP server channel. This is to 'Reply_required' flag set over the ENRP server channel. This is to
inform any other existing peers in the operation scope about the inform any other existing peers in the operation scope about the
initiating peer's presence. initiating peer's presence.
2) Upon the reception of this message, a peer shall send a 2) Upon the reception of this message, a peer shall send a
PEER_PRESENCE without 'Reply_required' flag back to the initiating PEER_PRESENCE without 'Reply_required' flag back to the initiating
server, in order to help the initiating server to build a peer list. server, in order to help the initiating server to build a peer list.
3) If no response to its PEER_PRESENCE message are received, the 3) If no response to its PEER_PRESENCE message are received after
initiating server shall assume that it is alone in the operation <MAX-TIME-SERVER-HUNT> seconds, the initiating server shall assume
scope and shall mark the initialization process as completed. The that it is alone in the operation scope and shall mark the
initiation server shall skip the remaining steps and start to offer initialization process as completed. The initiation server shall
the namespace services. skip the remaining steps and start to offer the namespace
services.
4) If there are responses to its PEER_PRESENCE message, the 4) If there are responses to its PEER_PRESENCE message, the
initiating server shall then take the actions described in 4.1.8 to 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. request a peer list from one of the peers that have responded.
5) Upon the reception of the PEER_LIST_RESPONSE message from the 5) Upon the reception of the PEER_LIST_RESPONSE message from the
peer, the initiating server shall use the information carried in the peer, the initiating server shall use the information carried in the
message to build a complete peer list, including both active and message to build a complete peer list.
inactive peers in the operation scope.
6) Then, the initiating server shall download the HOME_LIST of the
namespace from each active peer, as described in 4.1.6.
Moreover, the initiating server shall also pick one of the active
peers and request to download the REMOTE_LIST from that peer.
These downloads once done should allow the initiating server to 6) Then, the initiating server shall request to download a copy of
create a complete view of the current namespace. the namespace from one of the peer, as described in 4.1.6.
At this point, the initialization process is completed and the At this point, the initialization process is completed and the
initiating server shall start to provide namespace services. initiating server shall start to provide namespace services.
4.2 Fault Management Operations 4.2 Fault Management Operations
The following operations are used to detect and recover from various The following operations are used to detect and recover from
system faults. various system faults.
4.2.1 Detect and Report Unreachable PE
Two mechanisms exist to detect and report an unreachable PE:
1) Home ENRP server periodic sanity check
An ENRP server shall send, in every <Endpoint-sanity-cycle> seconds,
an ENDPOINT_KEEP_ALIVE message to each of the PE it owns, and shall
keep the number of consecutive failed send attempts in the counter
<Endpoint-sanity-failures> of that PE.
If the value of <Endpoint-sanity-failures> of a PE exceeds the
pre-set threshold Max-endpoint-sanity-failures, the home ENRP
server shall remove the PE from its local copy of the namespace
and take the actions described in section 4.1.4.3 to inform its
peers.
The definition and handling of the ENDPOINT_KEEP_ALIVE message by
the PE are part of ASAP and are described in sections 3.9?? and
4.10.3?? in [ASAP].
2) Failure report by peer PE 4.2.1 Detect and Remove an Unreachable PE
Whenever a PE finds a peer PE unreachable (e.g., via an SCTP Whenever a PE finds a peer PE unreachable (e.g., via an SCTP
SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the
former shall send an ENDPOINT_UNREACHABLE message over the ENRP former shall send an ENDPOINT_UNREACHABLE message over the ENRP
client channel to its home ENRP server. The message shall contain client channel to its home ENRP server. The message shall contain
one of the transport addresses of the unreachable peer PE and have the pool handle and one of the transport addresses of the
the 'Severity' flag set to NORMAL_REPORT in the message. unreachable peer PE in a PE parameter.
The definition and procedure of ENDPOINT_UNREACHABLE message are Note: The definition and procedure of ENDPOINT_UNREACHABLE message
part of ASAP and are described in [ASAP]. are part of ASAP and are described in [ASAP].
Upon the reception of the ENDPOINT_UNREACHABLE message, the home Upon the reception of the ENDPOINT_UNREACHABLE message, the home
ENRP server shall first check whether it owns the unreachable ENRP server shall immediately send an ENDPOINT_KEEP_ALIVE message
PE. If not, the home ENRP server shall take the actions described to the PE that is reported as unreachable. If this
in section 4.1.4.6. ENDPOINT_KEEP_ALIVE fails (i.e., it results in an SCTP
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.
If the home ENRP server does own the unreachable PE, it shall Note: The definition and handling of the ENDPOINT_KEEP_ALIVE
increase an <Endpoint-report-failures> counter of the unreachable message by the PE are part of ASAP and are described in Sections
PE by 1, and if the value of the <Endpoint-report-failures> 3.2.8? and 4.9.3? in [ASAP].
counter exceeds threshold Max-endpoint-report-failures, the server
shall remove the PE from its local copy of the namespace and take
actions described in 4.1.4.3.
4.2.2 ENRP Server Failure Detection by Heartbeat 4.2.2 Server Failure Detection by Heartbeat
An ENRP server shall multicast, in every <Peer-heartbeat-cycle> An ENRP server shall multicast, in every <PEER-HEARTBEAT-CYCLE>
seconds, a PEER_PRESENCE message over the ENRP server channel to seconds, a PEER_PRESENCE message over the ENRP server channel to
inform its peers that it is still operational. In the PEER_PRESENCE inform its peers that it is still operational. In the multicasted
message, the sending ENRP server shall unset the 'Replay_required' PEER_PRESENCE message, the sending ENRP server shall set the
flag to indicate that no response is required. 'Replay_required' flag to '0' indicating that no response is
required.
Occassionally, an ENRP server may also send a point-to-point An ENRP server shall keep track the time when the last message
PEER_PRESENCE message to a specific peer server, with the (multicast or point-to-point) was received from each known peer in
'Replay_required' flag set in the message, indicating that a the internal variable <Peer-last-heared>.
response is required. In such a case, the receiving peer server 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 Home ENRP Server Hunt 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]. 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 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 service request) with its current home ENRP server, a PE or PU shall
initiate the following home server hunt procedure. initiate the following procedure to find a new home server.
In the home server hunt procedure, the PE or PU shall multicast a In the home server hunt procedure, the PE or PU shall multicast a
SERVER_HUNT message over the ENRP client channel, and shall repeat SERVER_HUNT message over the ENRP client channel, and shall repeat
sending this message every <Timeout-server-hunt> seconds until a sending this message every <TIMEOUT-SERVER-HUNT> seconds until a
SERVER_HUNT_RESPONSE message is received from an ENRP SERVER_HUNT_RESPONSE message is received from an ENRP server.
server. Moreover, each time the 'Timeout-server-hunt' timer expires
the criticality should be raised (initially criticality should be
set to LOW_CRITICALITY).
Then the PE or PU shall pick one of the ENRP servers that have 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 responded as its new home ENRP server, and send all its subsequent
the namespace service requests to it. the namespace service requests to this new home server.
Upon the reception of the SERVER_HUNT message, an ENRP server shall Upon the reception of the SERVER_HUNT message, an ENRP server shall
normally reply to the PE with a SERVER_HUNT_RESPONSE message, unless reply to the PE with a SERVER_HUNT_RESPONSE message.
its peer status information indicates that there is a caretaker ENRP
server other than itself for the node where the PE resides, AND the
criticality flag in the SERVER_HUNT message is not HIGH_CRITICALITY.
4.2.4 ENRP Server Detecting and Taking-over Inactive Peer
An ENRP server shall keep track the time when the last message
(multicast or point-to-point) was received from each known peer.
If a peer has not been heard for more than Max-time-last-heard, the
ENRP server shall send a point-to-point PEER_PRESENCE with 'Reply
request' to that peer.
If the send fails or the peer does not reply after
Max-time-no-response seconds, the ENRP server shall initiate the
following server take-over procedures:
1) Initiate Server Take-over Arbitration
The ENRP server (the initiating server) shall initiate a take-over
arbitration on the inactive peer (the target server) by multicasting
a TAKEOVER_INITIATE message over the ENRP server channel. In the
message, the initiating server shall specify the identification of
the target server.
After multicasting the TAKEOVER_INITIATE message, the initiating
server shall wait for a TAKEOVER_INITIATE_RESPONSE message from
each of its active peers.
Upon the reception of this message, other peer servers shall take
the following actions accordingly:
A1) If the peer server finds that itself is the target server
indicated in the TAKEOVER_INITIATE message, it MUST
immediately multicast a PEER_PRESENCE message over the ENRP
server channel in an attempt to stop the take-over process.
A2) If the peer server finds that itself has also initiated a
take-over process on the same target server AND its IP address
is smaller in value than that of the sender of the
TAKEOVER_INITIATE message, the peer server shall abort its own
take-over process and perform A3) below.
A3) Peers other than the target peer and the initiating peer shall
mark the target server as <inactive> and mark the initiating
server as the caretaker of the target server and reply to the
initiating server with a TAKEOVER_INITIATE_RESPONSE message.
A4) Once it has received TAKEOVER_INITIATE_RESPONSE message from
all of its active peers, the initiating server shall consider
it won the arbitration and shall then take the actions in 2)
below so as to complete the take-over.
However, if it receives a PEER_PRESENCE from the target server
at any point of the take-over, the initiating server shall
immediately abort the take-over process and re-mark the target
server as <active>.
2) Take-over the target peer server
The initiating ENRP server shall multicast a TAKEOVER_PEER_SERVER
message over the ENRP server channel in order to inform all its
peers about the take-over.
In the message, identification of the inactive peer server targeted
for the take-over MUST be included.
The initiating server shall mark the target server as <inactive> and
mark itself as the caretaker of the target server in its own peer
list.
Then it shall claim ownership on each of the PEs in its local copy
of the namespace that is originally owned by the target server. The
procedures in x.x.x.x. shall be followed when claiming the ownership
of the PEs.
The server shall finally check whether there are any inactive peers
(other than the current target server) which has designated the
target server as their caretaker. If so, the initiating server shall
perform the above ownership take-over procedure on each one of those
inactive peers as well.
4.2.5 Registration of Remote PEs
When an ENRP server receives a REGISTRATION message from a PE
located on a remote machine, it shall always accept and grant the
registration and assume ownership of the PE.
However, if the ENRP server's peer status information indicates that
the peer on the remote machine is inactive AND a caretaker other
than the ENRP server itself exists for that machine, the ENRP server
shall reject the registration and take no further actions.
If the ENRP server has no record about a peer on that remote node,
it shall grant the registration as above AND then create a peer
record in its local peer list about that node, mark the new peer as
inactive, and initiate a take-over procedure on the new peer, as
described in section 4.2.4.
4.3 Maintenance Operations
The following operations are used by an ENRP maintenance client to
monitor the name space data and perform maintenances on ENRP servers
in an operation scope.
4.3.1 Forceful Removal of a PE
In order to force the removal of PE from the namespace, a
maintenance client shall send an ENDPOINT_UNREACHABLE message to an
existing ENRP server, and in the message shall indicate one of the
transport addresses of the target PE and have the 'Severity' flag
set to FINAL_REPORT.
Upon the reception of this message, the ENRP server shall
immediately remove the target PE from its local copy of the
namespace and take actions described in Section 4.1.4.2 to inform
its peers to do the same.
4.3.2 Dump Home PE List
To require a copy of the information on all the PEs owned by an ENRP
server, a maintenance client shall send a SERVER_DUMP message with
'Dump type' flag set to HOME_LIST to the server.
Upon receiving this message, the ENRP server shall response with a
SERVER_DUMP_RESPONSE message with the 'Dump type' flag set to
HOME_LIST to the maintenance client, and in the message body,
include information on all the PEs the server currently owns.
4.3.3 Dump Remote PE List
To require a copy of the information on all the PEs NOT owned by an
ENRP server, a maintenance client shall send a SERVER_DUMP message
with 'Dump type' flag set to REMOTE_LIST to the server.
Upon receiving this message, the server shall response with a
SERVER_DUMP_RESPONSE message with the 'Dump type' flag set to
REMOTE_LIST to the maintenance client, and in the message body,
include information on all the PEs the server currently does NOT
own.
4.3.4 Dump Peer Server List
To require a copy of the peer list known to a specific ENRP server
(this list most likely will also represent ALL the active and
inactive ENPR servers in the operation scope), a maintenance client
shall send a SERVER_DUMP message with the 'Dump type' flag set to
PEER_SERVER_LIST to the ENRP server.
Upon receiving this message, the server shall response with a
SERVER_DUMP_RESPONSE message with the 'Dump type' flag set to
PEER_SERVER_LIST to the maintenance client, and in the message body,
include information on all the peers that server currently knows.
5. Variables, Time Constants, and Thresholds
The following is a summary of the variables, time values, and 5. Variables and Time Constants
pre-set thresholds used in ASAP and ENRP protocol.
5.1 Variables 5.1 Variables
Endpoint-report-failures --- per registered PE, this keeps the <Peer-last-heared> - the local time that a peer server was last
number of unreachable reports concerning the PE. heard (via receiving either a multicast or
point-to-point message from the peer).
Endpoint-sanity-failures --- per registered PE; this keeps the
number of failed sanity message send attempts concerning the PE.
Peer-server-last-heard --- per peer ENRP server; this is a time
stamp on when the last message was received from this peer server.
5.2 Timer Constants 5.2 Timer Constants
Endpoint-sanity-cycle --- the period for a home ENRP server to start <PEER-HEARTBEAT-CYCLE> - the period for an ENRP server to send out a
a new round of PE sanity check.
Peer-heartbeat-cycle ---the period for an ENRP server to send out a
heartheat message to its known peers. heartheat message to its known peers.
(Default=30 secs.)
5.3 Thresholds <MAX-TIME-LAST-HEARD> - pre-set threshold for how long an ENRP
server will wait before considering a
Max-endpoint-sanity-failures --- pre-set threshold for silent peer server potentially dead.
Endpoint-sanity-failures. (Default=61 secs.)
Max-endpoint-report-failures --- pre-set threshold for <MAX-TIME-NO-RESPONSE> - pre-set threshold for how long a message
Endpoint-report-failures. sender will wait for a response after
sending out a message. (Default=5 secs.)
Max-time-last-heard --- pre-set threshold for <TIMEOUT-SERVER-HUNT> - pre-set threshold for how long a sender
Peer-server-last-heard. will wait before sending another
SERVER_HUNT message out. (Default=5 secs.)
Max-time-no-response --- pre-set threshold for a peer server to 6. Security COnsiderations
answer a PEER_PRESENCE message with reply required.
Timeout-server-hunt --- pre-set threshold for how long a PE will [TBD]
wait for the REGISTRATION_RESPONSE from its home ENRP server.
6. References 7. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol [ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol
(ASAP)", <draft-ietf-rserpool-asap-00.txt>, work in progress. (ASAP)", <draft-ietf-rserpool-asap-00.txt>, work in progress.
skipping to change at page 27, line 47 skipping to change at page 21, line 10
[RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, [RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore,
L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server
Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress. Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress.
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and,
V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October
2000. 2000.
7. Acknowledgements 8. Acknowledgements
The authors wish to thank John Loughney, Lyndon Ong, and The authors wish to thank John Loughney, Lyndon Ong, and Maureen
Maureen Stillman and many others for their invaluable comments. Stillman and many others for their invaluable comments.
8. Authors' Addresses 9. Authors' Addresses
Randall R. Stewart Randall R. Stewart
24 Burning Bush Trail. 24 Burning Bush Trail.
Crystal Lake, IL 60012 Crystal Lake, IL 60012
USA USA
Phone: +1-815-477-2127 Phone: +1-815-477-2127
EMail: rrs@cisco.com EMail: rrs@cisco.com
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Phone: +1-847-632-3028 Phone: +1-847-632-3028
EMail: qxie1@email.mot.com EMail: qxie1@email.mot.com
Expires in six months from June 2001 Expires in six months from Nov. 2001
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/