idnits 2.17.1 draft-ietf-rserpool-enrp-15.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 on line 1829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1853. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Other values are reserved by IETF and MUST not be used. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 4, 2007) is 6322 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 1731, 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 2960 (ref. '8') (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 informational reference (is this intentional?): RFC 1750 (ref. '13') (Obsoleted by RFC 4086) Summary: 6 errors (**), 0 flaws (~~), 9 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: July 8, 2007 Cisco Systems, Inc. 6 M. Stillman 7 Nokia 8 M. Tuexen 9 Muenster Univ. of Applied Sciences 10 A. Silverton 11 Motorola, Inc. 12 January 4, 2007 14 Endpoint Handlespace Redundancy Protocol (ENRP) 15 draft-ietf-rserpool-enrp-15.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 July 8, 2007. 42 Copyright Notice 44 Copyright (C) The Internet Society (2007). 46 Abstract 48 Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work 49 in conjunction with the Aggregate Server Access Protocol (ASAP) to 50 accomplish the functionality of the Reliable Server Pooling 51 (Rserpool) requirements and architecture. Within the operational 52 scope of Rserpool, ENRP defines the procedures and message formats of 53 a distributed, fault-tolerant registry service for storing, 54 bookkeeping, retrieving, and distributing pool operation and 55 membership information. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . . 6 63 2.1. ENRP_PRESENCE message . . . . . . . . . . . . . . . . . . 6 64 2.2. ENRP_HANDLE_TABLE_REQUEST message . . . . . . . . . . . . 8 65 2.3. ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . . 8 66 2.4. ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10 67 2.5. ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 11 68 2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12 69 2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13 70 2.8. ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 71 2.9. ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 14 72 2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . 25 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 . . . . . 30 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 . . . . . . . . . . . . . 31 93 3.10.1. Initiate Server Take-over Arbitration . . . . . . . . 31 94 3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32 95 3.11. Handlespace Data Auditing and Re-synchronization . . . . . 33 96 3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33 97 3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 34 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. Security Considerations . . . . . . . . . . . . . . . . . . . 37 104 5.1. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 38 105 5.2. Implementing Security Mechanisms . . . . . . . . . . . . . 39 106 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 107 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 108 7.1. Normative References . . . . . . . . . . . . . . . . . . . 42 109 7.2. Informative References . . . . . . . . . . . . . . . . . . 43 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 111 Intellectual Property and Copyright Statements . . . . . . . . . . 46 113 1. Introduction 115 ENRP is designed to work in conjunction with ASAP [1] to accomplish 116 the functionality of Rserpool as defined by its requirements [2] and 117 architecture [3]. 119 Within the operational scope of Rserpool, ENRP defines the procedures 120 and message formats of a distributed fault-tolerant registry service 121 for storing, bookkeeping, retrieving, and distributing pool operation 122 and membership information. 124 Whenever appropriate, in the rest of this document we will refer to 125 this Rserpool registry service as ENRP handlespace, or simply 126 handlespace. 128 1.1. Definitions 130 This document uses the following terms: 132 Operational scope: See [3]; 134 Pool (or server pool): See [3]; 136 Pool handle: See [3]; 138 Pool element (PE): See [3]; 140 Pool user (PU): See [3]; 142 Pool element handle: See [3]; 144 ENRP handlespace (or handlespace): See [3]; 146 ENRP client channel: The communication channel through which an ASAP 147 User (either a PE or PU) requests ENRP handlespace service. The 148 client channel is usually defined by the transport address of the 149 home server and a well known port number. The channel MAY make 150 use of multi-cast or a named list of ENRP servers. 152 ENRP server channel: Defined by a well known multicast IP address 153 and a well known port number. All ENRP servers in an operational 154 scope can send multicast messages to other servers through this 155 channel. PEs are also allowed to multicast on this channel 156 occasionally; 158 Home ENRP server: The ENRP server to which a PE or PU currently 159 belongs. A PE MUST only have one home ENRP server at any given 160 time and both the PE and its home ENRP server MUST keep track of 161 this master/slave relationship between them. A PU SHOULD select 162 one of the available ENRP servers as its home ENRP server, but the 163 ENRP server does not need to know, nor does it need to keep track 164 of this relationship. 166 1.2. Conventions 168 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 169 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 170 they appear in this document, are to be interpreted as described in 171 [6]. 173 2. ENRP Message Definitions 175 In this section, we defines the format of all ENRP messages. These 176 are messages sent and received amongst ENRP servers in an operational 177 scope. Messages sent and received between a PE/PU and an ENRP server 178 are part of ASAP and are defined in [1]. A common format, defined in 179 [11], is used for all ENRP and ASAP messages. 181 Most ENRP messages contains a combination of fixed fields and TLV 182 parameters. The TLV parameters are also defined in [11]. 184 All messages, as well as their fields/parameters described below, 185 MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., 186 the most significant byte first). 188 For ENRP, the following message types are defined: 190 Type Message Name 191 ----- ------------------------- 192 0x00 - (reserved by IETF) 193 0x01 - ENRP_PRESENCE 194 0x02 - ENRP_HANDLE_TABLE_REQUEST 195 0x03 - ENRP_HANDLE_TABLE_RESPONSE 196 0x04 - ENRP_HANDLE_UPDATE 197 0x05 - ENRP_LIST_REQUEST 198 0x06 - ENRP_LIST_RESPONSE 199 0x07 - ENRP_INIT_TAKEOVER 200 0x08 - ENRP_INIT_TAKEOVER_ACK 201 0x09 - ENRP_TAKEOVER_SERVER 202 0x0a - ENRP_ERROR 203 0x0b-0xff - (reserved by IETF) 205 2.1. ENRP_PRESENCE message 207 This ENRP message is used to announce (periodically) the presence of 208 an ENRP server, or to probe the status of a peer ENRP sever. 210 0 1 2 3 211 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type = 0x01 |0|0|0|0|0|0|0|R| Message Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Sender Server's ID | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Receiver Server's ID | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 : PE Checksum Param : 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 : Server Information Param (optional) : 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 R (reply_required) flag: 1 bit 226 Set to '1' if the sender requires a response to this message, 227 otherwise set to '0'. 229 Sender Server's ID: 32 bit (unsigned integer) 231 This is the ID of the ENRP server which sends the message. 233 Receiver Server's ID: 32 bit (unsigned integer) 235 This is the ID of the ENRP server to which the message is 236 intended. If the message is not intended to an individual 237 server (e.g., the message is multicasted to a group of 238 servers), this field MUST be set with all 0's. 240 PE Checksum Parameter: 242 This is a TLV that contains the latest PE checksum of the ENRP 243 server who sends the ENRP_PRESENCE. This parameter SHOULD be 244 included for handlespace consistency auditing. See 245 Section 3.11.1 for details. 247 Server Information Parameter: 249 If present, contains the server information of the sender of 250 this message (Server Information Parameter is defined in [11]). 251 This parameter is optional. However, if this message is sent 252 in response to a received "reply required" ENRP_PRESENCE from a 253 peer, the sender then MUST include its server information. 255 Note, at startup an ENRP server MUST pick a randomly generated, non- 256 zero 32-bit unsigned integer as its ID and MUST use this same ID for 257 its entire life. 259 2.2. ENRP_HANDLE_TABLE_REQUEST message 261 An ENRP server sends this message to one of its peers to request a 262 copy of the handlespace data. This message is normally used during 263 server initialization or handlespace re-synchronization. 265 0 1 2 3 266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Sender Server's ID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Receiver Server's ID | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 W (oWn-children-only) flag: 1 bit 277 Set to '1' if the sender of this message is only requesting 278 information about the PEs owned by the message receiver. 279 Otherwise, set to '0'. 281 Sender Server's ID: 283 See Section 2.1. 285 Receiver Server's ID: 287 See Section 2.1. 289 2.3. ENRP_HANDLE_TABLE_RESPONSE message 290 0 1 2 3 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type = 0x03 |0|0|0|0|0|0|M|R| Message Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Sender Server's ID | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Receiver Server's ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 : : 300 : Pool entry #1 (see below) : 301 : : 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 : : 304 : ... : 305 : : 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 : : 308 : Pool entry #n (see below) : 309 : : 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 M (More_to_send) flag: 1 bit 314 Set to '1' if the sender has more pool entries to sent in 315 subsequent ENRP_HANDLE_TABLE_RESPONSE messages, otherwise, set 316 to '0'. 318 R (Reject) flag: 1 bit 320 MUST be set to '1' if the sender of this message is rejecting a 321 handlespace request. In such a case, this message MUST be sent 322 with no pool entries included. 324 Message Length: 16 bits (unsigned integer) 326 Indicates the entire length of the message in number of octets. 328 Note, the value in Message Length field will NOT cover any 329 padding at the end of this message. 331 Sender Server's ID: 333 See Section 2.1. 335 Receiver Server's ID: 337 See Section 2.1. 339 Pool entry #1-#n: 341 If R flag is '0', at least one pool entry SHOULD be present in 342 the message. Each pool entry MUST start with a pool handle 343 parameter as defined in section 3.1.7, followed by one or more 344 pool element parameters, i.e.: 346 +---------------------------+ 347 : Pool handle : 348 +---------------------------+ 349 : PE #1 : 350 +---------------------------+ 351 : PE #2 : 352 +---------------------------+ 353 : ... : 354 +---------------------------+ 355 : PE #n : 356 +---------------------------+ 358 2.4. ENRP_HANDLE_UPDATE message 360 0 1 2 3 361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Sender Server's ID | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Receiver Server's ID | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Update Action | (reserved) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 : Pool handle : 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 : Pool Element : 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Message Length: 16 bits (unsigned integer) 378 Indicates the entire length of the message in number of octets. 380 Note, the value in Message Length field will NOT cover any 381 padding at the end of this message. 383 Update Action: 16 bits (unsigned integer) 385 This field indicates what act is requested to the specified PE. 386 It MUST take one of the following values: 388 0x0 - ADD_PE: add or update the specified PE in the ENRP 389 handlespace 391 0x1 - DEL_PE: delete the specified PE from the ENRP 392 handlespace. 394 Other values are reserved by IETF and MUST not be used. 396 Reserved: 16 bits 398 MUST be set to 0's by sender and ignored by the receiver. 400 Sender Server's ID: 402 See Section 2.1. 404 Receiver Server's ID: 406 See Section 2.1. 408 Pool handle: 410 Specifies to which the PE belongs. 412 Pool Element: 414 Specifies the PE. 416 2.5. ENRP_LIST_REQUEST message 418 This ENRP message is used to request a copy of the current known ENRP 419 peer server list. This message is normally sent from a newly started 420 ENRP server to an existing ENRP server as part of the initialization 421 process of the new server. 423 0 1 2 3 424 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Sender Server's ID | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Receiver Server's ID | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Sender Server's ID: 435 See Section 2.1. 437 Receiver Server's ID: 439 See Section 2.1. 441 2.6. ENRP_LIST_RESPONSE message 443 This message is used to respond an ENRP_LIST_REQUEST. 445 0 1 2 3 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type = 0x06 |0|0|0|0|0|0|0|R| Message Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Sender Server's ID | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Receiver Server's ID | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 : Server Info Param of Peer #1 : 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 : ... : 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 : Server Info Param of Peer #n : 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 R (Reject) flag: 1 bit 463 MUST be set to '1' if the sender of this message is rejecting a 464 peer list request. In such a case, this message MUST be sent 465 with no peer server ID included. 467 Message Length: 16 bits (unsigned integer) 469 Indicates the entire length of the message in number of octets. 471 Note, the value in Message Length field will NOT cover any 472 padding at the end of this message. 474 Sender Server's ID: 476 See Section 2.1. 478 Receiver Server's ID: 480 See Section 2.1. 482 Server Information Parameter of Peer #1-#n: 484 Each contains a Server Information Parameter of a peer known to 485 the sender. The Server Information Parameter is defined in 486 [11]. 488 2.7. ENRP_INIT_TAKEOVER message 490 This message is used by an ENRP server (the takeover initiator) to 491 declare its intention of taking over a specific peer ENRP server. 493 0 1 2 3 494 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type = 0x07 |0|0|0|0|0|0|0|0| Message Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Sender Server's ID | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Receiver Server's ID | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Target Server's ID | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Sender Server's ID: 507 See Section 2.1. 509 Receiver Server's ID: 511 See Section 2.1. 513 Target Server's ID: 515 Contains the 32-bit server ID of the peer ENRP that is the 516 target of this takeover attempt. 518 2.8. ENRP_INIT_TAKEOVER_ACK message 520 This message is used to acknowledge the takeover initiator that the 521 sender of this message received the ENRP_INIT_TAKEOVER message and 522 that it does not object to the takeover. 524 0 1 2 3 525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Sender Server's ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Receiver Server's ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Target Server's ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Sender Server's ID: 538 See Section 2.1. 540 Receiver Server's ID: 542 See Section 2.1. 544 Target Server's ID: 546 Contains the 32-bit server ID of the peer ENRP that is the 547 target of this takeover attempt. 549 2.9. ENRP_TAKEOVER_SERVER message 551 This message is used by the takeover initiator to declare that a 552 takeover is underway. 554 0 1 2 3 555 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Sender Server's ID | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Receiver Server's ID | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Target Server's ID | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Sender Server's ID: 568 See Section 2.1. 570 Receiver Server's ID: 572 See Section 2.1. 574 Target Server's ID: 576 Contains the 32-bit server ID of the peer ENRP that is the 577 target of this takeover operation. 579 2.10. ENRP_ERROR message 581 This message is used by an ENRP server to report an operational error 582 to one of its peers. 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Sender Server's ID | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Receiver Server's ID | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 : Operational Error Parameter : 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Sender Server's ID: 597 See Section 2.1. 599 Receiver Server's ID: 601 See Section 2.1. 603 Operational Error Parameter: 605 This parameter, defined in [11], indicates the type of error(s) 606 being reported. 608 3. ENRP Operation Procedures 610 In this section, we discuss the operation procedures defined by ENRP. 611 An ENRP server MUST following these procedures when sending, 612 receiving, or processing ENRP messages. 614 Many of the Rserpool events call for both server-to-server and PU/ 615 PE-to-server message exchanges. Only the message exchanges and 616 activities between an ENRP server and its peer(s) are considered 617 within the ENRP scope and are defined in this document. 619 Procedures for exchanging messages between a PE/PU and ENRP servers 620 are defined in [1]. 622 3.1. Methods for Communicating amongst ENRP Servers 624 Within an Rserpool operational scope, ENRP servers need to 625 communicate with each other in order to exchange information such as 626 the pool membership changes, handlespace data synchronization, etc. 628 Two types of communications are used amongst ENRP servers: 630 o point-to-point message exchange from one ENPR server to a specific 631 peer server, and 633 o announcements from one server to all its peer servers in the 634 operational scope. 636 Point-to-point communication is always carried out over an SCTP 637 association between the sending server and the receiving server. 639 Announcements are communicated out with one of the following two 640 approaches: 642 1. The sending server sends the announcement message to a well-known 643 RSERPOOL IP multicast channel that its peer servers subscribe to. 645 Note: Because IP multicast is not reliable, this approach does 646 not guarantee that all the peers will receive the announcement 647 message. Moreover, since IP multicast is not secure, this 648 approach cannot provide any security to the communication. 650 2. The sending server sends multiple copies of the announcement, one 651 to each of its peer servers, over a set of point-to-point SCTP 652 associations between the sending server and the peers. 654 This approach guarantees the reliable reception of the message. 655 When needed, data security can be achieved by using IP security 656 mechanisms such as IPsec [10] or TLS [9]. 658 In order to maximize inter-operability of ENRP servers, the following 659 rules MUST be followed: 661 1. At the startup time, a new ENRP server SHOULD make a decision on 662 whether it will enable IP multicast for ENRP announcements. This 663 decision should be based on factors such as the availability of 664 IP multicast and the security requirements from the user of 665 Rserpool. 667 2. If an ENRP server disables multicast, it then: 669 A. MUST NOT subscribe to the well-known server multicast 670 channel, i.e., it only receives peer announcements over SCTP 671 associations, and 673 B. MUST transmit all its out-going announcements over point-to- 674 point SCTP associations with its peers. 676 3. If an ENRP server enables itself to use multicast, it then: 678 A. MUST subscribe to the well-known server multicast channel to 679 ready itself for receiving peers' multicast announcements, 681 B. MUST also be prepared to receive peer announcements over 682 point-to-point SCTP associations from peers. 684 C. MUST track internally which peers are multicast-enabled and 685 which are not. Note: A peer is always assumed to be 686 multicast-disabled until/unless an ENRP message of any type 687 is received from that peer over the well-known server 688 multicast channel. 690 D. when sending out an announcement, MUST send a copy to the 691 well-known server multicast channel AND a copy to each of the 692 peers that are marked as multicast-disabled over a point-to- 693 point SCTP association. 695 3.2. ENRP Server Initialization 697 This section describes the steps a new ENRP server needs to take in 698 order to join the other existing ENRP servers, or to initiate the 699 handlespace service if it is the first ENRP server started in the 700 operational scope. 702 3.2.1. Generate a Server Identifier 704 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 705 as unique as possible in the operational scope and this server Id 706 MUST remain unchanged for the lifetime of the server. Normally, a 707 good 32-bit random number will be good enough as the server Id ([13] 708 provides some information on randomness guidelines). 710 Note, there is a very remote chance (about 1 in 4 billion) that two 711 ENRP servers in an operational scope will generate the same server Id 712 and hence cause a server Id conflict in the pool. However, no severe 713 consequence of such a conflict has been identified. 715 3.2.2. Acquire Peer Server List 717 At startup, the ENRP server (initiating server) will first attempt to 718 learn all existing peer ENRP servers in the same operational scope, 719 or to determine that it is along in the scope. 721 The initiating server uses an existing peer server to bootstrap 722 itself into service. We call this peer server the mentor server. 724 3.2.2.1. Find the mentor server 726 If the initiating server is told about an existing peer server 727 through some administrative means (such as DNS query, configuration 728 database, startup scripts, etc), the initiating server SHOULD then 729 use this peer server as its mentor server and SHOULD skip the 730 remaining steps in this subsection. 732 If multiple existing peer servers are specified, the initiating 733 server SHOULD pick one of them as its mentor peer server, keep the 734 others as its backup mentor peers, and skip the remaining steps in 735 this subsection. 737 If no existing peer server is specified to the initiating server AND 738 if multicast is available in the operational scope, the following 739 mentor peer discovery procedures SHOULD be followed: 741 1. The initiating server SHOULD first join the well-known ENRP 742 server multicast channel. 744 2. Then the initiating server SHOULD send an ENRP_PRESENCE message, 745 with the 'Reply_required' flag set, over the multicast channel. 746 Upon the reception of this ENRP_PRESENCE message, a peer server 747 MUST send an ENRP_PRESENCE, without the 'Reply_required' flag, 748 back to the initiating server. 750 3. When the first response to its original ENRP_PRESENCE arrives, 751 the initiating server SHOULD take the sender of this received 752 response as its mentor peer server. This completes the discovery 753 of the mentor peer server. 755 If responses are also received from other peers (a likely event 756 when multiple peers exist in the operational scope at the time 757 the new server started), the initiating server SHOULD keep a list 758 of those responded as its backup mentor peers (see below). 760 4. If no response to its ENRP_PRESENCE message are received after 761 TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat 762 steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After 763 that, if there is still no response, the initiating server MUST 764 assume that it is alone in the operational scope. 766 5. If the initiating server determined that it is alone in the 767 scope, it MUST skip the procedures in Section 3.2.2.2 and 768 Section 3.2.3 and MUST consider its initialization completed and 769 start offering ENRP services. 771 Note, if multicast is not available (or not allowed for reasons such 772 as security concerns) in the operational scope, at least one peer 773 server MUST be specified to the initiating server through 774 administrative means, unless the initiation server is the first 775 server to start in the operational scope. 777 Note, if the administratively specified mentor peer(s) fails, the 778 initiating server SHOULD use the auto-discover procedure defined in 779 steps 1-5 above. 781 3.2.2.2. Request complete server list from mentor peer 783 Once the initiating server finds its mentor peer server (by either 784 discovery or administrative means), the initiating server MUST send 785 an ENRP_LIST_REQUEST message to the mentor peer server to request a 786 copy of the complete server list maintained by the mentor peer (see 787 Section 3.9 for maintaining server list). 789 The initiating server SHOULD start a timer every time it finishes 790 sending an ENRP_LIST_REQUEST message. If the timer expires before 791 receiving a response from the mentor peer, the initiating server 792 SHOULD abort and send a new server list request to a backup mentor 793 peer, if one is available. 795 Upon the reception of this request, the mentor peer server SHOULD 796 reply with an ENRP_LIST_RESPONSE message and include in the message 797 body all existing ENRP servers known by the mentor peer. 799 Upon the reception of the ENRP_LIST_RESPONSE message from the mentor 800 peer, the initiating server MUST use the server information carried 801 in the message to initialize its own peer list. 803 However, if the mentor itself is in the process of startup and not 804 ready to provide a peer server list (for example, the mentor peer is 805 waiting for a response to its own ENRP_LIST_REQUEST to another 806 server), it MUST reject the request by the initiating server and 807 respond with an ENRP_LIST_RESPONSE message with the R flag set to 808 '1', and with no server information included in the response. 810 In the case where its ENRP_LIST_REQUEST is rejected by the mentor 811 peer, the initiating server SHOULD either wait for a few seconds and 812 re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a 813 backup mentor peer available, select another mentor peer server and 814 send the ENRP_LIST_REQUEST to the new mentor server. 816 3.2.3. Download ENRP Handlespace Data from Mentor Peer 818 After a peer list download is completed, the initiating server MUST 819 request a copy of the current handlespace data from its mentor peer 820 server, by taking the following steps: 822 1. The initiating server MUST first send a ENRP_HANDLE_TABLE_REQUEST 823 message to the mentor peer, with W flag set to '0', indicating 824 that the entire handlespace is requested. 826 2. Upon the reception of this message, the mentor peer MUST start a 827 download session in which a copy of the current handlespace data 828 maintained by the mentor peer is sent to the initiating server in 829 one or more ENRP_HANDLE_TABLE_RESPONSE messages (Note, the mentor 830 server may find it particularly desirable to use multiple 831 ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when 832 the handlespace is large, especially when forming and sending out 833 a single response containing a large handlespace may interrupt 834 its other services). 836 If more than one ENRP_HANDLE_TABLE_RESPONSE message are used 837 during the download, the mentor peer MUST use the M flag in each 838 ENRP_HANDLE_TABLE_RESPONSE message to indicate whether this 839 message is the last one for the download session. In particular, 840 the mentor peer MUST set the M flag to '1' in the outbound 841 ENRP_HANDLE_TABLE_RESPONSE if there is more data to be 842 transferred and MUST keep track of the progress of the current 843 download session. The mentor peer MUST set the M flag to '0' in 844 the last ENRP_HANDLE_TABLE_RESPONSE for the download session and 845 close the download session (i.e., removing any internal record of 846 the session) after sending out the last message. 848 3. During the downloading, every time the initiating server receives 849 an ENRP_HANDLE_TABLE_RESPONSE message, it MUST transfer the data 850 entries carried in the message into its local handlespace 851 database, and then check whether or not this message is the last 852 one for the download session. 854 If the M flag is set to '1' in the just processed 855 ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST 856 send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer 857 to request for the next ENRP_HANDLE_TABLE_RESPONSE message. 859 4. When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE 860 message into its local handlespace database, the initiating 861 server MUST handle each pool entry carried in the message using 862 the following rules: 864 A. If the pool does not exist in the local handlespace, the 865 initiating server MUST creates the pool in the local 866 handlespace and add the PE(s) in the pool entry to the pool. 868 When creating the pool, the initiation server MUST set the 869 overall member selection policy type of the pool to the 870 policy type indicated in the first PE. 872 B. If the pool already exists in the local handlespace, but the 873 PE(s) in the pool entry is not currently a member of the 874 pool, the initiating server MUST add the PE(s) to the pool. 876 C. If the pool already exists in the local handlespace AND the 877 PE(s) in the Pool entry is already a member of the pool, the 878 initiating server SHOULD replace the attributes of the 879 existing PE(s) with the new information. 881 5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from 882 the mentor peer and unpacked into the local handlespace, the 883 initialization process is completed and the initiating server 884 SHOULD start to provide ENRP services. 886 Under certain circumstances, the mentor peer itself may not be able 887 to provide a handlespace download to the initiating server. For 888 example, the mentor peer is in the middle of initializing its own 889 handlespace database, or it has currently too many download sessions 890 open to other servers. 892 In such a case, the mentor peer MUST reject the request by the 893 initiating server and respond with an ENRP_HANDLE_TABLE_RESPONSE 894 message with the R flag set to '1', and with no pool entries included 895 in the response. 897 In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the 898 mentor peer, the initiating server SHOULD either wait for a few 899 seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor 900 server, or if there is a backup mentor peer available, select another 901 mentor peer server and send the ENRP_HANDLE_TABLE_REQUEST to the new 902 mentor server. 904 A started handlespace download session may get interrupted for some 905 reason. To cope with this, the initiating server SHOULD start a 906 timer every time it finishes sending an ENRP_HANDLE_TABLE_REQUEST to 907 its mentor peer. If this timer expires without receiving a response 908 from the mentor peer, the initiating server SHOULD abort the current 909 download session and re-start a new handlespace download with a 910 backup mentor peer, if one is available. 912 Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, if the 913 mentor peer has still more data to send, it SHOULD start a session 914 timer. If this timer expires without receiving another request from 915 the initiating server, the mentor peer SHOULD abort the session, 916 cleaning out any resource and record of the session. 918 3.3. Handle PE Registration 920 To register itself with the handlespace, a PE sends an 921 ASAP_REGISTRATION message to its home ENRP server. The format of 922 ASAP_REGISTRATION message and rules of sending it are defined in [1]. 924 In the ASAP_REGISTRATION message, the PE indicates the handle of the 925 pool it wishes to join in a pool handle parameter, and its complete 926 transport information and any load control information in a PE 927 parameter. 929 The ENRP server handles the ASAP_REGISTRATION message according to 930 the following rules: 932 1. If the named pool does not exist in the handlespace, the ENRP 933 server MUST creates a new pool with that handle in the 934 handlespace and add the PE to the pool as its first PE; 936 When a new pool is created, the overall member selection policy 937 of the pool MUST be set to the policy type indicated by the first 938 PE, the overall pool transport type MUST be set to the transport 939 type indicated by the PE, and the overall pool data/control 940 channel configuration MUST be set to what is indicated in the 941 Transport Use field of the User Transport parameter by the 942 registering PE. 944 2. If the named pool already exists in the handlespace, but the 945 requesting PE is not currently a member of the pool, the ENRP 946 server will add the PE as a new member to the pool; 948 However, before adding the PE to the pool, the server MUST check 949 if the policy type, transport type, and transport usage indicated 950 by the registering PE is consistent with those of the pool. If 951 different, the ENRP server MUST reject the registration. 953 3. If the named pool already exists in the handlespace AND the 954 requesting PE is already a member of the pool, the ENRP server 955 SHOULD consider this as a re-registration case. The ENRP server 956 MUST perform the same tests on policy, transport type, transport 957 use, as described above. If the re-registration is accepted 958 after the test, the ENRP Server SHOULD replace the attributes of 959 the existing PE with the information carried in the received 960 ASAP_REGISTRATION message. 962 4. After accepting the registration, the ENRP server MUST assign 963 itself the owner of this PE. If this is a re-registration, the 964 ENRP server MUST take over ownership of this PE regardless of 965 whether the PE was previously owned by this server or by another 966 server. The ENRP server MUST also record the SCTP transport 967 address from which it received the ASAP_REGISTRATION in the ASAP 968 Transport parameter TLV inside the PE parameter of this PE. 970 5. The ENRP server may reject the registration due to other reasons 971 such as invalid values, lack of resource, authentication failure, 972 etc. 974 In all above cases, the ENRP server MUST reply to the requesting PE 975 with an ASAP_REGISTRATION_RESPONSE message. If the registration is 976 accepted, the ENRP server MUST set the 'R' flag in the 977 ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, 978 the ENRP server MUST indicate the rejection by setting the 'R' flag 979 in the ASAP_REGISTRATION_RESPONSE to '1'. 981 If the registration is rejected, the ENRP server SHOULD include the 982 proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message. 984 If the registration is granted (either a new registration or a re- 985 registration case), the ENRP server MUST assign itself to be the home 986 ENRP server of the PE, i.e., to "own" the PE. 988 Implementation note: for better performance, the ENRP server may 989 find it both efficient and convenient to internally maintain two 990 separate PE lists or tables - one is for the PEs that are "owned" 991 by the ENRP server and the other for all the PEs owned by its 992 peer(s). 994 Moreover, if the registration is granted, the ENRP server MUST take 995 the handlespace update action as described in Section 3.6 to inform 996 its peers about the change just made. If the registration is denied, 997 no message will be sent to its peers. 999 3.3.1. Rules on PE Re-registration 1001 A PE may re-register itself to the handlespace with a new set of 1002 attributes in order to, for example, extend its registration life, 1003 change its load factor value, etc. 1005 A PE may modify its load factor value at any time via re- 1006 registration. Based on the number of PEs in the pool and the pool's 1007 overall policy type, this operation allows the PE to dynamically 1008 control its share of inbound messages received by the pool (also see 1009 Section ???? in [1] for more on load control). 1011 Moreover, when re-registering, the PE MUST NOT change its policy 1012 type. The server MUST reject the re-registration if the PE attempt 1013 to change its policy type. In the rejection, the server SHOULD 1014 attach an error code "Pooling Policy Inconsistent". 1016 Regardless whether it is the current owner of the PE, if the re- 1017 registration is granted to the PE, the ENRP server MUST assign itself 1018 to be the new home ENRP server of the PE. 1020 Moreover, if the re-registration is granted, the ENRP server MUST 1021 take the handlespace update action as described in Section 3.6 to 1022 inform its peers about the change just made. If the re-registration 1023 is denied, no message will be sent to its peers. 1025 3.4. Handle PE De-registration 1027 To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION 1028 message to its home ENRP server. The complete format of 1029 ASAP_DEREGISTRATION message and rules of sending it are defined in 1030 [1]. 1032 In the ASAP_DEREGISTRATION message the PE indicates the handle of the 1033 pool it belongs to in a pool handle parameter and provides its PE 1034 identifier. 1036 Upon receiving the message, the ENRP server SHALL remove the PE from 1037 its handlespace. Moreover, if the PE is the last one of the named 1038 pool, the ENRP server will remove the pool from the handlespace as 1039 well. 1041 If the ENRP server fails to find any record of the PE in its 1042 handlespace, it SHOULD consider the de-registration granted and 1043 completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the 1044 PE. 1046 The ENRP server may reject the de-registration request for various 1047 reasons, such as invalid parameters, authentication failure, etc. 1049 In response, the ENRP server MUST send an 1050 ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de- 1051 registration is rejected, the ENRP server MUST indicate the rejection 1052 by including the proper Operational Error parameter. 1054 It should be noted that de-registration does not stop the PE from 1055 sending or receiving application messages. 1057 Once the de-registration request is granted AND the PE removed from 1058 its local copy of the handlespace, the ENRP server MUST take the 1059 handlespace update action described in Section 3.6 to inform its 1060 peers about the change just made. Otherwise, NO message SHALL be 1061 send to its peers. 1063 3.5. Pool Handle Translation 1065 A PU uses the pool handle translation service of an ENRP server to 1066 resolve a pool handle to a list of accessible transport addresses of 1067 the member PEs of the pool. 1069 This requires the PU to send an ASAP_HANDLE_RESOLUTION message to its 1070 home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify 1071 the pool handle to be translated in a Pool Handle parameter. 1072 Complete definition of the ASAP_HANDLE_RESOLUTION message and the 1073 rules of sending it are defined in [1]. 1075 An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION 1076 requests from PUs either over an SCTP association on the well-know 1077 SCTP port, or over a TCP connection on the well-know TCP port. 1079 Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server 1080 MUST first look up the pool handle in its handlespace. If the pool 1081 exits, the home ENRP server MUST compose and send back an 1082 ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU. 1084 In the response message, the ENRP server SHOULD list all the PEs 1085 currently registered in this pool, in a list of PE parameters. The 1086 ENRP server MUST also include a pool member selection policy 1087 parameter to indicate the overall member selection policy for the 1088 pool, if the current pool member selection policy is not round-robin 1089 (if the overall policy is round-Robin, this parameter MAY be 1090 omitted?). 1092 If the named pool does not exist in the handlespace, the ENRP server 1093 MUST reject the handle resolution request by responding with an 1094 ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor 1095 Handle error. 1097 The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and 1098 the rules of receiving it are defined in [1]. 1100 3.6. Server Handlespace Update 1102 This includes a set of update operations used by an ENRP server to 1103 inform its peers when its local handlespace is modified, e.g., 1104 addition of a new PE, removal of an existing PE, change of pool or PE 1105 properties. 1107 3.6.1. Announcing Addition or Update of PE 1109 When a new PE is granted registration to the handlespace or an 1110 existing PE is granted a re-registration, the home ENRP server uses 1111 this procedure to inform all its peers. 1113 This is an ENRP announcement and is sent to all the peer of the home 1114 ENRP server. See Section 3.1 on how announcements are sent. 1116 An ENRP server MUST announce this update to all its peers in a 1117 ENRP_HANDLE_UPDATE message with the Update Action field set to 1118 ADD_PE, indicating the addition of a new PE or the modification of an 1119 existing PE. The complete new information of the PE and the pool its 1120 belongs to MUST be indicated in the message with a PE parameter and a 1121 Pool Handle parameter, respectively. 1123 The home ENRP server SHOULD fill in its server Id in the Sender 1124 Server's ID field and leave the Receiver Server's ID blank (i.e., all 1125 0's). 1127 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take 1128 the following actions: 1130 1. If the named pool indicated by the pool handle does not exist in 1131 its local copy of the handlespace, the peer MUST create the named 1132 pool in its local handlespace and add the PE to the pool as the 1133 first PE. It MUST then copy in all other attributes of the PE 1134 carried in the message. 1136 When the new pool is created, the overall member selection policy 1137 of the pool MUST be set to the policy type indicated by the PE. 1139 2. If the named pool already exists in the peer's local copy of the 1140 handlespace AND the PE does not exist, the peer MUST add the PE 1141 to the pool as a new PE and copy in all attributes of the PE 1142 carried in the message. 1144 3. If the named pool exists AND the PE is already a member of the 1145 pool, the peer MUST replace the attributes of the PE with the new 1146 information carried in the message. 1148 3.6.2. Announcing Removal of PE 1150 When an existing PE is granted de-registration or is removed from its 1151 handlespace for some other reasons (e.g., purging an unreachable PE, 1152 see Section 3.7), the ENRP server MUST uses this procedure to inform 1153 all its peers about the change just made. 1155 This is an ENRP announcement and is sent to all the peer of the home 1156 ENRP server. See Section 3.1 on how announcements are sent. 1158 An ENRP server MUST announce the PE removal to all its peers in an 1159 ENRP_HANDLE_UPDATE message with the Update Action field set to 1160 DEL_PE, indicating the removal of an existing PE. The complete 1161 information of the PE and the pool its belongs to MUST be indicated 1162 in the message with a PE parameter and a Pool Handle parameter, 1163 respectively. 1165 [editor's note: only the pool handle and the PE's id are needed, it 1166 should reduce the size of the message] 1168 The sending server MUST fill in its server ID in the Sender Server's 1169 ID field and leave the Receiver Server's ID blank (i.e., set to all 1170 0's). 1172 When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first 1173 find pool and the PE in its own handlespace, and then remove the PE 1174 from its local handlespace. If the removed PE is the last one in the 1175 pool, the peer MUST also delete the pool from its local handlespace. 1177 If the peer fails to find the PE or the pool in its handlespace, it 1178 SHOULD take no further actions. 1180 3.7. Detecting and Removing Unreachable PE 1182 Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 1183 Notification, see section 10.2 of [8]), the PU SHOULD send an 1184 ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The 1185 message SHOULD contain the pool handle and the PE Id of the 1186 unreachable PE. 1188 Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server 1189 MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE 1190 message to the PE in question (the 'H' flag in the message SHOULD be 1191 set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails 1192 (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP 1193 server MUST consider the PE as truly unreachable and MUST remove the 1194 PE from its handlespace and take actions described in Section 3.6.2. 1196 If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully 1197 to the PE, the ENRP server MUST retain the PE in its handlespace. 1198 Moreover, the server SHOULD keep a counter to record how many 1199 ASAP_ENDPOINT_UNREACHABLE messages it has received reporting 1200 reachability problem relating to this PE. If the counter exceeds the 1201 protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove 1202 the PE from its handlespace and take actions described in 1203 Section 3.6.2. 1205 Optionally, an ENRP server may also periodically send point-to-point 1206 ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each 1207 of the PEs owned by the ENRP server in order to check their 1208 reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE 1209 fails, the ENRP server MUST consider the PE as unreachable and MUST 1210 remove the PE from its handlespace and take actions described in 1211 Section 3.6.2. Note, if an ENRP server owns a large number of PEs, 1212 the implementation should pay attention not to flood the network with 1213 bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the 1214 implementation should try to smooth out the ASAP_ENDPOINT_KEEP_ALIVE 1215 message traffic over time. 1217 The complete definition and rules of sending 1218 ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE 1219 messages are described in [1]. 1221 3.8. Helping PE and PU to Discover Home ENRP Server 1223 At its startup time, or whenever its current home ENRP server is not 1224 providing services, a PE or PU will attempt to find a new home 1225 server. For this reason, the PE or PU will need to maintain a list 1226 of currently available ENRP servers in its scope. 1228 To help the PE or PU maintaining this list, an ENRP server, if it is 1229 enabled for multicast, SHOULD periodically send out an 1230 ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to 1231 the well-known ASAP multicast channel. And in the 1232 ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the 1233 transport addresses available for ASAP communications. If the ENRP 1234 server only supports SCTP for ASAP communications, the transport 1235 information MAY be omitted in the ASAP_SERVER_ANNOUNCE message. 1237 For the complete procedure of this, see Section 3.6?? in [1]. 1239 3.9. Maintaining Peer List and Monitoring Peer Status 1241 An ENRP server MUST keep an internal record on the status of each of 1242 its known peers. This record is referred to as the server's "peer 1243 list" 1245 3.9.1. Discovering New Peer 1247 If a message of any type is received from a previously unknown peer, 1248 the ENRP server MUST consider this peer a new peer in the operational 1249 scope and add it to the peer list. 1251 The ENRP server MUST send an ENRP_PRESENCE message with the Reply- 1252 required flag set to '1' to the source address found in the arrived 1253 message. This will force the new peer to reply with its own 1254 ENRP_PRESENCE containing its full server information (see 1255 Section 2.1). 1257 [editor's note: should we ask for a peer list from the new peer? this 1258 may help mending two split networks.] 1260 3.9.2. Server Sending Heartbeat 1262 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 1263 continued presence to all its peer with a ENRP_PRESENCE message. In 1264 the ENRP_PRESENCE message, the ENRP server MUST set the 1265 'Replay_required' flag to '0', indicating that no response is 1266 required. 1268 The arrival of this periodic ENRP_PRESENCE message will cause all its 1269 peers to update their internal variable "peer.last.heard" for the 1270 sending server (see Section 3.9.3 for more details). 1272 3.9.3. Detecting Peer Server Failure 1274 An ENRP server MUST keep an internal variable "peer.last.heard" for 1275 each of its known peers and the value of this variable MUST be 1276 updated to the current local time every time a message of any type 1277 (point-to-point or announcement) is received from the corresponding 1278 peer. 1280 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 1281 seconds, the ENRP server MUST immediately send a point-to-point 1282 ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1284 If the send fails or the peer does not reply after MAX-TIME-NO- 1285 RESPONSE seconds, the ENRP server MUST consider the peer server dead 1286 and SHOULD initiate the takeover procedure defined in Section 3.10. 1288 3.10. Taking-over a Failed Peer Server 1290 In the following descriptions, We call the ENRP server that detects 1291 the failed peer server and initiates the take-over the "initiating 1292 server" and the failed peer server the "target server." 1294 3.10.1. Initiate Server Take-over Arbitration 1296 The initiating server SHOULD first start a take-over arbitration 1297 process by announcing an ENRP_INIT_TAKEOVER message to all its peer 1298 servers. See Section 3.1 on how announcements are sent. In the 1299 message, the initiating server MUST fill in the Sender Server's ID 1300 and Target Server's ID. 1302 After announcing the ENRP_INIT_TAKEOVER message, the initiating 1303 server SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from _each_ 1304 of its known peers, except of the target server. [editor's note: how 1305 long should it wait?] 1307 Each of the peer servers that receives the ENRP_INIT_TAKEOVER message 1308 from the initiating server SHOULD take the following actions: 1310 1. If the peer server finds that itself is the target server 1311 indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately 1312 announce an ENRP_PRESENCE message to all its peer ENRP servers in 1313 an attempt to stop this take-over process. This indicates a 1314 false failure detection case by the initiating server. 1316 2. If the peer server finds that itself has already started its own 1317 take-over arbitration process on the same target server, it MUST 1318 perform the following arbitration: 1320 A. if the peer's server ID is smaller in value than the Sender 1321 Server's ID in the arrived ENRP_INIT_TAKEOVER message, the 1322 peer server SHOULD immediately abort its own take-over 1323 attempt. Moreover, the peer SHOULD mark the target server as 1324 "not active" on its internal peer list so that its status 1325 will no longer be monitored by the peer, and reply the 1326 initiating server with an ENRP_INIT_TAKEOVER_ACK message. 1328 B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER 1329 message and take no action. 1331 3. If the peer finds that it is neither the target server nor is in 1332 its own take-over process, the peer SHOULD: a) mark the target 1333 server as "not active" on its internal peer list so that its 1334 status will no longer be monitored by this peer, and b) reply to 1335 the initiating server with an ENRP_INIT_TAKEOVER_ACK message. 1337 Once the initiating server has received ENRP_INIT_TAKEOVER_ACK 1338 message from _all_ of its currently known peers (except for the 1339 target server), it SHOULD consider that it has won the arbitration 1340 and SHOULD proceed to complete the take-over, following the steps 1341 described in Section 3.10.2. 1343 However, if it receives an ENRP_PRESENCE from the target server at 1344 any point in the arbitration process, the initiating server SHOULD 1345 immediately abort the take-over process and mark the status of the 1346 target server as "active". 1348 3.10.2. Take-over Target Peer Server 1350 The initiating ENRP server SHOULD first send, via an announcement, a 1351 ENRP_TAKEOVER_SERVER message to inform all its active peers that the 1352 take-over is enforced. The target server's ID MUST be filled in the 1353 message. The initiating server SHOULD then remove the target server 1354 from its internal peer list. 1356 Then it SHOULD examine its local copy of the handlespace and claim 1357 ownership of each of the PEs originally owned by the target server, 1358 by following these steps: 1360 1. mark itself as the home ENRP server of each of the PEs originally 1361 owned by the target server; 1363 2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message, with the 1364 'H' flag set to '1', to each of the PEs. This will trigger the 1365 PE to adopt the initiating sever as its new home ENRP server; 1367 When a peer receives the ENRP_TAKEOVER_SERVER message from the 1368 initiating server, it SHOULD update its local peer list and PE cache 1369 by following these steps: 1371 1. remove the target server from its internal peer list; 1373 2. update the home ENRP server of each PE in its local copy of the 1374 handlespace to be the sender of the message, i.e., the initiating 1375 server. 1377 3.11. Handlespace Data Auditing and Re-synchronization 1379 Message losses or certain temporary breaks in network connectivity 1380 may result in data inconsistency in the local handlespace copy of 1381 some of the ENRP servers in an operational scope. Therefore, each 1382 ENRP server in the operational scope SHOULD periodically verify that 1383 its local copy of handlespace data is still in sync with that of its 1384 peers. 1386 This section defines the auditing and re-synchronization procedures 1387 for an ENRP server to maintain its handlespace data consistency. 1389 3.11.1. Auditing Procedures 1391 The auditing of handlespace consistency is based on the following 1392 procedures: 1394 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1395 integer internal variable) for each of its known peers and for 1396 itself. For an ENRP server with 'k' known peers, we denote these 1397 internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ..., 1398 "pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE 1399 checksum. The definition and detailed algorithm for calculating 1400 these PE checksum variables are given in Section 3.11.2. 1402 2. Each time an ENRP server sends out an ENRP_PRESENCE, it SHOULD 1403 include in the message its current PE checksum (i.e., 1404 "pe.checksum.pr0"). 1406 3. When an ENRP server (server A) receives a PE checksum (carried in 1407 an arrived ENRP_PRESENCE) from a peer ENRP server (server B), 1408 server A SHOULD compare the PE checksum found in the 1409 ENRP_PRESENCE with its own internal PE checksum of server B 1410 (i.e., "pe.checksum.prB"). 1412 4. If the two values match, server A will consider that there is no 1413 handlespace inconsistency between itself and server B and should 1414 take no further actions. 1416 5. If the two values do NOT match, server A SHOULD consider that 1417 there is a handlespace inconsistency between itself and server B 1418 and a re-synchronization process SHOULD be carried out 1419 immediately with server B (see Section 3.11.3). 1421 3.11.2. PE Checksum Calculation Algorithm 1423 When an ENRP server (server A) calculate an internal PE checksum for 1424 a peer (server B), it MUST use the following algorithm. 1426 Let us assume that in server A's internal handlespace there are 1427 currently 'M' PEs that are owned by server B. Each of the 'M' PEs 1428 will then contribute to the checksum calculation with the following 1429 byte block: 1431 0 1 2 3 1432 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 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 : Pool handle string of the pool the PE belongs (padded with : 1435 : zeros to next 32-bit word boundary if needed) : 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | PE Id (4 octets) | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 Note, these are not TLVs. This byte block gives each PE a unique 1441 byte pattern in the scope. The 16-bit PE checksum for server B 1442 "pe.checksum.prB" is then calculated over the byte blocks contributed 1443 by the 'M' PEs one by one. The PE checksum calculation MUST use the 1444 Internet algorithm described in [4]. 1446 Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") 1447 in the same fashion, using the byte blocks of all the PEs owned by 1448 itself. 1450 Note, whenever an ENRP finds that its internal handlespace has 1451 changed (e.g., due to PE registration/deregistration, receiving peer 1452 updates, removing failed PEs, downloading handlespace pieces from a 1453 peer, etc.), it MUST immediately update all its internal PE checksums 1454 that are affected by the change. 1456 Implementation Note: when the internal handlespace changes (e.g., a 1457 new PE added or an existing PE removed), an implementation needs not 1458 to re-calculate the affected PE checksum; it should instead simply 1459 update the checksum by adding or subtracting the byte block of the 1460 corresponding PE from the previous checksum value. 1462 3.11.3. Re-synchronization Procedures 1464 Once an ENRP server determines that there is inconsistency between 1465 its local handlespace data and a peer's handlespace data with 1466 regarding to the PEs owned by that peer, it SHOULD perform the 1467 following steps to re-synchronize the data: 1469 1. The ENRP server SHOULD first "mark" every PE it knows about that 1470 is owned by the peer in its local handlespace database; 1472 2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST 1473 message with W flag set to '1' to the peer to request a complete 1474 list of PEs owned by the peer; 1476 3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with W 1477 flag set to '1', the peer server SHOULD immediately respond with 1478 an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently 1479 owned by the peer. 1481 4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the 1482 ENRP server SHOULD transfer the PE entries carried in the message 1483 into its local handlespace database. If an PE entry being 1484 transferred already exists in its local database, the ENRP server 1485 MUST replace the entry with the copy found in the message and 1486 remove the "mark" from the entry. 1488 5. After transferring all the PE entries from the received 1489 ENRP_HANDLE_TABLE_RESPONSE message into its local database, the 1490 ENRP server SHOULD check whether there are still PE entries that 1491 remain "marked" in its local handlespace. If so, the ENRP server 1492 SHOULD silently remove those "marked" entries. 1494 Note, similar to what is described in Section 3.2.3, the peer may 1495 reject the ENRP_HANDLE_TABLE_REQUEST or use more than one 1496 ENRP_HANDLE_TABLE_RESPONSE message to respond. 1498 3.12. Handling Unrecognized Message or Unrecognized Parameter 1500 When an ENRP server receives an ENRP message with an unknown message 1501 type or a message of known type that contains an unknown parameter, 1502 it SHOULD handle the unknown message or the unknown parameter 1503 according to the unrecognized message and parameter handling rules 1504 defined in Sections 3 and 4 in [11]. 1506 According to the rules, if an error report to the message sender is 1507 needed, the ENRP server that discovered the error SHOULD send back an 1508 ENRP_ERROR message with proper error cause code. 1510 4. Variables and Thresholds 1512 4.1. Variables 1514 peer.last.heard - the local time that a peer server was last heard 1515 (via receiving either a multicast or point-to-point message from 1516 the peer). 1518 pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server 1519 keeps for a peer. A separate PE checksum is kept for each of its 1520 known peers as well as for itself. 1522 4.2. Thresholds 1524 MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender 1525 will make to contact an ENRP server (Default=3 times). 1527 TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will 1528 wait for a response from an ENRP server (Default=5 seconds). 1530 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1531 heartbeat message to all its known peers. (Default=30 secs.) 1533 SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a 1534 SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) 1536 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1537 will wait before considering a silent peer server potentially 1538 dead. (Default=61 secs.) 1540 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1541 sender will wait for a response after sending out a message. 1542 (Default=5 secs.) 1544 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on 1545 a PE that an ENRP server will allow before purging this PE from 1546 the handlespace. (Default=3) 1548 5. Security Considerations 1550 Threats Introduced by Rserpool and Requirements for Security in 1551 Response to Threats [12] describes the threats to the Rserpool 1552 architecture in detail and lists the security requirements in 1553 response to each threat. From the threats described in this 1554 document, the security services required for the Rserpool protocol 1555 are enumerated below. 1557 Threat 1) PE registration/deregistration flooding or spoofing 1558 ----------- 1559 Security mechanism in response: ENRP server authenticates the PE 1561 Threat 2) PE registers with a malicious ENRP server 1562 ----------- 1563 Security mechanism in response: PE authenticates the ENRP server 1565 Threat 1 and 2 taken together results in mutual authentication of the 1566 ENRP server and the PE. 1568 Threat 3) Malicious ENRP server joins the ENRP server pool 1569 ----------- 1570 Security mechanism in response: ENRP servers mutually authenticate 1572 Threat 4) A PU communicates with a malicious ENRP server for handle 1573 resolution 1574 ----------- 1575 Security mechanism in response: The PU authenticates the ENRP server 1577 Threat 5) Replay attack 1578 ----------- 1579 Security mechanism in response: Security protocol which has 1580 protection from replay attacks 1582 Threat 6) Corrupted data which causes a PU to have misinformation 1583 concerning a pool handle resolution 1584 ----------- 1585 Security mechanism in response: Security protocol which supports 1586 integrity protection 1588 Threat 7) Eavesdropper snooping on handlespace information 1589 ----------- 1590 Security mechanism in response: Security protocol which supports data 1591 confidentiality 1593 Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to 1594 ENRP server 1595 ----------- 1596 Security mechanism in response: ASAP must control the number of ASAP 1597 endpoint unreachable messages transmitted from the PU to the ENRP 1598 server. 1600 Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from 1601 the ENRP server 1602 ----------- 1603 Security mechanism in response: ENRP server must control the number 1604 of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE 1606 To summarize the threats 1-7 require security mechanisms which 1607 support authentication, integrity, data confidentiality, protection 1608 from replay attacks. 1610 For Rserpool we need to authenticate the following: 1612 PU <---- ENRP Server (PU authenticates the ENRP server) 1613 PE <----> ENRP Server (mutual authentication) 1614 ENRP server <-----> ENRP Server (mutual authentication) 1616 We do not define any new security mechanisms specifically for 1617 responding to threats 1-7. Rather we use existing IETF security 1618 protocols to provide the security services required. TLS supports 1619 all these requirements and MUST be implemented. The 1620 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a 1621 minimum by implementers of TLS for Rserpool. For purposes of 1622 backwards compatibility, ENRP SHOULD support 1623 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 1624 other ciphersuite. 1626 Threat 8 requires the ASAP protocol to limit the number of 1627 ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [1]) to the 1628 ENRP server. 1630 Threat 9 requires the ENRP protocol to limit the number of 1631 ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see 1632 Section Section 3.7). 1634 5.1. Chain of trust 1636 Security is mandatory to implement in Rserpool and is based on TLS 1637 implementation in all three architecture components that comprise 1638 Rserpool -- namely PU, PE and ENRP server. We define an ENRP server 1639 that uses TLS for all communication and authenticates ENRP peers and 1640 PE registrants to be a secured ENRP server. 1642 Here is a description of all possible data paths and a description of 1643 the security. 1645 PU <---> secured ENRP Server (authentication of ENRP server; 1646 queries over TLS) 1647 PE <---> secured ENRP server (mutual authentication; 1648 registration/deregistration over TLS) 1649 secured ENRP <---> secured ENRP server (mutual authentication; 1650 database updates using TLS) 1652 If all components of the system authenticate and communicate using 1653 TLS, the chain of trust is sound. The root of the trust chain is the 1654 ENRP server. If that is secured using TLS, then security will be 1655 enforced for all ENRP and PE components that try to connect to it. 1657 Summary of interaction between secured and unsecured components: If 1658 the PE does not use TLS and tries to register with a secure ENRP 1659 server, it will receive an error message response indicated as error 1660 due to security considerations and the registration will be rejected. 1661 If an ENRP server which does not use TLS tries to update the database 1662 of a secure ENRP server, then the update will be rejected. If an PU 1663 does not use TLS and communicates with a secure ENRP server, it will 1664 get a response with the understanding that the response is not secure 1665 as the response can be tampered with in transit even if the ENRP 1666 database is secured. 1668 The final case is the PU sending a secure request to ENRP. It might 1669 be that ENRP and PEs are not secured and this is an allowable 1670 configuration. The intent is to secure the communication over the 1671 Internet between the PU and the ENRP server. 1673 Summary: 1675 Rserpool architecture components can communicate with each other to 1676 establish a chain of trust. Secured PE and ENRP servers reject any 1677 communications with unsecured ENRP or PE servers. 1679 If the above is enforced, then a chain of trust is established for 1680 the Rserpool user. 1682 5.2. Implementing Security Mechanisms 1684 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must 1685 support mutual authentication. ENRP servers must support mutual 1686 authentication among themselves. PUs MUST authenticate ENRP servers. 1688 ENRP servers and PEs SHOULD possess a site certificate whose subject 1689 corresponds to their canonical hostname. PUs MAY have certificates 1690 of their own for mutual authentication with TLS, but no provisions 1691 are set forth in this document for their use. All Rserpool elements 1692 that support TLS MUST have a mechanism for validating certificates 1693 received during TLS negotiation; this entails possession of one or 1694 more root certificates issued by certificate authorities (preferably 1695 well-known distributors of site certificates comparable to those that 1696 issue root certificates for web browsers). 1698 Implementations MUST support TLS with SCTP as described in RFC3436 1699 [9] or TLS over TCP as described in RFC2246 [7]. When using TLS/SCTP 1700 we must ensure that RSerPool does not use any features of SCTP that 1701 are not available to an TLS/SCTP user. This is not a difficult 1702 technical problem, but simply a requirement. When describing an API 1703 of the RSerPool lower layer we have also to take into account the 1704 differences between TLS and SCTP. 1706 6. Acknowledgements 1708 The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, 1709 Thomas Dreibholz, and many others for their invaluable comments and 1710 feedback. 1712 7. References 1714 7.1. Normative References 1716 [1] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 1717 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-12 1718 (work in progress), July 2005. 1720 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1721 J., and M. Stillman, "Requirements for Reliable Server 1722 Pooling", RFC 3237, January 2002. 1724 [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and 1725 A. Silverton, "Architecture for Reliable Server Pooling", 1726 draft-ietf-rserpool-arch-10 (work in progress), July 2005. 1728 [4] Braden, R., Borman, D., and C. Partridge, "Computing the 1729 Internet Checksum", RFC 1071, September 1988. 1731 [5] Bradner, S., "The Internet Standards Process -- Revision 3", 1732 BCP 9, RFC 2026, October 1996. 1734 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1735 Levels", BCP 14, RFC 2119, March 1997. 1737 [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1738 RFC 2246, January 1999. 1740 [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1741 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 1742 Paxson, "Stream Control Transmission Protocol", RFC 2960, 1743 October 2000. 1745 [9] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP", 1746 RFC 3436, December 2002. 1748 [10] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On 1749 the Use of Stream Control Transmission Protocol (SCTP) with 1750 IPsec", RFC 3554, July 2003. 1752 [11] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 1753 Server Access Protocol (ASAP) and Endpoint Handlespace 1754 Redundancy Protocol (ENRP) Parameters", 1755 draft-ietf-rserpool-common-param-09 (work in progress), 1756 July 2005. 1758 [12] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M. 1759 Holdrege, "Threats Introduced by Rserpool and Requirements for 1760 Security in Response to Threats", 1761 draft-ietf-rserpool-threats-05 (work in progress), July 2005. 1763 7.2. Informative References 1765 [13] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1766 Recommendations for Security", RFC 1750, December 1994. 1768 Authors' Addresses 1770 Qiaobing Xie 1771 Motorola, Inc. 1772 1501 W. Shure Drive, 2-F9 1773 Arlington Heights, IL 60004 1774 US 1776 Phone: 1777 Email: qxie1@email.mot.com 1779 Randall R. Stewart 1780 Cisco Systems, Inc. 1781 4875 Forest Drive 1782 Suite 200 1783 Columbia, SC 29206 1784 USA 1786 Phone: 1787 Email: rrs@cisco.com 1789 Maureen Stillman 1790 Nokia 1791 127 W. State Street 1792 Ithaca, NY 14850 1793 US 1795 Phone: 1796 Email: maureen.stillman@nokia.com 1798 Michael Tuexen 1799 Muenster Univ. of Applied Sciences 1800 Stegerwaldstr. 39 1801 48565 Steinfurt 1802 Germany 1804 Email: tuexen@fh-muenster.de 1805 Aron J. Silverton 1806 Motorola, Inc. 1807 1301 E. Algonquin Road 1808 Room 2246 1809 Schaumburg, IL 60196 1810 USA 1812 Phone: +1 847-576-8747 1813 Email: aron.j.silverton@motorola.com 1815 Full Copyright Statement 1817 Copyright (C) The Internet Society (2007). 1819 This document is subject to the rights, licenses and restrictions 1820 contained in BCP 78, and except as set forth therein, the authors 1821 retain all their rights. 1823 This document and the information contained herein are provided on an 1824 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1825 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1826 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1827 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1828 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1829 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1831 Intellectual Property 1833 The IETF takes no position regarding the validity or scope of any 1834 Intellectual Property Rights or other rights that might be claimed to 1835 pertain to the implementation or use of the technology described in 1836 this document or the extent to which any license under such rights 1837 might or might not be available; nor does it represent that it has 1838 made any independent effort to identify any such rights. Information 1839 on the procedures with respect to rights in RFC documents can be 1840 found in BCP 78 and BCP 79. 1842 Copies of IPR disclosures made to the IETF Secretariat and any 1843 assurances of licenses to be made available, or the result of an 1844 attempt made to obtain a general license or permission for the use of 1845 such proprietary rights by implementers or users of this 1846 specification can be obtained from the IETF on-line IPR repository at 1847 http://www.ietf.org/ipr. 1849 The IETF invites any interested party to bring to its attention any 1850 copyrights, patents or patent applications, or other proprietary 1851 rights that may cover technology that may be required to implement 1852 this standard. Please address the information to the IETF at 1853 ietf-ipr@ietf.org. 1855 Acknowledgment 1857 Funding for the RFC Editor function is provided by the IETF 1858 Administrative Support Activity (IASA).