idnits 2.17.1 draft-ietf-rserpool-enrp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Other values are reserved by IETF and MUST not be used. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2003) is 7493 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 1732, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-08 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3237 (ref. '2') == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-07 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '3') ** Obsolete normative reference: RFC 2246 (ref. '6') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2960 (ref. '7') (Obsoleted by RFC 4960) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '10') == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '11') -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. '12') (Obsoleted by RFC 4086) Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Xie 3 Internet-Draft Motorola 4 Expires: April 20, 2004 R. Stewart 5 Cisco 6 M. Stillman 7 Nokia 8 October 21, 2003 10 Endpoint Name Resolution Protocol (ENRP) 11 draft-ietf-rserpool-enrp-07.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 20, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 Endpoint Name Resolution Protocol (ENRP) is designed to work in 42 conjunction with the Aggregate Server Access Protocol (ASAP) to 43 accomplish the functionality of the Reliable Server Pooling 44 (Rserpool) requirements and architecture. Within the operational 45 scope of Rserpool, ENRP defines the procedures and message formats of 46 a distributed, fault-tolerant registry service for storing, 47 bookkeeping, retrieving, and distributing pool operation and 48 membership information. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 55 3. ENRP Message Definitions . . . . . . . . . . . . . . . . . 7 56 3.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 7 57 3.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 9 58 3.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 9 59 3.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 11 60 3.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 12 61 3.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 62 3.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 63 3.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 15 64 3.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15 65 3.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . . 16 66 3.11 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 18 67 4. ENRP Operation Procedures . . . . . . . . . . . . . . . . 19 68 4.1 Methods for Communicating amongst ENRP Servers . . . . . . 19 69 4.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 20 70 4.2.1 Generate a Server Identifier . . . . . . . . . . . . . . . 21 71 4.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . . . 21 72 4.2.3 Download ENRP Namespace Data from Mentor Peer . . . . . . 23 73 4.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 25 74 4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . . . 27 75 4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 28 76 4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28 77 4.6 Server Namespace Update . . . . . . . . . . . . . . . . . 29 78 4.6.1 Announcing Addition or Update of PE . . . . . . . . . . . 29 79 4.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . . . 30 80 4.7 Detecting and Removing Unreachable PE . . . . . . . . . . 31 81 4.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 32 82 4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 32 83 4.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . . . 32 84 4.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . . . 32 85 4.9.3 Detecting Peer Server Failure . . . . . . . . . . . . . . 33 86 4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . . 33 87 4.10.1 Initiate Server Take-over Arbitration . . . . . . . . . . 33 88 4.10.2 Take-over Target Peer Server . . . . . . . . . . . . . . . 34 89 4.11 Namespace Data Auditing and Re-synchronization . . . . . . 35 90 4.11.1 Auditing Procedures . . . . . . . . . . . . . . . . . . . 35 91 4.11.2 PE Checksum Calculation Algorithm . . . . . . . . . . . . 36 92 4.11.3 Re-synchronization Procedures . . . . . . . . . . . . . . 37 93 4.12 Handling Unrecognized Message or Unrecognized Parameter . 37 94 5. Variables and Thresholds . . . . . . . . . . . . . . . . . 39 95 5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 39 96 5.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 39 97 6. Security Considerations . . . . . . . . . . . . . . . . . 40 98 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 41 99 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 43 100 Normative References . . . . . . . . . . . . . . . . . . . 44 101 Informative References . . . . . . . . . . . . . . . . . . 45 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 45 103 Intellectual Property and Copyright Statements . . . . . . 46 105 1. Introduction 107 ENRP is designed to work in conjunction with ASAP [1] to accomplish 108 the functionality of Rserpool as defined by its requirements [2] and 109 architecture [3]. 111 Within the operation scope of Rserpool, ENRP defines the procedures 112 and message formats of a distributed fault-tolerant registry service 113 for storing, bookkeeping, retrieving, and distributing pool operation 114 and membership information. 116 Whenever appropriate, in the rest of this document we will refer to 117 this Rserpool registry service as ENRP namespace, or simply 118 namespace. 120 1.1 Definitions 122 This document uses the following terms: 124 Operation scope: See [3]; 126 Pool (or server pool): See [3]; 128 Pool handle (or pool name): See [3]; 130 Pool element (PE): See [3]; 132 Pool user (PU): See [3]; 134 Pool element handle: See [3]; 136 ENRP namespace (or namespace): See [3]; 138 ENRP namespace server (or ENRP server): See [3]; 140 ENRP client channel: The communication channel through which a PE 141 requests for ENRP namespace service. The ENRP client channel is 142 usually defined by the transport address of the home ENRP server 143 and a well known port number; 145 ENRP server channel: Defined by a well known multicast IP address and 146 a well known port number. All ENRP servers in an operation scope 147 can send multicast messages to other servers through this channel. 148 PEs are also allowed to multicast on this channel occasionally; 150 Home ENRP server: The ENRP server to which a PE or PU currently 151 belongs. A PE MUST only have one home ENRP server at any given 152 time and both the PE and its home ENRP server MUST keep track of 153 this master/slave relationship between them. A PU SHOULD select 154 one of the available ENRP servers as its home ENRP server, but the 155 ENRP server does not need to know, nor does it need to keep track 156 of this relationship. 158 2. Conventions 160 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 161 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 162 they appear in this document, are to be interpreted as described in 163 [5]. 165 3. ENRP Message Definitions 167 In this section, we defines the format of all ENRP messages. These 168 are messages sent and received amongst ENRP servers in an operation 169 scope. Messages sent and received between a PE/PU and an ENRP server 170 are part of ASAP and are defined in [1]. A common format, defined in 171 [10], is used for all ENRP and ASAP messages. 173 Most ENRP messages contains a combination of fixed fields and TLV 174 parameters. The TLV parameters are also defined in [10]. 176 All messages, as well as their fields/parameters described below, 177 MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., 178 the most significant byte first). 180 For ENRP, the following message types are defined: 182 Type Message Name 183 ----- ------------------------- 184 0x0 - (reserved by IETF) 185 0x1 - PEER_PRESENCE 186 0x2 - PEER_NAME_TABLE_REQUEST 187 0x3 - PEER_NAME_TABLE_RESPONSE 188 0x4 - PEER_NAME_UPDATE 189 0x5 - PEER_LIST_REQUEST 190 0x6 - PEER_LIST_RESPONSE 191 0x7 - PEER_INIT_TAKEOVER 192 0x8 - PEER_INIT_TAKEOVER_ACK 193 0x9 - PEER_TAKEOVER_SERVER 194 0xa - PEER_OWNERSHIP_CHANGE 195 0xb - PEER_ERROR 196 0xc-0xFF - (reserved by IETF) 198 3.1 PEER_PRESENCE message 200 This ENRP message is used to announce (periodically) the presence of 201 an ENRP server, or to probe the status of a peer ENRP sever. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Sender Server's ID | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Receiver Server's ID | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 : PE Checksum Param : 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 : Server Information Param (optional) : 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 R (reply_required) flag: 1 bit 219 Set to '1' if the sender requires a response to this message, 220 otherwise set to '0'. 222 Sender Server's ID: 32 bit (unsigned integer) 224 This is the ID of the ENRP server which sends the message. 226 Receiver Server's ID: 32 bit (unsigned integer) 228 This is the ID of the ENRP server to which the message is 229 intended. If the message is not intended to an individual 230 server (e.g., the message is multicasted to a group of 231 servers), this field MUST be set with all 0's. 233 PE Checksum Parameter: 235 This is a TLV that contains the latest PE checksum of the ENRP 236 server who sends the PEER_PRESENCE. This parameter SHOULD be 237 included for namespace consistency auditing. See Section 4.11.1 238 for details. 240 Server Information Parameter: 242 If present, contains the server information of the sender of 243 this message (Server Information Parameter is defined in [10]). 244 This parameter is optional. However, if this message is sent in 245 response to a received "reply required" PEER_PRESENCE from a 246 peer, the sender then MUST include its server information. 248 Note, at startup an ENRP server MUST pick a randomly generated, 249 non-zero 32-bit unsigned integer as its ID and MUST use this same ID 250 for its entire life. 252 3.2 PEER_NAME_TABLE_REQUEST message 254 An ENRP server sends this message to one of its peers to request a 255 copy of the namespace data. This message is normally used during 256 server initialization or namespace re-synchronization. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type = 0x2 |0|0|0|0|0|0|0|W| Message Length = 0xC | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Sender Server's ID | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Receiver Server's ID | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 W (oWn-children-only) flag: 1 bit 270 Set to '1' if the sender of this message is only requesting 271 information about the PEs owned by the message receiver. 272 Otherwise, set to '0'. 274 Sender Server's ID: 276 See Section 3.1. 278 Receiver Server's ID: 280 See Section 3.1. 282 3.3 PEER_NAME_TABLE_RESPONSE message 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type = 0x3 |0|0|0|0|0|0|R|M| Message Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Sender Server's ID | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Receiver Server's ID | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 : : 293 : Pool entry #1 (see below) : 294 : : 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 : : 297 : ... : 298 : : 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 : : 301 : Pool entry #n (see below) : 302 : : 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 R (Reject) flag: 1 bit 307 MUST be set to '1' if the sender of this message is rejecting a 308 namespace request. In such a case, this message MUST be sent 309 with no pool entries included. 311 M (More_to_send) flag: 1 bit 313 Set to '1' if the sender has more pool entries to sent in 314 subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set to 315 '0'. 317 Message Length: 16 bits (unsigned integer) 319 Indicates the entire length of the message in number of octets. 321 Note, the value in Message Length field will NOT cover any 322 padding at the end of this message. 324 Sender Server's ID: 326 See Section 3.1. 328 Receiver Server's ID: 330 See Section 3.1. 332 Pool entry #1-#n: 334 If R flag is '0', at least one pool entry SHOULD be present in 335 the message. Each pool entry MUST start with a pool handle 336 parameter as defined in section 3.1.7, followed by one or more 337 pool element parameters, i.e.: 339 +---------------------------+ 340 : Pool handle : 341 +---------------------------+ 342 : PE #1 : 343 +---------------------------+ 344 : PE #2 : 345 +---------------------------+ 346 : ... : 347 +---------------------------+ 348 : PE #n : 349 +---------------------------+ 351 3.4 PEER_NAME_UPDATE message 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Update Action | (reserved) | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Sender Server's ID | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Receiver Server's ID | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 : Pool handle : 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 : Pool Element : 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Message Length: 16 bits (unsigned integer) 371 Indicates the entire length of the message in number of octets. 373 Note, the value in Message Length field will NOT cover any 374 padding at the end of this message. 376 Update Action: 16 bits (unsigned integer) 378 This field indicates what act is requested to the specified PE. 379 It MUST take one of the following values: 381 0x0 - ADD_PE: add or update the specified PE in the ENRP 382 namespace 384 0x1 - DEL_PE: delete the specified PE from the ENRP namespace. 386 Other values are reserved by IETF and MUST not be used. 388 Reserved: 16 bits 390 MUST be set to 0's by sender and ignored by the receiver. 392 Sender Server's ID: 394 See Section 3.1. 396 Receiver Server's ID: 398 See Section 3.1. 400 Pool handle: 402 Specifies to which the PE belongs. 404 Pool Element: 406 Specifies the PE. 408 3.5 PEER_LIST_REQUEST message 410 This ENRP message is used to request a copy of the current known ENRP 411 peer server list. This message is normally sent from a newly started 412 ENRP server to an existing ENRP server as part of the initialization 413 process of the new server. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length = 0xC | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Sender Server's ID | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Receiver Server's ID | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Sender Server's ID: 427 See Section 3.1. 429 Receiver Server's ID: 431 See Section 3.1. 433 3.6 PEER_LIST_RESPONSE message 435 This message is used to respond a PEER_LIST_REQUEST. 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Sender Server's ID | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Receiver Server's ID | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 : Server Info Param of Peer #1 : 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 : ... : 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 : Server Info Param of Peer #n : 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 R (Reject) flag: 1 bit 455 MUST be set to '1' if the sender of this message is rejecting a 456 peer list request. In such a case, this message MUST be sent 457 with no peer server ID included. 459 Message Length: 16 bits (unsigned integer) 461 Indicates the entire length of the message in number of octets. 463 Note, the value in Message Length field will NOT cover any 464 padding at the end of this message. 466 Sender Server's ID: 468 See Section 3.1. 470 Receiver Server's ID: 472 See Section 3.1. 474 Server Information Parameter of Peer #1-#n: 476 Each contains a Server Information Parameter of a peer known to 477 the sender. The Server Information Parameter is defined in 478 [10]. 480 3.7 PEER_INIT_TAKEOVER message 482 This message is used by an ENRP server (the takeover initiator) to 483 declare its intention of taking over a specific peer ENRP server. 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Sender Server's ID | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Receiver Server's ID | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Target Server's ID | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Sender Server's ID: 499 See Section 3.1. 501 Receiver Server's ID: 503 See Section 3.1. 505 Target Server's ID: 507 Contains the 32-bit server ID of the peer ENRP that is the 508 target of this takeover attempt. 510 3.8 PEER_INIT_TAKEOVER_ACK message 512 This message is used to acknowledge the takeover initiator that the 513 sender of this message received the PEER_INIT_TAKEOVER message and 514 that it does not object to the takeover. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Sender Server's ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Receiver Server's ID | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Target Server's ID | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Sender Server's ID: 530 See Section 3.1. 532 Receiver Server's ID: 534 See Section 3.1. 536 Target Server's ID: 538 Contains the 32-bit server ID of the peer ENRP that is the 539 target of this takeover attempt. 541 3.9 PEER_TAKEOVER_SERVER message 543 This message is used by the takeover initiator to declare that a 544 takeover is underway. 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type = 0x9 |0|0|0|0|0|0|0|0| Message Length | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Sender Server's ID | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Receiver Server's ID | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Target Server's ID | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Sender Server's ID: 560 See Section 3.1. 562 Receiver Server's ID: 564 See Section 3.1. 566 Target Server's ID: 568 Contains the 32-bit server ID of the peer ENRP that is the 569 target of this takeover operation. 571 3.10 PEER_OWNERSHIP_CHANGE message 573 This message is used by the ENRP server, normally after a successful 574 takeover, to declare that it is now the new home ENRP server of the 575 listed PEs in the listed pools. 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type = 0xa |0|0|0|0|0|0|0|0| Message Length | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Sender Server's ID | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Receiver Server's ID | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 : Pool handle #1 : 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 : PE Identifier Param #1 of pool #1 : 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 : ... : 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 : PE Identifier Param #k of pool #1 : 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 : : 595 : ... : 596 : : 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 : Pool handle #M : 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 : PE Identifier Param #1 of pool #M : 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 : ... : 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 : PE Identifier Param #n of pool #M : 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Sender Server's ID: 609 See Section 3.1. 611 Receiver Server's ID: 613 See Section 3.1. 615 Pool handles and PE Identifier parameters: 617 Each listed pool handle is followed by a list of PE Identifier 618 parameters, indicating that the sender of this message is 619 taking ownership of the listed PEs in the pool. 621 3.11 PEER_ERROR message 623 This message is used by an ENRP server to report an operation error 624 to one of its peers. 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 = 0xb |0|0|0|0|0|0|0|0| Message Length | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Sender Server's ID | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Receiver Server's ID | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 : Operation Error Parameter : 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Sender Server's ID: 640 See Section 3.1. 642 Receiver Server's ID: 644 See Section 3.1. 646 Operation Error Parameter: 648 This parameter, defined in [10], indicates the type of error(s) 649 being reported. 651 4. ENRP Operation Procedures 653 In this section, we discuss the operation procedures defined by ENRP. 654 An ENRP server MUST following these procedures when sending, 655 receiving, 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 [1]. 665 4.1 Methods for Communicating amongst ENRP Servers 667 Within an Rserpool operation scope, ENRP servers need to communicate 668 with each other in order to exchange information such as the pool 669 membership changes, namespace 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 operation 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 a well-known 686 RSERPOOL IP multicast channel that its peer servers subscribe to. 688 Note: Because IP multicast is not reliable, this approach does 689 not guarantee that all the peers will receive the announcement 690 message. Moreover, since IP multicast is not secure, this 691 approach cannot provide any security to the communication. 693 2. The sending server sends multiple copies of the announcement, one 694 to each of its peer servers, over a set of point-to-point SCTP 695 associations between the sending server and the peers. 697 This approach guarantees the reliable reception of the message. 698 When needed, data security can be achieved by using IP security 699 mechanisms such as IPsec [9] or TLS [8]. 701 In order to maximize inter-operability of ENRP servers, the following 702 rules MUST be followed: 704 1. At the startup time, a new ENRP server SHOULD make a decision on 705 whether it will enable IP multicast for ENRP announcements. This 706 decision should be based on factors such as the availability of 707 IP multicast and the security requirements from the user of 708 Rserpool. 710 2. If an ENRP server disables multicast, it then: 712 A. MUST NOT subscribe to the well-known server multicast 713 channel, i.e., it only receives peer announcements over SCTP 714 associations, and 716 B. MUST transmit all its out-going announcements over 717 point-to-point SCTP associations with its peers. 719 3. If an ENRP server enables itself to use multicast, it then: 721 A. MUST subscribe to the well-known server multicast channel to 722 ready itself for receiving peers' multicast announcements, 724 B. MUST also be prepared to receive peer announcements over 725 point-to-point SCTP associations from peers. 727 C. MUST track internally which peers are multicast-enabled and 728 which are not. Note: A peer is always assumed to be 729 multicast-disabled until/unless an ENRP message of any type 730 is received from that peer over the well-known server 731 multicast channel. 733 D. when sending out an announcement, MUST send a copy to the 734 well-known server multicast channel AND a copy to each of the 735 peers that are marked as multicast-disabled over a 736 point-to-point SCTP association. 738 4.2 ENRP Server Initialization 740 This section describes the steps a new ENRP server needs to take in 741 order to join the other existing ENRP servers, or to initiate the 742 namespace service if it is the first ENRP server started in the 743 operation scope. 745 4.2.1 Generate a Server Identifier 747 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 748 as unique as possible in the operation scope and this server Id MUST 749 remain unchanged for the lifetime of the server. Normally, a good 750 32-bit random number will be good enough as the server Id ([12] 751 provides some information on randomness guidelines). 753 Note, there is a very remote chance (about 1 in 4 billion) that two 754 PEs of a pool will generate the same server Id and hence cause a 755 server Id conflict in the pool. However, no severe consequence of 756 such a conflict has been identified. 758 4.2.2 Acquire Peer Server List 760 At startup, the ENRP server (initiating server) will first attempt to 761 learn all existing peer ENRP servers in the same operation scope, or 762 to determine that it is along in the scope. 764 The initiating server uses an existing peer server to bootstrap 765 itself into service. We call this peer server the mentor server. 767 4.2.2.1 Find the mentor server 769 If the initiating server is told about an existing peer server 770 through some administrative means (such as DNS query, configuration 771 database, startup scripts, etc), the initiating server SHOULD then 772 use this peer server as its mentor server and SHOULD skip the 773 remaining steps in this subsection. 775 If multiple existing peer servers are specified, the initiating 776 server SHOULD pick one of them as its mentor peer server, keep the 777 others as its backup mentor peers, and skip the remaining steps in 778 this subsection. 780 If no existing peer server is specified to the initiating server AND 781 if multicast is available in the operation scope, the following 782 mentor peer discovery procedures SHOULD be followed: 784 1. The initiating server SHOULD first join the well-known ENRP 785 server multicast channel. 787 2. Then the initiating server SHOULD send a PEER_PRESENCE message, 788 with the 'Reply_required' flag set, over the multicast channel. 789 Upon the reception of this PEER_PRESENCE message, a peer server 790 MUST send a PEER_PRESENCE, without the 'Reply_required' flag, 791 back to the initiating server. 793 3. When the first response to its original PEER_PRESENCE arrives, 794 the initiating server SHOULD take the sender of this received 795 response as its mentor peer server. This completes the discovery 796 of the mentor peer server. 798 If responses are also received from other peers (a likely event 799 when multiple peers exist in the operation scope at the time the 800 new server started), the initiating server SHOULD keep a list of 801 those responded as its backup mentor peers (see below). 803 4. If no response to its PEER_PRESENCE message are received after 804 TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat 805 steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After 806 that, if there is still no response, the initiating server MUST 807 assume that it is alone in the operation scope. 809 5. If the initiating server determined that it is alone in the 810 scope, it MUST skip the procedures in Section 4.2.2.2 and Section 811 4.2.3 and MUST consider its initialization completed and start 812 offering ENRP services. 814 Note, if multicast is not available (or not allowed for reasons such 815 as security concerns) in the operation scope, at least one peer 816 server MUST be specified to the initiating server through 817 administrative means, unless the initiation server is the first 818 server to start in the operation scope. 820 Note, if the administratively specified mentor peer(s) fails, the 821 initiating server SHOULD use the auto-discover procedure defined in 822 steps 1-5 above. 824 4.2.2.2 Request complete server list from mentor peer 826 Once the initiating server finds its mentor peer server (by either 827 discovery or administrative means), the initiating server MUST send a 828 PEER_LIST_REQUEST message to the mentor peer server to request a copy 829 of the complete server list maintained by the mentor peer (see 830 Section 4.9 for maintaining server list). 832 Upon the reception of this request, the mentor peer server SHOULD 833 reply with a PEER_LIST_RESPONSE message and include in the message 834 body all existing ENRP servers known by the mentor peer. 836 Upon the reception of the PEER_LIST_RESPONSE message from the mentor 837 peer, the initiating server MUST use the server information carried 838 in the message to initialize its own peer list. 840 However, if the mentor itself is in the process of startup and not 841 ready to provide a peer server list (for example, the mentor peer is 842 waiting for a response to its own PEER_LIST_REQUEST to another 843 server), it MUST reject the request by the initiating server and 844 respond with a PEER_LIST_RESPONSE message with the R flag set to '1', 845 and with no server information included in the response. 847 In the case where its PEER_LIST_REQUEST is rejected by the mentor 848 peer, the initiating server SHOULD either wait for a few seconds and 849 re-send the PEER_LIST_REQUEST to the mentor server, or if there is a 850 backup mentor peer available, select another mentor peer server and 851 send the PEER_LIST_REQUEST to the new mentor server. 853 4.2.3 Download ENRP Namespace Data from Mentor Peer 855 After a peer list download is completed, the initiating server MUST 856 request a copy of the current namespace data from its mentor peer 857 server, by taking the following steps: 859 1. The initiating server MUST first send a PEER_NAME_TABLE_REQUEST 860 message to the mentor peer, with W flag set to '0', indicating 861 that the entire namespace is requested. 863 2. Upon the reception of this message, the mentor peer MUST start a 864 download session in which a copy of the current namespace data 865 maintained by the mentor peer is sent to the initiating server in 866 one or more PEER_NAME_TABLE_RESPONSE messages (Note, the mentor 867 server may find it particularly desirable to use multiple 868 PEER_NAME_TABLE_RESPONSE messages to send the namespace when the 869 namespace is large, especially when forming and sending out a 870 single response containing a large namespace may interrupt its 871 other services). 873 If more than one PEER_NAME_TABLE_RESPONSE message are used during 874 the download, the mentor peer MUST use the M flag in each 875 PEER_NAME_TABLE_RESPONSE message to indicate whether this message 876 is the last one for the download session. In particular, the 877 mentor peer MUST set the M flag to '1' in the outbound 878 PEER_NAME_TABLE_RESPONSE if there is more data to be transferred 879 and MUST keep track of the progress of the current download 880 session. The mentor peer MUST set the M flag to '0' in the last 881 PEER_NAME_TABLE_RESPONSE for the download session and close the 882 download session (i.e., removing any internal record of the 883 session) after sending out the last message. 885 3. During the downloading, every time the initiating server receives 886 a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data 887 entries carried in the message into its local namespace database, 888 and then check whether or not this message is the last one for 889 the download session. 891 If the M flag is set to '1' in the just processed 892 PEER_NAME_TABLE_RESPONSE message, the initiating server MUST send 893 another PEER_NAME_TABLE_REQUEST message to the mentor peer to 894 request for the next PEER_NAME_TABLE_RESPONSE message. 896 4. When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 897 message into its local namespace database, the initiating server 898 MUST handle each pool entry carried in the message using the 899 following rules: 901 A. If the pool does not exist in the local namespace, the 902 initiating server MUST creates the pool in the local 903 namespace and add the PE(s) in the pool entry to the pool. 905 When creating the pool, the initiation server MUST set the 906 overall member selection policy type of the pool to the 907 policy type indicated in the first PE. 909 B. If the pool already exists in the local namespace, but the 910 PE(s) in the pool entry is not currently a member of the 911 pool, the initiating server MUST add the PE(s) to the pool. 913 C. If the pool already exists in the local namespace AND the 914 PE(s) in the Pool entry is already a member of the pool, the 915 initiating server SHOULD replace the attributes of the 916 existing PE(s) with the new information. 918 5. When the last PEER_NAME_TABLE_RESPONSE message is received from 919 the mentor peer and unpacked into the local namespace, the 920 initialization process is completed and the initiating server 921 SHOULD start to provide ENRP services. 923 Under certain circumstances, the mentor peer itself may not be able 924 to provide a namespace download to the initiating server. For 925 example, the mentor peer is in the middle of initializing its own 926 namespace database, or it has currently too many download sessions 927 open to other servers. 929 In such a case, the mentor peer MUST reject the request by the 930 initiating server and respond with a PEER_NAME_TABLE_RESPONSE message 931 with the R flag set to '1', and with no pool entries included in the 932 response. 934 In the case where its PEER_NAME_TABLE_REQUEST is rejected by the 935 mentor peer, the initiating server SHOULD either wait for a few 936 seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server, 937 or if there is a backup mentor peer available, select another mentor 938 peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor 939 server. 941 A started namespace download session may get interrupted for some 942 reason. To cope with this, the initiating server SHOULD start a timer 943 every time it finishes sending a PEER_NAME_TABLE_REQUEST to its 944 mentor peer. If this timer expires without receiving a response from 945 the mentor peer, the initiating server SHOULD abort the current 946 download session and re-start a new namespace download with a backup 947 mentor peer, if one is available. 949 Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the 950 mentor peer has still more data to send, it SHOULD start a session 951 timer. If this timer expires without receiving another request from 952 the initiating server, the mentor peer SHOULD abort the session, 953 cleaning out any resource and record of the session. 955 4.3 Handle PE Registration 957 To register itself with the namespace, a PE sends a REGISTRATION 958 message to its home ENRP server. The format of REGISTRATION message 959 and rules of sending it are defined in [1]. 961 In the REGISTRATION message, the PE indicates the name of the pool it 962 wishes to join in a pool handle parameter, and its complete transport 963 information and any load control information in a PE parameter. 965 The ENRP server handles the REGISTRATION message according to the 966 following rules: 968 1. If the named pool does not exist in the namespace, the ENRP 969 server MUST creates a new pool with that name in the namespace 970 and add the PE to the pool as its first PE; 972 When a new pool is created, the overall member selection policy 973 of the pool MUST be set to the policy type indicated by the first 974 PE, the overall pool transport type MUST be set to the transport 975 type indicated by the PE, and the overall pool data/control 976 channel configuration MUST be set to what is indicated in the 977 Transport Use field of the User Transport parameter by the 978 registering PE. 980 2. If the named pool already exists in the namespace, but the 981 requesting PE is not currently a member of the pool, the ENRP 982 server will add the PE as a new member to the pool; 984 However, before adding the PE to the pool, the server MUST check 985 if the policy type, transport type, and transport usage indicated 986 by the registering PE is consistent with those of the pool. If 987 different, the ENRP server MUST either attempt to override the 988 PE's value(s) or to reject the registration if overriding is not 989 possible. 991 A. Inconsistent policy - If no additional policy-related 992 information are required to perform an override of pool 993 policy (e.g., overriding Least-used with Round-robin does not 994 require additional policy-related information), the ENRP 995 server MUST replace the PE's policy type with the overall 996 policy type of the pool. However, if additional policy 997 information is required for the overriding (e.g., overriding 998 Round-robin with Least-load will require the knowledge of the 999 load factor of the PE), the ENRP server MUST reject the 1000 registration. 1002 B. Inconsistent transport type - The ENRP server MUST reject the 1003 registration. 1005 C. Inconsistent data/control configuration - If the overall pool 1006 configuration is "DATA ONLY", and the registering PE 1007 indicates "CONTORL plus DATA", the ENRP server SHOULD accept 1008 the registration but warn the PE that control channel cannot 1009 be used. If the pool configuration is "CONTROL plus DATA" and 1010 the PE indicates "DATA ONLY", the ENRP server MUST reject the 1011 registration. 1013 3. If the named pool already exists in the namespace AND the 1014 requesting PE is already a member of the pool, the ENRP server 1015 SHOULD consider this as a re-registration case. The ENRP server 1016 MUST perform the same tests on policy, transport type, transport 1017 use, as described above. If the re-registration is accepted after 1018 the test, the ENRP Server SHOULD replace the attributes of the 1019 existing PE with the information carried in the received 1020 REGISTRATION message. 1022 4. After accepting the registration, the ENRP server MUST assign 1023 itself the owner of this PE. If this is a re-registration, the 1024 ENRP server MUST take over ownership of this PE regardless of 1025 whether the PE was previously owned by this server or by another 1026 server. 1028 5. The ENRP server may reject the registration due to reasons such 1029 as invalid values, lack of resource, authentication failure, etc. 1031 In all above cases, the ENRP server MUST reply to the requesting PE 1032 with a REGISTRATION_RESPONSE message. If the registration is 1033 accepted, the ENRP server MUST set the 'R' flag in the 1034 REGISTRATION_RESPONSE to '0'. If the registration is rejected, the 1035 ENRP server MUST indicate the rejection by setting the 'R' flag in 1036 the REGISTRATION_RESPONSE to '1'. 1038 If the registration is rejected, the ENRP server SHOULD include the 1039 proper error cause(s) in the REGISTRATION_RESPONSE message. 1041 If the registration is granted but with an override of some PE's 1042 original values, in the REGISTRATION_RESPONSE message the ENRP server 1043 SHOULD include the proper error cause(s) so that the PE can be warned 1044 about the overriding and be informed about the new value(s). 1046 If the registration is granted (either a new registration or a 1047 re-registration case), the ENRP server MUST assign itself to be the 1048 home ENRP server of the PE, i.e., to "own" the PE. 1050 Implementation note: for better performance, the ENRP server may 1051 find it both efficient and convenient to internally maintain two 1052 separate PE lists or tables - one is for the PEs that are "owned" 1053 by the ENRP server and the other for all the PEs owned by its 1054 peer(s). 1056 Moreover, if the registration is granted, the ENRP server MUST take 1057 the namespace update action as described in Section 4.6 to inform its 1058 peers about the change just made. If the registration is denied, no 1059 message will be sent to its peers. 1061 4.3.1 Rules on PE Re-registration 1063 A PE may re-register itself to the namespace with a new set of 1064 attributes in order to, for example, extend its registration life, 1065 change its load factor value, etc. 1067 A PE may modify its load factor value at any time via 1068 re-registration. Based on the number of PEs in the pool and the 1069 pool's overall policy type, this operation allows the PE to 1070 dynamically control its share of inbound messages received by the 1071 pool (also see Section ???? in [1] for more on load control). 1073 Moreover, when re-registering, the PE MUST NOT change its policy 1074 type. The server MUST reject the re-registration if the PE attempt to 1075 change its policy type. In the rejection, the server SHOULD attach an 1076 error code "Pooling Policy Inconsistent". 1078 Regardless whether it is the current owner of the PE, if the 1079 re-registration is granted to the PE, the ENRP server MUST assign 1080 itself to be the new home ENRP server of the PE. 1082 Moreover, if the re-registration is granted, the ENRP server MUST 1083 take the namespace update action as described in Section 4.6 to 1084 inform its peers about the change just made. If the re-registration 1085 is denied, no message will be sent to its peers. 1087 4.4 Handle PE De-registration 1089 To remove itself from a pool, a PE sends a DEREGISTRATION message to 1090 its home ENRP server. The complete format of DEREGISTRATION message 1091 and rules of sending it are defined in [1]. 1093 In the DEREGISTRATION message the PE indicates the name of the pool 1094 it belongs to in a pool handle parameter and provides its PE 1095 identifier. 1097 Upon receiving the message, the ENRP server SHALL remove the PE from 1098 its namespace. Moreover, if the PE is the last one of the named pool, 1099 the ENRP server will remove the pool from the namespace as well. 1101 If the ENRP server fails to find any record of the PE in its 1102 namespace, it SHOULD consider the de-registration granted and 1103 completed. 1105 The ENRP server may reject the de-registration request for various 1106 reasons, such as invalid parameters, authentication failure, etc. 1108 In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE 1109 message to the PE. If the de-registration is rejected, the ENRP 1110 server MUST indicate the rejection by including the proper Operation 1111 Error parameter. 1113 It should be noted that de-registration does not stop the PE from 1114 sending or receiving application messages. 1116 Once the de-registration request is granted AND the PE removed from 1117 its local copy of the namespace, the ENRP server MUST take the 1118 namespace update action described in Section 4.6 to inform its peers 1119 about the change just made. Otherwise, NO message SHALL be send to 1120 its peers. 1122 4.5 Pool Handle Translation 1124 A PU uses the pool handle translation service of an ENRP server to 1125 resolve a pool handle to a list of accessible transport addresses of 1126 the member PEs of the pool. 1128 This requires the PU to send a NAME_RESOLUTION message to its home 1129 ENRP server and in the NAME_RESOLUTION message specify the pool 1130 handle to be translated in a Pool Handle parameter. Complete 1131 definition of the NAME_RESOLUTION message and the rules of sending it 1132 are defined in [1]. 1134 An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests 1135 from PUs either over an SCTP association on the well-know SCTP port, 1136 or over a TCP connection on the well-know TCP port. 1138 Upon reception of the NAME_RESOLUTION message, the ENRP server MUST 1139 first look up the pool handle in its namespace. If the pool exits, 1140 the home ENRP server MUST compose and send back a 1141 NAME_RESOLUTION_RESPONSE message to the requesting PU. 1143 In the response message, the ENRP server SHOULD list all the PEs 1144 currently registered in this pool, in a list of PE parameters. The 1145 ENRP server MUST also include a pool member selection policy 1146 parameter to indicate the overall member selection policy for the 1147 pool, if the current pool member selection policy is not round-robin 1148 (if the overall policy is round-Robin, this parameter MAY be 1149 omitted?). 1151 If the named pool does not exist in the namespace, the ENRP server 1152 MUST respond with a NAME_UNKNOWN message. 1154 The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN 1155 messages and the rules of receiving them are defined in [1]. 1157 4.6 Server Namespace Update 1159 This includes a set of update operations used by an ENRP server to 1160 inform its peers when its local namespace is modified, e.g., addition 1161 of a new PE, removal of an existing PE, change of pool or PE 1162 properties. 1164 4.6.1 Announcing Addition or Update of PE 1166 When a new PE is granted registration to the namespace or an existing 1167 PE is granted a re-registration, the home ENRP server uses this 1168 procedure to inform all its peers. 1170 This is an ENRP announcement and is sent to all the peer of the home 1171 ENRP server. See Section 4.1 on how announcements are sent. 1173 An ENRP server MUST announce this update to all its peers in a 1174 PEER_NAME_UPDATE message with the Update Action field set to ADD_PE, 1175 indicating the addition of a new PE or the modification of an 1176 existing PE. The complete new information of the PE and the pool its 1177 belongs to MUST be indicated in the message with a PE parameter and a 1178 Pool Handle parameter, respectively. 1180 The home ENRP server SHOULD fill in its server Id in the Sender 1181 Server's ID field and leave the Receiver Server's ID blank (i.e., all 1182 0's). 1184 When a peer receives this PEER_NAME_UPDATE message, it MUST take the 1185 following actions: 1187 1. If the named pool indicated by the pool handle does not exist in 1188 its local copy of the namespace, the peer MUST create the named 1189 pool in its local namespace and add the PE to the pool as the 1190 first PE. It MUST then copy in all other attributes of the PE 1191 carried in the message. 1193 When the new pool is created, the overall member selection policy 1194 of the pool MUST be set to the policy type indicated by the PE. 1196 2. If the named pool already exists in the peer's local copy of the 1197 namespace AND the PE does not exist, the peer MUST add the PE to 1198 the pool as a new PE and copy in all attributes of the PE carried 1199 in the message. 1201 3. If the named pool exists AND the PE is already a member of the 1202 pool, the peer MUST replace the attributes of the PE with the new 1203 information carried in the message. 1205 4.6.2 Announcing Removal of PE 1207 When an existing PE is granted de-registration or is removed from its 1208 namespace for some other reasons (e.g., purging an unreachable PE, 1209 see Section 4.7), the ENRP server MUST uses this procedure to inform 1210 all its peers about the change just made. 1212 This is an ENRP announcement and is sent to all the peer of the home 1213 ENRP server. See Section 4.1 on how announcements are sent. 1215 An ENRP server MUST announce the PE removal to all its peers in a 1216 PEER_NAME_UPDATE message with the Update Action field set to DEL_PE, 1217 indicating the removal of an existing PE. The complete information of 1218 the PE and the pool its belongs to MUST be indicated in the message 1219 with a PE parameter and a Pool Handle parameter, respectively. 1221 [editor's note: only the pool handle and the PE's id are needed, it 1222 should reduce the size of the message] 1224 The sending server MUST fill in its server ID in the Sender Server's 1225 ID field and leave the Receiver Server's ID blank (i.e., set to all 1226 0's). 1228 When a peer receives this PEER_NAME_UPDATE message, it MUST first 1229 find pool and the PE in its own namespace, and then remove the PE 1230 from its local namespace. If the removed PE is the last one in the 1231 pool, the peer MUST also delete the pool from its local namespace. 1233 If the peer fails to find the PE or the pool in its namespace, it 1234 SHOULD take no further actions. 1236 4.7 Detecting and Removing Unreachable PE 1238 Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 1239 Notification, see section 10.2 of [7]), the PU SHOULD send an 1240 ENDPOINT_UNREACHABLE message to its home ENRP server. The message 1241 SHOULD contain the pool handle and the PE Id of the unreachable PE. 1243 Upon the reception of an ENDPOINT_UNREACHABLE message, a server MUST 1244 immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the 1245 PE in question. If this ENDPOINT_KEEP_ALIVE fails (e.g., it results 1246 in an SCTP SEND.FAILURE notification), the ENRP server MUST consider 1247 the PE as truly unreachable and MUST remove the PE from its namespace 1248 and take actions described in Section 4.6.2. 1250 If the ENDPOINT_UNREACHABLE message is transmitted successfully to 1251 the PE, the ENRP server MUST retain the PE in its namespace. 1252 Moreover, the server SHOULD keep a counter to record how many 1253 ENDPOINT_UNREACHABLE messages it has received reporting reachability 1254 problem relating to this PE. If the counter exceeds the protocol 1255 threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE 1256 from its namespace and take actions described in Section 4.6.2. 1258 Optionally, an ENRP server may also periodically send point-to-point 1259 ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP 1260 server in order to check their reachability status. If the send of 1261 ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the 1262 PE as unreachable and MUST remove the PE from its namespace and take 1263 actions described in Section 4.6.2. Note, if an ENRP server owns a 1264 large number of PEs, the implementation should pay attention not to 1265 flood the network with bursts of ENDPOINT_KEEP_ALIVE messages. 1266 Instead, the implementation should try to smooth out the 1267 ENDPOINT_KEEP_ALIVE message traffic over time. 1269 The complete definition and rules of sending ENDPOINT_UNREACHABLE and 1270 receiving ENDPOINT_KEEP_ALIVE messages are described in [1]. 1272 4.8 Helping PE and PU to Discover Home ENRP Server 1274 At its startup time, or whenever its current home ENRP server is not 1275 providing services, a PE or PU will attempt to find a new home 1276 server. For this reason, the PE or PU will need to maintain a list of 1277 currently available ENRP servers in its scope. 1279 To help the PE or PU maintaining this list, an ENRP server, if it is 1280 enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE 1281 message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP 1282 multicast channel. And in the SERVER_ANNOUNE message the ENRP server 1283 SHOULD include all the transport addresses available for ASAP 1284 communications. If the ENRP server only supports SCTP for ASAP 1285 communications, the transport information MAY be omitted in the 1286 SERVER_ANNOUNCE message. 1288 For the complete procedure of this, see Section 3.6?? in [1]. 1290 4.9 Maintaining Peer List and Monitoring Peer Status 1292 An ENRP server MUST keep an internal record on the status of each of 1293 its known peers. This record is referred to as the server's "peer 1294 list" 1296 4.9.1 Discovering New Peer 1298 If a message of any type is received from a previously unknown peer, 1299 the ENRP server MUST consider this peer a new peer in the operation 1300 scope and add it to the peer list. 1302 The ENRP server MUST send a PEER_PRESENCE message with the 1303 Reply-required flag set to '1' to the source address found in the 1304 arrived message. This will force the new peer to reply with its own 1305 PEER_PRESENCE containing its full server information (see Section 1306 3.1). 1308 [editor's note: should we ask for a peer list from the new peer? 1309 this may help mending two split networks.] 1311 4.9.2 Server Sending Heartbeat 1313 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 1314 continued presence to all its peer with a PEER_PRESENCE message. In 1315 the PEER_PRESENCE message, the ENRP server MUST set the 1316 'Replay_required' flag to '0', indicating that no response is 1317 required. 1319 The arrival of this periodic PEER_PRESENCE message will cause all its 1320 peers to update their internal variable "peer.last.heard" for the 1321 sending server (see Section 4.9.3 for more details). 1323 4.9.3 Detecting Peer Server Failure 1325 An ENRP server MUST keep an internal variable "peer.last.heard" for 1326 each of its known peers and the value of this variable MUST be 1327 updated to the current local time every time a message of any type 1328 (point-to-point or announcement) is received from the corresponding 1329 peer. 1331 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 1332 seconds, the ENRP server MUST immediately send a point-to-point 1333 PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1335 If the send fails or the peer does not reply after 1336 MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer 1337 server dead and SHOULD initiate the takeover procedure defined in 1338 Section 4.10. 1340 4.10 Taking-over a Failed Peer Server 1342 In the following descriptions, We call the ENRP server that detects 1343 the failed peer server and initiates the take-over the "initiating 1344 server" and the failed peer server the "target server." 1346 4.10.1 Initiate Server Take-over Arbitration 1348 The initiating server SHOULD first start a take-over arbitration 1349 process by announcing a PEER_INIT_TAKEOVER message to all its peer 1350 servers. See Section 4.1 on how announcements are sent. In the 1351 message, the initiating server MUST fill in the Sender Server's ID 1352 and Target Server's ID. 1354 After announcing the PEER_INIT_TAKEOVER message, the initiating 1355 server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_ 1356 of its known peers, except of the target server. [editor's note: how 1357 long should it wait?] 1359 Each of the peer servers that receives the PEER_INIT_TAKEOVER message 1360 from the initiating server SHOULD take the following actions: 1362 1. If the peer server finds that itself is the target server 1363 indicated in the PEER_INIT_TAKEOVER message, it MUST immediately 1364 announce a PEER_PRESENCE message to all its peer ENRP servers in 1365 an attempt to stop this take-over process. This indicates a false 1366 failure detection case by the initiating server. 1368 2. If the peer server finds that itself has already started its own 1369 take-over arbitration process on the same target server, it MUST 1370 perform the following arbitration: 1372 A. if the peer's server ID is smaller in value than the Sender 1373 Server's ID in the arrived PEER_INIT_TAKEOVER message, the 1374 peer server SHOULD immediately abort its own take-over 1375 attempt. Moreover, the peer SHOULD mark the target server as 1376 "not active" on its internal peer list so that its status 1377 will no longer be monitored by the peer, and reply the 1378 initiating server with a PEER_INIT_TAKEOVER_ACK message. 1380 B. Otherwise, the peer MUST ignore the PEER_INIT_TAKEOVER 1381 message and take no action. 1383 3. If the peer finds that it is neither the target server nor is in 1384 its own take-over process, the peer SHOULD: a) mark the target 1385 server as "not active" on its internal peer list so that its 1386 status will no longer be monitored by this peer, and b) reply to 1387 the initiating server with a PEER_INIT_TAKEOVER_ACK message. 1389 Once the initiating server has received PEER_INIT_TAKEOVER_ACK 1390 message from _all_ of its currently known peers (except for the 1391 target server), it SHOULD consider that it has won the arbitration 1392 and SHOULD proceed to complete the take-over, following the steps 1393 described in Section 4.10.2. 1395 However, if it receives a PEER_PRESENCE from the target server at any 1396 point in the arbitration process, the initiating server SHOULD 1397 immediately abort the take-over process and mark the status of the 1398 target server as "active". 1400 4.10.2 Take-over Target Peer Server 1402 The initiating ENRP server SHOULD first send, via an announcement, a 1403 PEER_TAKEOVER_SERVER message to inform all its active peers that the 1404 take-over is enforced. The target server's ID MUST be filled in the 1405 message. The initiating server SHOULD then remove the target server 1406 from its internal peer list. 1408 [editor's note: peers should remove the target server from their list 1409 upon receiving this message. Do we really need this message? we can 1410 consolidate this with the ownership_change msg.] 1412 Then it SHOULD examine its local copy of the namespace and claim 1413 ownership of each of the PEs originally owned by the target server, 1414 by following these steps: 1416 1. mark itself as the home ENRP server of each of the PEs originally 1417 owned by the target server; 1419 2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the 1420 PEs. This will trigger the PE to adopt the initiating sever as 1421 its new home ENRP server; 1423 3. after claiming the ownership of all the PEs originally owned by 1424 the target server, announce the ownership changes of all the 1425 affected PEs in a PEER_OWNERSHIP_CHANGE message to all the 1426 currently known peers. Note, if the list of affected PEs is long, 1427 the sender MAY announce the ownership changes in multiple 1428 PEER_OWNERSHIP_CHANGE messages. 1430 When a peer receives the PEER_OWNERSHIP_CHANGE message from the 1431 initiating server, it SHOULD find each of the reported PEs in its 1432 local copy of the namespace and update the PE's home ENRP server to 1433 be the sender of the message (i.e., the initiating server). 1435 4.11 Namespace Data Auditing and Re-synchronization 1437 Message losses or certain temporary breaks in network connectivity 1438 may result in data inconsistency in the local namespace copy of some 1439 of the ENRP servers in an operation scope. Therefore, each ENRP 1440 server in the operation scope SHOULD periodically verify that its 1441 local copy of namespace data is still in sync with that of its peers. 1443 This section defines the auditing and re-synchronization procedures 1444 for an ENRP server to maintain its namespace data consistency. 1446 4.11.1 Auditing Procedures 1448 The auditing of namespace consistency is based on the following 1449 procedures: 1451 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1452 integer internal variable) for each of its known peers and for 1453 itself. For an ENRP server with 'k' known peers, we denote these 1454 internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ..., 1455 "pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE 1456 checksum. The definition and detailed algorithm for calculating 1457 these PE checksum variables are given in Section 4.11.2. 1459 2. Each time an ENRP server sends out a PEER_PRESENCE, it SHOULD 1460 include in the message its current PE checksum (i.e., 1461 "pe.checksum.pr0"). 1463 3. When an ENRP server (server A) receives a PE checksum (carried in 1464 an arrived PEER_PRESENCE) from a peer ENRP server (server B), 1465 server A SHOULD compare the PE checksum found in the 1466 PEER_PRESENCE with its own internal PE checksum of server B 1467 (i.e., "pe.checksum.prB"). 1469 4. If the two values match, server A will consider that there is no 1470 namespace inconsistency between itself and server B and should 1471 take no further actions. 1473 5. If the two values do NOT match, server A SHOULD consider that 1474 there is a namespace inconsistency between itself and server B 1475 and a re-synchronization process SHOULD be carried out 1476 immediately with server B (see Section 4.11.3). 1478 4.11.2 PE Checksum Calculation Algorithm 1480 When an ENRP server (server A) calculate an internal PE checksum for 1481 a peer (server B), it MUST use the following algorithm. 1483 Let us assume that in server A's internal namespace there are 1484 currently 'M' PEs that are owned by server B. Each of the 'M' PEs 1485 will then contribute to the checksum calculation with the following 1486 byte block: 1488 0 1 2 3 1489 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 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 : Pool handle string of the pool the PE belongs (padded with : 1492 : zeros to next 32-bit word boundary if needed) : 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | PE Id (4 octets) | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 Note, these are not TLVs. This byte block gives each PE a unique byte 1498 pattern in the scope. The 32-bit PE checksum for server B 1499 "pe.checksum.prB" is then calculated over the byte blocks contributed 1500 by the 'M' PEs one by one. 1502 Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") 1503 in the same fashion, using the byte blocks of all the PEs owned by 1504 itself. 1506 Note, whenever an ENRP finds that its internal namespace has changed 1507 (e.g., due to PE registration/deregistration, receiving peer updates, 1508 removing failed PEs, downloading namespace pieces from a peer, etc.), 1509 it MUST immediately update all its internal PE checksums that are 1510 affected by the change. 1512 Implementation Note: when the internal namespace changes (e.g., a new 1513 PE added or an existing PE removed), an implementation needs not to 1514 re-calculate the affected PE checksum; it should instead simply 1515 update the checksum by adding or subtracting the byte block of the 1516 corresponding PE from the previous checksum value. 1518 4.11.3 Re-synchronization Procedures 1520 Once an ENRP server determines that there is inconsistency between 1521 its local namespace data and a peer's namespace data with regarding 1522 to the PEs owned by that peer, it SHOULD perform the following steps 1523 to re-synchronize the data: 1525 1. The ENRP server SHOULD first "mark" every PE it knows about that 1526 is owned by the peer in its local namespace database; 1528 2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST 1529 message with W flag set to '1' to the peer to request a complete 1530 list of PEs owned by the peer; 1532 3. Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag 1533 set to '1', the peer server SHOULD immediately respond with a 1534 PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned 1535 by the peer. 1537 4. Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP 1538 server SHOULD transfer the PE entries carried in the message into 1539 its local namespace database. If an PE entry being transferred 1540 already exists in its local database, the ENRP server MUST 1541 replace the entry with the copy found in the message and remove 1542 the "mark" from the entry. 1544 5. After transferring all the PE entries from the received 1545 PEER_NAME_TABLE_RESPONSE message into its local database, the 1546 ENRP server SHOULD check whether there are still PE entries that 1547 remain "marked" in its local namespace. If so, the ENRP server 1548 SHOULD silently remove those "marked" entries. 1550 Note, similar to what is described in Section 4.2.3, the peer may 1551 reject the PEER_NAME_TABLE_REQUEST or use more than one 1552 PEER_NAME_TABLE_RESPONSE message to respond. 1554 4.12 Handling Unrecognized Message or Unrecognized Parameter 1556 When an ENRP server receives an ENRP message with an unknown message 1557 type or a message of known type that contains an unknown parameter, 1558 it SHOULD handle the unknown message or the unknown parameter 1559 according to the unrecognized message and parameter handling rules 1560 defined in Sections 3 and 4 in [10]. 1562 According to the rules, if an error report to the message sender is 1563 needed, the ENRP server that discovered the error SHOULD send back an 1564 ENRP_ERROR message with proper error cause code. 1566 5. Variables and Thresholds 1568 5.1 Variables 1570 peer.last.heard - the local time that a peer server was last heard 1571 (via receiving either a multicast or point-to-point message from 1572 the peer). 1574 pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server 1575 keeps for a peer. A separate PE checksum is kept for each of its 1576 known peers as well as for itself. 1578 5.2 Thresholds 1580 MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will 1581 make to contact an ENRP server (Default=3 times). 1583 TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will 1584 wait for a response from an ENRP server (Default=5 seconds). 1586 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1587 heartbeat message to all its known peers. (Default=30 secs.) 1589 SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a 1590 SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) 1592 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1593 will wait before considering a silent peer server potentially 1594 dead. (Default=61 secs.) 1596 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1597 sender will wait for a response after sending out a message. 1598 (Default=5 secs.) 1600 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a 1601 PE that an ENRP server will allow before purging this PE from the 1602 namespace. (Default=3) 1604 6. Security Considerations 1606 Threats Introduced by Rserpool and Requirements for Security in 1607 Response to Threats [11] describes the threats to the Rserpool 1608 architecture in detail and lists the security requirements in 1609 response to each threat. From the threats described in this document, 1610 the security services required for the Rserpool protocol are 1611 enumerated below. 1613 Threat 1) PE registration/deregistration flooding or spoofing 1614 ----------- 1615 Security mechanism in response: ENRP server authenticates the PE 1617 Threat 2) PE registers with a malicious ENRP server 1618 ----------- 1619 Security mechanism in response: PE authenticates the ENRP server 1621 Threat 1 and 2 taken together results in mutual authentication of the 1622 ENRP server and the PE. 1624 Threat 3) Malicious ENRP server joins the ENRP server pool 1625 ----------- 1626 Security mechanism in response: ENRP servers mutually authenticate 1628 Threat 4) A PU communicates with a malicious ENRP server for name 1629 resolution 1630 ----------- 1631 Security mechanism in response: The PU authenticates the ENRP server 1633 Threat 5) Replay attack 1634 ----------- 1635 Security mechanism in response: Security protocol which has 1636 protection from replay attacks 1638 Threat 6) Corrupted data which causes a PU to have misinformation 1639 concerning a pool handle resolution 1640 ----------- 1641 Security mechanism in response: Security protocol which supports 1642 integrity protection 1644 Threat 7) Eavesdropper snooping on namespace information 1645 ----------- 1646 Security mechanism in response: Security protocol which supports data 1647 confidentiality 1649 Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP 1650 server 1651 ----------- 1652 Security mechanism in response: ASAP must control the number of 1653 endpoint unreachable messages transmitted from the PU to the ENRP 1654 server. 1656 Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the 1657 ENRP server 1658 ----------- 1659 Security mechanism in response: ENRP server must control the number 1660 of Endpoint_KeepAlive messages to the PE 1662 To summarize the threats 1-7 require security mechanisms which 1663 support authentication, integrity, data confidentiality, protection 1664 from replay attacks. 1666 For Rserpool we need to authenticate the following: 1668 PU <---- ENRP Server (PU authenticates the ENRP server) 1669 PE <----> ENRP Server (mutual authentication) 1670 ENRP server <-----> ENRP Server (mutual authentication) 1672 We do not define any new security mechanisms specifically for 1673 responding to threats 1-7. Rather we use existing IETF security 1674 protocols to provide the security services required. TLS supports all 1675 these requirements and MUST be implemented. The 1676 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a 1677 minimum by implementers of TLS for Rserpool. For purposes of 1678 backwards compatibility, ENRP SHOULD support 1679 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 1680 other ciphersuite. 1682 Threat 8 requires the ASAP protocol to limit the number of 1683 Endpoint_Unreachable messages (see Section 3.5??? in [1]) to the ENRP 1684 server. 1686 Threat 9 requires the ENRP protocol to limit the number of 1687 Endpoint_KeepAlive messages to the PE (see Section x.y???). 1689 6.1 Implementing Security Mechanisms 1691 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must 1692 support mutual authentication. ENRP servers must support mutual 1693 authentication among themselves. PUs MUST authenticate ENRP servers. 1695 ENRP servers and PEs SHOULD possess a site certificate whose subject 1696 corresponds to their canonical hostname. PUs MAY have certificates 1697 of their own for mutual authentication with TLS, but no provisions 1698 are set forth in this document for their use. All Rserpool elements 1699 that support TLS MUST have a mechanism for validating certificates 1700 received during TLS negotiation; this entails possession of one or 1701 more root certificates issued by certificate authorities (preferably 1702 well-known distributors of site certificates comparable to those that 1703 issue root certificates for web browsers). 1705 Implementations MUST support TLS with SCTP as described in RFC3436 1706 [8] or TLS over TCP as described in RFC2246 [6]. When using TLS/SCTP 1707 we must ensure that RSerPool does not use any features of SCTP that 1708 are not available to an TLS/SCTP user. This is not a difficult 1709 technical problem, but simply a requirement. When describing an API 1710 of the RSerPool lower layer we have also to take into account the 1711 differences between TLS and SCTP. 1713 7. Acknowledgements 1715 The authors wish to thank John Loughney, Lyndon Ong, and many others 1716 for their invaluable comments. 1718 Normative References 1720 [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1721 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-08 1722 (work in progress), October 2003. 1724 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1725 J. and M. Stillman, "Requirements for Reliable Server Pooling", 1726 RFC 3237, January 2002. 1728 [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, 1729 "Architecture for Reliable Server Pooling", 1730 draft-ietf-rserpool-arch-07 (work in progress), October 2003. 1732 [4] Bradner, S., "The Internet Standards Process -- Revision 3", 1733 BCP 9, RFC 2026, October 1996. 1735 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1736 Levels", BCP 14, RFC 2119, March 1997. 1738 [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1739 2246, January 1999. 1741 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1742 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 1743 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1745 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC 1746 3436, December 2002. 1748 [9] 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 [10] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1753 Server Access Protocol (ASAP) and Endpoint Name Resolution 1754 (ENRP) common parameters document", 1755 draft-ietf-rserpool-common-param-05 (work in progress), October 1756 2003. 1758 [11] Stillman, M., "Threats Introduced by Rserpool and Requirements 1759 for Security in Response to Threats", 1760 draft-ietf-rserpool-threats-02 (work in progress), Sept 2003. 1762 Informative References 1764 [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1765 Recommendations for Security", RFC 1750, December 1994. 1767 Authors' Addresses 1769 Qiaobing Xie 1770 Motorola, Inc. 1771 1501 W. Shure Drive, 2-F9 1772 Arlington Heights, IL 60004 1773 US 1775 Phone: +1-847-632-3028 1776 EMail: qxie1@email.mot.com 1778 Randall R. Stewart 1779 Cisco 1780 24 Burning Bush Trail 1781 Crystal Lake, IL 60012 1782 US 1784 Phone: +1-815-477-2127 1785 EMail: rrs@cisco.com 1787 Maureen Stillman 1788 Nokia 1789 127 W. State Street 1790 Ithaca, NY 14850 1791 US 1793 Phone: +1 607 273 0724 62 1794 EMail: maureen.stillman@nokia.com 1796 Intellectual Property Statement 1798 The IETF takes no position regarding the validity or scope of any 1799 intellectual property or other rights that might be claimed to 1800 pertain to the implementation or use of the technology described in 1801 this document or the extent to which any license under such rights 1802 might or might not be available; neither does it represent that it 1803 has made any effort to identify any such rights. Information on the 1804 IETF's procedures with respect to rights in standards-track and 1805 standards-related documentation can be found in BCP-11. Copies of 1806 claims of rights made available for publication and any assurances of 1807 licenses to be made available, or the result of an attempt made to 1808 obtain a general license or permission for the use of such 1809 proprietary rights by implementors or users of this specification can 1810 be obtained from the IETF Secretariat. 1812 The IETF invites any interested party to bring to its attention any 1813 copyrights, patents or patent applications, or other proprietary 1814 rights which may cover technology that may be required to practice 1815 this standard. Please address the information to the IETF Executive 1816 Director. 1818 Full Copyright Statement 1820 Copyright (C) The Internet Society (2003). All Rights Reserved. 1822 This document and translations of it may be copied and furnished to 1823 others, and derivative works that comment on or otherwise explain it 1824 or assist in its implementation may be prepared, copied, published 1825 and distributed, in whole or in part, without restriction of any 1826 kind, provided that the above copyright notice and this paragraph are 1827 included on all such copies and derivative works. However, this 1828 document itself may not be modified in any way, such as by removing 1829 the copyright notice or references to the Internet Society or other 1830 Internet organizations, except as needed for the purpose of 1831 developing Internet standards in which case the procedures for 1832 copyrights defined in the Internet Standards process must be 1833 followed, or as required to translate it into languages other than 1834 English. 1836 The limited permissions granted above are perpetual and will not be 1837 revoked by the Internet Society or its successors or assignees. 1839 This document and the information contained herein is provided on an 1840 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1841 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1842 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1843 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1844 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1846 Acknowledgement 1848 Funding for the RFC Editor function is currently provided by the 1849 Internet Society.