draft-ietf-rserpool-enrp-03.txt   draft-ietf-rserpool-enrp-04.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
INTERNET-DRAFT Motorola Internet-Draft Motorola
R. R. Stewart Expires: March 4, 2003 R. Stewart
Cisco Systems Cisco
M. Stillman M. Stillman
Nokia Nokia
September 3, 2002
Expires in six months May 2, 2002
Endpoint Name Resolution Protocol (ENRP) Endpoint Name Resolution Protocol (ENRP)
<draft-ietf-rserpool-enrp-03.txt> draft-ietf-rserpool-enrp-04.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 RFC2026.
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at Internet-Drafts are working documents of the Internet Engineering
http://www.ietf.org/ietf/1id-abstracts.txt Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
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) conjunction with the Aggregate Server Access Protocol (ASAP) to
to accomplish the functionality of the Reliable Server Pooling accomplish the functionality of the Reliable Server Pooling
(Rserpool) requirements and architecture. (Rserpool) requirements and architecture. Within the operational
scope of Rserpool, ENRP defines the procedures and message formats of
Within the operational scope of Rserpool, ENRP defines the a distributed, fault-tolerant registry service for storing,
procedures and message formats of a distributed, fault-tolerant bookkeeping, retrieving, and distributing pool operation and
registry service for storing, bookkeeping, retrieving, and membership information.
distributing pool operation and membership information.
Table Of Contents Table of Contents
1. Introduction...............................................2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Definitions...............................................2 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions................................................3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
3. ENRP Message Definitions...................................3 3. ENRP Message Definitions . . . . . . . . . . . . . . . . . 7
3.1 PEER_PRESENCE message.....................................4 3.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 7
3.2 PEER_NAME_TABLE_REQUEST message...........................5 3.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 8
3.3 PEER_NAME_TABLE_RESPONSE message..........................5 3.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 9
3.4 PEER_NAME_UPDATE message..................................7 3.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 11
3.5 PEER_LIST_REQUEST message.................................7 3.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 12
3.6 PEER_LIST_RESPONSE message................................8 3.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13
4. ENRP Operation Procedures..................................9 3.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14
4.1 Methods for Communicating amongst ENRP Servers............9 3.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 15
4.2 ENRP Server Initialization................................10 3.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 16
4.2.1 Generate a Server Identifier ...........................11 3.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . . 16
4.2.2 Acquire Peer Server List................................11 3.11 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 18
4.2.2.1 Find the mentor server................................11 4. ENRP Operation Procedures . . . . . . . . . . . . . . . . 19
4.2.2.2 Request complete server list from mentor peer.........12 4.1 Methods for Communicating amongst ENRP Servers . . . . . . 19
4.2.3 Download ENRP Namespace Data from mentor Peer...........13 4.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 20
4.3 Handle PE Registration....................................14 4.2.1 Generate a Server Identifier . . . . . . . . . . . . . . . 21
4.3.1 Rules on PE Re-registration.............................16 4.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . . . 21
4.4 Handle PE De-registration.................................16 4.2.3 Download ENRP Namespace Data from Mentor Peer . . . . . . 23
4.5 Pool Handle Translation...................................17 4.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 25
4.6 Server Namespace Update...................................17 4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . . . 26
4.6.1 Announcing Addition or Update of PE.....................17 4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 27
4.6.2 Announcing Removal of PE................................18 4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28
4.7 Detecting and Removing Unreachable PE.....................19 4.6 Server Namespace Update . . . . . . . . . . . . . . . . . 28
4.8 Helping PE and PU to Discover Home ENRP Server............19 4.6.1 Announcing Addition or Update of PE . . . . . . . . . . . 29
4.9 Maintaining Peer List and Monitoring Peer Status..........20 4.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . . . 29
4.9.1 Discovering New Peer....................................20 4.7 Detecting and Removing Unreachable PE . . . . . . . . . . 30
4.9.2 Server Sending Heartbeat................................20 4.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 31
4.9.3 Detecting Peer Server Failure...........................20 4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 31
4.10 Namespace Data Auditing and Re-synchronization...........21 4.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . . . 31
4.10 Reporting Unrecognized Message 4.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . . . 32
or Unrecognized Parameter................................21 4.9.3 Detecting Peer Server Failure . . . . . . . . . . . . . . 32
5. Protocol Variables and Time Constants......................21 4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . . 32
5.1 Variables.................................................21 4.10.1 Initiate Server Take-over Arbitration . . . . . . . . . . 32
5.2 Timer Constants...........................................21 4.10.2 Take-over Target Peer Server . . . . . . . . . . . . . . . 33
6. Security Considerations....................................22 4.11 Namespace Data Auditing and Re-synchronization . . . . . . 34
7. References.................................................22 4.11.1 Auditing Prodecures . . . . . . . . . . . . . . . . . . . 34
7.1 Informative References....................................23 4.11.2 Re-synchronization Prodecures . . . . . . . . . . . . . . 34
8. Acknowledgements...........................................23 4.12 Handling Unrecognized Message or Unrecognized Parameter . 35
9. Authors' Addresses.........................................23 5. Variables and Time Constants . . . . . . . . . . . . . . . 36
5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Timer Constants . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 38
Normative References . . . . . . . . . . . . . . . . . . . 39
Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP [ASAP] to ENRP is designed to work in conjunction with ASAP [1] to accomplish
accomplish the functionality of Rserpool as defined by its the functionality of Rserpool as defined by its requirements [2] and
requirements [RFC3237] and architecture [RSPL-ARCH]. architecture [3].
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 and message formats of a distributed fault-tolerant registry service
service for storing, bookkeeping, retrieving, and distributing pool for storing, bookkeeping, retrieving, and distributing pool operation
operation and membership information. 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.1 Definitions
This document uses the following terms: This document uses the following terms:
Operation scope: Operation scope: See [3];
See [RSPL-ARCH].
Pool (or server pool): Pool (or server pool): See [3];
See [RSPL-ARCH].
Pool handle (or pool name): Pool handle (or pool name): See [3];
See [RSPL-ARCH].
Pool element (PE): Pool element (PE): See [3];
See [RSPL-ARCH].
Pool user (PU): Pool user (PU): See [3];
See [RSPL-ARCH].
Pool element handle: Pool element handle: See [3];
See [RSPL-ARCH].
ENRP namespace (or namespace): ENRP namespace (or namespace): See [3];
See [RSPL-ARCH].
ENRP namespace server (or ENRP server): ENRP namespace server (or ENRP server): See [3];
See [RSPL-ARCH].
ENRP client channel: ENRP client channel: The communication channel through which a PE
The communication channel through which a PE requests for ENRP requests for ENRP namespace service. The ENRP client channel is
namespace service. The ENRP client channel is usually defined usually defined by the transport address of the home ENRP server
by the transport address of the home ENRP server and a well and a well known port number;
known port number.
ENRP server channel: ENRP server channel: Defined by a well known multicast IP address and
Defined by a well known multicast IP address and a well 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 channel.
send multicast messages to other servers through this PEs are also allowed to multicast on this channel occasionally;
channel. PEs are also allowed to multicast on this channel
occasionally. Home ENRP server: The ENRP server to which a PE or PU currently
belongs. A PE MUST only have one home ENRP server at any given
time and both the PE and its home ENRP server MUST keep track of
this master/slave relationship between them. A PU SHOULD select
one of the available ENRP servers as its home ENRP server, but the
ENRP server does not need to know, nor does it need to keep track
of this relationship.
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]. [5].
3. ENRP Message Definitions 3. ENRP Message Definitions
In this section, we defines the format of all ENRP messages. These In this section, we defines the format of all ENRP messages. These
are messages sent and received amongst ENRP servers in an operation are messages sent and received amongst ENRP servers in an operation
scope. Messages sent and received between a PE/PU and an ENRP scope. Messages sent and received between a PE/PU and an ENRP server
server are part of ASAP and are defined in [ASAP]. A common format, are part of ASAP and are defined in [1]. A common format, defined in
defined in [RSPL-PARAM], is used for all ENRP and ASAP messages. [10], is used for all ENRP and ASAP messages.
Most ENRP messages contains a combination of fixed fields and TLV Most ENRP messages contains a combination of fixed fields and TLV
parameters. The TLV parameters are also defined in [PARAMS]. parameters. The TLV parameters are also defined in [10].
All messages, as well as their fields/parameters described below, All messages, as well as their fields/parameters described below,
MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., MUST be transmitted in network byte order (a.k.a. Big Endian, i.e.,
the most significant byte first). the most significant byte first).
For ENRP, the following message types are defined: For ENRP, the following message types are defined:
Type Message Name Type Message Name
----- ------------------------- ----- -------------------------
0x0 - (reserved by IETF) 0x0 - (reserved by IETF)
0x1 - PEER_PRESENCE 0x1 - PEER_PRESENCE
0x2 - PEER_NAME_TABLE_REQUEST 0x2 - PEER_NAME_TABLE_REQUEST
0x3 - PEER_NAME_TABLE_RESPONSE 0x3 - PEER_NAME_TABLE_RESPONSE
0x4 - PEER_NAME_UPDATE 0x4 - PEER_NAME_UPDATE
0x5 - PEER_LIST_REQUEST 0x5 - PEER_LIST_REQUEST
0x6 - PEER_LIST_RESPONSE 0x6 - PEER_LIST_RESPONSE
0x7-0x11 - ASAP messages, defined in [ASAP]. 0x7 - PEER_INIT_TAKEOVER
0x12-0xFF - (reserved by IETF) 0x8 - PEER_INIT_TAKEOVER_ACK
0x9 - PEER_TAKEOVER_SERVER
0xa - PEER_OWNERSHIP_CHANGE
0xb - PEER_ERROR
0xc-0xFF - (reserved by IETF)
3.1 PEER_PRESENCE message 3.1 PEER_PRESENCE message
This ENRP message is used to announce (periodically) the presence This ENRP message is used to announce (periodically) the presence of
of an ENRP server, or to probe the status of a peer ENRP sever. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC | | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (reply_required) flag: 1 bit R (reply_required) flag: 1 bit
Set to '1' if the sender requires a response to this message, Set to '1' if the sender requires a response to this message,
otherwise set to '0'. otherwise set to '0'.
Sender Server's ID: 32 bit (unsiged integer) Sender Server's ID: 32 bit (unsiged integer)
This is the ID of the ENRP server which sends the message. This is the ID of the ENRP server which sends the message.
Receiver Server's ID: 32 bit (unsiged integer) Receiver Server's ID: 32 bit (unsiged integer)
This is the ID of the ENRP server to which the message is This is the ID of the ENRP server to which the message is
intended. If the message is not intended to an individual intended. If the message is not intended to an individual
server (e.g., the message is multicasted to a group of servers), server (e.g., the message is multicasted to a group of
this field MUST be set with all 0's. servers), this field MUST be set with all 0's.
Note, at startup an ENRP server MUST pick a randomly generated, Server Information Parameter:
non-zero 32-bit unsigned integer as its ID and MUST use this same
ID for its entire life. If present, contains the server information of the sender of
this message (Server Information Parameter is defined in [10]).
This parameter is optional. However, if this message is sent
in response to a received "reply required" PEER_PRESENCE from a
peer, the sender then MUST include its server information.
Note, at startup an ENRP server MUST pick a randomly generated, non-
zero 32-bit unsigned integer as its ID and MUST use this same ID for
its entire life.
3.2 PEER_NAME_TABLE_REQUEST message 3.2 PEER_NAME_TABLE_REQUEST message
An ENRP server sends this message to one of its peers to request a
copy of the namespace data. This message is normally used during
server initialization or namespace re-synchronization.
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 = 0xC | | Type = 0x2 |0|0|0|0|0|0|0|W| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
W (oWn-children-only) flag: 1 bit
Set to '1' if the sender of this message is only requesting
information about the PEs owned by the message receiver.
Otherwise, set to '0'.
Sender Server's ID: Sender Server's ID:
See section 3.1. See Section 3.1.
Receiver Server's ID: Receiver Server's ID:
See section 3.1. See Section 3.1.
3.3 PEER_NAME_TABLE_RESPONSE message 3.3 PEER_NAME_TABLE_RESPONSE 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 = 0x3 |0|0|0|0|0|0|R|M| Message Length | | Type = 0x3 |0|0|0|0|0|0|R|M| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
skipping to change at page 5, line 55 skipping to change at page 10, line 28
: ... : : ... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Pool entry #n (see below) : : Pool entry #n (see below) :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reject) flag: 1 bit R (Reject) flag: 1 bit
MUST be set to '1' if the sender of this message is rejecting MUST be set to '1' if the sender of this message is rejecting a
a namespace request. In such a case, this message MUST be sent namespace request. In such a case, this message MUST be sent
with no pool entries included. with no pool entries included.
M (More_to_send) flag: 1 bit M (More_to_send) flag: 1 bit
Set to '1' if the sender has more pool entries to sent in Set to '1' if the sender has more pool entries to sent in
subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set to
to '0'. '0'.
Message Length: 16 bits (unsigned integer) Message Length: 16 bits (unsigned integer)
Indicates the entire length of the message in number of Indicates the entire length of the message in number of octets.
octets.
Note, the value in Message Length field will NOT cover any Note, the value in Message Length field will NOT cover any
padding at the end of this message. padding at the end of this message.
Sender Server's ID: Sender Server's ID:
See section 3.1. See Section 3.1.
Receiver Server's ID: Receiver Server's ID:
See section 3.1. See Section 3.1.
Pool entry #1-#n: Pool entry #1-#n:
If R flag is '0', at least one pool entry SHOULD be present in If R flag is '0', at least one pool entry SHOULD be present in
the message. Each pool entry MUST start with a pool handle the message. Each pool entry MUST start with a pool handle
parameter as defined in section 3.1.7, followed by one or more parameter as defined in section 3.1.7, followed by one or more
pool element parameters, i.e.: pool element parameters, i.e.:
+---------------------------+ +---------------------------+
: Pool handle : : Pool handle :
skipping to change at page 7, line 25 skipping to change at page 11, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle : : Pool handle :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element : : Pool Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Length: 16 bits (unsigned integer) Message Length: 16 bits (unsigned integer)
Indicates the entire length of the message in number of Indicates the entire length of the message in number of octets.
octets.
Note, the value in Message Length field will NOT cover any Note, the value in Message Length field will NOT cover any
padding at the end of this message. padding at the end of this message.
Update Action: 16 bits (unsigned integer) Update Action: 16 bits (unsigned integer)
This field indicates what act is requested to the specified This field indicates what act is requested to the specified PE.
PE. It MUST take one of the following values: It MUST take one of the following values:
0x0 - ADD_PE: add or update the specified PE in the ENRP 0x0 - ADD_PE: add or update the specified PE in the ENRP
namespace namespace
0x1 - DEL_PE: delete the specified PE from the ENRP namespace. 0x1 - DEL_PE: delete the specified PE from the ENRP namespace.
Other values are reserved by IETF and MUST not be used. Other values are reserved by IETF and MUST not be used.
Reserved: 16 bits Reserved: 16 bits
MUST be set to 0's by sender and ignored by the receiver. MUST be set to 0's by sender and ignored by the receiver.
Sender Server's ID: Sender Server's ID:
skipping to change at page 7, line 48 skipping to change at page 12, line 23
0x1 - DEL_PE: delete the specified PE from the ENRP namespace. 0x1 - DEL_PE: delete the specified PE from the ENRP namespace.
Other values are reserved by IETF and MUST not be used. Other values are reserved by IETF and MUST not be used.
Reserved: 16 bits Reserved: 16 bits
MUST be set to 0's by sender and ignored by the receiver. MUST be set to 0's by sender and ignored by the receiver.
Sender Server's ID: Sender Server's ID:
See section 3.1. See Section 3.1.
Receiver Server's ID: Receiver Server's ID:
See section 3.1. See Section 3.1.
Pool handle: Pool handle:
Specifies to which the PE belongs. Specifies to which the PE belongs.
Pool Element: Pool Element:
Specifies the PE. Specifies the PE.
3.5 PEER_LIST_REQUEST message 3.5 PEER_LIST_REQUEST message
This ENRP message is used to request a copy of the current known This ENRP message is used to request a copy of the current known ENRP
ENRP peer server list. This message is normally sent from a newly peer server list. This message is normally sent from a newly started
started ENRP server to an existing ENRP server as part of the ENRP server to an existing ENRP server as part of the initialization
initialization process of the new server. 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 = 0x5 |0|0|0|0|0|0|0|0| Message Length = 0xC | | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sender Server's ID:
See section 3.1. See Section 3.1.
Receiver Server's ID: Receiver Server's ID:
See section 3.1. See Section 3.1.
3.6 PEER_LIST_RESPONSE message 3.6 PEER_LIST_RESPONSE message
This message is used to respond a PEER_LIST_REQUEST. 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 = 0x6 |0|0|0|0|0|0|0|R| Message Length | | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 54 skipping to change at page 14, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reject) flag: 1 bit R (Reject) flag: 1 bit
MUST be set to '1' if the sender of this message is rejecting a MUST be set to '1' if the sender of this message is rejecting a
peer list request. In such a case, this message MUST be sent peer list request. In such a case, this message MUST be sent
with no peer server ID included. with no peer server ID included.
Message Length: 16 bits (unsigned integer) Message Length: 16 bits (unsigned integer)
Indicates the entire length of the message in number of Indicates the entire length of the message in number of octets.
octets.
Note, the value in Message Length field will NOT cover any
padding at the end of this message.
Sender Server's ID: Sender Server's ID:
See section 3.1. See Section 3.1.
Receiver Server's ID: Receiver Server's ID:
See section 3.1. See Section 3.1.
Server Information Parameter of Peer #1-#n: Server Information Parameter of Peer #1-#n:
Each contains a Server Information Parameter of a peer known to the Each contains a Server Information Parameter of a peer known to
sender. The Server Information Parameter is defined in the sender. The Server Information Parameter is defined in
[RSPL-PARAM]. [10].
3.7 PEER_INIT_TAKEOVER message
This message is used by an ENRP server (the takeover initiator) to
declare its intention of taking over a specific peer ENRP server.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x7 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID:
See Section 3.1.
Receiver Server's ID:
See Section 3.1.
Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover attempt.
3.8 PEER_INIT_TAKEOVER_ACK message
This message is used to acknowledge the takeover initiator that the
sender of this message received the PEER_INIT_TAKEOVER message and
that it does not object to the takeover.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x8 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID:
See Section 3.1.
Receiver Server's ID:
See Section 3.1.
Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover attempt.
3.9 PEER_TAKEOVER_SERVER message
This message is used by the takeover initiator to declare that a
takeover is underway.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x9 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID:
See Section 3.1.
Receiver Server's ID:
See Section 3.1.
Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover operation.
3.10 PEER_OWNERSHIP_CHANGE message
This message is used by the ENRP server, normally after a successful
takeover, to declare that it is now the new home ENRP server of the
listed PEs in the listed pools.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xa |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #1 of pool #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #k of pool #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle #M :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #1 of pool #M :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #n of pool #M :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID:
See Section 3.1.
Receiver Server's ID:
See Section 3.1.
Pool handles and PE Identifier parameters:
Each listed pool handle is followed by a list of PE Identifier
parameters, indicating that the sender of this message is
taking ownership of the listed PEs in the pool.
3.11 PEER_ERROR message
This message is used by an ENRP server to report an operation error
to one of its peers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xb |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operation Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID:
See Section 3.1.
Receiver Server's ID:
See Section 3.1.
Operation Error Parameter:
This parameter, defined in [10], indicates the type of error(s)
being reported.
4. ENRP Operation Procedures 4. ENRP Operation Procedures
In this section, we discuss the operation procedures defined by In this section, we discuss the operation procedures defined by ENRP.
ENRP. An ENRP server MUST following these procedures when sending, An ENRP server MUST following these procedures when sending,
receiving, or processing ENRP messages. receiving, or processing ENRP messages.
Many of the Rserpool events call for both server-to-server and Many of the Rserpool events call for both server-to-server and PU/PE-
PU/PE-to-server message exchanges. Only the message exchanges and to-server message exchanges. Only the message exchanges and
activities between an ENRP server and its peer(s) are considered activities between an ENRP server and its peer(s) are considered
within the ENRP scope and are defined in this document. within the ENRP scope and are defined in this document.
Procedures for exchanging messages between a PE/PU and ENRP servers Procedures for exchanging messages between a PE/PU and ENRP servers
are defined in [ASAP]. are defined in [1].
4.1 Methods for Communicating amongst ENRP Servers 4.1 Methods for Communicating amongst ENRP Servers
Within an Rserpool operation scope, ENRP servers need to Within an Rserpool operation scope, ENRP servers need to communicate
communicate with each other in order to exchange information such with each other in order to exchange information such as the pool
as the pool membership changes, namespace data synchronization, membership changes, namespace data synchronization, etc.
etc.
Two types of communications are used amongst ENRP servers: Two types of communications are used amongst ENRP servers:
- point-to-point message exchange from one ENPR server to a o point-to-point message exchange from one ENPR server to a specific
specific peer server, and peer server, and
- announcements from one server to all its peer servers in the o announcements from one server to all its peer servers in the
operation scope. operation scope.
Point-to-point communication is always carried out over an SCTP Point-to-point communication is always carried out over an SCTP
associaiton between the sending server and the receiving associaiton between the sending server and the receiving server.
server.
Announcements are communicated out with one of the following two Announcements are communicated out with one of the following two
approaches: approaches:
1) The sending server sends the announcement message to a 1. The sending server sends the announcement message to a well-known
well-known RSERPOOL IP multicast channel that its peer RSERPOOL IP multicast channel that its peer servers subscribe to.
servers subscribe to.
Note: Because IP multicast is not reliable, this approach does Note: Because IP multicast is not reliable, this approach does
not gaurrantee that all the peers will receive the announcement not gaurrantee that all the peers will receive the announcement
message. Moreover, since IP multicast is not secure, this message. Moreover, since IP multicast is not secure, this
approach cannot provide any security to the communication. approach cannot provide any security to the communication.
2) The sending server sends multiple copies of the announcement, 2. The sending server sends multiple copies of the announcement, one
one to each of its peer servers, over a set of point-to-point to each of its peer servers, over a set of point-to-point SCTP
SCTP associations between the sending server and the peers. associations between the sending server and the peers.
This approach gaurrantees the reliabe receiption of the This approach gaurrantees the reliabe receiption of the message.
message. When needed, data security can be achieved by using IP When needed, data security can be achieved by using IP security
security mechanisms such as IPsec [SCTP-IPSEC] or TLS [SCTP-TLS]. mechanisms such as IPsec [9] or TLS [8].
In order to maximize inter-operability of ENRP servers, the In order to maximize inter-operability of ENRP servers, the following
following rules MUST be followed: rules MUST be followed:
1) At the startup time, a new ENRP server SHOULD make a decision 1. At the startup time, a new ENRP server SHOULD make a decision on
on whether it will enable IP multicast for ENRP announcements. whether it will enable IP multicast for ENRP announcements. This
This decision should be based on factors such as the decision should be based on factors such as the availability of
availability of IP multicast and the security requirements IP multicast and the security requirements from the user of
from the user of Rserpool. Rserpool.
2) If an ENRP server disables multicast, it then: 2. If an ENRP server disables multicast, it then:
2a) MUST NOT subscribe to the well-known server multicast A. MUST NOT subscribe to the well-known server multicast
channel, i.e., it only receives peer announcements over channel, i.e., it only receives peer announcements over SCTP
SCTP associations, and associations, and
2b) MUST transmit all its out-going announcements over B. MUST transmit all its out-going announcements over point-to-
point-to-point SCTP associations with its peers. point SCTP associations with its peers.
3) If an ENRP server enables itself to use multicast, it then: 3. If an ENRP server enables itself to use multicast, it then:
3a) MUST subcribe to the well-known server multicast channel to A. MUST subcribe to the well-known server multicast channel to
ready itself for receiving peers' multicast announcements, ready itself for receiving peers' multicast announcements,
3b) MUST also be prepared to receive peer announcements over B. MUST also be prepared to receive peer announcements over
point-to-point SCTP associations from peers. point-to-point SCTP associations from peers.
3c) MUST track internally which peers are multicast-enabled and C. MUST track internally which peers are multicast-enabled and
which are not. Note: A peer is always assumed to be which are not. Note: A peer is always assumed to be
multicast-disabled until/unless an ENRP message of any type multicast-disabled until/unless an ENRP message of any type
is received from that peer over the well-known server is received from that peer over the well-known server
multicast channel. multicast channel.
3d) when sending out an announcement, MUST send a copy to the D. when sending out an announcement, MUST send a copy to the
well-known server multicast channel AND a copy to each of well-known server multicast channel AND a copy to each of the
the peers that are marked as multicast-disabled over a peers that are marked as multicast-disabled over a point-to-
point-to-point SCTP association. point SCTP association.
4.2 ENRP Server Initialization 4.2 ENRP 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, or to initiate the order to join the other existing ENRP servers, or to initiate the
namespace service if it is the first ENRP server started in the namespace service if it is the first ENRP server started in the
operation scope. operation scope.
4.2.1 Generate a Server Identifier 4.2.1 Generate a Server Identifier
A new ENRP server MUST generate a 32-bit server Id that is as A new ENRP server MUST generate a non-zero, 32-bit server Id that is
unique as possible in the operation scope and this server Id MUST as unique as possible in the operation scope and this server Id MUST
remain unchanged for the lifetime of the server. Normally, a good remain unchanged for the lifetime of the server. Normally, a good
32-bit random number will be good enough as the server Id 32-bit random number will be good enough as the server Id ([11]
([RFC1750] provides some information on randomness guidelines). provides some information on randomness guidelines).
4.2.2 Acquire Peer Server List 4.2.2 Acquire Peer Server List
At startup, the ENRP server (initiating server) will first attempt At startup, the ENRP server (initiating server) will first attempt to
to learn all existing peer ENRP servers in the same operation learn all existing peer ENRP servers in the same operation scope, or
scope, or to determine that it is along in the scope. to determine that it is along in the scope.
The initiating server uses an existing peer server to bootstrap The initiating server uses an existing peer server to bootstrap
itself into service. We call this peer server the mentor server. itself into service. We call this peer server the mentor server.
4.2.2.1 Find the mentor server 4.2.2.1 Find the mentor server
If the initiating server is told about an existing peer server If the initiating server is told about an existing peer server
through some administrative means (such as DNS query, configuration through some administrative means (such as DNS query, configuration
database, startup scripts, etc), the initiating server SHOULD then database, startup scripts, etc), the initiating server SHOULD then
use this peer server as its mentor server and SHOULD skip the use this peer server as its mentor server and SHOULD skip the
remaining steps in this subsection. remaining steps in this subsection.
If multiple existing peer servers are specified, the initiating If multiple existing peer servers are specified, the initiating
server SHOULD pick one of them as its mentor peer server, keep the server SHOULD pick one of them as its mentor peer server, keep the
others as its backup menter peers, and skip the remaining steps others as its backup menter peers, and skip the remaining steps in
in this subsection. this subsection.
If no existing peer server is specified to the initiating server If no existing peer server is specified to the initiating server AND
AND if multicast is available in the operation scope, the following if multicast is available in the operation scope, the following
mentor peer discovery procedures SHOULD be followed: mentor peer discovery procedures SHOULD be followed:
1) The initiating server SHOULD first join the well-known ENRP 1. The initiating server SHOULD first join the well-known ENRP
server multicast channel. server multicast channel.
2) Then the initiating server SHOULD send a PEER_PRESENCE message, 2. Then the initiating server SHOULD send a PEER_PRESENCE message,
with the 'Reply_required' flag set, over the multicast channel. with the 'Reply_required' flag set, over the multicast channel.
Upon the reception of this PEER_PRESENCE message, a peer server Upon the reception of this PEER_PRESENCE message, a peer server
MUST send a PEER_PRESENCE, without the 'Reply_required' flag, MUST send a PEER_PRESENCE, without the 'Reply_required' flag,
back to the initiating server. back to the initiating server.
3) When the first response to its original PEER_PRESENCE arrives, 3. When the first response to its original PEER_PRESENCE arrives,
the initiating server SHOULD take the sender of this received the initiating server SHOULD take the sender of this received
response as its mentor peer server. This completes the discovery response as its mentor peer server. This completes the discovery
of the mentor peer server. of the mentor peer server.
If responses are also received from other peers (a likely event If responses are also received from other peers (a likely event
when multiple peers exist in the operation scope at the time the when multiple peers exist in the operation scope at the time the
new server started), the initiating server SHOULD keep a list of new server started), the initiating server SHOULD keep a list of
those responded as its backup mentor peers (see below). those responded as its backup mentor peers (see below).
4) If no response to its PEER_PRESENCE message are received after 4. If no response to its PEER_PRESENCE message are received after
<TIMEOUT-SERVER-HUNT> seconds, the initiating server SHOULD TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat
repeat steps 2) and 3) for up to <MAX-TIME-SERVER-HUNT> steps 2) and 3) for up to MAX-TIME-SERVER-HUNT times. After
times. After that, if there is still no response, the initiating that, if there is still no response, the initiating server MUST
server MUST assume that it is alone in the operation scope. assume that it is alone in the operation scope.
5) If the initiating server determined that it is alone in the 5. If the initiating server determined that it is alone in the
scope, it MUST skip the procedures in Sections 4.2.2.2? to scope, it MUST skip the procedures in Section 4.2.2.2 and Section
4.2.3? and MUST consider its initialization complete and start 4.2.3 and MUST consider its initialization completed and start
offering ENRP services. offering ENRP services.
Note, if multicast is not available (or not allowed for reasons Note, if multicast is not available (or not allowed for reasons such
such as security concerns) in the operation scope, at least one as security concerns) in the operation scope, at least one peer
peer server MUST be specified to the initiating server through server MUST be specified to the initiating server through
administrative means, unless the initiation server is the first administrative means, unless the initiation server is the first
server to start in the operation scope. server to start in the operation scope.
Note, if the administratively specified menter peer(s) fails, the Note, if the administratively specified menter peer(s) fails, the
initiating server SHOULD use the auto-discover procedure defined in initiating server SHOULD use the auto-discover procedure defined in
steps 1-5 above. steps 1-5 above.
4.2.2.2 Request complete server list from mentor peer 4.2.2.2 Request complete server list from mentor peer
Once the initiating server finds its mentor peer server (by either Once the initiating server finds its mentor peer server (by either
discovery or administrative means), the initiating server MUST send discovery or administrative means), the initiating server MUST send a
a PEER_LIST_REQUEST message to the mentor peer server to request a PEER_LIST_REQUEST message to the mentor peer server to request a copy
copy of the complete server list maintained by the mentor peer (see of the complete server list maintained by the mentor peer (see
Section 4.9? for maintaining server list). Section 4.9 for maintaining server list).
Upon the reception of this request, the mentor peer server SHOULD Upon the reception of this request, the mentor peer server SHOULD
reply with a PEER_LIST_RESPONSE message and include in the message reply with a PEER_LIST_RESPONSE message and include in the message
body all existing ENRP servers known by the mentor peer. body all existing ENRP servers known by the mentor peer.
Upon the reception of the PEER_LIST_RESPONSE message from the Upon the reception of the PEER_LIST_RESPONSE message from the mentor
mentor peer, the initiating server MUST use the server peer, the initiating server MUST use the server information carried
information carried in the message to initialize its own peer in the message to initialize its own peer list.
list.
However, if the mentor itself is in the process of startup and not 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 ready to provide a peer server list (for example, the mentor peer is
is waiting for a response to its own PEER_LIST_REQUEST to another waiting for a response to its own PEER_LIST_REQUEST to another
server), it MUST rejest the request by the initiating server and server), it MUST rejest the request by the initiating server and
respond with a PEER_LIST_RESPONSE message with the R flag set to respond with a PEER_LIST_RESPONSE message with the R flag set to '1',
'1', and with no server information included in the response. and with no server information included in the response.
In the case where its PEER_LIST_REQUEST is rejected by the mentor In the case where its PEER_LIST_REQUEST is rejected by the mentor
peer, the initiating server SHOULD either wait for a few seconds peer, the initiating server SHOULD either wait for a few seconds and
and re-send the PEER_LIST_REQUEST to the mentor server, or if there re-send the PEER_LIST_REQUEST to the mentor server, or if there is a
is a backup mentor peer available, select another mentor peer backup mentor peer available, select another mentor peer server and
server and send the PEER_LIST_REQUEST to the new mentor server. send the PEER_LIST_REQUEST to the new mentor server.
4.2.3 Download ENRP Namespace Data from Mentor Peer 4.2.3 Download ENRP Namespace Data from Mentor Peer
After a peer list download is completed, the initiating server After a peer list download is completed, the initiating server MUST
MUST request a copy of the current namespace data from its mentor request a copy of the current namespace data from its mentor peer
peer server, by taking the following steps: server, by taking the following steps:
1) The initiating server MUST first send a PEER_NAME_TABLE_REQUEST 1. The initiating server MUST first send a PEER_NAME_TABLE_REQUEST
message to the mentor peer. message to the mentor peer, with W flag set to '0', indicating
that the entire namespace is requested.
2) Upon the reception of this message, the mentor peer MUST start a 2. Upon the reception of this message, the mentor peer MUST start a
download session in which a copy of the current namespace data download session in which a copy of the current namespace data
maintained by the mentor peer is sent to the initiating server maintained by the mentor peer is sent to the initiating server in
in one or more PEER_NAME_TABLE_RESPONSE messages. one or more PEER_NAME_TABLE_RESPONSE messages.
If more than one PEER_NAME_TABLE_RESPONSE message are used If more than one PEER_NAME_TABLE_RESPONSE message are used during
during the download, the mentor peer MUST use the M flag in each the download, the mentor peer MUST use the M flag in each
PEER_NAME_TABLE_RESPONSE message to indicate whether this PEER_NAME_TABLE_RESPONSE message to indicate whether this message
message is the last one for the download session. In particular, is the last one for the download session. In particular, the
the mentor peer MUST set the M flag to '1' in the outbound mentor peer MUST set the M flag to '1' in the outbound
PEER_NAME_TABLE_RESPONSE if there is more data to be transferred PEER_NAME_TABLE_RESPONSE if there is more data to be transferred
and MUST keep track of the progress of the current download 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 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 PEER_NAME_TABLE_RESPONSE for the download session and close the
download session (i.e., removing any internal record of the download session (i.e., removing any internal record of the
session) after sending out the last message. session) after sending out the last message.
3) During the downloading, every time the initiating server 3. During the downloading, every time the initiating server receives
receives a PEER_NAME_TABLE_RESPONSE message, it MUST transfer a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data
the data entries carried in the message into its local namespace entries carried in the message into its local namespace database,
database, and then check whether or not this message is the last and then check whether or not this message is the last one for
one for the download session. the download session.
If the M flag is set to '1' in the just processed If the M flag is set to '1' in the just processed
PEER_NAME_TABLE_RESPONSE message, the initiating server MUST PEER_NAME_TABLE_RESPONSE message, the initiating server MUST send
send another PEER_NAME_TABLE_REQUEST message to the mentor peer another PEER_NAME_TABLE_REQUEST message to the mentor peer to
to request for the next PEER_NAME_TABLE_RESPONSE message. request for the next PEER_NAME_TABLE_RESPONSE message.
4) When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 4. When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE
message into its local namespace database, the initiating message into its local namespace database, the initiating server
server MUST handle each pool entry carried in the message using MUST handle each pool entry carried in the message using the
the following rules: following rules:
4a) If the pool does not exist in the local namespace, the A. If the pool does not exist in the local namespace, the
initiating server MUST creates the pool in the local initiating server MUST creates the pool in the local
namespace and add the PE(s) in the pool entry to the pool. namespace and add the PE(s) in the pool entry to the pool.
When creating the pool, the initiation server MUST set the When creating the pool, the initiation server MUST set the
overall member selection policy type of the pool to the overall member selection policy type of the pool to the
policy type indicated in the first PE. policy type indicated in the first PE.
4b) If the pool already exists in the local namespace, but the B. If the pool already exists in the local namespace, but the
PE(s) in the pool entry is not currently a member of the PE(s) in the pool entry is not currently a member of the
pool, the initiating server MUST add the PE(s) to the pool. pool, the initiating server MUST add the PE(s) to the pool.
4c) If the pool already exists in the local namespace AND the C. 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 PE(s) in the Pool entry is already a member of the pool, the
initiating server server SHOULD replace the attributes of initiating server server SHOULD replace the attributes of the
the existing PE(s) with the new information. existing PE(s) with the new information.
5) When the last PEER_NAME_TABLE_RESPONSE message is received from 5. When the last PEER_NAME_TABLE_RESPONSE message is received from
the mentor peer and unpacked into the local namespace, the the mentor peer and unpacked into the local namespace, the
initialization process is completed and the initiating server initialization process is completed and the initiating server
SHOULD start to provide ENRP services. SHOULD start to provide ENRP services.
Under certain circumstances, the mentor peer itself may not be able Under certain circumstances, the mentor peer itself may not be able
to provide a namespace download to the initiating server. For to provide a namespace download to the initiating server. For
example, the mentor peer is in the middle of initializing its own example, the mentor peer is in the middle of initializing its own
namespace database, or it has currently too many download sessions namespace database, or it has currently too many download sessions
open to other servers. open to other servers.
In such a case, the mentor peer MUST rejest the request by the In such a case, the mentor peer MUST rejest the request by the
initiating server and respond with a PEER_NAME_TABLE_RESPONSE initiating server and respond with a PEER_NAME_TABLE_RESPONSE message
message with the R flag set to '1', and with no pool entries with the R flag set to '1', and with no pool entries included in the
included in the response. response.
In the case where its PEER_NAME_TABLE_REQUEST is rejected by the In the case where its PEER_NAME_TABLE_REQUEST is rejected by the
mentor peer, the initiating server SHOULD either wait for a few mentor peer, the initiating server SHOULD either wait for a few
seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server,
server, or if there is a backup mentor peer available, select or if there is a backup mentor peer available, select another mentor
another mentor peer server and send the PEER_NAME_TABLE_REQUEST to peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor
the new mentor server. server.
A started namespace download session may get interrupted for some A started namespace download session may get interrupted for some
reason. To cope with this, the initiating server SHOULD start a reason. To cope with this, the initiating server SHOULD start a
timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST to timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST to its
its mentor peer. If this timer expires without receiving a response mentor peer. If this timer expires without receiving a response from
from the mentor peer, the initiating server SHOULD abort the the mentor peer, the initiating server SHOULD abort the current
current download session and re-start a new namespace download with download session and re-start a new namespace download with a backup
a backup mentor peer, if one is available. mentor peer, if one is available.
Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the
mentor peer has still more data to send, it SHOULD start a session mentor peer has still more data to send, it SHOULD start a session
timer. If this timer expires without receiving another request from timer. If this timer expires without receiving another request from
the initiating server, the mentor peer SHOULD abort the session, the initiating server, the mentor peer SHOULD abort the session,
cleaning out any resource and record of the session. cleaning out any resource and record of the session.
4.3 Handle PE Registration 4.3 Handle PE Registration
To register itself with the namespace, a PE sends a REGISTRATION To register itself with the namespace, a PE sends a REGISTRATION
message to its home ENRP server. The format of REGISTRATION message message to its home ENRP server. The format of REGISTRATION message
and rules of sending it are defined in [ASAP]. and rules of sending it are defined in [1].
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
it wishes to join in a pool handle parameter, and its complete wishes to join in a pool handle parameter, and its complete transport
transport information and any load control information in a PE information and any load control information in a PE parameter.
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 MUST creates a new pool with that name in the namespace and server MUST creates a new pool with that name in the namespace
add the PE to the pool as its first PE; and add the PE to the pool as its first PE;
When a new pool is created, the overall member selection policy of When a new pool is created, the overall member selection policy
the pool MUST be set to the policy type indicated by the first PE. of the pool MUST be set to the policy type indicated by the 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, the ENRP server requesting PE is not currently a member of the pool, the ENRP
will add the PE as a new member to the pool; server will add the PE as a new member to the pool;
After adding the PE to the pool, the server MUST check if the After adding the PE to the pool, the server MUST check if the
policy type indicated by the PE is the same as the overall policy 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 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 override the PE's policy and make it the same as the overall
policy. policy.
2a) If no additional policy-related information are required to A. If no additional policy-related information are required to
perform the override (e.g., overriding Least-used with Round-robin perform the override (e.g., overriding Least-used with Round-
does not require additional policy-related information), the ENRP robin does not require additional policy-related
server MUST replace the PE's policy type with the overall policy information), the ENRP server MUST replace the PE's policy
type. type with the overall policy type.
2b) If additional policy information is required (e.g., B. If additional policy information is required (e.g.,
overriding Round-robin with Least-load will require the knowledge overriding Round-robin with Least-load will require the
of the load factor of the PE), the ENRP server MUST reject the knowledge of the load factor of the PE), the ENRP server MUST
regirstration with an error code "Pooling policy inconsistent". reject the regirstration with an error code "Pooling policy
inconsistent".
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, the ENRP server requesting PE is already a member of the pool, the ENRP server
SHOULD consider this as a re-registration case. The ENRP Server SHOULD consider this as a re-registration case. The ENRP Server
SHOULD replace the attributes of the existing PE with the SHOULD replace the attributes of the existing PE with the
information carried in the received REGISTRATION message. information carried in the received REGISTRATION message.
4) The ENRP server may reject the registration due to reasons such 4. After accepting the registration, the ENRP server MUST assgin
itself the owner of this PE. If this is a re-registration, the
ENRP server MUST take over ownership of this PE regardless of
whether the PE was previously owned by the server or by a peer of
it.
5. The ENRP server may reject the registration due to reasons such
as invalid values, lack of resource, authentication failure, etc. as invalid values, lack of resource, authentication failure, etc.
In all above cases, the ENRP server MUST reply to the requesting PE In all above cases, the ENRP server MUST reply to the requesting PE
with a REGISTRATION_RESPONSE message. In the message, the ENRP with a REGISTRATION_RESPONSE message. If the registration is
server MUST set the Action code to indicate that this is a response rejected, the ENRP server MUST indicate the rejection by including
to a PE registration and MUST indicate in the Result code whether the proper Operation Error parameter in the REGISTRATION_RESPONSE
the registration is granted or rejected. message.
If the registration is granted with a polcy override (see Step 2a If the registration is granted with a polcy override (see Step 2a
above), in addition to the Result code, in the above), in the REGISTRATION_RESPONSE message the ENRP server SHOULD
REGISTRATION_RESPONSE message the ENRP server SHOULD also send back also send back the registrant PE the new policy, in a Member
the registrant PE the new policy, in a Member Selection Policy Selection Policy Parameter, so as to inform the PE that a policy
Parameter, so as to inform the PE that a policy override is override is performed.
performed.
If the registration is granted (i.e., one of cases 1-3 above), the 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 ENRP server MUST assign itself to be the home ENRP server of the PE,
Section 4.6? to inform its peers about the change just made. If the i.e., to "own" the PE.
registration is denied, no message will be send to its peers.
Implementation note: for better performance, the ENRP server may
find it both efficient and convenient to internally maintain two
separate PE lists or tables - one is for the PEs that are "owned"
by the ENRP server and the other for all the PEs owned by its
peer(s).
Moreover, if the registration is granted, 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 sent to its peers.
4.3.1 Rules on PE Re-registration 4.3.1 Rules on PE Re-registration
A PE may re-register itself to the namespace with a new set of A PE may re-register itself to the namespace with a new set of
attributtes in order to, for example, extend its registration attributtes in order to, for example, extend its registration life,
life, change its load factor value, etc. change its load factor value, etc.
A PE may modify its load factor value at any time via A PE may modify its load factor value at any time via re-
re-registration. Based on the number of PEs in the pool and the registration. Based on the number of PEs in the pool and the pool's
pool's overall policy type, this operation allows the PE to overall policy type, this operation allows the PE to dynamically
dynamically control its share of inbound messages received by the control its share of inbound messages received by the pool (also see
pool (also see Section 4.5.2 in [ASAP] for more on load control). Section ???? in [1] for more on load control).
Moreover, when re-registering, the PE MUST NOT change its policy Moreover, when re-registering, the PE MUST NOT change its policy
type. The server MUST reject the re-registration if the PE attempt type. The server MUST reject the re-registration if the PE attempt
to change its policy type. In the rejection, the server SHOULD to change its policy type. In the rejection, the server SHOULD
attach an error code "Pooling policy inconsistent". attach an error code "Pooling Policy Inconsistent".
Regardless whether it is the current owner of the PE, if the re-
registration is granted to the PE, the ENRP server MUST assign itself
to be the new home ENRP server of the PE.
Moreover, if the re-registration is granted, 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 re-registration
is denied, no message will be sent to its peers.
4.4 Handle PE De-registration 4.4 Handle PE De-registration
To remove itself from a pool, a PE sends a DEREGISTRATION message To remove itself from a pool, a PE sends a DEREGISTRATION message to
to its home ENRP server. The complete format of DEREGISTRATION its home ENRP server. The complete format of DEREGISTRATION message
message and rules of sending it are defined in [ASAP]. and rules of sending it are defined in [1].
In the DEREGISTRATION message the PE indicates the name of the In the DEREGISTRATION message the PE indicates the name of the pool
pool it belongs to in a pool handle parameter and provides its PE it belongs to in a pool handle parameter and provides its PE
identifer. identifer.
Upon receiving the message, the ENRP server SHALL remove the PE Upon receiving the message, the ENRP server SHALL remove the PE from
from its namespace. Moreover, if the PE is the last one of the its namespace. Moreover, if the PE is the last one of the named
named pool, the ENRP server will remove the pool from the namespace pool, the ENRP server will remove the pool from the namespace as
as well. well.
If the ENRP server fails to find any record of the PE in its If the ENRP server fails to find any record of the PE in its
namespace, it SHOULD consider the de-registration granted and namespace, it SHOULD consider the de-registration granted and
completed. completed.
The ENRP server may reject the de-registration request for various The ENRP server may reject the de-registration request for various
reasons, such as invalid parameters, authentication failure, etc. reasons, such as invalid parameters, authentication failure, etc.
In response, the ENRP server MUST send a REGISTRATION_RESPONSE In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE
message to the PE. In the message, the ENRP server MUST set the message to the PE. If the de-registration is rejected, the ENRP
Action code to indicate that this is a response to a PE server MUST indicate the rejection by including the proper Operation
de-registration, and indicate in the Result code whether the Error parameter.
request is granted or rejected.
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 application messages. sending or receiving application messages.
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 ENRP server MUST take the its local copy of the namespace, the ENRP server MUST take the
namespace update action described in Section 4.6? to inform its namespace update action described in Section 4.6 to inform its peers
peers about the change just made. Otherwise, NO message SHALL be about the change just made. Otherwise, NO message SHALL be send to
send to its peers. its peers.
4.5 Pool Handle Translation 4.5 Pool Handle Translation
A PE or PU uses the pool handle translation service of an ENRP A PU uses the pool handle translation service of an ENRP server to
server to resolve a pool handle to a list of accessible transport resolve a pool handle to a list of accessible transport addresses of
addresses of the member PEs of the pool. the member PEs of the pool.
This requires the PE or PU to send a NAME_RESOLUTION message to its This requires the PU to send a NAME_RESOLUTION message to its home
home ENRP server and in the NAME_RESOLUTION message specify the ENRP server and in the NAME_RESOLUTION message specify the pool
pool handle to be translated in a Pool Handle parameter. Complete handle to be translated in a Pool Handle parameter. Complete
defintion of the NAME_RESOLUTION message and the rules of sending defintion of the NAME_RESOLUTION message and the rules of sending it
it are defined in [ASAP]. are defined in [1].
An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests
from PUs either over an SCTP associaiton on the well-know SCTP port,
or over a TCP connection on the well-know TCP port.
Upon reception of the NAME_RESOLUTION message, the ENRP server MUST Upon reception of the NAME_RESOLUTION message, the ENRP server MUST
first look up the pool handle in its namespace. If the pool exits, first look up the pool handle in its namespace. If the pool exits,
the home ENRP server MUST compose and send back a the home ENRP server MUST compose and send back a
NAME_RESOLUTION_RESPONSE message to the requesting PU or PE. NAME_RESOLUTION_RESPONSE message to the requesting PU.
In the response message, the ENRP server MUST list all the PEs In the response message, the ENRP server MUST list all the PEs
currently registered in this pool, in a list of PE parameters. The currently registered in this pool, in a list of PE parameters. The
ENRP server MUST also include a pool member selection policy ENRP server MUST also include a pool member selection policy
parameter to indicate the overall member selection policy for the parameter to indicate the overall member selection policy for the
pool, if the current pool member selection policy is not pool, if the current pool member selection policy is not round-robin
round-robin (if the overall policy is round-Robin, this parameter (if the overall policy is round-Robin, this parameter MAY be
MAY be omitted?). omitted?).
If the named pool does not exist in the namespace, the ENRP server If the named pool does not exist in the namespace, the ENRP server
MUST respond with a NAME_UNKNOWN message. MUST respond with a NAME_UNKNOWN message.
The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN
messages and the rules of receiving them are defined in [ASAP]. messages and the rules of receiving them are defined in [1].
4.6 Server Namespace Update 4.6 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 peers when its local namespace is modified, e.g., inform its peers when its local namespace is modified, e.g., addition
addition of a new PE, removal of an existing PE, change of pool of a new PE, removal of an existing PE, change of pool or PE
or PE properties. properties.
4.6.1 Announcing Addition or Update of PE 4.6.1 Announcing Addition or Update of PE
When a new PE is granted registration to the namespace or an When a new PE is granted registration to the namespace or an existing
existing PE is granted a re-registration, the home ENRP server PE is granted a re-registration, the home ENRP server uses this
uses this procedure to inform all its peers. procedure to inform all its peers.
This is an ENRP announcement and is sent to all the peer of the This is an ENRP announcement and is sent to all the peer of the home
home ENRP server. See Section 4.1 on how annoucements are sent. ENRP server. See Section 4.1 on how annoucements are sent.
An ENRP server MUST announce this update to all its peers in a An ENRP server MUST announce this update to all its peers in a
PEER_NAME_UPDATE message with the Update action field set to PEER_NAME_UPDATE message with the Update Action field set to ADD_PE,
ADD_PE, indicating the addition of a new PE or the modification of indicating the addition of a new PE or the modification of an
an existing PE. The complete new information of the PE and the pool existing PE. The complete new information of the PE and the pool its
its belongs to MUST be indicated in the message with a PE parameter belongs to MUST be indicated in the message with a PE parameter and a
and a Pool Handle parameter, respectively. Pool Handle parameter, respectively.
The home ENRP server SHOULD fill in its server Id in the Sender The home ENRP server SHOULD fill in its server Id in the Sender
Server's ID field and leave the Receiver Server's ID blank (i.e., Server's ID field and leave the Receiver Server's ID blank (i.e., all
all 0's). 0's).
When a peer receives this PEER_NAME_UPDATE message, it MUST take When a peer receives this PEER_NAME_UPDATE message, it MUST take the
the following actions: following actions:
1) If the named pool indicated by the pool handle does not exist 1. If the named pool indicated by the pool handle does not exist in
in its local copy of the namespace, the peer MUST create the named its local copy of the namespace, the peer MUST create the named
pool in its local namespace and add the PE to the pool as the first pool in its local namespace and add the PE to the pool as the
PE. It MUST then copy in all other attributes of the PE carried first PE. It MUST then copy in all other attributes of the PE
in the message. carried in the message.
When the new pool is created, the overall member selection policy When the new pool is created, the overall member selection policy
of the pool MUST be set to the policy type indicated by the PE. of the pool MUST be set to the policy type indicated by the PE.
2) If the named pool already exists in the peer's local copy of 2. If the named pool already exists in the peer's local copy of the
the namespace AND the PE does not exist, the peer MUST add the PE namespace AND the PE does not exist, the peer MUST add the PE to
to the pool as a new PE and copy in all attributes of the PE the pool as a new PE and copy in all attributes of the PE carried
carried in the message. 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, the peer MUST replace the attributes of the PE with the new pool, the peer MUST replace the attributes of the PE with the new
information carried in the message. information carried in the message.
4.6.2 Announcing Removal of PE 4.6.2 Announcing Removal of PE
When an existing PE is granted de-registration or is removed from When an existing PE is granted de-registration or is removed from its
its namespace for some other reasons (e.g., purging an unreachable namespace for some other reasons (e.g., purging an unreachable PE,
PE), the ENRP server MUST uses this procedure to inform all its see Section 4.7), the ENRP server MUST uses this procedure to inform
peers about the change just made. all its peers about the change just made.
This is an ENRP announcement and is sent to all the peer of the This is an ENRP announcement and is sent to all the peer of the home
home ENRP server. See Section 4.1 on how annoucements are sent. ENRP server. See Section 4.1 on how annoucements are sent.
An ENRP server MUST announce the PE removal to all its peers in a An ENRP server MUST announce the PE removal to all its peers in a
PEER_NAME_UPDATE message with the Update action field set to PEER_NAME_UPDATE message with the Update Action field set to DEL_PE,
DEL_PE, indicating the removal of an existing PE. The complete indicating the removal of an existing PE. The complete information
information of the PE and the pool its belongs to MUST be indicated of the PE and the pool its belongs to MUST be indicated in the
in the message with a PE parameter and a Pool Handle parameter, message with a PE parameter and a Pool Handle parameter,
respectively. respectively.
[editor's note: only the pool handle and the PE's id are needed, it [editor's note: only the pool handle and the PE's id are needed, it
should reduce the size of the message] should reduce the size of the message]
The sending server MUST fill in its server ID in the Sender The sending server MUST fill in its server ID in the Sender Server's
Server's ID field and leave the Receiver Server's ID blank (i.e., ID field and leave the Receiver Server's ID blank (i.e., set to all
set to all 0's). 0's).
When a peer receives this PEER_NAME_UPDATE message, it MUST first 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 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 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. 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 If the peer fails to find the PE or the pool in its namespace, it
SHOULD take no further actions. SHOULD take no further actions.
4.7 Detecting and Removing Unreachable PE 4.7 Detecting and Removing Unreachable PE
Whenever a PU finds a PE unreachable (e.g., via an SCTP Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE
SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the PU Notification, see section 10.2 of [7]), the PU SHOULD send an
SHOULD send an ENDPOINT_UNREACHABLE message to its home ENRP ENDPOINT_UNREACHABLE message to its home ENRP server. The message
server. The message SHOULD contain the pool handle and the PE Id SHOULD contain the pool handle and the PE Id of the unreachable PE.
of the unreachable PE.
Upon the reception of an ENDPOINT_UNREACHABLE message, a server Upon the reception of an ENDPOINT_UNREACHABLE message, a server MUST
MUST immediately send a point-to-point ENDPOINT_KEEP_ALIVE message immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the
to the PE in question. If this ENDPOINT_KEEP_ALIVE fails (i.e., it PE in question. If this ENDPOINT_KEEP_ALIVE fails (e.g., it results
results in an SCTP SEND.FAILURE notification), the ENRP server MUST in an SCTP SEND.FAILURE notification), the ENRP server MUST consider
consider the PE as truly unreachable and MUST remove the PE from the PE as truly unreachable and MUST remove the PE from its namespace
its namespace and take actions described in 4.6.2?. and take actions described in Section 4.6.2.
If the ENDPOINT_UNREACHABLE message is transmitted successfully to If the ENDPOINT_UNREACHABLE message is transmitted successfully to
the PE, the ENRP server MUST retain the PE in its namespace. the PE, the ENRP server MUST retain the PE in its namespace.
Moreover, the server SHOULD keep a counter to record how Moreover, the server SHOULD keep a counter to record how many
many ENDPOINT_UNREACHABLE messages it has received reporting ENDPOINT_UNREACHABLE messages it has received reporting reachability
reachability problem relating to this PE. If the counter exceeds problem relating to this PE. If the counter exceeds the protocol
the protocol threshold <MAX-BAD-PE-REPORT>, the ENRP server SHOULD threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE
remove the PE from its namespace and take actions described in from its namespace and take actions described in Section 4.6.2.
Section 4.6.2?.
The complete definition and rules of sending ENDPOINT_UNREACHABLE Optionally, an ENRP server may also periodically send point-to-point
and ENDPOINT_KEEP_ALIVE messages are described in [ASAP]. ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP
server in order to check their reachability status. If the send of
ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the
PE as unreachable and MUST remove the PE from its namespace and take
actions described in Section 4.6.2. Note, if an ENRP server owns a
large number of PEs, the implementation should pay attention not to
flood the network with bursts of ENDPOINT_KEEP_ALIVE messages.
Instead, the implementation should try to smooth out the
ENDPOINT_KEEP_ALIVE message traffic over time.
The complete definition and rules of sending ENDPOINT_UNREACHABLE and
receiving ENDPOINT_KEEP_ALIVE messages are described in [1].
4.8 Helping PE and PU to Discover Home ENRP Server 4.8 Helping PE and PU to Discover Home ENRP Server
At its startup time, or whenever its current home ENRP server is At its startup time, or whenever its current home ENRP server is not
not providing services, a PE or PU will attempt to find a new home 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. 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 SERVER_HUNT message to one or more ENRP servers in the operation
scope. For the complete procedure of this, see Section xxxx in scope. For the complete procedure of this, see Section ???? in [1].
[ASAP].
To support this procedure, whenever a SERVER_HUNT message is To support this procedure, whenever a SERVER_HUNT message is received
received an ENRP server SHOULD immediately respond to the sending an ENRP server SHOULD immediately respond to the sending PE or PU
PE or PU with a SERVER_HUNT_RESPONSE message. with a SERVER_HUNT_RESPONSE message.
4.9 Maintaining Peer List and Monitoring Peer Status 4.9 Maintaining Peer List and Monitoring Peer Status
An ENRP server MUST keep internally a record on the status of each An ENRP server MUST keep an internal record on the status of each of
of its known peers. This record is referred to as the server's its known peers. This record is referred to as the server's "peer
"peer list" list"
4.9.1 Discovering New Peer 4.9.1 Discovering New Peer
If a message of any type is received from a previously unknown If a message of any type is received from a previously unknown peer,
peer, the ENRP server MUST consider this peer a new peer in the the ENRP server MUST consider this peer a new peer in the operation
operation scope and add it to the peer list. scope and add it to the peer list.
If the message is The ENRP server MUST send a PEER_PRESENCE message with the Reply-
received over the well-known server multicast channel, the ENRP required flag set to '1' to the source address found in the arrived
server MUST mark this new peer as multicast-enabled. Otherwise, the message. This will force the new peer to reply with its own
new peer MUST be marked as multicast-disabled (see Section 4.1 for PEER_PRESENCE containing its full server information (see Section
more details). 3.1).
[editor's note: should we ask for a peer list from the new peer? [editor's note: should we ask for a peer list from the new peer?
this may help mending two splitted networks.] 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 4.9.2 Server Sending Heartbeat
Every <PEER-HEARTBEAT-CYCLE> seconds, an ENRP server MUST announce Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its
its continued presence to all its peer with a PEER_PRESENCE continued presence to all its peer with a PEER_PRESENCE message. In
message. In the PEER_PRESENCE message, the ENRP server MUST set the the PEER_PRESENCE message, the ENRP server MUST set the
'Replay_required' flag to '0', indicating that no response is 'Replay_required' flag to '0', indicating that no response is
required. required.
The arrival of this periodic PEER_PRESENCE message will cause all The arrival of this periodic PEER_PRESENCE message will cause all its
its peers to update their internal variable <Peer-last-heared> for peers to update their internal variable "Peer-last-heared" for the
the sending server (see Section 4.9.3? for more details). sending server (see Section 4.9.3 for more details).
4.9.3 Detecting Peer Server Failure 4.9.3 Detecting Peer Server Failure
An ENRP server MUST keep an interanl variable <Peer-last-heared> An ENRP server MUST keep an interanl variable "Peer-last-heared" for
for each of its known peers and the value of this variable MUST be 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 updated to the current local time everytime a message of any type
(point-to-point or announcement) is received from the cooresponding (point-to-point or announcement) is received from the cooresponding
peer. peer.
If a peer has not been heard for more than <MAX-TIME-LAST-HEARD> 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 seconds, the ENRP server MUST immediately send a point-to-point
PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer. PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer.
If the send fails or the peer does not reply after If the send fails or the peer does not reply after MAX-TIME-NO-
<MAX-TIME-NO-RESPONSE> seconds, the ENRP server MUST consider the RESPONSE seconds, the ENRP server MUST consider the peer server dead
peer server dead and remove the peer from its peer list. and SHOULD initiate the takeover procedure defined in Section 4.10.
4.10 Namespace Data Auditing and Re-synchronization 4.10 Taking-over a Failed Peer Server
[TBD] In the following descriptions, We call the ENRP server that detects
the failed peer server and initiates the take-over the "initiating
server" and the failed peer server the "target server."
4.11 Reporting Unrecognized Message or Unrecognized Parameter 4.10.1 Initiate Server Take-over Arbitration
The initiating server SHOULD fisrt start a take-over arbitration
process by announcing a PEER_INIT_TAKEOVER message to all its peer
servers. See Section 4.1 on how annoucements are sent. In the
message, the initiating server MUST fill in the Sender Server's ID
and Target Server's ID.
After announcing the PEER_INIT_TAKEOVER message, the initiating
server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_
of its known peers, except of the target server. [editor's note: how
long should it wait?]
Each of the peer servers that receives the PEER_INIT_TAKEOVER message
from the initiating server SHOULD take the following actions:
1. If the peer server finds that itself is the target server
indicated in the PEER_INIT_TAKEOVER message, it MUST immediately
announce a PEER_PRESENCE message to all its peer ENRP servers in
an attempt to stop this take-over process. This indicates a
false failure detection case by the initiating server.
2. If the peer server finds that itself has already started its own
take-over arbitration process on the same target server, it MUST
perform the following arbitration:
A. if the peer's server ID is smaller in value than the Sender
Server's ID in the arrived PEER_INIT_TAKEOVER message, the
peer server SHOULD immediately abort its own take-over
attempt. Moreover, the peer SHOULD mark the target server as
"not active" on its internal peer list so that its status
will no longer be monitored by the peer, and reply the
initiating server with a PEER_INIT_TAKEOVER_ACK message.
B. Otherwise, the peer MUST ignore the PEER_INIT_TAKEOVER
message and take no action.
3. If the peer finds that it is neither the target server nor is in
its own take-over process, the peer SHOULD: a) mark the target
server as "not active" on its internal peer list so that its
status will no longer be monitored by this peer, and b) reply to
the initiating server with a PEER_INIT_TAKEOVER_ACK message.
Once the initiating server has received PEER_INIT_TAKEOVER_ACK
message from _all_ of its currently known peers (except for the
target server), it SHOULD consider that it has won the arbitration
and SHOULD proceed to complete the take-over, following the steps
described in Section 4.10.2.
However, if it receives a PEER_PRESENCE from the target server at any
point in the arbitration process, the initiating server SHOULD
immediately abort the take-over process and mark the status of the
target server as "active".
4.10.2 Take-over Target Peer Server
The initiating ENRP server SHOULD first send, via an announcement, a
PEER_TAKEOVER_SERVER message to inform all its active peers that the
take-over is enforced. The target server's ID MUST be filled in the
message. The initiating server SHOULD then remove the target server
from its internal peer list.
[editor's note: peers should remove the target server from their list
upon receiving this message. Do we really need this message? we can
consolidate this with the ownership_change msg.]
Then it SHOULD examine its local copy of the namespace and claim
ownership of each of the PEs originally owned by the target server,
by following these steps:
1. mark itself as the home ENRP server of each of the PEs originally
owned by the target server;
2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the
PEs. This will trigger the PE to adopt the initiating sever as
its new home ENRP server;
3. after claiming the ownership of all the PEs originally owned by
the target server, announce the ownership changes of all the
affected PEs in a PEER_OWNERSHIP_CHANGE message to all the
currently known peers. Note, if the list of affected PEs is
long, the sender MAY announce the ownership changes in multiple
PEER_OWNERSHIP_CHANGE messages.
When a peer receives the PEER_OWNERSHIP_CHANGE message from the
initiating server, it SHOULD find each of the reported PEs in its
local copy of the namespace and update the PE's home ENRP server to
be the sender of the message (i.e., the initiating server).
4.11 Namespace Data Auditing and Re-synchronization
Message losses or certain temporary breaks in network connectivity
may result in data inconsistency in the local namespace copy of some
of the ENRP servers in an operation scope. Therefore, each ENRP
server in the operation scope SHOULD periodically verify that its
local copy of namespace data is still in sync with that of its peers.
This section defines the auditing and re-synchronization procedures
for an ENRP server to maintain its namespace data consistency.
4.11.1 Auditing Prodecures
[TBD] [TBD]
4.11.2 Re-synchronization Prodecures
Once an ENRP server determines that there is inconsistancy between
its local namespace data and a peer's namespace data with regarding
to the PEs owned by that peer, it SHOULD perform the following steps
to re-synchronize the data:
1. The ENRP server SHOULD first "mark" every PE it knows about that
is owned by the peer in its local namespace database;
2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST
message with W flag set to '1' to the peer to request a complete
list of PEs owned by the peer;
3. Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag
set to '1', the peer server SHOULD immediately respond with a
PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned
by the peer.
4. Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP
server SHOULD transfer the PE entries carried in the message into
its local namespace database. If an PE entry being transferred
already exists in its local database, the ENRP server MUST
replace the entry with the copy found in the message and remove
the "mark" from the entry.
5. After transferring all the PE entries from the received
PEER_NAME_TABLE_RESPONSE message into its local database, the
ENRP server SHOULD check whether there are still PE entries that
remain "marked" in its local namespace. If so, the ENRP server
SHOULD silently remove those "marked" entries.
Note, similar to what is described in Section 4.2.3, the peer may
reject the PEER_NAME_TABLE_REQUEST or use more than one
PEER_NAME_TABLE_RESPONSE message to respond.
4.12 Handling Unrecognized Message or Unrecognized Parameter
When an ENRP server receives an ENRP message with an unknown message
type or a message of known type that contains an unknow parameter, it
SHOULD handle the unknow message or the unknown parameter according
to the unrecognized message and parameter handling rules defined in
Sections 3 and 4 in [10].
According to the rules, if an error report to the message sender is
needed, the ENRP server that discovered the error SHOULD send back an
ENRP_ERROR message with proper error cause code.
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
heard (via receiving either a multicast or (via receiving either a multicast or point-to-point message from
point-to-point message from the peer). the peer).
5.2 Timer Constants 5.2 Timer Constants
<MAX-TIME-SERVER-HUNT> - the maximal number of attempts a sender MAX-TIME-SERVER-HUNT - the maximal number of attempts a sender will
will make to contact an ENRP server make to contact an ENRP server (Default=3 times).
(Default=3 times).
<TIMEOUT-SERVER-HUNT> - pre-set threshold for how long a sender TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will
will wait for a response from an ENRP wait for a response from an ENRP server (Default=5 secends).
server (Default=5 secends).
<PEER-HEARTBEAT-CYCLE> - the period for an ENRP server to announce a PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a
heartheat message to all its known peers. 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
server will wait before considering a will wait before considering a silent peer server potentially
silent peer server potentially dead. 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.
sending out a message. (Default=5 secs.) (Default=5 secs.)
<MAX-BAD-PE-REPORT> - the maximal number of unreachability reports MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a
on a PE that an ENRP server will allow PE that an ENRP server will allow before purging this PE from the
before purging this PE from the namespace. namespace. (Default=3)
(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
and network architects based on system requirements. network architects based on system requirements.
For networks that demand IPsec security, implementations MUST For networks that demand IPsec security, implementations MUST support
support [SCTP-IPSEC] which describes IPsec-SCTP. IPsec is two [9] which describes IPsec-SCTP. IPsec is two layers below RSerPool.
layers below RSerPool. Therefore, if IPsec is used for securing Therefore, if IPsec is used for securing Rserpool, no changes or
Rserpool, no changes or special considerations need to be made to special considerations need to be made to Rserpool to secure the
Rserpool to secure the protocol. 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
described in [SCTP-TLS] or TLS over TCP as described in [RFC2246]. in [8] or TLS over TCP as described in [6]. When using TLS/SCTP we
When using TLS/SCTP we must ensure that RSerPool does not use any must ensure that RSerPool does not use any features of SCTP that are
features of SCTP that are not available to an TLS/SCTP user. This not available to an TLS/SCTP user. This is not a difficult technical
is not a difficult technical problem, but simply a problem, but simply a requirement. When describing an API of the
requirement. When describing an API of the RSerPool lower layer we RSerPool lower layer we have also to take into account the
have also to take into account the differences between TLS and differences between TLS and SCTP. This is also not difficult, but it
SCTP. This is also not difficult, but it is in contrast to the is in contrast to the IPsec solution which is transparently layered
IPsec solution which is transparently layered below Rserpool. 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
the end user implementation contains a piece of the Rserpool the end user implementation contains a piece of the Rserpool protocol
protocol -- namely ASAP -- whereby the pool handle is passed for -- namely ASAP -- whereby the pool handle is passed for name
name resolution to the ENRP server and IP address(es) are resolution to the ENRP server and IP address(es) are returned.
returned.
The argument for optional end user security is as follows: If the The argument for optional end user security is as follows: If the
user doesn't require security protection for example, against user doesn't require security protection for example, against
eavesdropping for the request for pool handle resolution and eavesdropping for the request for pool handle resolution and
response, then they are free to make that choice. However, if the response, then they are free to make that choice. However, if the
end user does require security, they are guaranteed to get it due end user does require security, they are guaranteed to get it due to
to the requirement for security support for the ENRP server. It is the requirement for security support for the ENRP server. It is also
also possible for the ENRP server to reject an unsecured request possible for the ENRP server to reject an unsecured request from the
from the user due to its security policy in the case that it user due to its security policy in the case that it requires
requires enforcement of strong security. But this will be enforcement of strong security. But this will be determined by the
determined by the security requirements of the individual network security requirements of the individual network design.
design.
7. References 7. Acknowledgements
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision The authors wish to thank John Loughney, Lyndon Ong, and many others
3", BCP 9, RFC 2026, October 1996. for their invaluable comments.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0", [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
RFC 2246, January 1999. Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-04
(work in progress), July 2002.
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, J. and M. Stillman, "Requirements for Reliable Server Pooling",
V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October RFC 3237, January 2002.
2000.
[RFC3237] M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
J. Loughney, M. Stillman: "Requirements for Reliable Server J. and M. Stillman, "Architecture for Reliable Server Pooling",
Pooling", RFC 3237, January 2002. draft-ietf-rserpool-arch-03 (work in progress), July 2002.
[ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol [4] Bradner, S., "The Internet Standards Process -- Revision 3",
(ASAP)", <draft-ietf-rserpool-asap-00.txt>, work in progress. BCP 9, RFC 2026, October 1996.
[RSPL-ARCH] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server Levels", BCP 14, RFC 2119, March 1997.
Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress.
[SCTP-TLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP", [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress. 2246, January 1999.
[SCTP-IPSEC] S.M. Bellovin, J. Ioannidis, A.D. Keromytis, [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
R.R. Stewart, "On the Use of SCTP with IPsec", H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
<draft-ietf-ipsec-sctp-03.txt>, work in progress. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RSPL-PARAM] R. Stewart, Q. Xie: "Aggregate Server Access Protocol [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP",
(ASAP) and Endpoint Name Resolution Protocol (ENRP) Common draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November
Parameters Document", <draft-ietf-rserpool-enrp-asap-param-00.txt>, 2001.
work in progress.
7.1 Informative References [9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On
the Use of SCTP with IPsec", draft-ietf-ipsec-sctp-03 (work in
progress), February 2002.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for [10] Stewart, R. and Q. Xie, "Aggregate Server Access Protocol
Security", RFC 1750, December 1994. (ASAP) and Endpoint Name Resolution (ENRP) common parameters
document", draft-ietf-rserpool-common-param-00 (work in
progress), July 2002.
8. Acknowledgements Informative References
The authors wish to thank John Loughney, Lyndon Ong, and many [11] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
others for their invaluable comments. Recommendations for Security", RFC 1750, December 1994.
9. Authors' Addresses Authors' Addresses
Qiaobing Xie Phone: +1-847-632-3028 Qiaobing Xie
Motorola, Inc. EMail: qxie1@email.mot.com Motorola, Inc.
1501 W. Shure Drive, 2-F9 1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA US
Randall R. Stewart Phone: +1-815-477-2127 Phone: +1-847-632-3028
24 Burning Bush Trail. EMail: rrs@cisco.com EMail: qxie1@email.mot.com
Randall R. Stewart
Cisco
24 Burning Bush Trail
Crystal Lake, IL 60012 Crystal Lake, IL 60012
USA US
Maureen Stillman Phone: +1 607 273 0724 62 Phone: +1-815-477-2127
Nokia EMail: maureen.stillman@nokia.com EMail: rrs@cisco.com
Maureen Stillman
Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA US
Expires in six months from May 2002 Phone: +1 607 273 0724 62
EMail: maureen.stillman@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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