idnits 2.17.1 draft-ietf-rserpool-enrp-02.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 3 longer pages, the longest (page 20) being 99 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 55 instances of lines with control characters in the document. ** The abstract seems to contain references ([RSERPOOL1], [ASAP], [RSERPOOL2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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). -- 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 (March 1, 2002) is 8085 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2026' is defined on line 1062, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSERPOOL1' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSERPOOL2' ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-sctp-03 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 5 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 March 1, 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) [ASAP] 32 to accomplish the functionality of the Reliable Server Pooling 33 (Rserpool) requirements and architecture as defined in [RSERPOOL1] 34 and [RSERPOOL2]. 36 Within the operational scope of Rserpool, ENRP defines the 37 procedures and message formats of a distributed fault-tolerant 38 registry service for storing, bookkeeping, retrieving, and 39 distributing pool operation and membership information. 41 Table Of Contents 43 1. Introduction...............................................2 44 1.2 Definitions............................................2 45 2. Conventions................................................3 46 3. Message Definitions........................................4 47 3.1 ENRP Parameter Formats.................................4 48 3.1.1 IPv4 Address Parameter...........................5 49 3.1.2 IPv6 Address Parameter ..........................5 50 3.1.3 Pool Element Parameter...........................6 51 3.1.4 Pool Handle Parameter............................6 52 3.1.5 Authorization Parameter..........................7 53 3.1.6 Name Server Identifier Parameter.................7 54 3.2 ENRP Message Formats..................................7 55 3.2.1 PEER_PRESENCE message...........................8 56 3.2.2 PEER_NAME_TABLE_REQUEST message.................9 57 3.2.3 PEER_NAME_TABLE_RESPONSE message................9 58 3.2.4 PEER_NAME_UPDATE message........................10 59 3.2.5 PEER_LIST_REQUEST message.......................11 60 3.2.6 PEER_LIST_RESPONSE message......................11 61 4. ENRP Operation Procedures..................................12 62 4.1 Basic ENRP Operations..................................12 63 4.1.1 PE Registration..................................12 64 4.1.2 PE De-registration...............................13 65 4.1.3 PE Re-registration...............................13 66 4.1.4 Name Translation.................................14 67 4.1.5 Server Namespace Update..........................15 68 4.1.5.1 Add/Update a PE..........................15 69 4.1.5.2 Remove a PE..............................15 70 4.1.6 Server Download Namespace from a Peer Server.....16 71 4.1.7 Server Monitor Peer Status.......................17 72 4.1.8 Server Download Peer List from a Peer Server.....17 73 4.1.9 Server Initialization............................17 74 4.2 Fault Management Operations............................18 75 4.2.1 Detect and Remove an Unreachable PE..............18 76 4.2.2 Server Failure Detection by Heartbeat............19 77 4.2.3 PE or PU Discover Home ENRP Server...............19 78 5. Variables and Timer Constants..............................20 79 5.1 Variables..............................................20 80 5.2 Timer Constants........................................20 81 6. Security COnsiderations....................................20 82 7. References.................................................20 83 8. Acknowledgements...........................................21 84 9. Authors' Addresses.........................................21 86 1. Introduction 88 Endpoint Name Resolution Protocol (ENRP) is designed to work in 89 conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP] 90 to accomplish the functionality of the Reliable Server Pooling 91 (Rserpool) requirements and architecture as defined in [RSERPOOL1] 92 and [RSERPOOL2]. 94 Within the operation scope of Rserpool, ENRP defines the procedures 95 and message formats of a distributed fault-tolerant registry service 96 for storing, bookkeeping, retrieving, and distributing pool 97 operation and membership information. 99 Whenever appropriate, in the rest of this document we will refer to 100 this Rserpool registry service as ENRP namespace, or simply 101 namespace. 103 1.2 Definitions 104 This document uses the following terms: 106 Operation scope: 107 The part of the network visible to pool users by a specific 108 instance of the reliable server pooling protocols. 110 Pool (or server pool): 111 A collection of servers providing the same application 112 functionality. 114 Pool handle (or pool name): 115 A logical pointer to a pool. Each server pool will be 116 identifiable in the operation scope of the system by a unique 117 pool handle or "name". 119 ENRP namespace (or namespace): 120 A cohesive structure of pool names and relations that may be 121 queried by an internal or external agent. 123 Pool element (PE): 124 A server entity that runs ASAP and has registered to a pool. 126 Pool user (PU): 127 A server pool user that runs ASAP. Note, a PU can also be a 128 PE if it has registered itself to a pool. 130 ENRP namespace server (or ENRP server): 131 Entity which runs ENRP and is responsible for managing and 132 maintaining the namespace within the operation scope. 134 ENRP client channel: 135 The communication channel through which a PE requests for 136 ENRP namespace service. The ENRP client channel is usually 137 defined by the transport address of the home ENRP server and 138 a well known port number. 140 ENRP server channel: 141 Defined by a well known multicast IP address and a well 142 known port number. All ENRP servers in an operation scope 143 can send multicast messages to other servers through this 144 channel. PEs are also allowed to multicast on this channel 145 occasionally. 147 Network Byte Order: 148 Most significant byte first, a.k.a Big Endian. 150 2. Conventions 152 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 153 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 154 they appear in this document, are to be interpreted as described in 155 [RFC2119]. 157 3. Message Definitions 159 All messages as well as their fields described below shall be in 160 Network Byte Order during transmission. For fields with a length 161 bigger than 4 octets, a number in a pair of parentheses may follow 162 the filed name to indicate the length of the field in number of 163 octets. 165 3.1 ENRP Parameter Formats 167 ENRP parameters are defined in a Type-length-value (TLV) format as 168 shown below. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Parameter Type | Parameter Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 : : 176 : Parameter Value : 177 : : 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Parameter Type: 16 bits (unsigned integer) 182 The Type field is a 16 bit identifier of the type of parameter. 183 It takes a value of 0 to 65534. 185 The value of 65535 is reserved for IETF-defined extensions. Values 186 other than those defined in specific SCTP chunk description are 187 reserved for use by IETF. 189 Parameter Length: 16 bits (unsigned integer) 191 The Parameter Length field contains the size of the parameter in 192 bytes, including the Parameter Type, Parameter Length, and 193 Parameter Value fields. Thus, a parameter with a zero-length 194 Parameter Value field would have a Length field of 4. The 195 Parameter Length does not include any padding bytes. 197 Parameter Value: variable-length. 199 The Parameter Value field contains the actual information to be 200 transferred in the parameter. 202 The total length of a parameter (including Type, Parameter Length and 203 Value fields) MUST be a multiple of 4 bytes. If the length of the 204 parameter is not a multiple of 4 bytes, the sender pads the Parameter 205 at the end (i.e., after the Parameter Value field) with all zero 206 bytes. The length of the padding is not included in the parameter 207 length field. A sender SHOULD NOT pad with more than 3 bytes. The 208 receiver MUST ignore the padding bytes. 210 The Parameter Types are encoded such that the highest-order two bits 211 specify the action that must be taken if the processing endpoint does 212 not recognize the Parameter Type. 214 00 - Stop processing this ENRP message and discard it, do not process 215 any further parameters within it. 217 01 - Stop processing this ENRP message and discard it, do not process 218 any further parameters within it, and report the unrecognized 219 parameter in an 'Unrecognized Parameter Type' error. 221 10 - Skip this parameter and continue processing. 223 11 - Skip this parameter and continue processing but report the 224 unrecognized parameter in an 'Unrecognized Parameter Type' 225 error. 227 In the following sections, we define the common parameter formats 228 used in ENRP. 230 3.1.1 IPv4 Address Parameter 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type = 0x1 | Length = 8 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | IPv4 Address | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 IPv4 Address: 32 bits (unsigned integer) 242 Contains an IPv4 address of the sending endpoint. It is binary 243 encoded. 245 3.1.2 IPv6 Address Parameter 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = 0x2 | Length = 20 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 | IPv6 Address | 254 | | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 IPv6 Address: 128 bit (unsigned integer) 259 Contains an IPv6 address of the sending endpoint. It is binary 260 encoded. 262 3.1.3 Pool Element Parameter 264 This parameter is used in multiple ENRP message to represent an ASAP 265 endpoint (i.e., a PE in a pool) and the associated information, such 266 as its transport address(es), load control, and other operational 267 status information of the PE. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type = 0x3 | Length=variable | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | SCTP Port | Number of IP addrs=k | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 : IP addr param #0 : 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 : IP addr param #1 : 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 : : 281 : ..... : 282 : : 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 : IP addr param #k : 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Load Policy Type | Policy Value | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Registration Life | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Each of the IP address parameters in a PE parameter can be either 292 an IPv4 or IPv6 address parameter. 294 3.1.4 Pool Handle Parameter 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type = 0x4 | Length=variable | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 : : 302 : Pool Handle : 303 : : 304 : : 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 This parameter holds a pool handle (i.e., a pool name), defined as 308 a NULL terminated ASCII string. 310 3.1.5 Authorization Parameter 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type = 0x5 | Length=variable | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 : : 318 : Authorization Signature : 319 : : 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 This parameter is used to hold an authorization signature. The 323 signature is signed over the entire ASAP message and uses a 324 preconfigured public/private key pair. The receiver of a message 325 which includes this parameter can validate the message is 326 from the sender by comparing the signature to one generated 327 using the peers public key. 329 3.1.6 Name Server Identifier Parameter 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type = 0x7 | Length=variable | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Name Server SCTP Port | (reserved) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 : IPv4 or IPv6 Addr Param : 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 When a name server is multi-homed, any one of its IP addresses can 342 be used in its Server Identifier Parameter. This is because the 343 combination of any one of its IP addresses and its SCTP port 344 number always uniquely identifies the server. 346 3.2 ENRP Message Formats 348 The figure below illustrates the common format for all ENRP 349 messages. Each message is formatted with a Message 350 Type field, a message-specific Flag field, a Message Length field, and a 351 Value field. 353 0 1 2 3 354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Message Type | Msg Flags | Message Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 : : 359 : Message Value : 360 : : 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Message Type: 8 bits (unsigned integer) 365 This field identifies the type of information contained in the 366 Message Value field. It takes a value from 0 to 254. The value 367 of 255 is reserved for future use as an extension field. 369 Message Types are encoded such that the highest-order two bits 370 specify the action that must be taken if the message receiver 371 does not recognize the Message Type. 373 00 - Stop processing this message and discard it. 375 01 - Stop processing this message and discard it, and report the 376 unrecognized message in an 'Unrecognized Parameter Type' 377 error. 379 10 - reserved. 381 11 - reserved. 383 Message Flags: 8 bits 385 The usage of these bits depends on the message type as given by 386 the Message Type. Unless otherwise specified, they are set to 387 zero on transmit and are ignored on receipt. 389 Message Length: 16 bits (unsigned integer) 391 This value represents the size of the message in bytes including 392 the Message Type, Message Flags, Message Length, and Message 393 Value fields. Therefore, if the Message Value field is 394 zero-length, the Length field will be set to 4. The Message 395 Length field does not count any padding. 397 Message Value: variable length 399 The Message Value field contains the actual information to be 400 transferred in the message. The usage and format of this field 401 is dependent on the Message Type. 403 The total length of a message (including Type, Length and Value 404 fields) MUST be a multiple of 4 bytes. If the length of the 405 message is not a multiple of 4 bytes, the sender MUST pad the 406 message with all zero bytes and this padding is not included in the 407 message length field. The sender should never pad with more than 3 408 bytes. The receiver MUST ignore the padding bytes. 410 3.2.1 PEER_PRESENCE message 412 0 1 2 3 413 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 : Sender's Server ID param : 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 : Receiver's Server ID param (optional) : 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 : Authorization Parameter (optional) : 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 The receiving server's ID does not need to be included if the 426 message is being multicasted. 428 "Reply_required" (R) flag shall be set to '1' if response to this 429 message is required, otherwise set to '0'. 431 3.2.2 PEER_NAME_TABLE_REQUEST message 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 : Sender's Server ID param : 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 : Receiver's Server ID param (optional) : 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 : Authorization Parameter (optional) : 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 The receiving server's ID does not need to be included if the 446 message is being multicasted. 448 (Editor's note: we may not support multicast of this message). 450 3.2.3 PEER_NAME_TABLE_RESPONSE message 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type = 0x3 |0|0|0|0|0|0|0|M| Message Length | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 : Sender's Server ID param : 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 : Receiver's Server ID parameter : 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 : : 462 : Pool entry #1 (see below) : 463 : : 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 : : 466 : ... : 468 : : 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 : : 471 : Pool entry #n (see below) : 472 : : 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 : Authorization Parameter (optional) : 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 "More_to_send" (M) flag: 479 shall be set to '1' if there are more pool entries to be sent 480 in subsequent PEER_NAME_TABLE_RESPONSE messages. Otherwise, it 481 shall be set to '0'. 483 Pool entries: 485 At least one pool entry MUST be present in the message. Each 486 pool entry MUST start with a pool handle parameter, followed by 487 one or more pool element (PE) parameters, i.e.: 489 +---------------------------+ 490 : Pool handle : 491 +---------------------------+ 492 : PE #1 : 493 +---------------------------+ 494 : PE #2 : 495 +---------------------------+ 496 : ... : 497 +---------------------------+ 498 : PE #n : 499 +---------------------------+ 501 3.2.4 PEER_NAME_UPDATE message 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 : Sender's Server ID param : 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 : Receiver's Server ID param (optional) : 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 : : 513 : Pool handle : 514 : : 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 : : 517 : Pool Element : 518 : : 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Update action | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 : Authorization Parameter (optional) : 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 The receiving server's ID does not need to be included if the 526 message is being multicasted. 528 "Update_action" field: 530 shall take one of the following values: 532 0x0 - ADD_PE: add the PE as a new member to or update the PE in 533 the named pool in the namespace. 534 0x1 - DELETE_PE: delete the specified PE from the namespace. 536 3.2.5 PEER_LIST_REQUEST message 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 : Sender's Server ID param : 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 : Receiver's Server ID param (optional) : 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 : Authorization Parameter (optional) : 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 The receiving server's ID does not need to be included if the 551 message is being multicasted. 553 3.2.6 PEER_LIST_RESPONSE message 555 This message shall contain all the peer information of the sending 556 server. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 : Sender's Server ID param : 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 : Receiver's Server ID parameter : 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 : ID of Peer Server #1 : 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 : ... : 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 : ID of Peer Server #n : 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 : Authorization Parameter (optional) : 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 "Reject" (R) flag: 578 shall be set to '1' if the sender of this message is rejecting 579 a peer list request. In such a case, this message MUST be sent 580 with no peer server ID included. 582 4. ENRP Operation Procedures 584 In this section, we discuss the procedures defined by ENRP. The 585 procedures are divided into two groups, namely the basic ENRP 586 operations and fault management procedures. 588 Many of the Rserpool events call for message exchange and other 589 activities between both a PE and an ENRP server and the ENRP server 590 and its peers. But only the message exchange and activities between 591 the ENRP server and its peers are considered within the ENRP 592 protocol definition scope 594 Procedures and message formats for communications between the PE 595 and ENRP servers are defined in [ASAP]. However, in order to put 596 our discussion in context, we will give brief description of the 597 ASAP activities whenever appropreate. 599 4.1 Basic ENRP Operations 601 4.1.1 PE Registration 603 ENRP server <-> PE: 605 This action is part of the ASAP protocol and is defined in [ASAP]. 607 To register itself with the name space, a PE sends a REGISTRATION 608 message over the ENRP client channel to its home ENRP server. 610 In the REGISTRATION message, the PE indicates the name of the pool 611 it wishes to join in a pool handle parameter, and its port number 612 and network access address(es) and any load control information in 613 a PE parameter. 615 The ENRP server handles the REGISTRATION message according to the 616 following rules: 618 1) If the named pool does not exist in the namespace, the ENRP 619 server will creates a new pool with that name in the namespace and 620 add the PE to the pool as its first PE; 622 2) If the named pool already exists in the namespace, but the 623 requesting PE is not currently a member of the pool, ENRP server 624 will add the PE as a new member to the pool; 625 3) If the named pool already exists in the namespace AND the 626 requesting PE is already a member of the pool, the ENRP server 627 shall consider this as a re-registration case. The ENRP Server 628 shall replace the attributes of the existing PE with the 629 information carried in the received REGISTRATION message. 631 4) The ENRP server may reject the registration due to reasons such 632 as invalid values, lack of resource, etc. 634 In all cases, the ENRP server will reply to the requesting PE with 635 a REGISTRATION_RESPONSE message, and will indicate in the message 636 body whether the registration is granted or rejected. 638 ENRP server <-> Its peers: 640 If the registration request is granted (i.e., cases 1-3 above), 641 the ENRP server MUST take the namespace modification action as 642 described in section 4.1.5.1?. Otherwise, no message shall be 643 exchanged with its peers. 645 4.1.2 PE De-registration 647 ENRP server <-> PE: 649 This action is part of the ASAP protocol and is defined in [ASAP]. 651 To remove itself from a pool, a PE sends a DEREGISTRATION message 652 over the ENRP client channel to its home ENRP server. 654 In response, the home ENRP server sends a REGISTRATION_RESPONSE 655 message to the PE and indicates in the message body whether the 656 request is granted or rejected. 658 If the PE is the last one of the named pool, the home ENRP server 659 will remove the pool from the namespace as well. 661 The ENRP server may reject the de-registration request due to 662 reasons such as invalid parameters, etc. 664 It should be noted that de-registration does not stop the PE from 665 sending or receiving application messages. 667 ENRP server <-> peers: 669 Once the de-registration request is granted and the PE removed from 670 its local copy of the namespace, the home ENRP server MUST take the 671 namespace modification action described in Section 4.1.5.2. 673 4.1.3 PE Re-registration 675 A PE may re-register itself to the namespace with a new set of 676 attributtes in order to, for example, extend its registration 677 life, change its load policy value. 679 However, an existing PE MUST NOT change its access address list 680 via re-registration. Instead, to change its address list a PE 681 shall de-register itself first and then register with the 682 namespace as a new PE. 684 A PE can modify its load policy value at any time via 685 re-registration. Based on the number of PEs in the pool and the 686 pool's load distrbution policy, this operation allows the PE to 687 dynamically control its share of inbound messages received by the 688 pool (also see Section 4.5.2 in [ASAP] for more on load control). 690 ENRP server <-> PE: 692 This action is part of the ASAP protocol and is defined in [ASAP]. 694 To perform a re-registration, a registered PE shall simply send 695 a new REGISTRATION message with a new set of attributes over the 696 ENRP client channel to its home ENRP server. 698 Upon the reception of this REGISTRATION message, the home ENRP 699 server shall follow the same procedures described in Section 700 4.1.1. 702 ENRP server <-> peers: 704 If the REGISTRATION message is accepted, the home ENRP server 705 shall take the action described in Section 4.1.5.1?. Otherwise, no 706 message shall be exchanged with its peers. 708 4.1.4 Name Translation 710 ENRP server <-> PE or PU: 712 This action is part of the ASAP protocol and is defined in [ASAP]. 714 A PE or PU can use the name translation service provided by the ENRP 715 server to resolve a pool name to a list of accessible transport 716 addresses of existing PEs. 718 This requires the PE or PU to send a NAME_RESOLUTION messages to its 719 home ENRP server and in the NAME_RESOLUTION message specify the pool 720 name to be translated in a Pool Handle parameter. 722 If the named pool exits in the namespace, the home ENRP server will 723 send back a NAME_RESOLUTION_RESPONSE message that shall carry a 724 list of PE parameters containing all information of the PEs 725 currently registered under that pool name. This information may 726 include the current load control policy of the pool, policy value 727 of each PE, transport address(es) for each PE, etc. 729 Otherwise, the ENRP server shall respond with a NAME_UNKNOWN 730 message. 732 ENRP server <-> peers: 734 None. 736 4.1.5 Server Namespace Update 738 This includes a set of update operations used by an ENRP server to 739 inform its peer(s) about the addition of a new PE, removal of an 740 existing PE, or change of pool or PE properties. 742 4.1.5.1 Add/Update a PE 744 When a new PE is granted registration to the namespace or an 745 existing PE is granted a re-registration, the home ENRP server 746 uses this procedure to inform all its peers. 748 An ENRP server shall multicast over the ENRP server channel a 749 PEER_NAME_UPDATE message with the Update_action field set to 750 ADD_PE, indicating the addition of the new PE or the update of an 751 existing PE to the namespace. The PE and the pool its belongs to 752 shall be indicated in the message with a PE parameter and a Pool 753 Handle parameter, respectively (see Section 3.2.4). 755 Upon the reception of this PEER_NAME_UPDATE message, each of the 756 peer ENRP servers shall take the following actions: 758 1) If the named pool under which the PE has been registered (or 759 re-registered) does not exist in the peer's local copy of the 760 namespace, the peer ENRP server shall create the named pool in its 761 local namespace copy and add the PE to it as the first PE. It then 762 shall copy in all other attributes of the PE carried in the 763 message. 765 2) If the named pool already exists in the peer's local copy of the 766 namespace AND the PE does not exist, the peer shall add the PE to 767 the pool as a new PE and copy in all attributes of the PE carried 768 in the message. 770 3) If the named pool exists AND the PE is already a member of the 771 pool in its the local copy of the namespace, the peer ENRP server 772 shall replace the attributes of the PE with the new information 773 carried in the message. 775 4.1.5.2 Remove a PE 777 This procedure is used by an ENRP server to inform its peer(s) to 778 remove an existing PE. 780 An ENRP server shall multicast over the ENRP server channel a 781 PEER_NAME_UPDATE message with the Update_action field set to 782 DELETE_PE, indicating the removal of an existing PE from the 783 namespace. The PE and the pool its belongs to shall be indicated 784 in the message with a PE parameter and a Pool Handle parameter, 785 respectively. 787 On the reception of this PEER_NAME_UPDATE message, each peer ENRP 788 server shall find and remove the PE from its local copy of the 789 namespace. If the peer does not find the PE in its local copy of 790 the namespace, it SHOULD take no action. 792 4.1.6 Server Download Namespace from a Peer Server 794 This operation allows an ENRP server to request and receive a copy 795 of the current namespace from one of its peer ENRP servers. 797 This operation is especially useful for a newly started ENRP server 798 to initiate its local copy of the namespace, as well as for an 799 existing ENRP server to correct namespace inconsistency found during 800 its operation. 802 1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message 803 directly to one of its peers. 805 2) Upon the reception of this message, the peer server shall 806 initiate a download session in which the namespace shall be sent 807 to the requesting ENRP server in one or more 808 PEER_NAME_TABLE_RESPONSE messages. 810 If the sending ENRP server determines that multiple 811 PEER_NAME_TABLE_RESPONSE messages are needed for the session, it 812 shall use the M flag in each PEER_NAME_TABLE_RESPONSE message to 813 inform the receiving ENRP server whether or not the data 814 in this message is the last piece of the namespace transfer. 816 3) During the downloading, every time the requesting ENRP server 817 receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer the 818 data entries carried in the message into its local namespace 819 database, and then check whether or not the data in this message is 820 the last piece being transfered. If more data transfer is indicated, 821 the requesting ENRP server shall send another 822 PEER_NAME_TABLE_REQUEST message to the same peer to request for the 823 next piece whenever it is ready. 825 When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 826 message into its local namespace database, the requesting ENRP 827 server shall handle each PE by the following steps: 829 1) If the named pool does not exist in the local namespace, the 830 ENRP server will creates a new pool with that name in the 831 namespace and add the PE to the pool as the first PE; 832 2) If the named pool already exists in the local namespace, but 833 the PE is not currently a member of the pool, ENRP server shall 834 add the PE as a new member to the pool; 836 3) If the named pool already exists in the local namespace AND 837 the requesting PE is already a member of the pool, the ENRP 838 server may skip this PE. 840 4.1.7 Server Monitor Peer Status 842 An ENRP server shall keep a record on the status of each of its 843 known peers. This record is referred to as the "Peer list" of the 844 server. 846 An interanl variable is kept for each peer on 847 the peer list and its value updated to the current local time each 848 time a message of any type is received from the peer. 850 If a message of any type is received from a peer previously 851 unknown, the ENRP server shall create a record for the new peer 852 and add it to the peer list. 854 4.1.8 Server Download Peer List from a Peer Server 856 This operation allows an ENRP server to request from a peer server 857 a copy of its peer list. This is useful for a new ENRP server to 858 initiate its own peer list at startup. 860 An ENRP server shall send a PEER_LIST_REQUEST message to a peer to 861 request a copy of the peer list. 863 Upon the reception of this message, the peer server shall reply 864 with a PEER_LIST_RESPONSE message and include in the message body 865 a list of server IDs of all known peers. 867 If the peer itself is in the process of startup and not ready to 868 provide a good peer list, it shall response with a 869 PEER_LIST_RESPONSE message but set the R flag in the message to 870 '1' to indicate that it can not grant the PEER_LIST_REQUEST. In 871 such a case, the requesting ENRP server shall select another peer 872 and repeat the peer list request with the new peer at a later 873 time. 875 4.1.9 Server Initialization 877 This section describes the steps a new ENRP server needs to take in 878 order to join the other existing ENRP servers for providing the 879 namespace service in the operation scope, or initiating the 880 namespace service if this is the first ENRP server starting in the 881 operation scope. 883 1) At startup, before getting into service, the ENRP server 884 (initiating server) shall multicast a PEER_PRESENCE message with 885 'Reply_required' flag set over the ENRP server channel. This is to 886 inform any other existing peers in the operation scope about the 887 initiating peer's presence. 889 2) Upon the reception of this message, a peer shall send a 890 PEER_PRESENCE without 'Reply_required' flag back to the initiating 891 server, in order to help the initiating server to build a peer list. 893 3) If no response to its PEER_PRESENCE message are received after 894 seconds, the initiating server shall assume 895 that it is alone in the operation scope and shall mark the 896 initialization process as completed. The initiation server shall 897 skip the remaining steps and start to offer the namespace 898 services. 900 4) If there are responses to its PEER_PRESENCE message, the 901 initiating server shall then take the actions described in 4.1.8 to 902 request a peer list from one of the peers that have responded. 904 5) Upon the reception of the PEER_LIST_RESPONSE message from the 905 peer, the initiating server shall use the information carried in the 906 message to build a complete peer list. 908 6) Then, the initiating server shall request to download a copy of 909 the namespace from one of the peer, as described in 4.1.6. 911 At this point, the initialization process is completed and the 912 initiating server shall start to provide namespace services. 914 4.2 Fault Management Operations 916 The following operations are used to detect and recover from 917 various system faults. 919 4.2.1 Detect and Remove an Unreachable PE 921 Whenever a PE finds a peer PE unreachable (e.g., via an SCTP 922 SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the 923 former shall send an ENDPOINT_UNREACHABLE message over the ENRP 924 client channel to its home ENRP server. The message shall contain 925 the pool handle and one of the transport addresses of the 926 unreachable peer PE in a PE parameter. 928 Note: The definition and procedure of ENDPOINT_UNREACHABLE message 929 are part of ASAP and are described in [ASAP]. 931 Upon the reception of the ENDPOINT_UNREACHABLE message, the home 932 ENRP server shall immediately send an ENDPOINT_KEEP_ALIVE message 933 to the PE that is reported as unreachable. If this 934 ENDPOINT_KEEP_ALIVE fails (i.e., it results in an SCTP 935 SEND.FAILURE notification), the ENRP server shall consider the PE 936 as truly unreachable and shall remove the PE from its local copy 937 of the namespace and take actions described in 4.1.5.2. 939 Note: The definition and handling of the ENDPOINT_KEEP_ALIVE 940 message by the PE are part of ASAP and are described in Sections 941 3.2.8? and 4.9.3? in [ASAP]. 943 4.2.2 Server Failure Detection by Heartbeat 945 An ENRP server shall multicast, in every 946 seconds, a PEER_PRESENCE message over the ENRP server channel to 947 inform its peers that it is still operational. In the multicasted 948 PEER_PRESENCE message, the sending ENRP server shall set the 949 'Replay_required' flag to '0' indicating that no response is 950 required. 952 An ENRP server shall keep track the time when the last message 953 (multicast or point-to-point) was received from each known peer in 954 the internal variable . 956 If a peer has not been heard for more than 957 seconds, the ENRP server shall send a point-to-point PEER_PRESENCE 958 with 'Reply_request' flag set to '1' to that peer. 960 If the send fails or the peer does not reply after 961 seconds, the ENRP server shall consider 962 the peer server dead and shall remove the peer from its peer list. 964 When an ENRP server receives a PEER_PRESENCE message with 965 'Reply_request' flag set to '1', it MUST immediately respond to 966 the sender with its own point-to-point PEER_PRESENCE message 967 without setting the 'Replay_required' flag. 969 4.2.3 PE or PU Discover Home ENRP Server 971 This action is part of ASAP protocol and is defined in [ASAP]. 973 At its startup, or when it fails to send to (i.e., timed-out on a 974 service request) with its current home ENRP server, a PE or PU shall 975 initiate the following procedure to find a new home server. 977 In the home server hunt procedure, the PE or PU shall multicast a 978 SERVER_HUNT message over the ENRP client channel, and shall repeat 979 sending this message every seconds until a 980 SERVER_HUNT_RESPONSE message is received from an ENRP server. 982 Then the PE or PU shall pick one of the ENRP servers that have 983 responded as its new home ENRP server, and send all its subsequent 984 the namespace service requests to this new home server. 986 Upon the reception of the SERVER_HUNT message, an ENRP server shall 987 reply to the PE with a SERVER_HUNT_RESPONSE message. 989 5. Variables and Time Constants 991 5.1 Variables 993 - the local time that a peer server was last 994 heard (via receiving either a multicast or 995 point-to-point message from the peer). 997 5.2 Timer Constants 999 - the period for an ENRP server to send out a 1000 heartheat message to its known peers. 1001 (Default=30 secs.) 1003 - pre-set threshold for how long an ENRP 1004 server will wait before considering a 1005 silent peer server potentially dead. 1006 (Default=61 secs.) 1008 - pre-set threshold for how long a message 1009 sender will wait for a response after 1010 sending out a message. (Default=5 secs.) 1012 - pre-set threshold for how long a sender 1013 will wait before sending another 1014 SERVER_HUNT message out. (Default=5 secs.) 1016 6. Security COnsiderations 1018 Due to varying requirements and multiple use cases of Rserpool, we 1019 point out two basic security protocols, IPsec and TLS. We 1020 specifically do not discuss whether one security protocol would be 1021 preferred over the other. This choice will be made by designers 1022 and network architects based on system requirements. 1024 For networks that demand IPsec security, implementations MUST 1025 support [SCTPIPSEC] which describes IPsec-SCTP. IPsec is two 1026 layers below RSerPool. Therefore, if IPsec is used for securing 1027 Rserpool, no changes or special considerations need to be made to 1028 Rserpool to secure the protocol. 1030 For networks that cannot or do not wish to use IPsec and prefer 1031 instead TLS, implementations MUST support TLS with SCTP as 1032 described in [SCTPTLS] or TLS over TCP as described in [RFC2246]. 1033 When using TLS/SCTP we must ensure that RSerPool does not use any 1034 features of SCTP that are not available to an TLS/SCTP user. This 1035 is not a difficult technical problem, but simply a 1036 requirement. When describing an API of the RSerPool lower layer we 1037 have also to take into account the differences between TLS and 1038 SCTP. This is also not difficult, but it is in contrast to the 1039 IPsec solution which is transparently layered below Rserpool. 1041 Support for security is required for the ENRP server and the PEs. 1042 Security support for the Rserpool end user is optional. Note that 1043 the end user implementation contains a piece of the Rserpool 1044 protocol -- namely ASAP -- whereby the pool handle is passed for 1045 name resolution to the ENRP server and IP address(es) are 1046 returned. 1048 The argument for optional end user security is as follows: If the 1049 user doesn't require security protection for example, against 1050 eavesdropping for the request for pool handle resolution and 1051 response, then they are free to make that choice. However, if the 1052 end user does require security, they are guaranteed to get it due 1053 to the requirement for security support for the ENRP server. It is 1054 also possible for the ENRP server to reject an unsecured request 1055 from the user due to its security policy in the case that it 1056 requires enforcement of strong security. But this will be 1057 determined by the security requirements of the individual network 1058 design. 1060 7. References 1062 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1063 3", BCP 9, RFC 2026, October 1996. 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, March 1997. 1068 [ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol 1069 (ASAP)", , work in progress. 1071 [RSERPOOL1] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, 1072 L. Ong, J. Loughney, M. Stillman: "Requirements for Reliable Server 1073 Pooling," , work in progress. 1075 [RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, 1076 L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server 1077 Pooling," , work in progress. 1079 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 1080 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, 1081 V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October 1082 2000. 1084 [SCTPTLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP", 1085 draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress. 1087 [SCTPIPSEC] S.M. Bellovin, J. Ioannidis, A.D. Keromytis, 1088 R.R. Stewart, "On the Use of SCTP with IPsec", 1089 draft-ietf-ipsec-sctp-03.txt, work in progress. 1091 [RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0", 1092 RFC 2246, January 1999. 1094 8. Acknowledgements 1096 The authors wish to thank John Loughney, Lyndon Ong, and many 1097 others for their invaluable comments. 1099 9. Authors' Addresses 1101 Qiaobing Xie Phone: +1-847-632-3028 1102 Motorola, Inc. EMail: qxie1@email.mot.com 1103 1501 W. Shure Drive, 2-F9 1104 Arlington Heights, IL 60004 1105 USA 1107 Randall R. Stewart Phone: +1-815-477-2127 1108 24 Burning Bush Trail. EMail: rrs@cisco.com 1109 Crystal Lake, IL 60012 1110 USA 1112 Maureen Stillman Phone: +1 607 273 0724 62 1113 Nokia EMail: maureen.stillman@nokia.com 1114 127 W. State Street 1115 Ithaca, NY 14850 1116 USA 1118 Expires in six months from Mar. 2002