draft-ietf-rserpool-enrp-09.txt   draft-ietf-rserpool-enrp-10.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Expires: January 7, 2005 R. Stewart Expires: April 14, 2005 R. Stewart
Cisco Cisco Systems, Inc.
M. Stillman M. Stillman
Nokia Nokia
July 9, 2004 M. Tuexen
October 14, 2004
Endpoint Name Resolution Protocol (ENRP) Endpoint Name Resolution Protocol (ENRP)
draft-ietf-rserpool-enrp-09.txt draft-ietf-rserpool-enrp-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2005. This Internet-Draft will expire on April 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
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) to conjunction with the Aggregate Server Access Protocol (ASAP) to
accomplish the functionality of the Reliable Server Pooling accomplish the functionality of the Reliable Server Pooling
(Rserpool) requirements and architecture. Within the operational (Rserpool) requirements and architecture. Within the operational
scope of Rserpool, ENRP defines the procedures and message formats of scope of Rserpool, ENRP defines the procedures and message formats of
a distributed, fault-tolerant registry service for storing, a distributed, fault-tolerant registry service for storing,
bookkeeping, retrieving, and distributing pool operation and bookkeeping, retrieving, and distributing pool operation and
membership information. membership information.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
3. ENRP Message Definitions . . . . . . . . . . . . . . . . . . 7 2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . 6
3.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 7 2.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 6
3.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 9 2.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 8
3.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 9 2.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 8
3.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 11 2.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 10
3.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 12 2.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 11
3.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 2.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12
3.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 2.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13
3.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 15 2.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14
3.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15 2.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 14
3.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . 16 2.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . 15
3.11 PEER_ERROR message . . . . . . . . . . . . . . . . . . . 18 2.11 ENRP_ERROR message . . . . . . . . . . . . . . . . . . . 17
4. ENRP Operation Procedures . . . . . . . . . . . . . . . . . 19 3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . 18
4.1 Methods for Communicating amongst ENRP Servers . . . . . . 19 3.1 Methods for Communicating amongst ENRP Servers . . . . . . 18
4.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 20 3.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 19
4.2.1 Generate a Server Identifier . . . . . . . . . . . . . 21 3.2.1 Generate a Server Identifier . . . . . . . . . . . . . 20
4.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . 21 3.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . 20
4.2.3 Download ENRP Namespace Data from Mentor Peer . . . . 23 3.2.3 Download ENRP Handlespace Data from Mentor Peer . . . 22
4.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 25 3.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 24
4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . 27 3.3.1 Rules on PE Re-registration . . . . . . . . . . . . . 26
4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 28 3.4 Handle PE De-registration . . . . . . . . . . . . . . . . 27
4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28 3.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 27
4.6 Server Namespace Update . . . . . . . . . . . . . . . . . 29 3.6 Server Handlespace Update . . . . . . . . . . . . . . . . 28
4.6.1 Announcing Addition or Update of PE . . . . . . . . . 29 3.6.1 Announcing Addition or Update of PE . . . . . . . . . 28
4.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . 30 3.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . 29
4.7 Detecting and Removing Unreachable PE . . . . . . . . . . 31 3.7 Detecting and Removing Unreachable PE . . . . . . . . . . 30
4.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 32 3.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 31
4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 32 3.9 Maintaining Peer List and Monitoring Peer Status . . . . . 31
4.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . 32 3.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . 31
4.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . 32 3.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . 31
4.9.3 Detecting Peer Server Failure . . . . . . . . . . . . 33 3.9.3 Detecting Peer Server Failure . . . . . . . . . . . . 32
4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . 33 3.10 Taking-over a Failed Peer Server . . . . . . . . . . . . 32
4.10.1 Initiate Server Take-over Arbitration . . . . . . . 33 3.10.1 Initiate Server Take-over Arbitration . . . . . . . 32
4.10.2 Take-over Target Peer Server . . . . . . . . . . . . 34 3.10.2 Take-over Target Peer Server . . . . . . . . . . . . 33
4.11 Namespace Data Auditing and Re-synchronization . . . . . 35 3.11 Handlespace Data Auditing and Re-synchronization . . . . 34
4.11.1 Auditing Procedures . . . . . . . . . . . . . . . . 35 3.11.1 Auditing Procedures . . . . . . . . . . . . . . . . 34
4.11.2 PE Checksum Calculation Algorithm . . . . . . . . . 36 3.11.2 PE Checksum Calculation Algorithm . . . . . . . . . 35
4.11.3 Re-synchronization Procedures . . . . . . . . . . . 37 3.11.3 Re-synchronization Procedures . . . . . . . . . . . 36
4.12 Handling Unrecognized Message or Unrecognized 3.12 Handling Unrecognized Message or Unrecognized
Parameter . . . . . . . . . . . . . . . . . . . . . . . 37 Parameter . . . . . . . . . . . . . . . . . . . . . . . 36
5. Variables and Thresholds . . . . . . . . . . . . . . . . . . 39 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . 38
5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . 40 5. Security Considerations . . . . . . . . . . . . . . . . . . 39
6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 41 5.1 Implementing Security Mechanisms . . . . . . . . . . . . . 40
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 44 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 43
8.2 Informative References . . . . . . . . . . . . . . . . . . . 45 7.2 Informative References . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . 45
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP [1] to accomplish ENRP is designed to work in conjunction with ASAP [1] to accomplish
the functionality of Rserpool as defined by its requirements [2] and the functionality of Rserpool as defined by its requirements [2] and
architecture [3]. 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 service and message formats of a distributed fault-tolerant registry service
for storing, bookkeeping, retrieving, and distributing pool operation for storing, bookkeeping, retrieving, and distributing pool 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 handlespace, or simply
namespace. handlespace.
1.1 Definitions 1.1 Definitions
This document uses the following terms: This document uses the following terms:
Operation scope: See [3]; Operation scope: See [3];
Pool (or server pool): See [3]; Pool (or server pool): See [3];
Pool handle (or pool name): See [3]; Pool handle: See [3];
Pool element (PE): See [3]; Pool element (PE): See [3];
Pool user (PU): See [3]; Pool user (PU): See [3];
Pool element handle: See [3]; Pool element handle: See [3];
ENRP namespace (or namespace): See [3]; ENRP handlespace (or handlespace): See [3];
ENRP namespace server (or ENRP server): See [3];
ENRP client channel: The communication channel through which a PE ENRP client channel: The communication channel through which an ASAP
requests for ENRP namespace service. The ENRP client channel is User (either a PE or PU) requests ENRP handlespace service. The
usually defined by the transport address of the home ENRP server client channel is usually defined by the transport address of the
and a well known port number; home server and a well known port number. The channel MAY make
use of multi-cast or a named list of ENRP servers.
ENRP server channel: Defined by a well known multicast IP address and ENRP server channel: Defined by a well known multicast IP address and
a well known port number. All ENRP servers in an operation scope a well known port number. All ENRP servers in an operation scope
can send multicast messages to other servers through this channel. can send multicast messages to other servers through this channel.
PEs are also allowed to multicast on this channel occasionally; PEs are also allowed to multicast on this channel occasionally;
Home ENRP server: The ENRP server to which a PE or PU currently 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 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 time and both the PE and its home ENRP server MUST keep track of
this master/slave relationship between them. A PU SHOULD select this master/slave relationship between them. A PU SHOULD select
one of the available ENRP servers as its home ENRP server, but the 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 ENRP server does not need to know, nor does it need to keep track
of this relationship. of this relationship.
2. Conventions 1.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
[5]. [5].
3. ENRP Message Definitions 2. 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 server scope. Messages sent and received between a PE/PU and an ENRP server
are part of ASAP and are defined in [1]. A common format, defined in are part of ASAP and are defined in [1]. A common format, defined in
[10], 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 [10]. 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) 0x00 - (reserved by IETF)
0x1 - PEER_PRESENCE 0x01 - PEER_PRESENCE
0x2 - PEER_NAME_TABLE_REQUEST 0x02 - PEER_NAME_TABLE_REQUEST
0x3 - PEER_NAME_TABLE_RESPONSE 0x03 - PEER_NAME_TABLE_RESPONSE
0x4 - PEER_NAME_UPDATE 0x04 - PEER_NAME_UPDATE
0x5 - PEER_LIST_REQUEST 0x05 - PEER_LIST_REQUEST
0x6 - PEER_LIST_RESPONSE 0x06 - PEER_LIST_RESPONSE
0x7 - PEER_INIT_TAKEOVER 0x07 - PEER_INIT_TAKEOVER
0x8 - PEER_INIT_TAKEOVER_ACK 0x08 - PEER_INIT_TAKEOVER_ACK
0x9 - PEER_TAKEOVER_SERVER 0x09 - PEER_TAKEOVER_SERVER
0xa - PEER_OWNERSHIP_CHANGE 0x0a - PEER_OWNERSHIP_CHANGE
0xb - PEER_ERROR 0x0b - ENRP_ERROR
0xc-0xFF - (reserved by IETF) 0x0c-0xff - (reserved by IETF)
3.1 PEER_PRESENCE message 2.1 PEER_PRESENCE message
This ENRP message is used to announce (periodically) the presence of This ENRP message is used to announce (periodically) the presence 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 | | Type = 0x01 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Checksum Param : : PE Checksum Param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Param (optional) : : Server Information Param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 39 skipping to change at page 7, line 39
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 server (e.g., the message is multicasted to a group of
servers), this field MUST be set with all 0's. servers), this field MUST be set with all 0's.
PE Checksum Parameter: PE Checksum Parameter:
This is a TLV that contains the latest PE checksum of the ENRP This is a TLV that contains the latest PE checksum of the ENRP
server who sends the PEER_PRESENCE. This parameter SHOULD be server who sends the PEER_PRESENCE. This parameter SHOULD be
included for namespace consistency auditing. See Section included for handlespace consistency auditing. See Section
4.11.1 for details. 3.11.1 for details.
Server Information Parameter: Server Information Parameter:
If present, contains the server information of the sender of If present, contains the server information of the sender of
this message (Server Information Parameter is defined in [10]). this message (Server Information Parameter is defined in [10]).
This parameter is optional. However, if this message is sent This parameter is optional. However, if this message is sent
in response to a received "reply required" PEER_PRESENCE from a in response to a received "reply required" PEER_PRESENCE from a
peer, the sender then MUST include its server information. peer, the sender then MUST include its server information.
Note, at startup an ENRP server MUST pick a randomly generated, 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 non-zero 32-bit unsigned integer as its ID and MUST use this same ID
for its entire life. for its entire life.
3.2 PEER_NAME_TABLE_REQUEST message 2.2 PEER_NAME_TABLE_REQUEST message
An ENRP server sends this message to one of its peers to request a 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 copy of the handlespace data. This message is normally used during
server initialization or namespace re-synchronization. server initialization or handlespace 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|W| Message Length = 0xC | | Type = 0x02 |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 W (oWn-children-only) flag: 1 bit
Set to '1' if the sender of this message is only requesting Set to '1' if the sender of this message is only requesting
information about the PEs owned by the message receiver. information about the PEs owned by the message receiver.
Otherwise, set to '0'. Otherwise, set to '0'.
Sender Server's ID: Sender Server's ID:
See Section 3.1. See Section 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.1.
3.3 PEER_NAME_TABLE_RESPONSE message 2.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|M|R| Message Length | | Type = 0x03 |0|0|0|0|0|0|M|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Pool entry #1 (see below) : : Pool entry #1 (see below) :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
skipping to change at page 10, line 35 skipping to change at page 9, line 35
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 to subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set to
'0'. '0'.
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
namespace request. In such a case, this message MUST be sent handlespace request. In such a case, this message MUST be sent
with no pool entries included. with no pool entries included.
Message Length: 16 bits (unsigned integer) Message Length: 16 bits (unsigned integer)
Indicates the entire length of the message in number of octets. Indicates the entire length of the message in number of 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 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.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 :
+---------------------------+ +---------------------------+
: PE #1 : : PE #1 :
+---------------------------+ +---------------------------+
: PE #2 : : PE #2 :
+---------------------------+ +---------------------------+
: ... : : ... :
+---------------------------+ +---------------------------+
: PE #n : : PE #n :
+---------------------------+ +---------------------------+
3.4 PEER_NAME_UPDATE message 2.4 PEER_NAME_UPDATE message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Action | (reserved) | | Update Action | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle : : Pool handle :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element : : Pool Element :
skipping to change at page 12, line 14 skipping to change at page 11, line 14
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 PE. This field indicates what act is requested to the specified 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 handlespace
0x1 - DEL_PE: delete the specified PE from the ENRP namespace. 0x1 - DEL_PE: delete the specified PE from the ENRP
handlespace.
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 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.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 2.5 PEER_LIST_REQUEST message
This ENRP message is used to request a copy of the current known ENRP This ENRP message is used to request a copy of the current known ENRP
peer server list. This message is normally sent from a newly started peer server list. This message is normally sent from a newly started
ENRP server to an existing ENRP server as part of the initialization ENRP server to an existing ENRP server as part of the 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 = 0x05 |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 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.1.
3.6 PEER_LIST_RESPONSE message 2.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 = 0x06 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Info Param of Peer #1 : : Server Info Param of Peer #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Info Param of Peer #n : : Server Info Param of Peer #n :
skipping to change at page 14, line 15 skipping to change at page 13, line 15
Message Length: 16 bits (unsigned integer) Message Length: 16 bits (unsigned integer)
Indicates the entire length of the message in number of octets. Indicates the entire length of the message in number of 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 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.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 Each contains a Server Information Parameter of a peer known to
the sender. The Server Information Parameter is defined in the sender. The Server Information Parameter is defined in
[10]. [10].
3.7 PEER_INIT_TAKEOVER message 2.7 PEER_INIT_TAKEOVER message
This message is used by an ENRP server (the takeover initiator) to This message is used by an ENRP server (the takeover initiator) to
declare its intention of taking over a specific peer ENRP server. declare its intention of taking over a specific peer ENRP 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 = 0x7 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Server's ID | | Target Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sender Server's ID:
See Section 3.1. See Section 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.1.
Target Server's ID: Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover attempt. target of this takeover attempt.
3.8 PEER_INIT_TAKEOVER_ACK message 2.8 PEER_INIT_TAKEOVER_ACK message
This message is used to acknowledge the takeover initiator that the This message is used to acknowledge the takeover initiator that the
sender of this message received the PEER_INIT_TAKEOVER message and sender of this message received the PEER_INIT_TAKEOVER message and
that it does not object to the takeover. that it does not object to the takeover.
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 = 0x8 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Server's ID | | Target Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sender Server's ID:
See Section 3.1. See Section 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.1.
Target Server's ID: Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover attempt. target of this takeover attempt.
3.9 PEER_TAKEOVER_SERVER message 2.9 PEER_TAKEOVER_SERVER message
This message is used by the takeover initiator to declare that a This message is used by the takeover initiator to declare that a
takeover is underway. takeover is underway.
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 = 0x9 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Server's ID | | Target Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sender Server's ID:
See Section 3.1. See Section 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.1.
Target Server's ID: Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover operation. target of this takeover operation.
3.10 PEER_OWNERSHIP_CHANGE message 2.10 PEER_OWNERSHIP_CHANGE message
This message is used by the ENRP server, normally after a successful 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 takeover, to declare that it is now the new home ENRP server of the
listed PEs in the listed pools. listed PEs in the listed pools.
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 = 0xa |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle #1 : : Pool handle #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #1 of pool #1 : : PE Identifier Param #1 of pool #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
skipping to change at page 17, line 37 skipping to change at page 16, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #1 of pool #M : : PE Identifier Param #1 of pool #M :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #n of pool #M : : PE Identifier Param #n of pool #M :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sender Server's ID:
See Section 3.1. See Section 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.1.
Pool handles and PE Identifier parameters: Pool handles and PE Identifier parameters:
Each listed pool handle is followed by a list of PE Identifier Each listed pool handle is followed by a list of PE Identifier
parameters, indicating that the sender of this message is parameters, indicating that the sender of this message is
taking ownership of the listed PEs in the pool. taking ownership of the listed PEs in the pool.
3.11 PEER_ERROR message 2.11 ENRP_ERROR message
This message is used by an ENRP server to report an operation error This message is used by an ENRP server to report an operation error
to one of its peers. to one of its peers.
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 = 0xb |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operation Error Parameter : : Operation Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sender Server's ID:
See Section 3.1. See Section 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 3.1. See Section 2.1.
Operation Error Parameter: Operation Error Parameter:
This parameter, defined in [10], indicates the type of error(s) This parameter, defined in [10], indicates the type of error(s)
being reported. being reported.
4. ENRP Operation Procedures 3. ENRP Operation Procedures
In this section, we discuss the operation procedures defined by ENRP. In this section, we discuss the operation procedures defined by 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 PU/ Many of the Rserpool events call for both server-to-server and
PE-to-server message exchanges. Only the message exchanges and PU/PE-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 [1]. are defined in [1].
4.1 Methods for Communicating amongst ENRP Servers 3.1 Methods for Communicating amongst ENRP Servers
Within an Rserpool operation scope, ENRP servers need to communicate Within an Rserpool operation scope, ENRP servers need to communicate
with each other in order to exchange information such as the pool with each other in order to exchange information such as the pool
membership changes, namespace data synchronization, etc. membership changes, handlespace data synchronization, etc.
Two types of communications are used amongst ENRP servers: Two types of communications are used amongst ENRP servers:
o point-to-point message exchange from one ENPR server to a specific o point-to-point message exchange from one ENPR server to a specific
peer server, and peer server, and
o 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
skipping to change at page 20, line 43 skipping to change at page 19, line 43
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.
D. 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 the well-known server multicast channel AND a copy to each of the
peers that are marked as multicast-disabled over a peers that are marked as multicast-disabled over a
point-to-point SCTP association. point-to-point SCTP association.
4.2 ENRP Server Initialization 3.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 handlespace service if it is the first ENRP server started in the
operation scope. operation scope.
4.2.1 Generate a Server Identifier 3.2.1 Generate a Server Identifier
A new ENRP server MUST generate a non-zero, 32-bit server Id that is A new ENRP server MUST generate a non-zero, 32-bit server Id that is
as 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 ([12] 32-bit random number will be good enough as the server Id ([12]
provides some information on randomness guidelines). provides some information on randomness guidelines).
Note, there is a very remote chance (about 1 in 4 billion) that two Note, there is a very remote chance (about 1 in 4 billion) that two
ENRP servers in an operation scope will generate the same server Id ENRP servers in an operation scope will generate the same server Id
and hence cause a server Id conflict in the pool. However, no severe and hence cause a server Id conflict in the pool. However, no severe
consequence of such a conflict has been identified. consequence of such a conflict has been identified.
4.2.2 Acquire Peer Server List 3.2.2 Acquire Peer Server List
At startup, the ENRP server (initiating server) will first attempt to At startup, the ENRP server (initiating server) will first attempt to
learn all existing peer ENRP servers in the same operation scope, or learn all existing peer ENRP servers in the same operation 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 3.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 mentor peers, and skip the remaining steps in others as its backup mentor peers, and skip the remaining steps in
skipping to change at page 22, line 22 skipping to change at page 21, line 22
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 repeat TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat
steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After
that, if there is still no response, the initiating server MUST that, if there is still no response, the initiating 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 Section 4.2.2.2 and Section scope, it MUST skip the procedures in Section 3.2.2.2 and Section
4.2.3 and MUST consider its initialization completed and start 3.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 such Note, if multicast is not available (or not allowed for reasons such
as security concerns) in the operation scope, at least one peer as security concerns) in the operation scope, at least one 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 mentor peer(s) fails, the Note, if the administratively specified mentor 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 3.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 a discovery or administrative means), the initiating server MUST send a
PEER_LIST_REQUEST message to the mentor peer server to request a copy PEER_LIST_REQUEST message to the mentor peer server to request a 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 3.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 mentor Upon the reception of the PEER_LIST_RESPONSE message from the mentor
peer, the initiating server MUST use the server information carried peer, the initiating server MUST use the server information carried
in the message to initialize its own peer list. in the message to initialize its own peer 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
skipping to change at page 23, line 16 skipping to change at page 22, line 16
server), it MUST reject the request by the initiating server and server), it MUST reject the request by the initiating server and
respond with a PEER_LIST_RESPONSE message with the R flag set to '1', respond with a PEER_LIST_RESPONSE message with the R flag set to '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 and peer, the initiating server SHOULD either wait for a few seconds and
re-send the PEER_LIST_REQUEST to the mentor server, or if there is a re-send the PEER_LIST_REQUEST to the mentor server, or if there is a
backup mentor peer available, select another mentor peer server and backup mentor peer available, select another mentor peer 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 3.2.3 Download ENRP Handlespace Data from Mentor Peer
After a peer list download is completed, the initiating server MUST After a peer list download is completed, the initiating server MUST
request a copy of the current namespace data from its mentor peer request a copy of the current handlespace data from its mentor 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, with W flag set to '0', indicating message to the mentor peer, with W flag set to '0', indicating
that the entire namespace is requested. that the entire handlespace 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 handlespace data
maintained by the mentor peer is sent to the initiating server in maintained by the mentor peer is sent to the initiating server in
one or more PEER_NAME_TABLE_RESPONSE messages (Note, the mentor one or more PEER_NAME_TABLE_RESPONSE messages (Note, the mentor
server may find it particularly desirable to use multiple server may find it particularly desirable to use multiple
PEER_NAME_TABLE_RESPONSE messages to send the namespace when the PEER_NAME_TABLE_RESPONSE messages to send the handlespace when
namespace is large, especially when forming and sending out a the handlespace is large, especially when forming and sending out
single response containing a large namespace may interrupt its a single response containing a large handlespace may interrupt
other services). its other services).
If more than one PEER_NAME_TABLE_RESPONSE message are used during If more than one PEER_NAME_TABLE_RESPONSE message are used 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 message PEER_NAME_TABLE_RESPONSE message to indicate whether this message
is the last one for the download session. In particular, the is the last one for the download session. In particular, 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 receives 3. During the downloading, every time the initiating server receives
a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data
entries carried in the message into its local namespace database, entries carried in the message into its local handlespace
and then check whether or not this message is the last one for database, and then check whether or not this message is the last
the download session. one for 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 send PEER_NAME_TABLE_RESPONSE message, the initiating server MUST send
another PEER_NAME_TABLE_REQUEST message to the mentor peer to another PEER_NAME_TABLE_REQUEST message to the mentor peer 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 server message into its local handlespace database, the initiating
MUST handle each pool entry carried in the message using the server MUST handle each pool entry carried in the message using
following rules: the following rules:
A. If the pool does not exist in the local namespace, the A. If the pool does not exist in the local handlespace, 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. handlespace 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.
B. If the pool already exists in the local namespace, but the B. If the pool already exists in the local handlespace, 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.
C. If the pool already exists in the local namespace AND the C. If the pool already exists in the local handlespace 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 SHOULD replace the attributes of the initiating server SHOULD replace the attributes of 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 handlespace, 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 handlespace 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 handlespace 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 reject the request by the In such a case, the mentor peer MUST reject the request by the
initiating server and respond with a PEER_NAME_TABLE_RESPONSE message initiating server and respond with a PEER_NAME_TABLE_RESPONSE message
with the R flag set to '1', and with no pool entries included in the with the R flag set to '1', and with no pool entries 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 server, seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server,
or if there is a backup mentor peer available, select another mentor or if there is a backup mentor peer available, select another mentor
peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor
server. server.
A started namespace download session may get interrupted for some A started handlespace 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 every time it finishes sending a PEER_NAME_TABLE_REQUEST to its timer every time it finishes sending a PEER_NAME_TABLE_REQUEST to its
mentor peer. If this timer expires without receiving a response from mentor peer. If this timer expires without receiving a response from
the mentor peer, the initiating server SHOULD abort the current the mentor peer, the initiating server SHOULD abort the current
download session and re-start a new namespace download with a backup download session and re-start a new handlespace download with a
mentor peer, if one is available. backup 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 3.3 Handle PE Registration
To register itself with the namespace, a PE sends a REGISTRATION To register itself with the handlespace, 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 [1]. and rules of sending it are defined in [1].
In the REGISTRATION message, the PE indicates the name of the pool it In the REGISTRATION message, the PE indicates the name of the pool it
wishes to join in a pool handle parameter, and its complete transport wishes to join in a pool handle parameter, and its complete transport
information and any load control information in a PE parameter. information and any load control information in a PE parameter.
The ENRP server handles the REGISTRATION message according to the The ENRP server handles the REGISTRATION message according to the
following rules: following rules:
1. If the named pool does not exist in the namespace, the ENRP 1. If the named pool does not exist in the handlespace, the ENRP
server MUST creates a new pool with that name in the namespace server MUST creates a new pool with that name in the handlespace
and 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 When a new pool is created, the overall member selection policy
of the pool MUST be set to the policy type indicated by the first of the pool MUST be set to the policy type indicated by the first
PE, the overall pool transport type MUST be set to the transport PE, the overall pool transport type MUST be set to the transport
type indicated by the PE, and the overall pool data/control type indicated by the PE, and the overall pool data/control
channel configuration MUST be set to what is indicated in the channel configuration MUST be set to what is indicated in the
Transport Use field of the User Transport parameter by the Transport Use field of the User Transport parameter by the
registering PE. registering PE.
2. If the named pool already exists in the namespace, but the 2. If the named pool already exists in the handlespace, but the
requesting PE is not currently a member of the pool, the ENRP requesting PE is not currently a member of the pool, the ENRP
server will add the PE as a new member to the pool; server will add the PE as a new member to the pool;
However, before adding the PE to the pool, the server MUST check However, before adding the PE to the pool, the server MUST check
if the policy type, transport type, and transport usage indicated if the policy type, transport type, and transport usage indicated
by the registering PE is consistent with those of the pool. If by the registering PE is consistent with those of the pool. If
different, the ENRP server MUST either attempt to override the different, the ENRP server MUST either attempt to override the
PE's value(s) or to reject the registration if overriding is not PE's value(s) or to reject the registration if overriding is not
possible. possible.
skipping to change at page 26, line 32 skipping to change at page 25, line 32
registration. registration.
C. Inconsistent data/control configuration - If the overall pool C. Inconsistent data/control configuration - If the overall pool
configuration is "DATA ONLY", and the registering PE configuration is "DATA ONLY", and the registering PE
indicates "CONTORL plus DATA", the ENRP server SHOULD accept indicates "CONTORL plus DATA", the ENRP server SHOULD accept
the registration but warn the PE that control channel cannot the registration but warn the PE that control channel cannot
be used. If the pool configuration is "CONTROL plus DATA" be used. If the pool configuration is "CONTROL plus DATA"
and the PE indicates "DATA ONLY", the ENRP server MUST reject and the PE indicates "DATA ONLY", the ENRP server MUST reject
the registration. the registration.
3. If the named pool already exists in the namespace AND the 3. If the named pool already exists in the handlespace 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
MUST perform the same tests on policy, transport type, transport MUST perform the same tests on policy, transport type, transport
use, as described above. If the re-registration is accepted use, as described above. If the re-registration is accepted
after the test, the ENRP Server SHOULD replace the attributes of after the test, the ENRP Server SHOULD replace the attributes of
the existing PE with the information carried in the received the existing PE with the information carried in the received
REGISTRATION message. REGISTRATION message.
4. After accepting the registration, the ENRP server MUST assign 4. After accepting the registration, the ENRP server MUST assign
itself the owner of this PE. If this is a re-registration, the itself the owner of this PE. If this is a re-registration, the
skipping to change at page 27, line 28 skipping to change at page 26, line 28
re-registration case), the ENRP server MUST assign itself to be the re-registration case), the ENRP server MUST assign itself to be the
home ENRP server of the PE, i.e., to "own" the PE. home ENRP server of the PE, i.e., to "own" the PE.
Implementation note: for better performance, the ENRP server may Implementation note: for better performance, the ENRP server may
find it both efficient and convenient to internally maintain two find it both efficient and convenient to internally maintain two
separate PE lists or tables - one is for the PEs that are "owned" 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 by the ENRP server and the other for all the PEs owned by its
peer(s). peer(s).
Moreover, if the registration is granted, the ENRP server MUST take Moreover, if the registration is granted, the ENRP server MUST take
the namespace update action as described in Section 4.6 to inform its the handlespace update action as described in Section 3.6 to inform
peers about the change just made. If the registration is denied, no its peers about the change just made. If the registration is denied,
message will be sent to its peers. no message will be sent to its peers.
4.3.1 Rules on PE Re-registration 3.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 handlespace with a new set of
attributes in order to, for example, extend its registration life, attributes in order to, for example, extend its registration 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-registration. Based on the number of PEs in the pool and the re-registration. Based on the number of PEs in the pool and the
pool's overall policy type, this operation allows the PE to pool's overall policy type, this operation allows the PE to
dynamically control its share of inbound messages received by the dynamically control its share of inbound messages received by the
pool (also see Section ???? in [1] for more on load control). pool (also see 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 Regardless whether it is the current owner of the PE, if the
re-registration is granted to the PE, the ENRP server MUST assign re-registration is granted to the PE, the ENRP server MUST assign
itself to be the new home ENRP server of the PE. itself to be the new home ENRP server of the PE.
Moreover, if the re-registration is granted, the ENRP server MUST Moreover, if the re-registration is granted, the ENRP server MUST
take the namespace update action as described in Section 4.6 to take the handlespace update action as described in Section 3.6 to
inform its peers about the change just made. If the re-registration inform its peers about the change just made. If the re-registration
is denied, no message will be sent to its peers. is denied, no message will be sent to its peers.
4.4 Handle PE De-registration 3.4 Handle PE De-registration
To remove itself from a pool, a PE sends a DEREGISTRATION message to To remove itself from a pool, a PE sends a DEREGISTRATION message to
its home ENRP server. The complete format of DEREGISTRATION message its home ENRP server. The complete format of DEREGISTRATION message
and rules of sending it are defined in [1]. and rules of sending it are defined in [1].
In the DEREGISTRATION message the PE indicates the name of the pool In the DEREGISTRATION message the PE indicates the name of the 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
identifier. identifier.
Upon receiving the message, the ENRP server SHALL remove the PE from Upon receiving the message, the ENRP server SHALL remove the PE from
its namespace. Moreover, if the PE is the last one of the named its handlespace. Moreover, if the PE is the last one of the named
pool, the ENRP server will remove the pool from the namespace as pool, the ENRP server will remove the pool from the handlespace 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 handlespace, 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 DEREGISTRATION_RESPONSE In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE
message to the PE. If the de-registration is rejected, the ENRP message to the PE. If the de-registration is rejected, the ENRP
server MUST indicate the rejection by including the proper Operation server MUST indicate the rejection by including the proper Operation
Error parameter. Error parameter.
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 handlespace, the ENRP server MUST take the
namespace update action described in Section 4.6 to inform its peers handlespace update action described in Section 3.6 to inform its
about the change just made. Otherwise, NO message SHALL be send to peers about the change just made. Otherwise, NO message SHALL be
its peers. send to its peers.
4.5 Pool Handle Translation 3.5 Pool Handle Translation
A PU uses the pool handle translation service of an ENRP server to A PU uses the pool handle translation service of an ENRP server to
resolve a pool handle to a list of accessible transport addresses of resolve a pool handle to a list of accessible transport addresses of
the member PEs of the pool. the member PEs of the pool.
This requires the PU to send a NAME_RESOLUTION message to its home This requires the PU to send a NAME_RESOLUTION message to its home
ENRP server and in the NAME_RESOLUTION message specify the pool ENRP server and in the NAME_RESOLUTION message specify the pool
handle to be translated in a Pool Handle parameter. Complete handle to be translated in a Pool Handle parameter. Complete
definition of the NAME_RESOLUTION message and the rules of sending it definition of the NAME_RESOLUTION message and the rules of sending it
are defined in [1]. are defined in [1].
An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests
from PUs either over an SCTP association on the well-know SCTP port, from PUs either over an SCTP association on the well-know SCTP port,
or over a TCP connection on the well-know TCP 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 handlespace. 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. NAME_RESOLUTION_RESPONSE message to the requesting PU.
In the response message, the ENRP server SHOULD list all the PEs In the response message, the ENRP server SHOULD 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 round-robin pool, if the current pool member selection policy is not round-robin
(if the overall policy is round-Robin, this parameter MAY be (if the overall policy is round-Robin, this parameter 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 handlespace, 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 [1]. messages and the rules of receiving them are defined in [1].
4.6 Server Namespace Update 3.6 Server Handlespace 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., addition inform its peers when its local handlespace is modified, e.g.,
of a new PE, removal of an existing PE, change of pool or PE addition of a new PE, removal of an existing PE, change of pool or PE
properties. properties.
4.6.1 Announcing Addition or Update of PE 3.6.1 Announcing Addition or Update of PE
When a new PE is granted registration to the namespace or an existing When a new PE is granted registration to the handlespace or an
PE is granted a re-registration, the home ENRP server uses this existing PE is granted a re-registration, the home ENRP server uses
procedure to inform all its peers. this procedure to inform all its peers.
This is an ENRP announcement and is sent to all the peer of the home This is an ENRP announcement and is sent to all the peer of the home
ENRP server. See Section 4.1 on how announcements are sent. ENRP server. See Section 3.1 on how announcements 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 ADD_PE, PEER_NAME_UPDATE message with the Update Action field set to ADD_PE,
indicating the addition of a new PE or the modification of an indicating the addition of a new PE or the modification of an
existing PE. The complete new information of the PE and the pool its existing PE. The complete new information of the PE and the pool its
belongs to MUST be indicated in the message with a PE parameter and a belongs to MUST be indicated in the message with a PE parameter 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., all Server's ID field and leave the Receiver Server's ID blank (i.e., all
0's). 0's).
When a peer receives this PEER_NAME_UPDATE message, it MUST take the When a peer receives this PEER_NAME_UPDATE message, it MUST take the
following actions: following actions:
1. If the named pool indicated by the pool handle does not exist in 1. If the named pool indicated by the pool handle does not exist in
its local copy of the namespace, the peer MUST create the named its local copy of the handlespace, the peer MUST create the named
pool in its local namespace and add the PE to the pool as the pool in its local handlespace and add the PE to the pool as the
first PE. It MUST then copy in all other attributes of the PE first PE. It MUST then copy in all other attributes of the PE
carried 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 the 2. If the named pool already exists in the peer's local copy of the
namespace AND the PE does not exist, the peer MUST add the PE to handlespace AND the PE does not exist, the peer MUST add the PE
the pool as a new PE and copy in all attributes of the PE carried to the pool as a new PE and copy in all attributes of the PE
in the message. carried in the message.
3. If the named pool exists AND the PE is already a member of the 3. If the named pool exists AND the PE is already a member of the
pool, 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 3.6.2 Announcing Removal of PE
When an existing PE is granted de-registration or is removed from its When an existing PE is granted de-registration or is removed from its
namespace for some other reasons (e.g., purging an unreachable PE, handlespace for some other reasons (e.g., purging an unreachable PE,
see Section 4.7), the ENRP server MUST uses this procedure to inform see Section 3.7), the ENRP server MUST uses this procedure to inform
all its 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 home This is an ENRP announcement and is sent to all the peer of the home
ENRP server. See Section 4.1 on how announcements are sent. ENRP server. See Section 3.1 on how announcements 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 DEL_PE, PEER_NAME_UPDATE message with the Update Action field set to DEL_PE,
indicating the removal of an existing PE. The complete information indicating the removal of an existing PE. The complete information
of the PE and the pool its belongs to MUST be indicated in the of the PE and the pool its belongs to MUST be indicated 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 Server's The sending server MUST fill in its server ID in the Sender Server's
ID field and leave the Receiver Server's ID blank (i.e., set to all ID field and leave the Receiver Server's ID blank (i.e., 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 handlespace, and then remove the PE
from its local namespace. If the removed PE is the last one in the from its local handlespace. 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 handlespace.
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 handlespace, it
SHOULD take no further actions. SHOULD take no further actions.
4.7 Detecting and Removing Unreachable PE 3.7 Detecting and Removing Unreachable PE
Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE
Notification, see section 10.2 of [7]), the PU SHOULD send an Notification, see section 10.2 of [7]), the PU SHOULD send an
ENDPOINT_UNREACHABLE message to its home ENRP server. The message ENDPOINT_UNREACHABLE message to its home ENRP server. The message
SHOULD contain the pool handle and the PE Id of the unreachable PE. SHOULD contain the pool handle and the PE Id of the unreachable PE.
Upon the reception of an ENDPOINT_UNREACHABLE message, a server MUST Upon the reception of an ENDPOINT_UNREACHABLE message, a server MUST
immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the
PE in question. If this ENDPOINT_KEEP_ALIVE fails (e.g., it results PE in question. If this ENDPOINT_KEEP_ALIVE fails (e.g., it results
in an SCTP SEND.FAILURE notification), the ENRP server MUST consider in an SCTP SEND.FAILURE notification), the ENRP server MUST consider
the PE as truly unreachable and MUST remove the PE from its namespace the PE as truly unreachable and MUST remove the PE from its
and take actions described in Section 4.6.2. handlespace and take actions described in Section 3.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 handlespace.
Moreover, the server SHOULD keep a counter to record how many Moreover, the server SHOULD keep a counter to record how many
ENDPOINT_UNREACHABLE messages it has received reporting reachability ENDPOINT_UNREACHABLE messages it has received reporting reachability
problem relating to this PE. If the counter exceeds the protocol problem relating to this PE. If the counter exceeds the protocol
threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE
from its namespace and take actions described in Section 4.6.2. from its handlespace and take actions described in Section 3.6.2.
Optionally, an ENRP server may also periodically send point-to-point Optionally, an ENRP server may also periodically send point-to-point
ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP 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 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 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 PE as unreachable and MUST remove the PE from its handlespace and
actions described in Section 4.6.2. Note, if an ENRP server owns a take actions described in Section 3.6.2. Note, if an ENRP server
large number of PEs, the implementation should pay attention not to owns a large number of PEs, the implementation should pay attention
flood the network with bursts of ENDPOINT_KEEP_ALIVE messages. not to flood the network with bursts of ENDPOINT_KEEP_ALIVE messages.
Instead, the implementation should try to smooth out the Instead, the implementation should try to smooth out the
ENDPOINT_KEEP_ALIVE message traffic over time. ENDPOINT_KEEP_ALIVE message traffic over time.
The complete definition and rules of sending ENDPOINT_UNREACHABLE and The complete definition and rules of sending ENDPOINT_UNREACHABLE and
receiving ENDPOINT_KEEP_ALIVE messages are described in [1]. receiving ENDPOINT_KEEP_ALIVE messages are described in [1].
4.8 Helping PE and PU to Discover Home ENRP Server 3.8 Helping PE and PU to Discover Home ENRP Server
At its startup time, or whenever its current home ENRP server is not At its startup time, or whenever its current home ENRP server is not
providing services, a PE or PU will attempt to find a new home providing services, a PE or PU will attempt to find a new home
server. For this reason, the PE or PU will need to maintain a list server. For this reason, the PE or PU will need to maintain a list
of currently available ENRP servers in its scope. of currently available ENRP servers in its scope.
To help the PE or PU maintaining this list, an ENRP server, if it is To help the PE or PU maintaining this list, an ENRP server, if it is
enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE
message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP
multicast channel. And in the SERVER_ANNOUNE message the ENRP server multicast channel. And in the SERVER_ANNOUNE message the ENRP server
SHOULD include all the transport addresses available for ASAP SHOULD include all the transport addresses available for ASAP
communications. If the ENRP server only supports SCTP for ASAP communications. If the ENRP server only supports SCTP for ASAP
communications, the transport information MAY be omitted in the communications, the transport information MAY be omitted in the
SERVER_ANNOUNCE message. SERVER_ANNOUNCE message.
For the complete procedure of this, see Section 3.6?? in [1]. For the complete procedure of this, see Section 3.6?? in [1].
4.9 Maintaining Peer List and Monitoring Peer Status 3.9 Maintaining Peer List and Monitoring Peer Status
An ENRP server MUST keep an internal record on the status of each of An ENRP server MUST keep an internal record on the status of each of
its known peers. This record is referred to as the server's "peer its known peers. This record is referred to as the server's "peer
list" list"
4.9.1 Discovering New Peer 3.9.1 Discovering New Peer
If a message of any type is received from a previously unknown peer, If a message of any type is received from a previously unknown peer,
the ENRP server MUST consider this peer a new peer in the operation the ENRP server MUST consider this peer a new peer in the operation
scope and add it to the peer list. scope and add it to the peer list.
The ENRP server MUST send a PEER_PRESENCE message with the The ENRP server MUST send a PEER_PRESENCE message with the
Reply-required flag set to '1' to the source address found in the Reply-required flag set to '1' to the source address found in the
arrived message. This will force the new peer to reply with its own arrived message. This will force the new peer to reply with its own
PEER_PRESENCE containing its full server information (see Section PEER_PRESENCE containing its full server information (see Section
3.1). 2.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 split networks.] this may help mending two split networks.]
4.9.2 Server Sending Heartbeat 3.9.2 Server Sending Heartbeat
Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its
continued presence to all its peer with a PEER_PRESENCE message. In continued presence to all its peer with a PEER_PRESENCE 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 its The arrival of this periodic PEER_PRESENCE message will cause all its
peers to update their internal variable "peer.last.heard" for the peers to update their internal variable "peer.last.heard" for the
sending server (see Section 4.9.3 for more details). sending server (see Section 3.9.3 for more details).
4.9.3 Detecting Peer Server Failure 3.9.3 Detecting Peer Server Failure
An ENRP server MUST keep an internal variable "peer.last.heard" for An ENRP server MUST keep an internal variable "peer.last.heard" 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 every time a message of any type updated to the current local time every time a message of any type
(point-to-point or announcement) is received from the corresponding (point-to-point or announcement) is received from the corresponding
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-RESPONSE seconds, the ENRP server MUST consider the peer MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer
server dead and SHOULD initiate the takeover procedure defined in server dead and SHOULD initiate the takeover procedure defined in
Section 4.10. Section 3.10.
4.10 Taking-over a Failed Peer Server 3.10 Taking-over a Failed Peer Server
In the following descriptions, We call the ENRP server that detects In the following descriptions, We call the ENRP server that detects
the failed peer server and initiates the take-over the "initiating the failed peer server and initiates the take-over the "initiating
server" and the failed peer server the "target server." server" and the failed peer server the "target server."
4.10.1 Initiate Server Take-over Arbitration 3.10.1 Initiate Server Take-over Arbitration
The initiating server SHOULD first start a take-over arbitration The initiating server SHOULD first start a take-over arbitration
process by announcing a PEER_INIT_TAKEOVER message to all its peer process by announcing a PEER_INIT_TAKEOVER message to all its peer
servers. See Section 4.1 on how announcements are sent. In the servers. See Section 3.1 on how announcements are sent. In the
message, the initiating server MUST fill in the Sender Server's ID message, the initiating server MUST fill in the Sender Server's ID
and Target Server's ID. and Target Server's ID.
After announcing the PEER_INIT_TAKEOVER message, the initiating After announcing the PEER_INIT_TAKEOVER message, the initiating
server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_ 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 of its known peers, except of the target server. [editor's note: how
long should it wait?] long should it wait?]
Each of the peer servers that receives the PEER_INIT_TAKEOVER message Each of the peer servers that receives the PEER_INIT_TAKEOVER message
from the initiating server SHOULD take the following actions: from the initiating server SHOULD take the following actions:
skipping to change at page 34, line 30 skipping to change at page 33, line 30
3. If the peer finds that it is neither the target server nor is in 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 its own take-over process, the peer SHOULD: a) mark the target
server as "not active" on its internal peer list so that its 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 status will no longer be monitored by this peer, and b) reply to
the initiating server with a PEER_INIT_TAKEOVER_ACK message. the initiating server with a PEER_INIT_TAKEOVER_ACK message.
Once the initiating server has received PEER_INIT_TAKEOVER_ACK Once the initiating server has received PEER_INIT_TAKEOVER_ACK
message from _all_ of its currently known peers (except for the message from _all_ of its currently known peers (except for the
target server), it SHOULD consider that it has won the arbitration target server), it SHOULD consider that it has won the arbitration
and SHOULD proceed to complete the take-over, following the steps and SHOULD proceed to complete the take-over, following the steps
described in Section 4.10.2. described in Section 3.10.2.
However, if it receives a PEER_PRESENCE from the target server at any However, if it receives a PEER_PRESENCE from the target server at any
point in the arbitration process, the initiating server SHOULD point in the arbitration process, the initiating server SHOULD
immediately abort the take-over process and mark the status of the immediately abort the take-over process and mark the status of the
target server as "active". target server as "active".
4.10.2 Take-over Target Peer Server 3.10.2 Take-over Target Peer Server
The initiating ENRP server SHOULD first send, via an announcement, a The initiating ENRP server SHOULD first send, via an announcement, a
PEER_TAKEOVER_SERVER message to inform all its active peers that the 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 take-over is enforced. The target server's ID MUST be filled in the
message. The initiating server SHOULD then remove the target server message. The initiating server SHOULD then remove the target server
from its internal peer list. from its internal peer list.
[editor's note: peers should remove the target server from their 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 upon receiving this message. Do we really need this message? we can
consolidate this with the ownership_change msg.] consolidate this with the ownership_change msg.]
Then it SHOULD examine its local copy of the namespace and claim Then it SHOULD examine its local copy of the handlespace and claim
ownership of each of the PEs originally owned by the target server, ownership of each of the PEs originally owned by the target server,
by following these steps: by following these steps:
1. mark itself as the home ENRP server of each of the PEs originally 1. mark itself as the home ENRP server of each of the PEs originally
owned by the target server; owned by the target server;
2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the 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 PEs. This will trigger the PE to adopt the initiating sever as
its new home ENRP server; its new home ENRP server;
3. after claiming the ownership of all the PEs originally owned by 3. after claiming the ownership of all the PEs originally owned by
the target server, announce the ownership changes of all the the target server, announce the ownership changes of all the
affected PEs in a PEER_OWNERSHIP_CHANGE message to all the affected PEs in a PEER_OWNERSHIP_CHANGE message to all the
currently known peers. Note, if the list of affected PEs is currently known peers. Note, if the list of affected PEs is
long, the sender MAY announce the ownership changes in multiple long, the sender MAY announce the ownership changes in multiple
PEER_OWNERSHIP_CHANGE messages. PEER_OWNERSHIP_CHANGE messages.
When a peer receives the PEER_OWNERSHIP_CHANGE message from the When a peer receives the PEER_OWNERSHIP_CHANGE message from the
initiating server, it SHOULD find each of the reported PEs in its 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 local copy of the handlespace and update the PE's home ENRP server to
be the sender of the message (i.e., the initiating server). be the sender of the message (i.e., the initiating server).
4.11 Namespace Data Auditing and Re-synchronization 3.11 Handlespace Data Auditing and Re-synchronization
Message losses or certain temporary breaks in network connectivity Message losses or certain temporary breaks in network connectivity
may result in data inconsistency in the local namespace copy of some may result in data inconsistency in the local handlespace copy of
of the ENRP servers in an operation scope. Therefore, each ENRP some of the ENRP servers in an operation scope. Therefore, each ENRP
server in the operation scope SHOULD periodically verify that its server in the operation scope SHOULD periodically verify that its
local copy of namespace data is still in sync with that of its peers. local copy of handlespace data is still in sync with that of its
peers.
This section defines the auditing and re-synchronization procedures This section defines the auditing and re-synchronization procedures
for an ENRP server to maintain its namespace data consistency. for an ENRP server to maintain its handlespace data consistency.
4.11.1 Auditing Procedures 3.11.1 Auditing Procedures
The auditing of namespace consistency is based on the following The auditing of handlespace consistency is based on the following
procedures: procedures:
1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit
integer internal variable) for each of its known peers and for integer internal variable) for each of its known peers and for
itself. For an ENRP server with 'k' known peers, we denote these itself. For an ENRP server with 'k' known peers, we denote these
internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ..., internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ...,
"pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE "pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE
checksum. The definition and detailed algorithm for calculating checksum. The definition and detailed algorithm for calculating
these PE checksum variables are given in Section 4.11.2. these PE checksum variables are given in Section 3.11.2.
2. Each time an ENRP server sends out a PEER_PRESENCE, it SHOULD 2. Each time an ENRP server sends out a PEER_PRESENCE, it SHOULD
include in the message its current PE checksum (i.e., include in the message its current PE checksum (i.e.,
"pe.checksum.pr0"). "pe.checksum.pr0").
3. When an ENRP server (server A) receives a PE checksum (carried in 3. When an ENRP server (server A) receives a PE checksum (carried in
an arrived PEER_PRESENCE) from a peer ENRP server (server B), an arrived PEER_PRESENCE) from a peer ENRP server (server B),
server A SHOULD compare the PE checksum found in the server A SHOULD compare the PE checksum found in the
PEER_PRESENCE with its own internal PE checksum of server B PEER_PRESENCE with its own internal PE checksum of server B
(i.e., "pe.checksum.prB"). (i.e., "pe.checksum.prB").
4. If the two values match, server A will consider that there is no 4. If the two values match, server A will consider that there is no
namespace inconsistency between itself and server B and should handlespace inconsistency between itself and server B and should
take no further actions. take no further actions.
5. If the two values do NOT match, server A SHOULD consider that 5. If the two values do NOT match, server A SHOULD consider that
there is a namespace inconsistency between itself and server B there is a handlespace inconsistency between itself and server B
and a re-synchronization process SHOULD be carried out and a re-synchronization process SHOULD be carried out
immediately with server B (see Section 4.11.3). immediately with server B (see Section 3.11.3).
4.11.2 PE Checksum Calculation Algorithm 3.11.2 PE Checksum Calculation Algorithm
When an ENRP server (server A) calculate an internal PE checksum for When an ENRP server (server A) calculate an internal PE checksum for
a peer (server B), it MUST use the following algorithm. a peer (server B), it MUST use the following algorithm.
Let us assume that in server A's internal namespace there are Let us assume that in server A's internal handlespace there are
currently 'M' PEs that are owned by server B. Each of the 'M' PEs currently 'M' PEs that are owned by server B. Each of the 'M' PEs
will then contribute to the checksum calculation with the following will then contribute to the checksum calculation with the following
byte block: byte block:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle string of the pool the PE belongs (padded with : : Pool handle string of the pool the PE belongs (padded with :
: zeros to next 32-bit word boundary if needed) : : zeros to next 32-bit word boundary if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 36, line 46 skipping to change at page 35, line 48
Note, these are not TLVs. This byte block gives each PE a unique Note, these are not TLVs. This byte block gives each PE a unique
byte pattern in the scope. The 32-bit PE checksum for server B byte pattern in the scope. The 32-bit PE checksum for server B
"pe.checksum.prB" is then calculated over the byte blocks contributed "pe.checksum.prB" is then calculated over the byte blocks contributed
by the 'M' PEs one by one. by the 'M' PEs one by one.
Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0")
in the same fashion, using the byte blocks of all the PEs owned by in the same fashion, using the byte blocks of all the PEs owned by
itself. itself.
Note, whenever an ENRP finds that its internal namespace has changed Note, whenever an ENRP finds that its internal handlespace has
(e.g., due to PE registration/deregistration, receiving peer updates, changed (e.g., due to PE registration/deregistration, receiving peer
removing failed PEs, downloading namespace pieces from a peer, etc.), updates, removing failed PEs, downloading handlespace pieces from a
it MUST immediately update all its internal PE checksums that are peer, etc.), it MUST immediately update all its internal PE checksums
affected by the change. that are affected by the change.
Implementation Note: when the internal namespace changes (e.g., a new Implementation Note: when the internal handlespace changes (e.g., a
PE added or an existing PE removed), an implementation needs not to new PE added or an existing PE removed), an implementation needs not
re-calculate the affected PE checksum; it should instead simply to re-calculate the affected PE checksum; it should instead simply
update the checksum by adding or subtracting the byte block of the update the checksum by adding or subtracting the byte block of the
corresponding PE from the previous checksum value. corresponding PE from the previous checksum value.
4.11.3 Re-synchronization Procedures 3.11.3 Re-synchronization Procedures
Once an ENRP server determines that there is inconsistency between Once an ENRP server determines that there is inconsistency between
its local namespace data and a peer's namespace data with regarding its local handlespace data and a peer's handlespace data with
to the PEs owned by that peer, it SHOULD perform the following steps regarding to the PEs owned by that peer, it SHOULD perform the
to re-synchronize the data: following steps to re-synchronize the data:
1. The ENRP server SHOULD first "mark" every PE it knows about that 1. The ENRP server SHOULD first "mark" every PE it knows about that
is owned by the peer in its local namespace database; is owned by the peer in its local handlespace database;
2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST 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 message with W flag set to '1' to the peer to request a complete
list of PEs owned by the peer; list of PEs owned by the peer;
3. Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag 3. Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag
set to '1', the peer server SHOULD immediately respond with a set to '1', the peer server SHOULD immediately respond with a
PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned
by the peer. by the peer.
4. Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP 4. Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP
server SHOULD transfer the PE entries carried in the message into server SHOULD transfer the PE entries carried in the message into
its local namespace database. If an PE entry being transferred its local handlespace database. If an PE entry being transferred
already exists in its local database, the ENRP server MUST already exists in its local database, the ENRP server MUST
replace the entry with the copy found in the message and remove replace the entry with the copy found in the message and remove
the "mark" from the entry. the "mark" from the entry.
5. After transferring all the PE entries from the received 5. After transferring all the PE entries from the received
PEER_NAME_TABLE_RESPONSE message into its local database, the PEER_NAME_TABLE_RESPONSE message into its local database, the
ENRP server SHOULD check whether there are still PE entries that ENRP server SHOULD check whether there are still PE entries that
remain "marked" in its local namespace. If so, the ENRP server remain "marked" in its local handlespace. If so, the ENRP server
SHOULD silently remove those "marked" entries. SHOULD silently remove those "marked" entries.
Note, similar to what is described in Section 4.2.3, the peer may Note, similar to what is described in Section 3.2.3, the peer may
reject the PEER_NAME_TABLE_REQUEST or use more than one reject the PEER_NAME_TABLE_REQUEST or use more than one
PEER_NAME_TABLE_RESPONSE message to respond. PEER_NAME_TABLE_RESPONSE message to respond.
4.12 Handling Unrecognized Message or Unrecognized Parameter 3.12 Handling Unrecognized Message or Unrecognized Parameter
When an ENRP server receives an ENRP message with an unknown message When an ENRP server receives an ENRP message with an unknown message
type or a message of known type that contains an unknown parameter, type or a message of known type that contains an unknown parameter,
it SHOULD handle the unknown message or the unknown parameter it SHOULD handle the unknown message or the unknown parameter
according to the unrecognized message and parameter handling rules according to the unrecognized message and parameter handling rules
defined in Sections 3 and 4 in [10]. defined in Sections 3 and 4 in [10].
According to the rules, if an error report to the message sender is 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 needed, the ENRP server that discovered the error SHOULD send back an
ENRP_ERROR message with proper error cause code. ENRP_ERROR message with proper error cause code.
5. Variables and Thresholds 4. Variables and Thresholds
5.1 Variables 4.1 Variables
peer.last.heard - the local time that a peer server was last heard peer.last.heard - the local time that a peer server was last heard
(via receiving either a multicast or point-to-point message from (via receiving either a multicast or point-to-point message from
the peer). the peer).
pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server
keeps for a peer. A separate PE checksum is kept for each of its keeps for a peer. A separate PE checksum is kept for each of its
known peers as well as for itself. known peers as well as for itself.
5.2 Thresholds 4.2 Thresholds
MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will
make to contact an ENRP server (Default=3 times). make to contact an ENRP server (Default=3 times).
TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will
wait for a response from an ENRP server (Default=5 seconds). wait for a response from an ENRP server (Default=5 seconds).
PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a
heartbeat message to all its known peers. (Default=30 secs.) heartbeat message to all its known peers. (Default=30 secs.)
skipping to change at page 39, line 41 skipping to change at page 38, line 41
MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server
will wait before considering a silent peer server potentially will wait before considering a silent peer server potentially
dead. (Default=61 secs.) dead. (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 sending out a message. sender will wait for a response after sending out a message.
(Default=5 secs.) (Default=5 secs.)
MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a
PE that an ENRP server will allow before purging this PE from the PE that an ENRP server will allow before purging this PE from the
namespace. (Default=3) handlespace. (Default=3)
6. Security Considerations 5. Security Considerations
Threats Introduced by Rserpool and Requirements for Security in Threats Introduced by Rserpool and Requirements for Security in
Response to Threats [11] describes the threats to the Rserpool Response to Threats [11] describes the threats to the Rserpool
architecture in detail and lists the security requirements in architecture in detail and lists the security requirements in
response to each threat. From the threats described in this response to each threat. From the threats described in this
document, the security services required for the Rserpool protocol document, the security services required for the Rserpool protocol
are enumerated below. are enumerated below.
Threat 1) PE registration/deregistration flooding or spoofing Threat 1) PE registration/deregistration flooding or spoofing
----------- -----------
skipping to change at page 40, line 45 skipping to change at page 39, line 45
----------- -----------
Security mechanism in response: Security protocol which has Security mechanism in response: Security protocol which has
protection from replay attacks protection from replay attacks
Threat 6) Corrupted data which causes a PU to have misinformation Threat 6) Corrupted data which causes a PU to have misinformation
concerning a pool handle resolution concerning a pool handle resolution
----------- -----------
Security mechanism in response: Security protocol which supports Security mechanism in response: Security protocol which supports
integrity protection integrity protection
Threat 7) Eavesdropper snooping on namespace information Threat 7) Eavesdropper snooping on handlespace information
----------- -----------
Security mechanism in response: Security protocol which supports data Security mechanism in response: Security protocol which supports data
confidentiality confidentiality
Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP
server server
----------- -----------
Security mechanism in response: ASAP must control the number of Security mechanism in response: ASAP must control the number of
endpoint unreachable messages transmitted from the PU to the ENRP endpoint unreachable messages transmitted from the PU to the ENRP
server. server.
skipping to change at page 41, line 41 skipping to change at page 40, line 41
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other ciphersuite. other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
Endpoint_Unreachable messages (see Section 3.5??? in [1]) to the ENRP Endpoint_Unreachable messages (see Section 3.5??? in [1]) to the ENRP
server. server.
Threat 9 requires the ENRP protocol to limit the number of Threat 9 requires the ENRP protocol to limit the number of
Endpoint_KeepAlive messages to the PE (see Section x.y???). Endpoint_KeepAlive messages to the PE (see Section x.y???).
6.1 Implementing Security Mechanisms 5.1 Implementing Security Mechanisms
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication. ENRP servers must support mutual support mutual authentication. ENRP servers must support mutual
authentication among themselves. PUs MUST authenticate ENRP servers. authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname. PUs MAY have certificates corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use. All Rserpool elements are set forth in this document for their use. All Rserpool elements
that support TLS MUST have a mechanism for validating certificates that support TLS MUST have a mechanism for validating certificates
skipping to change at page 43, line 5 skipping to change at page 42, line 5
issue root certificates for web browsers). issue root certificates for web browsers).
Implementations MUST support TLS with SCTP as described in RFC3436 Implementations MUST support TLS with SCTP as described in RFC3436
[8] or TLS over TCP as described in RFC2246 [6]. When using TLS/SCTP [8] or TLS over TCP as described in RFC2246 [6]. When using TLS/SCTP
we must ensure that RSerPool does not use any features of SCTP that we must ensure that RSerPool does not use any features of SCTP that
are not available to an TLS/SCTP user. This is not a difficult are not available to an TLS/SCTP user. This is not a difficult
technical problem, but simply a requirement. When describing an API technical problem, but simply a requirement. When describing an API
of the RSerPool lower layer we have also to take into account the of the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP. differences between TLS and SCTP.
7. Acknowledgements 6. Acknowledgements
The authors wish to thank John Loughney, Lyndon Ong, and many others The authors wish to thank John Loughney, Lyndon Ong, and many others
for their invaluable comments. for their invaluable comments.
8. References 7. References
8.1 Normative References 7.1 Normative References
[1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-09 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-10
(work in progress), June 2004. (work in progress), June 2004.
[2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
J. and M. Stillman, "Requirements for Reliable Server Pooling", J. and M. Stillman, "Requirements for Reliable Server Pooling",
RFC 3237, January 2002. RFC 3237, January 2002.
[3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney,
"Architecture for Reliable Server Pooling", "Architecture for Reliable Server Pooling",
draft-ietf-rserpool-arch-07 (work in progress), October 2003. draft-ietf-rserpool-arch-07 (work in progress), October 2003.
skipping to change at page 44, line 44 skipping to change at page 43, line 44
[8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC
3436, December 2002. 3436, December 2002.
[9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On [9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On
the Use of Stream Control Transmission Protocol (SCTP) with the Use of Stream Control Transmission Protocol (SCTP) with
IPsec", RFC 3554, July 2003. IPsec", RFC 3554, July 2003.
[10] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [10] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol (ASAP) and Endpoint Name Resolution Server Access Protocol (ASAP) and Endpoint Name Resolution
(ENRP) common parameters document", (ENRP) common parameters document",
draft-ietf-rserpool-common-param-06 (work in progress), June draft-ietf-rserpool-common-param-07 (work in progress), October
2004. 2004.
[11] Stillman, M., "Threats Introduced by Rserpool and Requirements [11] Stillman, M., "Threats Introduced by Rserpool and Requirements
for Security in Response to Threats", for Security in Response to Threats",
draft-ietf-rserpool-threats-02 (work in progress), Sept 2003. draft-ietf-rserpool-threats-03 (work in progress), July 2004
8.2 Informative References 7.2 Informative References
[12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
Authors' Addresses Authors' Addresses
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, 2-F9 1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004 Arlington Heights, IL 60004
US US
Phone: +1-847-632-3028 Phone:
EMail: qxie1@email.mot.com EMail: qxie1@email.mot.com
Randall R. Stewart Randall R. Stewart
Cisco Cisco Systems, Inc.
24 Burning Bush Trail 4875 Forest Drive
Crystal Lake, IL 60012 Suite 200
US Columbia, SC 29206
USA
Phone: +1-815-477-2127 Phone:
EMail: rrs@cisco.com EMail: rrs@cisco.com
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
US US
Phone: +1 607 273 0724 62 Phone:
EMail: maureen.stillman@nokia.com EMail: maureen.stillman@nokia.com
Michael Tuexen
Germany
Phone:
EMail: tuexen@fh-muenster.de
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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