idnits 2.17.1 draft-ietf-rserpool-enrp-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1830. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Other values are reserved by IETF and MUST not be used. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2005) is 7006 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 1728, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3237 (ref. '2') == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-09 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 1950 (ref. '4') ** Obsolete normative reference: RFC 2246 (ref. '7') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2960 (ref. '8') (Obsoleted by RFC 4960) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '11') == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-04 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '12') -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. '13') (Obsoleted by RFC 4086) Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Q. Xie 2 Internet-Draft Motorola 3 Expires: August 22, 2005 R. Stewart 4 Cisco Systems, Inc. 5 M. Stillman 6 Nokia 7 M. Tuexen 9 A. Silverton 10 Motorola, Inc. 11 February 18, 2005 13 Endpoint Handlespace Redundancy Protocol (ENRP) 14 draft-ietf-rserpool-enrp-11.txt 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all provisions 19 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 20 author represents that any applicable patent or other IPR claims of 21 which he or she is aware have been or will be disclosed, and any of 22 which he or she become aware will be disclosed, in accordance with 23 RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 22, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work 49 in conjunction with the Aggregate Server Access Protocol (ASAP) to 50 accomplish the functionality of the Reliable Server Pooling 51 (Rserpool) requirements and architecture. Within the operational 52 scope of Rserpool, ENRP defines the procedures and message formats of 53 a distributed, fault-tolerant registry service for storing, 54 bookkeeping, retrieving, and distributing pool operation and 55 membership information. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . 6 63 2.1 ENRP_PRESENCE message . . . . . . . . . . . . . . . . . . 6 64 2.2 ENRP_HANDLE_TABLE_REQUEST message . . . . . . . . . . . . 8 65 2.3 ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . . 8 66 2.4 ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10 67 2.5 ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 11 68 2.6 ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12 69 2.7 ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13 70 2.8 ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 71 2.9 ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 14 72 2.10 ENRP_OWNERSHIP_CHANGE message . . . . . . . . . . . . . 15 73 2.11 ENRP_ERROR message . . . . . . . . . . . . . . . . . . . 17 74 3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . 18 75 3.1 Methods for Communicating amongst ENRP Servers . . . . . . 18 76 3.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 19 77 3.2.1 Generate a Server Identifier . . . . . . . . . . . . . 20 78 3.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . 20 79 3.2.3 Download ENRP Handlespace Data from Mentor Peer . . . 22 80 3.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 24 81 3.3.1 Rules on PE Re-registration . . . . . . . . . . . . . 26 82 3.4 Handle PE De-registration . . . . . . . . . . . . . . . . 26 83 3.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 27 84 3.6 Server Handlespace Update . . . . . . . . . . . . . . . . 28 85 3.6.1 Announcing Addition or Update of PE . . . . . . . . . 28 86 3.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . 29 87 3.7 Detecting and Removing Unreachable PE . . . . . . . . . . 29 88 3.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 30 89 3.9 Maintaining Peer List and Monitoring Peer Status . . . . . 31 90 3.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . 31 91 3.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . 31 92 3.9.3 Detecting Peer Server Failure . . . . . . . . . . . . 31 93 3.10 Taking-over a Failed Peer Server . . . . . . . . . . . . 32 94 3.10.1 Initiate Server Take-over Arbitration . . . . . . . 32 95 3.10.2 Take-over Target Peer Server . . . . . . . . . . . . 33 97 3.11 Handlespace Data Auditing and Re-synchronization . . . . 34 98 3.11.1 Auditing Procedures . . . . . . . . . . . . . . . . 34 99 3.11.2 PE Checksum Calculation Algorithm . . . . . . . . . 34 100 3.11.3 Re-synchronization Procedures . . . . . . . . . . . 35 101 3.12 Handling Unrecognized Message or Unrecognized 102 Parameter . . . . . . . . . . . . . . . . . . . . . . . 36 103 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . 37 104 4.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 37 105 4.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 37 106 5. Security Considerations . . . . . . . . . . . . . . . . . . 38 107 5.1 Implementing Security Mechanisms . . . . . . . . . . . . . 39 108 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 109 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 110 7.1 Normative References . . . . . . . . . . . . . . . . . . . 42 111 7.2 Informative References . . . . . . . . . . . . . . . . . . 43 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 113 Intellectual Property and Copyright Statements . . . . . . . 45 115 1. Introduction 117 ENRP is designed to work in conjunction with ASAP [1] to accomplish 118 the functionality of Rserpool as defined by its requirements [2] and 119 architecture [3]. 121 Within the operational scope of Rserpool, ENRP defines the procedures 122 and message formats of a distributed fault-tolerant registry service 123 for storing, bookkeeping, retrieving, and distributing pool operation 124 and membership information. 126 Whenever appropriate, in the rest of this document we will refer to 127 this Rserpool registry service as ENRP handlespace, or simply 128 handlespace. 130 1.1 Definitions 132 This document uses the following terms: 134 Operational scope: See [3]; 136 Pool (or server pool): See [3]; 138 Pool handle: See [3]; 140 Pool element (PE): See [3]; 142 Pool user (PU): See [3]; 144 Pool element handle: See [3]; 146 ENRP handlespace (or handlespace): See [3]; 148 ENRP client channel: The communication channel through which an ASAP 149 User (either a PE or PU) requests ENRP handlespace service. The 150 client channel is usually defined by the transport address of the 151 home server and a well known port number. The channel MAY make 152 use of multi-cast or a named list of ENRP servers. 154 ENRP server channel: Defined by a well known multicast IP address and 155 a well known port number. All ENRP servers in an operational 156 scope can send multicast messages to other servers through this 157 channel. PEs are also allowed to multicast on this channel 158 occasionally; 160 Home ENRP server: The ENRP server to which a PE or PU currently 161 belongs. A PE MUST only have one home ENRP server at any given 162 time and both the PE and its home ENRP server MUST keep track of 163 this master/slave relationship between them. A PU SHOULD select 164 one of the available ENRP servers as its home ENRP server, but the 165 ENRP server does not need to know, nor does it need to keep track 166 of this relationship. 168 1.2 Conventions 170 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 171 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 172 they appear in this document, are to be interpreted as described in 173 [6]. 175 2. ENRP Message Definitions 177 In this section, we defines the format of all ENRP messages. These 178 are messages sent and received amongst ENRP servers in an operational 179 scope. Messages sent and received between a PE/PU and an ENRP server 180 are part of ASAP and are defined in [1]. A common format, defined in 181 [11], is used for all ENRP and ASAP messages. 183 Most ENRP messages contains a combination of fixed fields and TLV 184 parameters. The TLV parameters are also defined in [11]. 186 All messages, as well as their fields/parameters described below, 187 MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., 188 the most significant byte first). 190 For ENRP, the following message types are defined: 192 Type Message Name 193 ----- ------------------------- 194 0x00 - (reserved by IETF) 195 0x01 - ENRP_PRESENCE 196 0x02 - ENRP_HANDLE_TABLE_REQUEST 197 0x03 - ENRP_HANDLE_TABLE_RESPONSE 198 0x04 - ENRP_HANDLE_UPDATE 199 0x05 - ENRP_LIST_REQUEST 200 0x06 - ENRP_LIST_RESPONSE 201 0x07 - ENRP_INIT_TAKEOVER 202 0x08 - ENRP_INIT_TAKEOVER_ACK 203 0x09 - ENRP_TAKEOVER_SERVER 204 0x0a - ENRP_OWNERSHIP_CHANGE 205 0x0b - ENRP_ERROR 206 0x0c-0xff - (reserved by IETF) 208 2.1 ENRP_PRESENCE message 210 This ENRP message is used to announce (periodically) the presence of 211 an ENRP server, or to probe the status of a peer ENRP sever. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type = 0x01 |0|0|0|0|0|0|0|R| Message Length | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Sender Server's ID | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Receiver Server's ID | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 : PE Checksum Param : 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 : Server Information Param (optional) : 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 R (reply_required) flag: 1 bit 229 Set to '1' if the sender requires a response to this message, 230 otherwise set to '0'. 232 Sender Server's ID: 32 bit (unsigned integer) 234 This is the ID of the ENRP server which sends the message. 236 Receiver Server's ID: 32 bit (unsigned integer) 238 This is the ID of the ENRP server to which the message is 239 intended. If the message is not intended to an individual 240 server (e.g., the message is multicasted to a group of 241 servers), this field MUST be set with all 0's. 243 PE Checksum Parameter: 245 This is a TLV that contains the latest PE checksum of the ENRP 246 server who sends the ENRP_PRESENCE. This parameter SHOULD be 247 included for handlespace consistency auditing. See 248 Section 3.11.1 for details. 250 Server Information Parameter: 252 If present, contains the server information of the sender of 253 this message (Server Information Parameter is defined in [11]). 254 This parameter is optional. However, if this message is sent 255 in response to a received "reply required" ENRP_PRESENCE from a 256 peer, the sender then MUST include its server information. 258 Note, at startup an ENRP server MUST pick a randomly generated, 259 non-zero 32-bit unsigned integer as its ID and MUST use this same ID 260 for its entire life. 262 2.2 ENRP_HANDLE_TABLE_REQUEST message 264 An ENRP server sends this message to one of its peers to request a 265 copy of the handlespace data. This message is normally used during 266 server initialization or handlespace re-synchronization. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Sender Server's ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Receiver Server's ID | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 W (oWn-children-only) flag: 1 bit 280 Set to '1' if the sender of this message is only requesting 281 information about the PEs owned by the message receiver. 282 Otherwise, set to '0'. 284 Sender Server's ID: 286 See Section 2.1. 288 Receiver Server's ID: 290 See Section 2.1. 292 2.3 ENRP_HANDLE_TABLE_RESPONSE message 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type = 0x03 |0|0|0|0|0|0|M|R| Message Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Sender Server's ID | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Receiver Server's ID | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 : : 303 : Pool entry #1 (see below) : 304 : : 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 : : 307 : ... : 308 : : 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 : : 311 : Pool entry #n (see below) : 312 : : 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 M (More_to_send) flag: 1 bit 317 Set to '1' if the sender has more pool entries to sent in 318 subsequent ENRP_HANDLE_TABLE_RESPONSE messages, otherwise, set 319 to '0'. 321 R (Reject) flag: 1 bit 323 MUST be set to '1' if the sender of this message is rejecting a 324 handlespace request. In such a case, this message MUST be sent 325 with no pool entries included. 327 Message Length: 16 bits (unsigned integer) 329 Indicates the entire length of the message in number of octets. 331 Note, the value in Message Length field will NOT cover any 332 padding at the end of this message. 334 Sender Server's ID: 336 See Section 2.1. 338 Receiver Server's ID: 340 See Section 2.1. 342 Pool entry #1-#n: 344 If R flag is '0', at least one pool entry SHOULD be present in 345 the message. Each pool entry MUST start with a pool handle 346 parameter as defined in section 3.1.7, followed by one or more 347 pool element parameters, i.e.: 349 +---------------------------+ 350 : Pool handle : 351 +---------------------------+ 352 : PE #1 : 353 +---------------------------+ 354 : PE #2 : 355 +---------------------------+ 356 : ... : 357 +---------------------------+ 358 : PE #n : 359 +---------------------------+ 361 2.4 ENRP_HANDLE_UPDATE message 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Sender Server's ID | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Receiver Server's ID | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Update Action | (reserved) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 : Pool handle : 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 : Pool Element : 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Message Length: 16 bits (unsigned integer) 381 Indicates the entire length of the message in number of octets. 383 Note, the value in Message Length field will NOT cover any 384 padding at the end of this message. 386 Update Action: 16 bits (unsigned integer) 388 This field indicates what act is requested to the specified PE. 389 It MUST take one of the following values: 391 0x0 - ADD_PE: add or update the specified PE in the ENRP 392 handlespace 394 0x1 - DEL_PE: delete the specified PE from the ENRP 395 handlespace. 397 Other values are reserved by IETF and MUST not be used. 399 Reserved: 16 bits 401 MUST be set to 0's by sender and ignored by the receiver. 403 Sender Server's ID: 405 See Section 2.1. 407 Receiver Server's ID: 409 See Section 2.1. 411 Pool handle: 413 Specifies to which the PE belongs. 415 Pool Element: 417 Specifies the PE. 419 2.5 ENRP_LIST_REQUEST message 421 This ENRP message is used to request a copy of the current known ENRP 422 peer server list. This message is normally sent from a newly started 423 ENRP server to an existing ENRP server as part of the initialization 424 process of the new server. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Sender Server's ID | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Receiver Server's ID | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Sender Server's ID: 438 See Section 2.1. 440 Receiver Server's ID: 442 See Section 2.1. 444 2.6 ENRP_LIST_RESPONSE message 446 This message is used to respond an ENRP_LIST_REQUEST. 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type = 0x06 |0|0|0|0|0|0|0|R| Message Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Sender Server's ID | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Receiver Server's ID | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 : Server Info Param of Peer #1 : 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 : ... : 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 : Server Info Param of Peer #n : 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 R (Reject) flag: 1 bit 466 MUST be set to '1' if the sender of this message is rejecting a 467 peer list request. In such a case, this message MUST be sent 468 with no peer server ID included. 470 Message Length: 16 bits (unsigned integer) 472 Indicates the entire length of the message in number of octets. 474 Note, the value in Message Length field will NOT cover any 475 padding at the end of this message. 477 Sender Server's ID: 479 See Section 2.1. 481 Receiver Server's ID: 483 See Section 2.1. 485 Server Information Parameter of Peer #1-#n: 487 Each contains a Server Information Parameter of a peer known to 488 the sender. The Server Information Parameter is defined in 489 [11]. 491 2.7 ENRP_INIT_TAKEOVER message 493 This message is used by an ENRP server (the takeover initiator) to 494 declare its intention of taking over a specific peer ENRP server. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Sender Server's ID | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Receiver Server's ID | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Target Server's ID | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Sender Server's ID: 510 See Section 2.1. 512 Receiver Server's ID: 514 See Section 2.1. 516 Target Server's ID: 518 Contains the 32-bit server ID of the peer ENRP that is the 519 target of this takeover attempt. 521 2.8 ENRP_INIT_TAKEOVER_ACK message 523 This message is used to acknowledge the takeover initiator that the 524 sender of this message received the ENRP_INIT_TAKEOVER message and 525 that it does not object to the takeover. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Sender Server's ID | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Receiver Server's ID | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Target Server's ID | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Sender Server's ID: 541 See Section 2.1. 543 Receiver Server's ID: 545 See Section 2.1. 547 Target Server's ID: 549 Contains the 32-bit server ID of the peer ENRP that is the 550 target of this takeover attempt. 552 2.9 ENRP_TAKEOVER_SERVER message 554 This message is used by the takeover initiator to declare that a 555 takeover is underway. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Sender Server's ID | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Receiver Server's ID | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Target Server's ID | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Sender Server's ID: 571 See Section 2.1. 573 Receiver Server's ID: 575 See Section 2.1. 577 Target Server's ID: 579 Contains the 32-bit server ID of the peer ENRP that is the 580 target of this takeover operation. 582 2.10 ENRP_OWNERSHIP_CHANGE message 584 This message is used by the ENRP server, normally after a successful 585 takeover, to declare that it is now the new home ENRP server of the 586 listed PEs in the listed pools. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Sender Server's ID | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Receiver Server's ID | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 : Pool handle #1 : 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 : PE Identifier Param #1 of pool #1 : 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 : ... : 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 : PE Identifier Param #k of pool #1 : 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 : : 606 : ... : 607 : : 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 : Pool handle #M : 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 : PE Identifier Param #1 of pool #M : 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 : ... : 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 : PE Identifier Param #n of pool #M : 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Sender Server's ID: 620 See Section 2.1. 622 Receiver Server's ID: 624 See Section 2.1. 626 Pool handles and PE Identifier parameters: 628 Each listed pool handle is followed by a list of PE Identifier 629 parameters, indicating that the sender of this message is 630 taking ownership of the listed PEs in the pool. 632 2.11 ENRP_ERROR message 634 This message is used by an ENRP server to report an operational error 635 to one of its peers. 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Sender Server's ID | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Receiver Server's ID | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 : Operational Error Parameter : 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Sender Server's ID: 651 See Section 2.1. 653 Receiver Server's ID: 655 See Section 2.1. 657 Operational Error Parameter: 659 This parameter, defined in [11], indicates the type of error(s) 660 being reported. 662 3. ENRP Operation Procedures 664 In this section, we discuss the operation procedures defined by ENRP. 665 An ENRP server MUST following these procedures when sending, 666 receiving, or processing ENRP messages. 668 Many of the Rserpool events call for both server-to-server and 669 PU/PE-to-server message exchanges. Only the message exchanges and 670 activities between an ENRP server and its peer(s) are considered 671 within the ENRP scope and are defined in this document. 673 Procedures for exchanging messages between a PE/PU and ENRP servers 674 are defined in [1]. 676 3.1 Methods for Communicating amongst ENRP Servers 678 Within an Rserpool operational scope, ENRP servers need to 679 communicate with each other in order to exchange information such as 680 the pool membership changes, handlespace data synchronization, etc. 682 Two types of communications are used amongst ENRP servers: 684 o point-to-point message exchange from one ENPR server to a specific 685 peer server, and 687 o announcements from one server to all its peer servers in the 688 operational scope. 690 Point-to-point communication is always carried out over an SCTP 691 association between the sending server and the receiving server. 693 Announcements are communicated out with one of the following two 694 approaches: 696 1. The sending server sends the announcement message to a well-known 697 RSERPOOL IP multicast channel that its peer servers subscribe to. 699 Note: Because IP multicast is not reliable, this approach does 700 not guarantee that all the peers will receive the announcement 701 message. Moreover, since IP multicast is not secure, this 702 approach cannot provide any security to the communication. 704 2. The sending server sends multiple copies of the announcement, one 705 to each of its peer servers, over a set of point-to-point SCTP 706 associations between the sending server and the peers. 708 This approach guarantees the reliable reception of the message. 709 When needed, data security can be achieved by using IP security 710 mechanisms such as IPsec [10] or TLS [9]. 712 In order to maximize inter-operability of ENRP servers, the following 713 rules MUST be followed: 715 1. At the startup time, a new ENRP server SHOULD make a decision on 716 whether it will enable IP multicast for ENRP announcements. This 717 decision should be based on factors such as the availability of 718 IP multicast and the security requirements from the user of 719 Rserpool. 721 2. If an ENRP server disables multicast, it then: 723 A. MUST NOT subscribe to the well-known server multicast 724 channel, i.e., it only receives peer announcements over SCTP 725 associations, and 727 B. MUST transmit all its out-going announcements over 728 point-to-point SCTP associations with its peers. 730 3. If an ENRP server enables itself to use multicast, it then: 732 A. MUST subscribe to the well-known server multicast channel to 733 ready itself for receiving peers' multicast announcements, 735 B. MUST also be prepared to receive peer announcements over 736 point-to-point SCTP associations from peers. 738 C. MUST track internally which peers are multicast-enabled and 739 which are not. Note: A peer is always assumed to be 740 multicast-disabled until/unless an ENRP message of any type 741 is received from that peer over the well-known server 742 multicast channel. 744 D. when sending out an announcement, MUST send a copy to the 745 well-known server multicast channel AND a copy to each of the 746 peers that are marked as multicast-disabled over a 747 point-to-point SCTP association. 749 3.2 ENRP Server Initialization 751 This section describes the steps a new ENRP server needs to take in 752 order to join the other existing ENRP servers, or to initiate the 753 handlespace service if it is the first ENRP server started in the 754 operational scope. 756 3.2.1 Generate a Server Identifier 758 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 759 as unique as possible in the operational scope and this server Id 760 MUST remain unchanged for the lifetime of the server. Normally, a 761 good 32-bit random number will be good enough as the server Id ([13] 762 provides some information on randomness guidelines). 764 Note, there is a very remote chance (about 1 in 4 billion) that two 765 ENRP servers in an operational scope will generate the same server Id 766 and hence cause a server Id conflict in the pool. However, no severe 767 consequence of such a conflict has been identified. 769 3.2.2 Acquire Peer Server List 771 At startup, the ENRP server (initiating server) will first attempt to 772 learn all existing peer ENRP servers in the same operational scope, 773 or to determine that it is along in the scope. 775 The initiating server uses an existing peer server to bootstrap 776 itself into service. We call this peer server the mentor server. 778 3.2.2.1 Find the mentor server 780 If the initiating server is told about an existing peer server 781 through some administrative means (such as DNS query, configuration 782 database, startup scripts, etc), the initiating server SHOULD then 783 use this peer server as its mentor server and SHOULD skip the 784 remaining steps in this subsection. 786 If multiple existing peer servers are specified, the initiating 787 server SHOULD pick one of them as its mentor peer server, keep the 788 others as its backup mentor peers, and skip the remaining steps in 789 this subsection. 791 If no existing peer server is specified to the initiating server AND 792 if multicast is available in the operational scope, the following 793 mentor peer discovery procedures SHOULD be followed: 795 1. The initiating server SHOULD first join the well-known ENRP 796 server multicast channel. 798 2. Then the initiating server SHOULD send an ENRP_PRESENCE message, 799 with the 'Reply_required' flag set, over the multicast channel. 800 Upon the reception of this ENRP_PRESENCE message, a peer server 801 MUST send an ENRP_PRESENCE, without the 'Reply_required' flag, 802 back to the initiating server. 804 3. When the first response to its original ENRP_PRESENCE arrives, 805 the initiating server SHOULD take the sender of this received 806 response as its mentor peer server. This completes the discovery 807 of the mentor peer server. 809 If responses are also received from other peers (a likely event 810 when multiple peers exist in the operational scope at the time 811 the new server started), the initiating server SHOULD keep a list 812 of those responded as its backup mentor peers (see below). 814 4. If no response to its ENRP_PRESENCE message are received after 815 TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat 816 steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After 817 that, if there is still no response, the initiating server MUST 818 assume that it is alone in the operational scope. 820 5. If the initiating server determined that it is alone in the 821 scope, it MUST skip the procedures in Section 3.2.2.2 and 822 Section 3.2.3 and MUST consider its initialization completed and 823 start offering ENRP services. 825 Note, if multicast is not available (or not allowed for reasons such 826 as security concerns) in the operational scope, at least one peer 827 server MUST be specified to the initiating server through 828 administrative means, unless the initiation server is the first 829 server to start in the operational scope. 831 Note, if the administratively specified mentor peer(s) fails, the 832 initiating server SHOULD use the auto-discover procedure defined in 833 steps 1-5 above. 835 3.2.2.2 Request complete server list from mentor peer 837 Once the initiating server finds its mentor peer server (by either 838 discovery or administrative means), the initiating server MUST send 839 an ENRP_LIST_REQUEST message to the mentor peer server to request a 840 copy of the complete server list maintained by the mentor peer (see 841 Section 3.9 for maintaining server list). 843 Upon the reception of this request, the mentor peer server SHOULD 844 reply with an ENRP_LIST_RESPONSE message and include in the message 845 body all existing ENRP servers known by the mentor peer. 847 Upon the reception of the ENRP_LIST_RESPONSE message from the mentor 848 peer, the initiating server MUST use the server information carried 849 in the message to initialize its own peer list. 851 However, if the mentor itself is in the process of startup and not 852 ready to provide a peer server list (for example, the mentor peer is 853 waiting for a response to its own ENRP_LIST_REQUEST to another 854 server), it MUST reject the request by the initiating server and 855 respond with an ENRP_LIST_RESPONSE message with the R flag set to 856 '1', and with no server information included in the response. 858 In the case where its ENRP_LIST_REQUEST is rejected by the mentor 859 peer, the initiating server SHOULD either wait for a few seconds and 860 re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a 861 backup mentor peer available, select another mentor peer server and 862 send the ENRP_LIST_REQUEST to the new mentor server. 864 3.2.3 Download ENRP Handlespace Data from Mentor Peer 866 After a peer list download is completed, the initiating server MUST 867 request a copy of the current handlespace data from its mentor peer 868 server, by taking the following steps: 870 1. The initiating server MUST first send a ENRP_HANDLE_TABLE_REQUEST 871 message to the mentor peer, with W flag set to '0', indicating 872 that the entire handlespace is requested. 874 2. Upon the reception of this message, the mentor peer MUST start a 875 download session in which a copy of the current handlespace data 876 maintained by the mentor peer is sent to the initiating server in 877 one or more ENRP_HANDLE_TABLE_RESPONSE messages (Note, the mentor 878 server may find it particularly desirable to use multiple 879 ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when 880 the handlespace is large, especially when forming and sending out 881 a single response containing a large handlespace may interrupt 882 its other services). 884 If more than one ENRP_HANDLE_TABLE_RESPONSE message are used 885 during the download, the mentor peer MUST use the M flag in each 886 ENRP_HANDLE_TABLE_RESPONSE message to indicate whether this 887 message is the last one for the download session. In particular, 888 the mentor peer MUST set the M flag to '1' in the outbound 889 ENRP_HANDLE_TABLE_RESPONSE if there is more data to be 890 transferred and MUST keep track of the progress of the current 891 download session. The mentor peer MUST set the M flag to '0' in 892 the last ENRP_HANDLE_TABLE_RESPONSE for the download session and 893 close the download session (i.e., removing any internal record of 894 the session) after sending out the last message. 896 3. During the downloading, every time the initiating server receives 897 an ENRP_HANDLE_TABLE_RESPONSE message, it MUST transfer the data 898 entries carried in the message into its local handlespace 899 database, and then check whether or not this message is the last 900 one for the download session. 902 If the M flag is set to '1' in the just processed 903 ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST 904 send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer 905 to request for the next ENRP_HANDLE_TABLE_RESPONSE message. 907 4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE 908 message into its local handlespace database, the initiating 909 server MUST handle each pool entry carried in the message using 910 the following rules: 912 A. If the pool does not exist in the local handlespace, the 913 initiating server MUST creates the pool in the local 914 handlespace and add the PE(s) in the pool entry to the pool. 916 When creating the pool, the initiation server MUST set the 917 overall member selection policy type of the pool to the 918 policy type indicated in the first PE. 920 B. If the pool already exists in the local handlespace, but the 921 PE(s) in the pool entry is not currently a member of the 922 pool, the initiating server MUST add the PE(s) to the pool. 924 C. If the pool already exists in the local handlespace AND the 925 PE(s) in the Pool entry is already a member of the pool, the 926 initiating server SHOULD replace the attributes of the 927 existing PE(s) with the new information. 929 5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from 930 the mentor peer and unpacked into the local handlespace, the 931 initialization process is completed and the initiating server 932 SHOULD start to provide ENRP services. 934 Under certain circumstances, the mentor peer itself may not be able 935 to provide a handlespace download to the initiating server. For 936 example, the mentor peer is in the middle of initializing its own 937 handlespace database, or it has currently too many download sessions 938 open to other servers. 940 In such a case, the mentor peer MUST reject the request by the 941 initiating server and respond with an ENRP_HANDLE_TABLE_RESPONSE 942 message with the R flag set to '1', and with no pool entries included 943 in the response. 945 In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the 946 mentor peer, the initiating server SHOULD either wait for a few 947 seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor 948 server, or if there is a backup mentor peer available, select another 949 mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new 950 mentor server. 952 A started handlespace download session may get interrupted for some 953 reason. To cope with this, the initiating server SHOULD start a 954 timer every time it finishes sending an ENRP_HANDLE_TABLE_REQUEST to 955 its mentor peer. If this timer expires without receiving a response 956 from the mentor peer, the initiating server SHOULD abort the current 957 download session and re-start a new handlespace download with a 958 backup mentor peer, if one is available. 960 Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, if the 961 mentor peer has still more data to send, it SHOULD start a session 962 timer. If this timer expires without receiving another request from 963 the initiating server, the mentor peer SHOULD abort the session, 964 cleaning out any resource and record of the session. 966 3.3 Handle PE Registration 968 To register itself with the handlespace, a PE sends an 969 ASAP_REGISTRATION message to its home ENRP server. The format of 970 ASAP_REGISTRATION message and rules of sending it are defined in [1]. 972 In the ASAP_REGISTRATION message, the PE indicates the handle of the 973 pool it wishes to join in a pool handle parameter, and its complete 974 transport information and any load control information in a PE 975 parameter. 977 The ENRP server handles the ASAP_REGISTRATION message according to 978 the following rules: 980 1. If the named pool does not exist in the handlespace, the ENRP 981 server MUST creates a new pool with that handle in the 982 handlespace and add the PE to the pool as its first PE; 984 When a new pool is created, the overall member selection policy 985 of the pool MUST be set to the policy type indicated by the first 986 PE, the overall pool transport type MUST be set to the transport 987 type indicated by the PE, and the overall pool data/control 988 channel configuration MUST be set to what is indicated in the 989 Transport Use field of the User Transport parameter by the 990 registering PE. 992 2. If the named pool already exists in the handlespace, but the 993 requesting PE is not currently a member of the pool, the ENRP 994 server will add the PE as a new member to the pool; 995 However, before adding the PE to the pool, the server MUST check 996 if the policy type, transport type, and transport usage indicated 997 by the registering PE is consistent with those of the pool. If 998 different, the ENRP server MUST reject the registration. 1000 3. If the named pool already exists in the handlespace AND the 1001 requesting PE is already a member of the pool, the ENRP server 1002 SHOULD consider this as a re-registration case. The ENRP server 1003 MUST perform the same tests on policy, transport type, transport 1004 use, as described above. If the re-registration is accepted 1005 after the test, the ENRP Server SHOULD replace the attributes of 1006 the existing PE with the information carried in the received 1007 ASAP_REGISTRATION message. 1009 4. After accepting the registration, the ENRP server MUST assign 1010 itself the owner of this PE. If this is a re-registration, the 1011 ENRP server MUST take over ownership of this PE regardless of 1012 whether the PE was previously owned by this server or by another 1013 server. The ENRP server MUST also record the SCTP transport 1014 address from which it received the ASAP_REGISTRATION in the ASAP 1015 Transport parameter TLV inside the PE parameter of this PE. 1017 5. The ENRP server may reject the registration due to other reasons 1018 such as invalid values, lack of resource, authentication failure, 1019 etc. 1021 In all above cases, the ENRP server MUST reply to the requesting PE 1022 with an ASAP_REGISTRATION_RESPONSE message. If the registration is 1023 accepted, the ENRP server MUST set the 'R' flag in the 1024 ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, 1025 the ENRP server MUST indicate the rejection by setting the 'R' flag 1026 in the ASAP_REGISTRATION_RESPONSE to '1'. 1028 If the registration is rejected, the ENRP server SHOULD include the 1029 proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message. 1031 If the registration is granted (either a new registration or a 1032 re-registration case), the ENRP server MUST assign itself to be the 1033 home ENRP server of the PE, i.e., to "own" the PE. 1035 Implementation note: for better performance, the ENRP server may 1036 find it both efficient and convenient to internally maintain two 1037 separate PE lists or tables - one is for the PEs that are "owned" 1038 by the ENRP server and the other for all the PEs owned by its 1039 peer(s). 1041 Moreover, if the registration is granted, the ENRP server MUST take 1042 the handlespace update action as described in Section 3.6 to inform 1043 its peers about the change just made. If the registration is denied, 1044 no message will be sent to its peers. 1046 3.3.1 Rules on PE Re-registration 1048 A PE may re-register itself to the handlespace with a new set of 1049 attributes in order to, for example, extend its registration life, 1050 change its load factor value, etc. 1052 A PE may modify its load factor value at any time via 1053 re-registration. Based on the number of PEs in the pool and the 1054 pool's overall policy type, this operation allows the PE to 1055 dynamically control its share of inbound messages received by the 1056 pool (also see Section ???? in [1] for more on load control). 1058 Moreover, when re-registering, the PE MUST NOT change its policy 1059 type. The server MUST reject the re-registration if the PE attempt 1060 to change its policy type. In the rejection, the server SHOULD 1061 attach an error code "Pooling Policy Inconsistent". 1063 Regardless whether it is the current owner of the PE, if the 1064 re-registration is granted to the PE, the ENRP server MUST assign 1065 itself to be the new home ENRP server of the PE. 1067 Moreover, if the re-registration is granted, the ENRP server MUST 1068 take the handlespace update action as described in Section 3.6 to 1069 inform its peers about the change just made. If the re-registration 1070 is denied, no message will be sent to its peers. 1072 3.4 Handle PE De-registration 1074 To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION 1075 message to its home ENRP server. The complete format of 1076 ASAP_DEREGISTRATION message and rules of sending it are defined in 1077 [1]. 1079 In the ASAP_DEREGISTRATION message the PE indicates the handle of the 1080 pool it belongs to in a pool handle parameter and provides its PE 1081 identifier. 1083 Upon receiving the message, the ENRP server SHALL remove the PE from 1084 its handlespace. Moreover, if the PE is the last one of the named 1085 pool, the ENRP server will remove the pool from the handlespace as 1086 well. 1088 If the ENRP server fails to find any record of the PE in its 1089 handlespace, it SHOULD consider the de-registration granted and 1090 completed. 1092 The ENRP server may reject the de-registration request for various 1093 reasons, such as invalid parameters, authentication failure, etc. 1095 In response, the ENRP server MUST send an 1096 ASAP_DEREGISTRATION_RESPONSE message to the PE. If the 1097 de-registration is rejected, the ENRP server MUST indicate the 1098 rejection by including the proper Operational Error parameter. 1100 It should be noted that de-registration does not stop the PE from 1101 sending or receiving application messages. 1103 Once the de-registration request is granted AND the PE removed from 1104 its local copy of the handlespace, the ENRP server MUST take the 1105 handlespace update action described in Section 3.6 to inform its 1106 peers about the change just made. Otherwise, NO message SHALL be 1107 send to its peers. 1109 3.5 Pool Handle Translation 1111 A PU uses the pool handle translation service of an ENRP server to 1112 resolve a pool handle to a list of accessible transport addresses of 1113 the member PEs of the pool. 1115 This requires the PU to send an ASAP_HANDLE_RESOLUTION message to its 1116 home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify 1117 the pool handle to be translated in a Pool Handle parameter. 1118 Complete definition of the ASAP_HANDLE_RESOLUTION message and the 1119 rules of sending it are defined in [1]. 1121 An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION 1122 requests from PUs either over an SCTP association on the well-know 1123 SCTP port, or over a TCP connection on the well-know TCP port. 1125 Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server 1126 MUST first look up the pool handle in its handlespace. If the pool 1127 exits, the home ENRP server MUST compose and send back an 1128 ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. 1130 In the response message, the ENRP server SHOULD list all the PEs 1131 currently registered in this pool, in a list of PE parameters. The 1132 ENRP server MUST also include a pool member selection policy 1133 parameter to indicate the overall member selection policy for the 1134 pool, if the current pool member selection policy is not round-robin 1135 (if the overall policy is round-Robin, this parameter MAY be 1136 omitted?). 1138 If the named pool does not exist in the handlespace, the ENRP server 1139 MUST reject the handle resolution request by responding with an 1140 ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor 1141 Handle error. 1143 The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and 1144 the rules of receiving it are defined in [1]. 1146 3.6 Server Handlespace Update 1148 This includes a set of update operations used by an ENRP server to 1149 inform its peers when its local handlespace is modified, e.g., 1150 addition of a new PE, removal of an existing PE, change of pool or PE 1151 properties. 1153 3.6.1 Announcing Addition or Update of PE 1155 When a new PE is granted registration to the handlespace or an 1156 existing PE is granted a re-registration, the home ENRP server uses 1157 this procedure to inform all its peers. 1159 This is an ENRP announcement and is sent to all the peer of the home 1160 ENRP server. See Section 3.1 on how announcements are sent. 1162 An ENRP server MUST announce this update to all its peers in a 1163 ENRP_HANDLE_UPDATE message with the Update Action field set to 1164 ADD_PE, indicating the addition of a new PE or the modification of an 1165 existing PE. The complete new information of the PE and the pool its 1166 belongs to MUST be indicated in the message with a PE parameter and a 1167 Pool Handle parameter, respectively. 1169 The home ENRP server SHOULD fill in its server Id in the Sender 1170 Server's ID field and leave the Receiver Server's ID blank (i.e., all 1171 0's). 1173 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take 1174 the following actions: 1176 1. If the named pool indicated by the pool handle does not exist in 1177 its local copy of the handlespace, the peer MUST create the named 1178 pool in its local handlespace and add the PE to the pool as the 1179 first PE. It MUST then copy in all other attributes of the PE 1180 carried in the message. 1182 When the new pool is created, the overall member selection policy 1183 of the pool MUST be set to the policy type indicated by the PE. 1185 2. If the named pool already exists in the peer's local copy of the 1186 handlespace AND the PE does not exist, the peer MUST add the PE 1187 to the pool as a new PE and copy in all attributes of the PE 1188 carried in the message. 1190 3. If the named pool exists AND the PE is already a member of the 1191 pool, the peer MUST replace the attributes of the PE with the new 1192 information carried in the message. 1194 3.6.2 Announcing Removal of PE 1196 When an existing PE is granted de-registration or is removed from its 1197 handlespace for some other reasons (e.g., purging an unreachable PE, 1198 see Section 3.7), the ENRP server MUST uses this procedure to inform 1199 all its peers about the change just made. 1201 This is an ENRP announcement and is sent to all the peer of the home 1202 ENRP server. See Section 3.1 on how announcements are sent. 1204 An ENRP server MUST announce the PE removal to all its peers in an 1205 ENRP_HANDLE_UPDATE message with the Update Action field set to 1206 DEL_PE, indicating the removal of an existing PE. The complete 1207 information of the PE and the pool its belongs to MUST be indicated 1208 in the message with a PE parameter and a Pool Handle parameter, 1209 respectively. 1211 [editor's note: only the pool handle and the PE's id are needed, it 1212 should reduce the size of the message] 1214 The sending server MUST fill in its server ID in the Sender Server's 1215 ID field and leave the Receiver Server's ID blank (i.e., set to all 1216 0's). 1218 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first 1219 find pool and the PE in its own handlespace, and then remove the PE 1220 from its local handlespace. If the removed PE is the last one in the 1221 pool, the peer MUST also delete the pool from its local handlespace. 1223 If the peer fails to find the PE or the pool in its handlespace, it 1224 SHOULD take no further actions. 1226 3.7 Detecting and Removing Unreachable PE 1228 Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 1229 Notification, see section 10.2 of [8]), the PU SHOULD send an 1230 ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The 1231 message SHOULD contain the pool handle and the PE Id of the 1232 unreachable PE. 1234 Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server 1235 MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE 1236 message to the PE in question. If this ASAP_ENDPOINT_KEEP_ALIVE 1237 fails (e.g., it results in an SCTP SEND.FAILURE notification), the 1238 ENRP server MUST consider the PE as truly unreachable and MUST remove 1239 the PE from its handlespace and take actions described in 1240 Section 3.6.2. 1242 If the ASAP_ENDPOINT_UNREACHABLE message is transmitted successfully 1243 to the PE, the ENRP server MUST retain the PE in its handlespace. 1244 Moreover, the server SHOULD keep a counter to record how many 1245 ASAP_ENDPOINT_UNREACHABLE messages it has received reporting 1246 reachability problem relating to this PE. If the counter exceeds the 1247 protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove 1248 the PE from its handlespace and take actions described in 1249 Section 3.6.2. 1251 Optionally, an ENRP server may also periodically send point-to-point 1252 ASAP_ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the 1253 ENRP server in order to check their reachability status. If the send 1254 of ASAP_ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST 1255 consider the PE as unreachable and MUST remove the PE from its 1256 handlespace and take actions described in Section 3.6.2. Note, if an 1257 ENRP server owns a large number of PEs, the implementation should pay 1258 attention not to flood the network with bursts of 1259 ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the implementation 1260 should try to smooth out the ASAP_ENDPOINT_KEEP_ALIVE message traffic 1261 over time. 1263 The complete definition and rules of sending 1264 ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE 1265 messages are described in [1]. 1267 3.8 Helping PE and PU to Discover Home ENRP Server 1269 At its startup time, or whenever its current home ENRP server is not 1270 providing services, a PE or PU will attempt to find a new home 1271 server. For this reason, the PE or PU will need to maintain a list 1272 of currently available ENRP servers in its scope. 1274 To help the PE or PU maintaining this list, an ENRP server, if it is 1275 enabled for multicast, SHOULD periodically send out an 1276 ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to 1277 the well-known ASAP multicast channel. And in the 1278 ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the 1279 transport addresses available for ASAP communications. If the ENRP 1280 server only supports SCTP for ASAP communications, the transport 1281 information MAY be omitted in the ASAP_SERVER_ANNOUNCE message. 1283 For the complete procedure of this, see Section 3.6?? in [1]. 1285 3.9 Maintaining Peer List and Monitoring Peer Status 1287 An ENRP server MUST keep an internal record on the status of each of 1288 its known peers. This record is referred to as the server's "peer 1289 list" 1291 3.9.1 Discovering New Peer 1293 If a message of any type is received from a previously unknown peer, 1294 the ENRP server MUST consider this peer a new peer in the operational 1295 scope and add it to the peer list. 1297 The ENRP server MUST send an ENRP_PRESENCE message with the 1298 Reply-required flag set to '1' to the source address found in the 1299 arrived message. This will force the new peer to reply with its own 1300 ENRP_PRESENCE containing its full server information (see 1301 Section 2.1). 1303 [editor's note: should we ask for a peer list from the new peer? 1304 this may help mending two split networks.] 1306 3.9.2 Server Sending Heartbeat 1308 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 1309 continued presence to all its peer with a ENRP_PRESENCE message. In 1310 the ENRP_PRESENCE message, the ENRP server MUST set the 1311 'Replay_required' flag to '0', indicating that no response is 1312 required. 1314 The arrival of this periodic ENRP_PRESENCE message will cause all its 1315 peers to update their internal variable "peer.last.heard" for the 1316 sending server (see Section 3.9.3 for more details). 1318 3.9.3 Detecting Peer Server Failure 1320 An ENRP server MUST keep an internal variable "peer.last.heard" for 1321 each of its known peers and the value of this variable MUST be 1322 updated to the current local time every time a message of any type 1323 (point-to-point or announcement) is received from the corresponding 1324 peer. 1326 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 1327 seconds, the ENRP server MUST immediately send a point-to-point 1328 ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1330 If the send fails or the peer does not reply after 1331 MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer 1332 server dead and SHOULD initiate the takeover procedure defined in 1333 Section 3.10. 1335 3.10 Taking-over a Failed Peer Server 1337 In the following descriptions, We call the ENRP server that detects 1338 the failed peer server and initiates the take-over the "initiating 1339 server" and the failed peer server the "target server." 1341 3.10.1 Initiate Server Take-over Arbitration 1343 The initiating server SHOULD first start a take-over arbitration 1344 process by announcing an ENRP_INIT_TAKEOVER message to all its peer 1345 servers. See Section 3.1 on how announcements are sent. In the 1346 message, the initiating server MUST fill in the Sender Server's ID 1347 and Target Server's ID. 1349 After announcing the ENRP_INIT_TAKEOVER message, the initiating 1350 server SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from _each_ 1351 of its known peers, except of the target server. [editor's note: how 1352 long should it wait?] 1354 Each of the peer servers that receives the ENRP_INIT_TAKEOVER message 1355 from the initiating server SHOULD take the following actions: 1357 1. If the peer server finds that itself is the target server 1358 indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately 1359 announce an ENRP_PRESENCE message to all its peer ENRP servers in 1360 an attempt to stop this take-over process. This indicates a 1361 false failure detection case by the initiating server. 1363 2. If the peer server finds that itself has already started its own 1364 take-over arbitration process on the same target server, it MUST 1365 perform the following arbitration: 1367 A. if the peer's server ID is smaller in value than the Sender 1368 Server's ID in the arrived ENRP_INIT_TAKEOVER message, the 1369 peer server SHOULD immediately abort its own take-over 1370 attempt. Moreover, the peer SHOULD mark the target server as 1371 "not active" on its internal peer list so that its status 1372 will no longer be monitored by the peer, and reply the 1373 initiating server with an ENRP_INIT_TAKEOVER_ACK message. 1375 B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER 1376 message and take no action. 1378 3. If the peer finds that it is neither the target server nor is in 1379 its own take-over process, the peer SHOULD: a) mark the target 1380 server as "not active" on its internal peer list so that its 1381 status will no longer be monitored by this peer, and b) reply to 1382 the initiating server with an ENRP_INIT_TAKEOVER_ACK message. 1384 Once the initiating server has received ENRP_INIT_TAKEOVER_ACK 1385 message from _all_ of its currently known peers (except for the 1386 target server), it SHOULD consider that it has won the arbitration 1387 and SHOULD proceed to complete the take-over, following the steps 1388 described in Section 3.10.2. 1390 However, if it receives an ENRP_PRESENCE from the target server at 1391 any point in the arbitration process, the initiating server SHOULD 1392 immediately abort the take-over process and mark the status of the 1393 target server as "active". 1395 3.10.2 Take-over Target Peer Server 1397 The initiating ENRP server SHOULD first send, via an announcement, a 1398 ENRP_TAKEOVER_SERVER message to inform all its active peers that the 1399 take-over is enforced. The target server's ID MUST be filled in the 1400 message. The initiating server SHOULD then remove the target server 1401 from its internal peer list. 1403 Then it SHOULD examine its local copy of the handlespace and claim 1404 ownership of each of the PEs originally owned by the target server, 1405 by following these steps: 1407 1. mark itself as the home ENRP server of each of the PEs originally 1408 owned by the target server; 1410 2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message to each of 1411 the PEs. This will trigger the PE to adopt the initiating sever 1412 as its new home ENRP server; 1414 When a peer receives the ENRP_TAKEOVER_SERVER message from the 1415 initiating server, it SHOULD update its local peer list and PE cache 1416 by following these steps: 1418 1. remove the target server from its internal peer list; 1420 2. update the home ENRP server of each PE in its local copy of the 1421 handlespace to be the sender of the message, i.e., the initiating 1422 server. 1424 3.11 Handlespace Data Auditing and Re-synchronization 1426 Message losses or certain temporary breaks in network connectivity 1427 may result in data inconsistency in the local handlespace copy of 1428 some of the ENRP servers in an operational scope. Therefore, each 1429 ENRP server in the operational scope SHOULD periodically verify that 1430 its local copy of handlespace data is still in sync with that of its 1431 peers. 1433 This section defines the auditing and re-synchronization procedures 1434 for an ENRP server to maintain its handlespace data consistency. 1436 3.11.1 Auditing Procedures 1438 The auditing of handlespace consistency is based on the following 1439 procedures: 1441 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1442 integer internal variable) for each of its known peers and for 1443 itself. For an ENRP server with 'k' known peers, we denote these 1444 internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ..., 1445 "pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE 1446 checksum. The definition and detailed algorithm for calculating 1447 these PE checksum variables are given in Section 3.11.2. 1449 2. Each time an ENRP server sends out an ENRP_PRESENCE, it SHOULD 1450 include in the message its current PE checksum (i.e., 1451 "pe.checksum.pr0"). 1453 3. When an ENRP server (server A) receives a PE checksum (carried in 1454 an arrived ENRP_PRESENCE) from a peer ENRP server (server B), 1455 server A SHOULD compare the PE checksum found in the 1456 ENRP_PRESENCE with its own internal PE checksum of server B 1457 (i.e., "pe.checksum.prB"). 1459 4. If the two values match, server A will consider that there is no 1460 handlespace inconsistency between itself and server B and should 1461 take no further actions. 1463 5. If the two values do NOT match, server A SHOULD consider that 1464 there is a handlespace inconsistency between itself and server B 1465 and a re-synchronization process SHOULD be carried out 1466 immediately with server B (see Section 3.11.3). 1468 3.11.2 PE Checksum Calculation Algorithm 1470 When an ENRP server (server A) calculate an internal PE checksum for 1471 a peer (server B), it MUST use the following algorithm. 1473 Let us assume that in server A's internal handlespace there are 1474 currently 'M' PEs that are owned by server B. Each of the 'M' PEs 1475 will then contribute to the checksum calculation with the following 1476 byte block: 1478 0 1 2 3 1479 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 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 : Pool handle string of the pool the PE belongs (padded with : 1482 : zeros to next 32-bit word boundary if needed) : 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | PE Id (4 octets) | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 Note, these are not TLVs. This byte block gives each PE a unique 1488 byte pattern in the scope. The 32-bit PE checksum for server B 1489 "pe.checksum.prB" is then calculated over the byte blocks contributed 1490 by the 'M' PEs one by one. The PE checksum calculation MUST use the 1491 Adler-32 algorithm described in section 8.2 of RFC1950 [4]. 1493 Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") 1494 in the same fashion, using the byte blocks of all the PEs owned by 1495 itself. 1497 Note, whenever an ENRP finds that its internal handlespace has 1498 changed (e.g., due to PE registration/deregistration, receiving peer 1499 updates, removing failed PEs, downloading handlespace pieces from a 1500 peer, etc.), it MUST immediately update all its internal PE checksums 1501 that are affected by the change. 1503 Implementation Note: when the internal handlespace changes (e.g., a 1504 new PE added or an existing PE removed), an implementation needs not 1505 to re-calculate the affected PE checksum; it should instead simply 1506 update the checksum by adding or subtracting the byte block of the 1507 corresponding PE from the previous checksum value. 1509 3.11.3 Re-synchronization Procedures 1511 Once an ENRP server determines that there is inconsistency between 1512 its local handlespace data and a peer's handlespace data with 1513 regarding to the PEs owned by that peer, it SHOULD perform the 1514 following steps to re-synchronize the data: 1516 1. The ENRP server SHOULD first "mark" every PE it knows about that 1517 is owned by the peer in its local handlespace database; 1519 2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST 1520 message with W flag set to '1' to the peer to request a complete 1521 list of PEs owned by the peer; 1523 3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with W 1524 flag set to '1', the peer server SHOULD immediately respond with 1525 an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently 1526 owned by the peer. 1528 4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the 1529 ENRP server SHOULD transfer the PE entries carried in the message 1530 into its local handlespace database. If an PE entry being 1531 transferred already exists in its local database, the ENRP server 1532 MUST replace the entry with the copy found in the message and 1533 remove the "mark" from the entry. 1535 5. After transferring all the PE entries from the received 1536 ENRP_HANDLE_TABLE_RESPONSE message into its local database, the 1537 ENRP server SHOULD check whether there are still PE entries that 1538 remain "marked" in its local handlespace. If so, the ENRP server 1539 SHOULD silently remove those "marked" entries. 1541 Note, similar to what is described in Section 3.2.3, the peer may 1542 reject the ENRP_HANDLE_TABLE_REQUEST or use more than one 1543 ENRP_HANDLE_TABLE_RESPONSE message to respond. 1545 3.12 Handling Unrecognized Message or Unrecognized Parameter 1547 When an ENRP server receives an ENRP message with an unknown message 1548 type or a message of known type that contains an unknown parameter, 1549 it SHOULD handle the unknown message or the unknown parameter 1550 according to the unrecognized message and parameter handling rules 1551 defined in Sections 3 and 4 in [11]. 1553 According to the rules, if an error report to the message sender is 1554 needed, the ENRP server that discovered the error SHOULD send back an 1555 ENRP_ERROR message with proper error cause code. 1557 4. Variables and Thresholds 1559 4.1 Variables 1561 peer.last.heard - the local time that a peer server was last heard 1562 (via receiving either a multicast or point-to-point message from 1563 the peer). 1565 pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server 1566 keeps for a peer. A separate PE checksum is kept for each of its 1567 known peers as well as for itself. 1569 4.2 Thresholds 1571 MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will 1572 make to contact an ENRP server (Default=3 times). 1574 TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will 1575 wait for a response from an ENRP server (Default=5 seconds). 1577 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1578 heartbeat message to all its known peers. (Default=30 secs.) 1580 SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a 1581 SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) 1583 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1584 will wait before considering a silent peer server potentially 1585 dead. (Default=61 secs.) 1587 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1588 sender will wait for a response after sending out a message. 1589 (Default=5 secs.) 1591 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a 1592 PE that an ENRP server will allow before purging this PE from the 1593 handlespace. (Default=3) 1595 5. Security Considerations 1597 Threats Introduced by Rserpool and Requirements for Security in 1598 Response to Threats [12] describes the threats to the Rserpool 1599 architecture in detail and lists the security requirements in 1600 response to each threat. From the threats described in this 1601 document, the security services required for the Rserpool protocol 1602 are enumerated below. 1604 Threat 1) PE registration/deregistration flooding or spoofing 1605 ----------- 1606 Security mechanism in response: ENRP server authenticates the PE 1608 Threat 2) PE registers with a malicious ENRP server 1609 ----------- 1610 Security mechanism in response: PE authenticates the ENRP server 1612 Threat 1 and 2 taken together results in mutual authentication of the 1613 ENRP server and the PE. 1615 Threat 3) Malicious ENRP server joins the ENRP server pool 1616 ----------- 1617 Security mechanism in response: ENRP servers mutually authenticate 1619 Threat 4) A PU communicates with a malicious ENRP server for handle 1620 resolution 1621 ----------- 1622 Security mechanism in response: The PU authenticates the ENRP server 1624 Threat 5) Replay attack 1625 ----------- 1626 Security mechanism in response: Security protocol which has 1627 protection from replay attacks 1629 Threat 6) Corrupted data which causes a PU to have misinformation 1630 concerning a pool handle resolution 1631 ----------- 1632 Security mechanism in response: Security protocol which supports 1633 integrity protection 1635 Threat 7) Eavesdropper snooping on handlespace information 1636 ----------- 1637 Security mechanism in response: Security protocol which supports data 1638 confidentiality 1640 Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to 1641 ENRP server 1642 ----------- 1643 Security mechanism in response: ASAP must control the number of 1644 endpoint unreachable messages transmitted from the PU to the ENRP 1645 server. 1647 Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the 1648 ENRP server 1649 ----------- 1650 Security mechanism in response: ENRP server must control the number 1651 of Endpoint_KeepAlive messages to the PE 1653 To summarize the threats 1-7 require security mechanisms which 1654 support authentication, integrity, data confidentiality, protection 1655 from replay attacks. 1657 For Rserpool we need to authenticate the following: 1659 PU <---- ENRP Server (PU authenticates the ENRP server) 1660 PE <----> ENRP Server (mutual authentication) 1661 ENRP server <-----> ENRP Server (mutual authentication) 1663 We do not define any new security mechanisms specifically for 1664 responding to threats 1-7. Rather we use existing IETF security 1665 protocols to provide the security services required. TLS supports 1666 all these requirements and MUST be implemented. The 1667 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a 1668 minimum by implementers of TLS for Rserpool. For purposes of 1669 backwards compatibility, ENRP SHOULD support 1670 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 1671 other ciphersuite. 1673 Threat 8 requires the ASAP protocol to limit the number of 1674 ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5??? in [1]) to the 1675 ENRP server. 1677 Threat 9 requires the ENRP protocol to limit the number of 1678 Endpoint_KeepAlive messages to the PE (see Section x.y???). 1680 5.1 Implementing Security Mechanisms 1682 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must 1683 support mutual authentication. ENRP servers must support mutual 1684 authentication among themselves. PUs MUST authenticate ENRP servers. 1686 ENRP servers and PEs SHOULD possess a site certificate whose subject 1687 corresponds to their canonical hostname. PUs MAY have certificates 1688 of their own for mutual authentication with TLS, but no provisions 1689 are set forth in this document for their use. All Rserpool elements 1690 that support TLS MUST have a mechanism for validating certificates 1691 received during TLS negotiation; this entails possession of one or 1692 more root certificates issued by certificate authorities (preferably 1693 well-known distributors of site certificates comparable to those that 1694 issue root certificates for web browsers). 1696 Implementations MUST support TLS with SCTP as described in RFC3436 1697 [9] or TLS over TCP as described in RFC2246 [7]. When using TLS/SCTP 1698 we must ensure that RSerPool does not use any features of SCTP that 1699 are not available to an TLS/SCTP user. This is not a difficult 1700 technical problem, but simply a requirement. When describing an API 1701 of the RSerPool lower layer we have also to take into account the 1702 differences between TLS and SCTP. 1704 6. Acknowledgements 1706 The authors wish to thank John Loughney, Lyndon Ong, and many others 1707 for their invaluable comments. 1709 7. References 1711 7.1 Normative References 1713 [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1714 Server Access Protocol (ASAP)", 1715 Internet-Draft draft-ietf-rserpool-asap-11, February 2005. 1717 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1718 J. and M. Stillman, "Requirements for Reliable Server Pooling", 1719 RFC 3237, January 2002. 1721 [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, 1722 "Architecture for Reliable Server Pooling", 1723 Internet-Draft draft-ietf-rserpool-arch-09, February 2005. 1725 [4] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format 1726 Specification version 3.3", RFC 1950, May 1996. 1728 [5] Bradner, S., "The Internet Standards Process -- Revision 3", 1729 BCP 9, RFC 2026, October 1996. 1731 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1732 Levels", BCP 14, RFC 2119, March 1997. 1734 [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1735 RFC 2246, January 1999. 1737 [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1738 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 1739 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1741 [9] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", 1742 RFC 3436, December 2002. 1744 [10] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On 1745 the Use of Stream Control Transmission Protocol (SCTP) with 1746 IPsec", RFC 3554, July 2003. 1748 [11] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1749 Server Access Protocol (ASAP) and Endpoint Handlespace 1750 Redundancy Protocol (ENRP) Parameters", 1751 Internet-Draft draft-ietf-rserpool-common-param-08, Feburary 1752 2005. 1754 [12] Stillman, M., "Threats Introduced by Rserpool and Requirements 1755 for Security in Response to Threats", 1756 Internet-Draft draft-ietf-rserpool-threats-04, January 2005. 1758 7.2 Informative References 1760 [13] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1761 Recommendations for Security", RFC 1750, December 1994. 1763 Authors' Addresses 1765 Qiaobing Xie 1766 Motorola, Inc. 1767 1501 W. Shure Drive, 2-F9 1768 Arlington Heights, IL 60004 1769 US 1771 Phone: 1772 Email: qxie1@email.mot.com 1774 Randall R. Stewart 1775 Cisco Systems, Inc. 1776 4875 Forest Drive 1777 Suite 200 1778 Columbia, SC 29206 1779 USA 1781 Phone: 1782 Email: rrs@cisco.com 1784 Maureen Stillman 1785 Nokia 1786 127 W. State Street 1787 Ithaca, NY 14850 1788 US 1790 Phone: 1791 Email: maureen.stillman@nokia.com 1793 Michael Tuexen 1794 Germany 1796 Phone: 1797 Email: tuexen@fh-muenster.de 1798 Aron J. Silverton 1799 Motorola, Inc. 1800 1301 E. Algonquin Road 1801 Room 2246 1802 Schaumburg, IL 60196 1803 USA 1805 Phone: +1 847-576-8747 1806 Email: aron.j.silverton@motorola.com 1808 Intellectual Property Statement 1810 The IETF takes no position regarding the validity or scope of any 1811 Intellectual Property Rights or other rights that might be claimed to 1812 pertain to the implementation or use of the technology described in 1813 this document or the extent to which any license under such rights 1814 might or might not be available; nor does it represent that it has 1815 made any independent effort to identify any such rights. Information 1816 on the procedures with respect to rights in RFC documents can be 1817 found in BCP 78 and BCP 79. 1819 Copies of IPR disclosures made to the IETF Secretariat and any 1820 assurances of licenses to be made available, or the result of an 1821 attempt made to obtain a general license or permission for the use of 1822 such proprietary rights by implementers or users of this 1823 specification can be obtained from the IETF on-line IPR repository at 1824 http://www.ietf.org/ipr. 1826 The IETF invites any interested party to bring to its attention any 1827 copyrights, patents or patent applications, or other proprietary 1828 rights that may cover technology that may be required to implement 1829 this standard. Please address the information to the IETF at 1830 ietf-ipr@ietf.org. 1832 Disclaimer of Validity 1834 This document and the information contained herein are provided on an 1835 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1836 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1837 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1838 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1839 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1840 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1842 Copyright Statement 1844 Copyright (C) The Internet Society (2005). This document is subject 1845 to the rights, licenses and restrictions contained in BCP 78, and 1846 except as set forth therein, the authors retain all their rights. 1848 Acknowledgment 1850 Funding for the RFC Editor function is currently provided by the 1851 Internet Society.