idnits 2.17.1 draft-ietf-rserpool-enrp-06.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.) 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 (May 15, 2003) is 7652 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) -- Looks like a reference, but probably isn't: 'TBD' on line 1431 == Unused Reference: '4' is defined on line 1576, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-05 ** 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-03 ** 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 (-05) exists of draft-ietf-ipsec-sctp-03 == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '10') -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. '11') (Obsoleted by RFC 4086) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: November 13, 2003 R. Stewart 5 Cisco 6 M. Stillman 7 Nokia 8 May 15, 2003 10 Endpoint Name Resolution Protocol (ENRP) 11 draft-ietf-rserpool-enrp-06.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 November 13, 2003. 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 . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 27 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 . . . . . . 31 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 . . . . . . . . . . . . . . 32 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 Prodecures . . . . . . . . . . . . . . . . . . . 35 91 4.11.2 Re-synchronization Prodecures . . . . . . . . . . . . . . 35 92 4.12 Handling Unrecognized Message or Unrecognized Parameter . 36 93 5. Variables and Time Constants . . . . . . . . . . . . . . . 37 94 5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 37 95 5.2 Timer Constants . . . . . . . . . . . . . . . . . . . . . 37 96 6. Security Considerations . . . . . . . . . . . . . . . . . 38 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 39 98 Normative References . . . . . . . . . . . . . . . . . . . 40 99 Informative References . . . . . . . . . . . . . . . . . . 41 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 41 101 Intellectual Property and Copyright Statements . . . . . . 42 103 1. Introduction 105 ENRP is designed to work in conjunction with ASAP [1] to accomplish 106 the functionality of Rserpool as defined by its requirements [2] and 107 architecture [3]. 109 Within the operation scope of Rserpool, ENRP defines the procedures 110 and message formats of a distributed fault-tolerant registry service 111 for storing, bookkeeping, retrieving, and distributing pool operation 112 and membership information. 114 Whenever appropriate, in the rest of this document we will refer to 115 this Rserpool registry service as ENRP namespace, or simply 116 namespace. 118 1.1 Definitions 120 This document uses the following terms: 122 Operation scope: See [3]; 124 Pool (or server pool): See [3]; 126 Pool handle (or pool name): See [3]; 128 Pool element (PE): See [3]; 130 Pool user (PU): See [3]; 132 Pool element handle: See [3]; 134 ENRP namespace (or namespace): See [3]; 136 ENRP namespace server (or ENRP server): See [3]; 138 ENRP client channel: The communication channel through which a PE 139 requests for ENRP namespace service. The ENRP client channel is 140 usually defined by the transport address of the home ENRP server 141 and a well known port number; 143 ENRP server channel: Defined by a well known multicast IP address and 144 a well known port number. All ENRP servers in an operation scope 145 can send multicast messages to other servers through this channel. 146 PEs are also allowed to multicast on this channel occasionally; 148 Home ENRP server: The ENRP server to which a PE or PU currently 149 belongs. A PE MUST only have one home ENRP server at any given 150 time and both the PE and its home ENRP server MUST keep track of 151 this master/slave relationship between them. A PU SHOULD select 152 one of the available ENRP servers as its home ENRP server, but the 153 ENRP server does not need to know, nor does it need to keep track 154 of this relationship. 156 2. Conventions 158 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 159 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 160 they appear in this document, are to be interpreted as described in 161 [5]. 163 3. ENRP Message Definitions 165 In this section, we defines the format of all ENRP messages. These 166 are messages sent and received amongst ENRP servers in an operation 167 scope. Messages sent and received between a PE/PU and an ENRP server 168 are part of ASAP and are defined in [1]. A common format, defined in 169 [10], is used for all ENRP and ASAP messages. 171 Most ENRP messages contains a combination of fixed fields and TLV 172 parameters. The TLV parameters are also defined in [10]. 174 All messages, as well as their fields/parameters described below, 175 MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., 176 the most significant byte first). 178 For ENRP, the following message types are defined: 180 Type Message Name 181 ----- ------------------------- 182 0x0 - (reserved by IETF) 183 0x1 - PEER_PRESENCE 184 0x2 - PEER_NAME_TABLE_REQUEST 185 0x3 - PEER_NAME_TABLE_RESPONSE 186 0x4 - PEER_NAME_UPDATE 187 0x5 - PEER_LIST_REQUEST 188 0x6 - PEER_LIST_RESPONSE 189 0x7 - PEER_INIT_TAKEOVER 190 0x8 - PEER_INIT_TAKEOVER_ACK 191 0x9 - PEER_TAKEOVER_SERVER 192 0xa - PEER_OWNERSHIP_CHANGE 193 0xb - PEER_ERROR 194 0xc-0xFF - (reserved by IETF) 196 3.1 PEER_PRESENCE message 198 This ENRP message is used to announce (periodically) the presence of 199 an ENRP server, or to probe the status of a peer ENRP sever. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Sender Server's ID | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Receiver Server's ID | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 : Server Information Param (optional) : 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 R (reply_required) flag: 1 bit 215 Set to '1' if the sender requires a response to this message, 216 otherwise set to '0'. 218 Sender Server's ID: 32 bit (unsiged integer) 220 This is the ID of the ENRP server which sends the message. 222 Receiver Server's ID: 32 bit (unsiged integer) 224 This is the ID of the ENRP server to which the message is 225 intended. If the message is not intended to an individual 226 server (e.g., the message is multicasted to a group of 227 servers), this field MUST be set with all 0's. 229 Server Information Parameter: 231 If present, contains the server information of the sender of 232 this message (Server Information Parameter is defined in [10]). 233 This parameter is optional. However, if this message is sent in 234 response to a received "reply required" PEER_PRESENCE from a 235 peer, the sender then MUST include its server information. 237 Note, at startup an ENRP server MUST pick a randomly generated, 238 non-zero 32-bit unsigned integer as its ID and MUST use this same ID 239 for its entire life. 241 3.2 PEER_NAME_TABLE_REQUEST message 243 An ENRP server sends this message to one of its peers to request a 244 copy of the namespace data. This message is normally used during 245 server initialization or namespace re-synchronization. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = 0x2 |0|0|0|0|0|0|0|W| Message Length = 0xC | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Sender Server's ID | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Receiver Server's ID | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 W (oWn-children-only) flag: 1 bit 259 Set to '1' if the sender of this message is only requesting 260 information about the PEs owned by the message receiver. 261 Otherwise, set to '0'. 263 Sender Server's ID: 265 See Section 3.1. 267 Receiver Server's ID: 269 See Section 3.1. 271 3.3 PEER_NAME_TABLE_RESPONSE message 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type = 0x3 |0|0|0|0|0|0|R|M| Message Length | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Sender Server's ID | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Receiver Server's ID | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 : : 282 : Pool entry #1 (see below) : 283 : : 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 : : 286 : ... : 287 : : 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 : : 290 : Pool entry #n (see below) : 291 : : 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 R (Reject) flag: 1 bit 296 MUST be set to '1' if the sender of this message is rejecting a 297 namespace request. In such a case, this message MUST be sent 298 with no pool entries included. 300 M (More_to_send) flag: 1 bit 302 Set to '1' if the sender has more pool entries to sent in 303 subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set to 304 '0'. 306 Message Length: 16 bits (unsigned integer) 308 Indicates the entire length of the message in number of octets. 310 Note, the value in Message Length field will NOT cover any 311 padding at the end of this message. 313 Sender Server's ID: 315 See Section 3.1. 317 Receiver Server's ID: 319 See Section 3.1. 321 Pool entry #1-#n: 323 If R flag is '0', at least one pool entry SHOULD be present in 324 the message. Each pool entry MUST start with a pool handle 325 parameter as defined in section 3.1.7, followed by one or more 326 pool element parameters, i.e.: 328 +---------------------------+ 329 : Pool handle : 330 +---------------------------+ 331 : PE #1 : 332 +---------------------------+ 333 : PE #2 : 334 +---------------------------+ 335 : ... : 336 +---------------------------+ 337 : PE #n : 338 +---------------------------+ 340 3.4 PEER_NAME_UPDATE message 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Update Action | (reserved) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Sender Server's ID | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Receiver Server's ID | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 : Pool handle : 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 : Pool Element : 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Message Length: 16 bits (unsigned integer) 360 Indicates the entire length of the message in number of octets. 362 Note, the value in Message Length field will NOT cover any 363 padding at the end of this message. 365 Update Action: 16 bits (unsigned integer) 367 This field indicates what act is requested to the specified PE. 368 It MUST take one of the following values: 370 0x0 - ADD_PE: add or update the specified PE in the ENRP 371 namespace 373 0x1 - DEL_PE: delete the specified PE from the ENRP namespace. 375 Other values are reserved by IETF and MUST not be used. 377 Reserved: 16 bits 379 MUST be set to 0's by sender and ignored by the receiver. 381 Sender Server's ID: 383 See Section 3.1. 385 Receiver Server's ID: 387 See Section 3.1. 389 Pool handle: 391 Specifies to which the PE belongs. 393 Pool Element: 395 Specifies the PE. 397 3.5 PEER_LIST_REQUEST message 399 This ENRP message is used to request a copy of the current known ENRP 400 peer server list. This message is normally sent from a newly started 401 ENRP server to an existing ENRP server as part of the initialization 402 process of the new server. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length = 0xC | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Sender Server's ID | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Receiver Server's ID | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Sender Server's ID: 416 See Section 3.1. 418 Receiver Server's ID: 420 See Section 3.1. 422 3.6 PEER_LIST_RESPONSE message 424 This message is used to respond a PEER_LIST_REQUEST. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Sender Server's ID | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Receiver Server's ID | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 : Server Info Param of Peer #1 : 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 : ... : 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 : Server Info Param of Peer #n : 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 R (Reject) flag: 1 bit 444 MUST be set to '1' if the sender of this message is rejecting a 445 peer list request. In such a case, this message MUST be sent 446 with no peer server ID included. 448 Message Length: 16 bits (unsigned integer) 450 Indicates the entire length of the message in number of octets. 452 Note, the value in Message Length field will NOT cover any 453 padding at the end of this message. 455 Sender Server's ID: 457 See Section 3.1. 459 Receiver Server's ID: 461 See Section 3.1. 463 Server Information Parameter of Peer #1-#n: 465 Each contains a Server Information Parameter of a peer known to 466 the sender. The Server Information Parameter is defined in 467 [10]. 469 3.7 PEER_INIT_TAKEOVER message 471 This message is used by an ENRP server (the takeover initiator) to 472 declare its intention of taking over a specific peer ENRP server. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Sender Server's ID | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Receiver Server's ID | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Target Server's ID | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Sender Server's ID: 488 See Section 3.1. 490 Receiver Server's ID: 492 See Section 3.1. 494 Target Server's ID: 496 Contains the 32-bit server ID of the peer ENRP that is the 497 target of this takeover attempt. 499 3.8 PEER_INIT_TAKEOVER_ACK message 501 This message is used to acknowledge the takeover initiator that the 502 sender of this message received the PEER_INIT_TAKEOVER message and 503 that it does not object to the takeover. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Sender Server's ID | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Receiver Server's ID | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Target Server's ID | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Sender Server's ID: 519 See Section 3.1. 521 Receiver Server's ID: 523 See Section 3.1. 525 Target Server's ID: 527 Contains the 32-bit server ID of the peer ENRP that is the 528 target of this takeover attempt. 530 3.9 PEER_TAKEOVER_SERVER message 532 This message is used by the takeover initiator to declare that a 533 takeover is underway. 535 0 1 2 3 536 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type = 0x9 |0|0|0|0|0|0|0|0| Message Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Sender Server's ID | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Receiver Server's ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Target Server's ID | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Sender Server's ID: 549 See Section 3.1. 551 Receiver Server's ID: 553 See Section 3.1. 555 Target Server's ID: 557 Contains the 32-bit server ID of the peer ENRP that is the 558 target of this takeover operation. 560 3.10 PEER_OWNERSHIP_CHANGE message 562 This message is used by the ENRP server, normally after a successful 563 takeover, to declare that it is now the new home ENRP server of the 564 listed PEs in the listed pools. 566 0 1 2 3 567 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type = 0xa |0|0|0|0|0|0|0|0| Message Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Sender Server's ID | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Receiver Server's ID | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 : Pool handle #1 : 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 : PE Identifier Param #1 of pool #1 : 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 : ... : 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 : PE Identifier Param #k of pool #1 : 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 : : 584 : ... : 585 : : 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 : Pool handle #M : 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 : PE Identifier Param #1 of pool #M : 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 : ... : 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 : PE Identifier Param #n of pool #M : 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Sender Server's ID: 598 See Section 3.1. 600 Receiver Server's ID: 602 See Section 3.1. 604 Pool handles and PE Identifier parameters: 606 Each listed pool handle is followed by a list of PE Identifier 607 parameters, indicating that the sender of this message is 608 taking ownership of the listed PEs in the pool. 610 3.11 PEER_ERROR message 612 This message is used by an ENRP server to report an operation error 613 to one of its peers. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type = 0xb |0|0|0|0|0|0|0|0| Message Length | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Sender Server's ID | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Receiver Server's ID | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 : Operation Error Parameter : 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Sender Server's ID: 629 See Section 3.1. 631 Receiver Server's ID: 633 See Section 3.1. 635 Operation Error Parameter: 637 This parameter, defined in [10], indicates the type of error(s) 638 being reported. 640 4. ENRP Operation Procedures 642 In this section, we discuss the operation procedures defined by ENRP. 643 An ENRP server MUST following these procedures when sending, 644 receiving, or processing ENRP messages. 646 Many of the Rserpool events call for both server-to-server and PU/ 647 PE-to-server message exchanges. Only the message exchanges and 648 activities between an ENRP server and its peer(s) are considered 649 within the ENRP scope and are defined in this document. 651 Procedures for exchanging messages between a PE/PU and ENRP servers 652 are defined in [1]. 654 4.1 Methods for Communicating amongst ENRP Servers 656 Within an Rserpool operation scope, ENRP servers need to communicate 657 with each other in order to exchange information such as the pool 658 membership changes, namespace data synchronization, etc. 660 Two types of communications are used amongst ENRP servers: 662 o point-to-point message exchange from one ENPR server to a specific 663 peer server, and 665 o announcements from one server to all its peer servers in the 666 operation scope. 668 Point-to-point communication is always carried out over an SCTP 669 associaiton between the sending server and the receiving server. 671 Announcements are communicated out with one of the following two 672 approaches: 674 1. The sending server sends the announcement message to a well-known 675 RSERPOOL IP multicast channel that its peer servers subscribe to. 677 Note: Because IP multicast is not reliable, this approach does 678 not gaurrantee that all the peers will receive the announcement 679 message. Moreover, since IP multicast is not secure, this 680 approach cannot provide any security to the communication. 682 2. The sending server sends multiple copies of the announcement, one 683 to each of its peer servers, over a set of point-to-point SCTP 684 associations between the sending server and the peers. 686 This approach gaurrantees the reliabe receiption of the message. 687 When needed, data security can be achieved by using IP security 688 mechanisms such as IPsec [9] or TLS [8]. 690 In order to maximize inter-operability of ENRP servers, the following 691 rules MUST be followed: 693 1. At the startup time, a new ENRP server SHOULD make a decision on 694 whether it will enable IP multicast for ENRP announcements. This 695 decision should be based on factors such as the availability of 696 IP multicast and the security requirements from the user of 697 Rserpool. 699 2. If an ENRP server disables multicast, it then: 701 A. MUST NOT subscribe to the well-known server multicast 702 channel, i.e., it only receives peer announcements over SCTP 703 associations, and 705 B. MUST transmit all its out-going announcements over 706 point-to-point SCTP associations with its peers. 708 3. If an ENRP server enables itself to use multicast, it then: 710 A. MUST subcribe to the well-known server multicast channel to 711 ready itself for receiving peers' multicast announcements, 713 B. MUST also be prepared to receive peer announcements over 714 point-to-point SCTP associations from peers. 716 C. MUST track internally which peers are multicast-enabled and 717 which are not. Note: A peer is always assumed to be 718 multicast-disabled until/unless an ENRP message of any type 719 is received from that peer over the well-known server 720 multicast channel. 722 D. when sending out an announcement, MUST send a copy to the 723 well-known server multicast channel AND a copy to each of the 724 peers that are marked as multicast-disabled over a 725 point-to-point SCTP association. 727 4.2 ENRP Server Initialization 729 This section describes the steps a new ENRP server needs to take in 730 order to join the other existing ENRP servers, or to initiate the 731 namespace service if it is the first ENRP server started in the 732 operation scope. 734 4.2.1 Generate a Server Identifier 736 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 737 as unique as possible in the operation scope and this server Id MUST 738 remain unchanged for the lifetime of the server. Normally, a good 739 32-bit random number will be good enough as the server Id ([11] 740 provides some information on randomness guidelines). 742 4.2.2 Acquire Peer Server List 744 At startup, the ENRP server (initiating server) will first attempt to 745 learn all existing peer ENRP servers in the same operation scope, or 746 to determine that it is along in the scope. 748 The initiating server uses an existing peer server to bootstrap 749 itself into service. We call this peer server the mentor server. 751 4.2.2.1 Find the mentor server 753 If the initiating server is told about an existing peer server 754 through some administrative means (such as DNS query, configuration 755 database, startup scripts, etc), the initiating server SHOULD then 756 use this peer server as its mentor server and SHOULD skip the 757 remaining steps in this subsection. 759 If multiple existing peer servers are specified, the initiating 760 server SHOULD pick one of them as its mentor peer server, keep the 761 others as its backup menter peers, and skip the remaining steps in 762 this subsection. 764 If no existing peer server is specified to the initiating server AND 765 if multicast is available in the operation scope, the following 766 mentor peer discovery procedures SHOULD be followed: 768 1. The initiating server SHOULD first join the well-known ENRP 769 server multicast channel. 771 2. Then the initiating server SHOULD send a PEER_PRESENCE message, 772 with the 'Reply_required' flag set, over the multicast channel. 773 Upon the reception of this PEER_PRESENCE message, a peer server 774 MUST send a PEER_PRESENCE, without the 'Reply_required' flag, 775 back to the initiating server. 777 3. When the first response to its original PEER_PRESENCE arrives, 778 the initiating server SHOULD take the sender of this received 779 response as its mentor peer server. This completes the discovery 780 of the mentor peer server. 782 If responses are also received from other peers (a likely event 783 when multiple peers exist in the operation scope at the time the 784 new server started), the initiating server SHOULD keep a list of 785 those responded as its backup mentor peers (see below). 787 4. If no response to its PEER_PRESENCE message are received after 788 TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat 789 steps 2) and 3) for up to MAX-TIME-SERVER-HUNT times. After that, 790 if there is still no response, the initiating server MUST assume 791 that it is alone in the operation scope. 793 5. If the initiating server determined that it is alone in the 794 scope, it MUST skip the procedures in Section 4.2.2.2 and Section 795 4.2.3 and MUST consider its initialization completed and start 796 offering ENRP services. 798 Note, if multicast is not available (or not allowed for reasons such 799 as security concerns) in the operation scope, at least one peer 800 server MUST be specified to the initiating server through 801 administrative means, unless the initiation server is the first 802 server to start in the operation scope. 804 Note, if the administratively specified menter peer(s) fails, the 805 initiating server SHOULD use the auto-discover procedure defined in 806 steps 1-5 above. 808 4.2.2.2 Request complete server list from mentor peer 810 Once the initiating server finds its mentor peer server (by either 811 discovery or administrative means), the initiating server MUST send a 812 PEER_LIST_REQUEST message to the mentor peer server to request a copy 813 of the complete server list maintained by the mentor peer (see 814 Section 4.9 for maintaining server list). 816 Upon the reception of this request, the mentor peer server SHOULD 817 reply with a PEER_LIST_RESPONSE message and include in the message 818 body all existing ENRP servers known by the mentor peer. 820 Upon the reception of the PEER_LIST_RESPONSE message from the mentor 821 peer, the initiating server MUST use the server information carried 822 in the message to initialize its own peer list. 824 However, if the mentor itself is in the process of startup and not 825 ready to provide a peer server list (for example, the mentor peer is 826 waiting for a response to its own PEER_LIST_REQUEST to another 827 server), it MUST rejest the request by the initiating server and 828 respond with a PEER_LIST_RESPONSE message with the R flag set to '1', 829 and with no server information included in the response. 831 In the case where its PEER_LIST_REQUEST is rejected by the mentor 832 peer, the initiating server SHOULD either wait for a few seconds and 833 re-send the PEER_LIST_REQUEST to the mentor server, or if there is a 834 backup mentor peer available, select another mentor peer server and 835 send the PEER_LIST_REQUEST to the new mentor server. 837 4.2.3 Download ENRP Namespace Data from Mentor Peer 839 After a peer list download is completed, the initiating server MUST 840 request a copy of the current namespace data from its mentor peer 841 server, by taking the following steps: 843 1. The initiating server MUST first send a PEER_NAME_TABLE_REQUEST 844 message to the mentor peer, with W flag set to '0', indicating 845 that the entire namespace is requested. 847 2. Upon the reception of this message, the mentor peer MUST start a 848 download session in which a copy of the current namespace data 849 maintained by the mentor peer is sent to the initiating server in 850 one or more PEER_NAME_TABLE_RESPONSE messages (Note, the mentor 851 server may find it particularly desirable to use multiple 852 PEER_NAME_TABLE_RESPONSE messages to send the namespace when the 853 namespace is large, especially when forming and sending out a 854 single response containing a large namespace may interrupt its 855 other services). 857 If more than one PEER_NAME_TABLE_RESPONSE message are used during 858 the download, the mentor peer MUST use the M flag in each 859 PEER_NAME_TABLE_RESPONSE message to indicate whether this message 860 is the last one for the download session. In particular, the 861 mentor peer MUST set the M flag to '1' in the outbound 862 PEER_NAME_TABLE_RESPONSE if there is more data to be transferred 863 and MUST keep track of the progress of the current download 864 session. The mentor peer MUST set the M flag to '0' in the last 865 PEER_NAME_TABLE_RESPONSE for the download session and close the 866 download session (i.e., removing any internal record of the 867 session) after sending out the last message. 869 3. During the downloading, every time the initiating server receives 870 a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data 871 entries carried in the message into its local namespace database, 872 and then check whether or not this message is the last one for 873 the download session. 875 If the M flag is set to '1' in the just processed 876 PEER_NAME_TABLE_RESPONSE message, the initiating server MUST send 877 another PEER_NAME_TABLE_REQUEST message to the mentor peer to 878 request for the next PEER_NAME_TABLE_RESPONSE message. 880 4. When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 881 message into its local namespace database, the initiating server 882 MUST handle each pool entry carried in the message using the 883 following rules: 885 A. If the pool does not exist in the local namespace, the 886 initiating server MUST creates the pool in the local 887 namespace and add the PE(s) in the pool entry to the pool. 889 When creating the pool, the initiation server MUST set the 890 overall member selection policy type of the pool to the 891 policy type indicated in the first PE. 893 B. If the pool already exists in the local namespace, but the 894 PE(s) in the pool entry is not currently a member of the 895 pool, the initiating server MUST add the PE(s) to the pool. 897 C. If the pool already exists in the local namespace AND the 898 PE(s) in the Pool entry is already a member of the pool, the 899 initiating server server SHOULD replace the attributes of the 900 existing PE(s) with the new information. 902 5. When the last PEER_NAME_TABLE_RESPONSE message is received from 903 the mentor peer and unpacked into the local namespace, the 904 initialization process is completed and the initiating server 905 SHOULD start to provide ENRP services. 907 Under certain circumstances, the mentor peer itself may not be able 908 to provide a namespace download to the initiating server. For 909 example, the mentor peer is in the middle of initializing its own 910 namespace database, or it has currently too many download sessions 911 open to other servers. 913 In such a case, the mentor peer MUST rejest the request by the 914 initiating server and respond with a PEER_NAME_TABLE_RESPONSE message 915 with the R flag set to '1', and with no pool entries included in the 916 response. 918 In the case where its PEER_NAME_TABLE_REQUEST is rejected by the 919 mentor peer, the initiating server SHOULD either wait for a few 920 seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server, 921 or if there is a backup mentor peer available, select another mentor 922 peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor 923 server. 925 A started namespace download session may get interrupted for some 926 reason. To cope with this, the initiating server SHOULD start a timer 927 everytime it finishes sending a PEER_NAME_TABLE_REQUEST to its mentor 928 peer. If this timer expires without receiving a response from the 929 mentor peer, the initiating server SHOULD abort the current download 930 session and re-start a new namespace download with a backup mentor 931 peer, if one is available. 933 Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the 934 mentor peer has still more data to send, it SHOULD start a session 935 timer. If this timer expires without receiving another request from 936 the initiating server, the mentor peer SHOULD abort the session, 937 cleaning out any resource and record of the session. 939 4.3 Handle PE Registration 941 To register itself with the namespace, a PE sends a REGISTRATION 942 message to its home ENRP server. The format of REGISTRATION message 943 and rules of sending it are defined in [1]. 945 In the REGISTRATION message, the PE indicates the name of the pool it 946 wishes to join in a pool handle parameter, and its complete transport 947 information and any load control information in a PE parameter. 949 The ENRP server handles the REGISTRATION message according to the 950 following rules: 952 1. If the named pool does not exist in the namespace, the ENRP 953 server MUST creates a new pool with that name in the namespace 954 and add the PE to the pool as its first PE; 956 When a new pool is created, the overall member selection policy 957 of the pool MUST be set to the policy type indicated by the first 958 PE, the overall pool transport type MUST be set to the transport 959 type indicated by the PE, and the overall pool data/control 960 channel configuration MUST be set to what is indicated in the 961 Transport Use field of the User Transport parameter by the 962 registering PE. 964 2. If the named pool already exists in the namespace, but the 965 requesting PE is not currently a member of the pool, the ENRP 966 server will add the PE as a new member to the pool; 968 However, before adding the PE to the pool, the server MUST check 969 if the policy type, transport type, and transport usage indicated 970 by the registering PE is consistent with those of the pool. If 971 different, the ENRP server MUST either attempt to override the 972 PE's value(s) or to reject the registration if overriding is not 973 possible. 975 A. Inconsistent policy - If no additional policy-related 976 information are required to perform an override of pool 977 policy (e.g., overriding Least-used with Round-robin does not 978 require additional policy-related information), the ENRP 979 server MUST replace the PE's policy type with the overall 980 policy type of the pool. However, if additional policy 981 information is required for the overriding (e.g., overriding 982 Round-robin with Least-load will require the knowledge of the 983 load factor of the PE), the ENRP server MUST reject the 984 registration. 986 B. Inconsistent transport type - The ENRP server MUST reject the 987 registration. 989 C. Inconsistent data/control configuration - If the overall pool 990 configuration is "DATA ONLY", and the registering PE 991 indicates "CONTORL plus DATA", the ENRP server SHOULD accept 992 the registration but warn the PE that control channel cannot 993 be used. If the pool configuration is "CONTROL plus DATA" and 994 the PE indicates "DATA ONLY", the ENRP server MUST reject the 995 registration. 997 3. If the named pool already exists in the namespace AND the 998 requesting PE is already a member of the pool, the ENRP server 999 SHOULD consider this as a re-registration case. The ENRP server 1000 MUST perform the same tests on policy, transport type, transport 1001 use, as described above. If the re-registration is accepted after 1002 the test, the ENRP Server SHOULD replace the attributes of the 1003 existing PE with the information carried in the received 1004 REGISTRATION message. 1006 4. After accepting the registration, the ENRP server MUST assgin 1007 itself the owner of this PE. If this is a re-registration, the 1008 ENRP server MUST take over ownership of this PE regardless of 1009 whether the PE was previously owned by this server or by another 1010 server. 1012 5. The ENRP server may reject the registration due to reasons such 1013 as invalid values, lack of resource, authentication failure, etc. 1015 In all above cases, the ENRP server MUST reply to the requesting PE 1016 with a REGISTRATION_RESPONSE message. If the registration is 1017 accepted, the ENRP server MUST set the 'R' flag in the 1018 REGISTRATION_RESPONSE to '0'. If the registration is rejected, the 1019 ENRP server MUST indicate the rejection by setting the 'R' flag in 1020 the REGISTRATION_RESPONSE to '1'. 1022 If the registration is rejected, the ENRP server SHOULD include the 1023 proper error cause(s) in the REGISTRATION_RESPONSE message. 1025 If the registration is granted but with an override of some PE's 1026 original values, in the REGISTRATION_RESPONSE message the ENRP server 1027 SHOULD include the proper error cause(s) so that the PE can be warned 1028 about the overriding and be informed about the new value(s). 1030 If the registration is granted (either a new registration or a 1031 re-registration case), the ENRP server MUST assign itself to be the 1032 home ENRP server of the PE, i.e., to "own" the PE. 1034 Implementation note: for better performance, the ENRP server may 1035 find it both efficient and convenient to internally maintain two 1036 separate PE lists or tables - one is for the PEs that are "owned" 1037 by the ENRP server and the other for all the PEs owned by its 1038 peer(s). 1040 Moreover, if the registration is granted, the ENRP server MUST take 1041 the namespace update action as described in Section 4.6 to inform its 1042 peers about the change just made. If the registration is denied, no 1043 message will be sent to its peers. 1045 4.3.1 Rules on PE Re-registration 1047 A PE may re-register itself to the namespace with a new set of 1048 attributtes in order to, for example, extend its registration life, 1049 change its load factor value, etc. 1051 A PE may modify its load factor value at any time via 1052 re-registration. Based on the number of PEs in the pool and the 1053 pool's overall policy type, this operation allows the PE to 1054 dynamically control its share of inbound messages received by the 1055 pool (also see Section ???? in [1] for more on load control). 1057 Moreover, when re-registering, the PE MUST NOT change its policy 1058 type. The server MUST reject the re-registration if the PE attempt to 1059 change its policy type. In the rejection, the server SHOULD attach an 1060 error code "Pooling Policy Inconsistent". 1062 Regardless whether it is the current owner of the PE, if the 1063 re-registration is granted to the PE, the ENRP server MUST assign 1064 itself to be the new home ENRP server of the PE. 1066 Moreover, if the re-registration is granted, the ENRP server MUST 1067 take the namespace update action as described in Section 4.6 to 1068 inform its peers about the change just made. If the re-registration 1069 is denied, no message will be sent to its peers. 1071 4.4 Handle PE De-registration 1072 To remove itself from a pool, a PE sends a DEREGISTRATION message to 1073 its home ENRP server. The complete format of DEREGISTRATION message 1074 and rules of sending it are defined in [1]. 1076 In the DEREGISTRATION message the PE indicates the name of the pool 1077 it belongs to in a pool handle parameter and provides its PE 1078 identifer. 1080 Upon receiving the message, the ENRP server SHALL remove the PE from 1081 its namespace. Moreover, if the PE is the last one of the named pool, 1082 the ENRP server will remove the pool from the namespace as well. 1084 If the ENRP server fails to find any record of the PE in its 1085 namespace, it SHOULD consider the de-registration granted and 1086 completed. 1088 The ENRP server may reject the de-registration request for various 1089 reasons, such as invalid parameters, authentication failure, etc. 1091 In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE 1092 message to the PE. If the de-registration is rejected, the ENRP 1093 server MUST indicate the rejection by including the proper Operation 1094 Error parameter. 1096 It should be noted that de-registration does not stop the PE from 1097 sending or receiving application messages. 1099 Once the de-registration request is granted AND the PE removed from 1100 its local copy of the namespace, the ENRP server MUST take the 1101 namespace update action described in Section 4.6 to inform its peers 1102 about the change just made. Otherwise, NO message SHALL be send to 1103 its peers. 1105 4.5 Pool Handle Translation 1107 A PU uses the pool handle translation service of an ENRP server to 1108 resolve a pool handle to a list of accessible transport addresses of 1109 the member PEs of the pool. 1111 This requires the PU to send a NAME_RESOLUTION message to its home 1112 ENRP server and in the NAME_RESOLUTION message specify the pool 1113 handle to be translated in a Pool Handle parameter. Complete 1114 defintion of the NAME_RESOLUTION message and the rules of sending it 1115 are defined in [1]. 1117 An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests 1118 from PUs either over an SCTP associaiton on the well-know SCTP port, 1119 or over a TCP connection on the well-know TCP port. 1121 Upon reception of the NAME_RESOLUTION message, the ENRP server MUST 1122 first look up the pool handle in its namespace. If the pool exits, 1123 the home ENRP server MUST compose and send back a 1124 NAME_RESOLUTION_RESPONSE message to the requesting PU. 1126 In the response message, the ENRP server MUST list all the PEs 1127 currently registered in this pool, in a list of PE parameters. The 1128 ENRP server MUST also include a pool member selection policy 1129 parameter to indicate the overall member selection policy for the 1130 pool, if the current pool member selection policy is not round-robin 1131 (if the overall policy is round-Robin, this parameter MAY be 1132 omitted?). 1134 If the named pool does not exist in the namespace, the ENRP server 1135 MUST respond with a NAME_UNKNOWN message. 1137 The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN 1138 messages and the rules of receiving them are defined in [1]. 1140 4.6 Server Namespace Update 1142 This includes a set of update operations used by an ENRP server to 1143 inform its peers when its local namespace is modified, e.g., addition 1144 of a new PE, removal of an existing PE, change of pool or PE 1145 properties. 1147 4.6.1 Announcing Addition or Update of PE 1149 When a new PE is granted registration to the namespace or an existing 1150 PE is granted a re-registration, the home ENRP server uses this 1151 procedure to inform all its peers. 1153 This is an ENRP announcement and is sent to all the peer of the home 1154 ENRP server. See Section 4.1 on how annoucements are sent. 1156 An ENRP server MUST announce this update to all its peers in a 1157 PEER_NAME_UPDATE message with the Update Action field set to ADD_PE, 1158 indicating the addition of a new PE or the modification of an 1159 existing PE. The complete new information of the PE and the pool its 1160 belongs to MUST be indicated in the message with a PE parameter and a 1161 Pool Handle parameter, respectively. 1163 The home ENRP server SHOULD fill in its server Id in the Sender 1164 Server's ID field and leave the Receiver Server's ID blank (i.e., all 1165 0's). 1167 When a peer receives this PEER_NAME_UPDATE message, it MUST take the 1168 following actions: 1170 1. If the named pool indicated by the pool handle does not exist in 1171 its local copy of the namespace, the peer MUST create the named 1172 pool in its local namespace and add the PE to the pool as the 1173 first PE. It MUST then copy in all other attributes of the PE 1174 carried in the message. 1176 When the new pool is created, the overall member selection policy 1177 of the pool MUST be set to the policy type indicated by the PE. 1179 2. If the named pool already exists in the peer's local copy of the 1180 namespace AND the PE does not exist, the peer MUST add the PE to 1181 the pool as a new PE and copy in all attributes of the PE carried 1182 in the message. 1184 3. If the named pool exists AND the PE is already a member of the 1185 pool, the peer MUST replace the attributes of the PE with the new 1186 information carried in the message. 1188 4.6.2 Announcing Removal of PE 1190 When an existing PE is granted de-registration or is removed from its 1191 namespace for some other reasons (e.g., purging an unreachable PE, 1192 see Section 4.7), the ENRP server MUST uses this procedure to inform 1193 all its peers about the change just made. 1195 This is an ENRP announcement and is sent to all the peer of the home 1196 ENRP server. See Section 4.1 on how annoucements are sent. 1198 An ENRP server MUST announce the PE removal to all its peers in a 1199 PEER_NAME_UPDATE message with the Update Action field set to DEL_PE, 1200 indicating the removal of an existing PE. The complete information of 1201 the PE and the pool its belongs to MUST be indicated in the message 1202 with a PE parameter and a Pool Handle parameter, respectively. 1204 [editor's note: only the pool handle and the PE's id are needed, it 1205 should reduce the size of the message] 1207 The sending server MUST fill in its server ID in the Sender Server's 1208 ID field and leave the Receiver Server's ID blank (i.e., set to all 1209 0's). 1211 When a peer receives this PEER_NAME_UPDATE message, it MUST first 1212 find pool and the PE in its own namespace, and then remove the PE 1213 from its local namespace. If the removed PE is the last one in the 1214 pool, the peer MUST also delete the pool from its local namespace. 1216 If the peer fails to find the PE or the pool in its namespace, it 1217 SHOULD take no further actions. 1219 4.7 Detecting and Removing Unreachable PE 1221 Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 1222 Notification, see section 10.2 of [7]), the PU SHOULD send an 1223 ENDPOINT_UNREACHABLE message to its home ENRP server. The message 1224 SHOULD contain the pool handle and the PE Id of the unreachable PE. 1226 Upon the reception of an ENDPOINT_UNREACHABLE message, a server MUST 1227 immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the 1228 PE in question. If this ENDPOINT_KEEP_ALIVE fails (e.g., it results 1229 in an SCTP SEND.FAILURE notification), the ENRP server MUST consider 1230 the PE as truly unreachable and MUST remove the PE from its namespace 1231 and take actions described in Section 4.6.2. 1233 If the ENDPOINT_UNREACHABLE message is transmitted successfully to 1234 the PE, the ENRP server MUST retain the PE in its namespace. 1235 Moreover, the server SHOULD keep a counter to record how many 1236 ENDPOINT_UNREACHABLE messages it has received reporting reachability 1237 problem relating to this PE. If the counter exceeds the protocol 1238 threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE 1239 from its namespace and take actions described in Section 4.6.2. 1241 Optionally, an ENRP server may also periodically send point-to-point 1242 ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP 1243 server in order to check their reachability status. If the send of 1244 ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the 1245 PE as unreachable and MUST remove the PE from its namespace and take 1246 actions described in Section 4.6.2. Note, if an ENRP server owns a 1247 large number of PEs, the implementation should pay attention not to 1248 flood the network with bursts of ENDPOINT_KEEP_ALIVE messages. 1249 Instead, the implementation should try to smooth out the 1250 ENDPOINT_KEEP_ALIVE message traffic over time. 1252 The complete definition and rules of sending ENDPOINT_UNREACHABLE and 1253 receiving ENDPOINT_KEEP_ALIVE messages are described in [1]. 1255 4.8 Helping PE and PU to Discover Home ENRP Server 1257 At its startup time, or whenever its current home ENRP server is not 1258 providing services, a PE or PU will attempt to find a new home 1259 server. For this reason, the PE or PU will need to maintain a list of 1260 currently available ENRP servers in its scope. 1262 To help the PE or PU maintaining this list, an ENRP server, if it is 1263 enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE 1264 message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP 1265 multicast channel. And in the SERVER_ANNOUNE message the ENRP server 1266 SHOULD include all the transport addresses available for ASAP 1267 communications. If the ENRP server only supports SCTP for ASAP 1268 communications, the transport information MAY be omitted in the 1269 SERVER_ANNOUNCE message. 1271 For the complete procedure of this, see Section 3.6?? in [1]. 1273 4.9 Maintaining Peer List and Monitoring Peer Status 1275 An ENRP server MUST keep an internal record on the status of each of 1276 its known peers. This record is referred to as the server's "peer 1277 list" 1279 4.9.1 Discovering New Peer 1281 If a message of any type is received from a previously unknown peer, 1282 the ENRP server MUST consider this peer a new peer in the operation 1283 scope and add it to the peer list. 1285 The ENRP server MUST send a PEER_PRESENCE message with the 1286 Reply-required flag set to '1' to the source address found in the 1287 arrived message. This will force the new peer to reply with its own 1288 PEER_PRESENCE containing its full server information (see Section 1289 3.1). 1291 [editor's note: should we ask for a peer list from the new peer? 1292 this may help mending two splitted networks.] 1294 4.9.2 Server Sending Heartbeat 1296 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 1297 continued presence to all its peer with a PEER_PRESENCE message. In 1298 the PEER_PRESENCE message, the ENRP server MUST set the 1299 'Replay_required' flag to '0', indicating that no response is 1300 required. 1302 The arrival of this periodic PEER_PRESENCE message will cause all its 1303 peers to update their internal variable "Peer-last-heared" for the 1304 sending server (see Section 4.9.3 for more details). 1306 4.9.3 Detecting Peer Server Failure 1308 An ENRP server MUST keep an interanl variable "Peer-last-heared" for 1309 each of its known peers and the value of this variable MUST be 1310 updated to the current local time everytime a message of any type 1311 (point-to-point or announcement) is received from the cooresponding 1312 peer. 1314 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 1315 seconds, the ENRP server MUST immediately send a point-to-point 1316 PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1318 If the send fails or the peer does not reply after 1319 MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer 1320 server dead and SHOULD initiate the takeover procedure defined in 1321 Section 4.10. 1323 4.10 Taking-over a Failed Peer Server 1325 In the following descriptions, We call the ENRP server that detects 1326 the failed peer server and initiates the take-over the "initiating 1327 server" and the failed peer server the "target server." 1329 4.10.1 Initiate Server Take-over Arbitration 1331 The initiating server SHOULD fisrt start a take-over arbitration 1332 process by announcing a PEER_INIT_TAKEOVER message to all its peer 1333 servers. See Section 4.1 on how annoucements are sent. In the 1334 message, the initiating server MUST fill in the Sender Server's ID 1335 and Target Server's ID. 1337 After announcing the PEER_INIT_TAKEOVER message, the initiating 1338 server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_ 1339 of its known peers, except of the target server. [editor's note: how 1340 long should it wait?] 1342 Each of the peer servers that receives the PEER_INIT_TAKEOVER message 1343 from the initiating server SHOULD take the following actions: 1345 1. If the peer server finds that itself is the target server 1346 indicated in the PEER_INIT_TAKEOVER message, it MUST immediately 1347 announce a PEER_PRESENCE message to all its peer ENRP servers in 1348 an attempt to stop this take-over process. This indicates a false 1349 failure detection case by the initiating server. 1351 2. If the peer server finds that itself has already started its own 1352 take-over arbitration process on the same target server, it MUST 1353 perform the following arbitration: 1355 A. if the peer's server ID is smaller in value than the Sender 1356 Server's ID in the arrived PEER_INIT_TAKEOVER message, the 1357 peer server SHOULD immediately abort its own take-over 1358 attempt. Moreover, the peer SHOULD mark the target server as 1359 "not active" on its internal peer list so that its status 1360 will no longer be monitored by the peer, and reply the 1361 initiating server with a PEER_INIT_TAKEOVER_ACK message. 1363 B. Otherwise, the peer MUST ignore the PEER_INIT_TAKEOVER 1364 message and take no action. 1366 3. If the peer finds that it is neither the target server nor is in 1367 its own take-over process, the peer SHOULD: a) mark the target 1368 server as "not active" on its internal peer list so that its 1369 status will no longer be monitored by this peer, and b) reply to 1370 the initiating server with a PEER_INIT_TAKEOVER_ACK message. 1372 Once the initiating server has received PEER_INIT_TAKEOVER_ACK 1373 message from _all_ of its currently known peers (except for the 1374 target server), it SHOULD consider that it has won the arbitration 1375 and SHOULD proceed to complete the take-over, following the steps 1376 described in Section 4.10.2. 1378 However, if it receives a PEER_PRESENCE from the target server at any 1379 point in the arbitration process, the initiating server SHOULD 1380 immediately abort the take-over process and mark the status of the 1381 target server as "active". 1383 4.10.2 Take-over Target Peer Server 1385 The initiating ENRP server SHOULD first send, via an announcement, a 1386 PEER_TAKEOVER_SERVER message to inform all its active peers that the 1387 take-over is enforced. The target server's ID MUST be filled in the 1388 message. The initiating server SHOULD then remove the target server 1389 from its internal peer list. 1391 [editor's note: peers should remove the target server from their list 1392 upon receiving this message. Do we really need this message? we can 1393 consolidate this with the ownership_change msg.] 1395 Then it SHOULD examine its local copy of the namespace and claim 1396 ownership of each of the PEs originally owned by the target server, 1397 by following these steps: 1399 1. mark itself as the home ENRP server of each of the PEs originally 1400 owned by the target server; 1402 2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the 1403 PEs. This will trigger the PE to adopt the initiating sever as 1404 its new home ENRP server; 1406 3. after claiming the ownership of all the PEs originally owned by 1407 the target server, announce the ownership changes of all the 1408 affected PEs in a PEER_OWNERSHIP_CHANGE message to all the 1409 currently known peers. Note, if the list of affected PEs is long, 1410 the sender MAY announce the ownership changes in multiple 1411 PEER_OWNERSHIP_CHANGE messages. 1413 When a peer receives the PEER_OWNERSHIP_CHANGE message from the 1414 initiating server, it SHOULD find each of the reported PEs in its 1415 local copy of the namespace and update the PE's home ENRP server to 1416 be the sender of the message (i.e., the initiating server). 1418 4.11 Namespace Data Auditing and Re-synchronization 1420 Message losses or certain temporary breaks in network connectivity 1421 may result in data inconsistency in the local namespace copy of some 1422 of the ENRP servers in an operation scope. Therefore, each ENRP 1423 server in the operation scope SHOULD periodically verify that its 1424 local copy of namespace data is still in sync with that of its peers. 1426 This section defines the auditing and re-synchronization procedures 1427 for an ENRP server to maintain its namespace data consistency. 1429 4.11.1 Auditing Prodecures 1431 [TBD] 1433 4.11.2 Re-synchronization Prodecures 1435 Once an ENRP server determines that there is inconsistancy between 1436 its local namespace data and a peer's namespace data with regarding 1437 to the PEs owned by that peer, it SHOULD perform the following steps 1438 to re-synchronize the data: 1440 1. The ENRP server SHOULD first "mark" every PE it knows about that 1441 is owned by the peer in its local namespace database; 1443 2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST 1444 message with W flag set to '1' to the peer to request a complete 1445 list of PEs owned by the peer; 1447 3. Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag 1448 set to '1', the peer server SHOULD immediately respond with a 1449 PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned 1450 by the peer. 1452 4. Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP 1453 server SHOULD transfer the PE entries carried in the message into 1454 its local namespace database. If an PE entry being transferred 1455 already exists in its local database, the ENRP server MUST 1456 replace the entry with the copy found in the message and remove 1457 the "mark" from the entry. 1459 5. After transferring all the PE entries from the received 1460 PEER_NAME_TABLE_RESPONSE message into its local database, the 1461 ENRP server SHOULD check whether there are still PE entries that 1462 remain "marked" in its local namespace. If so, the ENRP server 1463 SHOULD silently remove those "marked" entries. 1465 Note, similar to what is described in Section 4.2.3, the peer may 1466 reject the PEER_NAME_TABLE_REQUEST or use more than one 1467 PEER_NAME_TABLE_RESPONSE message to respond. 1469 4.12 Handling Unrecognized Message or Unrecognized Parameter 1471 When an ENRP server receives an ENRP message with an unknown message 1472 type or a message of known type that contains an unknow parameter, it 1473 SHOULD handle the unknow message or the unknown parameter according 1474 to the unrecognized message and parameter handling rules defined in 1475 Sections 3 and 4 in [10]. 1477 According to the rules, if an error report to the message sender is 1478 needed, the ENRP server that discovered the error SHOULD send back an 1479 ENRP_ERROR message with proper error cause code. 1481 5. Variables and Time Constants 1483 5.1 Variables 1485 Peer-last-heared - the local time that a peer server was last heard 1486 (via receiving either a multicast or point-to-point message from 1487 the peer). 1489 5.2 Timer Constants 1491 MAX-TIME-SERVER-HUNT - the maximal number of attempts a sender will 1492 make to contact an ENRP server (Default=3 times). 1494 TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will 1495 wait for a response from an ENRP server (Default=5 secends). 1497 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1498 heartheat message to all its known peers. (Default=30 secs.) 1500 SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a 1501 SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) 1503 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1504 will wait before considering a silent peer server potentially 1505 dead. (Default=61 secs.) 1507 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1508 sender will wait for a response after sending out a message. 1509 (Default=5 secs.) 1511 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a 1512 PE that an ENRP server will allow before purging this PE from the 1513 namespace. (Default=3) 1515 6. Security Considerations 1517 Due to varying requirements and multiple use cases of Rserpool, we 1518 point out two basic security protocols, IPsec and TLS. We 1519 specifically do not discuss whether one security protocol would be 1520 preferred over the other. This choice will be made by designers and 1521 network architects based on system requirements. 1523 For networks that demand IPsec security, implementations MUST support 1524 [9] which describes IPsec-SCTP. IPsec is two layers below RSerPool. 1525 Therefore, if IPsec is used for securing Rserpool, no changes or 1526 special considerations need to be made to Rserpool to secure the 1527 protocol. 1529 For networks that cannot or do not wish to use IPsec and prefer 1530 instead TLS, implementations MUST support TLS with SCTP as described 1531 in [8] or TLS over TCP as described in [6]. When using TLS/SCTP we 1532 must ensure that RSerPool does not use any features of SCTP that are 1533 not available to an TLS/SCTP user. This is not a difficult technical 1534 problem, but simply a requirement. When describing an API of the 1535 RSerPool lower layer we have also to take into account the 1536 differences between TLS and SCTP. This is also not difficult, but it 1537 is in contrast to the IPsec solution which is transparently layered 1538 below Rserpool. 1540 Support for security is required for the ENRP server and the PEs. 1541 Security support for the Rserpool end user is optional. Note that 1542 the end user implementation contains a piece of the Rserpool protocol 1543 -- namely ASAP -- whereby the pool handle is passed for name 1544 resolution to the ENRP server and IP address(es) are returned. 1546 The argument for optional end user security is as follows: If the 1547 user doesn't require security protection for example, against 1548 eavesdropping for the request for pool handle resolution and 1549 response, then they are free to make that choice. However, if the 1550 end user does require security, they are guaranteed to get it due to 1551 the requirement for security support for the ENRP server. It is also 1552 possible for the ENRP server to reject an unsecured request from the 1553 user due to its security policy in the case that it requires 1554 enforcement of strong security. But this will be determined by the 1555 security requirements of the individual network design. 1557 7. Acknowledgements 1559 The authors wish to thank John Loughney, Lyndon Ong, and many others 1560 for their invaluable comments. 1562 Normative References 1564 [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1565 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-05 1566 (work in progress), October 2002. 1568 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1569 J. and M. Stillman, "Requirements for Reliable Server Pooling", 1570 RFC 3237, January 2002. 1572 [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1573 J. and M. Stillman, "Architecture for Reliable Server Pooling", 1574 draft-ietf-rserpool-arch-03 (work in progress), July 2002. 1576 [4] Bradner, S., "The Internet Standards Process -- Revision 3", 1577 BCP 9, RFC 2026, October 1996. 1579 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1580 Levels", BCP 14, RFC 2119, March 1997. 1582 [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1583 2246, January 1999. 1585 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1586 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 1587 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1589 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", 1590 draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November 1591 2001. 1593 [9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On 1594 the Use of SCTP with IPsec", draft-ietf-ipsec-sctp-03 (work in 1595 progress), February 2002. 1597 [10] Stewart, R. and Q. Xie, "Aggregate Server Access Protocol 1598 (ASAP) and Endpoint Name Resolution (ENRP) common parameters 1599 document", draft-ietf-rserpool-common-param-00 (work in 1600 progress), July 2002. 1602 Informative References 1604 [11] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1605 Recommendations for Security", RFC 1750, December 1994. 1607 Authors' Addresses 1609 Qiaobing Xie 1610 Motorola, Inc. 1611 1501 W. Shure Drive, 2-F9 1612 Arlington Heights, IL 60004 1613 US 1615 Phone: +1-847-632-3028 1616 EMail: qxie1@email.mot.com 1618 Randall R. Stewart 1619 Cisco 1620 24 Burning Bush Trail 1621 Crystal Lake, IL 60012 1622 US 1624 Phone: +1-815-477-2127 1625 EMail: rrs@cisco.com 1627 Maureen Stillman 1628 Nokia 1629 127 W. State Street 1630 Ithaca, NY 14850 1631 US 1633 Phone: +1 607 273 0724 62 1634 EMail: maureen.stillman@nokia.com 1636 Intellectual Property Statement 1638 The IETF takes no position regarding the validity or scope of any 1639 intellectual property or other rights that might be claimed to 1640 pertain to the implementation or use of the technology described in 1641 this document or the extent to which any license under such rights 1642 might or might not be available; neither does it represent that it 1643 has made any effort to identify any such rights. Information on the 1644 IETF's procedures with respect to rights in standards-track and 1645 standards-related documentation can be found in BCP-11. Copies of 1646 claims of rights made available for publication and any assurances of 1647 licenses to be made available, or the result of an attempt made to 1648 obtain a general license or permission for the use of such 1649 proprietary rights by implementors or users of this specification can 1650 be obtained from the IETF Secretariat. 1652 The IETF invites any interested party to bring to its attention any 1653 copyrights, patents or patent applications, or other proprietary 1654 rights which may cover technology that may be required to practice 1655 this standard. Please address the information to the IETF Executive 1656 Director. 1658 Full Copyright Statement 1660 Copyright (C) The Internet Society (2003). All Rights Reserved. 1662 This document and translations of it may be copied and furnished to 1663 others, and derivative works that comment on or otherwise explain it 1664 or assist in its implementation may be prepared, copied, published 1665 and distributed, in whole or in part, without restriction of any 1666 kind, provided that the above copyright notice and this paragraph are 1667 included on all such copies and derivative works. However, this 1668 document itself may not be modified in any way, such as by removing 1669 the copyright notice or references to the Internet Society or other 1670 Internet organizations, except as needed for the purpose of 1671 developing Internet standards in which case the procedures for 1672 copyrights defined in the Internet Standards process must be 1673 followed, or as required to translate it into languages other than 1674 English. 1676 The limited permissions granted above are perpetual and will not be 1677 revoked by the Internet Society or its successors or assignees. 1679 This document and the information contained herein is provided on an 1680 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1681 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1682 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1683 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1684 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1686 Acknowledgement 1688 Funding for the RFC Editor function is currently provided by the 1689 Internet Society.