idnits 2.17.1 draft-ietf-rserpool-enrp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 11) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 5 instances of too long lines in the document, the longest one being 1 character 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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (June 1, 2001) is 8365 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 1376, 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: 10 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Q. Xie 2 INTERNET-DRAFT Motorola 3 R. R. Stewart 4 Cisco Systems 6 Expires in six months June 1, 2001 8 Enpoint Name Resolution Protocol (ENRP) 9 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 The list of current Internet-Drafts can be accessed at 20 http://www.ietf.org/ietf/1id-abstracts.txt 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Abstract 27 Endpoint Name Resolution Protocol (ENRP) is designed to work in 28 conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP] 29 to accomplish the functionality of the Reliable Server Pooling 30 (Rserpool) requirements and architecture as defined in [RSERPOOL1] 31 and [RSERPOOL2]. 33 Within the operational scope of Rserpool, ENRP defines the 34 procedures and message formats of a distributed fault-tolerant 35 registry service for storing, bookkeeping, retrieving, and 36 distributing pool operation and membership information. 38 Table Of Contents 40 1. Introduction.................................................. 2 41 1.2 Definitions................................................ 3 42 2. Conventions................................................... 4 43 3. ENRP Message Definitions...................................... 4 44 3.1 PE Parameter Definition.................................... 4 45 3.2 PEER_PRESENCE message...................................... 5 46 3.3 PEER_NAME_TABLE_REQUEST message............................ 5 47 3.4 PEER_NAME_TABLE_RESPONSE message........................... 6 48 3.5 PEER_NAME_UPDATE message................................... 7 49 3.6 PEER_LIST_REQUEST message.................................. 8 50 3.7 PEER_LIST_RESPONSE message................................. 9 51 3.8 TAKEOVER_INITIATE message..................................10 52 3.9 TAKEOVER_INITIATE_RESPONSE message.........................11 53 3.10 TAKEOVER_PEER_SERVER message..............................11 54 3.11 SERVER_DUMP message.......................................12 55 3.12 SERVER_DUMP_RESPONSE message..............................12 56 4. ENRP Operation Procedures.....................................14 57 4.1 Basic ENRP Operations......................................14 58 4.1.1 PE Registration........................................14 59 4.1.2 PE De-registration.....................................15 60 4.1.3 Name Translation.......................................16 61 4.1.4 Server Namespace Update................................16 62 4.1.4.1 Add a New PE.......................................16 63 4.1.4.2 Forceful Removal of a PE...........................17 64 4.1.4.3 Advisory Removal of a PE...........................17 65 4.1.4.4 Update PE Attributes...............................18 66 4.1.4.5 Claim Ownership over a PE..........................18 67 4.1.4.6 Report PE Communication Failure....................18 68 4.1.5 PE Change Policy Value.................................19 69 4.1.6 Server Download Namespace from a Peer Server...........19 70 4.1.7 Server Monitor Peer Status.............................20 71 4.1.8 Server Download Peer List from a Peer Server...........20 72 4.1.9 ENRP Server Initialization.............................21 73 4.2 Fault Management Operations................................21 74 4.2.1 Detect and Report Unreachable PE.......................21 75 4.2.2 ENRP Server Failure Detection by Heartbeat.............22 76 4.2.3 PE Home ENRP Server Hunt...............................23 77 4.2.4 ENRP Server Detecting and Taking-over Inactive Peer ...23 78 4.2.5 Registration of Remote PEs.............................25 79 4.3 Maintenance Operations.....................................25 80 4.3.1 Forceful Removal of a PE...............................25 81 4.3.2 Dump Home PE List......................................25 82 4.3.3 Dump Remote PE List....................................26 83 4.3.4 Dump Peer Server List..................................26 84 5. Variables, Time Constants, and Thresholds....................26 85 5.1 Variables..................................................26 86 5.2 Timer Constants............................................26 87 5.3 Thresholds.................................................27 88 6. References....................................................27 89 7. Acknowledgements..............................................27 90 8. Authors' Addresses...........................................27 92 1. Introduction 94 Endpoint Name Resolution Protocol (ENRP) is designed to work in 95 conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP] 96 to accomplish the functionality of the Reliable Server Pooling 97 (Rserpool) requirements and architecture as defined in [RSERPOOL1] 98 and [RSERPOOL2]. 100 Within the operation scope of Rserpool, ENRP defines the procedures 101 and message formats of a distributed fault-tolerant registry service 102 for storing, bookkeeping, retrieving, and distributing pool 103 operation and membership information. 105 Whenever appropriate, in the rest of this document we will refer to 106 this Rserpool registry service as ENRP namespace, or simply 107 namespace. 109 1.2 Definitions 111 This document uses the following terms: 113 Operation scope: 114 The part of the network visible to pool users by a specific 115 instance of the reliable server pooling protocols. 117 Pool (or server pool): 118 A collection of servers providing the same application 119 functionality. 121 Pool handle (or pool name): 122 A logical pointer to a pool. Each server pool will be 123 identifiable in the operation scope of the system by a unique 124 pool handle or "name". 126 ENRP namespace (or namespace): 127 A cohesive structure of pool names and relations that may be 128 queried by an internal or external agent. 130 Pool element (PE): 131 A server entity that runs ASAP and has registered to a pool. 133 Pool user (PU): 134 A server pool user that runs ASAP. Note, a PU can also be a 135 PE if it has registered itself to a pool. 137 ENRP namespace server (or ENRP server): 138 Entity which runs ENRP and is responsible for managing and 139 maintaining the namespace within the operation scope. 141 ENRP maintenance client (or maintanance client): 142 A special program that runs ASAP and has the additional 143 capability of exchanging ENRP maintenance messages with an 144 ENRP server in order to perform certain maintenance 145 functions. 147 Home ENRP server: 148 The ENRP server to which a PE currently belongs. PEs 149 normally choose the ENRP server on their local host as the 150 home ENRP server, if one exists. A PU shall only have one 151 home ENRP server at any given time, and both the PU and the 152 home ENRP server shall keep track of this master/slave 153 relationship between them. 155 ENRP server takeover: 156 The event that a remote ENRP server takes the ownership of 157 all the PEs on a node and becomes their new home ENRP 158 server. 160 Caretaker ENRP server: 161 The ENRP server on a remote node which takes ownership of 162 all PEs on the local node because of the absence of an 163 active local ENRP server. 165 ENRP client channel: 166 The communication channel through which a PE requests for 167 ENRP namespace service. The ENRP client channel is usually 168 defined by the transport address of the home ENRP server and 169 a well known port number. 171 ENRP server channel: 172 Defined by a well known multicast IP address and a well 173 known port number. All ENRP servers in an operation scope 174 can send multicast messages to other servers through this 175 channel. PEs are also allowed to multicast on this channel 176 occasionally. 178 Network Byte Order: 179 Most significant byte first, a.k.a Big Endian. 181 2. Conventions 183 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 184 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 185 they appear in this document, are to be interpreted as described in 186 [RFC2119]. 188 3. Message Message Definitions 190 All messages as well as their fields described below shall be in 191 Network Byte Order during transmission. For fields with a length 192 bigger than 4 octets, a number in a pair of parentheses may follow 193 the filed name to indicate the length of the field in number of 194 octets. 196 3.1 PE Parameter Definition 198 This parameter is used in multiple ENRP message to represent an ASAP 199 endpoint (i.e., a PE in a pool) and the associated information, such 200 as its transport address(es), load control, and other operational 201 status information of the PE. 203 The parameter is defined to support PEs with up to 8 different IPv4 204 transport addresses. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | IP address #0 | 210 +-------------------------------+-------------------------------+ 211 | IP address #1 | 212 +-------------------------------+-------------------------------+ 213 \ \ \ \ 214 / / / / 215 \ \ \ \ 216 +-------------------------------+-------------------------------+ 217 | IP address #7 | 218 +-------------------------------+-------------------------------+ 219 | SCTP Port | Padding | 220 +-------------------------------+-------------------------------+ 221 | Load sharing policy type | Policy Value | 222 +---------------+---------------+---------------+---------------+ 224 The total size of a PE parameter is 40 octets. 226 3.2 PEER_PRESENCE message 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | ENRP server message identifier #1 = 0x27047729 | 232 +-------------------------------+-------------------------------+ 233 | ENRP server message identifier #2 = 0x53829149 | 234 +-------------------------------+-------------------------------+ 235 | Type = 0x100 | 236 +-------------------------------+-------------------------------+ 237 | sender's IP address | 238 +-------------------------------+-------------------------------+ 239 | sender's SCTP port | padding | 240 +-------------------------------+-------------------------------+ 241 | receiver's IP address | 242 +-------------------------------+-------------------------------+ 243 | receiver's SCTP port | padding | 244 +-------------------------------+-------------------------------+ 245 | Reply required | 246 +-------------------------------+-------------------------------+ 248 The receiving server's IP address and port do not need to be filled 249 in if the message is being multicasted. 251 'Reply_required' flag shall be set to 0x1 if response to this 252 message is required, otherwise set to 0x0. 254 3.3 PEER_NAME_TABLE_REQUEST message 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | ENRP server message identifier #1 = 0x27047729 | 260 +-------------------------------+-------------------------------+ 261 | ENRP server message identifier #2 = 0x53829149 | 262 +-------------------------------+-------------------------------+ 263 | Type = 0x102 | 264 +-------------------------------+-------------------------------+ 265 | sending server's IP address | 266 +-------------------------------+-------------------------------+ 267 | sender's SCTP port | padding | 268 +-------------------------------+-------------------------------+ 269 | receiving server's IP address | 270 +-------------------------------+-------------------------------+ 271 | receiver's SCTP port | padding | 272 +-------------------------------+-------------------------------+ 273 | Table type = (see below) | 274 +-------------------------------+-------------------------------+ 276 Note, the receiver's IP address and port do not need to be filled in 277 if the message is being multicasted. 279 The requested 'Table type' shall take one of the following values: 281 0x1 --- HOME_LIST: PEs owned by the receiver server. 282 0x2 --- REMOTE_LIST: PEs NOT owned by the receiver 283 server. 285 3.4 PEER_NAME_TABLE_RESPONSE message 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | ENRP server message identifier #1 = 0x27047729 | 291 +-------------------------------+-------------------------------+ 292 | ENRP server message identifier #2 = 0x53829149 | 293 +-------------------------------+-------------------------------+ 294 | Type = 0x103 | 295 +-------------------------------+-------------------------------+ 296 | sender's IP address | 297 +-------------------------------+-------------------------------+ 298 | sender's SCTP port | padding | 299 +-------------------------------+-------------------------------+ 300 | receiver's IP address | 301 +-------------------------------+-------------------------------+ 302 | receiver's SCTP port | padding | 303 +-------------------------------+-------------------------------+ 304 | Table type = (see below) | 305 +-------------------------------+-------------------------------+ 306 | More to send = (see below) | 307 +-------------------------------+-------------------------------+ 308 | number of pool names = n | 309 +-------------------------------+-------------------------------+ 310 | | 311 | Pool entry #1 (see below) | 312 | | 313 +-------------------------------+-------------------------------+ 314 / / 315 \ \ 316 / / 317 +-------------------------------+-------------------------------+ 318 | | 319 | Pool entry #n (see below) | 320 | | 321 +-------------------------------+-------------------------------+ 323 Field 'Table type' shall take one of the following values: 325 0x1 --- HOME_LIST: PEs owned by the sending ENRP server. 326 0x2 --- REMOTE_LIST: PEs NOT owned by the sending ENRP 327 server. 329 Field 'More to send' flag shall be set to 0x1 if there are more pool 330 entries to be sent for the requested table type. Otherwise, it shall 331 be set to 0x0. 333 Each 'Pool entry' represents an existing pool and shall consist of 334 the following: 336 +-------------------------------+-------------------------------+ 337 | | 338 | Pool handle name (32) | 339 | | 340 +-------------------------------+-------------------------------+ 341 | number of PEs = m | 342 +-------------------------------+-------------------------------+ 343 | | 344 | PE #1 (40) | 345 | | 346 +-------------------------------+-------------------------------+ 347 / / 348 \ ..... \ 349 / / 350 +-------------------------------+-------------------------------+ 351 | | 352 | PE #m (40) | 353 | | 354 +-------------------------------+-------------------------------+ 356 3.5 PEER_NAME_UPDATE message 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | ENRP server message identifier #1 = 0x27047729 | 362 +-------------------------------+-------------------------------+ 363 | ENRP server message identifier #2 = 0x53829149 | 364 +-------------------------------+-------------------------------+ 365 | Type = 0x104 | 366 +-------------------------------+-------------------------------+ 367 | sender's IP address | 368 +-------------------------------+-------------------------------+ 369 | sender's SCTP port | padding | 370 +-------------------------------+-------------------------------+ 371 | receiver's IP address | 372 +-------------------------------+-------------------------------+ 373 | receiver's SCTP port | padding | 374 +-------------------------------+-------------------------------+ 375 | | 376 | Pool handle name (32) | 377 | | 378 +-------------------------------+-------------------------------+ 379 | | 380 | PE entry (40) | 381 | | 382 +-------------------------------+-------------------------------+ 383 | Update action (see below) | 384 +-------------------------------+-------------------------------+ 386 The receiver's IP address and port do not need to be filled in if 387 the message is being multicasted. 389 Field 'Update action' shall take one of the following values: 391 0x0 --- ADD_ENDPOINT: add the PE as a new member to the named pool 392 in the local copy of the namespace. 393 0x1 --- DELETE_ENDPOINT: delete the specified PE from the local copy 394 of namespace _if_ the receiving server owns the PE. 395 0x2 --- REMOVE_ENDPOINT: remove the specified PE from the local copy 396 of namespace, regardless who owns the PE. 397 0x3 --- UPDATE_ENDPOINT: replace the specified PE's attributes with 398 the new information carried in this message. 399 0x4 --- ENDPOINT_FAILURE: warn the receiver that the specified PE 400 is potentially unreachable. 401 0x5 --- CLAIM_ENDPOINT: inform the receiver that the sender has 402 taken the ownership of the specified PE. 404 3.6 PEER_LIST_REQUEST message 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | ENRP server message identifier #1 = 0x27047729 | 410 +-------------------------------+-------------------------------+ 411 | ENRP server message identifier #2 = 0x53829149 | 412 +-------------------------------+-------------------------------+ 413 | Type = 0x10b | 414 +-------------------------------+-------------------------------+ 415 | sender's IP address | 416 +-------------------------------+-------------------------------+ 417 | sender's SCTP port | padding | 418 +-------------------------------+-------------------------------+ 419 | receiver's IP address | 420 +-------------------------------+-------------------------------+ 421 | receiver's SCTP port | padding | 422 +-------------------------------+-------------------------------+ 424 The receiver's IP address and port do not need to be filled in if 425 the message is being multicasted. 427 3.7 PEER_LIST_RESPONSE message 429 This message shall contain all the peer information of the sending 430 server. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | ENRP server message identifier #1 = 0x27047729 | 436 +-------------------------------+-------------------------------+ 437 | ENRP server message identifier #2 = 0x53829149 | 438 +-------------------------------+-------------------------------+ 439 | Type = 0x10c | 440 +-------------------------------+-------------------------------+ 441 | sender's IP address | 442 +-------------------------------+-------------------------------+ 443 | senders SCTP port | padding | 444 +-------------------------------+-------------------------------+ 445 | receiver's IP address | 446 +-------------------------------+-------------------------------+ 447 | receiver's SCTP port | padding | 448 +-------------------------------+-------------------------------+ 449 | responseIndication (see below) | 450 +-------------------------------+-------------------------------+ 451 | number of peers = n | 452 +-------------------------------+-------------------------------+ 453 | | 454 | Peer entry 1 (see below) | 455 | | 456 +-------------------------------+-------------------------------+ 457 / / 458 \ \ 459 / / 460 +-------------------------------+-------------------------------+ 461 | | 462 | Peer entry n (see below) | 463 | | 464 +-------------------------------+-------------------------------+ 466 The 'responseIndication' flag shall be set to 0x2 to indicate a 467 rejection to the request, and no 'Peer entry' shall be attached if 468 the request is rejected. 470 Otherwise, the 'responseIndication' flag shall be set to 0x1 and n 471 'Peer entries' attached. 473 Each 'Peer entry' shall consist of the following fields: 475 0 1 2 3 476 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Peer's IP address | 479 +-------------------------------+-------------------------------+ 480 | Peer's SCTP port | padding | 481 +-------------------------------+-------------------------------+ 482 | Caretaker's IP address | 483 +-------------------------------+-------------------------------+ 484 | caretaker's SCTP port | padding | 485 +-------------------------------+-------------------------------+ 487 The peer's IP address and port number serve as the identification of 488 that peer. If the peer is inactive, its caretaker's IP address and 489 port number shall be filled in. Otherwise, the caretaker IP and port 490 fields shall be set to zeros. 492 3.8 TAKEOVER_INITIATE message 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | ENRP server message identifier #1 = 0x27047729 | 498 +-------------------------------+-------------------------------+ 499 | ENRP server message identifier #2 = 0x53829149 | 500 +-------------------------------+-------------------------------+ 501 | Type = 0x106 | 502 +-------------------------------+-------------------------------+ 503 | sending server's IP address | 504 +-------------------------------+-------------------------------+ 505 | sender's SCTP port | padding | 506 +-------------------------------+-------------------------------+ 507 | receiving server's IP address | 508 +-------------------------------+-------------------------------+ 509 | receiver's SCTP port | padding | 510 +-------------------------------+-------------------------------+ 511 | Target server's IP address | 512 +-------------------------------+-------------------------------+ 513 | Target server's SCTP port | padding | 514 +-------------------------------+-------------------------------+ 516 The receiving server's address and port do not need to be filled in 517 if the message is being multicasted. 519 The 'Target server's IP address and port number MUST be supplied. 521 3.9 TAKEOVER_INITIATE_RESPONSE message 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | ENRP server message identifier #1 = 0x27047729 | 527 +-------------------------------+-------------------------------+ 528 | ENRP server message identifier #2 = 0x53829149 | 529 +-------------------------------+-------------------------------+ 530 | Type = 0x107 | 531 +-------------------------------+-------------------------------+ 532 | sending server's IP address | 533 +-------------------------------+-------------------------------+ 534 | sender's SCTP port | padding | 535 +-------------------------------+-------------------------------+ 536 | receiving server's IP address | 537 +-------------------------------+-------------------------------+ 538 | receiver's SCTP port | padding | 539 +-------------------------------+-------------------------------+ 540 | Target server's IP address | 541 +-------------------------------+-------------------------------+ 542 | Target server's SCTP port | padding | 543 +-------------------------------+-------------------------------+ 545 The receiving server's address and port do not need to be filled in 546 if the message is being multicasted. 548 The 'Target server's IP address and port number MUST be supplied. 550 3.10 TAKEOVER_PEER_SERVER message 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | ENRP server message identifier #1 = 0x27047729 | 556 +-------------------------------+-------------------------------+ 557 | ENRP server message identifier #2 = 0x53829149 | 558 +-------------------------------+-------------------------------+ 559 | Type = 0x108 | 560 +-------------------------------+-------------------------------+ 561 | sending server's IP address | 562 +-------------------------------+-------------------------------+ 563 | sender's SCTP port | padding | 564 +-------------------------------+-------------------------------+ 565 | receiving server's IP address | 566 +-------------------------------+-------------------------------+ 567 | receiver's SCTP port | padding | 568 +-------------------------------+-------------------------------+ 569 | Target server's IP address | 570 +-------------------------------+-------------------------------+ 571 | Target server's SCTP port | padding | 572 +-------------------------------+-------------------------------+ 574 The receiving server's address and port do not need to be filled in 575 if the message is being multicasted. 577 The 'Target server's IP address and port number MUST be supplied. 579 3.11 SERVER_DUMP message 581 This is an ENRP service/maintainance message sent from an ENRP 582 service console. 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | ENRP endpoint message identifier #1 = 0x18038688 | 588 +-------------------------------+-------------------------------+ 589 | ENRP endpoint message identifier #2 = 0x77734683 | 590 +-------------------------------+-------------------------------+ 591 | Type = 0x7 | 592 +-------------------------------+-------------------------------+ 593 | | 594 | Console handle name (32) | 595 | | 596 +-------------------------------+-------------------------------+ 597 | Dump Type (see below) | 598 +-------------------------------+-------------------------------+ 600 The 'Dump Type' field shall take one of the following values: 602 0x0 --- HOME_LIST: dump the list of all the home PEs (i.e., PEs 603 owned by the receiving server) from the local copy of the 604 namespace. 605 0x1 --- REMOTE_LIST: dump the list of all the remote PEs (i.e., PEs 606 NOT owned by the receiving server) from the local copy of 607 the namespace. 608 0x2 --- PEER_LIST: dump the list of all the peers known to the 609 receiving server. 611 3.12 SERVER_DUMP_RESPONSE message 613 This is an ENRP service/maintainance message sent to an ENRP service 614 console as a response to a SERVER_DUMP request. 616 0 1 2 3 617 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | ENRP endpoint message identifier #1 = 0x18038688 | 620 +-------------------------------+-------------------------------+ 621 | ENRP endpoint message identifier #2 = 0x77734683 | 622 +-------------------------------+-------------------------------+ 623 | Type = 0x8 | 624 +-------------------------------+-------------------------------+ 625 | | 626 | Console handle name (32) | 627 | | 628 +-------------------------------+-------------------------------+ 629 | Dump Type (see below) | 630 +-------------------------------+-------------------------------+ 631 | Number of Entries = n (see below) | 632 +-------------------------------+-------------------------------+ 633 | | 634 | Dump entry 1 (see below) | 635 | | 636 +-------------------------------+-------------------------------+ 637 / / 638 \ \ 639 / / 640 +-------------------------------+-------------------------------+ 641 | | 642 | Dump entry n (see below) | 643 | | 644 +-------------------------------+-------------------------------+ 646 The 'Dump Type' fields shall take the same values as defined in 647 Section 3.11. 649 When the 'Dump Type' is HOME_LIST or REMOTE_LIST, the 'Number of 650 Entries' field shall be the number of pool entries carried in the 651 message, and each 'Dump entry' field shall contain a pool entry and 652 shall be defined as: 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | 658 | Pool handle name (32) | 659 | | 660 +-------------------------------+-------------------------------+ 661 | number of PEs in pool = m | 662 +-------------------------------+-------------------------------+ 663 | | 664 | PE #1 (40) | 665 | | 666 +-------------------------------+-------------------------------+ 667 / / 668 \ ..... \ 669 / / 670 +-------------------------------+-------------------------------+ 671 | | 672 | PE #m (40) | 673 | | 674 +-------------------------------+-------------------------------+ 676 When the 'Dump Type' is PEER_LIST, the 'Number of Entries' field 677 shall be the number of peer entries carried in the message, and each 678 'Dump entry' field shall contain a peer entry and shall be defined 679 as: 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Peer's IP address | 685 +-------------------------------+-------------------------------+ 686 | Peer's SCTP port | padding | 687 +-------------------------------+-------------------------------+ 688 | Caretaker's IP address | 689 +-------------------------------+-------------------------------+ 690 | caretaker's SCTP port | padding | 691 +-------------------------------+-------------------------------+ 693 In a peer entry, the peer's IP address and port number serve as the 694 identification of that peer. If the peer is inactive, its 695 caretaker's IP address and port number shall be filled 696 in. Otherwise, the caretaker IP and port fields shall be zeroed out. 698 4. ENRP Operation Procedures 700 In this section, we discuss the procedures defined by ENRP. The 701 procedures are divided into three groups, namely the basic ENRP 702 operations, fault management, and control/maintenance procedures. 704 Many of the Rserpool events call for message exchanges and other 705 activities between both a PE and an ENRP server and the ENRP server 706 and its peers. But only the message exchanges and activities between 707 the ENRP server and its peers are considered within the ENRP 708 protocol definition scope 710 Procedures and message formats for communications between a PE and 711 ENRP servers are defined in [ASAP]. However, in order to put our 712 discussion in context, we will give brief description of the ASAP 713 activities whenever appropreate. 715 4.1 Basic ENRP Operations 717 4.1.1 PE Registration 719 ENRP server <-> PE: 721 This action is part of the ASAP protocol and is defined in [ASAP]. 723 To register itself with the name space, a PE sends a REGISTRATION 724 message over the ENRP client channel to its home ENRP server. 726 In the REGISTRATION message, the PE indicates the name of the pool 727 it wishes to join, its network access address(es) (e.g., a list of 728 valid transport addresses with which the PE can be reached), and any 729 load control information. 731 The ENRP server handles the REGISTRATION message according to the 732 following rules: 734 1) If the named pool does not exist in the namespace, the ENRP 735 server will creates a new pool with that name in the namespace and 736 add the PE to the pool as its first PE; 738 2) If the named pool already exists in the namespace, but the 739 requesting PE is not currently a member of the pool, ENRP server 740 will add the PE as a new member to the pool; 742 3) If the named pool already exists in the namespace AND the 743 requesting PE is already a member of the pool, i.e., a case of 744 duplicated registration, the ENRP server will acknowledge the 745 registration request but will not take any further actions; 747 4) The ENRP server may reject the registration due to reasons such 748 as invalid values, lack of resource, etc. 750 In cases 1 and 2 above, the ENRP server will also assume the 751 ownership of the requesting PE. 753 In all cases, the ENRP server will reply to the requesting PE with a 754 REGISTRATION_RESPONSE message, and will indicate in the message body 755 whether the registration is granted or rejected. 757 ENRP server <-> Its peers: 759 If the registration request is not a duplicate and is granted, the 760 home ENRP server MUST take the namespace modification action as 761 described in section 4.1.4.1. Otherwise, no message shall be 762 exchanged with its peers. 764 4.1.2 PE De-registration 766 ENRP server <-> PE: 768 This action is part of the ASAP protocol and is defined in [ASAP]. 770 To remove itself from a pool, a PE sends a DEREGISTRATION message 771 over the ENRP client channel to its home ENRP server. 773 In response, the home ENRP server sends a REGISTRATION_RESPONSE 774 message to the PE and indicates in the message body whether the 775 request is granted or rejected. 777 If the PE is the last one of the named pool, the home ENRP server 778 will remove the pool from the namespace as well. 780 The ENRP server may reject the de-registration request due to 781 reasons such as invalid parameters, etc. 783 It should be noted that de-registration does not stop the PE from 784 sending or receiving messages. 786 ENRP server <-> peers: 788 Once the de-registration request is granted and the PE removed from 789 its local copy of the namespace, the home ENRP server MUST take the 790 namespace modification action described in section 4.1.4.2. 792 4.1.3 Name Translation 794 ENRP server <-> PE or PU: 796 This action is part of the ASAP protocol and is defined in [ASAP]. 798 A PE or PU can use the name translation service provided by the ENRP 799 server to resolve a pool name to a list of accessible transport 800 addresses of existing PEs. 802 This requires the PE or PU to send a NAME_REQUEST messages to its 803 home ENRP server and in the NAME_REQUEST message specify the pool 804 name to be translated. 806 If the named pool exits in the namespace, the home ENRP server will 807 send back a NAME_INFORMATION message that shall carry all 808 information of the PEs currently registered under that pool 809 name. This information may include the current load control policy 810 of the pool, policy value of each PE, transport address(es) for each 811 PE, etc. 813 Otherwise, the ENRP server shall respond with a NAME_UNKNOWN 814 message. 816 ENRP server <-> peers: 818 None. 820 4.1.4 Server Namespace Update 822 This includes a set of update operations used by an ENRP server to 823 inform its peer(s) the addition of a new PE, removal of an existing 824 PE, or change of pool or PE properties, etc. 826 4.1.4.1 Add a New PE 828 When a new PE is granted registration to the namespace, the home 829 ENRP server uses this procedure to inform all its peers. 831 An ENRP server shall multicast over the ENRP server channel a 832 PEER_NAME_UPDATE message with the appropriate flag set to indicate 833 to its peers about the addition of the new PE to the namespace. 835 Upon the reception of this PEER_NAME_UPDATE message, each of the 836 peer ENRP servers shall take the following actions: 838 1) If the named pool under which the new PE has been registered does 839 not exist in the peer's local copy of the namespace, the peer ENRP 840 server shall create the named pool in its local namespace copy and 841 add the PE to it as the first PE. It then shall copy in all other 842 attributes of the PE carried in the message. 844 2) If the named pool already exists in the peer's local copy of the 845 namespace, the peer shall add the new PE to the pool as a new PE and 846 copy in all attributes of the PE carried in the message. 848 3) If the named pool exists AND the PE is already a member of the 849 pool in its the local copy of the namespace, the peer ENRP server 850 shall take no actions. 852 4) If the new PE is added to its local copy of namespace (i.e., case 853 1 or 2 above), the peer ENRP server shall further check whether the 854 PE is located on the same host as the peer ENRP server itself 855 does. If so, the peer ENRP server shall assume the ownership of the 856 PE, and take the claim ownership actions described in section 857 4.1.4.5. 859 4.1.4.2 Forceful Removal of a PE 861 This procedure is used by an ENRP server to inform its peer(s) to 862 remove an existing PE, regardless of the ownership of the PE. 864 The ENRP server shall multicast over the ENRP server channel a 865 PEER_NAME_UPDATE message with the appropriate flag set to instruct 866 its peers to forcefully remove the PE from their local copy of the 867 namespace. 869 On the reception of this PEER_NAME_UPDATE message, each peer ENRP 870 server shall find and remove the PE from its local copy of the 871 namespace regardless whether or not it has ownership on the PE. 873 4.1.4.3 Advisory Removal of a PE 875 This operation is used by an ENRP server to instruct its peers to 876 remove an existing PE on which the peer does not have an ownership. 878 An ENRP server shall multicast over the ENRP server channel a 879 PEER_NAME_UPDATE message with the appropriate flag set to instruct 880 its peers to remove the specified PE from its local copy of the 881 namespace _if_ the peer does not own the PE. 883 On the reception of this PEER_NAME_UPDATE message, a peer ENRP 884 server shall find and remove the PE from its local copy of the 885 namespace _if_ it does not own this PE. 887 4.1.4.4 Update PE Attributes 889 This operation is used by an ENRP server to inform its peers to 890 update the attributes of an existing PE. 892 An ENRP server shall multicast over the ENRP server channel a 893 PEER_NAME_UPDATE message with the appropriate flag set to instruct 894 its peers to replace the attributes of an existing PE in its local 895 copy of the name space. 897 On the reception of this PEER_NAME_UPDATE message, a peer ENRP 898 server shall replace the attributes of the existing PE with the new 899 information carried in the message if the PE exists in its local 900 copy of the name space. If the specified PE is not found in its 901 local name space copy, the peer server shall add the PE following 902 the steps 1) to 2) in Section 4.1.1. 904 4.1.4.5 Claim Ownership over a PE 906 This operation is used by an ENRP server to claim the ownership on a 907 specific PE and to inform its peers about its claim. 909 ENRP server <-> PE: 911 This action is part of the ASAP protocol and is defined in [ASAP]. 913 An ENRP server shall send an ASAP ENDPOINT_KEEP_ALIVE message to the 914 PE. This message will cause the PE to adopt this ENRP server as its 915 new home ENRP server (see section 4.10.3 in [ASAP]). 917 ENRP server <-> Its peers: 919 An ENRP server shall multicast over the ENRP server channel a 920 PEER_NAME_UPDATE message with the appropriate flag set to inform its 921 peers that it has taken the ownership of the specified PE. 923 Upon the reception of this PEER_NAME_UPDATE message, a peer server 924 shall check whether it is the current owner of the PE. If so, this 925 peer server shall relinquish its ownership on that PE. Otherwise, no 926 action is needed. 928 4.1.4.6 Report PE Communication Failure 930 This operation is used by an ENRP server to warn its peers that it 931 has noticed a potentially unreachable PE that the server does not 932 have ownership on. 934 An ENRP server shall multicast over the ENRP server channel a 935 PEER_NAME_UPDATE message with the appropriate flag set to indicate 936 that the specified PE is potentially unreachable. 938 On the reception of this message, each peer ENRP server shall check 939 whether it owns the specified PE. If it does, the peer server shall 940 increase the counter of the specified PE 941 by 1. If the value of the counter has 942 exceeded the protocol parameter Max-Endpoint-Report-Failures, the 943 peer server shall remove the PE from its local namespace and take 944 actions described in Section 4.1.4.3. 946 If the peer server does not own the specified PE, it shall take no 947 action. 949 4.1.5 PE Change Policy Value 951 A PE can modify its load policy value at any time. Based on the 952 number of PEs in the pool and the pool's load distrbution policy, 953 this operation allows the PE to dynamically control its share of 954 inbound messages received by the pool (also see section 4.5.2?? in 955 [ASAP] for more on load control). 957 ENRP server <-> PE: 959 This action is part of the ASAP protocol and is defined in [ASAP]. 961 A PE normally sends an UPDATE_POLICY_VALUE ASAP message over the 962 ENRP client channel to its home ENRP server in order to modify its 963 policy value. The new policy value is always indicated in the 964 message. 966 Upon the reception of this UPDATE_POLICY_VALUE message, the home 967 ENRP server will replace the policy value of that PE in its local 968 copy of the namespace with the new value indicated in the message. 970 ENRP server <-> peers: 972 If the above update on its local copy of the namespace is 973 successful, the home ENRP server shall take the Update PE Attributes 974 actions as described in Section 4.1.4.4. 976 4.1.6 Server Download Namespace from a Peer Server 978 This operation allows an ENRP server to request and receive a copy 979 of a portion of the namespace from one of its peer ENRP servers. 981 This operation is especially useful for a newly started ENRP server 982 to initiate its local copy of the namespace, as well as for an 983 existing ENRP server to correct namespace inconsistency found during 984 its operation. 986 1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message 987 directly to one of its peers. In the message, it shall indicate 988 which portion of the namespace is being requested. 990 2) Upon the reception of this message, the peer server shall 991 initiate a download session in which the requested portion of the 992 namespace shall be sent to the requesting ENRP server in one or more 993 PEER_NAME_TABLE_RESPONSE messages. 995 If the sending ENRP server determines that multiple 996 PEER_NAME_TABLE_RESPONSE messages are needed for the session, it 997 shall set the appropriate flag in each PEER_NAME_TABLE_RESPONSE 998 message to inform the receiving ENRP server whether or not the data 999 in this message is the last piece of the transfer. 1001 3) During the downloading, every time the requesting ENRP server 1002 receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer the 1003 data entries carried in the message into its local namespace 1004 database, and then check whether or not the data in this message is 1005 the last piece being transfered. If more data transfer is indicated, 1006 the requesting ENRP server shall send another 1007 PEER_NAME_TABLE_REQUEST message to the same peer to request for the 1008 next piece whenever it is ready. 1010 When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 1011 message into its local namespace database, the requesting ENRP 1012 server shall follow the same procedures as described in section 1013 2.1.1.4.1 when parsing through the PEs carrying in the message one 1014 by one. 1016 4.1.7 Server Monitor Peer Status 1018 An ENRP server shall keep a record on the status of each of its 1019 known peers. 1021 If a message of any type is received from a peer, the ENRP server 1022 shall update that peers status as . If a message of any 1023 type is received from a peer previously unknown, the ENRP server 1024 shall create a record for the new peer and mark the new peer as 1025 . 1027 4.1.8 Server Download Peer List from a Peer Server 1029 This operation allows an ENRP server to request from a peer server a 1030 copy of its internal peer list. This is useful for a new ENRP server 1031 to initiate its own peer list at startup. 1033 An ENRP server shall send a PEER_LIST_REQUEST message to a peer to 1034 request a copy of the peer list. 1036 Upon the reception of this message, the peer server shall reply with 1037 a PEER_LIST_RESPONSE message and include in the message body a copy 1038 of its peer list, consisting of all the ENRP servers known by the 1039 peer togather with their status. 1041 If the peer itself is in the process of startup, it shall response 1042 with a PEER_LIST_RESPONSE message but set the appropriate flag to 1043 indicate that it can not grant the PEER_LIST_REQUEST. In such a 1044 case, the requesting ENRP server shall select another peer and 1045 repeat the peer list request with the new peer at a later time. 1047 4.1.9 ENRP Server Initialization 1049 This section describes the steps a new ENRP server needs to take in 1050 order to join the other existing ENRP servers for providing the 1051 namespace service in the operation scope, or initiating the 1052 namespace service if this is the first ENRP server starting in the 1053 operation scope. 1055 1) At startup, before getting into service, the ENRP server 1056 (initiating server) shall multicast a PEER_PRESENCE message with 1057 'Reply_required' flag set over the ENRP server channel. This is to 1058 inform any other existing peers in the operation scope about the 1059 initiating peer's presence. 1061 2) Upon the reception of this message, a peer shall send a 1062 PEER_PRESENCE without 'Reply_required' flag back to the initiating 1063 server, in order to help the initiating server to build a peer list. 1065 3) If no response to its PEER_PRESENCE message are received, the 1066 initiating server shall assume that it is alone in the operation 1067 scope and shall mark the initialization process as completed. The 1068 initiation server shall skip the remaining steps and start to offer 1069 the namespace services. 1071 4) If there are responses to its PEER_PRESENCE message, the 1072 initiating server shall then take the actions described in 4.1.8 to 1073 request a peer list from one of the peers that have responded. 1075 5) Upon the reception of the PEER_LIST_RESPONSE message from the 1076 peer, the initiating server shall use the information carried in the 1077 message to build a complete peer list, including both active and 1078 inactive peers in the operation scope. 1080 6) Then, the initiating server shall download the HOME_LIST of the 1081 namespace from each active peer, as described in 4.1.6. 1083 Moreover, the initiating server shall also pick one of the active 1084 peers and request to download the REMOTE_LIST from that peer. 1086 These downloads once done should allow the initiating server to 1087 create a complete view of the current namespace. 1089 At this point, the initialization process is completed and the 1090 initiating server shall start to provide namespace services. 1092 4.2 Fault Management Operations 1094 The following operations are used to detect and recover from various 1095 system faults. 1097 4.2.1 Detect and Report Unreachable PE 1099 Two mechanisms exist to detect and report an unreachable PE: 1101 1) Home ENRP server periodic sanity check 1103 An ENRP server shall send, in every seconds, 1104 an ENDPOINT_KEEP_ALIVE message to each of the PE it owns, and shall 1105 keep the number of consecutive failed send attempts in the counter 1106 of that PE. 1108 If the value of of a PE exceeds the 1109 pre-set threshold Max-endpoint-sanity-failures, the home ENRP 1110 server shall remove the PE from its local copy of the namespace 1111 and take the actions described in section 4.1.4.3 to inform its 1112 peers. 1114 The definition and handling of the ENDPOINT_KEEP_ALIVE message by 1115 the PE are part of ASAP and are described in sections 3.9?? and 1116 4.10.3?? in [ASAP]. 1118 2) Failure report by peer PE 1120 Whenever a PE finds a peer PE unreachable (e.g., via an SCTP 1121 SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the 1122 former shall send an ENDPOINT_UNREACHABLE message over the ENRP 1123 client channel to its home ENRP server. The message shall contain 1124 one of the transport addresses of the unreachable peer PE and have 1125 the 'Severity' flag set to NORMAL_REPORT in the message. 1127 The definition and procedure of ENDPOINT_UNREACHABLE message are 1128 part of ASAP and are described in [ASAP]. 1130 Upon the reception of the ENDPOINT_UNREACHABLE message, the home 1131 ENRP server shall first check whether it owns the unreachable 1132 PE. If not, the home ENRP server shall take the actions described 1133 in section 4.1.4.6. 1135 If the home ENRP server does own the unreachable PE, it shall 1136 increase an counter of the unreachable 1137 PE by 1, and if the value of the 1138 counter exceeds threshold Max-endpoint-report-failures, the server 1139 shall remove the PE from its local copy of the namespace and take 1140 actions described in 4.1.4.3. 1142 4.2.2 ENRP Server Failure Detection by Heartbeat 1144 An ENRP server shall multicast, in every 1145 seconds, a PEER_PRESENCE message over the ENRP server channel to 1146 inform its peers that it is still operational. In the PEER_PRESENCE 1147 message, the sending ENRP server shall unset the 'Replay_required' 1148 flag to indicate that no response is required. 1150 Occassionally, an ENRP server may also send a point-to-point 1151 PEER_PRESENCE message to a specific peer server, with the 1152 'Replay_required' flag set in the message, indicating that a 1153 response is required. In such a case, the receiving peer server MUST 1154 immediately respond to the sender with its own point-to-point 1155 PEER_PRESENCE message without setting the 'Replay_required' flag. 1157 4.2.3 PE or PU Home ENRP Server Hunt 1159 This action is part of ASAP protocol and is defined in [ASAP]. 1161 At its startup, or when it fails to send to (i.e., timed-out on a 1162 service request) with its current home ENRP server, a PE or PU shall 1163 initiate the following home server hunt procedure. 1165 In the home server hunt procedure, the PE or PU shall multicast a 1166 SERVER_HUNT message over the ENRP client channel, and shall repeat 1167 sending this message every seconds until a 1168 SERVER_HUNT_RESPONSE message is received from an ENRP 1169 server. Moreover, each time the 'Timeout-server-hunt' timer expires 1170 the criticality should be raised (initially criticality should be 1171 set to LOW_CRITICALITY). 1173 Then the PE or PU shall pick one of the ENRP servers that have 1174 responded as its new home ENRP server, and send all its subsequent 1175 the namespace service requests to it. 1177 Upon the reception of the SERVER_HUNT message, an ENRP server shall 1178 normally reply to the PE with a SERVER_HUNT_RESPONSE message, unless 1179 its peer status information indicates that there is a caretaker ENRP 1180 server other than itself for the node where the PE resides, AND the 1181 criticality flag in the SERVER_HUNT message is not HIGH_CRITICALITY. 1183 4.2.4 ENRP Server Detecting and Taking-over Inactive Peer 1185 An ENRP server shall keep track the time when the last message 1186 (multicast or point-to-point) was received from each known peer. 1188 If a peer has not been heard for more than Max-time-last-heard, the 1189 ENRP server shall send a point-to-point PEER_PRESENCE with 'Reply 1190 request' to that peer. 1192 If the send fails or the peer does not reply after 1193 Max-time-no-response seconds, the ENRP server shall initiate the 1194 following server take-over procedures: 1196 1) Initiate Server Take-over Arbitration 1198 The ENRP server (the initiating server) shall initiate a take-over 1199 arbitration on the inactive peer (the target server) by multicasting 1200 a TAKEOVER_INITIATE message over the ENRP server channel. In the 1201 message, the initiating server shall specify the identification of 1202 the target server. 1204 After multicasting the TAKEOVER_INITIATE message, the initiating 1205 server shall wait for a TAKEOVER_INITIATE_RESPONSE message from 1206 each of its active peers. 1208 Upon the reception of this message, other peer servers shall take 1209 the following actions accordingly: 1211 A1) If the peer server finds that itself is the target server 1212 indicated in the TAKEOVER_INITIATE message, it MUST 1213 immediately multicast a PEER_PRESENCE message over the ENRP 1214 server channel in an attempt to stop the take-over process. 1216 A2) If the peer server finds that itself has also initiated a 1217 take-over process on the same target server AND its IP address 1218 is smaller in value than that of the sender of the 1219 TAKEOVER_INITIATE message, the peer server shall abort its own 1220 take-over process and perform A3) below. 1222 A3) Peers other than the target peer and the initiating peer shall 1223 mark the target server as and mark the initiating 1224 server as the caretaker of the target server and reply to the 1225 initiating server with a TAKEOVER_INITIATE_RESPONSE message. 1227 A4) Once it has received TAKEOVER_INITIATE_RESPONSE message from 1228 all of its active peers, the initiating server shall consider 1229 it won the arbitration and shall then take the actions in 2) 1230 below so as to complete the take-over. 1232 However, if it receives a PEER_PRESENCE from the target server 1233 at any point of the take-over, the initiating server shall 1234 immediately abort the take-over process and re-mark the target 1235 server as . 1237 2) Take-over the target peer server 1239 The initiating ENRP server shall multicast a TAKEOVER_PEER_SERVER 1240 message over the ENRP server channel in order to inform all its 1241 peers about the take-over. 1243 In the message, identification of the inactive peer server targeted 1244 for the take-over MUST be included. 1246 The initiating server shall mark the target server as and 1247 mark itself as the caretaker of the target server in its own peer 1248 list. 1250 Then it shall claim ownership on each of the PEs in its local copy 1251 of the namespace that is originally owned by the target server. The 1252 procedures in x.x.x.x. shall be followed when claiming the ownership 1253 of the PEs. 1255 The server shall finally check whether there are any inactive peers 1256 (other than the current target server) which has designated the 1257 target server as their caretaker. If so, the initiating server shall 1258 perform the above ownership take-over procedure on each one of those 1259 inactive peers as well. 1261 4.2.5 Registration of Remote PEs 1263 When an ENRP server receives a REGISTRATION message from a PE 1264 located on a remote machine, it shall always accept and grant the 1265 registration and assume ownership of the PE. 1267 However, if the ENRP server's peer status information indicates that 1268 the peer on the remote machine is inactive AND a caretaker other 1269 than the ENRP server itself exists for that machine, the ENRP server 1270 shall reject the registration and take no further actions. 1272 If the ENRP server has no record about a peer on that remote node, 1273 it shall grant the registration as above AND then create a peer 1274 record in its local peer list about that node, mark the new peer as 1275 inactive, and initiate a take-over procedure on the new peer, as 1276 described in section 4.2.4. 1278 4.3 Maintenance Operations 1280 The following operations are used by an ENRP maintenance client to 1281 monitor the name space data and perform maintenances on ENRP servers 1282 in an operation scope. 1284 4.3.1 Forceful Removal of a PE 1286 In order to force the removal of PE from the namespace, a 1287 maintenance client shall send an ENDPOINT_UNREACHABLE message to an 1288 existing ENRP server, and in the message shall indicate one of the 1289 transport addresses of the target PE and have the 'Severity' flag 1290 set to FINAL_REPORT. 1292 Upon the reception of this message, the ENRP server shall 1293 immediately remove the target PE from its local copy of the 1294 namespace and take actions described in Section 4.1.4.2 to inform 1295 its peers to do the same. 1297 4.3.2 Dump Home PE List 1299 To require a copy of the information on all the PEs owned by an ENRP 1300 server, a maintenance client shall send a SERVER_DUMP message with 1301 'Dump type' flag set to HOME_LIST to the server. 1303 Upon receiving this message, the ENRP server shall response with a 1304 SERVER_DUMP_RESPONSE message with the 'Dump type' flag set to 1305 HOME_LIST to the maintenance client, and in the message body, 1306 include information on all the PEs the server currently owns. 1308 4.3.3 Dump Remote PE List 1310 To require a copy of the information on all the PEs NOT owned by an 1311 ENRP server, a maintenance client shall send a SERVER_DUMP message 1312 with 'Dump type' flag set to REMOTE_LIST to the server. 1314 Upon receiving this message, the server shall response with a 1315 SERVER_DUMP_RESPONSE message with the 'Dump type' flag set to 1316 REMOTE_LIST to the maintenance client, and in the message body, 1317 include information on all the PEs the server currently does NOT 1318 own. 1320 4.3.4 Dump Peer Server List 1322 To require a copy of the peer list known to a specific ENRP server 1323 (this list most likely will also represent ALL the active and 1324 inactive ENPR servers in the operation scope), a maintenance client 1325 shall send a SERVER_DUMP message with the 'Dump type' flag set to 1326 PEER_SERVER_LIST to the ENRP server. 1328 Upon receiving this message, the server shall response with a 1329 SERVER_DUMP_RESPONSE message with the 'Dump type' flag set to 1330 PEER_SERVER_LIST to the maintenance client, and in the message body, 1331 include information on all the peers that server currently knows. 1333 5. Variables, Time Constants, and Thresholds 1335 The following is a summary of the variables, time values, and 1336 pre-set thresholds used in ASAP and ENRP protocol. 1338 5.1 Variables 1340 Endpoint-report-failures --- per registered PE, this keeps the 1341 number of unreachable reports concerning the PE. 1343 Endpoint-sanity-failures --- per registered PE; this keeps the 1344 number of failed sanity message send attempts concerning the PE. 1346 Peer-server-last-heard --- per peer ENRP server; this is a time 1347 stamp on when the last message was received from this peer server. 1349 5.2 Timer Constants 1351 Endpoint-sanity-cycle --- the period for a home ENRP server to start 1352 a new round of PE sanity check. 1354 Peer-heartbeat-cycle ---the period for an ENRP server to send out a 1355 heartheat message to its known peers. 1357 5.3 Thresholds 1359 Max-endpoint-sanity-failures --- pre-set threshold for 1360 Endpoint-sanity-failures. 1362 Max-endpoint-report-failures --- pre-set threshold for 1363 Endpoint-report-failures. 1365 Max-time-last-heard --- pre-set threshold for 1366 Peer-server-last-heard. 1368 Max-time-no-response --- pre-set threshold for a peer server to 1369 answer a PEER_PRESENCE message with reply required. 1371 Timeout-server-hunt --- pre-set threshold for how long a PE will 1372 wait for the REGISTRATION_RESPONSE from its home ENRP server. 1374 6. References 1376 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1377 3", BCP 9, RFC 2026, October 1996. 1379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1380 Requirement Levels", BCP 14, RFC 2119, March 1997. 1382 [ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol 1383 (ASAP)", , work in progress. 1385 [RSERPOOL1] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, 1386 L. Ong, J. Loughney, M. Stillman: "Requirements for Reliable Server 1387 Pooling," , work in progress. 1389 [RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, 1390 L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server 1391 Pooling," , work in progress. 1393 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 1394 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, 1395 V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October 1396 2000. 1398 7. Acknowledgements 1400 The authors wish to thank John Loughney, Lyndon Ong, and 1401 Maureen Stillman and many others for their invaluable comments. 1403 8. Authors' Addresses 1405 Randall R. Stewart 1406 24 Burning Bush Trail. 1407 Crystal Lake, IL 60012 1408 USA 1410 Phone: +1-815-477-2127 1411 EMail: rrs@cisco.com 1413 Qiaobing Xie 1414 Motorola, Inc. 1415 1501 W. Shure Drive, #2309 1416 Arlington Heights, IL 60004 1417 USA 1419 Phone: +1-847-632-3028 1420 EMail: qxie1@email.mot.com 1422 Expires in six months from June 2001