draft-ietf-rserpool-enrp-15.txt   draft-ietf-rserpool-enrp-16.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Intended status: Experimental R. Stewart Intended status: Experimental R. Stewart
Expires: July 8, 2007 Cisco Systems, Inc. Expires: January 10, 2008 Cisco Systems, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
A. Silverton A. Silverton
Motorola, Inc. Motorola, Inc.
January 4, 2007 July 9, 2007
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-15.txt draft-ietf-rserpool-enrp-16.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 July 8, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to
in conjunction with the Aggregate Server Access Protocol (ASAP) to work in conjunction with the Aggregate Server Access Protocol (ASAP)
accomplish the functionality of the Reliable Server Pooling to 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
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . . 6 2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . . 6
2.1. ENRP_PRESENCE message . . . . . . . . . . . . . . . . . . 6 2.1. ENRP_PRESENCE message . . . . . . . . . . . . . . . . . . 6
2.2. ENRP_HANDLE_TABLE_REQUEST message . . . . . . . . . . . . 8 2.2. ENRP_HANDLE_TABLE_REQUEST message . . . . . . . . . . . . 8
2.3. ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . . 8 2.3. ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . . 8
2.4. ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10 2.4. ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10
2.5. ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 11 2.5. ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 12
2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12 2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13
2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13 2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14
2.8. ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 2.8. ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14
2.9. ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 14 2.9. ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15
2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 15 2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 16
3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . . 17 3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . . 17
3.1. Methods for Communicating amongst ENRP Servers . . . . . . 17 3.1. Methods for Communicating amongst ENRP Servers . . . . . . 17
3.2. ENRP Server Initialization . . . . . . . . . . . . . . . . 18 3.2. ENRP Server Initialization . . . . . . . . . . . . . . . . 18
3.2.1. Generate a Server Identifier . . . . . . . . . . . . . 19 3.2.1. Generate a Server Identifier . . . . . . . . . . . . . 18
3.2.2. Acquire Peer Server List . . . . . . . . . . . . . . . 19 3.2.2. Acquire Peer Server List . . . . . . . . . . . . . . . 19
3.2.3. Download ENRP Handlespace Data from Mentor Peer . . . 21 3.2.3. Download ENRP Handlespace Data from Mentor Peer . . . 21
3.3. Handle PE Registration . . . . . . . . . . . . . . . . . . 23 3.3. Handle PE Registration . . . . . . . . . . . . . . . . . . 23
3.3.1. Rules on PE Re-registration . . . . . . . . . . . . . 25 3.3.1. Rules on PE Re-registration . . . . . . . . . . . . . 24
3.4. Handle PE De-registration . . . . . . . . . . . . . . . . 25 3.4. Handle PE De-registration . . . . . . . . . . . . . . . . 25
3.5. Pool Handle Translation . . . . . . . . . . . . . . . . . 26 3.5. Pool Handle Translation . . . . . . . . . . . . . . . . . 26
3.6. Server Handlespace Update . . . . . . . . . . . . . . . . 27 3.6. Server Handlespace Update . . . . . . . . . . . . . . . . 27
3.6.1. Announcing Addition or Update of PE . . . . . . . . . 27 3.6.1. Announcing Addition or Update of PE . . . . . . . . . 27
3.6.2. Announcing Removal of PE . . . . . . . . . . . . . . . 28 3.6.2. Announcing Removal of PE . . . . . . . . . . . . . . . 28
3.7. Detecting and Removing Unreachable PE . . . . . . . . . . 28 3.7. Detecting and Removing Unreachable PE . . . . . . . . . . 28
3.8. Helping PE and PU to Discover Home ENRP Server . . . . . . 29 3.8. Helping PE and PU to Discover Home ENRP Server . . . . . . 29
3.9. Maintaining Peer List and Monitoring Peer Status . . . . . 30 3.9. Maintaining Peer List and Monitoring Peer Status . . . . . 29
3.9.1. Discovering New Peer . . . . . . . . . . . . . . . . . 30 3.9.1. Discovering New Peer . . . . . . . . . . . . . . . . . 30
3.9.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 30 3.9.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 30
3.9.3. Detecting Peer Server Failure . . . . . . . . . . . . 30 3.9.3. Detecting Peer Server Failure . . . . . . . . . . . . 30
3.10. Taking-over a Failed Peer Server . . . . . . . . . . . . . 31 3.10. Taking-over a Failed Peer Server . . . . . . . . . . . . . 30
3.10.1. Initiate Server Take-over Arbitration . . . . . . . . 31 3.10.1. Initiating Server Take-over Arbitration . . . . . . . 31
3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32 3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32
3.11. Handlespace Data Auditing and Re-synchronization . . . . . 33 3.11. Handlespace Data Auditing and Re-synchronization . . . . . 32
3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33 3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33
3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 34 3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 33
3.11.3. Re-synchronization Procedures . . . . . . . . . . . . 34 3.11.3. Re-synchronization Procedures . . . . . . . . . . . . 34
3.12. Handling Unrecognized Message or Unrecognized Parameter . 35 3.12. Handling Unrecognized Message or Unrecognized Parameter . 35
4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36
4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 37 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
5.1. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 38 5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 37
5.2. Implementing Security Mechanisms . . . . . . . . . . . . . 39 5.2. A New Table for Update Action Types . . . . . . . . . . . 37
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 5.3. Multicast Addresses . . . . . . . . . . . . . . . . . . . 38
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39
7.1. Normative References . . . . . . . . . . . . . . . . . . . 42 6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 39
7.2. Informative References . . . . . . . . . . . . . . . . . . 43 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 46 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1. Normative References . . . . . . . . . . . . . . . . . . . 44
8.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 48
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 operational scope of Rserpool, ENRP defines the procedures Within the operational 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 handlespace, or simply this RSerPool registry service as ENRP handlespace, or simply
handlespace. handlespace because it manages all pool handles.
1.1. Definitions 1.1. Definitions
This document uses the following terms: This document uses the following terms:
Operational scope: See [3]; Operational scope: See [3];
Pool (or server pool): See [3]; Pool (or server pool): See [3];
Pool handle: See [3]; Pool handle: See [3];
skipping to change at page 4, line 41 skipping to change at page 4, line 41
Pool user (PU): See [3]; Pool user (PU): See [3];
Pool element handle: See [3]; Pool element handle: See [3];
ENRP handlespace (or handlespace): See [3]; ENRP handlespace (or handlespace): See [3];
ENRP client channel: The communication channel through which an ASAP ENRP client channel: The communication channel through which an ASAP
User (either a PE or PU) requests ENRP handlespace service. The User (either a PE or PU) requests ENRP handlespace service. The
client channel is usually defined by the transport address of the client channel is usually defined by the transport address of the
home server and a well known port number. The channel MAY make home server and a well-known port number. The channel MAY make
use of multi-cast or a named list of ENRP servers. use of multi-cast or a named list of ENRP servers.
ENRP server channel: Defined by a well known multicast IP address ENRP server channel: Defined by a well-known multicast IP address
and a well known port number. All ENRP servers in an operational and a well known port number. All ENRP servers in an operational
scope can send multicast messages to other servers through this scope can send multicast messages to other servers through this
channel. PEs are also allowed to multicast on this channel channel. PEs are also allowed to multicast on this channel
occasionally; occasionally;
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
skipping to change at page 6, line 7 skipping to change at page 6, line 7
1.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
[6]. [6].
2. ENRP Message Definitions 2. ENRP Message Definitions
In this section, we defines the format of all ENRP messages. These In this section, we define the format of all ENRP messages. These
are messages sent and received amongst ENRP servers in an operational are messages sent and received amongst ENRP servers in an operational
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, that is
[11], is used for all ENRP and ASAP messages. defined in [12], 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 [11]. parameters. The TLV (Type-Length_value) parameters are also defined
in [12].
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,
the most significant byte first). meaning the most significant byte is transmitted first).
For ENRP, the following message types are defined: For ENRP, the following message types are defined in this section:
Type Message Name Type Message Name
----- ------------------------- ----- -------------------------
0x00 - (reserved by IETF) 0x00 - (reserved by IETF)
0x01 - ENRP_PRESENCE 0x01 - ENRP_PRESENCE
0x02 - ENRP_HANDLE_TABLE_REQUEST 0x02 - ENRP_HANDLE_TABLE_REQUEST
0x03 - ENRP_HANDLE_TABLE_RESPONSE 0x03 - ENRP_HANDLE_TABLE_RESPONSE
0x04 - ENRP_HANDLE_UPDATE 0x04 - ENRP_HANDLE_UPDATE
0x05 - ENRP_LIST_REQUEST 0x05 - ENRP_LIST_REQUEST
0x06 - ENRP_LIST_RESPONSE 0x06 - ENRP_LIST_RESPONSE
0x07 - ENRP_INIT_TAKEOVER 0x07 - ENRP_INIT_TAKEOVER
0x08 - ENRP_INIT_TAKEOVER_ACK 0x08 - ENRP_INIT_TAKEOVER_ACK
0x09 - ENRP_TAKEOVER_SERVER 0x09 - ENRP_TAKEOVER_SERVER
0x0a - ENRP_ERROR 0x0a - ENRP_ERROR
0x0b-0xff - (reserved by IETF) 0x0b-0xff - (reserved by IETF)
Figure 1
Except for the ENRP_PRESENCE message, the usage of the ENRP server
channel is for further study. The usage of point-to-point
communications is assumed in this specification.
2.1. ENRP_PRESENCE message 2.1. ENRP_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 server. This
message is either send on the ENRP server channel or point-to-point
to another 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 = 0x01 |0|0|0|0|0|0|0|R| Message Length | | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Checksum Param : : PE Checksum Param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Param (optional) : : Server Information Param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (reply_required) flag: 1 bit R (reply_required) flag: 1 bit
Set to '1' if the sender requires a response to this message, Set to '1' if the sender requires a response to this message,
otherwise set to '0'. otherwise set to '0'. If sent to the ENRP server channel this
field MUST be set to '0'.
Sender Server's ID: 32 bit (unsigned integer) Sending Server's ID: 32 bit (unsigned integer)
This is the ID of the ENRP server which sends the message. This is the ID of the ENRP server which sent this message.
Receiver Server's ID: 32 bit (unsigned integer) Receiving Server's ID: 32 bit (unsigned integer)
This is the ID of the ENRP server to which the message is This is the ID of the ENRP server to which this message is
intended. If the message is not intended to an individual intended. If the message is not intended for 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 sent with all 0's. If the message
is send point-to-point this field MAY be sent 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 ENRP_PRESENCE. This parameter SHOULD be server who sends the ENRP_PRESENCE. This parameter SHOULD be
included for handlespace consistency auditing. See included for handlespace consistency auditing. See
Section 3.11.1 for details. Section 3.11.1 for details.
Server Information Parameter: Server Information Parameter:
If present, contains the server information of the sender of If this parameter is present, it contains the server
this message (Server Information Parameter is defined in [11]). information of the sender of this message (Server Information
This parameter is optional. However, if this message is sent Parameter is defined in [12]). This parameter is optional.
in response to a received "reply required" ENRP_PRESENCE from a However, if this message is sent in response to a received
peer, the sender then MUST include its server information. "reply required" ENRP_PRESENCE from a peer, the sender then
MUST include its server information.
Note, at startup an ENRP server MUST pick a randomly generated, non- Note, at startup an ENRP server MUST pick a randomly generated, non-
zero 32-bit unsigned integer as its ID and MUST use this same ID for zero 32-bit unsigned integer as its ID and MUST use this same ID
its entire life. until the ENRP server is rebooted.
2.2. ENRP_HANDLE_TABLE_REQUEST message 2.2. ENRP_HANDLE_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 handlespace data. This message is normally used during copy of the handlespace data. This message is normally used during
server initialization or handlespace 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 = 0x02 |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 | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving 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: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
2.3. ENRP_HANDLE_TABLE_RESPONSE message 2.3. ENRP_HANDLE_TABLE_RESPONSE message
The PEER_NAME_TABLE_RESPONSE message is sent by an ENRP server in
response to a received PEER_NAME_TABLE_REQUEST message to assist peer
server initialization or handle-space 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 = 0x03 |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 | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Pool entry #1 (see below) : : Pool entry #1 (optional) :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: ... : : ... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Pool entry #n (see below) : : Pool entry #n (optional) :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 of this message has more pool entries
subsequent ENRP_HANDLE_TABLE_RESPONSE messages, otherwise, set to send in subsequent ENRP_HANDLE_TABLE_RESPONSE messages.
to '0'. Otherwise, set to '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
handlespace request. In such a case, this message MUST be sent handlespace request. In this case, pool entries MUST not be
with no pool entries included. included. This might happen if the sender of this message is
in the middle of initializing its database or it is under high
load.
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 including the header
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: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiving Server's ID:
See Section 2.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 the R flag is set to '0', at least one pool entry SHOULD be
the message. Each pool entry MUST start with a pool handle present in this message. Each pool entry MUST start with a
parameter as defined in section 3.1.7, followed by one or more Pool Handle parameter as defined in section 3.1.7, and is
pool element parameters, i.e.: followed by one or more Pool Element parameters in TLV format,
as shown below:
+---------------------------+ +---------------------------+
: Pool handle : : Pool handle :
+---------------------------+ +---------------------------+
: PE #1 : : PE #1 :
+---------------------------+ +---------------------------+
: PE #2 : : PE #2 :
+---------------------------+ +---------------------------+
: ... : : ... :
+---------------------------+ +---------------------------+
: PE #n : : PE #n :
+---------------------------+ +---------------------------+
2.4. ENRP_HANDLE_UPDATE message 2.4. ENRP_HANDLE_UPDATE message
The PEER_NAME_UPDATE message is sent by the home ENRP server of a PE
to all peer servers to announce registration, reregistration, or
deregistration of the PE in the handle-space.
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 = 0x04 |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 | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Action | (reserved) | | Update Action | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 including the header
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.
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 the requested action of the specified PE.
It MUST take one of the following values: The field MUST be set to one of the following values:
0x0 - ADD_PE: add or update the specified PE in the ENRP 0x0000 - ADD_PE: Add or update the specified PE in the ENRP
handlespace handlespace
0x1 - DEL_PE: delete the specified PE from the ENRP 0x0001 - DEL_PE: Delete the specified PE from the ENRP
handlespace. handlespace.
0x0002 - 0xFFFF: Reserved by IETF.
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. This field MUST be set to all 0's by sender and ignored by the
receiver.
Sender Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiving Server's ID:
See Section 2.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.
2.5. ENRP_LIST_REQUEST message 2.5. ENRP_LIST_REQUEST message
This ENRP message is used to request a copy of the current known ENRP The PEER_LIST_REQUEST message is sent to request a current copy of
peer server list. This message is normally sent from a newly started the ENRP server list. This message is normally sent from a newly
ENRP server to an existing ENRP server as part of the initialization activated ENRP server to an established ENRP server as part of the
process of the new server. initialization process.
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 = 0x05 |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 | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
2.6. ENRP_LIST_RESPONSE message 2.6. ENRP_LIST_RESPONSE message
This message is used to respond an ENRP_LIST_REQUEST. The PEER_LIST_RESPONSE message is sent in response from an ENRP
server that receives a PEER_LIST_REQUEST message to return
information about known ENRP servers.
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 = 0x06 |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 | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Info Param of Peer #1 : : Server Information Parameter of Peer #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Info Param of Peer #n : : Server Information Parameter of Peer #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reject) flag: 1 bit R (Reject) flag: 1 bit
MUST be set to '1' if the sender of this message is rejecting a This flag MUST be set to '1' if the sender of this message is
peer list request. In such a case, this message MUST be sent rejecting a PEER_LIST_REQUEST message. If this case occurs,
with no peer server ID included. the message MUST NOT include any Server Information Parameters.
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: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiving Server's ID:
See Section 2.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
[11]. [12].
2.7. ENRP_INIT_TAKEOVER message 2.7. ENRP_INIT_TAKEOVER message
This message is used by an ENRP server (the takeover initiator) to The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the
declare its intention of taking over a specific peer ENRP server. takeover initiator) to announce its intention of taking over a
specific peer ENRP server. It is send to all 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 = 0x07 |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 | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Server's ID | | Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Target Server's ID: Targeting Server's ID: 32-bit (unsigned integer)
Contains the 32-bit server ID of the peer ENRP that is the This is the ID of the peer ENRP that is the target of this
target of this takeover attempt. takeover attempt.
2.8. ENRP_INIT_TAKEOVER_ACK message 2.8. ENRP_INIT_TAKEOVER_ACK message
This message is used to acknowledge the takeover initiator that the The PEER_INIT_TAKEOVER_ACK message is sent in response to a takeover
sender of this message received the ENRP_INIT_TAKEOVER message and initiator to acknowledge the reception of the PEER_INIT_TAKEROVER
that it does not object to the takeover. message and 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 = 0x08 |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 | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Server's ID | | Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Target Server's ID: Targeting Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the This is the ID of the peer ENRP that is the target of this
target of this takeover attempt. takeover attempt.
2.9. ENRP_TAKEOVER_SERVER message 2.9. ENRP_TAKEOVER_SERVER message
This message is used by the takeover initiator to declare that a The PEER_TAKEOVER_REGISTRAR message is sent by the takeover initiator
takeover is underway. to declare the enforcement of a takeover to all active peer ENRP
servers.
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 = 0x09 |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 | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Server's ID | | Targeting Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID:
Sender Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Target Server's ID: Targeting Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the This is the ID of the peer ENRP that is the target of this
target of this takeover operation. takeover operation.
2.10. ENRP_ERROR message 2.10. ENRP_ERROR message
This message is used by an ENRP server to report an operational error The ENRP_ERROR message is sent by a registrar to report an
to one of its peers. operational error to a 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 = 0x0a |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 | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error Parameter : : Operational Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID:
Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Operational Error Parameter: Operational Error Parameter:
This parameter, defined in [11], indicates the type of error(s) This parameter, defined in [12], indicates the type of error(s)
being reported. being reported.
3. 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 follow these procedures when sending, receiving,
receiving, or processing ENRP messages. 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 PU/
PE-to-server message exchanges. Only the message exchanges and 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].
3.1. Methods for Communicating amongst ENRP Servers 3.1. Methods for Communicating amongst ENRP Servers
Within an Rserpool operational scope, ENRP servers need to Within an RSerPool operational scope, ENRP servers need to
communicate with each other in order to exchange information such as communicate with each other in order to exchange information such as
the pool membership changes, handlespace data synchronization, etc. the pool 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
operational scope. operational scope.
Point-to-point communication is always carried out over an SCTP Point-to-point communication is always carried out over an SCTP
association between the sending server and the receiving server. association between the sending server and the receiving server.
Announcements are communicated out with one of the following two Announcements are communicated out with one of the following two
approaches: approaches:
1. The sending server sends the announcement message to a well-known 1. The sending server sends the announcement message to the ENRP
RSERPOOL IP multicast channel that its peer servers subscribe to. server channel. This must also handle the relation between the
ENRP server channel and the operational scope. The usage of the
Note: Because IP multicast is not reliable, this approach does ENRP server channel is for further study.
not guarantee that all the peers will receive the announcement
message. Moreover, since IP multicast is not secure, this
approach cannot provide any security to the communication.
2. The sending server sends multiple copies of the announcement, one 2. The sending server sends multiple copies of the announcement, one
to each of its peer servers, over a set of point-to-point SCTP to each of its peer servers, over a set of point-to-point SCTP
associations between the sending server and the peers. associations between the sending server and the peers.
This approach guarantees the reliable reception of the message.
When needed, data security can be achieved by using IP security
mechanisms such as IPsec [10] or TLS [9].
In order to maximize inter-operability of ENRP servers, the following In order to maximize inter-operability of ENRP servers, the following
rules MUST be followed: rules MUST be followed:
1. At the startup time, a new ENRP server SHOULD make a decision on 1. At the startup time, a new ENRP server SHOULD make a decision on
whether it will enable IP multicast for ENRP announcements. This whether it will enable IP multicast for ENRP announcements. This
decision should be based on factors such as the availability of decision should be based on preconfigured information such as the
IP multicast and the security requirements from the user of availability of IP multicast and the security requirements from
Rserpool. the user of RSerPool.
2. If an ENRP server disables multicast, it then: 2. If an ENRP server disables multicast, it then:
A. MUST NOT subscribe to the well-known server multicast A. MUST NOT subscribe to the well-known server multicast
channel, i.e., it only receives peer announcements over SCTP channel, i.e., it only receives peer announcements over SCTP
associations, and associations, and
B. MUST transmit all its out-going announcements over point-to- B. MUST transmit all its out-going announcements over point-to-
point SCTP associations with its peers. point SCTP associations with its peers.
skipping to change at page 18, line 39 skipping to change at page 18, line 32
B. MUST also be prepared to receive peer announcements over B. MUST also be prepared to receive peer announcements over
point-to-point SCTP associations from peers. point-to-point SCTP associations from peers.
C. MUST track internally which peers are multicast-enabled and C. MUST track internally which peers are multicast-enabled and
which are not. Note: A peer is always assumed to be which are not. Note: A peer is always assumed to be
multicast-disabled until/unless an ENRP message of any type multicast-disabled until/unless an ENRP message of any type
is received from that peer over the well-known server is received from that peer over the well-known server
multicast channel. multicast channel.
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 ENRP server channel AND a copy to each of the peers that are
peers that are marked as multicast-disabled over a point-to- marked as multicast-disabled over a point-to-point SCTP
point SCTP association. association.
3.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
handlespace service if it is the first ENRP server started in the handlespace service if it is the first ENRP server started in the
operational scope. operational scope.
3.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 operational scope and this server Id as unique as possible in the operational scope and this server Id
MUST remain unchanged for the lifetime of the server. Normally, a MUST remain unchanged for the lifetime of the server. Normally, a
good 32-bit random number will be good enough as the server Id ([13] good 32-bit random number will be good enough as the server Id ([15]
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 about 4 billion) that
ENRP servers in an operational scope will generate the same server Id two ENRP servers in an operational scope will generate the same
and hence cause a server Id conflict in the pool. However, no severe server Id and hence cause a server Id conflict in the pool. However,
consequence of such a conflict has been identified. no severe consequence of such a conflict has been identified.
3.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 operational scope, learn all existing peer ENRP servers in the same operational scope,
or to determine that it is along in the scope. or to determine that it is alone 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.
3.2.2.1. Find the mentor server 3.2.2.1. Finding 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 server, keep the others
others as its backup mentor peers, and skip the remaining steps in as its backup mentor servers, and skip the remaining steps in this
this subsection. subsection.
If no existing peer server is specified to the initiating server AND If no existing peer server is specified to the initiating server AND
if multicast is available in the operational scope, the following if multicast is available in the operational scope, the following
mentor peer discovery procedures SHOULD be followed: mentor server discovery procedures SHOULD be followed:
1. The initiating server SHOULD first join the well-known ENRP
server multicast channel.
2. Then the initiating server SHOULD send an ENRP_PRESENCE message, 1. The initiating server SHOULD first join the ENRP server channel.
with the 'Reply_required' flag set, over the multicast channel.
Upon the reception of this ENRP_PRESENCE message, a peer server
MUST send an ENRP_PRESENCE, without the 'Reply_required' flag,
back to the initiating server.
3. When the first response to its original ENRP_PRESENCE arrives, 2. When the first ENRP_PRESENCE message arrives, the server SHOULD
the initiating server SHOULD take the sender of this received take the sender of this received response as its mentor server.
response as its mentor peer server. This completes the discovery This completes the discovery of the mentor server.
of the mentor peer server.
If responses are also received from other peers (a likely event If ENRP_PRESENCE messages are also received from other peers (a
when multiple peers exist in the operational scope at the time likely event when multiple peers exist in the operational scope
the new server started), the initiating server SHOULD keep a list at the time the new server started), the initiating server SHOULD
of those responded as its backup mentor peers (see below). keep a list of those responded as its backup mentor servers (see
below).
4. If no response to its ENRP_PRESENCE message are received after 3. If no response to its ENRP_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 operational scope. assume that it is alone in the operational scope.
5. If the initiating server determined that it is alone in the 4. If the initiating server determined that it is alone in the
scope, it MUST skip the procedures in Section 3.2.2.2 and scope, it MUST skip the procedures in Section 3.2.2.2 and
Section 3.2.3 and MUST consider its initialization completed and Section 3.2.3 and MUST consider its initialization completed and
start offering ENRP services. start 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 operational scope, at least one peer as security concerns) in the operational 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 operational scope. server to start in the operational scope.
Note, if the administratively specified mentor peer(s) fails, the Note, if the administratively specified mentor peer(s) fails and the
initiating server SHOULD use the auto-discover procedure defined in ENRP server channel is available, the initiating server SHOULD use
steps 1-5 above. the auto-discover procedure defined in steps 1-5 above.
3.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 discovery or administrative means), the initiating server MUST send
an ENRP_LIST_REQUEST message to the mentor peer server to request a an ENRP_LIST_REQUEST message to the mentor peer server to request a
copy of the complete server list maintained by the mentor peer (see copy of the complete server list maintained by the mentor peer (see
Section 3.9 for maintaining server list). Section 3.9 for maintaining server list).
The initiating server SHOULD start a timer every time it finishes The initiating server SHOULD start a MAX-TIME-NO-RESPONSE timer every
sending an ENRP_LIST_REQUEST message. If the timer expires before time it finishes sending an ENRP_LIST_REQUEST message. If the timer
receiving a response from the mentor peer, the initiating server expires before receiving a response from the mentor peer, the
SHOULD abort and send a new server list request to a backup mentor initiating server SHOULD abort and send a new server list request to
peer, if one is available. a backup mentor peer, if one is available.
Upon the reception of this request, the mentor peer server SHOULD Upon the reception of this request, the mentor peer server SHOULD
reply with an ENRP_LIST_RESPONSE message and include in the message reply with an ENRP_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 ENRP_LIST_RESPONSE message from the mentor Upon the reception of the ENRP_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 22, line 22 skipping to change at page 22, line 7
ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST
send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer
to request for the next ENRP_HANDLE_TABLE_RESPONSE message. to request for the next ENRP_HANDLE_TABLE_RESPONSE message.
4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE 4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE
message into its local handlespace database, the initiating message into its local handlespace database, the initiating
server MUST handle each pool entry carried in the message using server MUST handle each pool entry carried in the message using
the following rules: the following rules:
A. If the pool does not exist in the local handlespace, 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 create the pool in the local
handlespace 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 handlespace, 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 handlespace 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. ENRP will make sure
that the information keeps up to date.
5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from 5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from
the mentor peer and unpacked into the local handlespace, 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 handlespace 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
handlespace database, or it has currently too many download sessions handlespace database, or it has currently too many download sessions
skipping to change at page 23, line 12 skipping to change at page 22, line 47
message with the R flag set to '1', and with no pool entries included message with the R flag set to '1', and with no pool entries included
in the response. in the response.
In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the In the case where its ENRP_HANDLE_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 ENRP_HANDLE_TABLE_REQUEST to the mentor seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor
server, or if there is a backup mentor peer available, select another server, or if there is a backup mentor peer available, select another
mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new
mentor server. mentor server.
A started handlespace download session may get interrupted for some A handlespace download session that has been started may get
reason. To cope with this, the initiating server SHOULD start a interrupted for some reason. To cope with this, the initiating
timer every time it finishes sending an ENRP_HANDLE_TABLE_REQUEST to server SHOULD start a timer every time it finishes sending an
its mentor peer. If this timer expires without receiving a response ENRP_HANDLE_TABLE_REQUEST to its mentor peer. If this timer expires
from the mentor peer, the initiating server SHOULD abort the current without receiving a response from the mentor peer, the initiating
download session and re-start a new handlespace download with a server SHOULD abort the current download session and re-start a new
backup mentor peer, if one is available. handlespace download with a backup mentor peer, if one is available.
Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, if the Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, and the
mentor peer has still more data to send, it SHOULD start a session mentor peer set the M-bit to 1 to indicate that it has more data to
timer. If this timer expires without receiving another request from send, it SHOULD start a session timer. If this timer expires without
the initiating server, the mentor peer SHOULD abort the session, receiving another request from the initiating server, the mentor peer
cleaning out any resource and record of the session. SHOULD abort the session, cleaning out any resource and record of the
session.
3.3. Handle PE Registration 3.3. Handle PE Registration
To register itself with the handlespace, a PE sends an To register itself with the handlespace, a PE sends an
ASAP_REGISTRATION message to its home ENRP server. The format of ASAP_REGISTRATION message to its home ENRP server. The format of
ASAP_REGISTRATION message and rules of sending it are defined in [1]. ASAP_REGISTRATION message and rules of sending it are defined in [1].
In the ASAP_REGISTRATION message, the PE indicates the handle of the In the ASAP_REGISTRATION message, the PE indicates the handle of the
pool it wishes to join in a pool handle parameter, and its complete pool it wishes to join in a pool handle parameter, and its complete
transport information and any load control information in a PE transport information and any load control information in a PE
skipping to change at page 25, line 15 skipping to change at page 24, line 51
Moreover, if the registration is granted, the ENRP server MUST take Moreover, if the registration is granted, the ENRP server MUST take
the handlespace update action as described in Section 3.6 to inform the handlespace update action as described in Section 3.6 to inform
its peers about the change just made. If the registration is denied, its peers about the change just made. If the registration is denied,
no message will be sent to its peers. no message will be sent to its peers.
3.3.1. Rules on PE Re-registration 3.3.1. Rules on PE Re-registration
A PE may re-register itself to the handlespace 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. as described in the ASAP
specification.
A PE may modify its load factor value at any time via re- 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 pool's registration. Based on the number of PEs in the pool and the pool's
overall policy type, this operation allows the PE to dynamically overall policy type, this operation allows the PE to dynamically
control its share of inbound messages received by the pool (also see control its share of inbound messages received by the pool (also see
Section ???? in [1] for more on load control). Section ???? in [1] for more on load control).
Moreover, when re-registering, the PE MUST NOT change its policy Moreover, when re-registering, the PE MUST NOT change its policy
type. The server MUST reject the re-registration if the PE attempt type. The server MUST reject the re-registration if the PE attempt
to change its policy type. In the rejection, the server SHOULD to change its policy type. In the rejection, the server SHOULD
skipping to change at page 26, line 24 skipping to change at page 26, line 13
ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de- ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de-
registration is rejected, the ENRP server MUST indicate the rejection registration is rejected, the ENRP server MUST indicate the rejection
by including the proper Operational Error parameter. by including the proper Operational 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 handlespace, the ENRP server MUST take the its local copy of the handlespace, the ENRP server MUST take the
handlespace update action described in Section 3.6 to inform its handlespace update action described in Section 3.6 to inform its
peers about the change just made. Otherwise, NO message SHALL be peers about the change just made. Otherwise, the ENRP server MUST
send to its peers. NOT inform its peers.
3.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 an ASAP_HANDLE_RESOLUTION message to its This requires the PU to send an ASAP_HANDLE_RESOLUTION message to its
home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify
the pool handle to be translated in a Pool Handle parameter. the pool handle to be translated in a Pool Handle parameter.
skipping to change at page 26, line 52 skipping to change at page 26, line 41
Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server
MUST first look up the pool handle in its handlespace. If the pool MUST first look up the pool handle in its handlespace. If the pool
exits, the home ENRP server MUST compose and send back an exits, the home ENRP server MUST compose and send back an
ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. ASAP_HANDLE_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
omitted?).
If the named pool does not exist in the handlespace, the ENRP server If the named pool does not exist in the handlespace, the ENRP server
MUST reject the handle resolution request by responding with an MUST reject the handle resolution request by responding with an
ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor
Handle error. Handle error.
The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and
the rules of receiving it are defined in [1]. the rules of receiving it are defined in [1].
3.6. Server Handlespace Update 3.6. Server Handlespace Update
skipping to change at page 27, line 38 skipping to change at page 27, line 28
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 3.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
ENRP_HANDLE_UPDATE message with the Update Action field set to ENRP_HANDLE_UPDATE message with the Update Action field set to
ADD_PE, indicating the addition of a new PE or the modification of an ADD_PE, 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 Sending
Server's ID field and leave the Receiver Server's ID blank (i.e., all Server's ID field and leave the Receiving Server's ID blank (i.e.,
0's). all 0's).
When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take
the following actions: the 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 handlespace, the peer MUST create the named its local copy of the handlespace, the peer MUST create the named
pool in its local handlespace 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.
skipping to change at page 28, line 32 skipping to change at page 28, line 22
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 3.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 an An ENRP server MUST announce the PE removal to all its peers in an
ENRP_HANDLE_UPDATE message with the Update Action field set to ENRP_HANDLE_UPDATE message with the Update Action field set to
DEL_PE, indicating the removal of an existing PE. The complete DEL_PE, indicating the removal of an existing PE. The complete
information of the PE and the pool its belongs to MUST be indicated information of the PE and the pool its belongs to MUST be indicated
in the message with a PE parameter and a Pool Handle parameter, in the 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 The sending server MUST fill in its server ID in the Sending Server's
should reduce the size of the message] ID field and leave the Receiving Server's ID blank (i.e., set to all
The sending server MUST fill in its server ID in the Sender Server's
ID field and leave the Receiver Server's ID blank (i.e., set to all
0's). 0's).
When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first
find pool and the PE in its own handlespace, and then remove the PE find pool and the PE in its own handlespace, and then remove the PE
from its local handlespace. 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 handlespace. 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 handlespace, 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.
3.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 [8]), the PU SHOULD send an Notification, see section 10.2 of [9]), the PU SHOULD send an
ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The
message SHOULD contain the pool handle and the PE Id of the message SHOULD contain the pool handle and the PE Id of the
unreachable PE. unreachable PE.
Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server
MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE
message to the PE in question (the 'H' flag in the message SHOULD be message to the PE in question (the 'H' flag in the message SHOULD be
set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails
(e.g., it results in an SCTP SEND.FAILURE notification), the ENRP (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP
server MUST consider the PE as truly unreachable and MUST remove the server MUST consider the PE as truly unreachable and MUST remove the
skipping to change at page 29, line 33 skipping to change at page 29, line 19
Optionally, an ENRP server may also periodically send point-to-point Optionally, an ENRP server may also periodically send point-to-point
ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each
of the PEs owned by the ENRP server in order to check their of the PEs owned by the ENRP server in order to check their
reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE
fails, the ENRP server MUST consider the PE as unreachable and MUST fails, the ENRP server MUST consider the PE as unreachable and MUST
remove the PE from its handlespace and take actions described in remove the PE from its handlespace and take actions described in
Section 3.6.2. Note, if an ENRP server owns a large number of PEs, Section 3.6.2. Note, if an ENRP server owns a large number of PEs,
the implementation should pay attention not to flood the network with the implementation should pay attention not to flood the network with
bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the
implementation should try to smooth out the ASAP_ENDPOINT_KEEP_ALIVE implementation MUST distribute the ASAP_ENDPOINT_KEEP_ALIVE message
message traffic over time. traffic over a time period.
The complete definition and rules of sending The complete definition and rules of sending
ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE
messages are described in [1]. messages are described in [1].
3.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
skipping to change at page 30, line 28 skipping to change at page 30, line 17
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 operational the ENRP server MUST consider this peer a new peer in the operational
scope and add it to the peer list. scope and add it to the peer list.
The ENRP server MUST send an ENRP_PRESENCE message with the Reply- The ENRP server MUST send an ENRP_PRESENCE message with the Reply-
required flag set to '1' to the source address found in the arrived 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 message. This will force the new peer to reply with its own
ENRP_PRESENCE containing its full server information (see ENRP_PRESENCE containing its full server information (see
Section 2.1). Section 2.1).
[editor's note: should we ask for a peer list from the new peer? this
may help mending two split networks.]
3.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 ENRP_PRESENCE message. In continued presence to all its peer with a ENRP_PRESENCE message. In
the ENRP_PRESENCE message, the ENRP server MUST set the the ENRP_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 ENRP_PRESENCE message will cause all its The arrival of this periodic ENRP_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
skipping to change at page 31, line 13 skipping to change at page 30, line 47
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
ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer. ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer.
If the send fails or the peer does not reply after MAX-TIME-NO- If the send fails or the peer does not reply after MAX-TIME-NO-
RESPONSE seconds, the ENRP server MUST consider the peer server dead RESPONSE seconds, the ENRP server MUST consider the peer server dead
and SHOULD initiate the takeover procedure defined in Section 3.10. and SHOULD initiate the takeover procedure defined in Section 3.10.
3.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." This allows
PE to continue to operate in case of a failure of their Home ENRP
server.
3.10.1. Initiate Server Take-over Arbitration 3.10.1. Initiating Server Take-over Arbitration
The initiating server SHOULD first start a take-over arbitration The initiating server SHOULD first start the take-over arbitration
process by announcing an ENRP_INIT_TAKEOVER message to all its peer process by sending a ENRP_INIT_TAKEOVER message to all its peer
servers. See Section 3.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 Sending Server's ID
and Target Server's ID. and Targeting Server's ID. The goal is that only one ENRP server
takes over the PE from the target.
After announcing the ENRP_INIT_TAKEOVER message, the initiating After announcing the ENRP_INIT_TAKEOVER message, the initiating
server SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from _each_ server SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of
of its known peers, except of the target server. [editor's note: how its known peers, except of the target server.
long should it wait?]
Each of the peer servers that receives the ENRP_INIT_TAKEOVER message Each peer receiving a ENRP_INIT_TAKEOVER message from the initiating
from the initiating server SHOULD take the following actions: server SHOULD take the following actions:
1. If the peer server finds that itself is the target server 1. If the peer server determines that itself is the target server
indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately
announce an ENRP_PRESENCE message to all its peer ENRP servers in announce an ENRP_PRESENCE message to all its peer ENRP servers in
an attempt to stop this take-over process. This indicates a an attempt to stop this take-over process. This indicates a
false failure detection case by the initiating server. false failure detection case by the initiating server. The
initiating server MUST stop the takeover operation.
2. If the peer server finds that itself has already started its own 2. If the peer server finds that it has already started its own
take-over arbitration process on the same target server, it MUST take-over arbitration process on the same target server, it MUST
perform the following arbitration: perform the following arbitration:
A. if the peer's server ID is smaller in value than the Sender A. If the peer's server ID is smaller in value than the Sending
Server's ID in the arrived ENRP_INIT_TAKEOVER message, the Server's ID in the arrived ENRP_INIT_TAKEOVER message, the
peer server SHOULD immediately abort its own take-over peer server SHOULD immediately abort its own take-over
attempt. Moreover, the peer SHOULD mark the target server as attempt. Moreover, the peer SHOULD mark the target server as
"not active" on its internal peer list so that its status "not active" on its internal peer list so that its status
will no longer be monitored by the peer, and reply the will no longer be monitored by the peer, and reply the
initiating server with an ENRP_INIT_TAKEOVER_ACK message. initiating server with an ENRP_INIT_TAKEOVER_ACK message.
B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER
message and take no action. message and take no action.
skipping to change at page 32, line 21 skipping to change at page 32, line 7
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 an ENRP_INIT_TAKEOVER_ACK message. the initiating server with an ENRP_INIT_TAKEOVER_ACK message.
Once the initiating server has received ENRP_INIT_TAKEOVER_ACK Once the initiating server has received ENRP_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 3.10.2. described in Section 3.10.2.
However, if it receives an ENRP_PRESENCE from the target server at However, if it receives an ENRP_PRESENCE from the target server at
any point in the arbitration process, the initiating server SHOULD any point in the arbitration process, the initiating server MUST
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".
3.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
ENRP_TAKEOVER_SERVER message to inform all its active peers that the ENRP_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.
skipping to change at page 33, line 19 skipping to change at page 33, line 7
some of the ENRP servers in an operational scope. Therefore, each some of the ENRP servers in an operational scope. Therefore, each
ENRP server in the operational scope SHOULD periodically verify that ENRP server in the operational scope SHOULD periodically verify that
its local copy of handlespace data is still in sync with that of its its local copy of handlespace data is still in sync with that of its
peers. 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 handlespace data consistency. for an ENRP server to maintain its handlespace data consistency.
3.11.1. Auditing Procedures 3.11.1. Auditing Procedures
A checksum covering the data which should be the same is exchanged to
figure out if the data is the same or not.
The auditing of handlespace 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 list of what these checksums cover and a detailed
these PE checksum variables are given in Section 3.11.2. algorithm for calculating them is given in Section 3.11.2.
2. Each time an ENRP server sends out an ENRP_PRESENCE, it SHOULD 2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST
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 ENRP_PRESENCE) from a peer ENRP server (server B), an arrived ENRP_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
ENRP_PRESENCE with its own internal PE checksum of server B ENRP_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
skipping to change at page 34, line 42 skipping to change at page 34, line 32
itself. itself.
Note, whenever an ENRP finds that its internal handlespace has Note, whenever an ENRP finds that its internal handlespace has
changed (e.g., due to PE registration/deregistration, receiving peer changed (e.g., due to PE registration/deregistration, receiving peer
updates, removing failed PEs, downloading handlespace pieces from a updates, removing failed PEs, downloading handlespace pieces from a
peer, etc.), it MUST immediately update all its internal PE checksums peer, etc.), it MUST immediately update all its internal PE checksums
that are affected by the change. that are affected by the change.
Implementation Note: when the internal handlespace changes (e.g., a Implementation Note: when the internal handlespace changes (e.g., a
new PE added or an existing PE removed), an implementation needs not new PE added or an existing PE removed), an implementation needs not
to re-calculate the affected PE checksum; it should instead simply to re-calculate the affected PE checksum; it can 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.
3.11.3. Re-synchronization Procedures 3.11.3. Re-synchronization Procedures
Once an ENRP server determines that there is inconsistency between If an ENRP server determines that there is inconsistency between its
its local handlespace data and a peer's handlespace data with local handlespace data and a peer's handlespace data with regarding
regarding to the PEs owned by that peer, it SHOULD perform the to the PEs owned by that peer, it MUST perform the following steps to
following steps to re-synchronize the data: 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 handlespace database; is owned by the peer in its local handlespace database;
2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST 2. The ENRP server SHOULD then send an ENRP_HANDLE_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 ENRP_HANDLE_TABLE_REQUEST message with W 3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with W
flag set to '1', the peer server SHOULD immediately respond with flag set to '1', the peer server SHOULD immediately respond with
skipping to change at page 35, line 40 skipping to change at page 35, line 29
Note, similar to what is described in Section 3.2.3, the peer may Note, similar to what is described in Section 3.2.3, the peer may
reject the ENRP_HANDLE_TABLE_REQUEST or use more than one reject the ENRP_HANDLE_TABLE_REQUEST or use more than one
ENRP_HANDLE_TABLE_RESPONSE message to respond. ENRP_HANDLE_TABLE_RESPONSE message to respond.
3.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 [11]. defined in Sections 3 and 4 in [12].
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.
4. Variables and Thresholds 4. Variables and Thresholds
4.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
skipping to change at page 37, line 5 skipping to change at page 37, line 5
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 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on
a PE that an ENRP server will allow before purging this PE from a PE that an ENRP server will allow before purging this PE from
the handlespace. (Default=3) the handlespace. (Default=3)
5. Security Considerations 5. IANA Considerations
Threats Introduced by Rserpool and Requirements for Security in [NOTE to RFC-Editor:
Response to Threats [12] describes the threats to the Rserpool
architecture in detail and lists the security requirements in "RFCXXXX" is to be replaced by the RFC number you assign this
response to each threat. From the threats described in this document.
document, the security services required for the Rserpool protocol
are enumerated below. ]
This document (RFCXXX) is the reference for all registrations
described in this section. All registrations need to be listed on an
RSerPool specific page.
5.1. A New Table for ENRP Message Types
ENRP Message Types have to be maintained by IANA. Ten initial values
should be assigned by IANA as described in Figure 1. This requires a
new table "ENRP Message Types":
Type Message Name Reference
----- ------------------------- ---------
0x00 (reserved by IETF) RFCXXXX
0x01 ENRP_PRESENCE RFCXXXX
0x02 ENRP_HANDLE_TABLE_REQUEST RFCXXXX
0x03 ENRP_HANDLE_TABLE_RESPONSE RFCXXXX
0x04 ENRP_HANDLE_UPDATE RFCXXXX
0x05 ENRP_LIST_REQUEST RFCXXXX
0x06 ENRP_LIST_RESPONSE RFCXXXX
0x07 ENRP_INIT_TAKEOVER RFCXXXX
0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX
0x09 ENRP_TAKEOVER_SERVER RFCXXXX
0x0a ENRP_ERROR RFCXXXX
0x0b-0xff (reserved by IETF) RFCXXXX
For registering at IANA an ENRP Message Type in this table a request
has to be made to assign such a number. This number must be unique.
The "Specification Required" policy of RFC2434 [8] MUST be applied.
5.2. A New Table for Update Action Types
Update Types have to be maintained by IANA. Two initial values
should be assigned by IANA. This requires a new table "Update Action
Types":
Type Update Action Reference
------------- -------------------- ---------
0x0000 ADD_PE RFCXXXX
0x0001 DEL_PE RFCXXXX
0x0002-0xffff (reserved by IETF) RFCXXXX
For registering at IANA an Update Action Type in this table a request
has to be made to assign such a number. This number must be unique.
The "Specification Required" policy of RFC2434 [8] MUST be applied.
5.3. Multicast Addresses
IANA should assign one multicast address for the ENRP server channel
and another one for the ENRP client channel.
6. Security Considerations
We present a summary of the threats to the RSerPool architecture and
describe security requirements in response to mitigate the
threats.ENext we present the security mechanisms, based on TLS, that
are implementation requirements in response to the threats.E Finally,
we present a chain of trust argument that examines critical data
paths in RSerPool and shows how these paths are protected by the TLS
implementation.
6.1. Summary of Rserpool Security Threats
Threats Introduced by RSerPool and Requirements for Security in
Response to Threats [13] describes the threats to the RSerPool
architecture in detail lists the security requirements in response to
each threat.E From the threats described in this document, the
security services required for the RSerPool protocol are enumerated
below.
Threat 1) PE registration/deregistration flooding or spoofing Threat 1) PE registration/deregistration flooding or spoofing
----------- -----------
Security mechanism in response: ENRP server authenticates the PE Security mechanism in response: ENRP server authenticates the PE
Threat 2) PE registers with a malicious ENRP server Threat 2) PE registers with a malicious ENRP server
----------- -----------
Security mechanism in response: PE authenticates the ENRP server Security mechanism in response: PE authenticates the ENRP server
Threat 1 and 2 taken together results in mutual authentication of the Threat 1 and 2 taken together results in mutual authentication of the
skipping to change at page 38, line 18 skipping to change at page 40, line 28
Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
the ENRP server the ENRP server
----------- -----------
Security mechanism in response: ENRP server must control the number Security mechanism in response: ENRP server must control the number
of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE
To summarize the threats 1-7 require security mechanisms which To summarize the threats 1-7 require security mechanisms which
support authentication, integrity, data confidentiality, protection support authentication, integrity, data confidentiality, protection
from replay attacks. from replay attacks.
For Rserpool we need to authenticate the following: For RSerPool we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server) PU <---- ENRP Server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication) PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication)
We do not define any new security mechanisms specifically for 6.2. Implementing Security Mechanisms
responding to threats 1-7. Rather we use existing IETF security
protocols to provide the security services required. TLS supports We do not define any new security mechanisms specifically for EE
all these requirements and MUST be implemented. The responding to threats 1-7.E Rather we use an existing IETF security
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a EE protocol, specifically [2], to provide the security services
minimum by implementers of TLS for Rserpool. For purposes of required.ETLS supports all these requirements and MUST be
backwards compatibility, ENRP SHOULD support implemented.EThe TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any supported at a minimum by implementors of TLS for RSerPool.E For
other ciphersuite. purposes of backwards compatibility, ENRP SHOULD support EE
TLS_RSA_WITH_3DES_EDE_CBC_SHA.EImplementers MAY also support any EE
other IETF approved ciphersuites.
ENRP servers, PEs, PUs MUST implement TLS.E ENRP servers and PEs must
support mutual authentication.E ENRP servers must support mutual
authentication among themselves.E PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname.E PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use.E All RSerPool elements
that support TLS MUST have a mechanism for validating certificates
received during TLS negotiation; this entails possession of one or
more root certificates issued by certificate authorities (preferably
well-known distributors of site certificates comparable to those that
issue root certificates for web browsers).
Implementations MUST support TLS with SCTP as described in [10] or
TLS over TCP as described in [7].EWhen using TLS/SCTP we must ensure
that RSerPool does not use any features of SCTP that are not
available to an TLS/SCTP user.E This is not a difficult technical
problem, but simply a requirement.E When describing an API of the
RSerPool lower layer we have also to take into account the
differences between TLS and SCTP.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [1]) to the ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [1]) to the
ENRP server. ENRP server.
Threat 9 requires the ENRP protocol to limit the number of Threat 9 requires the ENRP protocol to limit the number of
ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see
Section Section 3.7). section Section 3.7).
5.1. Chain of trust 6.3. Chain of trust
Security is mandatory to implement in Rserpool and is based on TLS Security is mandatory to implement in RSerPool and is based on TLS
implementation in all three architecture components that comprise implementation in all three architecture components that comprise
Rserpool -- namely PU, PE and ENRP server. We define an ENRP server RSerPool -- namely PU, PE and ENRP server. We define an ENRP server
that uses TLS for all communication and authenticates ENRP peers and that uses TLS for all communication and authenticates ENRP peers and
PE registrants to be a secured ENRP server. PE registrants to be a secured ENRP server.
Here is a description of all possible data paths and a description of Here is a description of all possible data paths and a description of
the security. the security.
PU <---> secured ENRP Server (authentication of ENRP server; PU <---> secured ENRP Server (authentication of ENRP server;
queries over TLS) queries over TLS)
PE <---> secured ENRP server (mutual authentication; PE <---> secured ENRP server (mutual authentication;
registration/deregistration over TLS) registration/deregistration over TLS)
secured ENRP <---> secured ENRP server (mutual authentication; secured ENRP server <---> secured ENRP server (mutual authentication;
database updates using TLS) database updates using TLS)
If all components of the system authenticate and communicate using If all components of the system authenticate and communicate using
TLS, the chain of trust is sound. The root of the trust chain is the TLS, the chain of trust is sound. The root of the trust chain is the
ENRP server. If that is secured using TLS, then security will be ENRP server. If that is secured using TLS, then security will be
enforced for all ENRP and PE components that try to connect to it. enforced for all ENRP and PE components that try to connect to it.
Summary of interaction between secured and unsecured components: If Summary of interaction between secured and unsecured components: If
the PE does not use TLS and tries to register with a secure ENRP the PE does not use TLS and tries to register with a secure ENRP
server, it will receive an error message response indicated as error server, it will receive an error message response indicated as error
skipping to change at page 39, line 35 skipping to change at page 42, line 21
as the response can be tampered with in transit even if the ENRP as the response can be tampered with in transit even if the ENRP
database is secured. database is secured.
The final case is the PU sending a secure request to ENRP. It might The final case is the PU sending a secure request to ENRP. It might
be that ENRP and PEs are not secured and this is an allowable be that ENRP and PEs are not secured and this is an allowable
configuration. The intent is to secure the communication over the configuration. The intent is to secure the communication over the
Internet between the PU and the ENRP server. Internet between the PU and the ENRP server.
Summary: Summary:
Rserpool architecture components can communicate with each other to RSerPool architecture components can communicate with each other to
establish a chain of trust. Secured PE and ENRP servers reject any establish a chain of trust. Secured PE and ENRP servers reject any
communications with unsecured ENRP or PE servers. communications with unsecured ENRP or PE servers.
If the above is enforced, then a chain of trust is established for If the above is enforced, then a chain of trust is established for
the Rserpool user. the RSerPool user.
5.2. Implementing Security Mechanisms
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication. ENRP servers must support mutual
authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use. All Rserpool elements
that support TLS MUST have a mechanism for validating certificates
received during TLS negotiation; this entails possession of one or
more root certificates issued by certificate authorities (preferably
well-known distributors of site certificates comparable to those that
issue root certificates for web browsers).
Implementations MUST support TLS with SCTP as described in RFC3436
[9] or TLS over TCP as described in RFC2246 [7]. When using TLS/SCTP
we must ensure that RSerPool does not use any features of SCTP that
are not available to an TLS/SCTP user. This is not a difficult
technical problem, but simply a requirement. When describing an API
of the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP.
6. Acknowledgements 7. Acknowledgements
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson,
Thomas Dreibholz, and many others for their invaluable comments and Thomas Dreibholz, and many others for their invaluable comments and
feedback. feedback.
7. References 8. References
7.1. Normative References 8.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-12 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-12
(work in progress), July 2005. (work in progress), July 2005.
[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 J., and M. Stillman, "Requirements for Reliable Server
Pooling", RFC 3237, January 2002. Pooling", RFC 3237, January 2002.
[3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and
skipping to change at page 42, line 33 skipping to change at page 44, line 33
[5] Bradner, S., "The Internet Standards Process -- Revision 3", [5] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960, Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000. October 2000.
[9] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP", [10] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP",
RFC 3436, December 2002. RFC 3436, December 2002.
[10] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On [11] 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.
[11] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate [12] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate
Server Access Protocol (ASAP) and Endpoint Handlespace Server Access Protocol (ASAP) and Endpoint Handlespace
Redundancy Protocol (ENRP) Parameters", Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-09 (work in progress), draft-ietf-rserpool-common-param-09 (work in progress),
July 2005. July 2005.
[12] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M. [13] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M.
Holdrege, "Threats Introduced by Rserpool and Requirements for Holdrege, "Threats Introduced by Rserpool and Requirements for
Security in Response to Threats", Security in Response to Threats",
draft-ietf-rserpool-threats-05 (work in progress), July 2005. draft-ietf-rserpool-threats-05 (work in progress), July 2005.
7.2. Informative References [14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[13] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 8.2. Informative References
[15] 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
skipping to change at page 46, line 7 skipping to change at page 48, line 7
1301 E. Algonquin Road 1301 E. Algonquin Road
Room 2246 Room 2246
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Phone: +1 847-576-8747 Phone: +1 847-576-8747
Email: aron.j.silverton@motorola.com Email: aron.j.silverton@motorola.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
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
 End of changes. 183 change blocks. 
333 lines changed or deleted 434 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/