idnits 2.17.1 draft-ietf-rserpool-enrp-10.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1837. ** 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 == The page length should not exceed 58 lines per page, but there was 41 longer pages, the longest (page 11) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 45 pages 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 (October 14, 2004) is 7133 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: '4' is defined on line 1744, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-10 ** 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-07 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '3') ** Obsolete normative reference: RFC 2246 (ref. '6') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2960 (ref. '7') (Obsoleted by RFC 4960) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-07 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '10') == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-03 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '11') -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. '12') (Obsoleted by RFC 4086) Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Xie 3 Internet-Draft Motorola 4 Expires: April 14, 2005 R. Stewart 5 Cisco Systems, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 October 14, 2004 11 Endpoint Name Resolution Protocol (ENRP) 12 draft-ietf-rserpool-enrp-10.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 14, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 Endpoint Name Resolution Protocol (ENRP) is designed to work in 48 conjunction with the Aggregate Server Access Protocol (ASAP) to 49 accomplish the functionality of the Reliable Server Pooling 50 (Rserpool) requirements and architecture. Within the operational 51 scope of Rserpool, ENRP defines the procedures and message formats of 52 a distributed, fault-tolerant registry service for storing, 53 bookkeeping, retrieving, and distributing pool operation and 54 membership information. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . 6 62 2.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 6 63 2.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 8 64 2.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 8 65 2.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 10 66 2.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 11 67 2.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12 68 2.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13 69 2.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 70 2.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 14 71 2.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . 15 72 2.11 ENRP_ERROR message . . . . . . . . . . . . . . . . . . . 17 73 3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . 18 74 3.1 Methods for Communicating amongst ENRP Servers . . . . . . 18 75 3.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 19 76 3.2.1 Generate a Server Identifier . . . . . . . . . . . . . 20 77 3.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . 20 78 3.2.3 Download ENRP Handlespace Data from Mentor Peer . . . 22 79 3.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 24 80 3.3.1 Rules on PE Re-registration . . . . . . . . . . . . . 26 81 3.4 Handle PE De-registration . . . . . . . . . . . . . . . . 27 82 3.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 27 83 3.6 Server Handlespace Update . . . . . . . . . . . . . . . . 28 84 3.6.1 Announcing Addition or Update of PE . . . . . . . . . 28 85 3.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . 29 86 3.7 Detecting and Removing Unreachable PE . . . . . . . . . . 30 87 3.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 31 88 3.9 Maintaining Peer List and Monitoring Peer Status . . . . . 31 89 3.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . 31 90 3.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . 31 91 3.9.3 Detecting Peer Server Failure . . . . . . . . . . . . 32 92 3.10 Taking-over a Failed Peer Server . . . . . . . . . . . . 32 93 3.10.1 Initiate Server Take-over Arbitration . . . . . . . 32 94 3.10.2 Take-over Target Peer Server . . . . . . . . . . . . 33 95 3.11 Handlespace Data Auditing and Re-synchronization . . . . 34 96 3.11.1 Auditing Procedures . . . . . . . . . . . . . . . . 34 97 3.11.2 PE Checksum Calculation Algorithm . . . . . . . . . 35 98 3.11.3 Re-synchronization Procedures . . . . . . . . . . . 36 99 3.12 Handling Unrecognized Message or Unrecognized 100 Parameter . . . . . . . . . . . . . . . . . . . . . . . 36 101 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . 38 102 4.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 38 103 4.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 38 104 5. Security Considerations . . . . . . . . . . . . . . . . . . 39 105 5.1 Implementing Security Mechanisms . . . . . . . . . . . . . 40 106 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 107 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 108 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 43 109 7.2 Informative References . . . . . . . . . . . . . . . . . . . 44 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 111 Intellectual Property and Copyright Statements . . . . . . . 45 113 1. Introduction 115 ENRP is designed to work in conjunction with ASAP [1] to accomplish 116 the functionality of Rserpool as defined by its requirements [2] and 117 architecture [3]. 119 Within the operation scope of Rserpool, ENRP defines the procedures 120 and message formats of a distributed fault-tolerant registry service 121 for storing, bookkeeping, retrieving, and distributing pool operation 122 and membership information. 124 Whenever appropriate, in the rest of this document we will refer to 125 this Rserpool registry service as ENRP handlespace, or simply 126 handlespace. 128 1.1 Definitions 130 This document uses the following terms: 132 Operation scope: See [3]; 134 Pool (or server pool): See [3]; 136 Pool handle: See [3]; 138 Pool element (PE): See [3]; 140 Pool user (PU): See [3]; 142 Pool element handle: See [3]; 144 ENRP handlespace (or handlespace): See [3]; 146 ENRP client channel: The communication channel through which an ASAP 147 User (either a PE or PU) requests ENRP handlespace service. The 148 client channel is usually defined by the transport address of the 149 home server and a well known port number. The channel MAY make 150 use of multi-cast or a named list of ENRP servers. 152 ENRP server channel: Defined by a well known multicast IP address and 153 a well known port number. All ENRP servers in an operation scope 154 can send multicast messages to other servers through this channel. 155 PEs are also allowed to multicast on this channel occasionally; 157 Home ENRP server: The ENRP server to which a PE or PU currently 158 belongs. A PE MUST only have one home ENRP server at any given 159 time and both the PE and its home ENRP server MUST keep track of 160 this master/slave relationship between them. A PU SHOULD select 161 one of the available ENRP servers as its home ENRP server, but the 162 ENRP server does not need to know, nor does it need to keep track 163 of this relationship. 165 1.2 Conventions 167 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 168 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 169 they appear in this document, are to be interpreted as described in 170 [5]. 172 2. ENRP Message Definitions 174 In this section, we defines the format of all ENRP messages. These 175 are messages sent and received amongst ENRP servers in an operation 176 scope. Messages sent and received between a PE/PU and an ENRP server 177 are part of ASAP and are defined in [1]. A common format, defined in 178 [10], is used for all ENRP and ASAP messages. 180 Most ENRP messages contains a combination of fixed fields and TLV 181 parameters. The TLV parameters are also defined in [10]. 183 All messages, as well as their fields/parameters described below, 184 MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., 185 the most significant byte first). 187 For ENRP, the following message types are defined: 189 Type Message Name 190 ----- ------------------------- 191 0x00 - (reserved by IETF) 192 0x01 - PEER_PRESENCE 193 0x02 - PEER_NAME_TABLE_REQUEST 194 0x03 - PEER_NAME_TABLE_RESPONSE 195 0x04 - PEER_NAME_UPDATE 196 0x05 - PEER_LIST_REQUEST 197 0x06 - PEER_LIST_RESPONSE 198 0x07 - PEER_INIT_TAKEOVER 199 0x08 - PEER_INIT_TAKEOVER_ACK 200 0x09 - PEER_TAKEOVER_SERVER 201 0x0a - PEER_OWNERSHIP_CHANGE 202 0x0b - ENRP_ERROR 203 0x0c-0xff - (reserved by IETF) 205 2.1 PEER_PRESENCE message 207 This ENRP message is used to announce (periodically) the presence of 208 an ENRP server, or to probe the status of a peer ENRP sever. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type = 0x01 |0|0|0|0|0|0|0|R| Message Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Sender Server's ID | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Receiver Server's ID | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 : PE Checksum Param : 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 : Server Information Param (optional) : 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 R (reply_required) flag: 1 bit 226 Set to '1' if the sender requires a response to this message, 227 otherwise set to '0'. 229 Sender Server's ID: 32 bit (unsigned integer) 231 This is the ID of the ENRP server which sends the message. 233 Receiver Server's ID: 32 bit (unsigned integer) 235 This is the ID of the ENRP server to which the message is 236 intended. If the message is not intended to an individual 237 server (e.g., the message is multicasted to a group of 238 servers), this field MUST be set with all 0's. 240 PE Checksum Parameter: 242 This is a TLV that contains the latest PE checksum of the ENRP 243 server who sends the PEER_PRESENCE. This parameter SHOULD be 244 included for handlespace consistency auditing. See Section 245 3.11.1 for details. 247 Server Information Parameter: 249 If present, contains the server information of the sender of 250 this message (Server Information Parameter is defined in [10]). 251 This parameter is optional. However, if this message is sent 252 in response to a received "reply required" PEER_PRESENCE from a 253 peer, the sender then MUST include its server information. 255 Note, at startup an ENRP server MUST pick a randomly generated, 256 non-zero 32-bit unsigned integer as its ID and MUST use this same ID 257 for its entire life. 259 2.2 PEER_NAME_TABLE_REQUEST message 261 An ENRP server sends this message to one of its peers to request a 262 copy of the handlespace data. This message is normally used during 263 server initialization or handlespace re-synchronization. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Sender Server's ID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Receiver Server's ID | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 W (oWn-children-only) flag: 1 bit 277 Set to '1' if the sender of this message is only requesting 278 information about the PEs owned by the message receiver. 279 Otherwise, set to '0'. 281 Sender Server's ID: 283 See Section 2.1. 285 Receiver Server's ID: 287 See Section 2.1. 289 2.3 PEER_NAME_TABLE_RESPONSE message 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type = 0x03 |0|0|0|0|0|0|M|R| Message Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Sender Server's ID | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Receiver Server's ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 : : 300 : Pool entry #1 (see below) : 301 : : 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 : : 304 : ... : 305 : : 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 : : 308 : Pool entry #n (see below) : 309 : : 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 M (More_to_send) flag: 1 bit 314 Set to '1' if the sender has more pool entries to sent in 315 subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set to 316 '0'. 318 R (Reject) flag: 1 bit 320 MUST be set to '1' if the sender of this message is rejecting a 321 handlespace request. In such a case, this message MUST be sent 322 with no pool entries included. 324 Message Length: 16 bits (unsigned integer) 326 Indicates the entire length of the message in number of octets. 328 Note, the value in Message Length field will NOT cover any 329 padding at the end of this message. 331 Sender Server's ID: 333 See Section 2.1. 335 Receiver Server's ID: 337 See Section 2.1. 339 Pool entry #1-#n: 341 If R flag is '0', at least one pool entry SHOULD be present in 342 the message. Each pool entry MUST start with a pool handle 343 parameter as defined in section 3.1.7, followed by one or more 344 pool element parameters, i.e.: 346 +---------------------------+ 347 : Pool handle : 348 +---------------------------+ 349 : PE #1 : 350 +---------------------------+ 351 : PE #2 : 352 +---------------------------+ 353 : ... : 354 +---------------------------+ 355 : PE #n : 356 +---------------------------+ 358 2.4 PEER_NAME_UPDATE message 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Sender Server's ID | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Receiver Server's ID | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Update Action | (reserved) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 : Pool handle : 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 : Pool Element : 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Message Length: 16 bits (unsigned integer) 378 Indicates the entire length of the message in number of octets. 380 Note, the value in Message Length field will NOT cover any 381 padding at the end of this message. 383 Update Action: 16 bits (unsigned integer) 385 This field indicates what act is requested to the specified PE. 386 It MUST take one of the following values: 388 0x0 - ADD_PE: add or update the specified PE in the ENRP 389 handlespace 391 0x1 - DEL_PE: delete the specified PE from the ENRP 392 handlespace. 394 Other values are reserved by IETF and MUST not be used. 396 Reserved: 16 bits 398 MUST be set to 0's by sender and ignored by the receiver. 400 Sender Server's ID: 402 See Section 2.1. 404 Receiver Server's ID: 406 See Section 2.1. 408 Pool handle: 410 Specifies to which the PE belongs. 412 Pool Element: 414 Specifies the PE. 416 2.5 PEER_LIST_REQUEST message 418 This ENRP message is used to request a copy of the current known ENRP 419 peer server list. This message is normally sent from a newly started 420 ENRP server to an existing ENRP server as part of the initialization 421 process of the new server. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Sender Server's ID | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Receiver Server's ID | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Sender Server's ID: 435 See Section 2.1. 437 Receiver Server's ID: 439 See Section 2.1. 441 2.6 PEER_LIST_RESPONSE message 443 This message is used to respond a PEER_LIST_REQUEST. 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type = 0x06 |0|0|0|0|0|0|0|R| Message Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Sender Server's ID | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Receiver Server's ID | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 : Server Info Param of Peer #1 : 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 : ... : 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 : Server Info Param of Peer #n : 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 R (Reject) flag: 1 bit 463 MUST be set to '1' if the sender of this message is rejecting a 464 peer list request. In such a case, this message MUST be sent 465 with no peer server ID included. 467 Message Length: 16 bits (unsigned integer) 469 Indicates the entire length of the message in number of octets. 471 Note, the value in Message Length field will NOT cover any 472 padding at the end of this message. 474 Sender Server's ID: 476 See Section 2.1. 478 Receiver Server's ID: 480 See Section 2.1. 482 Server Information Parameter of Peer #1-#n: 484 Each contains a Server Information Parameter of a peer known to 485 the sender. The Server Information Parameter is defined in 486 [10]. 488 2.7 PEER_INIT_TAKEOVER message 490 This message is used by an ENRP server (the takeover initiator) to 491 declare its intention of taking over a specific peer ENRP server. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Sender Server's ID | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Receiver Server's ID | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Target Server's ID | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Sender Server's ID: 507 See Section 2.1. 509 Receiver Server's ID: 511 See Section 2.1. 513 Target Server's ID: 515 Contains the 32-bit server ID of the peer ENRP that is the 516 target of this takeover attempt. 518 2.8 PEER_INIT_TAKEOVER_ACK message 520 This message is used to acknowledge the takeover initiator that the 521 sender of this message received the PEER_INIT_TAKEOVER message and 522 that it does not object to the takeover. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Sender Server's ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Receiver Server's ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Target Server's ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Sender Server's ID: 538 See Section 2.1. 540 Receiver Server's ID: 542 See Section 2.1. 544 Target Server's ID: 546 Contains the 32-bit server ID of the peer ENRP that is the 547 target of this takeover attempt. 549 2.9 PEER_TAKEOVER_SERVER message 551 This message is used by the takeover initiator to declare that a 552 takeover is underway. 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Sender Server's ID | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Receiver Server's ID | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Target Server's ID | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Sender Server's ID: 568 See Section 2.1. 570 Receiver Server's ID: 572 See Section 2.1. 574 Target Server's ID: 576 Contains the 32-bit server ID of the peer ENRP that is the 577 target of this takeover operation. 579 2.10 PEER_OWNERSHIP_CHANGE message 581 This message is used by the ENRP server, normally after a successful 582 takeover, to declare that it is now the new home ENRP server of the 583 listed PEs in the listed pools. 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Sender Server's ID | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Receiver Server's ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 : Pool handle #1 : 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 : PE Identifier Param #1 of pool #1 : 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 : ... : 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 : PE Identifier Param #k of pool #1 : 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 : : 603 : ... : 604 : : 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 : Pool handle #M : 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 : PE Identifier Param #1 of pool #M : 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 : ... : 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 : PE Identifier Param #n of pool #M : 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Sender Server's ID: 617 See Section 2.1. 619 Receiver Server's ID: 621 See Section 2.1. 623 Pool handles and PE Identifier parameters: 625 Each listed pool handle is followed by a list of PE Identifier 626 parameters, indicating that the sender of this message is 627 taking ownership of the listed PEs in the pool. 629 2.11 ENRP_ERROR message 631 This message is used by an ENRP server to report an operation error 632 to one of its peers. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type = 0x0b |0|0|0|0|0|0|0|0| Message Length | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Sender Server's ID | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Receiver Server's ID | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 : Operation Error Parameter : 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Sender Server's ID: 648 See Section 2.1. 650 Receiver Server's ID: 652 See Section 2.1. 654 Operation Error Parameter: 656 This parameter, defined in [10], indicates the type of error(s) 657 being reported. 659 3. ENRP Operation Procedures 661 In this section, we discuss the operation procedures defined by ENRP. 662 An ENRP server MUST following these procedures when sending, 663 receiving, or processing ENRP messages. 665 Many of the Rserpool events call for both server-to-server and 666 PU/PE-to-server message exchanges. Only the message exchanges and 667 activities between an ENRP server and its peer(s) are considered 668 within the ENRP scope and are defined in this document. 670 Procedures for exchanging messages between a PE/PU and ENRP servers 671 are defined in [1]. 673 3.1 Methods for Communicating amongst ENRP Servers 675 Within an Rserpool operation scope, ENRP servers need to communicate 676 with each other in order to exchange information such as the pool 677 membership changes, handlespace data synchronization, etc. 679 Two types of communications are used amongst ENRP servers: 681 o point-to-point message exchange from one ENPR server to a specific 682 peer server, and 684 o announcements from one server to all its peer servers in the 685 operation scope. 687 Point-to-point communication is always carried out over an SCTP 688 association between the sending server and the receiving server. 690 Announcements are communicated out with one of the following two 691 approaches: 693 1. The sending server sends the announcement message to a well-known 694 RSERPOOL IP multicast channel that its peer servers subscribe to. 696 Note: Because IP multicast is not reliable, this approach does 697 not guarantee that all the peers will receive the announcement 698 message. Moreover, since IP multicast is not secure, this 699 approach cannot provide any security to the communication. 701 2. The sending server sends multiple copies of the announcement, one 702 to each of its peer servers, over a set of point-to-point SCTP 703 associations between the sending server and the peers. 705 This approach guarantees the reliable reception of the message. 706 When needed, data security can be achieved by using IP security 707 mechanisms such as IPsec [9] or TLS [8]. 709 In order to maximize inter-operability of ENRP servers, the following 710 rules MUST be followed: 712 1. At the startup time, a new ENRP server SHOULD make a decision on 713 whether it will enable IP multicast for ENRP announcements. This 714 decision should be based on factors such as the availability of 715 IP multicast and the security requirements from the user of 716 Rserpool. 718 2. If an ENRP server disables multicast, it then: 720 A. MUST NOT subscribe to the well-known server multicast 721 channel, i.e., it only receives peer announcements over SCTP 722 associations, and 724 B. MUST transmit all its out-going announcements over 725 point-to-point SCTP associations with its peers. 727 3. If an ENRP server enables itself to use multicast, it then: 729 A. MUST subscribe to the well-known server multicast channel to 730 ready itself for receiving peers' multicast announcements, 732 B. MUST also be prepared to receive peer announcements over 733 point-to-point SCTP associations from peers. 735 C. MUST track internally which peers are multicast-enabled and 736 which are not. Note: A peer is always assumed to be 737 multicast-disabled until/unless an ENRP message of any type 738 is received from that peer over the well-known server 739 multicast channel. 741 D. when sending out an announcement, MUST send a copy to the 742 well-known server multicast channel AND a copy to each of the 743 peers that are marked as multicast-disabled over a 744 point-to-point SCTP association. 746 3.2 ENRP Server Initialization 748 This section describes the steps a new ENRP server needs to take in 749 order to join the other existing ENRP servers, or to initiate the 750 handlespace service if it is the first ENRP server started in the 751 operation scope. 753 3.2.1 Generate a Server Identifier 755 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 756 as unique as possible in the operation scope and this server Id MUST 757 remain unchanged for the lifetime of the server. Normally, a good 758 32-bit random number will be good enough as the server Id ([12] 759 provides some information on randomness guidelines). 761 Note, there is a very remote chance (about 1 in 4 billion) that two 762 ENRP servers in an operation scope will generate the same server Id 763 and hence cause a server Id conflict in the pool. However, no severe 764 consequence of such a conflict has been identified. 766 3.2.2 Acquire Peer Server List 768 At startup, the ENRP server (initiating server) will first attempt to 769 learn all existing peer ENRP servers in the same operation scope, or 770 to determine that it is along in the scope. 772 The initiating server uses an existing peer server to bootstrap 773 itself into service. We call this peer server the mentor server. 775 3.2.2.1 Find the mentor server 777 If the initiating server is told about an existing peer server 778 through some administrative means (such as DNS query, configuration 779 database, startup scripts, etc), the initiating server SHOULD then 780 use this peer server as its mentor server and SHOULD skip the 781 remaining steps in this subsection. 783 If multiple existing peer servers are specified, the initiating 784 server SHOULD pick one of them as its mentor peer server, keep the 785 others as its backup mentor peers, and skip the remaining steps in 786 this subsection. 788 If no existing peer server is specified to the initiating server AND 789 if multicast is available in the operation scope, the following 790 mentor peer discovery procedures SHOULD be followed: 792 1. The initiating server SHOULD first join the well-known ENRP 793 server multicast channel. 795 2. Then the initiating server SHOULD send a PEER_PRESENCE message, 796 with the 'Reply_required' flag set, over the multicast channel. 797 Upon the reception of this PEER_PRESENCE message, a peer server 798 MUST send a PEER_PRESENCE, without the 'Reply_required' flag, 799 back to the initiating server. 801 3. When the first response to its original PEER_PRESENCE arrives, 802 the initiating server SHOULD take the sender of this received 803 response as its mentor peer server. This completes the discovery 804 of the mentor peer server. 806 If responses are also received from other peers (a likely event 807 when multiple peers exist in the operation scope at the time the 808 new server started), the initiating server SHOULD keep a list of 809 those responded as its backup mentor peers (see below). 811 4. If no response to its PEER_PRESENCE message are received after 812 TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat 813 steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After 814 that, if there is still no response, the initiating server MUST 815 assume that it is alone in the operation scope. 817 5. If the initiating server determined that it is alone in the 818 scope, it MUST skip the procedures in Section 3.2.2.2 and Section 819 3.2.3 and MUST consider its initialization completed and start 820 offering ENRP services. 822 Note, if multicast is not available (or not allowed for reasons such 823 as security concerns) in the operation scope, at least one peer 824 server MUST be specified to the initiating server through 825 administrative means, unless the initiation server is the first 826 server to start in the operation scope. 828 Note, if the administratively specified mentor peer(s) fails, the 829 initiating server SHOULD use the auto-discover procedure defined in 830 steps 1-5 above. 832 3.2.2.2 Request complete server list from mentor peer 834 Once the initiating server finds its mentor peer server (by either 835 discovery or administrative means), the initiating server MUST send a 836 PEER_LIST_REQUEST message to the mentor peer server to request a copy 837 of the complete server list maintained by the mentor peer (see 838 Section 3.9 for maintaining server list). 840 Upon the reception of this request, the mentor peer server SHOULD 841 reply with a PEER_LIST_RESPONSE message and include in the message 842 body all existing ENRP servers known by the mentor peer. 844 Upon the reception of the PEER_LIST_RESPONSE message from the mentor 845 peer, the initiating server MUST use the server information carried 846 in the message to initialize its own peer list. 848 However, if the mentor itself is in the process of startup and not 849 ready to provide a peer server list (for example, the mentor peer is 850 waiting for a response to its own PEER_LIST_REQUEST to another 851 server), it MUST reject the request by the initiating server and 852 respond with a PEER_LIST_RESPONSE message with the R flag set to '1', 853 and with no server information included in the response. 855 In the case where its PEER_LIST_REQUEST is rejected by the mentor 856 peer, the initiating server SHOULD either wait for a few seconds and 857 re-send the PEER_LIST_REQUEST to the mentor server, or if there is a 858 backup mentor peer available, select another mentor peer server and 859 send the PEER_LIST_REQUEST to the new mentor server. 861 3.2.3 Download ENRP Handlespace Data from Mentor Peer 863 After a peer list download is completed, the initiating server MUST 864 request a copy of the current handlespace data from its mentor peer 865 server, by taking the following steps: 867 1. The initiating server MUST first send a PEER_NAME_TABLE_REQUEST 868 message to the mentor peer, with W flag set to '0', indicating 869 that the entire handlespace is requested. 871 2. Upon the reception of this message, the mentor peer MUST start a 872 download session in which a copy of the current handlespace data 873 maintained by the mentor peer is sent to the initiating server in 874 one or more PEER_NAME_TABLE_RESPONSE messages (Note, the mentor 875 server may find it particularly desirable to use multiple 876 PEER_NAME_TABLE_RESPONSE messages to send the handlespace when 877 the handlespace is large, especially when forming and sending out 878 a single response containing a large handlespace may interrupt 879 its other services). 881 If more than one PEER_NAME_TABLE_RESPONSE message are used during 882 the download, the mentor peer MUST use the M flag in each 883 PEER_NAME_TABLE_RESPONSE message to indicate whether this message 884 is the last one for the download session. In particular, the 885 mentor peer MUST set the M flag to '1' in the outbound 886 PEER_NAME_TABLE_RESPONSE if there is more data to be transferred 887 and MUST keep track of the progress of the current download 888 session. The mentor peer MUST set the M flag to '0' in the last 889 PEER_NAME_TABLE_RESPONSE for the download session and close the 890 download session (i.e., removing any internal record of the 891 session) after sending out the last message. 893 3. During the downloading, every time the initiating server receives 894 a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data 895 entries carried in the message into its local handlespace 896 database, and then check whether or not this message is the last 897 one for the download session. 899 If the M flag is set to '1' in the just processed 900 PEER_NAME_TABLE_RESPONSE message, the initiating server MUST send 901 another PEER_NAME_TABLE_REQUEST message to the mentor peer to 902 request for the next PEER_NAME_TABLE_RESPONSE message. 904 4. When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 905 message into its local handlespace database, the initiating 906 server MUST handle each pool entry carried in the message using 907 the following rules: 909 A. If the pool does not exist in the local handlespace, the 910 initiating server MUST creates the pool in the local 911 handlespace and add the PE(s) in the pool entry to the pool. 913 When creating the pool, the initiation server MUST set the 914 overall member selection policy type of the pool to the 915 policy type indicated in the first PE. 917 B. If the pool already exists in the local handlespace, but the 918 PE(s) in the pool entry is not currently a member of the 919 pool, the initiating server MUST add the PE(s) to the pool. 921 C. If the pool already exists in the local handlespace AND the 922 PE(s) in the Pool entry is already a member of the pool, the 923 initiating server SHOULD replace the attributes of the 924 existing PE(s) with the new information. 926 5. When the last PEER_NAME_TABLE_RESPONSE message is received from 927 the mentor peer and unpacked into the local handlespace, the 928 initialization process is completed and the initiating server 929 SHOULD start to provide ENRP services. 931 Under certain circumstances, the mentor peer itself may not be able 932 to provide a handlespace download to the initiating server. For 933 example, the mentor peer is in the middle of initializing its own 934 handlespace database, or it has currently too many download sessions 935 open to other servers. 937 In such a case, the mentor peer MUST reject the request by the 938 initiating server and respond with a PEER_NAME_TABLE_RESPONSE message 939 with the R flag set to '1', and with no pool entries included in the 940 response. 942 In the case where its PEER_NAME_TABLE_REQUEST is rejected by the 943 mentor peer, the initiating server SHOULD either wait for a few 944 seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server, 945 or if there is a backup mentor peer available, select another mentor 946 peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor 947 server. 949 A started handlespace download session may get interrupted for some 950 reason. To cope with this, the initiating server SHOULD start a 951 timer every time it finishes sending a PEER_NAME_TABLE_REQUEST to its 952 mentor peer. If this timer expires without receiving a response from 953 the mentor peer, the initiating server SHOULD abort the current 954 download session and re-start a new handlespace download with a 955 backup mentor peer, if one is available. 957 Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the 958 mentor peer has still more data to send, it SHOULD start a session 959 timer. If this timer expires without receiving another request from 960 the initiating server, the mentor peer SHOULD abort the session, 961 cleaning out any resource and record of the session. 963 3.3 Handle PE Registration 965 To register itself with the handlespace, a PE sends a REGISTRATION 966 message to its home ENRP server. The format of REGISTRATION message 967 and rules of sending it are defined in [1]. 969 In the REGISTRATION message, the PE indicates the name of the pool it 970 wishes to join in a pool handle parameter, and its complete transport 971 information and any load control information in a PE parameter. 973 The ENRP server handles the REGISTRATION message according to the 974 following rules: 976 1. If the named pool does not exist in the handlespace, the ENRP 977 server MUST creates a new pool with that name in the handlespace 978 and add the PE to the pool as its first PE; 980 When a new pool is created, the overall member selection policy 981 of the pool MUST be set to the policy type indicated by the first 982 PE, the overall pool transport type MUST be set to the transport 983 type indicated by the PE, and the overall pool data/control 984 channel configuration MUST be set to what is indicated in the 985 Transport Use field of the User Transport parameter by the 986 registering PE. 988 2. If the named pool already exists in the handlespace, but the 989 requesting PE is not currently a member of the pool, the ENRP 990 server will add the PE as a new member to the pool; 992 However, before adding the PE to the pool, the server MUST check 993 if the policy type, transport type, and transport usage indicated 994 by the registering PE is consistent with those of the pool. If 995 different, the ENRP server MUST either attempt to override the 996 PE's value(s) or to reject the registration if overriding is not 997 possible. 999 A. Inconsistent policy - If no additional policy-related 1000 information are required to perform an override of pool 1001 policy (e.g., overriding Least-used with Round-robin does not 1002 require additional policy-related information), the ENRP 1003 server MUST replace the PE's policy type with the overall 1004 policy type of the pool. However, if additional policy 1005 information is required for the overriding (e.g., overriding 1006 Round-robin with Least-load will require the knowledge of the 1007 load factor of the PE), the ENRP server MUST reject the 1008 registration. 1010 B. Inconsistent transport type - The ENRP server MUST reject the 1011 registration. 1013 C. Inconsistent data/control configuration - If the overall pool 1014 configuration is "DATA ONLY", and the registering PE 1015 indicates "CONTORL plus DATA", the ENRP server SHOULD accept 1016 the registration but warn the PE that control channel cannot 1017 be used. If the pool configuration is "CONTROL plus DATA" 1018 and the PE indicates "DATA ONLY", the ENRP server MUST reject 1019 the registration. 1021 3. If the named pool already exists in the handlespace AND the 1022 requesting PE is already a member of the pool, the ENRP server 1023 SHOULD consider this as a re-registration case. The ENRP server 1024 MUST perform the same tests on policy, transport type, transport 1025 use, as described above. If the re-registration is accepted 1026 after the test, the ENRP Server SHOULD replace the attributes of 1027 the existing PE with the information carried in the received 1028 REGISTRATION message. 1030 4. After accepting the registration, the ENRP server MUST assign 1031 itself the owner of this PE. If this is a re-registration, the 1032 ENRP server MUST take over ownership of this PE regardless of 1033 whether the PE was previously owned by this server or by another 1034 server. 1036 5. The ENRP server may reject the registration due to reasons such 1037 as invalid values, lack of resource, authentication failure, etc. 1039 In all above cases, the ENRP server MUST reply to the requesting PE 1040 with a REGISTRATION_RESPONSE message. If the registration is 1041 accepted, the ENRP server MUST set the 'R' flag in the 1042 REGISTRATION_RESPONSE to '0'. If the registration is rejected, the 1043 ENRP server MUST indicate the rejection by setting the 'R' flag in 1044 the REGISTRATION_RESPONSE to '1'. 1046 If the registration is rejected, the ENRP server SHOULD include the 1047 proper error cause(s) in the REGISTRATION_RESPONSE message. 1049 If the registration is granted but with an override of some PE's 1050 original values, in the REGISTRATION_RESPONSE message the ENRP server 1051 SHOULD include the proper error cause(s) so that the PE can be warned 1052 about the overriding and be informed about the new value(s). 1054 If the registration is granted (either a new registration or a 1055 re-registration case), the ENRP server MUST assign itself to be the 1056 home ENRP server of the PE, i.e., to "own" the PE. 1058 Implementation note: for better performance, the ENRP server may 1059 find it both efficient and convenient to internally maintain two 1060 separate PE lists or tables - one is for the PEs that are "owned" 1061 by the ENRP server and the other for all the PEs owned by its 1062 peer(s). 1064 Moreover, if the registration is granted, the ENRP server MUST take 1065 the handlespace update action as described in Section 3.6 to inform 1066 its peers about the change just made. If the registration is denied, 1067 no message will be sent to its peers. 1069 3.3.1 Rules on PE Re-registration 1071 A PE may re-register itself to the handlespace with a new set of 1072 attributes in order to, for example, extend its registration life, 1073 change its load factor value, etc. 1075 A PE may modify its load factor value at any time via 1076 re-registration. Based on the number of PEs in the pool and the 1077 pool's overall policy type, this operation allows the PE to 1078 dynamically control its share of inbound messages received by the 1079 pool (also see Section ???? in [1] for more on load control). 1081 Moreover, when re-registering, the PE MUST NOT change its policy 1082 type. The server MUST reject the re-registration if the PE attempt 1083 to change its policy type. In the rejection, the server SHOULD 1084 attach an error code "Pooling Policy Inconsistent". 1086 Regardless whether it is the current owner of the PE, if the 1087 re-registration is granted to the PE, the ENRP server MUST assign 1088 itself to be the new home ENRP server of the PE. 1090 Moreover, if the re-registration is granted, the ENRP server MUST 1091 take the handlespace update action as described in Section 3.6 to 1092 inform its peers about the change just made. If the re-registration 1093 is denied, no message will be sent to its peers. 1095 3.4 Handle PE De-registration 1097 To remove itself from a pool, a PE sends a DEREGISTRATION message to 1098 its home ENRP server. The complete format of DEREGISTRATION message 1099 and rules of sending it are defined in [1]. 1101 In the DEREGISTRATION message the PE indicates the name of the pool 1102 it belongs to in a pool handle parameter and provides its PE 1103 identifier. 1105 Upon receiving the message, the ENRP server SHALL remove the PE from 1106 its handlespace. Moreover, if the PE is the last one of the named 1107 pool, the ENRP server will remove the pool from the handlespace as 1108 well. 1110 If the ENRP server fails to find any record of the PE in its 1111 handlespace, it SHOULD consider the de-registration granted and 1112 completed. 1114 The ENRP server may reject the de-registration request for various 1115 reasons, such as invalid parameters, authentication failure, etc. 1117 In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE 1118 message to the PE. If the de-registration is rejected, the ENRP 1119 server MUST indicate the rejection by including the proper Operation 1120 Error parameter. 1122 It should be noted that de-registration does not stop the PE from 1123 sending or receiving application messages. 1125 Once the de-registration request is granted AND the PE removed from 1126 its local copy of the handlespace, the ENRP server MUST take the 1127 handlespace update action described in Section 3.6 to inform its 1128 peers about the change just made. Otherwise, NO message SHALL be 1129 send to its peers. 1131 3.5 Pool Handle Translation 1133 A PU uses the pool handle translation service of an ENRP server to 1134 resolve a pool handle to a list of accessible transport addresses of 1135 the member PEs of the pool. 1137 This requires the PU to send a NAME_RESOLUTION message to its home 1138 ENRP server and in the NAME_RESOLUTION message specify the pool 1139 handle to be translated in a Pool Handle parameter. Complete 1140 definition of the NAME_RESOLUTION message and the rules of sending it 1141 are defined in [1]. 1143 An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests 1144 from PUs either over an SCTP association on the well-know SCTP port, 1145 or over a TCP connection on the well-know TCP port. 1147 Upon reception of the NAME_RESOLUTION message, the ENRP server MUST 1148 first look up the pool handle in its handlespace. If the pool exits, 1149 the home ENRP server MUST compose and send back a 1150 NAME_RESOLUTION_RESPONSE message to the requesting PU. 1152 In the response message, the ENRP server SHOULD list all the PEs 1153 currently registered in this pool, in a list of PE parameters. The 1154 ENRP server MUST also include a pool member selection policy 1155 parameter to indicate the overall member selection policy for the 1156 pool, if the current pool member selection policy is not round-robin 1157 (if the overall policy is round-Robin, this parameter MAY be 1158 omitted?). 1160 If the named pool does not exist in the handlespace, the ENRP server 1161 MUST respond with a NAME_UNKNOWN message. 1163 The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN 1164 messages and the rules of receiving them are defined in [1]. 1166 3.6 Server Handlespace Update 1168 This includes a set of update operations used by an ENRP server to 1169 inform its peers when its local handlespace is modified, e.g., 1170 addition of a new PE, removal of an existing PE, change of pool or PE 1171 properties. 1173 3.6.1 Announcing Addition or Update of PE 1175 When a new PE is granted registration to the handlespace or an 1176 existing PE is granted a re-registration, the home ENRP server uses 1177 this procedure to inform all its peers. 1179 This is an ENRP announcement and is sent to all the peer of the home 1180 ENRP server. See Section 3.1 on how announcements are sent. 1182 An ENRP server MUST announce this update to all its peers in a 1183 PEER_NAME_UPDATE message with the Update Action field set to ADD_PE, 1184 indicating the addition of a new PE or the modification of an 1185 existing PE. The complete new information of the PE and the pool its 1186 belongs to MUST be indicated in the message with a PE parameter and a 1187 Pool Handle parameter, respectively. 1189 The home ENRP server SHOULD fill in its server Id in the Sender 1190 Server's ID field and leave the Receiver Server's ID blank (i.e., all 1191 0's). 1193 When a peer receives this PEER_NAME_UPDATE message, it MUST take the 1194 following actions: 1196 1. If the named pool indicated by the pool handle does not exist in 1197 its local copy of the handlespace, the peer MUST create the named 1198 pool in its local handlespace and add the PE to the pool as the 1199 first PE. It MUST then copy in all other attributes of the PE 1200 carried in the message. 1202 When the new pool is created, the overall member selection policy 1203 of the pool MUST be set to the policy type indicated by the PE. 1205 2. If the named pool already exists in the peer's local copy of the 1206 handlespace AND the PE does not exist, the peer MUST add the PE 1207 to the pool as a new PE and copy in all attributes of the PE 1208 carried in the message. 1210 3. If the named pool exists AND the PE is already a member of the 1211 pool, the peer MUST replace the attributes of the PE with the new 1212 information carried in the message. 1214 3.6.2 Announcing Removal of PE 1216 When an existing PE is granted de-registration or is removed from its 1217 handlespace for some other reasons (e.g., purging an unreachable PE, 1218 see Section 3.7), the ENRP server MUST uses this procedure to inform 1219 all its peers about the change just made. 1221 This is an ENRP announcement and is sent to all the peer of the home 1222 ENRP server. See Section 3.1 on how announcements are sent. 1224 An ENRP server MUST announce the PE removal to all its peers in a 1225 PEER_NAME_UPDATE message with the Update Action field set to DEL_PE, 1226 indicating the removal of an existing PE. The complete information 1227 of the PE and the pool its belongs to MUST be indicated in the 1228 message with a PE parameter and a Pool Handle parameter, 1229 respectively. 1231 [editor's note: only the pool handle and the PE's id are needed, it 1232 should reduce the size of the message] 1233 The sending server MUST fill in its server ID in the Sender Server's 1234 ID field and leave the Receiver Server's ID blank (i.e., set to all 1235 0's). 1237 When a peer receives this PEER_NAME_UPDATE message, it MUST first 1238 find pool and the PE in its own handlespace, and then remove the PE 1239 from its local handlespace. If the removed PE is the last one in the 1240 pool, the peer MUST also delete the pool from its local handlespace. 1242 If the peer fails to find the PE or the pool in its handlespace, it 1243 SHOULD take no further actions. 1245 3.7 Detecting and Removing Unreachable PE 1247 Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 1248 Notification, see section 10.2 of [7]), the PU SHOULD send an 1249 ENDPOINT_UNREACHABLE message to its home ENRP server. The message 1250 SHOULD contain the pool handle and the PE Id of the unreachable PE. 1252 Upon the reception of an ENDPOINT_UNREACHABLE message, a server MUST 1253 immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the 1254 PE in question. If this ENDPOINT_KEEP_ALIVE fails (e.g., it results 1255 in an SCTP SEND.FAILURE notification), the ENRP server MUST consider 1256 the PE as truly unreachable and MUST remove the PE from its 1257 handlespace and take actions described in Section 3.6.2. 1259 If the ENDPOINT_UNREACHABLE message is transmitted successfully to 1260 the PE, the ENRP server MUST retain the PE in its handlespace. 1261 Moreover, the server SHOULD keep a counter to record how many 1262 ENDPOINT_UNREACHABLE messages it has received reporting reachability 1263 problem relating to this PE. If the counter exceeds the protocol 1264 threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE 1265 from its handlespace and take actions described in Section 3.6.2. 1267 Optionally, an ENRP server may also periodically send point-to-point 1268 ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP 1269 server in order to check their reachability status. If the send of 1270 ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the 1271 PE as unreachable and MUST remove the PE from its handlespace and 1272 take actions described in Section 3.6.2. Note, if an ENRP server 1273 owns a large number of PEs, the implementation should pay attention 1274 not to flood the network with bursts of ENDPOINT_KEEP_ALIVE messages. 1275 Instead, the implementation should try to smooth out the 1276 ENDPOINT_KEEP_ALIVE message traffic over time. 1278 The complete definition and rules of sending ENDPOINT_UNREACHABLE and 1279 receiving ENDPOINT_KEEP_ALIVE messages are described in [1]. 1281 3.8 Helping PE and PU to Discover Home ENRP Server 1283 At its startup time, or whenever its current home ENRP server is not 1284 providing services, a PE or PU will attempt to find a new home 1285 server. For this reason, the PE or PU will need to maintain a list 1286 of currently available ENRP servers in its scope. 1288 To help the PE or PU maintaining this list, an ENRP server, if it is 1289 enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE 1290 message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP 1291 multicast channel. And in the SERVER_ANNOUNE message the ENRP server 1292 SHOULD include all the transport addresses available for ASAP 1293 communications. If the ENRP server only supports SCTP for ASAP 1294 communications, the transport information MAY be omitted in the 1295 SERVER_ANNOUNCE message. 1297 For the complete procedure of this, see Section 3.6?? in [1]. 1299 3.9 Maintaining Peer List and Monitoring Peer Status 1301 An ENRP server MUST keep an internal record on the status of each of 1302 its known peers. This record is referred to as the server's "peer 1303 list" 1305 3.9.1 Discovering New Peer 1307 If a message of any type is received from a previously unknown peer, 1308 the ENRP server MUST consider this peer a new peer in the operation 1309 scope and add it to the peer list. 1311 The ENRP server MUST send a PEER_PRESENCE message with the 1312 Reply-required flag set to '1' to the source address found in the 1313 arrived message. This will force the new peer to reply with its own 1314 PEER_PRESENCE containing its full server information (see Section 1315 2.1). 1317 [editor's note: should we ask for a peer list from the new peer? 1318 this may help mending two split networks.] 1320 3.9.2 Server Sending Heartbeat 1322 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 1323 continued presence to all its peer with a PEER_PRESENCE message. In 1324 the PEER_PRESENCE message, the ENRP server MUST set the 1325 'Replay_required' flag to '0', indicating that no response is 1326 required. 1328 The arrival of this periodic PEER_PRESENCE message will cause all its 1329 peers to update their internal variable "peer.last.heard" for the 1330 sending server (see Section 3.9.3 for more details). 1332 3.9.3 Detecting Peer Server Failure 1334 An ENRP server MUST keep an internal variable "peer.last.heard" for 1335 each of its known peers and the value of this variable MUST be 1336 updated to the current local time every time a message of any type 1337 (point-to-point or announcement) is received from the corresponding 1338 peer. 1340 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 1341 seconds, the ENRP server MUST immediately send a point-to-point 1342 PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1344 If the send fails or the peer does not reply after 1345 MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer 1346 server dead and SHOULD initiate the takeover procedure defined in 1347 Section 3.10. 1349 3.10 Taking-over a Failed Peer Server 1351 In the following descriptions, We call the ENRP server that detects 1352 the failed peer server and initiates the take-over the "initiating 1353 server" and the failed peer server the "target server." 1355 3.10.1 Initiate Server Take-over Arbitration 1357 The initiating server SHOULD first start a take-over arbitration 1358 process by announcing a PEER_INIT_TAKEOVER message to all its peer 1359 servers. See Section 3.1 on how announcements are sent. In the 1360 message, the initiating server MUST fill in the Sender Server's ID 1361 and Target Server's ID. 1363 After announcing the PEER_INIT_TAKEOVER message, the initiating 1364 server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_ 1365 of its known peers, except of the target server. [editor's note: how 1366 long should it wait?] 1368 Each of the peer servers that receives the PEER_INIT_TAKEOVER message 1369 from the initiating server SHOULD take the following actions: 1371 1. If the peer server finds that itself is the target server 1372 indicated in the PEER_INIT_TAKEOVER message, it MUST immediately 1373 announce a PEER_PRESENCE message to all its peer ENRP servers in 1374 an attempt to stop this take-over process. This indicates a 1375 false failure detection case by the initiating server. 1377 2. If the peer server finds that itself has already started its own 1378 take-over arbitration process on the same target server, it MUST 1379 perform the following arbitration: 1381 A. if the peer's server ID is smaller in value than the Sender 1382 Server's ID in the arrived PEER_INIT_TAKEOVER message, the 1383 peer server SHOULD immediately abort its own take-over 1384 attempt. Moreover, the peer SHOULD mark the target server as 1385 "not active" on its internal peer list so that its status 1386 will no longer be monitored by the peer, and reply the 1387 initiating server with a PEER_INIT_TAKEOVER_ACK message. 1389 B. Otherwise, the peer MUST ignore the PEER_INIT_TAKEOVER 1390 message and take no action. 1392 3. If the peer finds that it is neither the target server nor is in 1393 its own take-over process, the peer SHOULD: a) mark the target 1394 server as "not active" on its internal peer list so that its 1395 status will no longer be monitored by this peer, and b) reply to 1396 the initiating server with a PEER_INIT_TAKEOVER_ACK message. 1398 Once the initiating server has received PEER_INIT_TAKEOVER_ACK 1399 message from _all_ of its currently known peers (except for the 1400 target server), it SHOULD consider that it has won the arbitration 1401 and SHOULD proceed to complete the take-over, following the steps 1402 described in Section 3.10.2. 1404 However, if it receives a PEER_PRESENCE from the target server at any 1405 point in the arbitration process, the initiating server SHOULD 1406 immediately abort the take-over process and mark the status of the 1407 target server as "active". 1409 3.10.2 Take-over Target Peer Server 1411 The initiating ENRP server SHOULD first send, via an announcement, a 1412 PEER_TAKEOVER_SERVER message to inform all its active peers that the 1413 take-over is enforced. The target server's ID MUST be filled in the 1414 message. The initiating server SHOULD then remove the target server 1415 from its internal peer list. 1417 [editor's note: peers should remove the target server from their list 1418 upon receiving this message. Do we really need this message? we can 1419 consolidate this with the ownership_change msg.] 1421 Then it SHOULD examine its local copy of the handlespace and claim 1422 ownership of each of the PEs originally owned by the target server, 1423 by following these steps: 1425 1. mark itself as the home ENRP server of each of the PEs originally 1426 owned by the target server; 1428 2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the 1429 PEs. This will trigger the PE to adopt the initiating sever as 1430 its new home ENRP server; 1432 3. after claiming the ownership of all the PEs originally owned by 1433 the target server, announce the ownership changes of all the 1434 affected PEs in a PEER_OWNERSHIP_CHANGE message to all the 1435 currently known peers. Note, if the list of affected PEs is 1436 long, the sender MAY announce the ownership changes in multiple 1437 PEER_OWNERSHIP_CHANGE messages. 1439 When a peer receives the PEER_OWNERSHIP_CHANGE message from the 1440 initiating server, it SHOULD find each of the reported PEs in its 1441 local copy of the handlespace and update the PE's home ENRP server to 1442 be the sender of the message (i.e., the initiating server). 1444 3.11 Handlespace Data Auditing and Re-synchronization 1446 Message losses or certain temporary breaks in network connectivity 1447 may result in data inconsistency in the local handlespace copy of 1448 some of the ENRP servers in an operation scope. Therefore, each ENRP 1449 server in the operation scope SHOULD periodically verify that its 1450 local copy of handlespace data is still in sync with that of its 1451 peers. 1453 This section defines the auditing and re-synchronization procedures 1454 for an ENRP server to maintain its handlespace data consistency. 1456 3.11.1 Auditing Procedures 1458 The auditing of handlespace consistency is based on the following 1459 procedures: 1461 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1462 integer internal variable) for each of its known peers and for 1463 itself. For an ENRP server with 'k' known peers, we denote these 1464 internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ..., 1465 "pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE 1466 checksum. The definition and detailed algorithm for calculating 1467 these PE checksum variables are given in Section 3.11.2. 1469 2. Each time an ENRP server sends out a PEER_PRESENCE, it SHOULD 1470 include in the message its current PE checksum (i.e., 1471 "pe.checksum.pr0"). 1473 3. When an ENRP server (server A) receives a PE checksum (carried in 1474 an arrived PEER_PRESENCE) from a peer ENRP server (server B), 1475 server A SHOULD compare the PE checksum found in the 1476 PEER_PRESENCE with its own internal PE checksum of server B 1477 (i.e., "pe.checksum.prB"). 1479 4. If the two values match, server A will consider that there is no 1480 handlespace inconsistency between itself and server B and should 1481 take no further actions. 1483 5. If the two values do NOT match, server A SHOULD consider that 1484 there is a handlespace inconsistency between itself and server B 1485 and a re-synchronization process SHOULD be carried out 1486 immediately with server B (see Section 3.11.3). 1488 3.11.2 PE Checksum Calculation Algorithm 1490 When an ENRP server (server A) calculate an internal PE checksum for 1491 a peer (server B), it MUST use the following algorithm. 1493 Let us assume that in server A's internal handlespace there are 1494 currently 'M' PEs that are owned by server B. Each of the 'M' PEs 1495 will then contribute to the checksum calculation with the following 1496 byte block: 1498 0 1 2 3 1499 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 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 : Pool handle string of the pool the PE belongs (padded with : 1502 : zeros to next 32-bit word boundary if needed) : 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | PE Id (4 octets) | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 Note, these are not TLVs. This byte block gives each PE a unique 1508 byte pattern in the scope. The 32-bit PE checksum for server B 1509 "pe.checksum.prB" is then calculated over the byte blocks contributed 1510 by the 'M' PEs one by one. 1512 Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") 1513 in the same fashion, using the byte blocks of all the PEs owned by 1514 itself. 1516 Note, whenever an ENRP finds that its internal handlespace has 1517 changed (e.g., due to PE registration/deregistration, receiving peer 1518 updates, removing failed PEs, downloading handlespace pieces from a 1519 peer, etc.), it MUST immediately update all its internal PE checksums 1520 that are affected by the change. 1522 Implementation Note: when the internal handlespace changes (e.g., a 1523 new PE added or an existing PE removed), an implementation needs not 1524 to re-calculate the affected PE checksum; it should instead simply 1525 update the checksum by adding or subtracting the byte block of the 1526 corresponding PE from the previous checksum value. 1528 3.11.3 Re-synchronization Procedures 1530 Once an ENRP server determines that there is inconsistency between 1531 its local handlespace data and a peer's handlespace data with 1532 regarding to the PEs owned by that peer, it SHOULD perform the 1533 following steps to re-synchronize the data: 1535 1. The ENRP server SHOULD first "mark" every PE it knows about that 1536 is owned by the peer in its local handlespace database; 1538 2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST 1539 message with W flag set to '1' to the peer to request a complete 1540 list of PEs owned by the peer; 1542 3. Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag 1543 set to '1', the peer server SHOULD immediately respond with a 1544 PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned 1545 by the peer. 1547 4. Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP 1548 server SHOULD transfer the PE entries carried in the message into 1549 its local handlespace database. If an PE entry being transferred 1550 already exists in its local database, the ENRP server MUST 1551 replace the entry with the copy found in the message and remove 1552 the "mark" from the entry. 1554 5. After transferring all the PE entries from the received 1555 PEER_NAME_TABLE_RESPONSE message into its local database, the 1556 ENRP server SHOULD check whether there are still PE entries that 1557 remain "marked" in its local handlespace. If so, the ENRP server 1558 SHOULD silently remove those "marked" entries. 1560 Note, similar to what is described in Section 3.2.3, the peer may 1561 reject the PEER_NAME_TABLE_REQUEST or use more than one 1562 PEER_NAME_TABLE_RESPONSE message to respond. 1564 3.12 Handling Unrecognized Message or Unrecognized Parameter 1566 When an ENRP server receives an ENRP message with an unknown message 1567 type or a message of known type that contains an unknown parameter, 1568 it SHOULD handle the unknown message or the unknown parameter 1569 according to the unrecognized message and parameter handling rules 1570 defined in Sections 3 and 4 in [10]. 1572 According to the rules, if an error report to the message sender is 1573 needed, the ENRP server that discovered the error SHOULD send back an 1574 ENRP_ERROR message with proper error cause code. 1576 4. Variables and Thresholds 1578 4.1 Variables 1580 peer.last.heard - the local time that a peer server was last heard 1581 (via receiving either a multicast or point-to-point message from 1582 the peer). 1584 pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server 1585 keeps for a peer. A separate PE checksum is kept for each of its 1586 known peers as well as for itself. 1588 4.2 Thresholds 1590 MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will 1591 make to contact an ENRP server (Default=3 times). 1593 TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will 1594 wait for a response from an ENRP server (Default=5 seconds). 1596 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1597 heartbeat message to all its known peers. (Default=30 secs.) 1599 SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a 1600 SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) 1602 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1603 will wait before considering a silent peer server potentially 1604 dead. (Default=61 secs.) 1606 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1607 sender will wait for a response after sending out a message. 1608 (Default=5 secs.) 1610 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a 1611 PE that an ENRP server will allow before purging this PE from the 1612 handlespace. (Default=3) 1614 5. Security Considerations 1616 Threats Introduced by Rserpool and Requirements for Security in 1617 Response to Threats [11] describes the threats to the Rserpool 1618 architecture in detail and lists the security requirements in 1619 response to each threat. From the threats described in this 1620 document, the security services required for the Rserpool protocol 1621 are enumerated below. 1623 Threat 1) PE registration/deregistration flooding or spoofing 1624 ----------- 1625 Security mechanism in response: ENRP server authenticates the PE 1627 Threat 2) PE registers with a malicious ENRP server 1628 ----------- 1629 Security mechanism in response: PE authenticates the ENRP server 1631 Threat 1 and 2 taken together results in mutual authentication of the 1632 ENRP server and the PE. 1634 Threat 3) Malicious ENRP server joins the ENRP server pool 1635 ----------- 1636 Security mechanism in response: ENRP servers mutually authenticate 1638 Threat 4) A PU communicates with a malicious ENRP server for name 1639 resolution 1640 ----------- 1641 Security mechanism in response: The PU authenticates the ENRP server 1643 Threat 5) Replay attack 1644 ----------- 1645 Security mechanism in response: Security protocol which has 1646 protection from replay attacks 1648 Threat 6) Corrupted data which causes a PU to have misinformation 1649 concerning a pool handle resolution 1650 ----------- 1651 Security mechanism in response: Security protocol which supports 1652 integrity protection 1654 Threat 7) Eavesdropper snooping on handlespace information 1655 ----------- 1656 Security mechanism in response: Security protocol which supports data 1657 confidentiality 1659 Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP 1660 server 1661 ----------- 1662 Security mechanism in response: ASAP must control the number of 1663 endpoint unreachable messages transmitted from the PU to the ENRP 1664 server. 1666 Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the 1667 ENRP server 1668 ----------- 1669 Security mechanism in response: ENRP server must control the number 1670 of Endpoint_KeepAlive messages to the PE 1672 To summarize the threats 1-7 require security mechanisms which 1673 support authentication, integrity, data confidentiality, protection 1674 from replay attacks. 1676 For Rserpool we need to authenticate the following: 1678 PU <---- ENRP Server (PU authenticates the ENRP server) 1679 PE <----> ENRP Server (mutual authentication) 1680 ENRP server <-----> ENRP Server (mutual authentication) 1682 We do not define any new security mechanisms specifically for 1683 responding to threats 1-7. Rather we use existing IETF security 1684 protocols to provide the security services required. TLS supports 1685 all these requirements and MUST be implemented. The 1686 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a 1687 minimum by implementers of TLS for Rserpool. For purposes of 1688 backwards compatibility, ENRP SHOULD support 1689 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 1690 other ciphersuite. 1692 Threat 8 requires the ASAP protocol to limit the number of 1693 Endpoint_Unreachable messages (see Section 3.5??? in [1]) to the ENRP 1694 server. 1696 Threat 9 requires the ENRP protocol to limit the number of 1697 Endpoint_KeepAlive messages to the PE (see Section x.y???). 1699 5.1 Implementing Security Mechanisms 1701 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must 1702 support mutual authentication. ENRP servers must support mutual 1703 authentication among themselves. PUs MUST authenticate ENRP servers. 1705 ENRP servers and PEs SHOULD possess a site certificate whose subject 1706 corresponds to their canonical hostname. PUs MAY have certificates 1707 of their own for mutual authentication with TLS, but no provisions 1708 are set forth in this document for their use. All Rserpool elements 1709 that support TLS MUST have a mechanism for validating certificates 1710 received during TLS negotiation; this entails possession of one or 1711 more root certificates issued by certificate authorities (preferably 1712 well-known distributors of site certificates comparable to those that 1713 issue root certificates for web browsers). 1715 Implementations MUST support TLS with SCTP as described in RFC3436 1716 [8] or TLS over TCP as described in RFC2246 [6]. When using TLS/SCTP 1717 we must ensure that RSerPool does not use any features of SCTP that 1718 are not available to an TLS/SCTP user. This is not a difficult 1719 technical problem, but simply a requirement. When describing an API 1720 of the RSerPool lower layer we have also to take into account the 1721 differences between TLS and SCTP. 1723 6. Acknowledgements 1725 The authors wish to thank John Loughney, Lyndon Ong, and many others 1726 for their invaluable comments. 1728 7. References 1730 7.1 Normative References 1732 [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1733 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-10 1734 (work in progress), June 2004. 1736 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1737 J. and M. Stillman, "Requirements for Reliable Server Pooling", 1738 RFC 3237, January 2002. 1740 [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, 1741 "Architecture for Reliable Server Pooling", 1742 draft-ietf-rserpool-arch-07 (work in progress), October 2003. 1744 [4] Bradner, S., "The Internet Standards Process -- Revision 3", 1745 BCP 9, RFC 2026, October 1996. 1747 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1748 Levels", BCP 14, RFC 2119, March 1997. 1750 [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1751 2246, January 1999. 1753 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1754 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 1755 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1757 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC 1758 3436, December 2002. 1760 [9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On 1761 the Use of Stream Control Transmission Protocol (SCTP) with 1762 IPsec", RFC 3554, July 2003. 1764 [10] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1765 Server Access Protocol (ASAP) and Endpoint Name Resolution 1766 (ENRP) common parameters document", 1767 draft-ietf-rserpool-common-param-07 (work in progress), October 1768 2004. 1770 [11] Stillman, M., "Threats Introduced by Rserpool and Requirements 1771 for Security in Response to Threats", 1772 draft-ietf-rserpool-threats-03 (work in progress), July 2004 1774 7.2 Informative References 1776 [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1777 Recommendations for Security", RFC 1750, December 1994. 1779 Authors' Addresses 1781 Qiaobing Xie 1782 Motorola, Inc. 1783 1501 W. Shure Drive, 2-F9 1784 Arlington Heights, IL 60004 1785 US 1787 Phone: 1788 EMail: qxie1@email.mot.com 1790 Randall R. Stewart 1791 Cisco Systems, Inc. 1792 4875 Forest Drive 1793 Suite 200 1794 Columbia, SC 29206 1795 USA 1797 Phone: 1798 EMail: rrs@cisco.com 1800 Maureen Stillman 1801 Nokia 1802 127 W. State Street 1803 Ithaca, NY 14850 1804 US 1806 Phone: 1807 EMail: maureen.stillman@nokia.com 1809 Michael Tuexen 1810 Germany 1812 Phone: 1813 EMail: tuexen@fh-muenster.de 1815 Intellectual Property Statement 1817 The IETF takes no position regarding the validity or scope of any 1818 Intellectual Property Rights or other rights that might be claimed to 1819 pertain to the implementation or use of the technology described in 1820 this document or the extent to which any license under such rights 1821 might or might not be available; nor does it represent that it has 1822 made any independent effort to identify any such rights. Information 1823 on the procedures with respect to rights in RFC documents can be 1824 found in BCP 78 and BCP 79. 1826 Copies of IPR disclosures made to the IETF Secretariat and any 1827 assurances of licenses to be made available, or the result of an 1828 attempt made to obtain a general license or permission for the use of 1829 such proprietary rights by implementers or users of this 1830 specification can be obtained from the IETF on-line IPR repository at 1831 http://www.ietf.org/ipr. 1833 The IETF invites any interested party to bring to its attention any 1834 copyrights, patents or patent applications, or other proprietary 1835 rights that may cover technology that may be required to implement 1836 this standard. Please address the information to the IETF at 1837 ietf-ipr@ietf.org. 1839 Disclaimer of Validity 1841 This document and the information contained herein are provided on an 1842 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1843 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1844 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1845 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1846 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1847 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1849 Copyright Statement 1851 Copyright (C) The Internet Society (2004). This document is subject 1852 to the rights, licenses and restrictions contained in BCP 78, and 1853 except as set forth therein, the authors retain all their rights. 1855 Acknowledgment 1857 Funding for the RFC Editor function is currently provided by the 1858 Internet Society.