idnits 2.17.1 draft-ietf-rserpool-enrp-17.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 1921. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1945. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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 (September 22, 2007) is 6060 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2960 (ref. '4') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 4346 (ref. '7') (Obsoleted by RFC 5246) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-12 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-16 == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-08 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 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: March 25, 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 September 22, 2007 14 Endpoint Handlespace Redundancy Protocol (ENRP) 15 draft-ietf-rserpool-enrp-17.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 March 25, 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 . . . . . . . . . . . . . . . . . . 44 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 116 Intellectual Property and Copyright Statements . . . . . . . . . . 47 118 1. Introduction 120 ENRP is designed to work in conjunction with ASAP [9] to accomplish 121 the functionality of RSerPool as defined by its requirements [5]. 123 Within the operational scope of RSerPool, ENRP defines the procedures 124 and message formats of a distributed fault-tolerant registry service 125 for storing, bookkeeping, retrieving, and distributing pool operation 126 and membership information. 128 Whenever appropriate, in the rest of this document we will refer to 129 this RSerPool registry service as ENRP handlespace, or simply 130 handlespace because it manages all pool handles. 132 1.1. Definitions 134 This document uses the following terms: 136 Operational scope: The part of the network visible to pool users by 137 a specific instance of the reliable server pooling protocols. 139 Pool (or server pool): A collection of servers providing the same 140 application functionality. 142 Pool handle: A logical pointer to a pool. Each server pool will be 143 identifiable in the operational scope of the system by a unique 144 pool handle. 146 Pool element: A server entity having registered to a pool. 148 Pool user: A server pool user. 150 Pool element handle (or endpoint handle): A logical pointer to a 151 particular pool element in a pool, consisting of the pool handle 152 and a destination transport address of the pool element. 154 Handle space: A cohesive structure of pool handles and relations 155 that may be queried by an internal or external agent. 157 ENRP client channel: The communication channel through which an ASAP 158 User (either a PE or PU) requests ENRP handlespace service. The 159 client channel is usually defined by the transport address of the 160 home server and a well-known port number. The channel MAY make 161 use of multi-cast or a named list of ENRP servers. 163 ENRP server channel: Defined by a well-known multicast IP address 164 and a well known port number. All ENRP servers in an operational 165 scope can send multicast messages to other servers through this 166 channel. PEs are also allowed to multicast on this channel 167 occasionally; 169 Home ENRP server: The ENRP server to which a PE or PU currently 170 belongs. A PE MUST only have one home ENRP server at any given 171 time and both the PE and its home ENRP server MUST keep track of 172 this master/slave relationship between them. A PU SHOULD select 173 one of the available ENRP servers as its home ENRP server, but the 174 ENRP server does not need to know, nor does it need to keep track 175 of this relationship. 177 1.2. Conventions 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC2119 [2]. 183 2. ENRP Message Definitions 185 In this section, we define the format of all ENRP messages. These 186 are messages sent and received amongst ENRP servers in an operational 187 scope. Messages sent and received between a PE/PU and an ENRP server 188 are part of ASAP and are defined in [9]. A common format, that is 189 defined in [8], is used for all ENRP and ASAP messages. 191 Most ENRP messages contains a combination of fixed fields and TLV 192 parameters. The TLV (Type-Length_value) parameters are also defined 193 in [8]. 195 All messages, as well as their fields/parameters described below, 196 MUST be transmitted in network byte order (a.k.a. Big Endian, 197 meaning the most significant byte is transmitted first). 199 For ENRP, the following message types are defined in this section: 201 Type Message Name 202 ----- ------------------------- 203 0x00 - (reserved by IETF) 204 0x01 - ENRP_PRESENCE 205 0x02 - ENRP_HANDLE_TABLE_REQUEST 206 0x03 - ENRP_HANDLE_TABLE_RESPONSE 207 0x04 - ENRP_HANDLE_UPDATE 208 0x05 - ENRP_LIST_REQUEST 209 0x06 - ENRP_LIST_RESPONSE 210 0x07 - ENRP_INIT_TAKEOVER 211 0x08 - ENRP_INIT_TAKEOVER_ACK 212 0x09 - ENRP_TAKEOVER_SERVER 213 0x0a - ENRP_ERROR 214 0x0b-0xff - (reserved by IETF) 216 Figure 1 218 Except for the ENRP_PRESENCE message, the usage of the ENRP server 219 channel is for further study. The usage of point-to-point 220 communications is assumed in this specification. 222 2.1. ENRP_PRESENCE message 224 This ENRP message is used to announce (periodically) the presence of 225 an ENRP server, or to probe the status of a peer ENRP server. This 226 message is either send on the ENRP server channel or point-to-point 227 to another ENRP server. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type = 0x01 |0|0|0|0|0|0|0|0| Message Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Sending Server's ID | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Receiving Server's ID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 : PE Checksum Param : 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 : Server Information Param (optional) : 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 R (reply_required) flag: 1 bit 245 Set to '1' if the sender requires a response to this message, 246 otherwise set to '0'. If sent to the ENRP server channel this 247 field MUST be set to '0'. 249 Sending Server's ID: 32 bit (unsigned integer) 251 This is the ID of the ENRP server which sent this message. 253 Receiving Server's ID: 32 bit (unsigned integer) 255 This is the ID of the ENRP server to which this message is 256 intended. If the message is not intended for an individual 257 server (e.g., the message is multicasted to a group of 258 servers), this field MUST be sent with all 0's. If the message 259 is send point-to-point this field MAY be sent with all 0's. 261 PE Checksum Parameter: 263 This is a TLV that contains the latest PE checksum of the ENRP 264 server who sends the ENRP_PRESENCE. This parameter SHOULD be 265 included for handlespace consistency auditing. See 266 Section 3.11.1 for details. 268 Server Information Parameter: 270 If this parameter is present, it contains the server 271 information of the sender of this message (Server Information 272 Parameter is defined in [8]). This parameter is optional. 273 However, if this message is sent in response to a received 274 "reply required" ENRP_PRESENCE from a peer, the sender then 275 MUST include its server information. 277 Note, at startup an ENRP server MUST pick a randomly generated, non- 278 zero 32-bit unsigned integer as its ID and MUST use this same ID 279 until the ENRP server is rebooted. 281 2.2. ENRP_HANDLE_TABLE_REQUEST message 283 An ENRP server sends this message to one of its peers to request a 284 copy of the handlespace data. This message is normally used during 285 server initialization or handlespace re-synchronization. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Sending Server's ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Receiving Server's ID | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 W (oWn-children-only) flag: 1 bit 299 Set to '1' if the sender of this message is only requesting 300 information about the PEs owned by the message receiver. 301 Otherwise, set to '0'. 303 Sending Server's ID: 305 See Section 2.1. 307 Receiving Server's ID: 309 See Section 2.1. 311 2.3. ENRP_HANDLE_TABLE_RESPONSE message 313 The PEER_NAME_TABLE_RESPONSE message is sent by an ENRP server in 314 response to a received PEER_NAME_TABLE_REQUEST message to assist peer 315 server initialization or handle-space synchronization. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type = 0x03 |0|0|0|0|0|0|M|R| Message Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Sending Server's ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Receiving Server's ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 : : 327 : Pool entry #1 (optional) : 328 : : 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 : : 331 : ... : 332 : : 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 : : 335 : Pool entry #n (optional) : 336 : : 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 M (More_to_send) flag: 1 bit 341 Set to '1' if the sender of this message has more pool entries 342 to send in subsequent ENRP_HANDLE_TABLE_RESPONSE messages. 343 Otherwise, set to '0'. 345 R (Reject) flag: 1 bit 347 MUST be set to '1' if the sender of this message is rejecting a 348 handlespace request. In this case, pool entries MUST not be 349 included. This might happen if the sender of this message is 350 in the middle of initializing its database or it is under high 351 load. 353 Message Length: 16 bits (unsigned integer) 355 Indicates the entire length of the message including the header 356 in number of octets. 358 Note, the value in Message Length field will NOT cover any 359 padding at the end of this message. 361 Sending Server's ID: 363 See Section 2.1. 365 Receiving Server's ID: 367 See Section 2.1. 369 Pool entry #1-#n: 371 If the R flag is set to '0', at least one pool entry SHOULD be 372 present in this message. Each pool entry MUST start with a 373 Pool Handle parameter as defined in section 3.1.7, and is 374 followed by one or more Pool Element parameters in TLV format, 375 as shown below: 377 +---------------------------+ 378 : Pool handle : 379 +---------------------------+ 380 : PE #1 : 381 +---------------------------+ 382 : PE #2 : 383 +---------------------------+ 384 : ... : 385 +---------------------------+ 386 : PE #n : 387 +---------------------------+ 389 2.4. ENRP_HANDLE_UPDATE message 391 The PEER_NAME_UPDATE message is sent by the home ENRP server of a PE 392 to all peer servers to announce registration, reregistration, or 393 deregistration of the PE in the handle-space. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Sending Server's ID | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Receiving Server's ID | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Update Action | (reserved) | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 : Pool Handle Parameter : 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 : Pool Element Parameter : 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Message Length: 16 bits (unsigned integer) 413 Indicates the entire length of the message including the header 414 in number of octets. 416 Note, the value in Message Length field will NOT cover any 417 padding at the end of this message. 419 Update Action: 16 bits (unsigned integer) 421 This field indicates the requested action of the specified PE. 422 The field MUST be set to one of the following values: 424 0x0000 - ADD_PE: Add or update the specified PE in the ENRP 425 handlespace 427 0x0001 - DEL_PE: Delete the specified PE from the ENRP 428 handlespace. 430 0x0002 - 0xFFFF: Reserved by IETF. 432 Other values are reserved by IETF and MUST not be used. 434 Reserved: 16 bits 436 This field MUST be set to all 0's by sender and ignored by the 437 receiver. 439 Sending Server's ID: 441 See Section 2.1. 443 Receiving Server's ID: 445 See Section 2.1. 447 Pool handle: 449 Specifies to which the PE belongs. 451 Pool Element: 453 Specifies the PE. 455 2.5. ENRP_LIST_REQUEST message 457 The PEER_LIST_REQUEST message is sent to request a current copy of 458 the ENRP server list. This message is normally sent from a newly 459 activated ENRP server to an established ENRP server as part of the 460 initialization process. 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Sending Server's ID | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Receiving Server's ID | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Sending Server's ID: 474 See Section 2.1. 476 Receiving Server's ID: 478 See Section 2.1. 480 2.6. ENRP_LIST_RESPONSE message 482 The PEER_LIST_RESPONSE message is sent in response from an ENRP 483 server that receives a PEER_LIST_REQUEST message to return 484 information about known ENRP servers. 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type = 0x06 |0|0|0|0|0|0|0|R| Message Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Sending Server's ID | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Receiving Server's ID | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 : Server Information Parameter of Peer #1 : 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 : ... : 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 : Server Information Parameter of Peer #n : 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 R (Reject) flag: 1 bit 504 This flag MUST be set to '1' if the sender of this message is 505 rejecting a PEER_LIST_REQUEST message. If this case occurs, 506 the message MUST NOT include any Server Information Parameters. 508 Message Length: 16 bits (unsigned integer) 510 Indicates the entire length of the message in number of octets. 512 Note, the value in Message Length field will NOT cover any 513 padding at the end of this message. 515 Sending Server's ID: 517 See Section 2.1. 519 Receiving Server's ID: 521 See Section 2.1. 523 Server Information Parameter of Peer #1-#n: 525 Each contains a Server Information Parameter of a peer known to 526 the sender. The Server Information Parameter is defined in 527 [8]. 529 2.7. ENRP_INIT_TAKEOVER message 531 The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the 532 takeover initiator) to announce its intention of taking over a 533 specific peer ENRP server. It is send to all its peers. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Sending Server's ID | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Receiving Server's ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Targeting Server's ID | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Sending Server's ID: 549 See Section 2.1. 551 Receiving Server's ID: 553 See Section 2.1. 555 Targeting Server's ID: 32-bit (unsigned integer) 557 This is the ID of the peer ENRP that is the target of this 558 takeover attempt. 560 2.8. ENRP_INIT_TAKEOVER_ACK message 562 The PEER_INIT_TAKEOVER_ACK message is sent in response to a takeover 563 initiator to acknowledge the reception of the PEER_INIT_TAKEROVER 564 message and that it does not object to the takeover. 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Sending Server's ID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Receiving Server's ID | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Targeting Server's ID | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Sending Server's ID: 580 See Section 2.1. 582 Receiving Server's ID: 584 See Section 2.1. 586 Targeting Server's ID: 588 This is the ID of the peer ENRP that is the target of this 589 takeover attempt. 591 2.9. ENRP_TAKEOVER_SERVER message 593 The PEER_TAKEOVER_REGISTRAR message is sent by the takeover initiator 594 to declare the enforcement of a takeover to all active peer ENRP 595 servers. 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Sending Server's ID | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Receiving Server's ID | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Targeting Server's ID | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Sending Server's ID: 610 See Section 2.1. 612 Receiving Server's ID: 614 See Section 2.1. 616 Targeting Server's ID: 618 This is the ID of the peer ENRP that is the target of this 619 takeover operation. 621 2.10. ENRP_ERROR message 623 The ENRP_ERROR message is sent by a registrar to report an 624 operational error to a peer ENRP server. 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Sending Server's ID | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Receiving Server's ID | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 : Operational Error Parameter : 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Sending Server's ID: 640 See Section 2.1. 642 Receiving Server's ID: 644 See Section 2.1. 646 Operational Error Parameter: 648 This parameter, defined in [8], indicates the type of error(s) 649 being reported. 651 3. ENRP Operation Procedures 653 In this section, we discuss the operation procedures defined by ENRP. 654 An ENRP server MUST follow these procedures when sending, receiving, 655 or processing ENRP messages. 657 Many of the RSerPool events call for both server-to-server and PU/ 658 PE-to-server message exchanges. Only the message exchanges and 659 activities between an ENRP server and its peer(s) are considered 660 within the ENRP scope and are defined in this document. 662 Procedures for exchanging messages between a PE/PU and ENRP servers 663 are defined in [9]. 665 3.1. Methods for Communicating amongst ENRP Servers 667 Within an RSerPool operational scope, ENRP servers need to 668 communicate with each other in order to exchange information such as 669 the pool membership changes, handlespace data synchronization, etc. 671 Two types of communications are used amongst ENRP servers: 673 o point-to-point message exchange from one ENPR server to a specific 674 peer server, and 676 o announcements from one server to all its peer servers in the 677 operational scope. 679 Point-to-point communication is always carried out over an SCTP 680 association between the sending server and the receiving server. 682 Announcements are communicated out with one of the following two 683 approaches: 685 1. The sending server sends the announcement message to the ENRP 686 server channel. This must also handle the relation between the 687 ENRP server channel and the operational scope. The usage of the 688 ENRP server channel is for further study. 690 2. The sending server sends multiple copies of the announcement, one 691 to each of its peer servers, over a set of point-to-point SCTP 692 associations between the sending server and the peers. 694 In order to maximize inter-operability of ENRP servers, the following 695 rules MUST be followed: 697 1. At the startup time, a new ENRP server SHOULD make a decision on 698 whether it will enable IP multicast for ENRP announcements. This 699 decision should be based on preconfigured information such as the 700 availability of IP multicast and the security requirements from 701 the user of RSerPool. 703 2. If an ENRP server disables multicast, it then: 705 A. MUST NOT subscribe to the well-known server multicast 706 channel, i.e., it only receives peer announcements over SCTP 707 associations, and 709 B. MUST transmit all its out-going announcements over point-to- 710 point SCTP associations with its peers. 712 3. If an ENRP server enables itself to use multicast, it then: 714 A. MUST subscribe to the well-known server multicast channel to 715 ready itself for receiving peers' multicast announcements, 717 B. MUST also be prepared to receive peer announcements over 718 point-to-point SCTP associations from peers. 720 C. MUST track internally which peers are multicast-enabled and 721 which are not. Note: A peer is always assumed to be 722 multicast-disabled until/unless an ENRP message of any type 723 is received from that peer over the well-known server 724 multicast channel. 726 D. when sending out an announcement, MUST send a copy to the 727 ENRP server channel AND a copy to each of the peers that are 728 marked as multicast-disabled over a point-to-point SCTP 729 association. 731 3.2. ENRP Server Initialization 733 This section describes the steps a new ENRP server needs to take in 734 order to join the other existing ENRP servers, or to initiate the 735 handlespace service if it is the first ENRP server started in the 736 operational scope. 738 3.2.1. Generate a Server Identifier 740 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 741 as unique as possible in the operational scope and this server Id 742 MUST remain unchanged for the lifetime of the server. Normally, a 743 good 32-bit random number will be good enough as the server Id 744 (RFC4086 [11] provides some information on randomness guidelines). 746 Note, there is a very remote chance (about 1 in about 4 billion) that 747 two ENRP servers in an operational scope will generate the same 748 server Id and hence cause a server Id conflict in the pool. However, 749 no severe consequence of such a conflict has been identified. 751 3.2.2. Acquire Peer Server List 753 At startup, the ENRP server (initiating server) will first attempt to 754 learn all existing peer ENRP servers in the same operational scope, 755 or to determine that it is alone in the scope. 757 The initiating server uses an existing peer server to bootstrap 758 itself into service. We call this peer server the mentor server. 760 3.2.2.1. Finding the mentor server 762 If the initiating server is told about an existing peer server 763 through some administrative means (such as DNS query, configuration 764 database, startup scripts, etc), the initiating server SHOULD then 765 use this peer server as its mentor server and SHOULD skip the 766 remaining steps in this subsection. 768 If multiple existing peer servers are specified, the initiating 769 server SHOULD pick one of them as its mentor server, keep the others 770 as its backup mentor servers, and skip the remaining steps in this 771 subsection. 773 If no existing peer server is specified to the initiating server AND 774 if multicast is available in the operational scope, the following 775 mentor server discovery procedures SHOULD be followed: 777 1. The initiating server SHOULD first join the ENRP server channel. 779 2. When the first ENRP_PRESENCE message arrives, the server SHOULD 780 take the sender of this received response as its mentor server. 781 This completes the discovery of the mentor server. 783 If ENRP_PRESENCE messages are also received from other peers (a 784 likely event when multiple peers exist in the operational scope 785 at the time the new server started), the initiating server SHOULD 786 keep a list of those responded as its backup mentor servers (see 787 below). 789 3. If no response to its ENRP_PRESENCE message are received after 790 TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat 791 steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After 792 that, if there is still no response, the initiating server MUST 793 assume that it is alone in the operational scope. 795 4. If the initiating server determined that it is alone in the 796 scope, it MUST skip the procedures in Section 3.2.2.2 and 797 Section 3.2.3 and MUST consider its initialization completed and 798 start offering ENRP services. 800 Note, if multicast is not available (or not allowed for reasons such 801 as security concerns) in the operational scope, at least one peer 802 server MUST be specified to the initiating server through 803 administrative means, unless the initiation server is the first 804 server to start in the operational scope. 806 Note, if the administratively specified mentor peer(s) fails and the 807 ENRP server channel is available, the initiating server SHOULD use 808 the auto-discover procedure defined in steps 1-5 above. 810 3.2.2.2. Request complete server list from mentor peer 812 Once the initiating server finds its mentor peer server (by either 813 discovery or administrative means), the initiating server MUST send 814 an ENRP_LIST_REQUEST message to the mentor peer server to request a 815 copy of the complete server list maintained by the mentor peer (see 816 Section 3.9 for maintaining server list). 818 The initiating server SHOULD start a MAX-TIME-NO-RESPONSE timer every 819 time it finishes sending an ENRP_LIST_REQUEST message. If the timer 820 expires before receiving a response from the mentor peer, the 821 initiating server SHOULD abort and send a new server list request to 822 a backup mentor peer, if one is available. 824 Upon the reception of this request, the mentor peer server SHOULD 825 reply with an ENRP_LIST_RESPONSE message and include in the message 826 body all existing ENRP servers known by the mentor peer. 828 Upon the reception of the ENRP_LIST_RESPONSE message from the mentor 829 peer, the initiating server MUST use the server information carried 830 in the message to initialize its own peer list. 832 However, if the mentor itself is in the process of startup and not 833 ready to provide a peer server list (for example, the mentor peer is 834 waiting for a response to its own ENRP_LIST_REQUEST to another 835 server), it MUST reject the request by the initiating server and 836 respond with an ENRP_LIST_RESPONSE message with the R flag set to 837 '1', and with no server information included in the response. 839 In the case where its ENRP_LIST_REQUEST is rejected by the mentor 840 peer, the initiating server SHOULD either wait for a few seconds and 841 re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a 842 backup mentor peer available, select another mentor peer server and 843 send the ENRP_LIST_REQUEST to the new mentor server. 845 3.2.3. Download ENRP Handlespace Data from Mentor Peer 847 After a peer list download is completed, the initiating server MUST 848 request a copy of the current handlespace data from its mentor peer 849 server, by taking the following steps: 851 1. The initiating server MUST first send a ENRP_HANDLE_TABLE_REQUEST 852 message to the mentor peer, with W flag set to '0', indicating 853 that the entire handlespace is requested. 855 2. Upon the reception of this message, the mentor peer MUST start a 856 download session in which a copy of the current handlespace data 857 maintained by the mentor peer is sent to the initiating server in 858 one or more ENRP_HANDLE_TABLE_RESPONSE messages (Note, the mentor 859 server may find it particularly desirable to use multiple 860 ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when 861 the handlespace is large, especially when forming and sending out 862 a single response containing a large handlespace may interrupt 863 its other services). 865 If more than one ENRP_HANDLE_TABLE_RESPONSE message are used 866 during the download, the mentor peer MUST use the M flag in each 867 ENRP_HANDLE_TABLE_RESPONSE message to indicate whether this 868 message is the last one for the download session. In particular, 869 the mentor peer MUST set the M flag to '1' in the outbound 870 ENRP_HANDLE_TABLE_RESPONSE if there is more data to be 871 transferred and MUST keep track of the progress of the current 872 download session. The mentor peer MUST set the M flag to '0' in 873 the last ENRP_HANDLE_TABLE_RESPONSE for the download session and 874 close the download session (i.e., removing any internal record of 875 the session) after sending out the last message. 877 3. During the downloading, every time the initiating server receives 878 an ENRP_HANDLE_TABLE_RESPONSE message, it MUST transfer the data 879 entries carried in the message into its local handlespace 880 database, and then check whether or not this message is the last 881 one for the download session. 883 If the M flag is set to '1' in the just processed 884 ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST 885 send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer 886 to request for the next ENRP_HANDLE_TABLE_RESPONSE message. 888 4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE 889 message into its local handlespace database, the initiating 890 server MUST handle each pool entry carried in the message using 891 the following rules: 893 A. If the pool does not exist in the local handlespace, the 894 initiating server MUST create the pool in the local 895 handlespace and add the PE(s) in the pool entry to the pool. 897 When creating the pool, the initiation server MUST set the 898 overall member selection policy type of the pool to the 899 policy type indicated in the first PE. 901 B. If the pool already exists in the local handlespace, but the 902 PE(s) in the pool entry is not currently a member of the 903 pool, the initiating server MUST add the PE(s) to the pool. 905 C. If the pool already exists in the local handlespace AND the 906 PE(s) in the Pool entry is already a member of the pool, the 907 initiating server SHOULD replace the attributes of the 908 existing PE(s) with the new information. ENRP will make sure 909 that the information keeps up to date. 911 5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from 912 the mentor peer and unpacked into the local handlespace, the 913 initialization process is completed and the initiating server 914 SHOULD start to provide ENRP services. 916 Under certain circumstances, the mentor peer itself may not be able 917 to provide a handlespace download to the initiating server. For 918 example, the mentor peer is in the middle of initializing its own 919 handlespace database, or it has currently too many download sessions 920 open to other servers. 922 In such a case, the mentor peer MUST reject the request by the 923 initiating server and respond with an ENRP_HANDLE_TABLE_RESPONSE 924 message with the R flag set to '1', and with no pool entries included 925 in the response. 927 In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the 928 mentor peer, the initiating server SHOULD either wait for a few 929 seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor 930 server, or if there is a backup mentor peer available, select another 931 mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new 932 mentor server. 934 A handlespace download session that has been started may get 935 interrupted for some reason. To cope with this, the initiating 936 server SHOULD start a timer every time it finishes sending an 937 ENRP_HANDLE_TABLE_REQUEST to its mentor peer. If this timer expires 938 without receiving a response from the mentor peer, the initiating 939 server SHOULD abort the current download session and re-start a new 940 handlespace download with a backup mentor peer, if one is available. 942 Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, and the 943 mentor peer set the M-bit to 1 to indicate that it has more data to 944 send, it SHOULD start a session timer. If this timer expires without 945 receiving another request from the initiating server, the mentor peer 946 SHOULD abort the session, cleaning out any resource and record of the 947 session. 949 3.3. Handle PE Registration 951 To register itself with the handlespace, a PE sends an 952 ASAP_REGISTRATION message to its home ENRP server. The format of 953 ASAP_REGISTRATION message and rules of sending it are defined in [9]. 955 In the ASAP_REGISTRATION message, the PE indicates the handle of the 956 pool it wishes to join in a pool handle parameter, and its complete 957 transport information and any load control information in a PE 958 parameter. 960 The ENRP server handles the ASAP_REGISTRATION message according to 961 the following rules: 963 1. If the named pool does not exist in the handlespace, the ENRP 964 server MUST creates a new pool with that handle in the 965 handlespace and add the PE to the pool as its first PE; 967 When a new pool is created, the overall member selection policy 968 of the pool MUST be set to the policy type indicated by the first 969 PE, the overall pool transport type MUST be set to the transport 970 type indicated by the PE, and the overall pool data/control 971 channel configuration MUST be set to what is indicated in the 972 Transport Use field of the User Transport parameter by the 973 registering PE. 975 2. If the named pool already exists in the handlespace, but the 976 requesting PE is not currently a member of the pool, the ENRP 977 server will add the PE as a new member to the pool; 979 However, before adding the PE to the pool, the server MUST check 980 if the policy type, transport type, and transport usage indicated 981 by the registering PE is consistent with those of the pool. If 982 different, the ENRP server MUST reject the registration. 984 3. If the named pool already exists in the handlespace AND the 985 requesting PE is already a member of the pool, the ENRP server 986 SHOULD consider this as a re-registration case. The ENRP server 987 MUST perform the same tests on policy, transport type, transport 988 use, as described above. If the re-registration is accepted 989 after the test, the ENRP Server SHOULD replace the attributes of 990 the existing PE with the information carried in the received 991 ASAP_REGISTRATION message. 993 4. After accepting the registration, the ENRP server MUST assign 994 itself the owner of this PE. If this is a re-registration, the 995 ENRP server MUST take over ownership of this PE regardless of 996 whether the PE was previously owned by this server or by another 997 server. The ENRP server MUST also record the SCTP transport 998 address from which it received the ASAP_REGISTRATION in the ASAP 999 Transport parameter TLV inside the PE parameter of this PE. 1001 5. The ENRP server may reject the registration due to other reasons 1002 such as invalid values, lack of resource, authentication failure, 1003 etc. 1005 In all above cases, the ENRP server MUST reply to the requesting PE 1006 with an ASAP_REGISTRATION_RESPONSE message. If the registration is 1007 accepted, the ENRP server MUST set the 'R' flag in the 1008 ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, 1009 the ENRP server MUST indicate the rejection by setting the 'R' flag 1010 in the ASAP_REGISTRATION_RESPONSE to '1'. 1012 If the registration is rejected, the ENRP server SHOULD include the 1013 proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message. 1015 If the registration is granted (either a new registration or a re- 1016 registration case), the ENRP server MUST assign itself to be the home 1017 ENRP server of the PE, i.e., to "own" the PE. 1019 Implementation note: for better performance, the ENRP server may 1020 find it both efficient and convenient to internally maintain two 1021 separate PE lists or tables - one is for the PEs that are "owned" 1022 by the ENRP server and the other for all the PEs owned by its 1023 peer(s). 1025 Moreover, if the registration is granted, the ENRP server MUST take 1026 the handlespace update action as described in Section 3.6 to inform 1027 its peers about the change just made. If the registration is denied, 1028 no message will be sent to its peers. 1030 3.3.1. Rules on PE Re-registration 1032 A PE may re-register itself to the handlespace with a new set of 1033 attributes in order to, for example, extend its registration life, 1034 change its load factor value, etc. as described in the ASAP 1035 specification. 1037 A PE may modify its load factor value at any time via re- 1038 registration. Based on the number of PEs in the pool and the pool's 1039 overall policy type, this operation allows the PE to dynamically 1040 control its share of inbound messages received by the pool (also see 1041 Section ???? in [9] for more on load control). 1043 Moreover, when re-registering, the PE MUST NOT change its policy 1044 type. The server MUST reject the re-registration if the PE attempt 1045 to change its policy type. In the rejection, the server SHOULD 1046 attach an error code "Pooling Policy Inconsistent". 1048 Regardless whether it is the current owner of the PE, if the re- 1049 registration is granted to the PE, the ENRP server MUST assign itself 1050 to be the new home ENRP server of the PE. 1052 Moreover, if the re-registration is granted, the ENRP server MUST 1053 take the handlespace update action as described in Section 3.6 to 1054 inform its peers about the change just made. If the re-registration 1055 is denied, no message will be sent to its peers. 1057 3.4. Handle PE De-registration 1059 To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION 1060 message to its home ENRP server. The complete format of 1061 ASAP_DEREGISTRATION message and rules of sending it are defined in 1062 [9]. 1064 In the ASAP_DEREGISTRATION message the PE indicates the handle of the 1065 pool it belongs to in a pool handle parameter and provides its PE 1066 identifier. 1068 Upon receiving the message, the ENRP server SHALL remove the PE from 1069 its handlespace. Moreover, if the PE is the last one of the named 1070 pool, the ENRP server will remove the pool from the handlespace as 1071 well. 1073 If the ENRP server fails to find any record of the PE in its 1074 handlespace, it SHOULD consider the de-registration granted and 1075 completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the 1076 PE. 1078 The ENRP server may reject the de-registration request for various 1079 reasons, such as invalid parameters, authentication failure, etc. 1081 In response, the ENRP server MUST send an 1082 ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de- 1083 registration is rejected, the ENRP server MUST indicate the rejection 1084 by including the proper Operational Error parameter. 1086 It should be noted that de-registration does not stop the PE from 1087 sending or receiving application messages. 1089 Once the de-registration request is granted AND the PE removed from 1090 its local copy of the handlespace, the ENRP server MUST take the 1091 handlespace update action described in Section 3.6 to inform its 1092 peers about the change just made. Otherwise, the ENRP server MUST 1093 NOT inform its peers. 1095 3.5. Pool Handle Translation 1097 A PU uses the pool handle translation service of an ENRP server to 1098 resolve a pool handle to a list of accessible transport addresses of 1099 the member PEs of the pool. 1101 This requires the PU to send an ASAP_HANDLE_RESOLUTION message to its 1102 home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify 1103 the pool handle to be translated in a Pool Handle parameter. 1104 Complete definition of the ASAP_HANDLE_RESOLUTION message and the 1105 rules of sending it are defined in [9]. 1107 An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION 1108 requests from PUs either over an SCTP association on the well-know 1109 SCTP port, or over a TCP connection on the well-know TCP port. 1111 Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server 1112 MUST first look up the pool handle in its handlespace. If the pool 1113 exits, the home ENRP server MUST compose and send back an 1114 ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. 1116 In the response message, the ENRP server SHOULD list all the PEs 1117 currently registered in this pool, in a list of PE parameters. The 1118 ENRP server MUST also include a pool member selection policy 1119 parameter to indicate the overall member selection policy for the 1120 pool, if the current pool member selection policy is not round-robin. 1122 If the named pool does not exist in the handlespace, the ENRP server 1123 MUST reject the handle resolution request by responding with an 1124 ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor 1125 Handle error. 1127 The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and 1128 the rules of receiving it are defined in [9]. 1130 3.6. Server Handlespace Update 1132 This includes a set of update operations used by an ENRP server to 1133 inform its peers when its local handlespace is modified, e.g., 1134 addition of a new PE, removal of an existing PE, change of pool or PE 1135 properties. 1137 3.6.1. Announcing Addition or Update of PE 1139 When a new PE is granted registration to the handlespace or an 1140 existing PE is granted a re-registration, the home ENRP server uses 1141 this procedure to inform all its peers. 1143 This is an ENRP announcement and is sent to all the peer of the home 1144 ENRP server. See Section 3.1 on how announcements are sent. 1146 An ENRP server MUST announce this update to all its peers in a 1147 ENRP_HANDLE_UPDATE message with the Update Action field set to 1148 ADD_PE, indicating the addition of a new PE or the modification of an 1149 existing PE. The complete new information of the PE and the pool its 1150 belongs to MUST be indicated in the message with a PE parameter and a 1151 Pool Handle parameter, respectively. 1153 The home ENRP server SHOULD fill in its server Id in the Sending 1154 Server's ID field and leave the Receiving Server's ID blank (i.e., 1155 all 0's). 1157 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take 1158 the following actions: 1160 1. If the named pool indicated by the pool handle does not exist in 1161 its local copy of the handlespace, the peer MUST create the named 1162 pool in its local handlespace and add the PE to the pool as the 1163 first PE. It MUST then copy in all other attributes of the PE 1164 carried in the message. 1166 When the new pool is created, the overall member selection policy 1167 of the pool MUST be set to the policy type indicated by the PE. 1169 2. If the named pool already exists in the peer's local copy of the 1170 handlespace AND the PE does not exist, the peer MUST add the PE 1171 to the pool as a new PE and copy in all attributes of the PE 1172 carried in the message. 1174 3. If the named pool exists AND the PE is already a member of the 1175 pool, the peer MUST replace the attributes of the PE with the new 1176 information carried in the message. 1178 3.6.2. Announcing Removal of PE 1180 When an existing PE is granted de-registration or is removed from its 1181 handlespace for some other reasons (e.g., purging an unreachable PE, 1182 see Section 3.7), the ENRP server MUST uses this procedure to inform 1183 all its peers about the change just made. 1185 This is an ENRP announcement and is sent to all the peer of the home 1186 ENRP server. See Section 3.1 on how announcements are sent. 1188 An ENRP server MUST announce the PE removal to all its peers in an 1189 ENRP_HANDLE_UPDATE message with the Update Action field set to 1190 DEL_PE, indicating the removal of an existing PE. The complete 1191 information of the PE and the pool its belongs to MUST be indicated 1192 in the message with a PE parameter and a Pool Handle parameter, 1193 respectively. 1195 The sending server MUST fill in its server ID in the Sending Server's 1196 ID field and leave the Receiving Server's ID blank (i.e., set to all 1197 0's). 1199 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first 1200 find pool and the PE in its own handlespace, and then remove the PE 1201 from its local handlespace. If the removed PE is the last one in the 1202 pool, the peer MUST also delete the pool from its local handlespace. 1204 If the peer fails to find the PE or the pool in its handlespace, it 1205 SHOULD take no further actions. 1207 3.7. Detecting and Removing Unreachable PE 1209 Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 1210 Notification, see section 10.2 of [4]), the PU SHOULD send an 1211 ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The 1212 message SHOULD contain the pool handle and the PE Id of the 1213 unreachable PE. 1215 Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server 1216 MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE 1217 message to the PE in question (the 'H' flag in the message SHOULD be 1218 set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails 1219 (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP 1220 server MUST consider the PE as truly unreachable and MUST remove the 1221 PE from its handlespace and take actions described in Section 3.6.2. 1223 If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully 1224 to the PE, the ENRP server MUST retain the PE in its handlespace. 1225 Moreover, the server SHOULD keep a counter to record how many 1226 ASAP_ENDPOINT_UNREACHABLE messages it has received reporting 1227 reachability problem relating to this PE. If the counter exceeds the 1228 protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove 1229 the PE from its handlespace and take actions described in 1230 Section 3.6.2. 1232 Optionally, an ENRP server may also periodically send point-to-point 1233 ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each 1234 of the PEs owned by the ENRP server in order to check their 1235 reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE 1236 fails, the ENRP server MUST consider the PE as unreachable and MUST 1237 remove the PE from its handlespace and take actions described in 1238 Section 3.6.2. Note, if an ENRP server owns a large number of PEs, 1239 the implementation should pay attention not to flood the network with 1240 bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the 1241 implementation MUST distribute the ASAP_ENDPOINT_KEEP_ALIVE message 1242 traffic over a time period. 1244 The complete definition and rules of sending 1245 ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE 1246 messages are described in [9]. 1248 3.8. Helping PE and PU to Discover Home ENRP Server 1250 At its startup time, or whenever its current home ENRP server is not 1251 providing services, a PE or PU will attempt to find a new home 1252 server. For this reason, the PE or PU will need to maintain a list 1253 of currently available ENRP servers in its scope. 1255 To help the PE or PU maintaining this list, an ENRP server, if it is 1256 enabled for multicast, SHOULD periodically send out an 1257 ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to 1258 the well-known ASAP multicast channel. And in the 1259 ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the 1260 transport addresses available for ASAP communications. If the ENRP 1261 server only supports SCTP for ASAP communications, the transport 1262 information MAY be omitted in the ASAP_SERVER_ANNOUNCE message. 1264 For the complete procedure of this, see Section 3.6?? in [9]. 1266 3.9. Maintaining Peer List and Monitoring Peer Status 1268 An ENRP server MUST keep an internal record on the status of each of 1269 its known peers. This record is referred to as the server's "peer 1270 list" 1272 3.9.1. Discovering New Peer 1274 If a message of any type is received from a previously unknown peer, 1275 the ENRP server MUST consider this peer a new peer in the operational 1276 scope and add it to the peer list. 1278 The ENRP server MUST send an ENRP_PRESENCE message with the Reply- 1279 required flag set to '1' to the source address found in the arrived 1280 message. This will force the new peer to reply with its own 1281 ENRP_PRESENCE containing its full server information (see 1282 Section 2.1). 1284 3.9.2. Server Sending Heartbeat 1286 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 1287 continued presence to all its peer with a ENRP_PRESENCE message. In 1288 the ENRP_PRESENCE message, the ENRP server MUST set the 1289 'Replay_required' flag to '0', indicating that no response is 1290 required. 1292 The arrival of this periodic ENRP_PRESENCE message will cause all its 1293 peers to update their internal variable "peer_last_heard" for the 1294 sending server (see Section 3.9.3 for more details). 1296 3.9.3. Detecting Peer Server Failure 1298 An ENRP server MUST keep an internal variable "peer_last_heard" for 1299 each of its known peers and the value of this variable MUST be 1300 updated to the current local time every time a message of any type 1301 (point-to-point or announcement) is received from the corresponding 1302 peer. 1304 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 1305 seconds, the ENRP server MUST immediately send a point-to-point 1306 ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1308 If the send fails or the peer does not reply after MAX-TIME-NO- 1309 RESPONSE seconds, the ENRP server MUST consider the peer server dead 1310 and SHOULD initiate the takeover procedure defined in Section 3.10. 1312 3.10. Taking-over a Failed Peer Server 1314 In the following descriptions, we call the ENRP server that detects 1315 the failed peer server and initiates the take-over the "initiating 1316 server" and the failed peer server the "target server." This allows 1317 PE to continue to operate in case of a failure of their Home ENRP 1318 server. 1320 3.10.1. Initiating Server Take-over Arbitration 1322 The initiating server SHOULD first start the take-over arbitration 1323 process by sending a ENRP_INIT_TAKEOVER message to all its peer 1324 servers. See Section 3.1 on how announcements are sent. In the 1325 message, the initiating server MUST fill in the Sending Server's ID 1326 and Targeting Server's ID. The goal is that only one ENRP server 1327 takes over the PE from the target. 1329 After announcing the ENRP_INIT_TAKEOVER message, the initiating 1330 server SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of 1331 its known peers, except of the target server. 1333 Each peer receiving a ENRP_INIT_TAKEOVER message from the initiating 1334 server SHOULD take the following actions: 1336 1. If the peer server determines that itself is the target server 1337 indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately 1338 announce an ENRP_PRESENCE message to all its peer ENRP servers in 1339 an attempt to stop this take-over process. This indicates a 1340 false failure detection case by the initiating server. The 1341 initiating server MUST stop the takeover operation. 1343 2. If the peer server finds that it has already started its own 1344 take-over arbitration process on the same target server, it MUST 1345 perform the following arbitration: 1347 A. If the peer's server ID is smaller in value than the Sending 1348 Server's ID in the arrived ENRP_INIT_TAKEOVER message, the 1349 peer server SHOULD immediately abort its own take-over 1350 attempt. Moreover, the peer SHOULD mark the target server as 1351 "not active" on its internal peer list so that its status 1352 will no longer be monitored by the peer, and reply the 1353 initiating server with an ENRP_INIT_TAKEOVER_ACK message. 1355 B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER 1356 message and take no action. 1358 3. If the peer finds that it is neither the target server nor is in 1359 its own take-over process, the peer SHOULD: a) mark the target 1360 server as "not active" on its internal peer list so that its 1361 status will no longer be monitored by this peer, and b) reply to 1362 the initiating server with an ENRP_INIT_TAKEOVER_ACK message. 1364 Once the initiating server has received ENRP_INIT_TAKEOVER_ACK 1365 message from _all_ of its currently known peers (except for the 1366 target server), it SHOULD consider that it has won the arbitration 1367 and SHOULD proceed to complete the take-over, following the steps 1368 described in Section 3.10.2. 1370 However, if it receives an ENRP_PRESENCE from the target server at 1371 any point in the arbitration process, the initiating server MUST 1372 immediately abort the take-over process and mark the status of the 1373 target server as "active". 1375 3.10.2. Take-over Target Peer Server 1377 The initiating ENRP server SHOULD first send, via an announcement, a 1378 ENRP_TAKEOVER_SERVER message to inform all its active peers that the 1379 take-over is enforced. The target server's ID MUST be filled in the 1380 message. The initiating server SHOULD then remove the target server 1381 from its internal peer list. 1383 Then it SHOULD examine its local copy of the handlespace and claim 1384 ownership of each of the PEs originally owned by the target server, 1385 by following these steps: 1387 1. mark itself as the home ENRP server of each of the PEs originally 1388 owned by the target server; 1390 2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message, with the 1391 'H' flag set to '1', to each of the PEs. This will trigger the 1392 PE to adopt the initiating sever as its new home ENRP server; 1394 When a peer receives the ENRP_TAKEOVER_SERVER message from the 1395 initiating server, it SHOULD update its local peer list and PE cache 1396 by following these steps: 1398 1. remove the target server from its internal peer list; 1400 2. update the home ENRP server of each PE in its local copy of the 1401 handlespace to be the sender of the message, i.e., the initiating 1402 server. 1404 3.11. Handlespace Data Auditing and Re-synchronization 1406 Message losses or certain temporary breaks in network connectivity 1407 may result in data inconsistency in the local handlespace copy of 1408 some of the ENRP servers in an operational scope. Therefore, each 1409 ENRP server in the operational scope SHOULD periodically verify that 1410 its local copy of handlespace data is still in sync with that of its 1411 peers. 1413 This section defines the auditing and re-synchronization procedures 1414 for an ENRP server to maintain its handlespace data consistency. 1416 3.11.1. Auditing Procedures 1418 A checksum covering the data which should be the same is exchanged to 1419 figure out if the data is the same or not. 1421 The auditing of handlespace consistency is based on the following 1422 procedures: 1424 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1425 integer internal variable) for each of its known peers and for 1426 itself. For an ENRP server with 'k' known peers, we denote these 1427 internal variables as "pe_checksum_pr0", "pe_checksum_pr1", ..., 1428 "pe_checksum_prk", where "pe_checksum_pr0" is the server's own PE 1429 checksum. The list of what these checksums cover and a detailed 1430 algorithm for calculating them is given in Section 3.11.2. 1432 2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST 1433 include in the message its current PE checksum (i.e., 1434 "pe_checksum_pr0"). 1436 3. When an ENRP server (server A) receives a PE checksum (carried in 1437 an arrived ENRP_PRESENCE) from a peer ENRP server (server B), 1438 server A SHOULD compare the PE checksum found in the 1439 ENRP_PRESENCE with its own internal PE checksum of server B 1440 (i.e., "pe_checksum_prB"). 1442 4. If the two values match, server A will consider that there is no 1443 handlespace inconsistency between itself and server B and should 1444 take no further actions. 1446 5. If the two values do NOT match, server A SHOULD consider that 1447 there is a handlespace inconsistency between itself and server B 1448 and a re-synchronization process SHOULD be carried out 1449 immediately with server B (see Section 3.11.3). 1451 3.11.2. PE Checksum Calculation Algorithm 1453 When an ENRP server (server A) calculate an internal PE checksum for 1454 a peer (server B), it MUST use the following algorithm. 1456 Let us assume that in server A's internal handlespace there are 1457 currently 'M' PEs that are owned by server B. Each of the 'M' PEs 1458 will then contribute to the checksum calculation with the following 1459 byte block: 1461 0 1 2 3 1462 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 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 : Pool handle string of the pool the PE belongs (padded with : 1465 : zeros to next 32-bit word boundary if needed) : 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | PE Id (4 octets) | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 Note, these are not TLVs. This byte block gives each PE a unique 1471 byte pattern in the scope. The 16-bit PE checksum for server B 1472 "pe_checksum_prB" is then calculated over the byte blocks contributed 1473 by the 'M' PEs one by one. The PE checksum calculation MUST use the 1474 Internet algorithm described in [1]. 1476 Server A MUST calculate its own PE checksum (i.e., "pe_checksum_pr0") 1477 in the same fashion, using the byte blocks of all the PEs owned by 1478 itself. 1480 Note, whenever an ENRP finds that its internal handlespace has 1481 changed (e.g., due to PE registration/deregistration, receiving peer 1482 updates, removing failed PEs, downloading handlespace pieces from a 1483 peer, etc.), it MUST immediately update all its internal PE checksums 1484 that are affected by the change. 1486 Implementation Note: when the internal handlespace changes (e.g., a 1487 new PE added or an existing PE removed), an implementation needs not 1488 to re-calculate the affected PE checksum; it can instead simply 1489 update the checksum by adding or subtracting the byte block of the 1490 corresponding PE from the previous checksum value. 1492 3.11.3. Re-synchronization Procedures 1494 If an ENRP server determines that there is inconsistency between its 1495 local handlespace data and a peer's handlespace data with regarding 1496 to the PEs owned by that peer, it MUST perform the following steps to 1497 re-synchronize the data: 1499 1. The ENRP server SHOULD first "mark" every PE it knows about that 1500 is owned by the peer in its local handlespace database; 1502 2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST 1503 message with W flag set to '1' to the peer to request a complete 1504 list of PEs owned by the peer; 1506 3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with W 1507 flag set to '1', the peer server SHOULD immediately respond with 1508 an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently 1509 owned by the peer. 1511 4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the 1512 ENRP server SHOULD transfer the PE entries carried in the message 1513 into its local handlespace database. If an PE entry being 1514 transferred already exists in its local database, the ENRP server 1515 MUST replace the entry with the copy found in the message and 1516 remove the "mark" from the entry. 1518 5. After transferring all the PE entries from the received 1519 ENRP_HANDLE_TABLE_RESPONSE message into its local database, the 1520 ENRP server SHOULD check whether there are still PE entries that 1521 remain "marked" in its local handlespace. If so, the ENRP server 1522 SHOULD silently remove those "marked" entries. 1524 Note, similar to what is described in Section 3.2.3, the peer may 1525 reject the ENRP_HANDLE_TABLE_REQUEST or use more than one 1526 ENRP_HANDLE_TABLE_RESPONSE message to respond. 1528 3.12. Handling Unrecognized Message or Unrecognized Parameter 1530 When an ENRP server receives an ENRP message with an unknown message 1531 type or a message of known type that contains an unknown parameter, 1532 it SHOULD handle the unknown message or the unknown parameter 1533 according to the unrecognized message and parameter handling rules 1534 defined in Sections 3 and 4 in [8]. 1536 According to the rules, if an error report to the message sender is 1537 needed, the ENRP server that discovered the error SHOULD send back an 1538 ENRP_ERROR message with proper error cause code. 1540 4. Variables and Thresholds 1542 4.1. Variables 1544 peer_last_heard - the local time that a peer server was last heard 1545 (via receiving either a multicast or point-to-point message from 1546 the peer). 1548 pe_checksum_pr - the internal 32-bit PE checksum that an ENRP server 1549 keeps for a peer. A separate PE checksum is kept for each of its 1550 known peers as well as for itself. 1552 4.2. Thresholds 1554 MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender 1555 will make to contact an ENRP server (Default=3 times). 1557 TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will 1558 wait for a response from an ENRP server (Default=5 seconds). 1560 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1561 heartbeat message to all its known peers. (Default=30 secs.) 1563 SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a 1564 SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) 1566 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1567 will wait before considering a silent peer server potentially 1568 dead. (Default=61 secs.) 1570 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1571 sender will wait for a response after sending out a message. 1572 (Default=5 secs.) 1574 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on 1575 a PE that an ENRP server will allow before purging this PE from 1576 the handlespace. (Default=3) 1578 5. IANA Considerations 1580 [NOTE to RFC-Editor: 1582 "RFCXXXX" is to be replaced by the RFC number you assign this 1583 document. 1585 ] 1587 This document (RFCXXX) is the reference for all registrations 1588 described in this section. All registrations need to be listed on an 1589 RSerPool specific page. 1591 5.1. A New Table for ENRP Message Types 1593 ENRP Message Types have to be maintained by IANA. Ten initial values 1594 should be assigned by IANA as described in Figure 1. This requires a 1595 new table "ENRP Message Types": 1597 Type Message Name Reference 1598 ----- ------------------------- --------- 1599 0x00 (reserved by IETF) RFCXXXX 1600 0x01 ENRP_PRESENCE RFCXXXX 1601 0x02 ENRP_HANDLE_TABLE_REQUEST RFCXXXX 1602 0x03 ENRP_HANDLE_TABLE_RESPONSE RFCXXXX 1603 0x04 ENRP_HANDLE_UPDATE RFCXXXX 1604 0x05 ENRP_LIST_REQUEST RFCXXXX 1605 0x06 ENRP_LIST_RESPONSE RFCXXXX 1606 0x07 ENRP_INIT_TAKEOVER RFCXXXX 1607 0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX 1608 0x09 ENRP_TAKEOVER_SERVER RFCXXXX 1609 0x0a ENRP_ERROR RFCXXXX 1610 0x0b-0xff (reserved by IETF) RFCXXXX 1612 For registering at IANA an ENRP Message Type in this table a request 1613 has to be made to assign such a number. This number must be unique. 1614 The "Specification Required" policy of RFC2434 [3] MUST be applied. 1616 5.2. A New Table for Update Action Types 1618 Update Types have to be maintained by IANA. Two initial values 1619 should be assigned by IANA. This requires a new table "Update Action 1620 Types": 1622 Type Update Action Reference 1623 ------------- -------------------- --------- 1624 0x0000 ADD_PE RFCXXXX 1625 0x0001 DEL_PE RFCXXXX 1626 0x0002-0xffff (reserved by IETF) RFCXXXX 1628 For registering at IANA an Update Action Type in this table a request 1629 has to be made to assign such a number. This number must be unique. 1630 The "Specification Required" policy of RFC2434 [3] MUST be applied. 1632 5.3. Multicast Addresses 1634 IANA should assign one multicast address for the ENRP server channel 1635 and another one for the ENRP client channel. 1637 6. Security Considerations 1639 We present a summary of the threats to the RSerPool architecture and 1640 describe security requirements in response to mitigate the threats. 1641 Next we present the security mechanisms, based on TLS, that are 1642 implementation requirements in response to the threats. Finally, we 1643 present a chain of trust argument that examines critical data paths 1644 in RSerPool and shows how these paths are protected by the TLS 1645 implementation. 1647 6.1. Summary of Rserpool Security Threats 1649 Threats Introduced by RSerPool and Requirements for Security in 1650 Response to Threats [10] describes the threats to the RSerPool 1651 architecture in detail lists the security requirements in response to 1652 each threat. From the threats described in this document, the 1653 security services required for the RSerPool protocol are enumerated 1654 below. 1656 Threat 1) PE registration/deregistration flooding or spoofing 1657 ----------- 1658 Security mechanism in response: ENRP server authenticates the PE 1660 Threat 2) PE registers with a malicious ENRP server 1661 ----------- 1662 Security mechanism in response: PE authenticates the ENRP server 1664 Threat 1 and 2 taken together results in mutual authentication of the 1665 ENRP server and the PE. 1667 Threat 3) Malicious ENRP server joins the ENRP server pool 1668 ----------- 1669 Security mechanism in response: ENRP servers mutually authenticate 1671 Threat 4) A PU communicates with a malicious ENRP server for handle 1672 resolution 1673 ----------- 1674 Security mechanism in response: The PU authenticates the ENRP server 1676 Threat 5) Replay attack 1677 ----------- 1678 Security mechanism in response: Security protocol which has 1679 protection from replay attacks 1681 Threat 6) Corrupted data which causes a PU to have misinformation 1682 concerning a pool handle resolution 1683 ----------- 1684 Security mechanism in response: Security protocol which supports 1685 integrity protection 1687 Threat 7) Eavesdropper snooping on handlespace information 1688 ----------- 1689 Security mechanism in response: Security protocol which supports data 1690 confidentiality 1692 Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to 1693 ENRP server 1694 ----------- 1695 Security mechanism in response: ASAP must control the number of ASAP 1696 endpoint unreachable messages transmitted from the PU to the ENRP 1697 server. 1699 Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from 1700 the ENRP server 1701 ----------- 1702 Security mechanism in response: ENRP server must control the number 1703 of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE 1705 To summarize the threats 1-7 require security mechanisms which 1706 support authentication, integrity, data confidentiality, protection 1707 from replay attacks. 1709 For RSerPool we need to authenticate the following: 1711 PU <---- ENRP Server (PU authenticates the ENRP server) 1712 PE <----> ENRP Server (mutual authentication) 1713 ENRP server <-----> ENRP Server (mutual authentication) 1715 6.2. Implementing Security Mechanisms 1717 We do not define any new security mechanisms specifically for 1718 responding to threats 1-7. Rather we use an existing IETF security 1719 protocol, specifically [5], to provide the security services 1720 required. TLS supports all these requirements and MUST be 1721 implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be 1722 supported at a minimum by implementors of TLS for RSerPool. For 1723 purposes of backwards compatibility, ENRP SHOULD support 1724 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 1725 other IETF approved ciphersuites. 1727 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must 1728 support mutual authentication. ENRP servers must support mutual 1729 authentication among themselves. PUs MUST authenticate ENRP servers. 1731 ENRP servers and PEs SHOULD possess a site certificate whose subject 1732 corresponds to their canonical hostname. PUs MAY have certificates 1733 of their own for mutual authentication with TLS, but no provisions 1734 are set forth in this document for their use. All RSerPool elements 1735 that support TLS MUST have a mechanism for validating certificates 1736 received during TLS negotiation; this entails possession of one or 1737 more root certificates issued by certificate authorities (preferably 1738 well-known distributors of site certificates comparable to those that 1739 issue root certificates for web browsers). 1741 Implementations MUST support TLS with SCTP as described in [6] or TLS 1742 over TCP as described in [7]. When using TLS/SCTP we must ensure 1743 that RSerPool does not use any features of SCTP that are not 1744 available to an TLS/SCTP user. This is not a difficult technical 1745 problem, but simply a requirement. When describing an API of the 1746 RSerPool lower layer we have also to take into account the 1747 differences between TLS and SCTP. 1749 Threat 8 requires the ASAP protocol to limit the number of 1750 ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [9]) to the 1751 ENRP server. 1753 Threat 9 requires the ENRP protocol to limit the number of 1754 ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see 1755 section Section 3.7). 1757 6.3. Chain of trust 1759 Security is mandatory to implement in RSerPool and is based on TLS 1760 implementation in all three architecture components that comprise 1761 RSerPool -- namely PU, PE and ENRP server. We define an ENRP server 1762 that uses TLS for all communication and authenticates ENRP peers and 1763 PE registrants to be a secured ENRP server. 1765 Here is a description of all possible data paths and a description of 1766 the security. 1768 PU <---> secured ENRP Server (authentication of ENRP server; 1769 queries over TLS) 1770 PE <---> secured ENRP server (mutual authentication; 1771 registration/deregistration over TLS) 1772 secured ENRP server <---> secured ENRP server (mutual authentication; 1773 database updates using TLS) 1775 If all components of the system authenticate and communicate using 1776 TLS, the chain of trust is sound. The root of the trust chain is the 1777 ENRP server. If that is secured using TLS, then security will be 1778 enforced for all ENRP and PE components that try to connect to it. 1780 Summary of interaction between secured and unsecured components: If 1781 the PE does not use TLS and tries to register with a secure ENRP 1782 server, it will receive an error message response indicated as error 1783 due to security considerations and the registration will be rejected. 1784 If an ENRP server which does not use TLS tries to update the database 1785 of a secure ENRP server, then the update will be rejected. If an PU 1786 does not use TLS and communicates with a secure ENRP server, it will 1787 get a response with the understanding that the response is not secure 1788 as the response can be tampered with in transit even if the ENRP 1789 database is secured. 1791 The final case is the PU sending a secure request to ENRP. It might 1792 be that ENRP and PEs are not secured and this is an allowable 1793 configuration. The intent is to secure the communication over the 1794 Internet between the PU and the ENRP server. 1796 Summary: 1798 RSerPool architecture components can communicate with each other to 1799 establish a chain of trust. Secured PE and ENRP servers reject any 1800 communications with unsecured ENRP or PE servers. 1802 If the above is enforced, then a chain of trust is established for 1803 the RSerPool user. 1805 7. Acknowledgements 1807 The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, 1808 Thomas Dreibholz, and many others for their invaluable comments and 1809 feedback. 1811 8. References 1813 8.1. Normative References 1815 [1] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1816 "Computing the Internet checksum", RFC 1071, September 1988. 1818 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1819 Levels", BCP 14, RFC 2119, March 1997. 1821 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1822 Considerations Section in RFCs", BCP 26, RFC 2434, 1823 October 1998. 1825 [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1826 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 1827 Paxson, "Stream Control Transmission Protocol", RFC 2960, 1828 October 2000. 1830 [5] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1831 J., and M. Stillman, "Requirements for Reliable Server 1832 Pooling", RFC 3237, January 2002. 1834 [6] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer 1835 Security over Stream Control Transmission Protocol", RFC 3436, 1836 December 2002. 1838 [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1839 Protocol Version 1.1", RFC 4346, April 2006. 1841 [8] Stewart, R., "Aggregate Server Access Protocol (ASAP) and 1842 Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", 1843 draft-ietf-rserpool-common-param-12 (work in progress), 1844 July 2007. 1846 [9] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 1847 draft-ietf-rserpool-asap-16 (work in progress), July 2007. 1849 [10] Gopal, R., Guttman, E., Holdrege, M., Sengodan, S., and M. 1850 Stillman, "Threats Introduced by Rserpool and Requirements for 1851 Security in response to Threats", 1852 draft-ietf-rserpool-threats-08 (work in progress), 1853 September 2007. 1855 8.2. Informative References 1857 [11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1858 Requirements for Security", BCP 106, RFC 4086, June 2005. 1860 Authors' Addresses 1862 Qiaobing Xie 1863 Motorola, Inc. 1864 1501 W. Shure Drive, 2-F9 1865 Arlington Heights, IL 60004 1866 US 1868 Phone: 1869 Email: qxie1@email.mot.com 1871 Randall R. Stewart 1872 Cisco Systems, Inc. 1873 4875 Forest Drive 1874 Suite 200 1875 Columbia, SC 29206 1876 USA 1878 Phone: 1879 Email: rrs@cisco.com 1881 Maureen Stillman 1882 Nokia 1883 127 W. State Street 1884 Ithaca, NY 14850 1885 US 1887 Phone: 1888 Email: maureen.stillman@nokia.com 1890 Michael Tuexen 1891 Muenster Univ. of Applied Sciences 1892 Stegerwaldstr. 39 1893 48565 Steinfurt 1894 Germany 1896 Email: tuexen@fh-muenster.de 1897 Aron J. Silverton 1898 Motorola, Inc. 1899 1301 E. Algonquin Road 1900 Room 2246 1901 Schaumburg, IL 60196 1902 USA 1904 Phone: +1 847-576-8747 1905 Email: aron.j.silverton@motorola.com 1907 Full Copyright Statement 1909 Copyright (C) The IETF Trust (2007). 1911 This document is subject to the rights, licenses and restrictions 1912 contained in BCP 78, and except as set forth therein, the authors 1913 retain all their rights. 1915 This document and the information contained herein are provided on an 1916 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1917 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1918 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1919 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1920 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1921 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1923 Intellectual Property 1925 The IETF takes no position regarding the validity or scope of any 1926 Intellectual Property Rights or other rights that might be claimed to 1927 pertain to the implementation or use of the technology described in 1928 this document or the extent to which any license under such rights 1929 might or might not be available; nor does it represent that it has 1930 made any independent effort to identify any such rights. Information 1931 on the procedures with respect to rights in RFC documents can be 1932 found in BCP 78 and BCP 79. 1934 Copies of IPR disclosures made to the IETF Secretariat and any 1935 assurances of licenses to be made available, or the result of an 1936 attempt made to obtain a general license or permission for the use of 1937 such proprietary rights by implementers or users of this 1938 specification can be obtained from the IETF on-line IPR repository at 1939 http://www.ietf.org/ipr. 1941 The IETF invites any interested party to bring to its attention any 1942 copyrights, patents or patent applications, or other proprietary 1943 rights that may cover technology that may be required to implement 1944 this standard. Please address the information to the IETF at 1945 ietf-ipr@ietf.org. 1947 Acknowledgment 1949 Funding for the RFC Editor function is provided by the IETF 1950 Administrative Support Activity (IASA).