idnits 2.17.1 draft-ietf-rserpool-enrp-16.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 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1954. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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: MUST be set to '1' if the sender of this message is rejecting a handlespace request. In this case, pool entries MUST not be included. This might happen if the sender of this message is in the middle of initializing its database or it is under high load. == 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 (July 9, 2007) is 6136 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 1825, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1846, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1861, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-12 == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-10 ** Obsolete normative reference: RFC 2246 (ref. '7') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2960 (ref. '9') (Obsoleted by RFC 4960) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-09 == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-05 ** Obsolete normative reference: RFC 4346 (ref. '14') (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. '15') (Obsoleted by RFC 4086) Summary: 5 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 Intended status: Experimental R. Stewart 5 Expires: January 10, 2008 Cisco Systems, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Muenster Univ. of Applied Sciences 10 A. Silverton 11 Motorola, Inc. 12 July 9, 2007 14 Endpoint Handlespace Redundancy Protocol (ENRP) 15 draft-ietf-rserpool-enrp-16.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 10, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to 49 work in conjunction with the Aggregate Server Access Protocol (ASAP) 50 to 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 . . . . . . . . . . . . . . . . 12 68 2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 69 2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 70 2.8. ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 71 2.9. ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15 72 2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 16 73 3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . . 17 74 3.1. Methods for Communicating amongst ENRP Servers . . . . . . 17 75 3.2. ENRP Server Initialization . . . . . . . . . . . . . . . . 18 76 3.2.1. Generate a Server Identifier . . . . . . . . . . . . . 18 77 3.2.2. Acquire Peer Server List . . . . . . . . . . . . . . . 19 78 3.2.3. Download ENRP Handlespace Data from Mentor Peer . . . 21 79 3.3. Handle PE Registration . . . . . . . . . . . . . . . . . . 23 80 3.3.1. Rules on PE Re-registration . . . . . . . . . . . . . 24 81 3.4. Handle PE De-registration . . . . . . . . . . . . . . . . 25 82 3.5. Pool Handle Translation . . . . . . . . . . . . . . . . . 26 83 3.6. Server Handlespace Update . . . . . . . . . . . . . . . . 27 84 3.6.1. Announcing Addition or Update of PE . . . . . . . . . 27 85 3.6.2. Announcing Removal of PE . . . . . . . . . . . . . . . 28 86 3.7. Detecting and Removing Unreachable PE . . . . . . . . . . 28 87 3.8. Helping PE and PU to Discover Home ENRP Server . . . . . . 29 88 3.9. Maintaining Peer List and Monitoring Peer Status . . . . . 29 89 3.9.1. Discovering New Peer . . . . . . . . . . . . . . . . . 30 90 3.9.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 30 91 3.9.3. Detecting Peer Server Failure . . . . . . . . . . . . 30 92 3.10. Taking-over a Failed Peer Server . . . . . . . . . . . . . 30 93 3.10.1. Initiating Server Take-over Arbitration . . . . . . . 31 94 3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32 95 3.11. Handlespace Data Auditing and Re-synchronization . . . . . 32 96 3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33 97 3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 33 98 3.11.3. Re-synchronization Procedures . . . . . . . . . . . . 34 99 3.12. Handling Unrecognized Message or Unrecognized Parameter . 35 100 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36 101 4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 102 4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 103 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 104 5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 37 105 5.2. A New Table for Update Action Types . . . . . . . . . . . 37 106 5.3. Multicast Addresses . . . . . . . . . . . . . . . . . . . 38 107 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 108 6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 39 109 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 40 110 6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 41 111 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 112 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 113 8.1. Normative References . . . . . . . . . . . . . . . . . . . 44 114 8.2. Informative References . . . . . . . . . . . . . . . . . . 45 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 116 Intellectual Property and Copyright Statements . . . . . . . . . . 48 118 1. Introduction 120 ENRP is designed to work in conjunction with ASAP [1] to accomplish 121 the functionality of RSerPool as defined by its requirements [2] and 122 architecture [3]. 124 Within the operational scope of RSerPool, ENRP defines the procedures 125 and message formats of a distributed fault-tolerant registry service 126 for storing, bookkeeping, retrieving, and distributing pool operation 127 and membership information. 129 Whenever appropriate, in the rest of this document we will refer to 130 this RSerPool registry service as ENRP handlespace, or simply 131 handlespace because it manages all pool handles. 133 1.1. Definitions 135 This document uses the following terms: 137 Operational scope: See [3]; 139 Pool (or server pool): See [3]; 141 Pool handle: See [3]; 143 Pool element (PE): See [3]; 145 Pool user (PU): See [3]; 147 Pool element handle: See [3]; 149 ENRP handlespace (or handlespace): See [3]; 151 ENRP client channel: The communication channel through which an ASAP 152 User (either a PE or PU) requests ENRP handlespace service. The 153 client channel is usually defined by the transport address of the 154 home server and a well-known port number. The channel MAY make 155 use of multi-cast or a named list of ENRP servers. 157 ENRP server channel: Defined by a well-known multicast IP address 158 and a well known port number. All ENRP servers in an operational 159 scope can send multicast messages to other servers through this 160 channel. PEs are also allowed to multicast on this channel 161 occasionally; 163 Home ENRP server: The ENRP server to which a PE or PU currently 164 belongs. A PE MUST only have one home ENRP server at any given 165 time and both the PE and its home ENRP server MUST keep track of 166 this master/slave relationship between them. A PU SHOULD select 167 one of the available ENRP servers as its home ENRP server, but the 168 ENRP server does not need to know, nor does it need to keep track 169 of this relationship. 171 1.2. Conventions 173 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 174 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 175 they appear in this document, are to be interpreted as described in 176 [6]. 178 2. ENRP Message Definitions 180 In this section, we define the format of all ENRP messages. These 181 are messages sent and received amongst ENRP servers in an operational 182 scope. Messages sent and received between a PE/PU and an ENRP server 183 are part of ASAP and are defined in [1]. A common format, that is 184 defined in [12], is used for all ENRP and ASAP messages. 186 Most ENRP messages contains a combination of fixed fields and TLV 187 parameters. The TLV (Type-Length_value) parameters are also defined 188 in [12]. 190 All messages, as well as their fields/parameters described below, 191 MUST be transmitted in network byte order (a.k.a. Big Endian, 192 meaning the most significant byte is transmitted first). 194 For ENRP, the following message types are defined in this section: 196 Type Message Name 197 ----- ------------------------- 198 0x00 - (reserved by IETF) 199 0x01 - ENRP_PRESENCE 200 0x02 - ENRP_HANDLE_TABLE_REQUEST 201 0x03 - ENRP_HANDLE_TABLE_RESPONSE 202 0x04 - ENRP_HANDLE_UPDATE 203 0x05 - ENRP_LIST_REQUEST 204 0x06 - ENRP_LIST_RESPONSE 205 0x07 - ENRP_INIT_TAKEOVER 206 0x08 - ENRP_INIT_TAKEOVER_ACK 207 0x09 - ENRP_TAKEOVER_SERVER 208 0x0a - ENRP_ERROR 209 0x0b-0xff - (reserved by IETF) 211 Figure 1 213 Except for the ENRP_PRESENCE message, the usage of the ENRP server 214 channel is for further study. The usage of point-to-point 215 communications is assumed in this specification. 217 2.1. ENRP_PRESENCE message 219 This ENRP message is used to announce (periodically) the presence of 220 an ENRP server, or to probe the status of a peer ENRP server. This 221 message is either send on the ENRP server channel or point-to-point 222 to another ENRP server. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Sending Server's ID | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Receiving Server's ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 : PE Checksum Param : 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 : Server Information Param (optional) : 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 R (reply_required) flag: 1 bit 240 Set to '1' if the sender requires a response to this message, 241 otherwise set to '0'. If sent to the ENRP server channel this 242 field MUST be set to '0'. 244 Sending Server's ID: 32 bit (unsigned integer) 246 This is the ID of the ENRP server which sent this message. 248 Receiving Server's ID: 32 bit (unsigned integer) 250 This is the ID of the ENRP server to which this message is 251 intended. If the message is not intended for an individual 252 server (e.g., the message is multicasted to a group of 253 servers), this field MUST be sent with all 0's. If the message 254 is send point-to-point this field MAY be sent with all 0's. 256 PE Checksum Parameter: 258 This is a TLV that contains the latest PE checksum of the ENRP 259 server who sends the ENRP_PRESENCE. This parameter SHOULD be 260 included for handlespace consistency auditing. See 261 Section 3.11.1 for details. 263 Server Information Parameter: 265 If this parameter is present, it contains the server 266 information of the sender of this message (Server Information 267 Parameter is defined in [12]). This parameter is optional. 268 However, if this message is sent in response to a received 269 "reply required" ENRP_PRESENCE from a peer, the sender then 270 MUST include its server information. 272 Note, at startup an ENRP server MUST pick a randomly generated, non- 273 zero 32-bit unsigned integer as its ID and MUST use this same ID 274 until the ENRP server is rebooted. 276 2.2. ENRP_HANDLE_TABLE_REQUEST message 278 An ENRP server sends this message to one of its peers to request a 279 copy of the handlespace data. This message is normally used during 280 server initialization or handlespace re-synchronization. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Sending Server's ID | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Receiving Server's ID | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 W (oWn-children-only) flag: 1 bit 294 Set to '1' if the sender of this message is only requesting 295 information about the PEs owned by the message receiver. 296 Otherwise, set to '0'. 298 Sending Server's ID: 300 See Section 2.1. 302 Receiving Server's ID: 304 See Section 2.1. 306 2.3. ENRP_HANDLE_TABLE_RESPONSE message 308 The PEER_NAME_TABLE_RESPONSE message is sent by an ENRP server in 309 response to a received PEER_NAME_TABLE_REQUEST message to assist peer 310 server initialization or handle-space synchronization. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type = 0x03 |0|0|0|0|0|0|M|R| Message Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Sending Server's ID | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Receiving Server's ID | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 : : 322 : Pool entry #1 (optional) : 323 : : 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 : : 326 : ... : 327 : : 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 : : 330 : Pool entry #n (optional) : 331 : : 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 M (More_to_send) flag: 1 bit 336 Set to '1' if the sender of this message has more pool entries 337 to send in subsequent ENRP_HANDLE_TABLE_RESPONSE messages. 338 Otherwise, set to '0'. 340 R (Reject) flag: 1 bit 342 MUST be set to '1' if the sender of this message is rejecting a 343 handlespace request. In this case, pool entries MUST not be 344 included. This might happen if the sender of this message is 345 in the middle of initializing its database or it is under high 346 load. 348 Message Length: 16 bits (unsigned integer) 350 Indicates the entire length of the message including the header 351 in number of octets. 353 Note, the value in Message Length field will NOT cover any 354 padding at the end of this message. 356 Sending Server's ID: 358 See Section 2.1. 360 Receiving Server's ID: 362 See Section 2.1. 364 Pool entry #1-#n: 366 If the R flag is set to '0', at least one pool entry SHOULD be 367 present in this message. Each pool entry MUST start with a 368 Pool Handle parameter as defined in section 3.1.7, and is 369 followed by one or more Pool Element parameters in TLV format, 370 as shown below: 372 +---------------------------+ 373 : Pool handle : 374 +---------------------------+ 375 : PE #1 : 376 +---------------------------+ 377 : PE #2 : 378 +---------------------------+ 379 : ... : 380 +---------------------------+ 381 : PE #n : 382 +---------------------------+ 384 2.4. ENRP_HANDLE_UPDATE message 386 The PEER_NAME_UPDATE message is sent by the home ENRP server of a PE 387 to all peer servers to announce registration, reregistration, or 388 deregistration of the PE in the handle-space. 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Sending Server's ID | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Receiving Server's ID | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Update Action | (reserved) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 : Pool Handle Parameter : 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 : Pool Element Parameter : 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Message Length: 16 bits (unsigned integer) 408 Indicates the entire length of the message including the header 409 in number of octets. 411 Note, the value in Message Length field will NOT cover any 412 padding at the end of this message. 414 Update Action: 16 bits (unsigned integer) 416 This field indicates the requested action of the specified PE. 417 The field MUST be set to one of the following values: 419 0x0000 - ADD_PE: Add or update the specified PE in the ENRP 420 handlespace 422 0x0001 - DEL_PE: Delete the specified PE from the ENRP 423 handlespace. 425 0x0002 - 0xFFFF: Reserved by IETF. 427 Other values are reserved by IETF and MUST not be used. 429 Reserved: 16 bits 431 This field MUST be set to all 0's by sender and ignored by the 432 receiver. 434 Sending Server's ID: 436 See Section 2.1. 438 Receiving Server's ID: 440 See Section 2.1. 442 Pool handle: 444 Specifies to which the PE belongs. 446 Pool Element: 448 Specifies the PE. 450 2.5. ENRP_LIST_REQUEST message 452 The PEER_LIST_REQUEST message is sent to request a current copy of 453 the ENRP server list. This message is normally sent from a newly 454 activated ENRP server to an established ENRP server as part of the 455 initialization process. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Sending Server's ID | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Receiving Server's ID | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Sending Server's ID: 469 See Section 2.1. 471 Receiving Server's ID: 473 See Section 2.1. 475 2.6. ENRP_LIST_RESPONSE message 477 The PEER_LIST_RESPONSE message is sent in response from an ENRP 478 server that receives a PEER_LIST_REQUEST message to return 479 information about known ENRP servers. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type = 0x06 |0|0|0|0|0|0|0|R| Message Length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Sending Server's ID | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Receiving Server's ID | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 : Server Information Parameter of Peer #1 : 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 : ... : 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 : Server Information Parameter of Peer #n : 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 R (Reject) flag: 1 bit 499 This flag MUST be set to '1' if the sender of this message is 500 rejecting a PEER_LIST_REQUEST message. If this case occurs, 501 the message MUST NOT include any Server Information Parameters. 503 Message Length: 16 bits (unsigned integer) 505 Indicates the entire length of the message in number of octets. 507 Note, the value in Message Length field will NOT cover any 508 padding at the end of this message. 510 Sending Server's ID: 512 See Section 2.1. 514 Receiving Server's ID: 516 See Section 2.1. 518 Server Information Parameter of Peer #1-#n: 520 Each contains a Server Information Parameter of a peer known to 521 the sender. The Server Information Parameter is defined in 522 [12]. 524 2.7. ENRP_INIT_TAKEOVER message 526 The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the 527 takeover initiator) to announce its intention of taking over a 528 specific peer ENRP server. It is send to all its peers. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Sending Server's ID | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Receiving Server's ID | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Targeting Server's ID | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Sending Server's ID: 544 See Section 2.1. 546 Receiving Server's ID: 548 See Section 2.1. 550 Targeting Server's ID: 32-bit (unsigned integer) 552 This is the ID of the peer ENRP that is the target of this 553 takeover attempt. 555 2.8. ENRP_INIT_TAKEOVER_ACK message 557 The PEER_INIT_TAKEOVER_ACK message is sent in response to a takeover 558 initiator to acknowledge the reception of the PEER_INIT_TAKEROVER 559 message and that it does not object to the takeover. 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Sending Server's ID | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Receiving Server's ID | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Targeting Server's ID | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Sending Server's ID: 575 See Section 2.1. 577 Receiving Server's ID: 579 See Section 2.1. 581 Targeting Server's ID: 583 This is the ID of the peer ENRP that is the target of this 584 takeover attempt. 586 2.9. ENRP_TAKEOVER_SERVER message 588 The PEER_TAKEOVER_REGISTRAR message is sent by the takeover initiator 589 to declare the enforcement of a takeover to all active peer ENRP 590 servers. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Sending Server's ID | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Receiving Server's ID | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Targeting Server's ID | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Sending Server's ID: 605 See Section 2.1. 607 Receiving Server's ID: 609 See Section 2.1. 611 Targeting Server's ID: 613 This is the ID of the peer ENRP that is the target of this 614 takeover operation. 616 2.10. ENRP_ERROR message 618 The ENRP_ERROR message is sent by a registrar to report an 619 operational error to a peer ENRP server. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Sending Server's ID | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Receiving Server's ID | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 : Operational Error Parameter : 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Sending Server's ID: 635 See Section 2.1. 637 Receiving Server's ID: 639 See Section 2.1. 641 Operational Error Parameter: 643 This parameter, defined in [12], indicates the type of error(s) 644 being reported. 646 3. ENRP Operation Procedures 648 In this section, we discuss the operation procedures defined by ENRP. 649 An ENRP server MUST follow these procedures when sending, receiving, 650 or processing ENRP messages. 652 Many of the RSerPool events call for both server-to-server and PU/ 653 PE-to-server message exchanges. Only the message exchanges and 654 activities between an ENRP server and its peer(s) are considered 655 within the ENRP scope and are defined in this document. 657 Procedures for exchanging messages between a PE/PU and ENRP servers 658 are defined in [1]. 660 3.1. Methods for Communicating amongst ENRP Servers 662 Within an RSerPool operational scope, ENRP servers need to 663 communicate with each other in order to exchange information such as 664 the pool membership changes, handlespace data synchronization, etc. 666 Two types of communications are used amongst ENRP servers: 668 o point-to-point message exchange from one ENPR server to a specific 669 peer server, and 671 o announcements from one server to all its peer servers in the 672 operational scope. 674 Point-to-point communication is always carried out over an SCTP 675 association between the sending server and the receiving server. 677 Announcements are communicated out with one of the following two 678 approaches: 680 1. The sending server sends the announcement message to the ENRP 681 server channel. This must also handle the relation between the 682 ENRP server channel and the operational scope. The usage of the 683 ENRP server channel is for further study. 685 2. The sending server sends multiple copies of the announcement, one 686 to each of its peer servers, over a set of point-to-point SCTP 687 associations between the sending server and the peers. 689 In order to maximize inter-operability of ENRP servers, the following 690 rules MUST be followed: 692 1. At the startup time, a new ENRP server SHOULD make a decision on 693 whether it will enable IP multicast for ENRP announcements. This 694 decision should be based on preconfigured information such as the 695 availability of IP multicast and the security requirements from 696 the user of RSerPool. 698 2. If an ENRP server disables multicast, it then: 700 A. MUST NOT subscribe to the well-known server multicast 701 channel, i.e., it only receives peer announcements over SCTP 702 associations, and 704 B. MUST transmit all its out-going announcements over point-to- 705 point SCTP associations with its peers. 707 3. If an ENRP server enables itself to use multicast, it then: 709 A. MUST subscribe to the well-known server multicast channel to 710 ready itself for receiving peers' multicast announcements, 712 B. MUST also be prepared to receive peer announcements over 713 point-to-point SCTP associations from peers. 715 C. MUST track internally which peers are multicast-enabled and 716 which are not. Note: A peer is always assumed to be 717 multicast-disabled until/unless an ENRP message of any type 718 is received from that peer over the well-known server 719 multicast channel. 721 D. when sending out an announcement, MUST send a copy to the 722 ENRP server channel AND a copy to each of the peers that are 723 marked as multicast-disabled over a point-to-point SCTP 724 association. 726 3.2. ENRP Server Initialization 728 This section describes the steps a new ENRP server needs to take in 729 order to join the other existing ENRP servers, or to initiate the 730 handlespace service if it is the first ENRP server started in the 731 operational scope. 733 3.2.1. Generate a Server Identifier 735 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 736 as unique as possible in the operational scope and this server Id 737 MUST remain unchanged for the lifetime of the server. Normally, a 738 good 32-bit random number will be good enough as the server Id ([15] 739 provides some information on randomness guidelines). 741 Note, there is a very remote chance (about 1 in about 4 billion) that 742 two ENRP servers in an operational scope will generate the same 743 server Id and hence cause a server Id conflict in the pool. However, 744 no severe consequence of such a conflict has been identified. 746 3.2.2. Acquire Peer Server List 748 At startup, the ENRP server (initiating server) will first attempt to 749 learn all existing peer ENRP servers in the same operational scope, 750 or to determine that it is alone in the scope. 752 The initiating server uses an existing peer server to bootstrap 753 itself into service. We call this peer server the mentor server. 755 3.2.2.1. Finding the mentor server 757 If the initiating server is told about an existing peer server 758 through some administrative means (such as DNS query, configuration 759 database, startup scripts, etc), the initiating server SHOULD then 760 use this peer server as its mentor server and SHOULD skip the 761 remaining steps in this subsection. 763 If multiple existing peer servers are specified, the initiating 764 server SHOULD pick one of them as its mentor server, keep the others 765 as its backup mentor servers, and skip the remaining steps in this 766 subsection. 768 If no existing peer server is specified to the initiating server AND 769 if multicast is available in the operational scope, the following 770 mentor server discovery procedures SHOULD be followed: 772 1. The initiating server SHOULD first join the ENRP server channel. 774 2. When the first ENRP_PRESENCE message arrives, the server SHOULD 775 take the sender of this received response as its mentor server. 776 This completes the discovery of the mentor server. 778 If ENRP_PRESENCE messages are also received from other peers (a 779 likely event when multiple peers exist in the operational scope 780 at the time the new server started), the initiating server SHOULD 781 keep a list of those responded as its backup mentor servers (see 782 below). 784 3. If no response to its ENRP_PRESENCE message are received after 785 TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat 786 steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After 787 that, if there is still no response, the initiating server MUST 788 assume that it is alone in the operational scope. 790 4. If the initiating server determined that it is alone in the 791 scope, it MUST skip the procedures in Section 3.2.2.2 and 792 Section 3.2.3 and MUST consider its initialization completed and 793 start offering ENRP services. 795 Note, if multicast is not available (or not allowed for reasons such 796 as security concerns) in the operational scope, at least one peer 797 server MUST be specified to the initiating server through 798 administrative means, unless the initiation server is the first 799 server to start in the operational scope. 801 Note, if the administratively specified mentor peer(s) fails and the 802 ENRP server channel is available, the initiating server SHOULD use 803 the auto-discover procedure defined in steps 1-5 above. 805 3.2.2.2. Request complete server list from mentor peer 807 Once the initiating server finds its mentor peer server (by either 808 discovery or administrative means), the initiating server MUST send 809 an ENRP_LIST_REQUEST message to the mentor peer server to request a 810 copy of the complete server list maintained by the mentor peer (see 811 Section 3.9 for maintaining server list). 813 The initiating server SHOULD start a MAX-TIME-NO-RESPONSE timer every 814 time it finishes sending an ENRP_LIST_REQUEST message. If the timer 815 expires before receiving a response from the mentor peer, the 816 initiating server SHOULD abort and send a new server list request to 817 a backup mentor peer, if one is available. 819 Upon the reception of this request, the mentor peer server SHOULD 820 reply with an ENRP_LIST_RESPONSE message and include in the message 821 body all existing ENRP servers known by the mentor peer. 823 Upon the reception of the ENRP_LIST_RESPONSE message from the mentor 824 peer, the initiating server MUST use the server information carried 825 in the message to initialize its own peer list. 827 However, if the mentor itself is in the process of startup and not 828 ready to provide a peer server list (for example, the mentor peer is 829 waiting for a response to its own ENRP_LIST_REQUEST to another 830 server), it MUST reject the request by the initiating server and 831 respond with an ENRP_LIST_RESPONSE message with the R flag set to 832 '1', and with no server information included in the response. 834 In the case where its ENRP_LIST_REQUEST is rejected by the mentor 835 peer, the initiating server SHOULD either wait for a few seconds and 836 re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a 837 backup mentor peer available, select another mentor peer server and 838 send the ENRP_LIST_REQUEST to the new mentor server. 840 3.2.3. Download ENRP Handlespace Data from Mentor Peer 842 After a peer list download is completed, the initiating server MUST 843 request a copy of the current handlespace data from its mentor peer 844 server, by taking the following steps: 846 1. The initiating server MUST first send a ENRP_HANDLE_TABLE_REQUEST 847 message to the mentor peer, with W flag set to '0', indicating 848 that the entire handlespace is requested. 850 2. Upon the reception of this message, the mentor peer MUST start a 851 download session in which a copy of the current handlespace data 852 maintained by the mentor peer is sent to the initiating server in 853 one or more ENRP_HANDLE_TABLE_RESPONSE messages (Note, the mentor 854 server may find it particularly desirable to use multiple 855 ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when 856 the handlespace is large, especially when forming and sending out 857 a single response containing a large handlespace may interrupt 858 its other services). 860 If more than one ENRP_HANDLE_TABLE_RESPONSE message are used 861 during the download, the mentor peer MUST use the M flag in each 862 ENRP_HANDLE_TABLE_RESPONSE message to indicate whether this 863 message is the last one for the download session. In particular, 864 the mentor peer MUST set the M flag to '1' in the outbound 865 ENRP_HANDLE_TABLE_RESPONSE if there is more data to be 866 transferred and MUST keep track of the progress of the current 867 download session. The mentor peer MUST set the M flag to '0' in 868 the last ENRP_HANDLE_TABLE_RESPONSE for the download session and 869 close the download session (i.e., removing any internal record of 870 the session) after sending out the last message. 872 3. During the downloading, every time the initiating server receives 873 an ENRP_HANDLE_TABLE_RESPONSE message, it MUST transfer the data 874 entries carried in the message into its local handlespace 875 database, and then check whether or not this message is the last 876 one for the download session. 878 If the M flag is set to '1' in the just processed 879 ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST 880 send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer 881 to request for the next ENRP_HANDLE_TABLE_RESPONSE message. 883 4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE 884 message into its local handlespace database, the initiating 885 server MUST handle each pool entry carried in the message using 886 the following rules: 888 A. If the pool does not exist in the local handlespace, the 889 initiating server MUST create the pool in the local 890 handlespace and add the PE(s) in the pool entry to the pool. 892 When creating the pool, the initiation server MUST set the 893 overall member selection policy type of the pool to the 894 policy type indicated in the first PE. 896 B. If the pool already exists in the local handlespace, but the 897 PE(s) in the pool entry is not currently a member of the 898 pool, the initiating server MUST add the PE(s) to the pool. 900 C. If the pool already exists in the local handlespace AND the 901 PE(s) in the Pool entry is already a member of the pool, the 902 initiating server SHOULD replace the attributes of the 903 existing PE(s) with the new information. ENRP will make sure 904 that the information keeps up to date. 906 5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from 907 the mentor peer and unpacked into the local handlespace, the 908 initialization process is completed and the initiating server 909 SHOULD start to provide ENRP services. 911 Under certain circumstances, the mentor peer itself may not be able 912 to provide a handlespace download to the initiating server. For 913 example, the mentor peer is in the middle of initializing its own 914 handlespace database, or it has currently too many download sessions 915 open to other servers. 917 In such a case, the mentor peer MUST reject the request by the 918 initiating server and respond with an ENRP_HANDLE_TABLE_RESPONSE 919 message with the R flag set to '1', and with no pool entries included 920 in the response. 922 In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the 923 mentor peer, the initiating server SHOULD either wait for a few 924 seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor 925 server, or if there is a backup mentor peer available, select another 926 mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new 927 mentor server. 929 A handlespace download session that has been started may get 930 interrupted for some reason. To cope with this, the initiating 931 server SHOULD start a timer every time it finishes sending an 932 ENRP_HANDLE_TABLE_REQUEST to its mentor peer. If this timer expires 933 without receiving a response from the mentor peer, the initiating 934 server SHOULD abort the current download session and re-start a new 935 handlespace download with a backup mentor peer, if one is available. 937 Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, and the 938 mentor peer set the M-bit to 1 to indicate that it has more data to 939 send, it SHOULD start a session timer. If this timer expires without 940 receiving another request from the initiating server, the mentor peer 941 SHOULD abort the session, cleaning out any resource and record of the 942 session. 944 3.3. Handle PE Registration 946 To register itself with the handlespace, a PE sends an 947 ASAP_REGISTRATION message to its home ENRP server. The format of 948 ASAP_REGISTRATION message and rules of sending it are defined in [1]. 950 In the ASAP_REGISTRATION message, the PE indicates the handle of the 951 pool it wishes to join in a pool handle parameter, and its complete 952 transport information and any load control information in a PE 953 parameter. 955 The ENRP server handles the ASAP_REGISTRATION message according to 956 the following rules: 958 1. If the named pool does not exist in the handlespace, the ENRP 959 server MUST creates a new pool with that handle in the 960 handlespace and add the PE to the pool as its first PE; 962 When a new pool is created, the overall member selection policy 963 of the pool MUST be set to the policy type indicated by the first 964 PE, the overall pool transport type MUST be set to the transport 965 type indicated by the PE, and the overall pool data/control 966 channel configuration MUST be set to what is indicated in the 967 Transport Use field of the User Transport parameter by the 968 registering PE. 970 2. If the named pool already exists in the handlespace, but the 971 requesting PE is not currently a member of the pool, the ENRP 972 server will add the PE as a new member to the pool; 974 However, before adding the PE to the pool, the server MUST check 975 if the policy type, transport type, and transport usage indicated 976 by the registering PE is consistent with those of the pool. If 977 different, the ENRP server MUST reject the registration. 979 3. If the named pool already exists in the handlespace AND the 980 requesting PE is already a member of the pool, the ENRP server 981 SHOULD consider this as a re-registration case. The ENRP server 982 MUST perform the same tests on policy, transport type, transport 983 use, as described above. If the re-registration is accepted 984 after the test, the ENRP Server SHOULD replace the attributes of 985 the existing PE with the information carried in the received 986 ASAP_REGISTRATION message. 988 4. After accepting the registration, the ENRP server MUST assign 989 itself the owner of this PE. If this is a re-registration, the 990 ENRP server MUST take over ownership of this PE regardless of 991 whether the PE was previously owned by this server or by another 992 server. The ENRP server MUST also record the SCTP transport 993 address from which it received the ASAP_REGISTRATION in the ASAP 994 Transport parameter TLV inside the PE parameter of this PE. 996 5. The ENRP server may reject the registration due to other reasons 997 such as invalid values, lack of resource, authentication failure, 998 etc. 1000 In all above cases, the ENRP server MUST reply to the requesting PE 1001 with an ASAP_REGISTRATION_RESPONSE message. If the registration is 1002 accepted, the ENRP server MUST set the 'R' flag in the 1003 ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, 1004 the ENRP server MUST indicate the rejection by setting the 'R' flag 1005 in the ASAP_REGISTRATION_RESPONSE to '1'. 1007 If the registration is rejected, the ENRP server SHOULD include the 1008 proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message. 1010 If the registration is granted (either a new registration or a re- 1011 registration case), the ENRP server MUST assign itself to be the home 1012 ENRP server of the PE, i.e., to "own" the PE. 1014 Implementation note: for better performance, the ENRP server may 1015 find it both efficient and convenient to internally maintain two 1016 separate PE lists or tables - one is for the PEs that are "owned" 1017 by the ENRP server and the other for all the PEs owned by its 1018 peer(s). 1020 Moreover, if the registration is granted, the ENRP server MUST take 1021 the handlespace update action as described in Section 3.6 to inform 1022 its peers about the change just made. If the registration is denied, 1023 no message will be sent to its peers. 1025 3.3.1. Rules on PE Re-registration 1027 A PE may re-register itself to the handlespace with a new set of 1028 attributes in order to, for example, extend its registration life, 1029 change its load factor value, etc. as described in the ASAP 1030 specification. 1032 A PE may modify its load factor value at any time via re- 1033 registration. Based on the number of PEs in the pool and the pool's 1034 overall policy type, this operation allows the PE to dynamically 1035 control its share of inbound messages received by the pool (also see 1036 Section ???? in [1] for more on load control). 1038 Moreover, when re-registering, the PE MUST NOT change its policy 1039 type. The server MUST reject the re-registration if the PE attempt 1040 to change its policy type. In the rejection, the server SHOULD 1041 attach an error code "Pooling Policy Inconsistent". 1043 Regardless whether it is the current owner of the PE, if the re- 1044 registration is granted to the PE, the ENRP server MUST assign itself 1045 to be the new home ENRP server of the PE. 1047 Moreover, if the re-registration is granted, the ENRP server MUST 1048 take the handlespace update action as described in Section 3.6 to 1049 inform its peers about the change just made. If the re-registration 1050 is denied, no message will be sent to its peers. 1052 3.4. Handle PE De-registration 1054 To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION 1055 message to its home ENRP server. The complete format of 1056 ASAP_DEREGISTRATION message and rules of sending it are defined in 1057 [1]. 1059 In the ASAP_DEREGISTRATION message the PE indicates the handle of the 1060 pool it belongs to in a pool handle parameter and provides its PE 1061 identifier. 1063 Upon receiving the message, the ENRP server SHALL remove the PE from 1064 its handlespace. Moreover, if the PE is the last one of the named 1065 pool, the ENRP server will remove the pool from the handlespace as 1066 well. 1068 If the ENRP server fails to find any record of the PE in its 1069 handlespace, it SHOULD consider the de-registration granted and 1070 completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the 1071 PE. 1073 The ENRP server may reject the de-registration request for various 1074 reasons, such as invalid parameters, authentication failure, etc. 1076 In response, the ENRP server MUST send an 1077 ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de- 1078 registration is rejected, the ENRP server MUST indicate the rejection 1079 by including the proper Operational Error parameter. 1081 It should be noted that de-registration does not stop the PE from 1082 sending or receiving application messages. 1084 Once the de-registration request is granted AND the PE removed from 1085 its local copy of the handlespace, the ENRP server MUST take the 1086 handlespace update action described in Section 3.6 to inform its 1087 peers about the change just made. Otherwise, the ENRP server MUST 1088 NOT inform its peers. 1090 3.5. Pool Handle Translation 1092 A PU uses the pool handle translation service of an ENRP server to 1093 resolve a pool handle to a list of accessible transport addresses of 1094 the member PEs of the pool. 1096 This requires the PU to send an ASAP_HANDLE_RESOLUTION message to its 1097 home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify 1098 the pool handle to be translated in a Pool Handle parameter. 1099 Complete definition of the ASAP_HANDLE_RESOLUTION message and the 1100 rules of sending it are defined in [1]. 1102 An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION 1103 requests from PUs either over an SCTP association on the well-know 1104 SCTP port, or over a TCP connection on the well-know TCP port. 1106 Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server 1107 MUST first look up the pool handle in its handlespace. If the pool 1108 exits, the home ENRP server MUST compose and send back an 1109 ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. 1111 In the response message, the ENRP server SHOULD list all the PEs 1112 currently registered in this pool, in a list of PE parameters. The 1113 ENRP server MUST also include a pool member selection policy 1114 parameter to indicate the overall member selection policy for the 1115 pool, if the current pool member selection policy is not round-robin. 1117 If the named pool does not exist in the handlespace, the ENRP server 1118 MUST reject the handle resolution request by responding with an 1119 ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor 1120 Handle error. 1122 The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and 1123 the rules of receiving it are defined in [1]. 1125 3.6. Server Handlespace Update 1127 This includes a set of update operations used by an ENRP server to 1128 inform its peers when its local handlespace is modified, e.g., 1129 addition of a new PE, removal of an existing PE, change of pool or PE 1130 properties. 1132 3.6.1. Announcing Addition or Update of PE 1134 When a new PE is granted registration to the handlespace or an 1135 existing PE is granted a re-registration, the home ENRP server uses 1136 this procedure to inform all its peers. 1138 This is an ENRP announcement and is sent to all the peer of the home 1139 ENRP server. See Section 3.1 on how announcements are sent. 1141 An ENRP server MUST announce this update to all its peers in a 1142 ENRP_HANDLE_UPDATE message with the Update Action field set to 1143 ADD_PE, indicating the addition of a new PE or the modification of an 1144 existing PE. The complete new information of the PE and the pool its 1145 belongs to MUST be indicated in the message with a PE parameter and a 1146 Pool Handle parameter, respectively. 1148 The home ENRP server SHOULD fill in its server Id in the Sending 1149 Server's ID field and leave the Receiving Server's ID blank (i.e., 1150 all 0's). 1152 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take 1153 the following actions: 1155 1. If the named pool indicated by the pool handle does not exist in 1156 its local copy of the handlespace, the peer MUST create the named 1157 pool in its local handlespace and add the PE to the pool as the 1158 first PE. It MUST then copy in all other attributes of the PE 1159 carried in the message. 1161 When the new pool is created, the overall member selection policy 1162 of the pool MUST be set to the policy type indicated by the PE. 1164 2. If the named pool already exists in the peer's local copy of the 1165 handlespace AND the PE does not exist, the peer MUST add the PE 1166 to the pool as a new PE and copy in all attributes of the PE 1167 carried in the message. 1169 3. If the named pool exists AND the PE is already a member of the 1170 pool, the peer MUST replace the attributes of the PE with the new 1171 information carried in the message. 1173 3.6.2. Announcing Removal of PE 1175 When an existing PE is granted de-registration or is removed from its 1176 handlespace for some other reasons (e.g., purging an unreachable PE, 1177 see Section 3.7), the ENRP server MUST uses this procedure to inform 1178 all its peers about the change just made. 1180 This is an ENRP announcement and is sent to all the peer of the home 1181 ENRP server. See Section 3.1 on how announcements are sent. 1183 An ENRP server MUST announce the PE removal to all its peers in an 1184 ENRP_HANDLE_UPDATE message with the Update Action field set to 1185 DEL_PE, indicating the removal of an existing PE. The complete 1186 information of the PE and the pool its belongs to MUST be indicated 1187 in the message with a PE parameter and a Pool Handle parameter, 1188 respectively. 1190 The sending server MUST fill in its server ID in the Sending Server's 1191 ID field and leave the Receiving Server's ID blank (i.e., set to all 1192 0's). 1194 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first 1195 find pool and the PE in its own handlespace, and then remove the PE 1196 from its local handlespace. If the removed PE is the last one in the 1197 pool, the peer MUST also delete the pool from its local handlespace. 1199 If the peer fails to find the PE or the pool in its handlespace, it 1200 SHOULD take no further actions. 1202 3.7. Detecting and Removing Unreachable PE 1204 Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 1205 Notification, see section 10.2 of [9]), the PU SHOULD send an 1206 ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The 1207 message SHOULD contain the pool handle and the PE Id of the 1208 unreachable PE. 1210 Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server 1211 MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE 1212 message to the PE in question (the 'H' flag in the message SHOULD be 1213 set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails 1214 (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP 1215 server MUST consider the PE as truly unreachable and MUST remove the 1216 PE from its handlespace and take actions described in Section 3.6.2. 1218 If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully 1219 to the PE, the ENRP server MUST retain the PE in its handlespace. 1220 Moreover, the server SHOULD keep a counter to record how many 1221 ASAP_ENDPOINT_UNREACHABLE messages it has received reporting 1222 reachability problem relating to this PE. If the counter exceeds the 1223 protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove 1224 the PE from its handlespace and take actions described in 1225 Section 3.6.2. 1227 Optionally, an ENRP server may also periodically send point-to-point 1228 ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each 1229 of the PEs owned by the ENRP server in order to check their 1230 reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE 1231 fails, the ENRP server MUST consider the PE as unreachable and MUST 1232 remove the PE from its handlespace and take actions described in 1233 Section 3.6.2. Note, if an ENRP server owns a large number of PEs, 1234 the implementation should pay attention not to flood the network with 1235 bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the 1236 implementation MUST distribute the ASAP_ENDPOINT_KEEP_ALIVE message 1237 traffic over a time period. 1239 The complete definition and rules of sending 1240 ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE 1241 messages are described in [1]. 1243 3.8. Helping PE and PU to Discover Home ENRP Server 1245 At its startup time, or whenever its current home ENRP server is not 1246 providing services, a PE or PU will attempt to find a new home 1247 server. For this reason, the PE or PU will need to maintain a list 1248 of currently available ENRP servers in its scope. 1250 To help the PE or PU maintaining this list, an ENRP server, if it is 1251 enabled for multicast, SHOULD periodically send out an 1252 ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to 1253 the well-known ASAP multicast channel. And in the 1254 ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the 1255 transport addresses available for ASAP communications. If the ENRP 1256 server only supports SCTP for ASAP communications, the transport 1257 information MAY be omitted in the ASAP_SERVER_ANNOUNCE message. 1259 For the complete procedure of this, see Section 3.6?? in [1]. 1261 3.9. Maintaining Peer List and Monitoring Peer Status 1263 An ENRP server MUST keep an internal record on the status of each of 1264 its known peers. This record is referred to as the server's "peer 1265 list" 1267 3.9.1. Discovering New Peer 1269 If a message of any type is received from a previously unknown peer, 1270 the ENRP server MUST consider this peer a new peer in the operational 1271 scope and add it to the peer list. 1273 The ENRP server MUST send an ENRP_PRESENCE message with the Reply- 1274 required flag set to '1' to the source address found in the arrived 1275 message. This will force the new peer to reply with its own 1276 ENRP_PRESENCE containing its full server information (see 1277 Section 2.1). 1279 3.9.2. Server Sending Heartbeat 1281 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 1282 continued presence to all its peer with a ENRP_PRESENCE message. In 1283 the ENRP_PRESENCE message, the ENRP server MUST set the 1284 'Replay_required' flag to '0', indicating that no response is 1285 required. 1287 The arrival of this periodic ENRP_PRESENCE message will cause all its 1288 peers to update their internal variable "peer.last.heard" for the 1289 sending server (see Section 3.9.3 for more details). 1291 3.9.3. Detecting Peer Server Failure 1293 An ENRP server MUST keep an internal variable "peer.last.heard" for 1294 each of its known peers and the value of this variable MUST be 1295 updated to the current local time every time a message of any type 1296 (point-to-point or announcement) is received from the corresponding 1297 peer. 1299 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 1300 seconds, the ENRP server MUST immediately send a point-to-point 1301 ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1303 If the send fails or the peer does not reply after MAX-TIME-NO- 1304 RESPONSE seconds, the ENRP server MUST consider the peer server dead 1305 and SHOULD initiate the takeover procedure defined in Section 3.10. 1307 3.10. Taking-over a Failed Peer Server 1309 In the following descriptions, we call the ENRP server that detects 1310 the failed peer server and initiates the take-over the "initiating 1311 server" and the failed peer server the "target server." This allows 1312 PE to continue to operate in case of a failure of their Home ENRP 1313 server. 1315 3.10.1. Initiating Server Take-over Arbitration 1317 The initiating server SHOULD first start the take-over arbitration 1318 process by sending a ENRP_INIT_TAKEOVER message to all its peer 1319 servers. See Section 3.1 on how announcements are sent. In the 1320 message, the initiating server MUST fill in the Sending Server's ID 1321 and Targeting Server's ID. The goal is that only one ENRP server 1322 takes over the PE from the target. 1324 After announcing the ENRP_INIT_TAKEOVER message, the initiating 1325 server SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of 1326 its known peers, except of the target server. 1328 Each peer receiving a ENRP_INIT_TAKEOVER message from the initiating 1329 server SHOULD take the following actions: 1331 1. If the peer server determines that itself is the target server 1332 indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately 1333 announce an ENRP_PRESENCE message to all its peer ENRP servers in 1334 an attempt to stop this take-over process. This indicates a 1335 false failure detection case by the initiating server. The 1336 initiating server MUST stop the takeover operation. 1338 2. If the peer server finds that it has already started its own 1339 take-over arbitration process on the same target server, it MUST 1340 perform the following arbitration: 1342 A. If the peer's server ID is smaller in value than the Sending 1343 Server's ID in the arrived ENRP_INIT_TAKEOVER message, the 1344 peer server SHOULD immediately abort its own take-over 1345 attempt. Moreover, the peer SHOULD mark the target server as 1346 "not active" on its internal peer list so that its status 1347 will no longer be monitored by the peer, and reply the 1348 initiating server with an ENRP_INIT_TAKEOVER_ACK message. 1350 B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER 1351 message and take no action. 1353 3. If the peer finds that it is neither the target server nor is in 1354 its own take-over process, the peer SHOULD: a) mark the target 1355 server as "not active" on its internal peer list so that its 1356 status will no longer be monitored by this peer, and b) reply to 1357 the initiating server with an ENRP_INIT_TAKEOVER_ACK message. 1359 Once the initiating server has received ENRP_INIT_TAKEOVER_ACK 1360 message from _all_ of its currently known peers (except for the 1361 target server), it SHOULD consider that it has won the arbitration 1362 and SHOULD proceed to complete the take-over, following the steps 1363 described in Section 3.10.2. 1365 However, if it receives an ENRP_PRESENCE from the target server at 1366 any point in the arbitration process, the initiating server MUST 1367 immediately abort the take-over process and mark the status of the 1368 target server as "active". 1370 3.10.2. Take-over Target Peer Server 1372 The initiating ENRP server SHOULD first send, via an announcement, a 1373 ENRP_TAKEOVER_SERVER message to inform all its active peers that the 1374 take-over is enforced. The target server's ID MUST be filled in the 1375 message. The initiating server SHOULD then remove the target server 1376 from its internal peer list. 1378 Then it SHOULD examine its local copy of the handlespace and claim 1379 ownership of each of the PEs originally owned by the target server, 1380 by following these steps: 1382 1. mark itself as the home ENRP server of each of the PEs originally 1383 owned by the target server; 1385 2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message, with the 1386 'H' flag set to '1', to each of the PEs. This will trigger the 1387 PE to adopt the initiating sever as its new home ENRP server; 1389 When a peer receives the ENRP_TAKEOVER_SERVER message from the 1390 initiating server, it SHOULD update its local peer list and PE cache 1391 by following these steps: 1393 1. remove the target server from its internal peer list; 1395 2. update the home ENRP server of each PE in its local copy of the 1396 handlespace to be the sender of the message, i.e., the initiating 1397 server. 1399 3.11. Handlespace Data Auditing and Re-synchronization 1401 Message losses or certain temporary breaks in network connectivity 1402 may result in data inconsistency in the local handlespace copy of 1403 some of the ENRP servers in an operational scope. Therefore, each 1404 ENRP server in the operational scope SHOULD periodically verify that 1405 its local copy of handlespace data is still in sync with that of its 1406 peers. 1408 This section defines the auditing and re-synchronization procedures 1409 for an ENRP server to maintain its handlespace data consistency. 1411 3.11.1. Auditing Procedures 1413 A checksum covering the data which should be the same is exchanged to 1414 figure out if the data is the same or not. 1416 The auditing of handlespace consistency is based on the following 1417 procedures: 1419 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1420 integer internal variable) for each of its known peers and for 1421 itself. For an ENRP server with 'k' known peers, we denote these 1422 internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ..., 1423 "pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE 1424 checksum. The list of what these checksums cover and a detailed 1425 algorithm for calculating them is given in Section 3.11.2. 1427 2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST 1428 include in the message its current PE checksum (i.e., 1429 "pe.checksum.pr0"). 1431 3. When an ENRP server (server A) receives a PE checksum (carried in 1432 an arrived ENRP_PRESENCE) from a peer ENRP server (server B), 1433 server A SHOULD compare the PE checksum found in the 1434 ENRP_PRESENCE with its own internal PE checksum of server B 1435 (i.e., "pe.checksum.prB"). 1437 4. If the two values match, server A will consider that there is no 1438 handlespace inconsistency between itself and server B and should 1439 take no further actions. 1441 5. If the two values do NOT match, server A SHOULD consider that 1442 there is a handlespace inconsistency between itself and server B 1443 and a re-synchronization process SHOULD be carried out 1444 immediately with server B (see Section 3.11.3). 1446 3.11.2. PE Checksum Calculation Algorithm 1448 When an ENRP server (server A) calculate an internal PE checksum for 1449 a peer (server B), it MUST use the following algorithm. 1451 Let us assume that in server A's internal handlespace there are 1452 currently 'M' PEs that are owned by server B. Each of the 'M' PEs 1453 will then contribute to the checksum calculation with the following 1454 byte block: 1456 0 1 2 3 1457 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 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 : Pool handle string of the pool the PE belongs (padded with : 1460 : zeros to next 32-bit word boundary if needed) : 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | PE Id (4 octets) | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 Note, these are not TLVs. This byte block gives each PE a unique 1466 byte pattern in the scope. The 16-bit PE checksum for server B 1467 "pe.checksum.prB" is then calculated over the byte blocks contributed 1468 by the 'M' PEs one by one. The PE checksum calculation MUST use the 1469 Internet algorithm described in [4]. 1471 Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") 1472 in the same fashion, using the byte blocks of all the PEs owned by 1473 itself. 1475 Note, whenever an ENRP finds that its internal handlespace has 1476 changed (e.g., due to PE registration/deregistration, receiving peer 1477 updates, removing failed PEs, downloading handlespace pieces from a 1478 peer, etc.), it MUST immediately update all its internal PE checksums 1479 that are affected by the change. 1481 Implementation Note: when the internal handlespace changes (e.g., a 1482 new PE added or an existing PE removed), an implementation needs not 1483 to re-calculate the affected PE checksum; it can instead simply 1484 update the checksum by adding or subtracting the byte block of the 1485 corresponding PE from the previous checksum value. 1487 3.11.3. Re-synchronization Procedures 1489 If an ENRP server determines that there is inconsistency between its 1490 local handlespace data and a peer's handlespace data with regarding 1491 to the PEs owned by that peer, it MUST perform the following steps to 1492 re-synchronize the data: 1494 1. The ENRP server SHOULD first "mark" every PE it knows about that 1495 is owned by the peer in its local handlespace database; 1497 2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST 1498 message with W flag set to '1' to the peer to request a complete 1499 list of PEs owned by the peer; 1501 3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with W 1502 flag set to '1', the peer server SHOULD immediately respond with 1503 an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently 1504 owned by the peer. 1506 4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the 1507 ENRP server SHOULD transfer the PE entries carried in the message 1508 into its local handlespace database. If an PE entry being 1509 transferred already exists in its local database, the ENRP server 1510 MUST replace the entry with the copy found in the message and 1511 remove the "mark" from the entry. 1513 5. After transferring all the PE entries from the received 1514 ENRP_HANDLE_TABLE_RESPONSE message into its local database, the 1515 ENRP server SHOULD check whether there are still PE entries that 1516 remain "marked" in its local handlespace. If so, the ENRP server 1517 SHOULD silently remove those "marked" entries. 1519 Note, similar to what is described in Section 3.2.3, the peer may 1520 reject the ENRP_HANDLE_TABLE_REQUEST or use more than one 1521 ENRP_HANDLE_TABLE_RESPONSE message to respond. 1523 3.12. Handling Unrecognized Message or Unrecognized Parameter 1525 When an ENRP server receives an ENRP message with an unknown message 1526 type or a message of known type that contains an unknown parameter, 1527 it SHOULD handle the unknown message or the unknown parameter 1528 according to the unrecognized message and parameter handling rules 1529 defined in Sections 3 and 4 in [12]. 1531 According to the rules, if an error report to the message sender is 1532 needed, the ENRP server that discovered the error SHOULD send back an 1533 ENRP_ERROR message with proper error cause code. 1535 4. Variables and Thresholds 1537 4.1. Variables 1539 peer.last.heard - the local time that a peer server was last heard 1540 (via receiving either a multicast or point-to-point message from 1541 the peer). 1543 pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server 1544 keeps for a peer. A separate PE checksum is kept for each of its 1545 known peers as well as for itself. 1547 4.2. Thresholds 1549 MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender 1550 will make to contact an ENRP server (Default=3 times). 1552 TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will 1553 wait for a response from an ENRP server (Default=5 seconds). 1555 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1556 heartbeat message to all its known peers. (Default=30 secs.) 1558 SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a 1559 SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) 1561 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1562 will wait before considering a silent peer server potentially 1563 dead. (Default=61 secs.) 1565 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1566 sender will wait for a response after sending out a message. 1567 (Default=5 secs.) 1569 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on 1570 a PE that an ENRP server will allow before purging this PE from 1571 the handlespace. (Default=3) 1573 5. IANA Considerations 1575 [NOTE to RFC-Editor: 1577 "RFCXXXX" is to be replaced by the RFC number you assign this 1578 document. 1580 ] 1582 This document (RFCXXX) is the reference for all registrations 1583 described in this section. All registrations need to be listed on an 1584 RSerPool specific page. 1586 5.1. A New Table for ENRP Message Types 1588 ENRP Message Types have to be maintained by IANA. Ten initial values 1589 should be assigned by IANA as described in Figure 1. This requires a 1590 new table "ENRP Message Types": 1592 Type Message Name Reference 1593 ----- ------------------------- --------- 1594 0x00 (reserved by IETF) RFCXXXX 1595 0x01 ENRP_PRESENCE RFCXXXX 1596 0x02 ENRP_HANDLE_TABLE_REQUEST RFCXXXX 1597 0x03 ENRP_HANDLE_TABLE_RESPONSE RFCXXXX 1598 0x04 ENRP_HANDLE_UPDATE RFCXXXX 1599 0x05 ENRP_LIST_REQUEST RFCXXXX 1600 0x06 ENRP_LIST_RESPONSE RFCXXXX 1601 0x07 ENRP_INIT_TAKEOVER RFCXXXX 1602 0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX 1603 0x09 ENRP_TAKEOVER_SERVER RFCXXXX 1604 0x0a ENRP_ERROR RFCXXXX 1605 0x0b-0xff (reserved by IETF) RFCXXXX 1607 For registering at IANA an ENRP Message Type in this table a request 1608 has to be made to assign such a number. This number must be unique. 1609 The "Specification Required" policy of RFC2434 [8] MUST be applied. 1611 5.2. A New Table for Update Action Types 1613 Update Types have to be maintained by IANA. Two initial values 1614 should be assigned by IANA. This requires a new table "Update Action 1615 Types": 1617 Type Update Action Reference 1618 ------------- -------------------- --------- 1619 0x0000 ADD_PE RFCXXXX 1620 0x0001 DEL_PE RFCXXXX 1621 0x0002-0xffff (reserved by IETF) RFCXXXX 1623 For registering at IANA an Update Action Type in this table a request 1624 has to be made to assign such a number. This number must be unique. 1625 The "Specification Required" policy of RFC2434 [8] MUST be applied. 1627 5.3. Multicast Addresses 1629 IANA should assign one multicast address for the ENRP server channel 1630 and another one for the ENRP client channel. 1632 6. Security Considerations 1634 We present a summary of the threats to the RSerPool architecture and 1635 describe security requirements in response to mitigate the 1636 threats.ENext we present the security mechanisms, based on TLS, that 1637 are implementation requirements in response to the threats.E Finally, 1638 we present a chain of trust argument that examines critical data 1639 paths in RSerPool and shows how these paths are protected by the TLS 1640 implementation. 1642 6.1. Summary of Rserpool Security Threats 1644 Threats Introduced by RSerPool and Requirements for Security in 1645 Response to Threats [13] describes the threats to the RSerPool 1646 architecture in detail lists the security requirements in response to 1647 each threat.E From the threats described in this document, the 1648 security services required for the RSerPool protocol are enumerated 1649 below. 1651 Threat 1) PE registration/deregistration flooding or spoofing 1652 ----------- 1653 Security mechanism in response: ENRP server authenticates the PE 1655 Threat 2) PE registers with a malicious ENRP server 1656 ----------- 1657 Security mechanism in response: PE authenticates the ENRP server 1659 Threat 1 and 2 taken together results in mutual authentication of the 1660 ENRP server and the PE. 1662 Threat 3) Malicious ENRP server joins the ENRP server pool 1663 ----------- 1664 Security mechanism in response: ENRP servers mutually authenticate 1666 Threat 4) A PU communicates with a malicious ENRP server for handle 1667 resolution 1668 ----------- 1669 Security mechanism in response: The PU authenticates the ENRP server 1671 Threat 5) Replay attack 1672 ----------- 1673 Security mechanism in response: Security protocol which has 1674 protection from replay attacks 1676 Threat 6) Corrupted data which causes a PU to have misinformation 1677 concerning a pool handle resolution 1678 ----------- 1679 Security mechanism in response: Security protocol which supports 1680 integrity protection 1682 Threat 7) Eavesdropper snooping on handlespace information 1683 ----------- 1684 Security mechanism in response: Security protocol which supports data 1685 confidentiality 1687 Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to 1688 ENRP server 1689 ----------- 1690 Security mechanism in response: ASAP must control the number of ASAP 1691 endpoint unreachable messages transmitted from the PU to the ENRP 1692 server. 1694 Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from 1695 the ENRP server 1696 ----------- 1697 Security mechanism in response: ENRP server must control the number 1698 of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE 1700 To summarize the threats 1-7 require security mechanisms which 1701 support authentication, integrity, data confidentiality, protection 1702 from replay attacks. 1704 For RSerPool we need to authenticate the following: 1706 PU <---- ENRP Server (PU authenticates the ENRP server) 1707 PE <----> ENRP Server (mutual authentication) 1708 ENRP server <-----> ENRP Server (mutual authentication) 1710 6.2. Implementing Security Mechanisms 1712 We do not define any new security mechanisms specifically for EE 1713 responding to threats 1-7.E Rather we use an existing IETF security 1714 EE protocol, specifically [2], to provide the security services 1715 required.ETLS supports all these requirements and MUST be 1716 implemented.EThe TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be 1717 supported at a minimum by implementors of TLS for RSerPool.E For 1718 purposes of backwards compatibility, ENRP SHOULD support EE 1719 TLS_RSA_WITH_3DES_EDE_CBC_SHA.EImplementers MAY also support any EE 1720 other IETF approved ciphersuites. 1722 ENRP servers, PEs, PUs MUST implement TLS.E ENRP servers and PEs must 1723 support mutual authentication.E ENRP servers must support mutual 1724 authentication among themselves.E PUs MUST authenticate ENRP servers. 1726 ENRP servers and PEs SHOULD possess a site certificate whose subject 1727 corresponds to their canonical hostname.E PUs MAY have certificates 1728 of their own for mutual authentication with TLS, but no provisions 1729 are set forth in this document for their use.E All RSerPool elements 1730 that support TLS MUST have a mechanism for validating certificates 1731 received during TLS negotiation; this entails possession of one or 1732 more root certificates issued by certificate authorities (preferably 1733 well-known distributors of site certificates comparable to those that 1734 issue root certificates for web browsers). 1736 Implementations MUST support TLS with SCTP as described in [10] or 1737 TLS over TCP as described in [7].EWhen using TLS/SCTP we must ensure 1738 that RSerPool does not use any features of SCTP that are not 1739 available to an TLS/SCTP user.E This is not a difficult technical 1740 problem, but simply a requirement.E When describing an API of the 1741 RSerPool lower layer we have also to take into account the 1742 differences between TLS and SCTP. 1744 Threat 8 requires the ASAP protocol to limit the number of 1745 ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [1]) to the 1746 ENRP server. 1748 Threat 9 requires the ENRP protocol to limit the number of 1749 ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see 1750 section Section 3.7). 1752 6.3. Chain of trust 1754 Security is mandatory to implement in RSerPool and is based on TLS 1755 implementation in all three architecture components that comprise 1756 RSerPool -- namely PU, PE and ENRP server. We define an ENRP server 1757 that uses TLS for all communication and authenticates ENRP peers and 1758 PE registrants to be a secured ENRP server. 1760 Here is a description of all possible data paths and a description of 1761 the security. 1763 PU <---> secured ENRP Server (authentication of ENRP server; 1764 queries over TLS) 1765 PE <---> secured ENRP server (mutual authentication; 1766 registration/deregistration over TLS) 1767 secured ENRP server <---> secured ENRP server (mutual authentication; 1768 database updates using TLS) 1770 If all components of the system authenticate and communicate using 1771 TLS, the chain of trust is sound. The root of the trust chain is the 1772 ENRP server. If that is secured using TLS, then security will be 1773 enforced for all ENRP and PE components that try to connect to it. 1775 Summary of interaction between secured and unsecured components: If 1776 the PE does not use TLS and tries to register with a secure ENRP 1777 server, it will receive an error message response indicated as error 1778 due to security considerations and the registration will be rejected. 1779 If an ENRP server which does not use TLS tries to update the database 1780 of a secure ENRP server, then the update will be rejected. If an PU 1781 does not use TLS and communicates with a secure ENRP server, it will 1782 get a response with the understanding that the response is not secure 1783 as the response can be tampered with in transit even if the ENRP 1784 database is secured. 1786 The final case is the PU sending a secure request to ENRP. It might 1787 be that ENRP and PEs are not secured and this is an allowable 1788 configuration. The intent is to secure the communication over the 1789 Internet between the PU and the ENRP server. 1791 Summary: 1793 RSerPool architecture components can communicate with each other to 1794 establish a chain of trust. Secured PE and ENRP servers reject any 1795 communications with unsecured ENRP or PE servers. 1797 If the above is enforced, then a chain of trust is established for 1798 the RSerPool user. 1800 7. Acknowledgements 1802 The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, 1803 Thomas Dreibholz, and many others for their invaluable comments and 1804 feedback. 1806 8. References 1808 8.1. Normative References 1810 [1] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 1811 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-12 1812 (work in progress), July 2005. 1814 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1815 J., and M. Stillman, "Requirements for Reliable Server 1816 Pooling", RFC 3237, January 2002. 1818 [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and 1819 A. Silverton, "Architecture for Reliable Server Pooling", 1820 draft-ietf-rserpool-arch-10 (work in progress), July 2005. 1822 [4] Braden, R., Borman, D., and C. Partridge, "Computing the 1823 Internet Checksum", RFC 1071, September 1988. 1825 [5] Bradner, S., "The Internet Standards Process -- Revision 3", 1826 BCP 9, RFC 2026, October 1996. 1828 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1829 Levels", BCP 14, RFC 2119, March 1997. 1831 [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1832 RFC 2246, January 1999. 1834 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1835 Considerations Section in RFCs", BCP 26, RFC 2434, 1836 October 1998. 1838 [9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1839 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 1840 Paxson, "Stream Control Transmission Protocol", RFC 2960, 1841 October 2000. 1843 [10] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP", 1844 RFC 3436, December 2002. 1846 [11] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On 1847 the Use of Stream Control Transmission Protocol (SCTP) with 1848 IPsec", RFC 3554, July 2003. 1850 [12] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 1851 Server Access Protocol (ASAP) and Endpoint Handlespace 1852 Redundancy Protocol (ENRP) Parameters", 1853 draft-ietf-rserpool-common-param-09 (work in progress), 1854 July 2005. 1856 [13] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M. 1857 Holdrege, "Threats Introduced by Rserpool and Requirements for 1858 Security in Response to Threats", 1859 draft-ietf-rserpool-threats-05 (work in progress), July 2005. 1861 [14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1862 Protocol Version 1.1", RFC 4346, April 2006. 1864 8.2. Informative References 1866 [15] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1867 Recommendations for Security", RFC 1750, December 1994. 1869 Authors' Addresses 1871 Qiaobing Xie 1872 Motorola, Inc. 1873 1501 W. Shure Drive, 2-F9 1874 Arlington Heights, IL 60004 1875 US 1877 Phone: 1878 Email: qxie1@email.mot.com 1880 Randall R. Stewart 1881 Cisco Systems, Inc. 1882 4875 Forest Drive 1883 Suite 200 1884 Columbia, SC 29206 1885 USA 1887 Phone: 1888 Email: rrs@cisco.com 1890 Maureen Stillman 1891 Nokia 1892 127 W. State Street 1893 Ithaca, NY 14850 1894 US 1896 Phone: 1897 Email: maureen.stillman@nokia.com 1899 Michael Tuexen 1900 Muenster Univ. of Applied Sciences 1901 Stegerwaldstr. 39 1902 48565 Steinfurt 1903 Germany 1905 Email: tuexen@fh-muenster.de 1906 Aron J. Silverton 1907 Motorola, Inc. 1908 1301 E. Algonquin Road 1909 Room 2246 1910 Schaumburg, IL 60196 1911 USA 1913 Phone: +1 847-576-8747 1914 Email: aron.j.silverton@motorola.com 1916 Full Copyright Statement 1918 Copyright (C) The IETF Trust (2007). 1920 This document is subject to the rights, licenses and restrictions 1921 contained in BCP 78, and except as set forth therein, the authors 1922 retain all their rights. 1924 This document and the information contained herein are provided on an 1925 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1926 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1927 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1928 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1929 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1930 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1932 Intellectual Property 1934 The IETF takes no position regarding the validity or scope of any 1935 Intellectual Property Rights or other rights that might be claimed to 1936 pertain to the implementation or use of the technology described in 1937 this document or the extent to which any license under such rights 1938 might or might not be available; nor does it represent that it has 1939 made any independent effort to identify any such rights. Information 1940 on the procedures with respect to rights in RFC documents can be 1941 found in BCP 78 and BCP 79. 1943 Copies of IPR disclosures made to the IETF Secretariat and any 1944 assurances of licenses to be made available, or the result of an 1945 attempt made to obtain a general license or permission for the use of 1946 such proprietary rights by implementers or users of this 1947 specification can be obtained from the IETF on-line IPR repository at 1948 http://www.ietf.org/ipr. 1950 The IETF invites any interested party to bring to its attention any 1951 copyrights, patents or patent applications, or other proprietary 1952 rights that may cover technology that may be required to implement 1953 this standard. Please address the information to the IETF at 1954 ietf-ipr@ietf.org. 1956 Acknowledgment 1958 Funding for the RFC Editor function is provided by the IETF 1959 Administrative Support Activity (IASA).