idnits 2.17.1 draft-ietf-rserpool-enrp-03.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 7) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 46 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 2, 2002) is 8029 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) == Missing Reference: 'PARAMS' is mentioned on line 157, but not defined == Missing Reference: 'TBD' is mentioned on line 1060, but not defined == Unused Reference: 'RFC2026' is defined on line 1145, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3237 -- Possible downref: Non-RFC (?) normative reference: ref. 'ASAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSPL-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCTP-IPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSPL-PARAM' -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Xie 3 INTERNET-DRAFT Motorola 4 R. R. Stewart 5 Cisco Systems 6 M. Stillman 7 Nokia 9 Expires in six months May 2, 2002 11 Endpoint Name Resolution Protocol (ENRP) 12 14 Status of This Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 Endpoint Name Resolution Protocol (ENRP) is designed to work in 31 conjunction with the Aggregate Server Access Protocol (ASAP) 32 to accomplish the functionality of the Reliable Server Pooling 33 (Rserpool) requirements and architecture. 35 Within the operational scope of Rserpool, ENRP defines the 36 procedures and message formats of a distributed, fault-tolerant 37 registry service for storing, bookkeeping, retrieving, and 38 distributing pool operation and membership information. 40 Table Of Contents 42 1. Introduction...............................................2 43 1.2 Definitions...............................................2 44 2. Conventions................................................3 45 3. ENRP Message Definitions...................................3 46 3.1 PEER_PRESENCE message.....................................4 47 3.2 PEER_NAME_TABLE_REQUEST message...........................5 48 3.3 PEER_NAME_TABLE_RESPONSE message..........................5 49 3.4 PEER_NAME_UPDATE message..................................7 50 3.5 PEER_LIST_REQUEST message.................................7 51 3.6 PEER_LIST_RESPONSE message................................8 52 4. ENRP Operation Procedures..................................9 53 4.1 Methods for Communicating amongst ENRP Servers............9 54 4.2 ENRP Server Initialization................................10 55 4.2.1 Generate a Server Identifier ...........................11 56 4.2.2 Acquire Peer Server List................................11 57 4.2.2.1 Find the mentor server................................11 58 4.2.2.2 Request complete server list from mentor peer.........12 59 4.2.3 Download ENRP Namespace Data from mentor Peer...........13 60 4.3 Handle PE Registration....................................14 61 4.3.1 Rules on PE Re-registration.............................16 62 4.4 Handle PE De-registration.................................16 63 4.5 Pool Handle Translation...................................17 64 4.6 Server Namespace Update...................................17 65 4.6.1 Announcing Addition or Update of PE.....................17 66 4.6.2 Announcing Removal of PE................................18 67 4.7 Detecting and Removing Unreachable PE.....................19 68 4.8 Helping PE and PU to Discover Home ENRP Server............19 69 4.9 Maintaining Peer List and Monitoring Peer Status..........20 70 4.9.1 Discovering New Peer....................................20 71 4.9.2 Server Sending Heartbeat................................20 72 4.9.3 Detecting Peer Server Failure...........................20 73 4.10 Namespace Data Auditing and Re-synchronization...........21 74 4.10 Reporting Unrecognized Message 75 or Unrecognized Parameter................................21 76 5. Protocol Variables and Time Constants......................21 77 5.1 Variables.................................................21 78 5.2 Timer Constants...........................................21 79 6. Security Considerations....................................22 80 7. References.................................................22 81 7.1 Informative References....................................23 82 8. Acknowledgements...........................................23 83 9. Authors' Addresses.........................................23 85 1. Introduction 87 ENRP is designed to work in conjunction with ASAP [ASAP] to 88 accomplish the functionality of Rserpool as defined by its 89 requirements [RFC3237] and architecture [RSPL-ARCH]. 91 Within the operation scope of Rserpool, ENRP defines the procedures 92 and message formats of a distributed fault-tolerant registry 93 service for storing, bookkeeping, retrieving, and distributing pool 94 operation and membership information. 96 Whenever appropriate, in the rest of this document we will refer to 97 this Rserpool registry service as ENRP namespace, or simply 98 namespace. 100 1.2 Definitions 102 This document uses the following terms: 104 Operation scope: 105 See [RSPL-ARCH]. 107 Pool (or server pool): 108 See [RSPL-ARCH]. 110 Pool handle (or pool name): 111 See [RSPL-ARCH]. 113 Pool element (PE): 114 See [RSPL-ARCH]. 116 Pool user (PU): 117 See [RSPL-ARCH]. 119 Pool element handle: 120 See [RSPL-ARCH]. 122 ENRP namespace (or namespace): 123 See [RSPL-ARCH]. 125 ENRP namespace server (or ENRP server): 126 See [RSPL-ARCH]. 128 ENRP client channel: 129 The communication channel through which a PE requests for ENRP 130 namespace service. The ENRP client channel is usually defined 131 by the transport address of the home ENRP server and a well 132 known port number. 134 ENRP server channel: 135 Defined by a well known multicast IP address and a well 136 known port number. All ENRP servers in an operation scope can 137 send multicast messages to other servers through this 138 channel. PEs are also allowed to multicast on this channel 139 occasionally. 141 2. Conventions 143 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 144 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 145 they appear in this document, are to be interpreted as described in 146 [RFC2119]. 148 3. ENRP Message Definitions 150 In this section, we defines the format of all ENRP messages. These 151 are messages sent and received amongst ENRP servers in an operation 152 scope. Messages sent and received between a PE/PU and an ENRP 153 server are part of ASAP and are defined in [ASAP]. A common format, 154 defined in [RSPL-PARAM], is used for all ENRP and ASAP messages. 156 Most ENRP messages contains a combination of fixed fields and TLV 157 parameters. The TLV parameters are also defined in [PARAMS]. 159 All messages, as well as their fields/parameters described below, 160 MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., 161 the most significant byte first). 163 For ENRP, the following message types are defined: 165 Type Message Name 166 ----- ------------------------- 167 0x0 - (reserved by IETF) 168 0x1 - PEER_PRESENCE 169 0x2 - PEER_NAME_TABLE_REQUEST 170 0x3 - PEER_NAME_TABLE_RESPONSE 171 0x4 - PEER_NAME_UPDATE 172 0x5 - PEER_LIST_REQUEST 173 0x6 - PEER_LIST_RESPONSE 174 0x7-0x11 - ASAP messages, defined in [ASAP]. 175 0x12-0xFF - (reserved by IETF) 177 3.1 PEER_PRESENCE message 179 This ENRP message is used to announce (periodically) the presence 180 of an ENRP server, or to probe the status of a peer ENRP sever. 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Sender Server's ID | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Receiver Server's ID | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 R (reply_required) flag: 1 bit 194 Set to '1' if the sender requires a response to this message, 195 otherwise set to '0'. 197 Sender Server's ID: 32 bit (unsiged integer) 199 This is the ID of the ENRP server which sends the message. 201 Receiver Server's ID: 32 bit (unsiged integer) 203 This is the ID of the ENRP server to which the message is 204 intended. If the message is not intended to an individual 205 server (e.g., the message is multicasted to a group of servers), 206 this field MUST be set with all 0's. 208 Note, at startup an ENRP server MUST pick a randomly generated, 209 non-zero 32-bit unsigned integer as its ID and MUST use this same 210 ID for its entire life. 212 3.2 PEER_NAME_TABLE_REQUEST message 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length = 0xC | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Sender Server's ID | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Receiver Server's ID | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Sender Server's ID: 226 See section 3.1. 228 Receiver Server's ID: 230 See section 3.1. 232 3.3 PEER_NAME_TABLE_RESPONSE message 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type = 0x3 |0|0|0|0|0|0|R|M| Message Length | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Sender Server's ID | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Receiver Server's ID | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 : : 244 : Pool entry #1 (see below) : 245 : : 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 : : 248 : ... : 249 : : 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 : : 252 : Pool entry #n (see below) : 253 : : 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 R (Reject) flag: 1 bit 258 MUST be set to '1' if the sender of this message is rejecting 259 a namespace request. In such a case, this message MUST be sent 260 with no pool entries included. 262 M (More_to_send) flag: 1 bit 264 Set to '1' if the sender has more pool entries to sent in 265 subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set 266 to '0'. 268 Message Length: 16 bits (unsigned integer) 270 Indicates the entire length of the message in number of 271 octets. 273 Note, the value in Message Length field will NOT cover any 274 padding at the end of this message. 276 Sender Server's ID: 278 See section 3.1. 280 Receiver Server's ID: 282 See section 3.1. 284 Pool entry #1-#n: 286 If R flag is '0', at least one pool entry SHOULD be present in 287 the message. Each pool entry MUST start with a pool handle 288 parameter as defined in section 3.1.7, followed by one or more 289 pool element parameters, i.e.: 291 +---------------------------+ 292 : Pool handle : 293 +---------------------------+ 294 : PE #1 : 295 +---------------------------+ 296 : PE #2 : 297 +---------------------------+ 298 : ... : 299 +---------------------------+ 300 : PE #n : 301 +---------------------------+ 303 3.4 PEER_NAME_UPDATE message 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Update Action | (reserved) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Sender Server's ID | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Receiver Server's ID | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 : Pool handle : 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 : Pool Element : 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Message Length: 16 bits (unsigned integer) 323 Indicates the entire length of the message in number of 324 octets. 326 Note, the value in Message Length field will NOT cover any 327 padding at the end of this message. 329 Update Action: 16 bits (unsigned integer) 331 This field indicates what act is requested to the specified 332 PE. It MUST take one of the following values: 334 0x0 - ADD_PE: add or update the specified PE in the ENRP 335 namespace 336 0x1 - DEL_PE: delete the specified PE from the ENRP namespace. 338 Other values are reserved by IETF and MUST not be used. 340 Reserved: 16 bits 342 MUST be set to 0's by sender and ignored by the receiver. 344 Sender Server's ID: 346 See section 3.1. 348 Receiver Server's ID: 350 See section 3.1. 352 Pool handle: 354 Specifies to which the PE belongs. 356 Pool Element: 358 Specifies the PE. 360 3.5 PEER_LIST_REQUEST message 362 This ENRP message is used to request a copy of the current known 363 ENRP peer server list. This message is normally sent from a newly 364 started ENRP server to an existing ENRP server as part of the 365 initialization process of the new server. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length = 0xC | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Sender Server's ID | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Receiver Server's ID | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Sender Server's ID: 379 See section 3.1. 381 Receiver Server's ID: 383 See section 3.1. 385 3.6 PEER_LIST_RESPONSE message 387 This message is used to respond a PEER_LIST_REQUEST. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Sender Server's ID | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Receiver Server's ID | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 : Server Info Param of Peer #1 : 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 : ... : 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 : Server Info Param of Peer #n : 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 R (Reject) flag: 1 bit 407 MUST be set to '1' if the sender of this message is rejecting a 408 peer list request. In such a case, this message MUST be sent 409 with no peer server ID included. 411 Message Length: 16 bits (unsigned integer) 413 Indicates the entire length of the message in number of 414 octets. 416 Sender Server's ID: 418 See section 3.1. 420 Receiver Server's ID: 422 See section 3.1. 424 Server Information Parameter of Peer #1-#n: 426 Each contains a Server Information Parameter of a peer known to the 427 sender. The Server Information Parameter is defined in 428 [RSPL-PARAM]. 430 4. ENRP Operation Procedures 432 In this section, we discuss the operation procedures defined by 433 ENRP. An ENRP server MUST following these procedures when sending, 434 receiving, or processing ENRP messages. 436 Many of the Rserpool events call for both server-to-server and 437 PU/PE-to-server message exchanges. Only the message exchanges and 438 activities between an ENRP server and its peer(s) are considered 439 within the ENRP scope and are defined in this document. 441 Procedures for exchanging messages between a PE/PU and ENRP servers 442 are defined in [ASAP]. 444 4.1 Methods for Communicating amongst ENRP Servers 446 Within an Rserpool operation scope, ENRP servers need to 447 communicate with each other in order to exchange information such 448 as the pool membership changes, namespace data synchronization, 449 etc. 451 Two types of communications are used amongst ENRP servers: 453 - point-to-point message exchange from one ENPR server to a 454 specific peer server, and 456 - announcements from one server to all its peer servers in the 457 operation scope. 459 Point-to-point communication is always carried out over an SCTP 460 associaiton between the sending server and the receiving 461 server. 463 Announcements are communicated out with one of the following two 464 approaches: 466 1) The sending server sends the announcement message to a 467 well-known RSERPOOL IP multicast channel that its peer 468 servers subscribe to. 470 Note: Because IP multicast is not reliable, this approach does 471 not gaurrantee that all the peers will receive the announcement 472 message. Moreover, since IP multicast is not secure, this 473 approach cannot provide any security to the communication. 475 2) The sending server sends multiple copies of the announcement, 476 one to each of its peer servers, over a set of point-to-point 477 SCTP associations between the sending server and the peers. 479 This approach gaurrantees the reliabe receiption of the 480 message. When needed, data security can be achieved by using IP 481 security mechanisms such as IPsec [SCTP-IPSEC] or TLS [SCTP-TLS]. 483 In order to maximize inter-operability of ENRP servers, the 484 following rules MUST be followed: 486 1) At the startup time, a new ENRP server SHOULD make a decision 487 on whether it will enable IP multicast for ENRP announcements. 488 This decision should be based on factors such as the 489 availability of IP multicast and the security requirements 490 from the user of Rserpool. 492 2) If an ENRP server disables multicast, it then: 494 2a) MUST NOT subscribe to the well-known server multicast 495 channel, i.e., it only receives peer announcements over 496 SCTP associations, and 498 2b) MUST transmit all its out-going announcements over 499 point-to-point SCTP associations with its peers. 501 3) If an ENRP server enables itself to use multicast, it then: 503 3a) MUST subcribe to the well-known server multicast channel to 504 ready itself for receiving peers' multicast announcements, 506 3b) MUST also be prepared to receive peer announcements over 507 point-to-point SCTP associations from peers. 509 3c) MUST track internally which peers are multicast-enabled and 510 which are not. Note: A peer is always assumed to be 511 multicast-disabled until/unless an ENRP message of any type 512 is received from that peer over the well-known server 513 multicast channel. 515 3d) when sending out an announcement, MUST send a copy to the 516 well-known server multicast channel AND a copy to each of 517 the peers that are marked as multicast-disabled over a 518 point-to-point SCTP association. 520 4.2 ENRP Server Initialization 522 This section describes the steps a new ENRP server needs to take in 523 order to join the other existing ENRP servers, or to initiate the 524 namespace service if it is the first ENRP server started in the 525 operation scope. 527 4.2.1 Generate a Server Identifier 529 A new ENRP server MUST generate a 32-bit server Id that is as 530 unique as possible in the operation scope and this server Id MUST 531 remain unchanged for the lifetime of the server. Normally, a good 532 32-bit random number will be good enough as the server Id 533 ([RFC1750] provides some information on randomness guidelines). 535 4.2.2 Acquire Peer Server List 537 At startup, the ENRP server (initiating server) will first attempt 538 to learn all existing peer ENRP servers in the same operation 539 scope, or to determine that it is along in the scope. 541 The initiating server uses an existing peer server to bootstrap 542 itself into service. We call this peer server the mentor server. 544 4.2.2.1 Find the mentor server 546 If the initiating server is told about an existing peer server 547 through some administrative means (such as DNS query, configuration 548 database, startup scripts, etc), the initiating server SHOULD then 549 use this peer server as its mentor server and SHOULD skip the 550 remaining steps in this subsection. 552 If multiple existing peer servers are specified, the initiating 553 server SHOULD pick one of them as its mentor peer server, keep the 554 others as its backup menter peers, and skip the remaining steps 555 in this subsection. 557 If no existing peer server is specified to the initiating server 558 AND if multicast is available in the operation scope, the following 559 mentor peer discovery procedures SHOULD be followed: 561 1) The initiating server SHOULD first join the well-known ENRP 562 server multicast channel. 564 2) Then the initiating server SHOULD send a PEER_PRESENCE message, 565 with the 'Reply_required' flag set, over the multicast channel. 566 Upon the reception of this PEER_PRESENCE message, a peer server 567 MUST send a PEER_PRESENCE, without the 'Reply_required' flag, 568 back to the initiating server. 570 3) When the first response to its original PEER_PRESENCE arrives, 571 the initiating server SHOULD take the sender of this received 572 response as its mentor peer server. This completes the discovery 573 of the mentor peer server. 575 If responses are also received from other peers (a likely event 576 when multiple peers exist in the operation scope at the time the 577 new server started), the initiating server SHOULD keep a list of 578 those responded as its backup mentor peers (see below). 580 4) If no response to its PEER_PRESENCE message are received after 581 seconds, the initiating server SHOULD 582 repeat steps 2) and 3) for up to 583 times. After that, if there is still no response, the initiating 584 server MUST assume that it is alone in the operation scope. 586 5) If the initiating server determined that it is alone in the 587 scope, it MUST skip the procedures in Sections 4.2.2.2? to 588 4.2.3? and MUST consider its initialization complete and start 589 offering ENRP services. 591 Note, if multicast is not available (or not allowed for reasons 592 such as security concerns) in the operation scope, at least one 593 peer server MUST be specified to the initiating server through 594 administrative means, unless the initiation server is the first 595 server to start in the operation scope. 597 Note, if the administratively specified menter peer(s) fails, the 598 initiating server SHOULD use the auto-discover procedure defined in 599 steps 1-5 above. 601 4.2.2.2 Request complete server list from mentor peer 603 Once the initiating server finds its mentor peer server (by either 604 discovery or administrative means), the initiating server MUST send 605 a PEER_LIST_REQUEST message to the mentor peer server to request a 606 copy of the complete server list maintained by the mentor peer (see 607 Section 4.9? for maintaining server list). 609 Upon the reception of this request, the mentor peer server SHOULD 610 reply with a PEER_LIST_RESPONSE message and include in the message 611 body all existing ENRP servers known by the mentor peer. 613 Upon the reception of the PEER_LIST_RESPONSE message from the 614 mentor peer, the initiating server MUST use the server 615 information carried in the message to initialize its own peer 616 list. 618 However, if the mentor itself is in the process of startup and not 619 ready to provide a peer server list (for example, the mentor peer 620 is waiting for a response to its own PEER_LIST_REQUEST to another 621 server), it MUST rejest the request by the initiating server and 622 respond with a PEER_LIST_RESPONSE message with the R flag set to 623 '1', and with no server information included in the response. 625 In the case where its PEER_LIST_REQUEST is rejected by the mentor 626 peer, the initiating server SHOULD either wait for a few seconds 627 and re-send the PEER_LIST_REQUEST to the mentor server, or if there 628 is a backup mentor peer available, select another mentor peer 629 server and send the PEER_LIST_REQUEST to the new mentor server. 631 4.2.3 Download ENRP Namespace Data from Mentor Peer 633 After a peer list download is completed, the initiating server 634 MUST request a copy of the current namespace data from its mentor 635 peer server, by taking the following steps: 637 1) The initiating server MUST first send a PEER_NAME_TABLE_REQUEST 638 message to the mentor peer. 640 2) Upon the reception of this message, the mentor peer MUST start a 641 download session in which a copy of the current namespace data 642 maintained by the mentor peer is sent to the initiating server 643 in one or more PEER_NAME_TABLE_RESPONSE messages. 645 If more than one PEER_NAME_TABLE_RESPONSE message are used 646 during the download, the mentor peer MUST use the M flag in each 647 PEER_NAME_TABLE_RESPONSE message to indicate whether this 648 message is the last one for the download session. In particular, 649 the mentor peer MUST set the M flag to '1' in the outbound 650 PEER_NAME_TABLE_RESPONSE if there is more data to be transferred 651 and MUST keep track of the progress of the current download 652 session. The mentor peer MUST set the M flag to '0' in the last 653 PEER_NAME_TABLE_RESPONSE for the download session and close the 654 download session (i.e., removing any internal record of the 655 session) after sending out the last message. 657 3) During the downloading, every time the initiating server 658 receives a PEER_NAME_TABLE_RESPONSE message, it MUST transfer 659 the data entries carried in the message into its local namespace 660 database, and then check whether or not this message is the last 661 one for the download session. 663 If the M flag is set to '1' in the just processed 664 PEER_NAME_TABLE_RESPONSE message, the initiating server MUST 665 send another PEER_NAME_TABLE_REQUEST message to the mentor peer 666 to request for the next PEER_NAME_TABLE_RESPONSE message. 668 4) When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 669 message into its local namespace database, the initiating 670 server MUST handle each pool entry carried in the message using 671 the following rules: 673 4a) If the pool does not exist in the local namespace, the 674 initiating server MUST creates the pool in the local 675 namespace and add the PE(s) in the pool entry to the pool. 677 When creating the pool, the initiation server MUST set the 678 overall member selection policy type of the pool to the 679 policy type indicated in the first PE. 681 4b) If the pool already exists in the local namespace, but the 682 PE(s) in the pool entry is not currently a member of the 683 pool, the initiating server MUST add the PE(s) to the pool. 685 4c) If the pool already exists in the local namespace AND the 686 PE(s) in the Pool entry is already a member of the pool, the 687 initiating server server SHOULD replace the attributes of 688 the existing PE(s) with the new information. 690 5) When the last PEER_NAME_TABLE_RESPONSE message is received from 691 the mentor peer and unpacked into the local namespace, the 692 initialization process is completed and the initiating server 693 SHOULD start to provide ENRP services. 695 Under certain circumstances, the mentor peer itself may not be able 696 to provide a namespace download to the initiating server. For 697 example, the mentor peer is in the middle of initializing its own 698 namespace database, or it has currently too many download sessions 699 open to other servers. 701 In such a case, the mentor peer MUST rejest the request by the 702 initiating server and respond with a PEER_NAME_TABLE_RESPONSE 703 message with the R flag set to '1', and with no pool entries 704 included in the response. 706 In the case where its PEER_NAME_TABLE_REQUEST is rejected by the 707 mentor peer, the initiating server SHOULD either wait for a few 708 seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor 709 server, or if there is a backup mentor peer available, select 710 another mentor peer server and send the PEER_NAME_TABLE_REQUEST to 711 the new mentor server. 713 A started namespace download session may get interrupted for some 714 reason. To cope with this, the initiating server SHOULD start a 715 timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST to 716 its mentor peer. If this timer expires without receiving a response 717 from the mentor peer, the initiating server SHOULD abort the 718 current download session and re-start a new namespace download with 719 a backup mentor peer, if one is available. 721 Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the 722 mentor peer has still more data to send, it SHOULD start a session 723 timer. If this timer expires without receiving another request from 724 the initiating server, the mentor peer SHOULD abort the session, 725 cleaning out any resource and record of the session. 727 4.3 Handle PE Registration 729 To register itself with the namespace, a PE sends a REGISTRATION 730 message to its home ENRP server. The format of REGISTRATION message 731 and rules of sending it are defined in [ASAP]. 733 In the REGISTRATION message, the PE indicates the name of the pool 734 it wishes to join in a pool handle parameter, and its complete 735 transport information and any load control information in a PE 736 parameter. 738 The ENRP server handles the REGISTRATION message according to the 739 following rules: 741 1) If the named pool does not exist in the namespace, the ENRP 742 server MUST creates a new pool with that name in the namespace and 743 add the PE to the pool as its first PE; 745 When a new pool is created, the overall member selection policy of 746 the pool MUST be set to the policy type indicated by the first PE. 748 2) If the named pool already exists in the namespace, but the 749 requesting PE is not currently a member of the pool, the ENRP server 750 will add the PE as a new member to the pool; 752 After adding the PE to the pool, the server MUST check if the 753 policy type indicated by the PE is the same as the overall policy 754 type of the pool. If different, the ENRP server MUST attempt to 755 override the PE's policy and make it the same as the overall 756 policy. 758 2a) If no additional policy-related information are required to 759 perform the override (e.g., overriding Least-used with Round-robin 760 does not require additional policy-related information), the ENRP 761 server MUST replace the PE's policy type with the overall policy 762 type. 764 2b) If additional policy information is required (e.g., 765 overriding Round-robin with Least-load will require the knowledge 766 of the load factor of the PE), the ENRP server MUST reject the 767 regirstration with an error code "Pooling policy inconsistent". 769 3) If the named pool already exists in the namespace AND the 770 requesting PE is already a member of the pool, the ENRP server 771 SHOULD consider this as a re-registration case. The ENRP Server 772 SHOULD replace the attributes of the existing PE with the 773 information carried in the received REGISTRATION message. 775 4) The ENRP server may reject the registration due to reasons such 776 as invalid values, lack of resource, authentication failure, etc. 778 In all above cases, the ENRP server MUST reply to the requesting PE 779 with a REGISTRATION_RESPONSE message. In the message, the ENRP 780 server MUST set the Action code to indicate that this is a response 781 to a PE registration and MUST indicate in the Result code whether 782 the registration is granted or rejected. 784 If the registration is granted with a polcy override (see Step 2a 785 above), in addition to the Result code, in the 786 REGISTRATION_RESPONSE message the ENRP server SHOULD also send back 787 the registrant PE the new policy, in a Member Selection Policy 788 Parameter, so as to inform the PE that a policy override is 789 performed. 791 If the registration is granted (i.e., one of cases 1-3 above), the 792 ENRP server MUST take the namespace update action as described in 793 Section 4.6? to inform its peers about the change just made. If the 794 registration is denied, no message will be send to its peers. 796 4.3.1 Rules on PE Re-registration 798 A PE may re-register itself to the namespace with a new set of 799 attributtes in order to, for example, extend its registration 800 life, change its load factor value, etc. 802 A PE may modify its load factor value at any time via 803 re-registration. Based on the number of PEs in the pool and the 804 pool's overall policy type, this operation allows the PE to 805 dynamically control its share of inbound messages received by the 806 pool (also see Section 4.5.2 in [ASAP] for more on load control). 808 Moreover, when re-registering, the PE MUST NOT change its policy 809 type. The server MUST reject the re-registration if the PE attempt 810 to change its policy type. In the rejection, the server SHOULD 811 attach an error code "Pooling policy inconsistent". 813 4.4 Handle PE De-registration 815 To remove itself from a pool, a PE sends a DEREGISTRATION message 816 to its home ENRP server. The complete format of DEREGISTRATION 817 message and rules of sending it are defined in [ASAP]. 819 In the DEREGISTRATION message the PE indicates the name of the 820 pool it belongs to in a pool handle parameter and provides its PE 821 identifer. 823 Upon receiving the message, the ENRP server SHALL remove the PE 824 from its namespace. Moreover, if the PE is the last one of the 825 named pool, the ENRP server will remove the pool from the namespace 826 as well. 828 If the ENRP server fails to find any record of the PE in its 829 namespace, it SHOULD consider the de-registration granted and 830 completed. 832 The ENRP server may reject the de-registration request for various 833 reasons, such as invalid parameters, authentication failure, etc. 835 In response, the ENRP server MUST send a REGISTRATION_RESPONSE 836 message to the PE. In the message, the ENRP server MUST set the 837 Action code to indicate that this is a response to a PE 838 de-registration, and indicate in the Result code whether the 839 request is granted or rejected. 841 It should be noted that de-registration does not stop the PE from 842 sending or receiving application messages. 844 Once the de-registration request is granted AND the PE removed from 845 its local copy of the namespace, the ENRP server MUST take the 846 namespace update action described in Section 4.6? to inform its 847 peers about the change just made. Otherwise, NO message SHALL be 848 send to its peers. 850 4.5 Pool Handle Translation 852 A PE or PU uses the pool handle translation service of an ENRP 853 server to resolve a pool handle to a list of accessible transport 854 addresses of the member PEs of the pool. 856 This requires the PE or PU to send a NAME_RESOLUTION message to its 857 home ENRP server and in the NAME_RESOLUTION message specify the 858 pool handle to be translated in a Pool Handle parameter. Complete 859 defintion of the NAME_RESOLUTION message and the rules of sending 860 it are defined in [ASAP]. 862 Upon reception of the NAME_RESOLUTION message, the ENRP server MUST 863 first look up the pool handle in its namespace. If the pool exits, 864 the home ENRP server MUST compose and send back a 865 NAME_RESOLUTION_RESPONSE message to the requesting PU or PE. 867 In the response message, the ENRP server MUST list all the PEs 868 currently registered in this pool, in a list of PE parameters. The 869 ENRP server MUST also include a pool member selection policy 870 parameter to indicate the overall member selection policy for the 871 pool, if the current pool member selection policy is not 872 round-robin (if the overall policy is round-Robin, this parameter 873 MAY be omitted?). 875 If the named pool does not exist in the namespace, the ENRP server 876 MUST respond with a NAME_UNKNOWN message. 878 The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN 879 messages and the rules of receiving them are defined in [ASAP]. 881 4.6 Server Namespace Update 883 This includes a set of update operations used by an ENRP server to 884 inform its peers when its local namespace is modified, e.g., 885 addition of a new PE, removal of an existing PE, change of pool 886 or PE properties. 888 4.6.1 Announcing Addition or Update of PE 890 When a new PE is granted registration to the namespace or an 891 existing PE is granted a re-registration, the home ENRP server 892 uses this procedure to inform all its peers. 894 This is an ENRP announcement and is sent to all the peer of the 895 home ENRP server. See Section 4.1 on how annoucements are sent. 897 An ENRP server MUST announce this update to all its peers in a 898 PEER_NAME_UPDATE message with the Update action field set to 899 ADD_PE, indicating the addition of a new PE or the modification of 900 an existing PE. The complete new information of the PE and the pool 901 its belongs to MUST be indicated in the message with a PE parameter 902 and a Pool Handle parameter, respectively. 904 The home ENRP server SHOULD fill in its server Id in the Sender 905 Server's ID field and leave the Receiver Server's ID blank (i.e., 906 all 0's). 908 When a peer receives this PEER_NAME_UPDATE message, it MUST take 909 the following actions: 911 1) If the named pool indicated by the pool handle does not exist 912 in its local copy of the namespace, the peer MUST create the named 913 pool in its local namespace and add the PE to the pool as the first 914 PE. It MUST then copy in all other attributes of the PE carried 915 in the message. 917 When the new pool is created, the overall member selection policy 918 of the pool MUST be set to the policy type indicated by the PE. 920 2) If the named pool already exists in the peer's local copy of 921 the namespace AND the PE does not exist, the peer MUST add the PE 922 to the pool as a new PE and copy in all attributes of the PE 923 carried in the message. 925 3) If the named pool exists AND the PE is already a member of the 926 pool, the peer MUST replace the attributes of the PE with the new 927 information carried in the message. 929 4.6.2 Announcing Removal of PE 931 When an existing PE is granted de-registration or is removed from 932 its namespace for some other reasons (e.g., purging an unreachable 933 PE), the ENRP server MUST uses this procedure to inform all its 934 peers about the change just made. 936 This is an ENRP announcement and is sent to all the peer of the 937 home ENRP server. See Section 4.1 on how annoucements are sent. 939 An ENRP server MUST announce the PE removal to all its peers in a 940 PEER_NAME_UPDATE message with the Update action field set to 941 DEL_PE, indicating the removal of an existing PE. The complete 942 information of the PE and the pool its belongs to MUST be indicated 943 in the message with a PE parameter and a Pool Handle parameter, 944 respectively. 946 [editor's note: only the pool handle and the PE's id are needed, it 947 should reduce the size of the message] 949 The sending server MUST fill in its server ID in the Sender 950 Server's ID field and leave the Receiver Server's ID blank (i.e., 951 set to all 0's). 953 When a peer receives this PEER_NAME_UPDATE message, it MUST first 954 find pool and the PE in its own namespace, and then remove the PE 955 from its local namespace. If the removed PE is the last one in the 956 pool, the peer MUST also delete the pool from its local namespace. 958 If the peer fails to find the PE or the pool in its namespace, it 959 SHOULD take no further actions. 961 4.7 Detecting and Removing Unreachable PE 963 Whenever a PU finds a PE unreachable (e.g., via an SCTP 964 SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the PU 965 SHOULD send an ENDPOINT_UNREACHABLE message to its home ENRP 966 server. The message SHOULD contain the pool handle and the PE Id 967 of the unreachable PE. 969 Upon the reception of an ENDPOINT_UNREACHABLE message, a server 970 MUST immediately send a point-to-point ENDPOINT_KEEP_ALIVE message 971 to the PE in question. If this ENDPOINT_KEEP_ALIVE fails (i.e., it 972 results in an SCTP SEND.FAILURE notification), the ENRP server MUST 973 consider the PE as truly unreachable and MUST remove the PE from 974 its namespace and take actions described in 4.6.2?. 976 If the ENDPOINT_UNREACHABLE message is transmitted successfully to 977 the PE, the ENRP server MUST retain the PE in its namespace. 978 Moreover, the server SHOULD keep a counter to record how 979 many ENDPOINT_UNREACHABLE messages it has received reporting 980 reachability problem relating to this PE. If the counter exceeds 981 the protocol threshold , the ENRP server SHOULD 982 remove the PE from its namespace and take actions described in 983 Section 4.6.2?. 985 The complete definition and rules of sending ENDPOINT_UNREACHABLE 986 and ENDPOINT_KEEP_ALIVE messages are described in [ASAP]. 988 4.8 Helping PE and PU to Discover Home ENRP Server 990 At its startup time, or whenever its current home ENRP server is 991 not providing services, a PE or PU will attempt to find a new home 992 server. The PE or PU will either multicast or send a point-to-point 993 SERVER_HUNT message to one or more ENRP servers in the operation 994 scope. For the complete procedure of this, see Section xxxx in 995 [ASAP]. 997 To support this procedure, whenever a SERVER_HUNT message is 998 received an ENRP server SHOULD immediately respond to the sending 999 PE or PU with a SERVER_HUNT_RESPONSE message. 1001 4.9 Maintaining Peer List and Monitoring Peer Status 1003 An ENRP server MUST keep internally a record on the status of each 1004 of its known peers. This record is referred to as the server's 1005 "peer list" 1007 4.9.1 Discovering New Peer 1009 If a message of any type is received from a previously unknown 1010 peer, the ENRP server MUST consider this peer a new peer in the 1011 operation scope and add it to the peer list. 1013 If the message is 1014 received over the well-known server multicast channel, the ENRP 1015 server MUST mark this new peer as multicast-enabled. Otherwise, the 1016 new peer MUST be marked as multicast-disabled (see Section 4.1 for 1017 more details). 1019 [editor's note: should we ask for a peer list from the new peer? 1020 this may help mending two splitted networks.] 1022 [editor's note: we also want to send a reply-required probe to 1023 force the new peer to send us its Server Info Param.. so we can now 1024 it details]. 1026 4.9.2 Server Sending Heartbeat 1028 Every seconds, an ENRP server MUST announce 1029 its continued presence to all its peer with a PEER_PRESENCE 1030 message. In the PEER_PRESENCE message, the ENRP server MUST set the 1031 'Replay_required' flag to '0', indicating that no response is 1032 required. 1034 The arrival of this periodic PEER_PRESENCE message will cause all 1035 its peers to update their internal variable for 1036 the sending server (see Section 4.9.3? for more details). 1038 4.9.3 Detecting Peer Server Failure 1040 An ENRP server MUST keep an interanl variable 1041 for each of its known peers and the value of this variable MUST be 1042 updated to the current local time everytime a message of any type 1043 (point-to-point or announcement) is received from the cooresponding 1044 peer. 1046 If a peer has not been heard for more than 1047 seconds, the ENRP server MUST immediately send a point-to-point 1048 PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1050 If the send fails or the peer does not reply after 1051 seconds, the ENRP server MUST consider the 1052 peer server dead and remove the peer from its peer list. 1054 4.10 Namespace Data Auditing and Re-synchronization 1056 [TBD] 1058 4.11 Reporting Unrecognized Message or Unrecognized Parameter 1060 [TBD] 1062 5. Variables and Time Constants 1064 5.1 Variables 1066 - the local time that a peer server was last 1067 heard (via receiving either a multicast or 1068 point-to-point message from the peer). 1070 5.2 Timer Constants 1072 - the maximal number of attempts a sender 1073 will make to contact an ENRP server 1074 (Default=3 times). 1076 - pre-set threshold for how long a sender 1077 will wait for a response from an ENRP 1078 server (Default=5 secends). 1080 - the period for an ENRP server to announce a 1081 heartheat message to all its known peers. 1082 (Default=30 secs.) 1084 - pre-set threshold for how long an ENRP 1085 server will wait before considering a 1086 silent peer server potentially dead. 1087 (Default=61 secs.) 1089 - pre-set threshold for how long a message 1090 sender will wait for a response after 1091 sending out a message. (Default=5 secs.) 1093 - the maximal number of unreachability reports 1095 on a PE that an ENRP server will allow 1096 before purging this PE from the namespace. 1097 (Default=3) 1099 6. Security Considerations 1101 Due to varying requirements and multiple use cases of Rserpool, we 1102 point out two basic security protocols, IPsec and TLS. We 1103 specifically do not discuss whether one security protocol would be 1104 preferred over the other. This choice will be made by designers 1105 and network architects based on system requirements. 1107 For networks that demand IPsec security, implementations MUST 1108 support [SCTP-IPSEC] which describes IPsec-SCTP. IPsec is two 1109 layers below RSerPool. Therefore, if IPsec is used for securing 1110 Rserpool, no changes or special considerations need to be made to 1111 Rserpool to secure the protocol. 1113 For networks that cannot or do not wish to use IPsec and prefer 1114 instead TLS, implementations MUST support TLS with SCTP as 1115 described in [SCTP-TLS] or TLS over TCP as described in [RFC2246]. 1116 When using TLS/SCTP we must ensure that RSerPool does not use any 1117 features of SCTP that are not available to an TLS/SCTP user. This 1118 is not a difficult technical problem, but simply a 1119 requirement. When describing an API of the RSerPool lower layer we 1120 have also to take into account the differences between TLS and 1121 SCTP. This is also not difficult, but it is in contrast to the 1122 IPsec solution which is transparently layered below Rserpool. 1124 Support for security is required for the ENRP server and the PEs. 1125 Security support for the Rserpool end user is optional. Note that 1126 the end user implementation contains a piece of the Rserpool 1127 protocol -- namely ASAP -- whereby the pool handle is passed for 1128 name resolution to the ENRP server and IP address(es) are 1129 returned. 1131 The argument for optional end user security is as follows: If the 1132 user doesn't require security protection for example, against 1133 eavesdropping for the request for pool handle resolution and 1134 response, then they are free to make that choice. However, if the 1135 end user does require security, they are guaranteed to get it due 1136 to the requirement for security support for the ENRP server. It is 1137 also possible for the ENRP server to reject an unsecured request 1138 from the user due to its security policy in the case that it 1139 requires enforcement of strong security. But this will be 1140 determined by the security requirements of the individual network 1141 design. 1143 7. References 1145 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1146 3", BCP 9, RFC 2026, October 1996. 1148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1149 Requirement Levels", BCP 14, RFC 2119, March 1997. 1151 [RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0", 1152 RFC 2246, January 1999. 1154 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 1155 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, 1156 V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October 1157 2000. 1159 [RFC3237] M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, 1160 J. Loughney, M. Stillman: "Requirements for Reliable Server 1161 Pooling", RFC 3237, January 2002. 1163 [ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol 1164 (ASAP)", , work in progress. 1166 [RSPL-ARCH] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, 1167 L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server 1168 Pooling," , work in progress. 1170 [SCTP-TLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP", 1171 draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress. 1173 [SCTP-IPSEC] S.M. Bellovin, J. Ioannidis, A.D. Keromytis, 1174 R.R. Stewart, "On the Use of SCTP with IPsec", 1175 , work in progress. 1177 [RSPL-PARAM] R. Stewart, Q. Xie: "Aggregate Server Access Protocol 1178 (ASAP) and Endpoint Name Resolution Protocol (ENRP) Common 1179 Parameters Document", , 1180 work in progress. 1182 7.1 Informative References 1184 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for 1185 Security", RFC 1750, December 1994. 1187 8. Acknowledgements 1189 The authors wish to thank John Loughney, Lyndon Ong, and many 1190 others for their invaluable comments. 1192 9. Authors' Addresses 1194 Qiaobing Xie Phone: +1-847-632-3028 1195 Motorola, Inc. EMail: qxie1@email.mot.com 1196 1501 W. Shure Drive, 2-F9 1197 Arlington Heights, IL 60004 1198 USA 1200 Randall R. Stewart Phone: +1-815-477-2127 1201 24 Burning Bush Trail. EMail: rrs@cisco.com 1202 Crystal Lake, IL 60012 1203 USA 1205 Maureen Stillman Phone: +1 607 273 0724 62 1206 Nokia EMail: maureen.stillman@nokia.com 1207 127 W. State Street 1208 Ithaca, NY 14850 1209 USA 1211 Expires in six months from May 2002