draft-ietf-rserpool-enrp-12.txt   draft-ietf-rserpool-enrp-13.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Expires: January 16, 2006 R. Stewart Expires: August 11, 2006 R. Stewart
Cisco Systems, Inc. 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.
July 15, 2005 February 7, 2006
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-12.txt draft-ietf-rserpool-enrp-13.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 January 16, 2006. This Internet-Draft will expire on August 11, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work
in conjunction with the Aggregate Server Access Protocol (ASAP) to in conjunction with the Aggregate Server Access Protocol (ASAP) to
accomplish the functionality of the Reliable Server Pooling accomplish the functionality of the Reliable Server Pooling
(Rserpool) requirements and architecture. Within the operational (Rserpool) requirements and architecture. Within the operational
scope of Rserpool, ENRP defines the procedures and message formats of scope of Rserpool, ENRP defines the procedures and message formats of
a distributed, fault-tolerant registry service for storing, a distributed, fault-tolerant registry service for storing,
bookkeeping, retrieving, and distributing pool operation and bookkeeping, retrieving, and distributing pool operation and
membership information. membership information.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 11
2.6 ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12 2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12
2.7 ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13 2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . 14
2.10 ENRP_ERROR message . . . . . . . . . . . . . . . . . . . 15 2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . 25
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 . . . . . 30
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 . . . . . . . . . . . . . 31
3.10.1 Initiate Server Take-over Arbitration . . . . . . . 31 3.10.1. Initiate 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 . . . . . 33
3.11.1 Auditing Procedures . . . . . . . . . . . . . . . . 33 3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33
3.11.2 PE Checksum Calculation Algorithm . . . . . . . . . 33 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 3.12. Handling Unrecognized Message or Unrecognized Parameter . 35
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. Security Considerations . . . . . . . . . . . . . . . . . . 37 5.1. Implementing Security Mechanisms . . . . . . . . . . . . . 38
5.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.1. Normative References . . . . . . . . . . . . . . . . . . . 41
7.1 Normative References . . . . . . . . . . . . . . . . . . . 41 7.2. Informative References . . . . . . . . . . . . . . . . . . 42
7.2 Informative References . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . 44
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.
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];
Pool element (PE): See [3]; Pool element (PE): See [3];
skipping to change at page 5, line 12 skipping to change at page 5, line 12
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
of this relationship. of this relationship.
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 defines 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
skipping to change at page 6, line 37 skipping to change at page 6, line 37
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)
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 sever.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x01 |0|0|0|0|0|0|0|R| Message Length | | Type = 0x01 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
skipping to change at page 8, line 7 skipping to change at page 8, line 7
If present, contains the server information of the sender of If present, contains the server information of the sender of
this message (Server Information Parameter is defined in [11]). this message (Server Information Parameter is defined in [11]).
This parameter is optional. However, if this message is sent This parameter is optional. However, if this message is sent
in response to a received "reply required" ENRP_PRESENCE from a in response to a received "reply required" ENRP_PRESENCE from a
peer, the sender then MUST include its server information. peer, the sender then MUST include its server information.
Note, at startup an ENRP server MUST pick a randomly generated, 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 for
its entire life. its entire life.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 37 skipping to change at page 8, line 37
Otherwise, set to '0'. Otherwise, set to '0'.
Sender Server's ID: Sender Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiver 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
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 | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
skipping to change at page 10, line 28 skipping to change at page 10, line 28
+---------------------------+ +---------------------------+
: PE #1 : : PE #1 :
+---------------------------+ +---------------------------+
: PE #2 : : PE #2 :
+---------------------------+ +---------------------------+
: ... : : ... :
+---------------------------+ +---------------------------+
: PE #n : : PE #n :
+---------------------------+ +---------------------------+
2.4 ENRP_HANDLE_UPDATE message 2.4. ENRP_HANDLE_UPDATE message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 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 | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 44 skipping to change at page 11, line 41
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 This ENRP message is used to request a copy of the current known ENRP
peer server list. This message is normally sent from a newly started peer server list. This message is normally sent from a newly started
ENRP server to an existing ENRP server as part of the initialization ENRP server to an existing ENRP server as part of the initialization
process of the new server. process of the new server.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 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 |
skipping to change at page 12, line 23 skipping to change at page 12, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sender Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiver 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. This message is used to respond an ENRP_LIST_REQUEST.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 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 | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 27 skipping to change at page 13, line 26
Receiver Server's ID: Receiver 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]. [11].
2.7 ENRP_INIT_TAKEOVER message 2.7. ENRP_INIT_TAKEOVER message
This message is used by an ENRP server (the takeover initiator) to This message is used by an ENRP server (the takeover initiator) to
declare its intention of taking over a specific peer ENRP server. declare its intention of taking over a specific peer ENRP server.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 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 | | Sender Server's ID |
skipping to change at page 14, line 14 skipping to change at page 14, line 14
Receiver Server's ID: Receiver Server's ID:
See Section 2.1. See Section 2.1.
Target Server's ID: Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover attempt. target of this takeover attempt.
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 This message is used to acknowledge the takeover initiator that the
sender of this message received the ENRP_INIT_TAKEOVER message and sender of this message received the ENRP_INIT_TAKEOVER message and
that it does not object to the takeover. that it does not object to the takeover.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 45 skipping to change at page 14, line 45
Receiver Server's ID: Receiver Server's ID:
See Section 2.1. See Section 2.1.
Target Server's ID: Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover attempt. target of this takeover attempt.
2.9 ENRP_TAKEOVER_SERVER message 2.9. ENRP_TAKEOVER_SERVER message
This message is used by the takeover initiator to declare that a This message is used by the takeover initiator to declare that a
takeover is underway. takeover is underway.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 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 | | Sender Server's ID |
skipping to change at page 15, line 31 skipping to change at page 15, line 30
Receiver Server's ID: Receiver Server's ID:
See Section 2.1. See Section 2.1.
Target Server's ID: Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover operation. target of this takeover operation.
2.10 ENRP_ERROR message 2.10. ENRP_ERROR message
This message is used by an ENRP server to report an operational error This message is used by an ENRP server to report an operational error
to one of its peers. to one of its peers.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 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 | | Sender Server's ID |
skipping to change at page 17, line 19 skipping to change at page 17, line 19
receiving, or processing ENRP messages. receiving, or processing ENRP messages.
Many of the Rserpool events call for both server-to-server and PU/ Many of the Rserpool events call for both server-to-server and 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
skipping to change at page 18, line 43 skipping to change at page 18, line 43
which are not. Note: A peer is always assumed to be which are not. Note: A peer is always assumed to be
multicast-disabled until/unless an ENRP message of any type multicast-disabled until/unless an ENRP message of any type
is received from that peer over the well-known server is received from that peer over the well-known server
multicast channel. multicast channel.
D. when sending out an announcement, MUST send a copy to the D. when sending out an announcement, MUST send a copy to the
well-known server multicast channel AND a copy to each of the well-known server multicast channel AND a copy to each of the
peers that are marked as multicast-disabled over a point-to- peers that are marked as multicast-disabled over a point-to-
point SCTP association. point SCTP 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 ([13]
provides some information on randomness guidelines). provides some information on randomness guidelines).
Note, there is a very remote chance (about 1 in 4 billion) that two Note, there is a very remote chance (about 1 in 4 billion) that two
ENRP servers in an operational scope will generate the same server Id ENRP servers in an operational scope will generate the same server Id
and hence cause a server Id conflict in the pool. However, no severe and hence cause a server Id conflict in the pool. However, no severe
consequence of such a conflict has been identified. consequence of such a conflict has been identified.
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 along in the scope.
The initiating server uses an existing peer server to bootstrap The initiating server uses an existing peer server to bootstrap
itself into service. We call this peer server the mentor server. itself into service. We call this peer server the mentor server.
3.2.2.1 Find the mentor server 3.2.2.1. Find the mentor server
If the initiating server is told about an existing peer server If the initiating server is told about an existing peer server
through some administrative means (such as DNS query, configuration through some administrative means (such as DNS query, configuration
database, startup scripts, etc), the initiating server SHOULD then database, startup scripts, etc), the initiating server SHOULD then
use this peer server as its mentor server and SHOULD skip the use this peer server as its mentor server and SHOULD skip the
remaining steps in this subsection. remaining steps in this subsection.
If multiple existing peer servers are specified, the initiating If multiple existing peer servers are specified, the initiating
server SHOULD pick one of them as its mentor peer server, keep the server SHOULD pick one of them as its mentor peer server, keep the
others as its backup mentor peers, and skip the remaining steps in others as its backup mentor peers, and skip the remaining steps in
skipping to change at page 20, line 36 skipping to change at page 20, line 36
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, the
initiating server SHOULD use the auto-discover procedure defined in initiating server SHOULD use the auto-discover procedure defined in
steps 1-5 above. steps 1-5 above.
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 timer every time it finishes
sending an ENRP_LIST_REQUEST message. If the timer expires before sending an ENRP_LIST_REQUEST message. If the timer expires before
receiving a response from the mentor peer, the initiating server receiving a response from the mentor peer, the initiating server
skipping to change at page 21, line 22 skipping to change at page 21, line 22
server), it MUST reject the request by the initiating server and server), it MUST reject the request by the initiating server and
respond with an ENRP_LIST_RESPONSE message with the R flag set to respond with an ENRP_LIST_RESPONSE message with the R flag set to
'1', and with no server information included in the response. '1', and with no server information included in the response.
In the case where its ENRP_LIST_REQUEST is rejected by the mentor In the case where its ENRP_LIST_REQUEST is rejected by the mentor
peer, the initiating server SHOULD either wait for a few seconds and peer, the initiating server SHOULD either wait for a few seconds and
re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a
backup mentor peer available, select another mentor peer server and backup mentor peer available, select another mentor peer server and
send the ENRP_LIST_REQUEST to the new mentor server. send the ENRP_LIST_REQUEST to the new mentor server.
3.2.3 Download ENRP Handlespace Data from Mentor Peer 3.2.3. Download ENRP Handlespace Data from Mentor Peer
After a peer list download is completed, the initiating server MUST After a peer list download is completed, the initiating server MUST
request a copy of the current handlespace data from its mentor peer request a copy of the current handlespace data from its mentor peer
server, by taking the following steps: server, by taking the following steps:
1. The initiating server MUST first send a ENRP_HANDLE_TABLE_REQUEST 1. The initiating server MUST first send a ENRP_HANDLE_TABLE_REQUEST
message to the mentor peer, with W flag set to '0', indicating message to the mentor peer, with W flag set to '0', indicating
that the entire handlespace is requested. that the entire handlespace is requested.
2. Upon the reception of this message, the mentor peer MUST start a 2. Upon the reception of this message, the mentor peer MUST start a
skipping to change at page 23, line 26 skipping to change at page 23, line 26
from the mentor peer, the initiating server SHOULD abort the current from the mentor peer, the initiating server SHOULD abort the current
download session and re-start a new handlespace download with a download session and re-start a new handlespace download with a
backup mentor peer, if one is available. 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, if the
mentor peer has still more data to send, it SHOULD start a session mentor peer has still more data to send, it SHOULD start a session
timer. If this timer expires without receiving another request from timer. If this timer expires without receiving another request from
the initiating server, the mentor peer SHOULD abort the session, the initiating server, the mentor peer SHOULD abort the session,
cleaning out any resource and record of the session. cleaning out any resource and record of the session.
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
parameter. parameter.
skipping to change at page 25, line 11 skipping to change at page 25, line 11
find it both efficient and convenient to internally maintain two find it both efficient and convenient to internally maintain two
separate PE lists or tables - one is for the PEs that are "owned" separate PE lists or tables - one is for the PEs that are "owned"
by the ENRP server and the other for all the PEs owned by its by the ENRP server and the other for all the PEs owned by its
peer(s). peer(s).
Moreover, if the registration is granted, the ENRP server MUST take Moreover, if the registration is granted, the ENRP server MUST take
the 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.
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).
skipping to change at page 25, line 37 skipping to change at page 25, line 37
Regardless whether it is the current owner of the PE, if the re- Regardless whether it is the current owner of the PE, if the re-
registration is granted to the PE, the ENRP server MUST assign itself registration is granted to the PE, the ENRP server MUST assign itself
to be the new home ENRP server of the PE. to be the new home ENRP server of the PE.
Moreover, if the re-registration is granted, the ENRP server MUST Moreover, if the re-registration is granted, the ENRP server MUST
take the handlespace update action as described in Section 3.6 to take the handlespace update action as described in Section 3.6 to
inform its peers about the change just made. If the re-registration inform its peers about the change just made. If the re-registration
is denied, no message will be sent to its peers. is denied, no message will be sent to its peers.
3.4 Handle PE De-registration 3.4. Handle PE De-registration
To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION
message to its home ENRP server. The complete format of message to its home ENRP server. The complete format of
ASAP_DEREGISTRATION message and rules of sending it are defined in ASAP_DEREGISTRATION message and rules of sending it are defined in
[1]. [1].
In the ASAP_DEREGISTRATION message the PE indicates the handle of the In the ASAP_DEREGISTRATION message the PE indicates the handle of the
pool it belongs to in a pool handle parameter and provides its PE pool it belongs to in a pool handle parameter and provides its PE
identifier. identifier.
skipping to change at page 26, line 27 skipping to change at page 26, line 27
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, NO message SHALL be
send to its peers. send to 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.
Complete definition of the ASAP_HANDLE_RESOLUTION message and the Complete definition of the ASAP_HANDLE_RESOLUTION message and the
rules of sending it are defined in [1]. rules of sending it are defined in [1].
skipping to change at page 27, line 15 skipping to change at page 27, line 15
omitted?). 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
This includes a set of update operations used by an ENRP server to This includes a set of update operations used by an ENRP server to
inform its peers when its local handlespace is modified, e.g., inform its peers when its local handlespace is modified, e.g.,
addition of a new PE, removal of an existing PE, change of pool or PE addition of a new PE, removal of an existing PE, change of pool or PE
properties. properties.
3.6.1 Announcing Addition or Update of PE 3.6.1. Announcing Addition or Update of PE
When a new PE is granted registration to the handlespace or an When a new PE is granted registration to the handlespace or an
existing PE is granted a re-registration, the home ENRP server uses existing PE is granted a re-registration, the home ENRP server uses
this procedure to inform all its peers. this procedure to inform all its peers.
This is an ENRP announcement and is sent to all the peer of the home This is an ENRP announcement and is sent to all the peer of the home
ENRP server. See Section 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
skipping to change at page 28, line 15 skipping to change at page 28, line 15
2. If the named pool already exists in the peer's local copy of the 2. If the named pool already exists in the peer's local copy of the
handlespace AND the PE does not exist, the peer MUST add the PE handlespace AND the PE does not exist, the peer MUST add the PE
to the pool as a new PE and copy in all attributes of the PE to the pool as a new PE and copy in all attributes of the PE
carried in the message. carried in the message.
3. If the named pool exists AND the PE is already a member of the 3. If the named pool exists AND the PE is already a member of the
pool, the peer MUST replace the attributes of the PE with the new pool, the peer MUST replace the attributes of the PE with the new
information carried in the message. information carried in the message.
3.6.2 Announcing Removal of PE 3.6.2. Announcing Removal of PE
When an existing PE is granted de-registration or is removed from its When an existing PE is granted de-registration or is removed from its
handlespace for some other reasons (e.g., purging an unreachable PE, handlespace for some other reasons (e.g., purging an unreachable PE,
see Section 3.7), the ENRP server MUST uses this procedure to inform see Section 3.7), the ENRP server MUST uses this procedure to inform
all its peers about the change just made. all its peers about the change just made.
This is an ENRP announcement and is sent to all the peer of the home This is an ENRP announcement and is sent to all the peer of the home
ENRP server. See Section 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
skipping to change at page 28, line 47 skipping to change at page 28, line 47
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 [8]), 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
skipping to change at page 29, line 41 skipping to change at page 29, line 40
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 should try to smooth out the ASAP_ENDPOINT_KEEP_ALIVE
message traffic over time. message traffic over time.
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
of currently available ENRP servers in its scope. of currently available ENRP servers in its scope.
To help the PE or PU maintaining this list, an ENRP server, if it is To help the PE or PU maintaining this list, an ENRP server, if it is
enabled for multicast, SHOULD periodically send out an enabled for multicast, SHOULD periodically send out an
ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to
the well-known ASAP multicast channel. And in the the well-known ASAP multicast channel. And in the
ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the
transport addresses available for ASAP communications. If the ENRP transport addresses available for ASAP communications. If the ENRP
server only supports SCTP for ASAP communications, the transport server only supports SCTP for ASAP communications, the transport
information MAY be omitted in the ASAP_SERVER_ANNOUNCE message. information MAY be omitted in the ASAP_SERVER_ANNOUNCE message.
For the complete procedure of this, see Section 3.6?? in [1]. For the complete procedure of this, see Section 3.6?? in [1].
3.9 Maintaining Peer List and Monitoring Peer Status 3.9. Maintaining Peer List and Monitoring Peer Status
An ENRP server MUST keep an internal record on the status of each of An ENRP server MUST keep an internal record on the status of each of
its known peers. This record is referred to as the server's "peer its known peers. This record is referred to as the server's "peer
list" list"
3.9.1 Discovering New Peer 3.9.1. Discovering New Peer
If a message of any type is received from a previously unknown peer, If a message of any type is received from a previously unknown peer,
the ENRP server MUST consider this peer a new peer in the 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 [editor's note: should we ask for a peer list from the new peer? this
may help mending two split networks.] 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
sending server (see Section 3.9.3 for more details). sending server (see Section 3.9.3 for more details).
3.9.3 Detecting Peer Server Failure 3.9.3. Detecting Peer Server Failure
An ENRP server MUST keep an internal variable "peer.last.heard" for An ENRP server MUST keep an internal variable "peer.last.heard" for
each of its known peers and the value of this variable MUST be each of its known peers and the value of this variable MUST be
updated to the current local time every time a message of any type updated to the current local time every time a message of any type
(point-to-point or announcement) is received from the corresponding (point-to-point or announcement) is received from the corresponding
peer. peer.
If a peer has not been heard for more than MAX-TIME-LAST-HEARD If a peer has not been heard for more than MAX-TIME-LAST-HEARD
seconds, the ENRP server MUST immediately send a point-to-point seconds, the ENRP server MUST immediately send a point-to-point
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."
3.10.1 Initiate Server Take-over Arbitration 3.10.1. Initiate Server Take-over Arbitration
The initiating server SHOULD first start a take-over arbitration The initiating server SHOULD first start a take-over arbitration
process by announcing an ENRP_INIT_TAKEOVER message to all its peer process by announcing an 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 Sender Server's ID
and Target Server's ID. and Target Server's ID.
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 its known peers, except of the target server. [editor's note: how of its known peers, except of the target server. [editor's note: how
skipping to change at page 32, line 25 skipping to change at page 32, line 25
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 SHOULD
immediately abort the take-over process and mark the status of the immediately abort the take-over process and mark the status of the
target server as "active". target server as "active".
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.
Then it SHOULD examine its local copy of the handlespace and claim Then it SHOULD examine its local copy of the handlespace and claim
ownership of each of the PEs originally owned by the target server, ownership of each of the PEs originally owned by the target server,
by following these steps: by following these steps:
skipping to change at page 33, line 5 skipping to change at page 33, line 5
When a peer receives the ENRP_TAKEOVER_SERVER message from the When a peer receives the ENRP_TAKEOVER_SERVER message from the
initiating server, it SHOULD update its local peer list and PE cache initiating server, it SHOULD update its local peer list and PE cache
by following these steps: by following these steps:
1. remove the target server from its internal peer list; 1. remove the target server from its internal peer list;
2. update the home ENRP server of each PE in its local copy of the 2. update the home ENRP server of each PE in its local copy of the
handlespace to be the sender of the message, i.e., the initiating handlespace to be the sender of the message, i.e., the initiating
server. server.
3.11 Handlespace Data Auditing and Re-synchronization 3.11. Handlespace Data Auditing and Re-synchronization
Message losses or certain temporary breaks in network connectivity Message losses or certain temporary breaks in network connectivity
may result in data inconsistency in the local handlespace copy of may result in data inconsistency in the local handlespace copy of
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
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 definition and detailed algorithm for calculating
skipping to change at page 33, line 49 skipping to change at page 33, line 49
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
handlespace inconsistency between itself and server B and should handlespace inconsistency between itself and server B and should
take no further actions. take no further actions.
5. If the two values do NOT match, server A SHOULD consider that 5. If the two values do NOT match, server A SHOULD consider that
there is a handlespace inconsistency between itself and server B there is a handlespace inconsistency between itself and server B
and a re-synchronization process SHOULD be carried out and a re-synchronization process SHOULD be carried out
immediately with server B (see Section 3.11.3). immediately with server B (see Section 3.11.3).
3.11.2 PE Checksum Calculation Algorithm 3.11.2. PE Checksum Calculation Algorithm
When an ENRP server (server A) calculate an internal PE checksum for When an ENRP server (server A) calculate an internal PE checksum for
a peer (server B), it MUST use the following algorithm. a peer (server B), it MUST use the following algorithm.
Let us assume that in server A's internal handlespace there are Let us assume that in server A's internal handlespace there are
currently 'M' PEs that are owned by server B. Each of the 'M' PEs currently 'M' PEs that are owned by server B. Each of the 'M' PEs
will then contribute to the checksum calculation with the following will then contribute to the checksum calculation with the following
byte block: byte block:
0 1 2 3 0 1 2 3
skipping to change at page 34, line 42 skipping to change at page 34, line 41
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 should instead simply
update the checksum by adding or subtracting the byte block of the update the checksum by adding or subtracting the byte block of the
corresponding PE from the previous checksum value. corresponding PE from the previous checksum value.
3.11.3 Re-synchronization Procedures 3.11.3. Re-synchronization Procedures
Once an ENRP server determines that there is inconsistency between Once an ENRP server determines that there is inconsistency between
its local handlespace data and a peer's handlespace data with its local handlespace data and a peer's handlespace data with
regarding to the PEs owned by that peer, it SHOULD perform the regarding to the PEs owned by that peer, it SHOULD perform the
following steps to re-synchronize the data: following steps to re-synchronize the data:
1. The ENRP server SHOULD first "mark" every PE it knows about that 1. The ENRP server SHOULD first "mark" every PE it knows about that
is owned by the peer in its local 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
an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently
owned by the peer. owned by the peer.
4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the 4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the
skipping to change at page 35, line 30 skipping to change at page 35, line 28
5. After transferring all the PE entries from the received 5. After transferring all the PE entries from the received
ENRP_HANDLE_TABLE_RESPONSE message into its local database, the ENRP_HANDLE_TABLE_RESPONSE message into its local database, the
ENRP server SHOULD check whether there are still PE entries that ENRP server SHOULD check whether there are still PE entries that
remain "marked" in its local handlespace. If so, the ENRP server remain "marked" in its local handlespace. If so, the ENRP server
SHOULD silently remove those "marked" entries. SHOULD silently remove those "marked" entries.
Note, similar to what is described in Section 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 [11].
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
(via receiving either a multicast or point-to-point message from (via receiving either a multicast or point-to-point message from
the peer). the peer).
pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server
keeps for a peer. A separate PE checksum is kept for each of its keeps for a peer. A separate PE checksum is kept for each of its
known peers as well as for itself. known peers as well as for itself.
4.2 Thresholds 4.2. Thresholds
MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will
make to contact an ENRP server (Default=3 times). make to contact an ENRP server (Default=3 times).
TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will
wait for a response from an ENRP server (Default=5 seconds). wait for a response from an ENRP server (Default=5 seconds).
PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a
heartbeat message to all its known peers. (Default=30 secs.) heartbeat message to all its known peers. (Default=30 secs.)
skipping to change at page 38, line 41 skipping to change at page 38, line 41
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other ciphersuite. other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
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
Endpoint_KeepAlive messages to the PE (see Section x.y???). Endpoint_KeepAlive messages to the PE (see Section x.y???).
5.1 Implementing Security Mechanisms 5.1. Implementing Security Mechanisms
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication. ENRP servers must support mutual support mutual authentication. ENRP servers must support mutual
authentication among themselves. PUs MUST authenticate ENRP servers. authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname. PUs MAY have certificates corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use. All Rserpool elements are set forth in this document for their use. All Rserpool elements
that support TLS MUST have a mechanism for validating certificates that support TLS MUST have a mechanism for validating certificates
skipping to change at page 41, line 7 skipping to change at page 41, line 7
differences between TLS and SCTP. differences between TLS and SCTP.
6. Acknowledgements 6. 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 7. References
7.1 Normative References 7.1. Normative References
[1] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate [1] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate
Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-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 7 skipping to change at page 42, line 7
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. [12] 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 7.2. Informative References
[13] Eastlake, D., Crocker, S., and J. Schiller, "Randomness [13] 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
skipping to change at page 44, line 41 skipping to change at page 45, line 41
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 53 change blocks. 
104 lines changed or deleted 104 lines changed or added

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