draft-ietf-rserpool-enrp-02.txt   draft-ietf-rserpool-enrp-03.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
M. Stillman M. Stillman
Nokia Nokia
Expires in six months March 1, 2002 Expires in six months May 2, 2002
Endpoint Name Resolution Protocol (ENRP) Endpoint Name Resolution Protocol (ENRP)
<draft-ietf-rserpool-enrp-02.txt> <draft-ietf-rserpool-enrp-03.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
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
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)
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.
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............................................2 1.2 Definitions...............................................2
2. Conventions................................................3 2. Conventions................................................3
3. Message Definitions........................................4 3. ENRP Message Definitions...................................3
3.1 ENRP Parameter Formats.................................4 3.1 PEER_PRESENCE message.....................................4
3.1.1 IPv4 Address Parameter...........................5 3.2 PEER_NAME_TABLE_REQUEST message...........................5
3.1.2 IPv6 Address Parameter ..........................5 3.3 PEER_NAME_TABLE_RESPONSE message..........................5
3.1.3 Pool Element Parameter...........................6 3.4 PEER_NAME_UPDATE message..................................7
3.1.4 Pool Handle Parameter............................6 3.5 PEER_LIST_REQUEST message.................................7
3.1.5 Authorization Parameter..........................7 3.6 PEER_LIST_RESPONSE message................................8
3.1.6 Name Server Identifier Parameter.................7 4. ENRP Operation Procedures..................................9
3.2 ENRP Message Formats..................................7 4.1 Methods for Communicating amongst ENRP Servers............9
3.2.1 PEER_PRESENCE message...........................8 4.2 ENRP Server Initialization................................10
3.2.2 PEER_NAME_TABLE_REQUEST message.................9 4.2.1 Generate a Server Identifier ...........................11
3.2.3 PEER_NAME_TABLE_RESPONSE message................9 4.2.2 Acquire Peer Server List................................11
3.2.4 PEER_NAME_UPDATE message........................10 4.2.2.1 Find the mentor server................................11
3.2.5 PEER_LIST_REQUEST message.......................11 4.2.2.2 Request complete server list from mentor peer.........12
3.2.6 PEER_LIST_RESPONSE message......................11 4.2.3 Download ENRP Namespace Data from mentor Peer...........13
4. ENRP Operation Procedures..................................12 4.3 Handle PE Registration....................................14
4.1 Basic ENRP Operations..................................12 4.3.1 Rules on PE Re-registration.............................16
4.1.1 PE Registration..................................12 4.4 Handle PE De-registration.................................16
4.1.2 PE De-registration...............................13 4.5 Pool Handle Translation...................................17
4.1.3 PE Re-registration...............................13 4.6 Server Namespace Update...................................17
4.1.4 Name Translation.................................14 4.6.1 Announcing Addition or Update of PE.....................17
4.1.5 Server Namespace Update..........................15 4.6.2 Announcing Removal of PE................................18
4.1.5.1 Add/Update a PE..........................15 4.7 Detecting and Removing Unreachable PE.....................19
4.1.5.2 Remove a PE..............................15 4.8 Helping PE and PU to Discover Home ENRP Server............19
4.1.6 Server Download Namespace from a Peer Server.....16 4.9 Maintaining Peer List and Monitoring Peer Status..........20
4.1.7 Server Monitor Peer Status.......................17 4.9.1 Discovering New Peer....................................20
4.1.8 Server Download Peer List from a Peer Server.....17 4.9.2 Server Sending Heartbeat................................20
4.1.9 Server Initialization............................17 4.9.3 Detecting Peer Server Failure...........................20
4.2 Fault Management Operations............................18 4.10 Namespace Data Auditing and Re-synchronization...........21
4.2.1 Detect and Remove an Unreachable PE..............18 4.10 Reporting Unrecognized Message
4.2.2 Server Failure Detection by Heartbeat............19 or Unrecognized Parameter................................21
4.2.3 PE or PU Discover Home ENRP Server...............19 5. Protocol Variables and Time Constants......................21
5. Variables and Timer Constants..............................20 5.1 Variables.................................................21
5.1 Variables..............................................20 5.2 Timer Constants...........................................21
5.2 Timer Constants........................................20 6. Security Considerations....................................22
6. Security COnsiderations....................................20 7. References.................................................22
7. References.................................................20 7.1 Informative References....................................23
8. Acknowledgements...........................................21 8. Acknowledgements...........................................23
9. Authors' Addresses.........................................21 9. Authors' Addresses.........................................23
1. Introduction 1. Introduction
Endpoint Name Resolution Protocol (ENRP) is designed to work in ENRP is designed to work in conjunction with ASAP [ASAP] to
conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP] accomplish the functionality of Rserpool as defined by its
to accomplish the functionality of the Reliable Server Pooling requirements [RFC3237] and architecture [RSPL-ARCH].
(Rserpool) requirements and architecture as defined in [RSERPOOL1]
and [RSERPOOL2].
Within the operation scope of Rserpool, ENRP defines the procedures Within the operation scope of Rserpool, ENRP defines the procedures
and message formats of a distributed fault-tolerant registry service and message formats of a distributed fault-tolerant registry
for storing, bookkeeping, retrieving, and distributing pool service for storing, bookkeeping, retrieving, and distributing pool
operation and membership information. operation and membership information.
Whenever appropriate, in the rest of this document we will refer to Whenever appropriate, in the rest of this document we will refer to
this Rserpool registry service as ENRP namespace, or simply this Rserpool registry service as ENRP namespace, or simply
namespace. namespace.
1.2 Definitions 1.2 Definitions
This document uses the following terms: This document uses the following terms:
Operation scope: Operation scope:
The part of the network visible to pool users by a specific See [RSPL-ARCH].
instance of the reliable server pooling protocols.
Pool (or server pool): Pool (or server pool):
A collection of servers providing the same application See [RSPL-ARCH].
functionality.
Pool handle (or pool name): Pool handle (or pool name):
A logical pointer to a pool. Each server pool will be See [RSPL-ARCH].
identifiable in the operation scope of the system by a unique
pool handle or "name".
ENRP namespace (or namespace):
A cohesive structure of pool names and relations that may be
queried by an internal or external agent.
Pool element (PE): Pool element (PE):
A server entity that runs ASAP and has registered to a pool. See [RSPL-ARCH].
Pool user (PU): Pool user (PU):
A server pool user that runs ASAP. Note, a PU can also be a See [RSPL-ARCH].
PE if it has registered itself to a pool.
Pool element handle:
See [RSPL-ARCH].
ENRP namespace (or namespace):
See [RSPL-ARCH].
ENRP namespace server (or ENRP server): ENRP namespace server (or ENRP server):
Entity which runs ENRP and is responsible for managing and See [RSPL-ARCH].
maintaining the namespace within the operation scope.
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
ENRP namespace service. The ENRP client channel is usually namespace service. The ENRP client channel is usually defined
defined by the transport address of the home ENRP server and by the transport address of the home ENRP server and a well
a well known port number. 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
can send multicast messages to other servers through this send multicast messages to other servers through this
channel. PEs are also allowed to multicast on this channel channel. PEs are also allowed to multicast on this channel
occasionally. occasionally.
Network Byte Order:
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 Definitions 3. ENRP Message Definitions
All messages as well as their fields described below shall be in In this section, we defines the format of all ENRP messages. These
Network Byte Order during transmission. For fields with a length are messages sent and received amongst ENRP servers in an operation
bigger than 4 octets, a number in a pair of parentheses may follow scope. Messages sent and received between a PE/PU and an ENRP
the filed name to indicate the length of the field in number of server are part of ASAP and are defined in [ASAP]. A common format,
octets. defined in [RSPL-PARAM], is used for all ENRP and ASAP messages.
3.1 ENRP Parameter Formats Most ENRP messages contains a combination of fixed fields and TLV
parameters. The TLV parameters are also defined in [PARAMS].
ENRP parameters are defined in a Type-length-value (TLV) format as All messages, as well as their fields/parameters described below,
shown below. MUST be transmitted in network byte order (a.k.a. Big Endian, i.e.,
the most significant byte first).
For ENRP, the following message types are defined:
Type Message Name
----- -------------------------
0x0 - (reserved by IETF)
0x1 - PEER_PRESENCE
0x2 - PEER_NAME_TABLE_REQUEST
0x3 - PEER_NAME_TABLE_RESPONSE
0x4 - PEER_NAME_UPDATE
0x5 - PEER_LIST_REQUEST
0x6 - PEER_LIST_RESPONSE
0x7-0x11 - ASAP messages, defined in [ASAP].
0x12-0xFF - (reserved by IETF)
3.1 PEER_PRESENCE message
This ENRP message is used to announce (periodically) the presence
of an ENRP server, or to probe the status of a peer ENRP sever.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type | Parameter Length | | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : | Sender Server's ID |
: Parameter Value : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 16 bits (unsigned integer) R (reply_required) flag: 1 bit
The Type field is a 16 bit identifier of the type of parameter.
It takes a value of 0 to 65534.
The value of 65535 is reserved for IETF-defined extensions. Values
other than those defined in specific SCTP chunk description are
reserved for use by IETF.
Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Type, Parameter Length, and
Parameter Value fields. Thus, a parameter with a zero-length
Parameter Value field would have a Length field of 4. The
Parameter Length does not include any padding bytes.
Parameter Value: variable-length.
The Parameter Value field contains the actual information to be
transferred in the parameter.
The total length of a parameter (including Type, Parameter Length and
Value fields) MUST be a multiple of 4 bytes. If the length of the
parameter is not a multiple of 4 bytes, the sender pads the Parameter
at the end (i.e., after the Parameter Value field) with all zero
bytes. The length of the padding is not included in the parameter
length field. A sender SHOULD NOT pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
The Parameter Types are encoded such that the highest-order two bits Set to '1' if the sender requires a response to this message,
specify the action that must be taken if the processing endpoint does otherwise set to '0'.
not recognize the Parameter Type.
00 - Stop processing this ENRP message and discard it, do not process Sender Server's ID: 32 bit (unsiged integer)
any further parameters within it.
01 - Stop processing this ENRP message and discard it, do not process This is the ID of the ENRP server which sends the message.
any further parameters within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' error.
10 - Skip this parameter and continue processing. Receiver Server's ID: 32 bit (unsiged integer)
11 - Skip this parameter and continue processing but report the This is the ID of the ENRP server to which the message is
unrecognized parameter in an 'Unrecognized Parameter Type' intended. If the message is not intended to an individual
error. server (e.g., the message is multicasted to a group of servers),
this field MUST be set with all 0's.
In the following sections, we define the common parameter formats Note, at startup an ENRP server MUST pick a randomly generated,
used in ENRP. non-zero 32-bit unsigned integer as its ID and MUST use this same
ID for its entire life.
3.1.1 IPv4 Address Parameter 3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 | Length = 8 | | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address: 32 bits (unsigned integer) Sender Server's ID:
Contains an IPv4 address of the sending endpoint. It is binary
encoded.
3.1.2 IPv6 Address Parameter
0 1 2 3 See section 3.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 = 0x2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bit (unsigned integer) Receiver Server's ID:
Contains an IPv6 address of the sending endpoint. It is binary
encoded.
3.1.3 Pool Element Parameter See section 3.1.
This parameter is used in multiple ENRP message to represent an ASAP 3.3 PEER_NAME_TABLE_RESPONSE message
endpoint (i.e., a PE in a pool) and the associated information, such
as its transport address(es), load control, and other operational
status information of the PE.
0 1 2 3 0 1 2 3
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 = 0x3 | Length=variable | | Type = 0x3 |0|0|0|0|0|0|R|M| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Port | Number of IP addrs=k |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP addr param #0 : | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP addr param #1 : | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: ..... : : Pool entry #1 (see below) :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP addr param #k : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... :
| Load Policy Type | Policy Value | : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Life | : :
: Pool entry #n (see below) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the IP address parameters in a PE parameter can be either R (Reject) flag: 1 bit
an IPv4 or IPv6 address parameter.
3.1.4 Pool Handle Parameter MUST be set to '1' if the sender of this message is rejecting
a namespace request. In such a case, this message MUST be sent
with no pool entries included.
0 1 2 3 M (More_to_send) flag: 1 bit
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Handle :
: :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter holds a pool handle (i.e., a pool name), defined as Set to '1' if the sender has more pool entries to sent in
a NULL terminated ASCII string. subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set
to '0'.
3.1.5 Authorization Parameter Message Length: 16 bits (unsigned integer)
0 1 2 3 Indicates the entire length of the message in number of
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 octets.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x5 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Authorization Signature :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is used to hold an authorization signature. The Note, the value in Message Length field will NOT cover any
signature is signed over the entire ASAP message and uses a padding at the end of this message.
preconfigured public/private key pair. The receiver of a message
which includes this parameter can validate the message is
from the sender by comparing the signature to one generated
using the peers public key.
3.1.6 Name Server Identifier Parameter Sender Server's ID:
0 1 2 3 See section 3.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 = 0x7 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name Server SCTP Port | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv4 or IPv6 Addr Param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a name server is multi-homed, any one of its IP addresses can Receiver Server's ID:
be used in its Server Identifier Parameter. This is because the
combination of any one of its IP addresses and its SCTP port
number always uniquely identifies the server.
3.2 ENRP Message Formats See section 3.1.
The figure below illustrates the common format for all ENRP Pool entry #1-#n:
messages. Each message is formatted with a Message
Type field, a message-specific Flag field, a Message Length field, and a If R flag is '0', at least one pool entry SHOULD be present in
Value field. the message. Each pool entry MUST start with a pool handle
parameter as defined in section 3.1.7, followed by one or more
pool element parameters, i.e.:
+---------------------------+
: Pool handle :
+---------------------------+
: PE #1 :
+---------------------------+
: PE #2 :
+---------------------------+
: ... :
+---------------------------+
: PE #n :
+---------------------------+
3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Msg Flags | Message Length | | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : | Update Action | (reserved) |
: Message Value : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Type: 8 bits (unsigned integer)
This field identifies the type of information contained in the Message Length: 16 bits (unsigned integer)
Message Value field. It takes a value from 0 to 254. The value
of 255 is reserved for future use as an extension field.
Message Types are encoded such that the highest-order two bits Indicates the entire length of the message in number of
specify the action that must be taken if the message receiver octets.
does not recognize the Message Type.
00 - Stop processing this message and discard it. Note, the value in Message Length field will NOT cover any
padding at the end of this message.
01 - Stop processing this message and discard it, and report the Update Action: 16 bits (unsigned integer)
unrecognized message in an 'Unrecognized Parameter Type'
error.
10 - reserved. This field indicates what act is requested to the specified
PE. It MUST take one of the following values:
11 - reserved. 0x0 - ADD_PE: add or update the specified PE in the ENRP
namespace
0x1 - DEL_PE: delete the specified PE from the ENRP namespace.
Message Flags: 8 bits Other values are reserved by IETF and MUST not be used.
The usage of these bits depends on the message type as given by Reserved: 16 bits
the Message Type. Unless otherwise specified, they are set to
zero on transmit and are ignored on receipt.
Message Length: 16 bits (unsigned integer) MUST be set to 0's by sender and ignored by the receiver.
This value represents the size of the message in bytes including Sender Server's ID:
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 See section 3.1.
The Message Value field contains the actual information to be Receiver Server's ID:
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 See section 3.1.
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 Pool handle:
0 1 2 3 Specifies to which the PE belongs.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The receiving server's ID does not need to be included if the Pool Element:
message is being multicasted.
"Reply_required" (R) flag shall be set to '1' if response to this Specifies the PE.
message is required, otherwise set to '0'.
3.2.2 PEER_NAME_TABLE_REQUEST message 3.5 PEER_LIST_REQUEST message
This ENRP message is used to request a copy of the current known
ENRP peer server list. This message is normally sent from a newly
started ENRP server to an existing ENRP server as part of the
initialization process of the new 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x2 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID param (optional) : | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) : | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The receiving server's ID does not need to be included if the Sender Server's ID:
message is being multicasted.
(Editor's note: we may not support multicast of this message). See section 3.1.
3.2.3 PEER_NAME_TABLE_RESPONSE message Receiver Server's ID:
See section 3.1.
3.6 PEER_LIST_RESPONSE message
This message is used to respond a PEER_LIST_REQUEST.
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 = 0x3 |0|0|0|0|0|0|0|M| Message Length | | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param : | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID parameter : | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : Server Info Param of Peer #1 :
: Pool entry #1 (see below) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ... : : ... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : Server Info Param of Peer #n :
: Pool entry #n (see below) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"More_to_send" (M) flag: R (Reject) flag: 1 bit
shall be set to '1' if there are more pool entries to be sent MUST be set to '1' if the sender of this message is rejecting a
in subsequent PEER_NAME_TABLE_RESPONSE messages. Otherwise, it peer list request. In such a case, this message MUST be sent
shall be set to '0'. with no peer server ID included.
Pool entries: Message Length: 16 bits (unsigned integer)
At least one pool entry MUST be present in the message. Each Indicates the entire length of the message in number of
pool entry MUST start with a pool handle parameter, followed by octets.
one or more pool element (PE) parameters, i.e.:
+---------------------------+ Sender Server's ID:
: Pool handle :
+---------------------------+
: PE #1 :
+---------------------------+
: PE #2 :
+---------------------------+
: ... :
+---------------------------+
: PE #n :
+---------------------------+
3.2.4 PEER_NAME_UPDATE message See section 3.1.
0 1 2 3 Receiver Server's ID:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool handle :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Pool Element :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The receiving server's ID does not need to be included if the See section 3.1.
message is being multicasted.
"Update_action" field: Server Information Parameter of Peer #1-#n:
shall take one of the following values: Each contains a Server Information Parameter of a peer known to the
sender. The Server Information Parameter is defined in
[RSPL-PARAM].
0x0 - ADD_PE: add the PE as a new member to or update the PE in 4. ENRP Operation Procedures
the named pool in the namespace.
0x1 - DELETE_PE: delete the specified PE from the namespace.
3.2.5 PEER_LIST_REQUEST message In this section, we discuss the operation procedures defined by
ENRP. An ENRP server MUST following these procedures when sending,
receiving, or processing ENRP messages.
0 1 2 3 Many of the Rserpool events call for both server-to-server and
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 PU/PE-to-server message exchanges. Only the message exchanges and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ activities between an ENRP server and its peer(s) are considered
| Type = 0x5 |0|0|0|0|0|0|0|0| Message Length | within the ENRP scope and are defined in this document.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The receiving server's ID does not need to be included if the Procedures for exchanging messages between a PE/PU and ENRP servers
message is being multicasted. are defined in [ASAP].
3.2.6 PEER_LIST_RESPONSE message 4.1 Methods for Communicating amongst ENRP Servers
This message shall contain all the peer information of the sending Within an Rserpool operation scope, ENRP servers need to
communicate with each other in order to exchange information such
as the pool membership changes, namespace data synchronization,
etc.
Two types of communications are used amongst ENRP servers:
- point-to-point message exchange from one ENPR server to a
specific peer server, and
- announcements from one server to all its peer servers in the
operation scope.
Point-to-point communication is always carried out over an SCTP
associaiton between the sending server and the receiving
server. server.
0 1 2 3 Announcements are communicated out with one of the following two
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 approaches:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x6 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sender's Server ID param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Receiver's Server ID parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ID of Peer Server #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ID of Peer Server #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authorization Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Reject" (R) flag: 1) The sending server sends the announcement message to a
well-known RSERPOOL IP multicast channel that its peer
servers subscribe to.
shall be set to '1' if the sender of this message is rejecting Note: Because IP multicast is not reliable, this approach does
a peer list request. In such a case, this message MUST be sent not gaurrantee that all the peers will receive the announcement
with no peer server ID included. message. Moreover, since IP multicast is not secure, this
approach cannot provide any security to the communication.
4. ENRP Operation Procedures 2) The sending server sends multiple copies of the announcement,
one to each of its peer servers, over a set of point-to-point
SCTP associations between the sending server and the peers.
In this section, we discuss the procedures defined by ENRP. The This approach gaurrantees the reliabe receiption of the
procedures are divided into two groups, namely the basic ENRP message. When needed, data security can be achieved by using IP
operations and fault management procedures. security mechanisms such as IPsec [SCTP-IPSEC] or TLS [SCTP-TLS].
Many of the Rserpool events call for message exchange and other In order to maximize inter-operability of ENRP servers, the
activities between both a PE and an ENRP server and the ENRP server following rules MUST be followed:
and its peers. But only the message exchange and activities between
the ENRP server and its peers are considered within the ENRP
protocol definition scope
Procedures and message formats for communications between the PE 1) At the startup time, a new ENRP server SHOULD make a decision
and ENRP servers are defined in [ASAP]. However, in order to put on whether it will enable IP multicast for ENRP announcements.
our discussion in context, we will give brief description of the This decision should be based on factors such as the
ASAP activities whenever appropreate. availability of IP multicast and the security requirements
from the user of Rserpool.
4.1 Basic ENRP Operations 2) If an ENRP server disables multicast, it then:
4.1.1 PE Registration 2a) MUST NOT subscribe to the well-known server multicast
channel, i.e., it only receives peer announcements over
SCTP associations, and
ENRP server <-> PE: 2b) MUST transmit all its out-going announcements over
point-to-point SCTP associations with its peers.
This action is part of the ASAP protocol and is defined in [ASAP]. 3) If an ENRP server enables itself to use multicast, it then:
To register itself with the name space, a PE sends a REGISTRATION 3a) MUST subcribe to the well-known server multicast channel to
message over the ENRP client channel to its home ENRP server. ready itself for receiving peers' multicast announcements,
In the REGISTRATION message, the PE indicates the name of the pool 3b) MUST also be prepared to receive peer announcements over
it wishes to join in a pool handle parameter, and its port number point-to-point SCTP associations from peers.
and network access address(es) and any load control information in
a PE parameter.
The ENRP server handles the REGISTRATION message according to the 3c) MUST track internally which peers are multicast-enabled and
following rules: which are not. Note: A peer is always assumed to be
multicast-disabled until/unless an ENRP message of any type
is received from that peer over the well-known server
multicast channel.
1) If the named pool does not exist in the namespace, the ENRP 3d) when sending out an announcement, MUST send a copy to the
server will creates a new pool with that name in the namespace and well-known server multicast channel AND a copy to each of
add the PE to the pool as its first PE; the peers that are marked as multicast-disabled over a
point-to-point SCTP association.
2) If the named pool already exists in the namespace, but the 4.2 ENRP Server Initialization
requesting PE is not currently a member of the pool, ENRP server
will add the PE as a new member to the pool;
3) If the named pool already exists in the namespace AND the
requesting PE is already a member of the pool, the ENRP server
shall consider this as a re-registration case. The ENRP Server
shall replace the attributes of the existing PE with the
information carried in the received REGISTRATION message.
4) The ENRP server may reject the registration due to reasons such This section describes the steps a new ENRP server needs to take in
as invalid values, lack of resource, etc. order to join the other existing ENRP servers, or to initiate the
namespace service if it is the first ENRP server started in the
operation scope.
In all cases, the ENRP server will reply to the requesting PE with 4.2.1 Generate a Server Identifier
a REGISTRATION_RESPONSE message, and will indicate in the message
body whether the registration is granted or rejected.
ENRP server <-> Its peers: A new ENRP server MUST generate a 32-bit server Id that is as
unique as possible in the operation scope and this server Id MUST
remain unchanged for the lifetime of the server. Normally, a good
32-bit random number will be good enough as the server Id
([RFC1750] provides some information on randomness guidelines).
If the registration request is granted (i.e., cases 1-3 above), 4.2.2 Acquire Peer Server List
the ENRP server MUST take the namespace modification action as
described in section 4.1.5.1?. Otherwise, no message shall be
exchanged with its peers.
4.1.2 PE De-registration At startup, the ENRP server (initiating server) will first attempt
to learn all existing peer ENRP servers in the same operation
scope, or to determine that it is along in the scope.
ENRP server <-> PE: The initiating server uses an existing peer server to bootstrap
itself into service. We call this peer server the mentor server.
This action is part of the ASAP protocol and is defined in [ASAP]. 4.2.2.1 Find the mentor server
To remove itself from a pool, a PE sends a DEREGISTRATION message If the initiating server is told about an existing peer server
over the ENRP client channel to its home ENRP server. through some administrative means (such as DNS query, configuration
database, startup scripts, etc), the initiating server SHOULD then
use this peer server as its mentor server and SHOULD skip the
remaining steps in this subsection.
In response, the home ENRP server sends a REGISTRATION_RESPONSE If multiple existing peer servers are specified, the initiating
message to the PE and indicates in the message body whether the server SHOULD pick one of them as its mentor peer server, keep the
request is granted or rejected. others as its backup menter peers, and skip the remaining steps
in this subsection.
If the PE is the last one of the named pool, the home ENRP server If no existing peer server is specified to the initiating server
will remove the pool from the namespace as well. AND if multicast is available in the operation scope, the following
mentor peer discovery procedures SHOULD be followed:
The ENRP server may reject the de-registration request due to 1) The initiating server SHOULD first join the well-known ENRP
reasons such as invalid parameters, etc. server multicast channel.
It should be noted that de-registration does not stop the PE from 2) Then the initiating server SHOULD send a PEER_PRESENCE message,
sending or receiving application messages. with the 'Reply_required' flag set, over the multicast channel.
Upon the reception of this PEER_PRESENCE message, a peer server
MUST send a PEER_PRESENCE, without the 'Reply_required' flag,
back to the initiating server.
ENRP server <-> peers: 3) When the first response to its original PEER_PRESENCE arrives,
the initiating server SHOULD take the sender of this received
response as its mentor peer server. This completes the discovery
of the mentor peer server.
Once the de-registration request is granted and the PE removed from If responses are also received from other peers (a likely event
its local copy of the namespace, the home ENRP server MUST take the when multiple peers exist in the operation scope at the time the
namespace modification action described in Section 4.1.5.2. new server started), the initiating server SHOULD keep a list of
those responded as its backup mentor peers (see below).
4.1.3 PE Re-registration 4) If no response to its PEER_PRESENCE message are received after
<TIMEOUT-SERVER-HUNT> seconds, the initiating server SHOULD
repeat steps 2) and 3) for up to <MAX-TIME-SERVER-HUNT>
times. After that, if there is still no response, the initiating
server MUST assume that it is alone in the operation scope.
A PE may re-register itself to the namespace with a new set of 5) If the initiating server determined that it is alone in the
attributtes in order to, for example, extend its registration scope, it MUST skip the procedures in Sections 4.2.2.2? to
life, change its load policy value. 4.2.3? and MUST consider its initialization complete and start
offering ENRP services.
However, an existing PE MUST NOT change its access address list Note, if multicast is not available (or not allowed for reasons
via re-registration. Instead, to change its address list a PE such as security concerns) in the operation scope, at least one
shall de-register itself first and then register with the peer server MUST be specified to the initiating server through
namespace as a new PE. administrative means, unless the initiation server is the first
server to start in the operation scope.
A PE can modify its load policy value at any time via Note, if the administratively specified menter peer(s) fails, the
re-registration. Based on the number of PEs in the pool and the initiating server SHOULD use the auto-discover procedure defined in
pool's load distrbution policy, this operation allows the PE to steps 1-5 above.
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: 4.2.2.2 Request complete server list from mentor peer
This action is part of the ASAP protocol and is defined in [ASAP]. Once the initiating server finds its mentor peer server (by either
discovery or administrative means), the initiating server MUST send
a PEER_LIST_REQUEST message to the mentor peer server to request a
copy of the complete server list maintained by the mentor peer (see
Section 4.9? for maintaining server list).
To perform a re-registration, a registered PE shall simply send Upon the reception of this request, the mentor peer server SHOULD
a new REGISTRATION message with a new set of attributes over the reply with a PEER_LIST_RESPONSE message and include in the message
ENRP client channel to its home ENRP server. body all existing ENRP servers known by the mentor peer.
Upon the reception of this REGISTRATION message, the home ENRP Upon the reception of the PEER_LIST_RESPONSE message from the
server shall follow the same procedures described in Section mentor peer, the initiating server MUST use the server
4.1.1. information carried in the message to initialize its own peer
list.
ENRP server <-> peers: However, if the mentor itself is in the process of startup and not
ready to provide a peer server list (for example, the mentor peer
is waiting for a response to its own PEER_LIST_REQUEST to another
server), it MUST rejest the request by the initiating server and
respond with a PEER_LIST_RESPONSE message with the R flag set to
'1', and with no server information included in the response.
If the REGISTRATION message is accepted, the home ENRP server In the case where its PEER_LIST_REQUEST is rejected by the mentor
shall take the action described in Section 4.1.5.1?. Otherwise, no peer, the initiating server SHOULD either wait for a few seconds
message shall be exchanged with its peers. and re-send the PEER_LIST_REQUEST to the mentor server, or if there
is a backup mentor peer available, select another mentor peer
server and send the PEER_LIST_REQUEST to the new mentor server.
4.1.4 Name Translation 4.2.3 Download ENRP Namespace Data from Mentor Peer
ENRP server <-> PE or PU: After a peer list download is completed, the initiating server
MUST request a copy of the current namespace data from its mentor
peer server, by taking the following steps:
This action is part of the ASAP protocol and is defined in [ASAP]. 1) The initiating server MUST first send a PEER_NAME_TABLE_REQUEST
message to the mentor peer.
A PE or PU can use the name translation service provided by the ENRP 2) Upon the reception of this message, the mentor peer MUST start a
server to resolve a pool name to a list of accessible transport download session in which a copy of the current namespace data
addresses of existing PEs. maintained by the mentor peer is sent to the initiating server
in one or more PEER_NAME_TABLE_RESPONSE messages.
This requires the PE or PU to send a NAME_RESOLUTION messages to its If more than one PEER_NAME_TABLE_RESPONSE message are used
home ENRP server and in the NAME_RESOLUTION message specify the pool during the download, the mentor peer MUST use the M flag in each
name to be translated in a Pool Handle parameter. PEER_NAME_TABLE_RESPONSE message to indicate whether this
message is the last one for the download session. In particular,
the mentor peer MUST set the M flag to '1' in the outbound
PEER_NAME_TABLE_RESPONSE if there is more data to be transferred
and MUST keep track of the progress of the current download
session. The mentor peer MUST set the M flag to '0' in the last
PEER_NAME_TABLE_RESPONSE for the download session and close the
download session (i.e., removing any internal record of the
session) after sending out the last message.
If the named pool exits in the namespace, the home ENRP server will 3) During the downloading, every time the initiating server
send back a NAME_RESOLUTION_RESPONSE message that shall carry a receives a PEER_NAME_TABLE_RESPONSE message, it MUST transfer
list of PE parameters containing all information of the PEs the data entries carried in the message into its local namespace
currently registered under that pool name. This information may database, and then check whether or not this message is the last
include the current load control policy of the pool, policy value one for the download session.
of each PE, transport address(es) for each PE, etc.
Otherwise, the ENRP server shall respond with a NAME_UNKNOWN If the M flag is set to '1' in the just processed
message. PEER_NAME_TABLE_RESPONSE message, the initiating server MUST
send another PEER_NAME_TABLE_REQUEST message to the mentor peer
to request for the next PEER_NAME_TABLE_RESPONSE message.
ENRP server <-> peers: 4) When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE
message into its local namespace database, the initiating
server MUST handle each pool entry carried in the message using
the following rules:
None. 4a) If the pool does not exist in the local namespace, the
initiating server MUST creates the pool in the local
namespace and add the PE(s) in the pool entry to the pool.
4.1.5 Server Namespace Update When creating the pool, the initiation server MUST set the
overall member selection policy type of the pool to the
policy type indicated in the first PE.
This includes a set of update operations used by an ENRP server to 4b) If the pool already exists in the local namespace, but the
inform its peer(s) about the addition of a new PE, removal of an PE(s) in the pool entry is not currently a member of the
existing PE, or change of pool or PE properties. pool, the initiating server MUST add the PE(s) to the pool.
4.1.5.1 Add/Update a PE 4c) If the pool already exists in the local namespace AND the
PE(s) in the Pool entry is already a member of the pool, the
initiating server server SHOULD replace the attributes of
the existing PE(s) with the new information.
When a new PE is granted registration to the namespace or an 5) When the last PEER_NAME_TABLE_RESPONSE message is received from
existing PE is granted a re-registration, the home ENRP server the mentor peer and unpacked into the local namespace, the
uses this procedure to inform all its peers. initialization process is completed and the initiating server
SHOULD start to provide ENRP services.
An ENRP server shall multicast over the ENRP server channel a Under certain circumstances, the mentor peer itself may not be able
PEER_NAME_UPDATE message with the Update_action field set to to provide a namespace download to the initiating server. For
ADD_PE, indicating the addition of the new PE or the update of an example, the mentor peer is in the middle of initializing its own
existing PE to the namespace. The PE and the pool its belongs to namespace database, or it has currently too many download sessions
shall be indicated in the message with a PE parameter and a Pool open to other servers.
Handle parameter, respectively (see Section 3.2.4).
Upon the reception of this PEER_NAME_UPDATE message, each of the In such a case, the mentor peer MUST rejest the request by the
peer ENRP servers shall take the following actions: initiating server and respond with a PEER_NAME_TABLE_RESPONSE
message with the R flag set to '1', and with no pool entries
included in the response.
1) If the named pool under which the PE has been registered (or In the case where its PEER_NAME_TABLE_REQUEST is rejected by the
re-registered) does not exist in the peer's local copy of the mentor peer, the initiating server SHOULD either wait for a few
namespace, the peer ENRP server shall create the named pool in its seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor
local namespace copy and add the PE to it as the first PE. It then server, or if there is a backup mentor peer available, select
shall copy in all other attributes of the PE carried in the another mentor peer server and send the PEER_NAME_TABLE_REQUEST to
message. the new mentor server.
2) If the named pool already exists in the peer's local copy of the A started namespace download session may get interrupted for some
namespace AND the PE does not exist, the peer shall add the PE to reason. To cope with this, the initiating server SHOULD start a
the pool as a new PE and copy in all attributes of the PE carried timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST to
in the message. its mentor peer. If this timer expires without receiving a response
from the mentor peer, the initiating server SHOULD abort the
current download session and re-start a new namespace download with
a backup mentor peer, if one is available.
3) If the named pool exists AND the PE is already a member of the Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the
pool in its the local copy of the namespace, the peer ENRP server mentor peer has still more data to send, it SHOULD start a session
shall replace the attributes of the PE with the new information timer. If this timer expires without receiving another request from
carried in the message. the initiating server, the mentor peer SHOULD abort the session,
cleaning out any resource and record of the session.
4.1.5.2 Remove a PE 4.3 Handle PE Registration
This procedure is used by an ENRP server to inform its peer(s) to To register itself with the namespace, a PE sends a REGISTRATION
remove an existing PE. message to its home ENRP server. The format of REGISTRATION message
and rules of sending it are defined in [ASAP].
An ENRP server shall multicast over the ENRP server channel a In the REGISTRATION message, the PE indicates the name of the pool
PEER_NAME_UPDATE message with the Update_action field set to it wishes to join in a pool handle parameter, and its complete
DELETE_PE, indicating the removal of an existing PE from the transport information and any load control information in a PE
namespace. The PE and the pool its belongs to shall be indicated parameter.
in the message with a PE parameter and a Pool Handle parameter,
respectively.
On the reception of this PEER_NAME_UPDATE message, each peer ENRP The ENRP server handles the REGISTRATION message according to the
server shall find and remove the PE from its local copy of the following rules:
namespace. If the peer does not find the PE in its local copy of
the namespace, it SHOULD take no action.
4.1.6 Server Download Namespace from a Peer Server 1) If the named pool does not exist in the namespace, the ENRP
server MUST creates a new pool with that name in the namespace and
add the PE to the pool as its first PE;
This operation allows an ENRP server to request and receive a copy When a new pool is created, the overall member selection policy of
of the current namespace from one of its peer ENRP servers. the pool MUST be set to the policy type indicated by the first PE.
This operation is especially useful for a newly started ENRP server 2) If the named pool already exists in the namespace, but the
to initiate its local copy of the namespace, as well as for an requesting PE is not currently a member of the pool, the ENRP server
existing ENRP server to correct namespace inconsistency found during will add the PE as a new member to the pool;
its operation.
1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message After adding the PE to the pool, the server MUST check if the
directly to one of its peers. policy type indicated by the PE is the same as the overall policy
type of the pool. If different, the ENRP server MUST attempt to
override the PE's policy and make it the same as the overall
policy.
2) Upon the reception of this message, the peer server shall 2a) If no additional policy-related information are required to
initiate a download session in which the namespace shall be sent perform the override (e.g., overriding Least-used with Round-robin
to the requesting ENRP server in one or more does not require additional policy-related information), the ENRP
PEER_NAME_TABLE_RESPONSE messages. server MUST replace the PE's policy type with the overall policy
type.
If the sending ENRP server determines that multiple 2b) If additional policy information is required (e.g.,
PEER_NAME_TABLE_RESPONSE messages are needed for the session, it overriding Round-robin with Least-load will require the knowledge
shall use the M flag in each PEER_NAME_TABLE_RESPONSE message to of the load factor of the PE), the ENRP server MUST reject the
inform the receiving ENRP server whether or not the data regirstration with an error code "Pooling policy inconsistent".
in this message is the last piece of the namespace transfer.
3) During the downloading, every time the requesting ENRP server 3) If the named pool already exists in the namespace AND the
receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer the requesting PE is already a member of the pool, the ENRP server
data entries carried in the message into its local namespace SHOULD consider this as a re-registration case. The ENRP Server
database, and then check whether or not the data in this message is SHOULD replace the attributes of the existing PE with the
the last piece being transfered. If more data transfer is indicated, information carried in the received REGISTRATION message.
the requesting ENRP server shall send another
PEER_NAME_TABLE_REQUEST message to the same peer to request for the
next piece whenever it is ready.
When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 4) The ENRP server may reject the registration due to reasons such
message into its local namespace database, the requesting ENRP as invalid values, lack of resource, authentication failure, etc.
server shall handle each PE by the following steps:
1) If the named pool does not exist in the local namespace, the In all above cases, the ENRP server MUST reply to the requesting PE
ENRP server will creates a new pool with that name in the with a REGISTRATION_RESPONSE message. In the message, the ENRP
namespace and add the PE to the pool as the first PE; server MUST set the Action code to indicate that this is a response
2) If the named pool already exists in the local namespace, but to a PE registration and MUST indicate in the Result code whether
the PE is not currently a member of the pool, ENRP server shall the registration is granted or rejected.
add the PE as a new member to the pool;
3) If the named pool already exists in the local namespace AND If the registration is granted with a polcy override (see Step 2a
the requesting PE is already a member of the pool, the ENRP above), in addition to the Result code, in the
server may skip this PE. REGISTRATION_RESPONSE message the ENRP server SHOULD also send back
the registrant PE the new policy, in a Member Selection Policy
Parameter, so as to inform the PE that a policy override is
performed.
4.1.7 Server Monitor Peer Status If the registration is granted (i.e., one of cases 1-3 above), the
ENRP server MUST take the namespace update action as described in
Section 4.6? to inform its peers about the change just made. If the
registration is denied, no message will be send to its peers.
An ENRP server shall keep a record on the status of each of its 4.3.1 Rules on PE Re-registration
known peers. This record is referred to as the "Peer list" of the
server.
An interanl variable <Peer-last-heared> is kept for each peer on A PE may re-register itself to the namespace with a new set of
the peer list and its value updated to the current local time each attributtes in order to, for example, extend its registration
time a message of any type is received from the peer. life, change its load factor value, etc.
If a message of any type is received from a peer previously A PE may modify its load factor value at any time via
unknown, the ENRP server shall create a record for the new peer re-registration. Based on the number of PEs in the pool and the
and add it to the peer list. pool's overall policy type, 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).
4.1.8 Server Download Peer List from a Peer Server Moreover, when re-registering, the PE MUST NOT change its policy
type. The server MUST reject the re-registration if the PE attempt
to change its policy type. In the rejection, the server SHOULD
attach an error code "Pooling policy inconsistent".
This operation allows an ENRP server to request from a peer server 4.4 Handle PE De-registration
a copy of its peer list. This is useful for a new ENRP server to
initiate its own peer list at startup.
An ENRP server shall send a PEER_LIST_REQUEST message to a peer to To remove itself from a pool, a PE sends a DEREGISTRATION message
request a copy of the peer list. to its home ENRP server. The complete format of DEREGISTRATION
message and rules of sending it are defined in [ASAP].
Upon the reception of this message, the peer server shall reply In the DEREGISTRATION message the PE indicates the name of the
with a PEER_LIST_RESPONSE message and include in the message body pool it belongs to in a pool handle parameter and provides its PE
a list of server IDs of all known peers. identifer.
If the peer itself is in the process of startup and not ready to Upon receiving the message, the ENRP server SHALL remove the PE
provide a good peer list, it shall response with a from its namespace. Moreover, if the PE is the last one of the
PEER_LIST_RESPONSE message but set the R flag in the message to named pool, the ENRP server will remove the pool from the namespace
'1' to indicate that it can not grant the PEER_LIST_REQUEST. In as well.
such a case, the requesting ENRP server shall select another peer
and repeat the peer list request with the new peer at a later
time.
4.1.9 Server Initialization If the ENRP server fails to find any record of the PE in its
namespace, it SHOULD consider the de-registration granted and
completed.
This section describes the steps a new ENRP server needs to take in The ENRP server may reject the de-registration request for various
order to join the other existing ENRP servers for providing the reasons, such as invalid parameters, authentication failure, etc.
namespace service in the operation scope, or initiating the
namespace service if this is the first ENRP server starting in the
operation scope.
1) At startup, before getting into service, the ENRP server In response, the ENRP server MUST send a REGISTRATION_RESPONSE
(initiating server) shall multicast a PEER_PRESENCE message with message to the PE. In the message, the ENRP server MUST set the
'Reply_required' flag set over the ENRP server channel. This is to Action code to indicate that this is a response to a PE
inform any other existing peers in the operation scope about the de-registration, and indicate in the Result code whether the
initiating peer's presence. request is granted or rejected.
2) Upon the reception of this message, a peer shall send a It should be noted that de-registration does not stop the PE from
PEER_PRESENCE without 'Reply_required' flag back to the initiating sending or receiving application messages.
server, in order to help the initiating server to build a peer list.
3) If no response to its PEER_PRESENCE message are received after Once the de-registration request is granted AND the PE removed from
<MAX-TIME-SERVER-HUNT> seconds, the initiating server shall assume its local copy of the namespace, the ENRP server MUST take the
that it is alone in the operation scope and shall mark the namespace update action described in Section 4.6? to inform its
initialization process as completed. The initiation server shall peers about the change just made. Otherwise, NO message SHALL be
skip the remaining steps and start to offer the namespace send to its peers.
services.
4) If there are responses to its PEER_PRESENCE message, the 4.5 Pool Handle Translation
initiating server shall then take the actions described in 4.1.8 to
request a peer list from one of the peers that have responded.
5) Upon the reception of the PEER_LIST_RESPONSE message from the A PE or PU uses the pool handle translation service of an ENRP
peer, the initiating server shall use the information carried in the server to resolve a pool handle to a list of accessible transport
message to build a complete peer list. addresses of the member PEs of the pool.
6) Then, the initiating server shall request to download a copy of This requires the PE or PU to send a NAME_RESOLUTION message to its
the namespace from one of the peer, as described in 4.1.6. home ENRP server and in the NAME_RESOLUTION message specify the
pool handle to be translated in a Pool Handle parameter. Complete
defintion of the NAME_RESOLUTION message and the rules of sending
it are defined in [ASAP].
At this point, the initialization process is completed and the Upon reception of the NAME_RESOLUTION message, the ENRP server MUST
initiating server shall start to provide namespace services. first look up the pool handle in its namespace. If the pool exits,
the home ENRP server MUST compose and send back a
NAME_RESOLUTION_RESPONSE message to the requesting PU or PE.
4.2 Fault Management Operations In the response message, the ENRP server MUST list all the PEs
currently registered in this pool, in a list of PE parameters. The
ENRP server MUST also include a pool member selection policy
parameter to indicate the overall member selection policy for the
pool, if the current pool member selection policy is not
round-robin (if the overall policy is round-Robin, this parameter
MAY be omitted?).
The following operations are used to detect and recover from If the named pool does not exist in the namespace, the ENRP server
various system faults. MUST respond with a NAME_UNKNOWN message.
4.2.1 Detect and Remove an Unreachable PE The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN
messages and the rules of receiving them are defined in [ASAP].
Whenever a PE finds a peer PE unreachable (e.g., via an SCTP 4.6 Server Namespace Update
SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the
former shall send an ENDPOINT_UNREACHABLE message over the ENRP
client channel to its home ENRP server. The message shall contain
the pool handle and one of the transport addresses of the
unreachable peer PE in a PE parameter.
Note: The definition and procedure of ENDPOINT_UNREACHABLE message This includes a set of update operations used by an ENRP server to
are part of ASAP and are described in [ASAP]. inform its peers when its local namespace is modified, e.g.,
addition of a new PE, removal of an existing PE, change of pool
or PE properties.
Upon the reception of the ENDPOINT_UNREACHABLE message, the home 4.6.1 Announcing Addition or Update of PE
ENRP server shall immediately send an ENDPOINT_KEEP_ALIVE message
to the PE that is reported as unreachable. If this
ENDPOINT_KEEP_ALIVE fails (i.e., it results in an SCTP
SEND.FAILURE notification), the ENRP server shall consider the PE
as truly unreachable and shall remove the PE from its local copy
of the namespace and take actions described in 4.1.5.2.
Note: The definition and handling of the ENDPOINT_KEEP_ALIVE When a new PE is granted registration to the namespace or an
message by the PE are part of ASAP and are described in Sections existing PE is granted a re-registration, the home ENRP server
3.2.8? and 4.9.3? in [ASAP]. uses this procedure to inform all its peers.
4.2.2 Server Failure Detection by Heartbeat This is an ENRP announcement and is sent to all the peer of the
home ENRP server. See Section 4.1 on how annoucements are sent.
An ENRP server shall multicast, in every <PEER-HEARTBEAT-CYCLE> An ENRP server MUST announce this update to all its peers in a
seconds, a PEER_PRESENCE message over the ENRP server channel to PEER_NAME_UPDATE message with the Update action field set to
inform its peers that it is still operational. In the multicasted ADD_PE, indicating the addition of a new PE or the modification of
PEER_PRESENCE message, the sending ENRP server shall set the an existing PE. The complete new information of the PE and the pool
'Replay_required' flag to '0' indicating that no response is its belongs to MUST be indicated in the message with a PE parameter
required. and a Pool Handle parameter, respectively.
An ENRP server shall keep track the time when the last message The home ENRP server SHOULD fill in its server Id in the Sender
(multicast or point-to-point) was received from each known peer in Server's ID field and leave the Receiver Server's ID blank (i.e.,
the internal variable <Peer-last-heared>. all 0's).
If a peer has not been heard for more than <MAX-TIME-LAST-HEARD> When a peer receives this PEER_NAME_UPDATE message, it MUST take
seconds, the ENRP server shall send a point-to-point PEER_PRESENCE the following actions:
with 'Reply_request' flag set to '1' to that peer.
If the send fails or the peer does not reply after 1) If the named pool indicated by the pool handle does not exist
<MAX-TIME-NO-RESPONSE> seconds, the ENRP server shall consider in its local copy of the namespace, the peer MUST create the named
the peer server dead and shall remove the peer from its peer list. pool in its local namespace and add the PE to the pool as the first
PE. It MUST then copy in all other attributes of the PE carried
in the message.
When an ENRP server receives a PEER_PRESENCE message with When the new pool is created, the overall member selection policy
'Reply_request' flag set to '1', it MUST immediately respond to of the pool MUST be set to the policy type indicated by the PE.
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 2) If the named pool already exists in the peer's local copy of
the namespace AND the PE does not exist, the peer MUST add the PE
to the pool as a new PE and copy in all attributes of the PE
carried in the message.
This action is part of ASAP protocol and is defined in [ASAP]. 3) If the named pool exists AND the PE is already a member of the
pool, the peer MUST replace the attributes of the PE with the new
information carried in the message.
At its startup, or when it fails to send to (i.e., timed-out on a 4.6.2 Announcing Removal of PE
service request) with its current home ENRP server, a PE or PU shall
initiate the following procedure to find a new home server.
In the home server hunt procedure, the PE or PU shall multicast a When an existing PE is granted de-registration or is removed from
SERVER_HUNT message over the ENRP client channel, and shall repeat its namespace for some other reasons (e.g., purging an unreachable
sending this message every <TIMEOUT-SERVER-HUNT> seconds until a PE), the ENRP server MUST uses this procedure to inform all its
SERVER_HUNT_RESPONSE message is received from an ENRP server. peers about the change just made.
Then the PE or PU shall pick one of the ENRP servers that have This is an ENRP announcement and is sent to all the peer of the
responded as its new home ENRP server, and send all its subsequent home ENRP server. See Section 4.1 on how annoucements are sent.
the namespace service requests to this new home server.
Upon the reception of the SERVER_HUNT message, an ENRP server shall An ENRP server MUST announce the PE removal to all its peers in a
reply to the PE with a SERVER_HUNT_RESPONSE message. PEER_NAME_UPDATE message with the Update action field set to
DEL_PE, indicating the removal of an existing PE. The complete
information of the PE and the pool its belongs to MUST be indicated
in the message with a PE parameter and a Pool Handle parameter,
respectively.
[editor's note: only the pool handle and the PE's id are needed, it
should reduce the size of the message]
The sending server MUST fill in its server ID in the Sender
Server's ID field and leave the Receiver Server's ID blank (i.e.,
set to all 0's).
When a peer receives this PEER_NAME_UPDATE message, it MUST first
find pool and the PE in its own namespace, and then remove the PE
from its local namespace. If the removed PE is the last one in the
pool, the peer MUST also delete the pool from its local namespace.
If the peer fails to find the PE or the pool in its namespace, it
SHOULD take no further actions.
4.7 Detecting and Removing Unreachable PE
Whenever a PU finds a PE unreachable (e.g., via an SCTP
SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the PU
SHOULD send an ENDPOINT_UNREACHABLE message to its home ENRP
server. The message SHOULD contain the pool handle and the PE Id
of the unreachable PE.
Upon the reception of an ENDPOINT_UNREACHABLE message, a server
MUST immediately send a point-to-point ENDPOINT_KEEP_ALIVE message
to the PE in question. If this ENDPOINT_KEEP_ALIVE fails (i.e., it
results in an SCTP SEND.FAILURE notification), the ENRP server MUST
consider the PE as truly unreachable and MUST remove the PE from
its namespace and take actions described in 4.6.2?.
If the ENDPOINT_UNREACHABLE message is transmitted successfully to
the PE, the ENRP server MUST retain the PE in its namespace.
Moreover, the server SHOULD keep a counter to record how
many ENDPOINT_UNREACHABLE messages it has received reporting
reachability problem relating to this PE. If the counter exceeds
the protocol threshold <MAX-BAD-PE-REPORT>, the ENRP server SHOULD
remove the PE from its namespace and take actions described in
Section 4.6.2?.
The complete definition and rules of sending ENDPOINT_UNREACHABLE
and ENDPOINT_KEEP_ALIVE messages are described in [ASAP].
4.8 Helping PE and PU to Discover Home ENRP Server
At its startup time, or whenever its current home ENRP server is
not providing services, a PE or PU will attempt to find a new home
server. The PE or PU will either multicast or send a point-to-point
SERVER_HUNT message to one or more ENRP servers in the operation
scope. For the complete procedure of this, see Section xxxx in
[ASAP].
To support this procedure, whenever a SERVER_HUNT message is
received an ENRP server SHOULD immediately respond to the sending
PE or PU with a SERVER_HUNT_RESPONSE message.
4.9 Maintaining Peer List and Monitoring Peer Status
An ENRP server MUST keep internally a record on the status of each
of its known peers. This record is referred to as the server's
"peer list"
4.9.1 Discovering New Peer
If a message of any type is received from a previously unknown
peer, the ENRP server MUST consider this peer a new peer in the
operation scope and add it to the peer list.
If the message is
received over the well-known server multicast channel, the ENRP
server MUST mark this new peer as multicast-enabled. Otherwise, the
new peer MUST be marked as multicast-disabled (see Section 4.1 for
more details).
[editor's note: should we ask for a peer list from the new peer?
this may help mending two splitted networks.]
[editor's note: we also want to send a reply-required probe to
force the new peer to send us its Server Info Param.. so we can now
it details].
4.9.2 Server Sending Heartbeat
Every <PEER-HEARTBEAT-CYCLE> seconds, an ENRP server MUST announce
its continued presence to all its peer with a PEER_PRESENCE
message. In the PEER_PRESENCE message, the ENRP server MUST set the
'Replay_required' flag to '0', indicating that no response is
required.
The arrival of this periodic PEER_PRESENCE message will cause all
its peers to update their internal variable <Peer-last-heared> for
the sending server (see Section 4.9.3? for more details).
4.9.3 Detecting Peer Server Failure
An ENRP server MUST keep an interanl variable <Peer-last-heared>
for each of its known peers and the value of this variable MUST be
updated to the current local time everytime a message of any type
(point-to-point or announcement) is received from the cooresponding
peer.
If a peer has not been heard for more than <MAX-TIME-LAST-HEARD>
seconds, the ENRP server MUST immediately 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 MUST consider the
peer server dead and remove the peer from its peer list.
4.10 Namespace Data Auditing and Re-synchronization
[TBD]
4.11 Reporting Unrecognized Message or Unrecognized Parameter
[TBD]
5. Variables and Time Constants 5. Variables and Time Constants
5.1 Variables 5.1 Variables
<Peer-last-heared> - the local time that a peer server was last <Peer-last-heared> - the local time that a peer server was last
heard (via receiving either a multicast or heard (via receiving either a multicast or
point-to-point message from the peer). point-to-point message from the peer).
5.2 Timer Constants 5.2 Timer Constants
<PEER-HEARTBEAT-CYCLE> - the period for an ENRP server to send out a <MAX-TIME-SERVER-HUNT> - the maximal number of attempts a sender
heartheat message to its known peers. will make to contact an ENRP server
(Default=3 times).
<TIMEOUT-SERVER-HUNT> - pre-set threshold for how long a sender
will wait for a response from an ENRP
server (Default=5 secends).
<PEER-HEARTBEAT-CYCLE> - the period for an ENRP server to announce a
heartheat message to all its known peers.
(Default=30 secs.) (Default=30 secs.)
<MAX-TIME-LAST-HEARD> - pre-set threshold for how long an ENRP <MAX-TIME-LAST-HEARD> - pre-set threshold for how long an ENRP
server will wait before considering a server will wait before considering a
silent peer server potentially dead. silent peer server potentially dead.
(Default=61 secs.) (Default=61 secs.)
<MAX-TIME-NO-RESPONSE> - pre-set threshold for how long a message <MAX-TIME-NO-RESPONSE> - pre-set threshold for how long a message
sender will wait for a response after sender will wait for a response after
sending out a message. (Default=5 secs.) sending out a message. (Default=5 secs.)
<TIMEOUT-SERVER-HUNT> - pre-set threshold for how long a sender <MAX-BAD-PE-REPORT> - the maximal number of unreachability reports
will wait before sending another on a PE that an ENRP server will allow
SERVER_HUNT message out. (Default=5 secs.) before purging this PE from the namespace.
(Default=3)
6. Security COnsiderations 6. Security Considerations
Due to varying requirements and multiple use cases of Rserpool, we Due to varying requirements and multiple use cases of Rserpool, we
point out two basic security protocols, IPsec and TLS. We point out two basic security protocols, IPsec and TLS. We
specifically do not discuss whether one security protocol would be specifically do not discuss whether one security protocol would be
preferred over the other. This choice will be made by designers preferred over the other. This choice will be made by designers
and network architects based on system requirements. and network architects based on system requirements.
For networks that demand IPsec security, implementations MUST For networks that demand IPsec security, implementations MUST
support [SCTPIPSEC] which describes IPsec-SCTP. IPsec is two support [SCTP-IPSEC] which describes IPsec-SCTP. IPsec is two
layers below RSerPool. Therefore, if IPsec is used for securing layers below RSerPool. Therefore, if IPsec is used for securing
Rserpool, no changes or special considerations need to be made to Rserpool, no changes or special considerations need to be made to
Rserpool to secure the protocol. Rserpool to secure the protocol.
For networks that cannot or do not wish to use IPsec and prefer For networks that cannot or do not wish to use IPsec and prefer
instead TLS, implementations MUST support TLS with SCTP as instead TLS, implementations MUST support TLS with SCTP as
described in [SCTPTLS] or TLS over TCP as described in [RFC2246]. described in [SCTP-TLS] or TLS over TCP as described in [RFC2246].
When using TLS/SCTP we must ensure that RSerPool does not use any When using TLS/SCTP we must ensure that RSerPool does not use any
features of SCTP that are not available to an TLS/SCTP user. This features of SCTP that are not available to an TLS/SCTP user. This
is not a difficult technical problem, but simply a is not a difficult technical problem, but simply a
requirement. When describing an API of the RSerPool lower layer we requirement. When describing an API of the RSerPool lower layer we
have also to take into account the differences between TLS and have also to take into account the differences between TLS and
SCTP. This is also not difficult, but it is in contrast to the SCTP. This is also not difficult, but it is in contrast to the
IPsec solution which is transparently layered below Rserpool. IPsec solution which is transparently layered below Rserpool.
Support for security is required for the ENRP server and the PEs. Support for security is required for the ENRP server and the PEs.
Security support for the Rserpool end user is optional. Note that Security support for the Rserpool end user is optional. Note that
skipping to change at page 20, line 85 skipping to change at page 23, line 8
design. design.
7. 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 [RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0",
(ASAP)", <draft-ietf-rserpool-asap-00.txt>, work in progress. RFC 2246, January 1999.
[RSERPOOL1] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore,
L. Ong, J. Loughney, M. Stillman: "Requirements for Reliable Server
Pooling," <draft-ietf-rserpool-reqts-03.txt>, work in progress.
[RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore,
L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server
Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress.
[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.
[SCTPTLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP", [RFC3237] M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong,
J. Loughney, M. Stillman: "Requirements for Reliable Server
Pooling", RFC 3237, January 2002.
[ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol
(ASAP)", <draft-ietf-rserpool-asap-00.txt>, work in progress.
[RSPL-ARCH] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore,
L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server
Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress.
[SCTP-TLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP",
draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress. draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress.
[SCTPIPSEC] S.M. Bellovin, J. Ioannidis, A.D. Keromytis, [SCTP-IPSEC] S.M. Bellovin, J. Ioannidis, A.D. Keromytis,
R.R. Stewart, "On the Use of SCTP with IPsec", R.R. Stewart, "On the Use of SCTP with IPsec",
draft-ietf-ipsec-sctp-03.txt, work in progress. <draft-ietf-ipsec-sctp-03.txt>, work in progress.
[RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0", [RSPL-PARAM] R. Stewart, Q. Xie: "Aggregate Server Access Protocol
RFC 2246, January 1999. (ASAP) and Endpoint Name Resolution Protocol (ENRP) Common
Parameters Document", <draft-ietf-rserpool-enrp-asap-param-00.txt>,
work in progress.
7.1 Informative References
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
8. Acknowledgements 8. Acknowledgements
The authors wish to thank John Loughney, Lyndon Ong, and many The authors wish to thank John Loughney, Lyndon Ong, and many
others for their invaluable comments. others for their invaluable comments.
9. Authors' Addresses 9. Authors' Addresses
Qiaobing Xie Phone: +1-847-632-3028 Qiaobing Xie Phone: +1-847-632-3028
Motorola, Inc. EMail: qxie1@email.mot.com Motorola, Inc. EMail: qxie1@email.mot.com
skipping to change at page 21, line 44 skipping to change at page 24, line 17
24 Burning Bush Trail. EMail: rrs@cisco.com 24 Burning Bush Trail. EMail: rrs@cisco.com
Crystal Lake, IL 60012 Crystal Lake, IL 60012
USA USA
Maureen Stillman Phone: +1 607 273 0724 62 Maureen Stillman Phone: +1 607 273 0724 62
Nokia EMail: maureen.stillman@nokia.com Nokia EMail: maureen.stillman@nokia.com
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Expires in six months from Mar. 2002 Expires in six months from May 2002
 End of changes. 

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