idnits 2.17.1 draft-ietf-rserpool-enrp-04.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 (September 3, 2002) is 7906 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 1402 == Unused Reference: '4' is defined on line 1544, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-04 ** 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: March 4, 2003 R. Stewart 5 Cisco 6 M. Stillman 7 Nokia 8 September 3, 2002 10 Endpoint Name Resolution Protocol (ENRP) 11 draft-ietf-rserpool-enrp-04.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 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 4, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2002). All Rights Reserved. 40 Abstract 42 Endpoint Name Resolution Protocol (ENRP) is designed to work in 43 conjunction with the Aggregate Server Access Protocol (ASAP) to 44 accomplish the functionality of the Reliable Server Pooling 45 (Rserpool) requirements and architecture. Within the operational 46 scope of Rserpool, ENRP defines the procedures and message formats of 47 a distributed, fault-tolerant registry service for storing, 48 bookkeeping, retrieving, and distributing pool operation and 49 membership information. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. ENRP Message Definitions . . . . . . . . . . . . . . . . . 7 57 3.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 7 58 3.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 8 59 3.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 9 60 3.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 11 61 3.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 12 62 3.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 63 3.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 64 3.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 15 65 3.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 16 66 3.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . . 16 67 3.11 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 18 68 4. ENRP Operation Procedures . . . . . . . . . . . . . . . . 19 69 4.1 Methods for Communicating amongst ENRP Servers . . . . . . 19 70 4.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 20 71 4.2.1 Generate a Server Identifier . . . . . . . . . . . . . . . 21 72 4.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . . . 21 73 4.2.3 Download ENRP Namespace Data from Mentor Peer . . . . . . 23 74 4.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 25 75 4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . . . 26 76 4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 27 77 4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28 78 4.6 Server Namespace Update . . . . . . . . . . . . . . . . . 28 79 4.6.1 Announcing Addition or Update of PE . . . . . . . . . . . 29 80 4.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . . . 29 81 4.7 Detecting and Removing Unreachable PE . . . . . . . . . . 30 82 4.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 31 83 4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 31 84 4.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . . . 31 85 4.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . . . 32 86 4.9.3 Detecting Peer Server Failure . . . . . . . . . . . . . . 32 87 4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . . 32 88 4.10.1 Initiate Server Take-over Arbitration . . . . . . . . . . 32 89 4.10.2 Take-over Target Peer Server . . . . . . . . . . . . . . . 33 90 4.11 Namespace Data Auditing and Re-synchronization . . . . . . 34 91 4.11.1 Auditing Prodecures . . . . . . . . . . . . . . . . . . . 34 92 4.11.2 Re-synchronization Prodecures . . . . . . . . . . . . . . 34 93 4.12 Handling Unrecognized Message or Unrecognized Parameter . 35 94 5. Variables and Time Constants . . . . . . . . . . . . . . . 36 95 5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 96 5.2 Timer Constants . . . . . . . . . . . . . . . . . . . . . 36 97 6. Security Considerations . . . . . . . . . . . . . . . . . 37 98 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 38 99 Normative References . . . . . . . . . . . . . . . . . . . 39 100 Informative References . . . . . . . . . . . . . . . . . . 40 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 102 Full Copyright Statement . . . . . . . . . . . . . . . . . 41 104 1. Introduction 106 ENRP is designed to work in conjunction with ASAP [1] to accomplish 107 the functionality of Rserpool as defined by its requirements [2] and 108 architecture [3]. 110 Within the operation scope of Rserpool, ENRP defines the procedures 111 and message formats of a distributed fault-tolerant registry service 112 for storing, bookkeeping, retrieving, and distributing pool operation 113 and membership information. 115 Whenever appropriate, in the rest of this document we will refer to 116 this Rserpool registry service as ENRP namespace, or simply 117 namespace. 119 1.1 Definitions 121 This document uses the following terms: 123 Operation scope: See [3]; 125 Pool (or server pool): See [3]; 127 Pool handle (or pool name): See [3]; 129 Pool element (PE): See [3]; 131 Pool user (PU): See [3]; 133 Pool element handle: See [3]; 135 ENRP namespace (or namespace): See [3]; 137 ENRP namespace server (or ENRP server): See [3]; 139 ENRP client channel: The communication channel through which a PE 140 requests for ENRP namespace service. The ENRP client channel is 141 usually defined by the transport address of the home ENRP server 142 and a well known port number; 144 ENRP server channel: Defined by a well known multicast IP address and 145 a well known port number. All ENRP servers in an operation scope 146 can send multicast messages to other servers through this channel. 147 PEs are also allowed to multicast on this channel occasionally; 149 Home ENRP server: The ENRP server to which a PE or PU currently 150 belongs. A PE MUST only have one home ENRP server at any given 151 time and both the PE and its home ENRP server MUST keep track of 152 this master/slave relationship between them. A PU SHOULD select 153 one of the available ENRP servers as its home ENRP server, but the 154 ENRP server does not need to know, nor does it need to keep track 155 of this relationship. 157 2. Conventions 159 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 160 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 161 they appear in this document, are to be interpreted as described in 162 [5]. 164 3. ENRP Message Definitions 166 In this section, we defines the format of all ENRP messages. These 167 are messages sent and received amongst ENRP servers in an operation 168 scope. Messages sent and received between a PE/PU and an ENRP server 169 are part of ASAP and are defined in [1]. A common format, defined in 170 [10], is used for all ENRP and ASAP messages. 172 Most ENRP messages contains a combination of fixed fields and TLV 173 parameters. The TLV parameters are also defined in [10]. 175 All messages, as well as their fields/parameters described below, 176 MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., 177 the most significant byte first). 179 For ENRP, the following message types are defined: 181 Type Message Name 182 ----- ------------------------- 183 0x0 - (reserved by IETF) 184 0x1 - PEER_PRESENCE 185 0x2 - PEER_NAME_TABLE_REQUEST 186 0x3 - PEER_NAME_TABLE_RESPONSE 187 0x4 - PEER_NAME_UPDATE 188 0x5 - PEER_LIST_REQUEST 189 0x6 - PEER_LIST_RESPONSE 190 0x7 - PEER_INIT_TAKEOVER 191 0x8 - PEER_INIT_TAKEOVER_ACK 192 0x9 - PEER_TAKEOVER_SERVER 193 0xa - PEER_OWNERSHIP_CHANGE 194 0xb - PEER_ERROR 195 0xc-0xFF - (reserved by IETF) 197 3.1 PEER_PRESENCE message 199 This ENRP message is used to announce (periodically) the presence of 200 an ENRP server, or to probe the status of a peer ENRP sever. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Sender Server's ID | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Receiver Server's ID | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 : Server Information Param (optional) : 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 R (reply_required) flag: 1 bit 216 Set to '1' if the sender requires a response to this message, 217 otherwise set to '0'. 219 Sender Server's ID: 32 bit (unsiged integer) 221 This is the ID of the ENRP server which sends the message. 223 Receiver Server's ID: 32 bit (unsiged integer) 225 This is the ID of the ENRP server to which the message is 226 intended. If the message is not intended to an individual 227 server (e.g., the message is multicasted to a group of 228 servers), this field MUST be set with all 0's. 230 Server Information Parameter: 232 If present, contains the server information of the sender of 233 this message (Server Information Parameter is defined in [10]). 234 This parameter is optional. However, if this message is sent 235 in response to a received "reply required" PEER_PRESENCE from a 236 peer, the sender then MUST include its server information. 238 Note, at startup an ENRP server MUST pick a randomly generated, non- 239 zero 32-bit unsigned integer as its ID and MUST use this same ID for 240 its entire life. 242 3.2 PEER_NAME_TABLE_REQUEST message 244 An ENRP server sends this message to one of its peers to request a 245 copy of the namespace data. This message is normally used during 246 server initialization or namespace re-synchronization. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type = 0x2 |0|0|0|0|0|0|0|W| Message Length = 0xC | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Sender Server's ID | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Receiver Server's ID | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 W (oWn-children-only) flag: 1 bit 260 Set to '1' if the sender of this message is only requesting 261 information about the PEs owned by the message receiver. 262 Otherwise, set to '0'. 264 Sender Server's ID: 266 See Section 3.1. 268 Receiver Server's ID: 270 See Section 3.1. 272 3.3 PEER_NAME_TABLE_RESPONSE message 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type = 0x3 |0|0|0|0|0|0|R|M| Message Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Sender Server's ID | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Receiver Server's ID | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 : : 283 : Pool entry #1 (see below) : 284 : : 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 : : 287 : ... : 288 : : 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 : : 291 : Pool entry #n (see below) : 292 : : 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 R (Reject) flag: 1 bit 297 MUST be set to '1' if the sender of this message is rejecting a 298 namespace request. In such a case, this message MUST be sent 299 with no pool entries included. 301 M (More_to_send) flag: 1 bit 303 Set to '1' if the sender has more pool entries to sent in 304 subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set to 305 '0'. 307 Message Length: 16 bits (unsigned integer) 309 Indicates the entire length of the message in number of octets. 311 Note, the value in Message Length field will NOT cover any 312 padding at the end of this message. 314 Sender Server's ID: 316 See Section 3.1. 318 Receiver Server's ID: 320 See Section 3.1. 322 Pool entry #1-#n: 324 If R flag is '0', at least one pool entry SHOULD be present in 325 the message. Each pool entry MUST start with a pool handle 326 parameter as defined in section 3.1.7, followed by one or more 327 pool element parameters, i.e.: 329 +---------------------------+ 330 : Pool handle : 331 +---------------------------+ 332 : PE #1 : 333 +---------------------------+ 334 : PE #2 : 335 +---------------------------+ 336 : ... : 337 +---------------------------+ 338 : PE #n : 339 +---------------------------+ 341 3.4 PEER_NAME_UPDATE message 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Update Action | (reserved) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Sender Server's ID | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Receiver Server's ID | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 : Pool handle : 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 : Pool Element : 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Message Length: 16 bits (unsigned integer) 361 Indicates the entire length of the message in number of octets. 363 Note, the value in Message Length field will NOT cover any 364 padding at the end of this message. 366 Update Action: 16 bits (unsigned integer) 368 This field indicates what act is requested to the specified PE. 369 It MUST take one of the following values: 371 0x0 - ADD_PE: add or update the specified PE in the ENRP 372 namespace 374 0x1 - DEL_PE: delete the specified PE from the ENRP namespace. 376 Other values are reserved by IETF and MUST not be used. 378 Reserved: 16 bits 380 MUST be set to 0's by sender and ignored by the receiver. 382 Sender Server's ID: 384 See Section 3.1. 386 Receiver Server's ID: 388 See Section 3.1. 390 Pool handle: 392 Specifies to which the PE belongs. 394 Pool Element: 396 Specifies the PE. 398 3.5 PEER_LIST_REQUEST message 400 This ENRP message is used to request a copy of the current known ENRP 401 peer server list. This message is normally sent from a newly started 402 ENRP server to an existing ENRP server as part of the initialization 403 process of the new server. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length = 0xC | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Sender Server's ID | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Receiver Server's ID | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Sender Server's ID: 417 See Section 3.1. 419 Receiver Server's ID: 421 See Section 3.1. 423 3.6 PEER_LIST_RESPONSE message 425 This message is used to respond a PEER_LIST_REQUEST. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Sender Server's ID | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Receiver Server's ID | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 : Server Info Param of Peer #1 : 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 : ... : 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 : Server Info Param of Peer #n : 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 R (Reject) flag: 1 bit 445 MUST be set to '1' if the sender of this message is rejecting a 446 peer list request. In such a case, this message MUST be sent 447 with no peer server ID included. 449 Message Length: 16 bits (unsigned integer) 451 Indicates the entire length of the message in number of octets. 453 Note, the value in Message Length field will NOT cover any 454 padding at the end of this message. 456 Sender Server's ID: 458 See Section 3.1. 460 Receiver Server's ID: 462 See Section 3.1. 464 Server Information Parameter of Peer #1-#n: 466 Each contains a Server Information Parameter of a peer known to 467 the sender. The Server Information Parameter is defined in 468 [10]. 470 3.7 PEER_INIT_TAKEOVER message 472 This message is used by an ENRP server (the takeover initiator) to 473 declare its intention of taking over a specific peer ENRP server. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Sender Server's ID | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Receiver Server's ID | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Target Server's ID | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Sender Server's ID: 489 See Section 3.1. 491 Receiver Server's ID: 493 See Section 3.1. 495 Target Server's ID: 497 Contains the 32-bit server ID of the peer ENRP that is the 498 target of this takeover attempt. 500 3.8 PEER_INIT_TAKEOVER_ACK message 502 This message is used to acknowledge the takeover initiator that the 503 sender of this message received the PEER_INIT_TAKEOVER message and 504 that it does not object to the takeover. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Sender Server's ID | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Receiver Server's ID | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Target Server's ID | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Sender Server's ID: 520 See Section 3.1. 522 Receiver Server's ID: 524 See Section 3.1. 526 Target Server's ID: 528 Contains the 32-bit server ID of the peer ENRP that is the 529 target of this takeover attempt. 531 3.9 PEER_TAKEOVER_SERVER message 533 This message is used by the takeover initiator to declare that a 534 takeover is underway. 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Type = 0x9 |0|0|0|0|0|0|0|0| Message Length | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Sender Server's ID | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Receiver Server's ID | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Target Server's ID | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Sender Server's ID: 550 See Section 3.1. 552 Receiver Server's ID: 554 See Section 3.1. 556 Target Server's ID: 558 Contains the 32-bit server ID of the peer ENRP that is the 559 target of this takeover operation. 561 3.10 PEER_OWNERSHIP_CHANGE message 563 This message is used by the ENRP server, normally after a successful 564 takeover, to declare that it is now the new home ENRP server of the 565 listed PEs in the listed pools. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type = 0xa |0|0|0|0|0|0|0|0| Message Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Sender Server's ID | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Receiver Server's ID | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 : Pool handle #1 : 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 : PE Identifier Param #1 of pool #1 : 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 : ... : 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 : PE Identifier Param #k of pool #1 : 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 : : 585 : ... : 586 : : 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 : Pool handle #M : 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 : PE Identifier Param #1 of pool #M : 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 : ... : 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 : PE Identifier Param #n of pool #M : 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Sender Server's ID: 599 See Section 3.1. 601 Receiver Server's ID: 603 See Section 3.1. 605 Pool handles and PE Identifier parameters: 607 Each listed pool handle is followed by a list of PE Identifier 608 parameters, indicating that the sender of this message is 609 taking ownership of the listed PEs in the pool. 611 3.11 PEER_ERROR message 613 This message is used by an ENRP server to report an operation error 614 to one of its peers. 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Type = 0xb |0|0|0|0|0|0|0|0| Message Length | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Sender Server's ID | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Receiver Server's ID | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 : Operation Error Parameter : 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Sender Server's ID: 630 See Section 3.1. 632 Receiver Server's ID: 634 See Section 3.1. 636 Operation Error Parameter: 638 This parameter, defined in [10], indicates the type of error(s) 639 being reported. 641 4. ENRP Operation Procedures 643 In this section, we discuss the operation procedures defined by ENRP. 644 An ENRP server MUST following these procedures when sending, 645 receiving, or processing ENRP messages. 647 Many of the Rserpool events call for both server-to-server and PU/PE- 648 to-server message exchanges. Only the message exchanges and 649 activities between an ENRP server and its peer(s) are considered 650 within the ENRP scope and are defined in this document. 652 Procedures for exchanging messages between a PE/PU and ENRP servers 653 are defined in [1]. 655 4.1 Methods for Communicating amongst ENRP Servers 657 Within an Rserpool operation scope, ENRP servers need to communicate 658 with each other in order to exchange information such as the pool 659 membership changes, namespace data synchronization, etc. 661 Two types of communications are used amongst ENRP servers: 663 o point-to-point message exchange from one ENPR server to a specific 664 peer server, and 666 o announcements from one server to all its peer servers in the 667 operation scope. 669 Point-to-point communication is always carried out over an SCTP 670 associaiton between the sending server and the receiving server. 672 Announcements are communicated out with one of the following two 673 approaches: 675 1. The sending server sends the announcement message to a well-known 676 RSERPOOL IP multicast channel that its peer servers subscribe to. 678 Note: Because IP multicast is not reliable, this approach does 679 not gaurrantee that all the peers will receive the announcement 680 message. Moreover, since IP multicast is not secure, this 681 approach cannot provide any security to the communication. 683 2. The sending server sends multiple copies of the announcement, one 684 to each of its peer servers, over a set of point-to-point SCTP 685 associations between the sending server and the peers. 687 This approach gaurrantees the reliabe receiption of the message. 688 When needed, data security can be achieved by using IP security 689 mechanisms such as IPsec [9] or TLS [8]. 691 In order to maximize inter-operability of ENRP servers, the following 692 rules MUST be followed: 694 1. At the startup time, a new ENRP server SHOULD make a decision on 695 whether it will enable IP multicast for ENRP announcements. This 696 decision should be based on factors such as the availability of 697 IP multicast and the security requirements from the user of 698 Rserpool. 700 2. If an ENRP server disables multicast, it then: 702 A. MUST NOT subscribe to the well-known server multicast 703 channel, i.e., it only receives peer announcements over SCTP 704 associations, and 706 B. MUST transmit all its out-going announcements over point-to- 707 point SCTP associations with its peers. 709 3. If an ENRP server enables itself to use multicast, it then: 711 A. MUST subcribe to the well-known server multicast channel to 712 ready itself for receiving peers' multicast announcements, 714 B. MUST also be prepared to receive peer announcements over 715 point-to-point SCTP associations from peers. 717 C. MUST track internally which peers are multicast-enabled and 718 which are not. Note: A peer is always assumed to be 719 multicast-disabled until/unless an ENRP message of any type 720 is received from that peer over the well-known server 721 multicast channel. 723 D. when sending out an announcement, MUST send a copy to the 724 well-known server multicast channel AND a copy to each of the 725 peers that are marked as multicast-disabled over a point-to- 726 point SCTP association. 728 4.2 ENRP Server Initialization 730 This section describes the steps a new ENRP server needs to take in 731 order to join the other existing ENRP servers, or to initiate the 732 namespace service if it is the first ENRP server started in the 733 operation scope. 735 4.2.1 Generate a Server Identifier 737 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 738 as unique as possible in the operation scope and this server Id MUST 739 remain unchanged for the lifetime of the server. Normally, a good 740 32-bit random number will be good enough as the server Id ([11] 741 provides some information on randomness guidelines). 743 4.2.2 Acquire Peer Server List 745 At startup, the ENRP server (initiating server) will first attempt to 746 learn all existing peer ENRP servers in the same operation scope, or 747 to determine that it is along in the scope. 749 The initiating server uses an existing peer server to bootstrap 750 itself into service. We call this peer server the mentor server. 752 4.2.2.1 Find the mentor server 754 If the initiating server is told about an existing peer server 755 through some administrative means (such as DNS query, configuration 756 database, startup scripts, etc), the initiating server SHOULD then 757 use this peer server as its mentor server and SHOULD skip the 758 remaining steps in this subsection. 760 If multiple existing peer servers are specified, the initiating 761 server SHOULD pick one of them as its mentor peer server, keep the 762 others as its backup menter peers, and skip the remaining steps in 763 this subsection. 765 If no existing peer server is specified to the initiating server AND 766 if multicast is available in the operation scope, the following 767 mentor peer discovery procedures SHOULD be followed: 769 1. The initiating server SHOULD first join the well-known ENRP 770 server multicast channel. 772 2. Then the initiating server SHOULD send a PEER_PRESENCE message, 773 with the 'Reply_required' flag set, over the multicast channel. 774 Upon the reception of this PEER_PRESENCE message, a peer server 775 MUST send a PEER_PRESENCE, without the 'Reply_required' flag, 776 back to the initiating server. 778 3. When the first response to its original PEER_PRESENCE arrives, 779 the initiating server SHOULD take the sender of this received 780 response as its mentor peer server. This completes the discovery 781 of the mentor peer server. 783 If responses are also received from other peers (a likely event 784 when multiple peers exist in the operation scope at the time the 785 new server started), the initiating server SHOULD keep a list of 786 those responded as its backup mentor peers (see below). 788 4. If no response to its PEER_PRESENCE message are received after 789 TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat 790 steps 2) and 3) for up to MAX-TIME-SERVER-HUNT times. After 791 that, if there is still no response, the initiating server MUST 792 assume that it is alone in the operation scope. 794 5. If the initiating server determined that it is alone in the 795 scope, it MUST skip the procedures in Section 4.2.2.2 and Section 796 4.2.3 and MUST consider its initialization completed and start 797 offering ENRP services. 799 Note, if multicast is not available (or not allowed for reasons such 800 as security concerns) in the operation scope, at least one peer 801 server MUST be specified to the initiating server through 802 administrative means, unless the initiation server is the first 803 server to start in the operation scope. 805 Note, if the administratively specified menter peer(s) fails, the 806 initiating server SHOULD use the auto-discover procedure defined in 807 steps 1-5 above. 809 4.2.2.2 Request complete server list from mentor peer 811 Once the initiating server finds its mentor peer server (by either 812 discovery or administrative means), the initiating server MUST send a 813 PEER_LIST_REQUEST message to the mentor peer server to request a copy 814 of the complete server list maintained by the mentor peer (see 815 Section 4.9 for maintaining server list). 817 Upon the reception of this request, the mentor peer server SHOULD 818 reply with a PEER_LIST_RESPONSE message and include in the message 819 body all existing ENRP servers known by the mentor peer. 821 Upon the reception of the PEER_LIST_RESPONSE message from the mentor 822 peer, the initiating server MUST use the server information carried 823 in the message to initialize its own peer list. 825 However, if the mentor itself is in the process of startup and not 826 ready to provide a peer server list (for example, the mentor peer is 827 waiting for a response to its own PEER_LIST_REQUEST to another 828 server), it MUST rejest the request by the initiating server and 829 respond with a PEER_LIST_RESPONSE message with the R flag set to '1', 830 and with no server information included in the response. 832 In the case where its PEER_LIST_REQUEST is rejected by the mentor 833 peer, the initiating server SHOULD either wait for a few seconds and 834 re-send the PEER_LIST_REQUEST to the mentor server, or if there is a 835 backup mentor peer available, select another mentor peer server and 836 send the PEER_LIST_REQUEST to the new mentor server. 838 4.2.3 Download ENRP Namespace Data from Mentor Peer 840 After a peer list download is completed, the initiating server MUST 841 request a copy of the current namespace data from its mentor peer 842 server, by taking the following steps: 844 1. The initiating server MUST first send a PEER_NAME_TABLE_REQUEST 845 message to the mentor peer, with W flag set to '0', indicating 846 that the entire namespace is requested. 848 2. Upon the reception of this message, the mentor peer MUST start a 849 download session in which a copy of the current namespace data 850 maintained by the mentor peer is sent to the initiating server in 851 one or more PEER_NAME_TABLE_RESPONSE messages. 853 If more than one PEER_NAME_TABLE_RESPONSE message are used during 854 the download, the mentor peer MUST use the M flag in each 855 PEER_NAME_TABLE_RESPONSE message to indicate whether this message 856 is the last one for the download session. In particular, the 857 mentor peer MUST set the M flag to '1' in the outbound 858 PEER_NAME_TABLE_RESPONSE if there is more data to be transferred 859 and MUST keep track of the progress of the current download 860 session. The mentor peer MUST set the M flag to '0' in the last 861 PEER_NAME_TABLE_RESPONSE for the download session and close the 862 download session (i.e., removing any internal record of the 863 session) after sending out the last message. 865 3. During the downloading, every time the initiating server receives 866 a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data 867 entries carried in the message into its local namespace database, 868 and then check whether or not this message is the last one for 869 the download session. 871 If the M flag is set to '1' in the just processed 872 PEER_NAME_TABLE_RESPONSE message, the initiating server MUST send 873 another PEER_NAME_TABLE_REQUEST message to the mentor peer to 874 request for the next PEER_NAME_TABLE_RESPONSE message. 876 4. When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 877 message into its local namespace database, the initiating server 878 MUST handle each pool entry carried in the message using the 879 following rules: 881 A. If the pool does not exist in the local namespace, the 882 initiating server MUST creates the pool in the local 883 namespace and add the PE(s) in the pool entry to the pool. 885 When creating the pool, the initiation server MUST set the 886 overall member selection policy type of the pool to the 887 policy type indicated in the first PE. 889 B. If the pool already exists in the local namespace, but the 890 PE(s) in the pool entry is not currently a member of the 891 pool, the initiating server MUST add the PE(s) to the pool. 893 C. If the pool already exists in the local namespace AND the 894 PE(s) in the Pool entry is already a member of the pool, the 895 initiating server server SHOULD replace the attributes of the 896 existing PE(s) with the new information. 898 5. When the last PEER_NAME_TABLE_RESPONSE message is received from 899 the mentor peer and unpacked into the local namespace, the 900 initialization process is completed and the initiating server 901 SHOULD start to provide ENRP services. 903 Under certain circumstances, the mentor peer itself may not be able 904 to provide a namespace download to the initiating server. For 905 example, the mentor peer is in the middle of initializing its own 906 namespace database, or it has currently too many download sessions 907 open to other servers. 909 In such a case, the mentor peer MUST rejest the request by the 910 initiating server and respond with a PEER_NAME_TABLE_RESPONSE message 911 with the R flag set to '1', and with no pool entries included in the 912 response. 914 In the case where its PEER_NAME_TABLE_REQUEST is rejected by the 915 mentor peer, the initiating server SHOULD either wait for a few 916 seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server, 917 or if there is a backup mentor peer available, select another mentor 918 peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor 919 server. 921 A started namespace download session may get interrupted for some 922 reason. To cope with this, the initiating server SHOULD start a 923 timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST to its 924 mentor peer. If this timer expires without receiving a response from 925 the mentor peer, the initiating server SHOULD abort the current 926 download session and re-start a new namespace download with a backup 927 mentor peer, if one is available. 929 Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the 930 mentor peer has still more data to send, it SHOULD start a session 931 timer. If this timer expires without receiving another request from 932 the initiating server, the mentor peer SHOULD abort the session, 933 cleaning out any resource and record of the session. 935 4.3 Handle PE Registration 937 To register itself with the namespace, a PE sends a REGISTRATION 938 message to its home ENRP server. The format of REGISTRATION message 939 and rules of sending it are defined in [1]. 941 In the REGISTRATION message, the PE indicates the name of the pool it 942 wishes to join in a pool handle parameter, and its complete transport 943 information and any load control information in a PE parameter. 945 The ENRP server handles the REGISTRATION message according to the 946 following rules: 948 1. If the named pool does not exist in the namespace, the ENRP 949 server MUST creates a new pool with that name in the namespace 950 and add the PE to the pool as its first PE; 952 When a new pool is created, the overall member selection policy 953 of the pool MUST be set to the policy type indicated by the first 954 PE. 956 2. If the named pool already exists in the namespace, but the 957 requesting PE is not currently a member of the pool, the ENRP 958 server will add the PE as a new member to the pool; 960 After adding the PE to the pool, the server MUST check if the 961 policy type indicated by the PE is the same as the overall policy 962 type of the pool. If different, the ENRP server MUST attempt to 963 override the PE's policy and make it the same as the overall 964 policy. 966 A. If no additional policy-related information are required to 967 perform the override (e.g., overriding Least-used with Round- 968 robin does not require additional policy-related 969 information), the ENRP server MUST replace the PE's policy 970 type with the overall policy type. 972 B. If additional policy information is required (e.g., 973 overriding Round-robin with Least-load will require the 974 knowledge of the load factor of the PE), the ENRP server MUST 975 reject the regirstration with an error code "Pooling policy 976 inconsistent". 978 3. If the named pool already exists in the namespace AND the 979 requesting PE is already a member of the pool, the ENRP server 980 SHOULD consider this as a re-registration case. The ENRP Server 981 SHOULD replace the attributes of the existing PE with the 982 information carried in the received REGISTRATION message. 984 4. After accepting the registration, the ENRP server MUST assgin 985 itself the owner of this PE. If this is a re-registration, the 986 ENRP server MUST take over ownership of this PE regardless of 987 whether the PE was previously owned by the server or by a peer of 988 it. 990 5. The ENRP server may reject the registration due to reasons such 991 as invalid values, lack of resource, authentication failure, etc. 993 In all above cases, the ENRP server MUST reply to the requesting PE 994 with a REGISTRATION_RESPONSE message. If the registration is 995 rejected, the ENRP server MUST indicate the rejection by including 996 the proper Operation Error parameter in the REGISTRATION_RESPONSE 997 message. 999 If the registration is granted with a polcy override (see Step 2a 1000 above), in the REGISTRATION_RESPONSE message the ENRP server SHOULD 1001 also send back the registrant PE the new policy, in a Member 1002 Selection Policy Parameter, so as to inform the PE that a policy 1003 override is performed. 1005 If the registration is granted (i.e., one of cases 1-3 above), the 1006 ENRP server MUST assign itself to be the home ENRP server of the PE, 1007 i.e., to "own" the PE. 1009 Implementation note: for better performance, the ENRP server may 1010 find it both efficient and convenient to internally maintain two 1011 separate PE lists or tables - one is for the PEs that are "owned" 1012 by the ENRP server and the other for all the PEs owned by its 1013 peer(s). 1015 Moreover, if the registration is granted, the ENRP server MUST take 1016 the namespace update action as described in Section 4.6 to inform its 1017 peers about the change just made. If the registration is denied, no 1018 message will be sent to its peers. 1020 4.3.1 Rules on PE Re-registration 1022 A PE may re-register itself to the namespace with a new set of 1023 attributtes in order to, for example, extend its registration life, 1024 change its load factor value, etc. 1026 A PE may modify its load factor value at any time via re- 1027 registration. Based on the number of PEs in the pool and the pool's 1028 overall policy type, this operation allows the PE to dynamically 1029 control its share of inbound messages received by the pool (also see 1030 Section ???? in [1] for more on load control). 1032 Moreover, when re-registering, the PE MUST NOT change its policy 1033 type. The server MUST reject the re-registration if the PE attempt 1034 to change its policy type. In the rejection, the server SHOULD 1035 attach an error code "Pooling Policy Inconsistent". 1037 Regardless whether it is the current owner of the PE, if the re- 1038 registration is granted to the PE, the ENRP server MUST assign itself 1039 to be the new home ENRP server of the PE. 1041 Moreover, if the re-registration is granted, the ENRP server MUST 1042 take the namespace update action as described in Section 4.6 to 1043 inform its peers about the change just made. If the re-registration 1044 is denied, no message will be sent to its peers. 1046 4.4 Handle PE De-registration 1048 To remove itself from a pool, a PE sends a DEREGISTRATION message to 1049 its home ENRP server. The complete format of DEREGISTRATION message 1050 and rules of sending it are defined in [1]. 1052 In the DEREGISTRATION message the PE indicates the name of the pool 1053 it belongs to in a pool handle parameter and provides its PE 1054 identifer. 1056 Upon receiving the message, the ENRP server SHALL remove the PE from 1057 its namespace. Moreover, if the PE is the last one of the named 1058 pool, the ENRP server will remove the pool from the namespace as 1059 well. 1061 If the ENRP server fails to find any record of the PE in its 1062 namespace, it SHOULD consider the de-registration granted and 1063 completed. 1065 The ENRP server may reject the de-registration request for various 1066 reasons, such as invalid parameters, authentication failure, etc. 1068 In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE 1069 message to the PE. If the de-registration is rejected, the ENRP 1070 server MUST indicate the rejection by including the proper Operation 1071 Error parameter. 1073 It should be noted that de-registration does not stop the PE from 1074 sending or receiving application messages. 1076 Once the de-registration request is granted AND the PE removed from 1077 its local copy of the namespace, the ENRP server MUST take the 1078 namespace update action described in Section 4.6 to inform its peers 1079 about the change just made. Otherwise, NO message SHALL be send to 1080 its peers. 1082 4.5 Pool Handle Translation 1084 A PU uses the pool handle translation service of an ENRP server to 1085 resolve a pool handle to a list of accessible transport addresses of 1086 the member PEs of the pool. 1088 This requires the PU to send a NAME_RESOLUTION message to its home 1089 ENRP server and in the NAME_RESOLUTION message specify the pool 1090 handle to be translated in a Pool Handle parameter. Complete 1091 defintion of the NAME_RESOLUTION message and the rules of sending it 1092 are defined in [1]. 1094 An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests 1095 from PUs either over an SCTP associaiton on the well-know SCTP port, 1096 or over a TCP connection on the well-know TCP port. 1098 Upon reception of the NAME_RESOLUTION message, the ENRP server MUST 1099 first look up the pool handle in its namespace. If the pool exits, 1100 the home ENRP server MUST compose and send back a 1101 NAME_RESOLUTION_RESPONSE message to the requesting PU. 1103 In the response message, the ENRP server MUST list all the PEs 1104 currently registered in this pool, in a list of PE parameters. The 1105 ENRP server MUST also include a pool member selection policy 1106 parameter to indicate the overall member selection policy for the 1107 pool, if the current pool member selection policy is not round-robin 1108 (if the overall policy is round-Robin, this parameter MAY be 1109 omitted?). 1111 If the named pool does not exist in the namespace, the ENRP server 1112 MUST respond with a NAME_UNKNOWN message. 1114 The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN 1115 messages and the rules of receiving them are defined in [1]. 1117 4.6 Server Namespace Update 1119 This includes a set of update operations used by an ENRP server to 1120 inform its peers when its local namespace is modified, e.g., addition 1121 of a new PE, removal of an existing PE, change of pool or PE 1122 properties. 1124 4.6.1 Announcing Addition or Update of PE 1126 When a new PE is granted registration to the namespace or an existing 1127 PE is granted a re-registration, the home ENRP server uses this 1128 procedure to inform all its peers. 1130 This is an ENRP announcement and is sent to all the peer of the home 1131 ENRP server. See Section 4.1 on how annoucements are sent. 1133 An ENRP server MUST announce this update to all its peers in a 1134 PEER_NAME_UPDATE message with the Update Action field set to ADD_PE, 1135 indicating the addition of a new PE or the modification of an 1136 existing PE. The complete new information of the PE and the pool its 1137 belongs to MUST be indicated in the message with a PE parameter and a 1138 Pool Handle parameter, respectively. 1140 The home ENRP server SHOULD fill in its server Id in the Sender 1141 Server's ID field and leave the Receiver Server's ID blank (i.e., all 1142 0's). 1144 When a peer receives this PEER_NAME_UPDATE message, it MUST take the 1145 following actions: 1147 1. If the named pool indicated by the pool handle does not exist in 1148 its local copy of the namespace, the peer MUST create the named 1149 pool in its local namespace and add the PE to the pool as the 1150 first PE. It MUST then copy in all other attributes of the PE 1151 carried in the message. 1153 When the new pool is created, the overall member selection policy 1154 of the pool MUST be set to the policy type indicated by the PE. 1156 2. If the named pool already exists in the peer's local copy of the 1157 namespace AND the PE does not exist, the peer MUST add the PE to 1158 the pool as a new PE and copy in all attributes of the PE carried 1159 in the message. 1161 3. If the named pool exists AND the PE is already a member of the 1162 pool, the peer MUST replace the attributes of the PE with the new 1163 information carried in the message. 1165 4.6.2 Announcing Removal of PE 1167 When an existing PE is granted de-registration or is removed from its 1168 namespace for some other reasons (e.g., purging an unreachable PE, 1169 see Section 4.7), the ENRP server MUST uses this procedure to inform 1170 all its peers about the change just made. 1172 This is an ENRP announcement and is sent to all the peer of the home 1173 ENRP server. See Section 4.1 on how annoucements are sent. 1175 An ENRP server MUST announce the PE removal to all its peers in a 1176 PEER_NAME_UPDATE message with the Update Action field set to DEL_PE, 1177 indicating the removal of an existing PE. The complete information 1178 of the PE and the pool its belongs to MUST be indicated in the 1179 message with a PE parameter and a Pool Handle parameter, 1180 respectively. 1182 [editor's note: only the pool handle and the PE's id are needed, it 1183 should reduce the size of the message] 1185 The sending server MUST fill in its server ID in the Sender Server's 1186 ID field and leave the Receiver Server's ID blank (i.e., set to all 1187 0's). 1189 When a peer receives this PEER_NAME_UPDATE message, it MUST first 1190 find pool and the PE in its own namespace, and then remove the PE 1191 from its local namespace. If the removed PE is the last one in the 1192 pool, the peer MUST also delete the pool from its local namespace. 1194 If the peer fails to find the PE or the pool in its namespace, it 1195 SHOULD take no further actions. 1197 4.7 Detecting and Removing Unreachable PE 1199 Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 1200 Notification, see section 10.2 of [7]), the PU SHOULD send an 1201 ENDPOINT_UNREACHABLE message to its home ENRP server. The message 1202 SHOULD contain the pool handle and the PE Id of the unreachable PE. 1204 Upon the reception of an ENDPOINT_UNREACHABLE message, a server MUST 1205 immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the 1206 PE in question. If this ENDPOINT_KEEP_ALIVE fails (e.g., it results 1207 in an SCTP SEND.FAILURE notification), the ENRP server MUST consider 1208 the PE as truly unreachable and MUST remove the PE from its namespace 1209 and take actions described in Section 4.6.2. 1211 If the ENDPOINT_UNREACHABLE message is transmitted successfully to 1212 the PE, the ENRP server MUST retain the PE in its namespace. 1213 Moreover, the server SHOULD keep a counter to record how many 1214 ENDPOINT_UNREACHABLE messages it has received reporting reachability 1215 problem relating to this PE. If the counter exceeds the protocol 1216 threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE 1217 from its namespace and take actions described in Section 4.6.2. 1219 Optionally, an ENRP server may also periodically send point-to-point 1220 ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP 1221 server in order to check their reachability status. If the send of 1222 ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the 1223 PE as unreachable and MUST remove the PE from its namespace and take 1224 actions described in Section 4.6.2. Note, if an ENRP server owns a 1225 large number of PEs, the implementation should pay attention not to 1226 flood the network with bursts of ENDPOINT_KEEP_ALIVE messages. 1227 Instead, the implementation should try to smooth out the 1228 ENDPOINT_KEEP_ALIVE message traffic over time. 1230 The complete definition and rules of sending ENDPOINT_UNREACHABLE and 1231 receiving ENDPOINT_KEEP_ALIVE messages are described in [1]. 1233 4.8 Helping PE and PU to Discover Home ENRP Server 1235 At its startup time, or whenever its current home ENRP server is not 1236 providing services, a PE or PU will attempt to find a new home 1237 server. The PE or PU will either multicast or send a point-to-point 1238 SERVER_HUNT message to one or more ENRP servers in the operation 1239 scope. For the complete procedure of this, see Section ???? in [1]. 1241 To support this procedure, whenever a SERVER_HUNT message is received 1242 an ENRP server SHOULD immediately respond to the sending PE or PU 1243 with a SERVER_HUNT_RESPONSE message. 1245 4.9 Maintaining Peer List and Monitoring Peer Status 1247 An ENRP server MUST keep an internal record on the status of each of 1248 its known peers. This record is referred to as the server's "peer 1249 list" 1251 4.9.1 Discovering New Peer 1253 If a message of any type is received from a previously unknown peer, 1254 the ENRP server MUST consider this peer a new peer in the operation 1255 scope and add it to the peer list. 1257 The ENRP server MUST send a PEER_PRESENCE message with the Reply- 1258 required flag set to '1' to the source address found in the arrived 1259 message. This will force the new peer to reply with its own 1260 PEER_PRESENCE containing its full server information (see Section 1261 3.1). 1263 [editor's note: should we ask for a peer list from the new peer? 1264 this may help mending two splitted networks.] 1266 4.9.2 Server Sending Heartbeat 1268 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 1269 continued presence to all its peer with a PEER_PRESENCE message. In 1270 the PEER_PRESENCE message, the ENRP server MUST set the 1271 'Replay_required' flag to '0', indicating that no response is 1272 required. 1274 The arrival of this periodic PEER_PRESENCE message will cause all its 1275 peers to update their internal variable "Peer-last-heared" for the 1276 sending server (see Section 4.9.3 for more details). 1278 4.9.3 Detecting Peer Server Failure 1280 An ENRP server MUST keep an interanl variable "Peer-last-heared" for 1281 each of its known peers and the value of this variable MUST be 1282 updated to the current local time everytime a message of any type 1283 (point-to-point or announcement) is received from the cooresponding 1284 peer. 1286 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 1287 seconds, the ENRP server MUST immediately send a point-to-point 1288 PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1290 If the send fails or the peer does not reply after MAX-TIME-NO- 1291 RESPONSE seconds, the ENRP server MUST consider the peer server dead 1292 and SHOULD initiate the takeover procedure defined in Section 4.10. 1294 4.10 Taking-over a Failed Peer Server 1296 In the following descriptions, We call the ENRP server that detects 1297 the failed peer server and initiates the take-over the "initiating 1298 server" and the failed peer server the "target server." 1300 4.10.1 Initiate Server Take-over Arbitration 1302 The initiating server SHOULD fisrt start a take-over arbitration 1303 process by announcing a PEER_INIT_TAKEOVER message to all its peer 1304 servers. See Section 4.1 on how annoucements are sent. In the 1305 message, the initiating server MUST fill in the Sender Server's ID 1306 and Target Server's ID. 1308 After announcing the PEER_INIT_TAKEOVER message, the initiating 1309 server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_ 1310 of its known peers, except of the target server. [editor's note: how 1311 long should it wait?] 1313 Each of the peer servers that receives the PEER_INIT_TAKEOVER message 1314 from the initiating server SHOULD take the following actions: 1316 1. If the peer server finds that itself is the target server 1317 indicated in the PEER_INIT_TAKEOVER message, it MUST immediately 1318 announce a PEER_PRESENCE message to all its peer ENRP servers in 1319 an attempt to stop this take-over process. This indicates a 1320 false failure detection case by the initiating server. 1322 2. If the peer server finds that itself has already started its own 1323 take-over arbitration process on the same target server, it MUST 1324 perform the following arbitration: 1326 A. if the peer's server ID is smaller in value than the Sender 1327 Server's ID in the arrived PEER_INIT_TAKEOVER message, the 1328 peer server SHOULD immediately abort its own take-over 1329 attempt. Moreover, the peer SHOULD mark the target server as 1330 "not active" on its internal peer list so that its status 1331 will no longer be monitored by the peer, and reply the 1332 initiating server with a PEER_INIT_TAKEOVER_ACK message. 1334 B. Otherwise, the peer MUST ignore the PEER_INIT_TAKEOVER 1335 message and take no action. 1337 3. If the peer finds that it is neither the target server nor is in 1338 its own take-over process, the peer SHOULD: a) mark the target 1339 server as "not active" on its internal peer list so that its 1340 status will no longer be monitored by this peer, and b) reply to 1341 the initiating server with a PEER_INIT_TAKEOVER_ACK message. 1343 Once the initiating server has received PEER_INIT_TAKEOVER_ACK 1344 message from _all_ of its currently known peers (except for the 1345 target server), it SHOULD consider that it has won the arbitration 1346 and SHOULD proceed to complete the take-over, following the steps 1347 described in Section 4.10.2. 1349 However, if it receives a PEER_PRESENCE from the target server at any 1350 point in the arbitration process, the initiating server SHOULD 1351 immediately abort the take-over process and mark the status of the 1352 target server as "active". 1354 4.10.2 Take-over Target Peer Server 1356 The initiating ENRP server SHOULD first send, via an announcement, a 1357 PEER_TAKEOVER_SERVER message to inform all its active peers that the 1358 take-over is enforced. The target server's ID MUST be filled in the 1359 message. The initiating server SHOULD then remove the target server 1360 from its internal peer list. 1362 [editor's note: peers should remove the target server from their list 1363 upon receiving this message. Do we really need this message? we can 1364 consolidate this with the ownership_change msg.] 1366 Then it SHOULD examine its local copy of the namespace and claim 1367 ownership of each of the PEs originally owned by the target server, 1368 by following these steps: 1370 1. mark itself as the home ENRP server of each of the PEs originally 1371 owned by the target server; 1373 2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the 1374 PEs. This will trigger the PE to adopt the initiating sever as 1375 its new home ENRP server; 1377 3. after claiming the ownership of all the PEs originally owned by 1378 the target server, announce the ownership changes of all the 1379 affected PEs in a PEER_OWNERSHIP_CHANGE message to all the 1380 currently known peers. Note, if the list of affected PEs is 1381 long, the sender MAY announce the ownership changes in multiple 1382 PEER_OWNERSHIP_CHANGE messages. 1384 When a peer receives the PEER_OWNERSHIP_CHANGE message from the 1385 initiating server, it SHOULD find each of the reported PEs in its 1386 local copy of the namespace and update the PE's home ENRP server to 1387 be the sender of the message (i.e., the initiating server). 1389 4.11 Namespace Data Auditing and Re-synchronization 1391 Message losses or certain temporary breaks in network connectivity 1392 may result in data inconsistency in the local namespace copy of some 1393 of the ENRP servers in an operation scope. Therefore, each ENRP 1394 server in the operation scope SHOULD periodically verify that its 1395 local copy of namespace data is still in sync with that of its peers. 1397 This section defines the auditing and re-synchronization procedures 1398 for an ENRP server to maintain its namespace data consistency. 1400 4.11.1 Auditing Prodecures 1402 [TBD] 1404 4.11.2 Re-synchronization Prodecures 1406 Once an ENRP server determines that there is inconsistancy between 1407 its local namespace data and a peer's namespace data with regarding 1408 to the PEs owned by that peer, it SHOULD perform the following steps 1409 to re-synchronize the data: 1411 1. The ENRP server SHOULD first "mark" every PE it knows about that 1412 is owned by the peer in its local namespace database; 1414 2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST 1415 message with W flag set to '1' to the peer to request a complete 1416 list of PEs owned by the peer; 1418 3. Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag 1419 set to '1', the peer server SHOULD immediately respond with a 1420 PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned 1421 by the peer. 1423 4. Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP 1424 server SHOULD transfer the PE entries carried in the message into 1425 its local namespace database. If an PE entry being transferred 1426 already exists in its local database, the ENRP server MUST 1427 replace the entry with the copy found in the message and remove 1428 the "mark" from the entry. 1430 5. After transferring all the PE entries from the received 1431 PEER_NAME_TABLE_RESPONSE message into its local database, the 1432 ENRP server SHOULD check whether there are still PE entries that 1433 remain "marked" in its local namespace. If so, the ENRP server 1434 SHOULD silently remove those "marked" entries. 1436 Note, similar to what is described in Section 4.2.3, the peer may 1437 reject the PEER_NAME_TABLE_REQUEST or use more than one 1438 PEER_NAME_TABLE_RESPONSE message to respond. 1440 4.12 Handling Unrecognized Message or Unrecognized Parameter 1442 When an ENRP server receives an ENRP message with an unknown message 1443 type or a message of known type that contains an unknow parameter, it 1444 SHOULD handle the unknow message or the unknown parameter according 1445 to the unrecognized message and parameter handling rules defined in 1446 Sections 3 and 4 in [10]. 1448 According to the rules, if an error report to the message sender is 1449 needed, the ENRP server that discovered the error SHOULD send back an 1450 ENRP_ERROR message with proper error cause code. 1452 5. Variables and Time Constants 1454 5.1 Variables 1456 Peer-last-heared - the local time that a peer server was last heard 1457 (via receiving either a multicast or point-to-point message from 1458 the peer). 1460 5.2 Timer Constants 1462 MAX-TIME-SERVER-HUNT - the maximal number of attempts a sender will 1463 make to contact an ENRP server (Default=3 times). 1465 TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will 1466 wait for a response from an ENRP server (Default=5 secends). 1468 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1469 heartheat message to all its known peers. (Default=30 secs.) 1471 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1472 will wait before considering a silent peer server potentially 1473 dead. (Default=61 secs.) 1475 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1476 sender will wait for a response after sending out a message. 1477 (Default=5 secs.) 1479 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a 1480 PE that an ENRP server will allow before purging this PE from the 1481 namespace. (Default=3) 1483 6. Security Considerations 1485 Due to varying requirements and multiple use cases of Rserpool, we 1486 point out two basic security protocols, IPsec and TLS. We 1487 specifically do not discuss whether one security protocol would be 1488 preferred over the other. This choice will be made by designers and 1489 network architects based on system requirements. 1491 For networks that demand IPsec security, implementations MUST support 1492 [9] which describes IPsec-SCTP. IPsec is two layers below RSerPool. 1493 Therefore, if IPsec is used for securing Rserpool, no changes or 1494 special considerations need to be made to Rserpool to secure the 1495 protocol. 1497 For networks that cannot or do not wish to use IPsec and prefer 1498 instead TLS, implementations MUST support TLS with SCTP as described 1499 in [8] or TLS over TCP as described in [6]. When using TLS/SCTP we 1500 must ensure that RSerPool does not use any features of SCTP that are 1501 not available to an TLS/SCTP user. This is not a difficult technical 1502 problem, but simply a requirement. When describing an API of the 1503 RSerPool lower layer we have also to take into account the 1504 differences between TLS and SCTP. This is also not difficult, but it 1505 is in contrast to the IPsec solution which is transparently layered 1506 below Rserpool. 1508 Support for security is required for the ENRP server and the PEs. 1509 Security support for the Rserpool end user is optional. Note that 1510 the end user implementation contains a piece of the Rserpool protocol 1511 -- namely ASAP -- whereby the pool handle is passed for name 1512 resolution to the ENRP server and IP address(es) are returned. 1514 The argument for optional end user security is as follows: If the 1515 user doesn't require security protection for example, against 1516 eavesdropping for the request for pool handle resolution and 1517 response, then they are free to make that choice. However, if the 1518 end user does require security, they are guaranteed to get it due to 1519 the requirement for security support for the ENRP server. It is also 1520 possible for the ENRP server to reject an unsecured request from the 1521 user due to its security policy in the case that it requires 1522 enforcement of strong security. But this will be determined by the 1523 security requirements of the individual network design. 1525 7. Acknowledgements 1527 The authors wish to thank John Loughney, Lyndon Ong, and many others 1528 for their invaluable comments. 1530 Normative References 1532 [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1533 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-04 1534 (work in progress), July 2002. 1536 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1537 J. and M. Stillman, "Requirements for Reliable Server Pooling", 1538 RFC 3237, January 2002. 1540 [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1541 J. and M. Stillman, "Architecture for Reliable Server Pooling", 1542 draft-ietf-rserpool-arch-03 (work in progress), July 2002. 1544 [4] Bradner, S., "The Internet Standards Process -- Revision 3", 1545 BCP 9, RFC 2026, October 1996. 1547 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1548 Levels", BCP 14, RFC 2119, March 1997. 1550 [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1551 2246, January 1999. 1553 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1554 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 1555 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1557 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", 1558 draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November 1559 2001. 1561 [9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On 1562 the Use of SCTP with IPsec", draft-ietf-ipsec-sctp-03 (work in 1563 progress), February 2002. 1565 [10] Stewart, R. and Q. Xie, "Aggregate Server Access Protocol 1566 (ASAP) and Endpoint Name Resolution (ENRP) common parameters 1567 document", draft-ietf-rserpool-common-param-00 (work in 1568 progress), July 2002. 1570 Informative References 1572 [11] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1573 Recommendations for Security", RFC 1750, December 1994. 1575 Authors' Addresses 1577 Qiaobing Xie 1578 Motorola, Inc. 1579 1501 W. Shure Drive, 2-F9 1580 Arlington Heights, IL 60004 1581 US 1583 Phone: +1-847-632-3028 1584 EMail: qxie1@email.mot.com 1586 Randall R. Stewart 1587 Cisco 1588 24 Burning Bush Trail 1589 Crystal Lake, IL 60012 1590 US 1592 Phone: +1-815-477-2127 1593 EMail: rrs@cisco.com 1595 Maureen Stillman 1596 Nokia 1597 127 W. State Street 1598 Ithaca, NY 14850 1599 US 1601 Phone: +1 607 273 0724 62 1602 EMail: maureen.stillman@nokia.com 1604 Full Copyright Statement 1606 Copyright (C) The Internet Society (2002). All Rights Reserved. 1608 This document and translations of it may be copied and furnished to 1609 others, and derivative works that comment on or otherwise explain it 1610 or assist in its implementation may be prepared, copied, published 1611 and distributed, in whole or in part, without restriction of any 1612 kind, provided that the above copyright notice and this paragraph are 1613 included on all such copies and derivative works. However, this 1614 document itself may not be modified in any way, such as by removing 1615 the copyright notice or references to the Internet Society or other 1616 Internet organizations, except as needed for the purpose of 1617 developing Internet standards in which case the procedures for 1618 copyrights defined in the Internet Standards process must be 1619 followed, or as required to translate it into languages other than 1620 English. 1622 The limited permissions granted above are perpetual and will not be 1623 revoked by the Internet Society or its successors or assigns. 1625 This document and the information contained herein is provided on an 1626 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1627 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1628 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1629 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1630 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1632 Acknowledgement 1634 Funding for the RFC Editor function is currently provided by the 1635 Internet Society.