idnits 2.17.1 draft-ietf-rserpool-enrp-01.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 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 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 53 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'TBD' is mentioned on line 1016, but not defined == Unused Reference: 'RFC2026' is defined on line 1020, 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) Summary: 9 errors (**), 0 flaws (~~), 4 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 7 Expires in six months Nov. 20, 2001 9 Endpoint Name Resolution Protocol (ENRP) 10 12 Status of This Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Abstract 28 Endpoint Name Resolution Protocol (ENRP) is designed to work in 29 conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP] 30 to accomplish the functionality of the Reliable Server Pooling 31 (Rserpool) requirements and architecture as defined in [RSERPOOL1] 32 and [RSERPOOL2]. 34 Within the operational scope of Rserpool, ENRP defines the 35 procedures and message formats of a distributed fault-tolerant 36 registry service for storing, bookkeeping, retrieving, and 37 distributing pool operation and membership information. 39 Table Of Contents 41 1. Introduction...............................................2 42 1.2 Definitions............................................2 43 2. Conventions................................................3 44 3. Message Definitions........................................4 45 3.1 ENRP Parameter Formats.................................4 46 3.1.1 IPv4 Address Parameter...........................5 47 3.1.2 IPv6 Address Parameter ..........................5 48 3.1.3 Pool Element Parameter...........................6 49 3.1.4 Pool Handle Parameter............................6 50 3.1.5 Authorization Parameter..........................7 51 3.1.6 Name Server Identifier Parameter.................7 52 3.2 ENRP Message Formats..................................7 53 3.2.1 PEER_PRESENCE message...........................8 54 3.2.2 PEER_NAME_TABLE_REQUEST message.................9 55 3.2.3 PEER_NAME_TABLE_RESPONSE message................9 56 3.2.4 PEER_NAME_UPDATE message........................10 57 3.2.5 PEER_LIST_REQUEST message.......................11 58 3.2.6 PEER_LIST_RESPONSE message......................11 59 4. ENRP Operation Procedures..................................12 60 4.1 Basic ENRP Operations..................................12 61 4.1.1 PE Registration..................................12 62 4.1.2 PE De-registration...............................13 63 4.1.3 PE Re-registration...............................13 64 4.1.4 Name Translation.................................14 65 4.1.5 Server Namespace Update..........................15 66 4.1.5.1 Add/Update a PE..........................15 67 4.1.5.2 Remove a PE..............................15 68 4.1.6 Server Download Namespace from a Peer Server.....16 69 4.1.7 Server Monitor Peer Status.......................17 70 4.1.8 Server Download Peer List from a Peer Server.....17 71 4.1.9 Server Initialization............................17 72 4.2 Fault Management Operations............................18 73 4.2.1 Detect and Remove an Unreachable PE..............18 74 4.2.2 Server Failure Detection by Heartbeat............19 75 4.2.3 PE or PU Discover Home ENRP Server...............19 76 5. Variables and Timer Constants..............................20 77 5.1 Variables..............................................20 78 5.2 Timer Constants........................................20 79 6. Security COnsiderations....................................20 80 7. References.................................................20 81 8. Acknowledgements...........................................21 82 9. Authors' Addresses.........................................21 84 1. Introduction 86 Endpoint Name Resolution Protocol (ENRP) is designed to work in 87 conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP] 88 to accomplish the functionality of the Reliable Server Pooling 89 (Rserpool) requirements and architecture as defined in [RSERPOOL1] 90 and [RSERPOOL2]. 92 Within the operation scope of Rserpool, ENRP defines the procedures 93 and message formats of a distributed fault-tolerant registry service 94 for storing, bookkeeping, retrieving, and distributing pool 95 operation and membership information. 97 Whenever appropriate, in the rest of this document we will refer to 98 this Rserpool registry service as ENRP namespace, or simply 99 namespace. 101 1.2 Definitions 102 This document uses the following terms: 104 Operation scope: 105 The part of the network visible to pool users by a specific 106 instance of the reliable server pooling protocols. 108 Pool (or server pool): 109 A collection of servers providing the same application 110 functionality. 112 Pool handle (or pool name): 113 A logical pointer to a pool. Each server pool will be 114 identifiable in the operation scope of the system by a unique 115 pool handle or "name". 117 ENRP namespace (or namespace): 118 A cohesive structure of pool names and relations that may be 119 queried by an internal or external agent. 121 Pool element (PE): 122 A server entity that runs ASAP and has registered to a pool. 124 Pool user (PU): 125 A server pool user that runs ASAP. Note, a PU can also be a 126 PE if it has registered itself to a pool. 128 ENRP namespace server (or ENRP server): 129 Entity which runs ENRP and is responsible for managing and 130 maintaining the namespace within the operation scope. 132 ENRP client channel: 133 The communication channel through which a PE requests for 134 ENRP namespace service. The ENRP client channel is usually 135 defined by the transport address of the home ENRP server and 136 a well known port number. 138 ENRP server channel: 139 Defined by a well known multicast IP address and a well 140 known port number. All ENRP servers in an operation scope 141 can send multicast messages to other servers through this 142 channel. PEs are also allowed to multicast on this channel 143 occasionally. 145 Network Byte Order: 146 Most significant byte first, a.k.a Big Endian. 148 2. Conventions 150 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 151 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 152 they appear in this document, are to be interpreted as described in 153 [RFC2119]. 155 3. Message Definitions 157 All messages as well as their fields described below shall be in 158 Network Byte Order during transmission. For fields with a length 159 bigger than 4 octets, a number in a pair of parentheses may follow 160 the filed name to indicate the length of the field in number of 161 octets. 163 3.1 ENRP Parameter Formats 165 ENRP parameters are defined in a Type-length-value (TLV) format as 166 shown below. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Parameter Type | Parameter Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 : : 174 : Parameter Value : 175 : : 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Parameter Type: 16 bits (unsigned integer) 180 The Type field is a 16 bit identifier of the type of parameter. 181 It takes a value of 0 to 65534. 183 The value of 65535 is reserved for IETF-defined extensions. Values 184 other than those defined in specific SCTP chunk description are 185 reserved for use by IETF. 187 Parameter Length: 16 bits (unsigned integer) 189 The Parameter Length field contains the size of the parameter in 190 bytes, including the Parameter Type, Parameter Length, and 191 Parameter Value fields. Thus, a parameter with a zero-length 192 Parameter Value field would have a Length field of 4. The 193 Parameter Length does not include any padding bytes. 195 Parameter Value: variable-length. 197 The Parameter Value field contains the actual information to be 198 transferred in the parameter. 200 The total length of a parameter (including Type, Parameter Length and 201 Value fields) MUST be a multiple of 4 bytes. If the length of the 202 parameter is not a multiple of 4 bytes, the sender pads the Parameter 203 at the end (i.e., after the Parameter Value field) with all zero 204 bytes. The length of the padding is not included in the parameter 205 length field. A sender SHOULD NOT pad with more than 3 bytes. The 206 receiver MUST ignore the padding bytes. 208 The Parameter Types are encoded such that the highest-order two bits 209 specify the action that must be taken if the processing endpoint does 210 not recognize the Parameter Type. 212 00 - Stop processing this ENRP message and discard it, do not process 213 any further parameters within it. 215 01 - Stop processing this ENRP message and discard it, do not process 216 any further parameters within it, and report the unrecognized 217 parameter in an 'Unrecognized Parameter Type' error. 219 10 - Skip this parameter and continue processing. 221 11 - Skip this parameter and continue processing but report the 222 unrecognized parameter in an 'Unrecognized Parameter Type' 223 error. 225 In the following sections, we define the common parameter formats 226 used in ENRP. 228 3.1.1 IPv4 Address Parameter 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type = 0x1 | Length = 8 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | IPv4 Address | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 IPv4 Address: 32 bits (unsigned integer) 240 Contains an IPv4 address of the sending endpoint. It is binary 241 encoded. 243 3.1.2 IPv6 Address Parameter 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type = 0x2 | Length = 20 | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 | IPv6 Address | 252 | | 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 IPv6 Address: 128 bit (unsigned integer) 257 Contains an IPv6 address of the sending endpoint. It is binary 258 encoded. 260 3.1.3 Pool Element Parameter 262 This parameter is used in multiple ENRP message to represent an ASAP 263 endpoint (i.e., a PE in a pool) and the associated information, such 264 as its transport address(es), load control, and other operational 265 status information of the PE. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type = 0x3 | Length=variable | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | SCTP Port | Number of IP addrs=k | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 : IP addr param #0 : 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 : IP addr param #1 : 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 : : 279 : ..... : 280 : : 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 : IP addr param #k : 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Load Policy Type | Policy Value | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Registration Life | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Each of the IP address parameters in a PE parameter can be either 290 an IPv4 or IPv6 address parameter. 292 3.1.4 Pool Handle Parameter 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type = 0x4 | Length=variable | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 : : 300 : Pool Handle : 301 : : 302 : : 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 This parameter holds a pool handle (i.e., a pool name), defined as 306 a NULL terminated ASCII string. 308 3.1.5 Authorization Parameter 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Type = 0x5 | Length=variable | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 : : 316 : Authorization Signature : 317 : : 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 This parameter is used to hold an authorization signature. The 321 signature is signed over the entire ASAP message and uses a 322 preconfigured public/private key pair. The receiver of a message 323 which includes this parameter can validate the message is 324 from the sender by comparing the signature to one generated 325 using the peers public key. 327 3.1.6 Name Server Identifier Parameter 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type = 0x7 | Length=variable | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Name Server SCTP Port | (reserved) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 : IPv4 or IPv6 Addr Param : 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 When a name server is multi-homed, any one of its IP addresses can 340 be used in its Server Identifier Parameter. This is because the 341 combination of any one of its IP addresses and its SCTP port 342 number always uniquely identifies the server. 344 3.2 ENRP Message Formats 346 The figure below illustrates the common format for all ENRP 347 messages. Each message is formatted with a Message 348 Type field, a message-specific Flag field, a Message Length field, and a 349 Value field. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Message Type | Msg Flags | Message Length | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 : : 357 : Message Value : 358 : : 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Message Type: 8 bits (unsigned integer) 363 This field identifies the type of information contained in the 364 Message Value field. It takes a value from 0 to 254. The value 365 of 255 is reserved for future use as an extension field. 367 Message Types are encoded such that the highest-order two bits 368 specify the action that must be taken if the message receiver 369 does not recognize the Message Type. 371 00 - Stop processing this message and discard it. 373 01 - Stop processing this message and discard it, and report the 374 unrecognized message in an 'Unrecognized Parameter Type' 375 error. 377 10 - reserved. 379 11 - reserved. 381 Message Flags: 8 bits 383 The usage of these bits depends on the message type as given by 384 the Message Type. Unless otherwise specified, they are set to 385 zero on transmit and are ignored on receipt. 387 Message Length: 16 bits (unsigned integer) 389 This value represents the size of the message in bytes including 390 the Message Type, Message Flags, Message Length, and Message 391 Value fields. Therefore, if the Message Value field is 392 zero-length, the Length field will be set to 4. The Message 393 Length field does not count any padding. 395 Message Value: variable length 397 The Message Value field contains the actual information to be 398 transferred in the message. The usage and format of this field 399 is dependent on the Message Type. 401 The total length of a message (including Type, Length and Value 402 fields) MUST be a multiple of 4 bytes. If the length of the 403 message is not a multiple of 4 bytes, the sender MUST pad the 404 message with all zero bytes and this padding is not included in the 405 message length field. The sender should never pad with more than 3 406 bytes. The receiver MUST ignore the padding bytes. 408 3.2.1 PEER_PRESENCE message 410 0 1 2 3 411 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 : Sender's Server ID param : 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 : Receiver's Server ID param (optional) : 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 : Authorization Parameter (optional) : 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 The receiving server's ID does not need to be included if the 424 message is being multicasted. 426 "Reply_required" (R) flag shall be set to '1' if response to this 427 message is required, otherwise set to '0'. 429 3.2.2 PEER_NAME_TABLE_REQUEST message 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type = 0x2 |0|0|0|0|0|0|0|0| Message Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 : Sender's Server ID param : 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 : Receiver's Server ID param (optional) : 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 : Authorization Parameter (optional) : 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 The receiving server's ID does not need to be included if the 444 message is being multicasted. 446 (Editor's note: we may not support multicast of this message). 448 3.2.3 PEER_NAME_TABLE_RESPONSE message 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type = 0x3 |0|0|0|0|0|0|0|M| Message Length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 : Sender's Server ID param : 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 : Receiver's Server ID parameter : 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 : : 460 : Pool entry #1 (see below) : 461 : : 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 : : 464 : ... : 466 : : 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 : : 469 : Pool entry #n (see below) : 470 : : 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 : Authorization Parameter (optional) : 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 "More_to_send" (M) flag: 477 shall be set to '1' if there are more pool entries to be sent 478 in subsequent PEER_NAME_TABLE_RESPONSE messages. Otherwise, it 479 shall be set to '0'. 481 Pool entries: 483 At least one pool entry MUST be present in the message. Each 484 pool entry MUST start with a pool handle parameter, followed by 485 one or more pool element (PE) parameters, i.e.: 487 +---------------------------+ 488 : Pool handle : 489 +---------------------------+ 490 : PE #1 : 491 +---------------------------+ 492 : PE #2 : 493 +---------------------------+ 494 : ... : 495 +---------------------------+ 496 : PE #n : 497 +---------------------------+ 499 3.2.4 PEER_NAME_UPDATE message 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 : Sender's Server ID param : 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 : Receiver's Server ID param (optional) : 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 : : 511 : Pool handle : 512 : : 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 : : 515 : Pool Element : 516 : : 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Update action | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 : Authorization Parameter (optional) : 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 The receiving server's ID does not need to be included if the 524 message is being multicasted. 526 "Update_action" field: 528 shall take one of the following values: 530 0x0 - ADD_PE: add the PE as a new member to or update the PE in 531 the named pool in the namespace. 532 0x1 - DELETE_PE: delete the specified PE from the namespace. 534 3.2.5 PEER_LIST_REQUEST message 536 0 1 2 3 537 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 : Sender's Server ID param : 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 : Receiver's Server ID param (optional) : 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 : Authorization Parameter (optional) : 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 The receiving server's ID does not need to be included if the 549 message is being multicasted. 551 3.2.6 PEER_LIST_RESPONSE message 553 This message shall contain all the peer information of the sending 554 server. 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 : Sender's Server ID param : 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 : Receiver's Server ID parameter : 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 : ID of Peer Server #1 : 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 : ... : 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 : ID of Peer Server #n : 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 : Authorization Parameter (optional) : 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 "Reject" (R) flag: 576 shall be set to '1' if the sender of this message is rejecting 577 a peer list request. In such a case, this message MUST be sent 578 with no peer server ID included. 580 4. ENRP Operation Procedures 582 In this section, we discuss the procedures defined by ENRP. The 583 procedures are divided into two groups, namely the basic ENRP 584 operations and fault management procedures. 586 Many of the Rserpool events call for message exchange and other 587 activities between both a PE and an ENRP server and the ENRP server 588 and its peers. But only the message exchange and activities between 589 the ENRP server and its peers are considered within the ENRP 590 protocol definition scope 592 Procedures and message formats for communications between the PE 593 and ENRP servers are defined in [ASAP]. However, in order to put 594 our discussion in context, we will give brief description of the 595 ASAP activities whenever appropreate. 597 4.1 Basic ENRP Operations 599 4.1.1 PE Registration 601 ENRP server <-> PE: 603 This action is part of the ASAP protocol and is defined in [ASAP]. 605 To register itself with the name space, a PE sends a REGISTRATION 606 message over the ENRP client channel to its home ENRP server. 608 In the REGISTRATION message, the PE indicates the name of the pool 609 it wishes to join in a pool handle parameter, and its port number 610 and network access address(es) and any load control information in 611 a PE parameter. 613 The ENRP server handles the REGISTRATION message according to the 614 following rules: 616 1) If the named pool does not exist in the namespace, the ENRP 617 server will creates a new pool with that name in the namespace and 618 add the PE to the pool as its first PE; 620 2) If the named pool already exists in the namespace, but the 621 requesting PE is not currently a member of the pool, ENRP server 622 will add the PE as a new member to the pool; 623 3) If the named pool already exists in the namespace AND the 624 requesting PE is already a member of the pool, the ENRP server 625 shall consider this as a re-registration case. The ENRP Server 626 shall replace the attributes of the existing PE with the 627 information carried in the received REGISTRATION message. 629 4) The ENRP server may reject the registration due to reasons such 630 as invalid values, lack of resource, etc. 632 In all cases, the ENRP server will reply to the requesting PE with 633 a REGISTRATION_RESPONSE message, and will indicate in the message 634 body whether the registration is granted or rejected. 636 ENRP server <-> Its peers: 638 If the registration request is granted (i.e., cases 1-3 above), 639 the ENRP server MUST take the namespace modification action as 640 described in section 4.1.5.1?. Otherwise, no message shall be 641 exchanged with its peers. 643 4.1.2 PE De-registration 645 ENRP server <-> PE: 647 This action is part of the ASAP protocol and is defined in [ASAP]. 649 To remove itself from a pool, a PE sends a DEREGISTRATION message 650 over the ENRP client channel to its home ENRP server. 652 In response, the home ENRP server sends a REGISTRATION_RESPONSE 653 message to the PE and indicates in the message body whether the 654 request is granted or rejected. 656 If the PE is the last one of the named pool, the home ENRP server 657 will remove the pool from the namespace as well. 659 The ENRP server may reject the de-registration request due to 660 reasons such as invalid parameters, etc. 662 It should be noted that de-registration does not stop the PE from 663 sending or receiving application messages. 665 ENRP server <-> peers: 667 Once the de-registration request is granted and the PE removed from 668 its local copy of the namespace, the home ENRP server MUST take the 669 namespace modification action described in Section 4.1.5.2. 671 4.1.3 PE Re-registration 673 A PE may re-register itself to the namespace with a new set of 674 attributtes in order to, for example, extend its registration 675 life, change its load policy value. 677 However, an existing PE MUST NOT change its access address list 678 via re-registration. Instead, to change its address list a PE 679 shall de-register itself first and then register with the 680 namespace as a new PE. 682 A PE can modify its load policy value at any time via 683 re-registration. Based on the number of PEs in the pool and the 684 pool's load distrbution policy, this operation allows the PE to 685 dynamically control its share of inbound messages received by the 686 pool (also see Section 4.5.2 in [ASAP] for more on load control). 688 ENRP server <-> PE: 690 This action is part of the ASAP protocol and is defined in [ASAP]. 692 To perform a re-registration, a registered PE shall simply send 693 a new REGISTRATION message with a new set of attributes over the 694 ENRP client channel to its home ENRP server. 696 Upon the reception of this REGISTRATION message, the home ENRP 697 server shall follow the same procedures described in Section 698 4.1.1. 700 ENRP server <-> peers: 702 If the REGISTRATION message is accepted, the home ENRP server 703 shall take the action described in Section 4.1.5.1?. Otherwise, no 704 message shall be exchanged with its peers. 706 4.1.4 Name Translation 708 ENRP server <-> PE or PU: 710 This action is part of the ASAP protocol and is defined in [ASAP]. 712 A PE or PU can use the name translation service provided by the ENRP 713 server to resolve a pool name to a list of accessible transport 714 addresses of existing PEs. 716 This requires the PE or PU to send a NAME_RESOLUTION messages to its 717 home ENRP server and in the NAME_RESOLUTION message specify the pool 718 name to be translated in a Pool Handle parameter. 720 If the named pool exits in the namespace, the home ENRP server will 721 send back a NAME_RESOLUTION_RESPONSE message that shall carry a 722 list of PE parameters containing all information of the PEs 723 currently registered under that pool name. This information may 724 include the current load control policy of the pool, policy value 725 of each PE, transport address(es) for each PE, etc. 727 Otherwise, the ENRP server shall respond with a NAME_UNKNOWN 728 message. 730 ENRP server <-> peers: 732 None. 734 4.1.5 Server Namespace Update 736 This includes a set of update operations used by an ENRP server to 737 inform its peer(s) about the addition of a new PE, removal of an 738 existing PE, or change of pool or PE properties. 740 4.1.5.1 Add/Update a PE 742 When a new PE is granted registration to the namespace or an 743 existing PE is granted a re-registration, the home ENRP server 744 uses this procedure to inform all its peers. 746 An ENRP server shall multicast over the ENRP server channel a 747 PEER_NAME_UPDATE message with the Update_action field set to 748 ADD_PE, indicating the addition of the new PE or the update of an 749 existing PE to the namespace. The PE and the pool its belongs to 750 shall be indicated in the message with a PE parameter and a Pool 751 Handle parameter, respectively (see Section 3.2.4). 753 Upon the reception of this PEER_NAME_UPDATE message, each of the 754 peer ENRP servers shall take the following actions: 756 1) If the named pool under which the PE has been registered (or 757 re-registered) does not exist in the peer's local copy of the 758 namespace, the peer ENRP server shall create the named pool in its 759 local namespace copy and add the PE to it as the first PE. It then 760 shall copy in all other attributes of the PE carried in the 761 message. 763 2) If the named pool already exists in the peer's local copy of the 764 namespace AND the PE does not exist, the peer shall add the PE to 765 the pool as a new PE and copy in all attributes of the PE carried 766 in the message. 768 3) If the named pool exists AND the PE is already a member of the 769 pool in its the local copy of the namespace, the peer ENRP server 770 shall replace the attributes of the PE with the new information 771 carried in the message. 773 4.1.5.2 Remove a PE 775 This procedure is used by an ENRP server to inform its peer(s) to 776 remove an existing PE. 778 An ENRP server shall multicast over the ENRP server channel a 779 PEER_NAME_UPDATE message with the Update_action field set to 780 DELETE_PE, indicating the removal of an existing PE from the 781 namespace. The PE and the pool its belongs to shall be indicated 782 in the message with a PE parameter and a Pool Handle parameter, 783 respectively. 785 On the reception of this PEER_NAME_UPDATE message, each peer ENRP 786 server shall find and remove the PE from its local copy of the 787 namespace. If the peer does not find the PE in its local copy of 788 the namespace, it SHOULD take no action. 790 4.1.6 Server Download Namespace from a Peer Server 792 This operation allows an ENRP server to request and receive a copy 793 of the current namespace from one of its peer ENRP servers. 795 This operation is especially useful for a newly started ENRP server 796 to initiate its local copy of the namespace, as well as for an 797 existing ENRP server to correct namespace inconsistency found during 798 its operation. 800 1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message 801 directly to one of its peers. 803 2) Upon the reception of this message, the peer server shall 804 initiate a download session in which the namespace shall be sent 805 to the requesting ENRP server in one or more 806 PEER_NAME_TABLE_RESPONSE messages. 808 If the sending ENRP server determines that multiple 809 PEER_NAME_TABLE_RESPONSE messages are needed for the session, it 810 shall use the M flag in each PEER_NAME_TABLE_RESPONSE message to 811 inform the receiving ENRP server whether or not the data 812 in this message is the last piece of the namespace transfer. 814 3) During the downloading, every time the requesting ENRP server 815 receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer the 816 data entries carried in the message into its local namespace 817 database, and then check whether or not the data in this message is 818 the last piece being transfered. If more data transfer is indicated, 819 the requesting ENRP server shall send another 820 PEER_NAME_TABLE_REQUEST message to the same peer to request for the 821 next piece whenever it is ready. 823 When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 824 message into its local namespace database, the requesting ENRP 825 server shall handle each PE by the following steps: 827 1) If the named pool does not exist in the local namespace, the 828 ENRP server will creates a new pool with that name in the 829 namespace and add the PE to the pool as the first PE; 830 2) If the named pool already exists in the local namespace, but 831 the PE is not currently a member of the pool, ENRP server shall 832 add the PE as a new member to the pool; 834 3) If the named pool already exists in the local namespace AND 835 the requesting PE is already a member of the pool, the ENRP 836 server may skip this PE. 838 4.1.7 Server Monitor Peer Status 840 An ENRP server shall keep a record on the status of each of its 841 known peers. This record is referred to as the "Peer list" of the 842 server. 844 An interanl variable is kept for each peer on 845 the peer list and its value updated to the current local time each 846 time a message of any type is received from the peer. 848 If a message of any type is received from a peer previously 849 unknown, the ENRP server shall create a record for the new peer 850 and add it to the peer list. 852 4.1.8 Server Download Peer List from a Peer Server 854 This operation allows an ENRP server to request from a peer server 855 a copy of its peer list. This is useful for a new ENRP server to 856 initiate its own peer list at startup. 858 An ENRP server shall send a PEER_LIST_REQUEST message to a peer to 859 request a copy of the peer list. 861 Upon the reception of this message, the peer server shall reply 862 with a PEER_LIST_RESPONSE message and include in the message body 863 a list of server IDs of all known peers. 865 If the peer itself is in the process of startup and not ready to 866 provide a good peer list, it shall response with a 867 PEER_LIST_RESPONSE message but set the R flag in the message to 868 '1' to indicate that it can not grant the PEER_LIST_REQUEST. In 869 such a case, the requesting ENRP server shall select another peer 870 and repeat the peer list request with the new peer at a later 871 time. 873 4.1.9 Server Initialization 875 This section describes the steps a new ENRP server needs to take in 876 order to join the other existing ENRP servers for providing the 877 namespace service in the operation scope, or initiating the 878 namespace service if this is the first ENRP server starting in the 879 operation scope. 881 1) At startup, before getting into service, the ENRP server 882 (initiating server) shall multicast a PEER_PRESENCE message with 883 'Reply_required' flag set over the ENRP server channel. This is to 884 inform any other existing peers in the operation scope about the 885 initiating peer's presence. 887 2) Upon the reception of this message, a peer shall send a 888 PEER_PRESENCE without 'Reply_required' flag back to the initiating 889 server, in order to help the initiating server to build a peer list. 891 3) If no response to its PEER_PRESENCE message are received after 892 seconds, the initiating server shall assume 893 that it is alone in the operation scope and shall mark the 894 initialization process as completed. The initiation server shall 895 skip the remaining steps and start to offer the namespace 896 services. 898 4) If there are responses to its PEER_PRESENCE message, the 899 initiating server shall then take the actions described in 4.1.8 to 900 request a peer list from one of the peers that have responded. 902 5) Upon the reception of the PEER_LIST_RESPONSE message from the 903 peer, the initiating server shall use the information carried in the 904 message to build a complete peer list. 906 6) Then, the initiating server shall request to download a copy of 907 the namespace from one of the peer, as described in 4.1.6. 909 At this point, the initialization process is completed and the 910 initiating server shall start to provide namespace services. 912 4.2 Fault Management Operations 914 The following operations are used to detect and recover from 915 various system faults. 917 4.2.1 Detect and Remove an Unreachable PE 919 Whenever a PE finds a peer PE unreachable (e.g., via an SCTP 920 SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the 921 former shall send an ENDPOINT_UNREACHABLE message over the ENRP 922 client channel to its home ENRP server. The message shall contain 923 the pool handle and one of the transport addresses of the 924 unreachable peer PE in a PE parameter. 926 Note: The definition and procedure of ENDPOINT_UNREACHABLE message 927 are part of ASAP and are described in [ASAP]. 929 Upon the reception of the ENDPOINT_UNREACHABLE message, the home 930 ENRP server shall immediately send an ENDPOINT_KEEP_ALIVE message 931 to the PE that is reported as unreachable. If this 932 ENDPOINT_KEEP_ALIVE fails (i.e., it results in an SCTP 933 SEND.FAILURE notification), the ENRP server shall consider the PE 934 as truly unreachable and shall remove the PE from its local copy 935 of the namespace and take actions described in 4.1.5.2. 937 Note: The definition and handling of the ENDPOINT_KEEP_ALIVE 938 message by the PE are part of ASAP and are described in Sections 939 3.2.8? and 4.9.3? in [ASAP]. 941 4.2.2 Server Failure Detection by Heartbeat 943 An ENRP server shall multicast, in every 944 seconds, a PEER_PRESENCE message over the ENRP server channel to 945 inform its peers that it is still operational. In the multicasted 946 PEER_PRESENCE message, the sending ENRP server shall set the 947 'Replay_required' flag to '0' indicating that no response is 948 required. 950 An ENRP server shall keep track the time when the last message 951 (multicast or point-to-point) was received from each known peer in 952 the internal variable . 954 If a peer has not been heard for more than 955 seconds, the ENRP server shall send a point-to-point PEER_PRESENCE 956 with 'Reply_request' flag set to '1' to that peer. 958 If the send fails or the peer does not reply after 959 seconds, the ENRP server shall consider 960 the peer server dead and shall remove the peer from its peer list. 962 When an ENRP server receives a PEER_PRESENCE message with 963 'Reply_request' flag set to '1', it MUST immediately respond to 964 the sender with its own point-to-point PEER_PRESENCE message 965 without setting the 'Replay_required' flag. 967 4.2.3 PE or PU Discover Home ENRP Server 969 This action is part of ASAP protocol and is defined in [ASAP]. 971 At its startup, or when it fails to send to (i.e., timed-out on a 972 service request) with its current home ENRP server, a PE or PU shall 973 initiate the following procedure to find a new home server. 975 In the home server hunt procedure, the PE or PU shall multicast a 976 SERVER_HUNT message over the ENRP client channel, and shall repeat 977 sending this message every seconds until a 978 SERVER_HUNT_RESPONSE message is received from an ENRP server. 980 Then the PE or PU shall pick one of the ENRP servers that have 981 responded as its new home ENRP server, and send all its subsequent 982 the namespace service requests to this new home server. 984 Upon the reception of the SERVER_HUNT message, an ENRP server shall 985 reply to the PE with a SERVER_HUNT_RESPONSE message. 987 5. Variables and Time Constants 989 5.1 Variables 991 - the local time that a peer server was last 992 heard (via receiving either a multicast or 993 point-to-point message from the peer). 995 5.2 Timer Constants 997 - the period for an ENRP server to send out a 998 heartheat message to its known peers. 999 (Default=30 secs.) 1001 - pre-set threshold for how long an ENRP 1002 server will wait before considering a 1003 silent peer server potentially dead. 1004 (Default=61 secs.) 1006 - pre-set threshold for how long a message 1007 sender will wait for a response after 1008 sending out a message. (Default=5 secs.) 1010 - pre-set threshold for how long a sender 1011 will wait before sending another 1012 SERVER_HUNT message out. (Default=5 secs.) 1014 6. Security COnsiderations 1016 [TBD] 1018 7. References 1020 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1021 3", BCP 9, RFC 2026, October 1996. 1023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1024 Requirement Levels", BCP 14, RFC 2119, March 1997. 1026 [ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol 1027 (ASAP)", , work in progress. 1029 [RSERPOOL1] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, 1030 L. Ong, J. Loughney, M. Stillman: "Requirements for Reliable Server 1031 Pooling," , work in progress. 1033 [RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, 1034 L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server 1035 Pooling," , work in progress. 1037 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 1038 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, 1039 V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October 1040 2000. 1042 8. Acknowledgements 1044 The authors wish to thank John Loughney, Lyndon Ong, and Maureen 1045 Stillman and many others for their invaluable comments. 1047 9. Authors' Addresses 1049 Randall R. Stewart 1050 24 Burning Bush Trail. 1051 Crystal Lake, IL 60012 1052 USA 1054 Phone: +1-815-477-2127 1055 EMail: rrs@cisco.com 1057 Qiaobing Xie 1058 Motorola, Inc. 1059 1501 W. Shure Drive, #2309 1060 Arlington Heights, IL 60004 1061 USA 1063 Phone: +1-847-632-3028 1064 EMail: qxie1@email.mot.com 1066 Expires in six months from Nov. 2001