idnits 2.17.1 draft-ietf-rserpool-enrp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1826. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1842), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 40 longer pages, the longest (page 12) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 46 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Other values are reserved by IETF and MUST not be used. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2004) is 7231 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: '4' is defined on line 1740, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3237 (ref. '2') == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-07 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '3') ** Obsolete normative reference: RFC 2246 (ref. '6') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2960 (ref. '7') (Obsoleted by RFC 4960) == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '10') == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-threats (ref. '11') -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. '12') (Obsoleted by RFC 4086) Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 8 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 Expires: January 7, 2005 R. Stewart 4 Cisco 5 M. Stillman 6 Nokia 7 July 9, 2004 9 Endpoint Name Resolution Protocol (ENRP) 10 draft-ietf-rserpool-enrp-09.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 7, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 Endpoint Name Resolution Protocol (ENRP) is designed to work in 44 conjunction with the Aggregate Server Access Protocol (ASAP) to 45 accomplish the functionality of the Reliable Server Pooling 46 (Rserpool) requirements and architecture. Within the operational 47 scope of Rserpool, ENRP defines the procedures and message formats of 48 a distributed, fault-tolerant registry service for storing, 49 bookkeeping, retrieving, and distributing pool operation and 50 membership information. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. ENRP Message Definitions . . . . . . . . . . . . . . . . . . 7 58 3.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 7 59 3.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 9 60 3.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 9 61 3.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 11 62 3.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 12 63 3.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 64 3.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 65 3.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 15 66 3.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15 67 3.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . 16 68 3.11 PEER_ERROR message . . . . . . . . . . . . . . . . . . . 18 69 4. ENRP Operation Procedures . . . . . . . . . . . . . . . . . 19 70 4.1 Methods for Communicating amongst ENRP Servers . . . . . . 19 71 4.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 20 72 4.2.1 Generate a Server Identifier . . . . . . . . . . . . . 21 73 4.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . 21 74 4.2.3 Download ENRP Namespace Data from Mentor Peer . . . . 23 75 4.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 25 76 4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . 27 77 4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 28 78 4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28 79 4.6 Server Namespace Update . . . . . . . . . . . . . . . . . 29 80 4.6.1 Announcing Addition or Update of PE . . . . . . . . . 29 81 4.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . 30 82 4.7 Detecting and Removing Unreachable PE . . . . . . . . . . 31 83 4.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 32 84 4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 32 85 4.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . 32 86 4.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . 32 87 4.9.3 Detecting Peer Server Failure . . . . . . . . . . . . 33 88 4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . 33 89 4.10.1 Initiate Server Take-over Arbitration . . . . . . . 33 90 4.10.2 Take-over Target Peer Server . . . . . . . . . . . . 34 91 4.11 Namespace Data Auditing and Re-synchronization . . . . . 35 92 4.11.1 Auditing Procedures . . . . . . . . . . . . . . . . 35 93 4.11.2 PE Checksum Calculation Algorithm . . . . . . . . . 36 94 4.11.3 Re-synchronization Procedures . . . . . . . . . . . 37 95 4.12 Handling Unrecognized Message or Unrecognized 96 Parameter . . . . . . . . . . . . . . . . . . . . . . . 37 98 5. Variables and Thresholds . . . . . . . . . . . . . . . . . . 39 99 5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 39 100 5.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 39 101 6. Security Considerations . . . . . . . . . . . . . . . . . . 40 102 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 41 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 105 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 44 106 8.2 Informative References . . . . . . . . . . . . . . . . . . . 45 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 108 Intellectual Property and Copyright Statements . . . . . . . 46 110 1. Introduction 112 ENRP is designed to work in conjunction with ASAP [1] to accomplish 113 the functionality of Rserpool as defined by its requirements [2] and 114 architecture [3]. 116 Within the operation scope of Rserpool, ENRP defines the procedures 117 and message formats of a distributed fault-tolerant registry service 118 for storing, bookkeeping, retrieving, and distributing pool operation 119 and membership information. 121 Whenever appropriate, in the rest of this document we will refer to 122 this Rserpool registry service as ENRP namespace, or simply 123 namespace. 125 1.1 Definitions 127 This document uses the following terms: 129 Operation scope: See [3]; 131 Pool (or server pool): See [3]; 133 Pool handle (or pool name): See [3]; 135 Pool element (PE): See [3]; 137 Pool user (PU): See [3]; 139 Pool element handle: See [3]; 141 ENRP namespace (or namespace): See [3]; 143 ENRP namespace server (or ENRP server): See [3]; 145 ENRP client channel: The communication channel through which a PE 146 requests for ENRP namespace service. The ENRP client channel is 147 usually defined by the transport address of the home ENRP server 148 and a well known port number; 150 ENRP server channel: Defined by a well known multicast IP address and 151 a well known port number. All ENRP servers in an operation scope 152 can send multicast messages to other servers through this channel. 153 PEs are also allowed to multicast on this channel occasionally; 155 Home ENRP server: The ENRP server to which a PE or PU currently 156 belongs. A PE MUST only have one home ENRP server at any given 157 time and both the PE and its home ENRP server MUST keep track of 158 this master/slave relationship between them. A PU SHOULD select 159 one of the available ENRP servers as its home ENRP server, but the 160 ENRP server does not need to know, nor does it need to keep track 161 of this relationship. 163 2. Conventions 165 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 166 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 167 they appear in this document, are to be interpreted as described in 168 [5]. 170 3. ENRP Message Definitions 172 In this section, we defines the format of all ENRP messages. These 173 are messages sent and received amongst ENRP servers in an operation 174 scope. Messages sent and received between a PE/PU and an ENRP server 175 are part of ASAP and are defined in [1]. A common format, defined in 176 [10], is used for all ENRP and ASAP messages. 178 Most ENRP messages contains a combination of fixed fields and TLV 179 parameters. The TLV parameters are also defined in [10]. 181 All messages, as well as their fields/parameters described below, 182 MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., 183 the most significant byte first). 185 For ENRP, the following message types are defined: 187 Type Message Name 188 ----- ------------------------- 189 0x0 - (reserved by IETF) 190 0x1 - PEER_PRESENCE 191 0x2 - PEER_NAME_TABLE_REQUEST 192 0x3 - PEER_NAME_TABLE_RESPONSE 193 0x4 - PEER_NAME_UPDATE 194 0x5 - PEER_LIST_REQUEST 195 0x6 - PEER_LIST_RESPONSE 196 0x7 - PEER_INIT_TAKEOVER 197 0x8 - PEER_INIT_TAKEOVER_ACK 198 0x9 - PEER_TAKEOVER_SERVER 199 0xa - PEER_OWNERSHIP_CHANGE 200 0xb - PEER_ERROR 201 0xc-0xFF - (reserved by IETF) 203 3.1 PEER_PRESENCE message 205 This ENRP message is used to announce (periodically) the presence of 206 an ENRP server, or to probe the status of a peer ENRP sever. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Sender Server's ID | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Receiver Server's ID | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 : PE Checksum Param : 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 : Server Information Param (optional) : 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 R (reply_required) flag: 1 bit 224 Set to '1' if the sender requires a response to this message, 225 otherwise set to '0'. 227 Sender Server's ID: 32 bit (unsigned integer) 229 This is the ID of the ENRP server which sends the message. 231 Receiver Server's ID: 32 bit (unsigned integer) 233 This is the ID of the ENRP server to which the message is 234 intended. If the message is not intended to an individual 235 server (e.g., the message is multicasted to a group of 236 servers), this field MUST be set with all 0's. 238 PE Checksum Parameter: 240 This is a TLV that contains the latest PE checksum of the ENRP 241 server who sends the PEER_PRESENCE. This parameter SHOULD be 242 included for namespace consistency auditing. See Section 243 4.11.1 for details. 245 Server Information Parameter: 247 If present, contains the server information of the sender of 248 this message (Server Information Parameter is defined in [10]). 249 This parameter is optional. However, if this message is sent 250 in response to a received "reply required" PEER_PRESENCE from a 251 peer, the sender then MUST include its server information. 253 Note, at startup an ENRP server MUST pick a randomly generated, 254 non-zero 32-bit unsigned integer as its ID and MUST use this same ID 255 for its entire life. 257 3.2 PEER_NAME_TABLE_REQUEST message 259 An ENRP server sends this message to one of its peers to request a 260 copy of the namespace data. This message is normally used during 261 server initialization or namespace re-synchronization. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type = 0x2 |0|0|0|0|0|0|0|W| Message Length = 0xC | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Sender Server's ID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Receiver Server's ID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 W (oWn-children-only) flag: 1 bit 275 Set to '1' if the sender of this message is only requesting 276 information about the PEs owned by the message receiver. 277 Otherwise, set to '0'. 279 Sender Server's ID: 281 See Section 3.1. 283 Receiver Server's ID: 285 See Section 3.1. 287 3.3 PEER_NAME_TABLE_RESPONSE message 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type = 0x3 |0|0|0|0|0|0|M|R| Message Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Sender Server's ID | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Receiver Server's ID | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 : : 298 : Pool entry #1 (see below) : 299 : : 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 : : 302 : ... : 303 : : 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 : : 306 : Pool entry #n (see below) : 307 : : 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 M (More_to_send) flag: 1 bit 312 Set to '1' if the sender has more pool entries to sent in 313 subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set to 314 '0'. 316 R (Reject) flag: 1 bit 318 MUST be set to '1' if the sender of this message is rejecting a 319 namespace request. In such a case, this message MUST be sent 320 with no pool entries included. 322 Message Length: 16 bits (unsigned integer) 324 Indicates the entire length of the message in number of octets. 326 Note, the value in Message Length field will NOT cover any 327 padding at the end of this message. 329 Sender Server's ID: 331 See Section 3.1. 333 Receiver Server's ID: 335 See Section 3.1. 337 Pool entry #1-#n: 339 If R flag is '0', at least one pool entry SHOULD be present in 340 the message. Each pool entry MUST start with a pool handle 341 parameter as defined in section 3.1.7, followed by one or more 342 pool element parameters, i.e.: 344 +---------------------------+ 345 : Pool handle : 346 +---------------------------+ 347 : PE #1 : 348 +---------------------------+ 349 : PE #2 : 350 +---------------------------+ 351 : ... : 352 +---------------------------+ 353 : PE #n : 354 +---------------------------+ 356 3.4 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 | Type = 0x4 |0|0|0|0|0|0|0|0| Message Length | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Sender Server's ID | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Receiver Server's ID | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Update Action | (reserved) | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 : Pool handle : 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 : Pool Element : 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Message Length: 16 bits (unsigned integer) 376 Indicates the entire length of the message in number of octets. 378 Note, the value in Message Length field will NOT cover any 379 padding at the end of this message. 381 Update Action: 16 bits (unsigned integer) 383 This field indicates what act is requested to the specified PE. 384 It MUST take one of the following values: 386 0x0 - ADD_PE: add or update the specified PE in the ENRP 387 namespace 389 0x1 - DEL_PE: delete the specified PE from the ENRP namespace. 391 Other values are reserved by IETF and MUST not be used. 393 Reserved: 16 bits 395 MUST be set to 0's by sender and ignored by the receiver. 397 Sender Server's ID: 399 See Section 3.1. 401 Receiver Server's ID: 403 See Section 3.1. 405 Pool handle: 407 Specifies to which the PE belongs. 409 Pool Element: 411 Specifies the PE. 413 3.5 PEER_LIST_REQUEST message 415 This ENRP message is used to request a copy of the current known ENRP 416 peer server list. This message is normally sent from a newly started 417 ENRP server to an existing ENRP server as part of the initialization 418 process of the new server. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length = 0xC | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Sender Server's ID | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Receiver Server's ID | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Sender Server's ID: 432 See Section 3.1. 434 Receiver Server's ID: 436 See Section 3.1. 438 3.6 PEER_LIST_RESPONSE message 440 This message is used to respond a PEER_LIST_REQUEST. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type = 0x6 |0|0|0|0|0|0|0|R| Message Length | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Sender Server's ID | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Receiver Server's ID | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 : Server Info Param of Peer #1 : 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 : ... : 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 : Server Info Param of Peer #n : 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 R (Reject) flag: 1 bit 460 MUST be set to '1' if the sender of this message is rejecting a 461 peer list request. In such a case, this message MUST be sent 462 with no peer server ID included. 464 Message Length: 16 bits (unsigned integer) 466 Indicates the entire length of the message in number of octets. 468 Note, the value in Message Length field will NOT cover any 469 padding at the end of this message. 471 Sender Server's ID: 473 See Section 3.1. 475 Receiver Server's ID: 477 See Section 3.1. 479 Server Information Parameter of Peer #1-#n: 481 Each contains a Server Information Parameter of a peer known to 482 the sender. The Server Information Parameter is defined in 483 [10]. 485 3.7 PEER_INIT_TAKEOVER message 487 This message is used by an ENRP server (the takeover initiator) to 488 declare its intention of taking over a specific peer ENRP server. 490 0 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Sender Server's ID | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Receiver Server's ID | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Target Server's ID | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Sender Server's ID: 504 See Section 3.1. 506 Receiver Server's ID: 508 See Section 3.1. 510 Target Server's ID: 512 Contains the 32-bit server ID of the peer ENRP that is the 513 target of this takeover attempt. 515 3.8 PEER_INIT_TAKEOVER_ACK message 517 This message is used to acknowledge the takeover initiator that the 518 sender of this message received the PEER_INIT_TAKEOVER message and 519 that it does not object to the takeover. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Type = 0x8 |0|0|0|0|0|0|0|0| Message Length | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Sender Server's ID | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Receiver Server's ID | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Target Server's ID | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Sender Server's ID: 535 See Section 3.1. 537 Receiver Server's ID: 539 See Section 3.1. 541 Target Server's ID: 543 Contains the 32-bit server ID of the peer ENRP that is the 544 target of this takeover attempt. 546 3.9 PEER_TAKEOVER_SERVER message 548 This message is used by the takeover initiator to declare that a 549 takeover is underway. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Type = 0x9 |0|0|0|0|0|0|0|0| Message Length | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Sender Server's ID | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Receiver Server's ID | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Target Server's ID | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 Sender Server's ID: 565 See Section 3.1. 567 Receiver Server's ID: 569 See Section 3.1. 571 Target Server's ID: 573 Contains the 32-bit server ID of the peer ENRP that is the 574 target of this takeover operation. 576 3.10 PEER_OWNERSHIP_CHANGE message 578 This message is used by the ENRP server, normally after a successful 579 takeover, to declare that it is now the new home ENRP server of the 580 listed PEs in the listed pools. 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type = 0xa |0|0|0|0|0|0|0|0| Message Length | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Sender Server's ID | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Receiver Server's ID | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 : Pool handle #1 : 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 : PE Identifier Param #1 of pool #1 : 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 : ... : 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 : PE Identifier Param #k of pool #1 : 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 : : 600 : ... : 601 : : 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 : Pool handle #M : 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 : PE Identifier Param #1 of pool #M : 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 : ... : 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 : PE Identifier Param #n of pool #M : 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Sender Server's ID: 614 See Section 3.1. 616 Receiver Server's ID: 618 See Section 3.1. 620 Pool handles and PE Identifier parameters: 622 Each listed pool handle is followed by a list of PE Identifier 623 parameters, indicating that the sender of this message is 624 taking ownership of the listed PEs in the pool. 626 3.11 PEER_ERROR message 628 This message is used by an ENRP server to report an operation error 629 to one of its peers. 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Type = 0xb |0|0|0|0|0|0|0|0| Message Length | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Sender Server's ID | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Receiver Server's ID | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 : Operation Error Parameter : 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Sender Server's ID: 645 See Section 3.1. 647 Receiver Server's ID: 649 See Section 3.1. 651 Operation Error Parameter: 653 This parameter, defined in [10], indicates the type of error(s) 654 being reported. 656 4. ENRP Operation Procedures 658 In this section, we discuss the operation procedures defined by ENRP. 659 An ENRP server MUST following these procedures when sending, 660 receiving, or processing ENRP messages. 662 Many of the Rserpool events call for both server-to-server and PU/ 663 PE-to-server message exchanges. Only the message exchanges and 664 activities between an ENRP server and its peer(s) are considered 665 within the ENRP scope and are defined in this document. 667 Procedures for exchanging messages between a PE/PU and ENRP servers 668 are defined in [1]. 670 4.1 Methods for Communicating amongst ENRP Servers 672 Within an Rserpool operation scope, ENRP servers need to communicate 673 with each other in order to exchange information such as the pool 674 membership changes, namespace data synchronization, etc. 676 Two types of communications are used amongst ENRP servers: 678 o point-to-point message exchange from one ENPR server to a specific 679 peer server, and 681 o announcements from one server to all its peer servers in the 682 operation scope. 684 Point-to-point communication is always carried out over an SCTP 685 association between the sending server and the receiving server. 687 Announcements are communicated out with one of the following two 688 approaches: 690 1. The sending server sends the announcement message to a well-known 691 RSERPOOL IP multicast channel that its peer servers subscribe to. 693 Note: Because IP multicast is not reliable, this approach does 694 not guarantee that all the peers will receive the announcement 695 message. Moreover, since IP multicast is not secure, this 696 approach cannot provide any security to the communication. 698 2. The sending server sends multiple copies of the announcement, one 699 to each of its peer servers, over a set of point-to-point SCTP 700 associations between the sending server and the peers. 702 This approach guarantees the reliable reception of the message. 703 When needed, data security can be achieved by using IP security 704 mechanisms such as IPsec [9] or TLS [8]. 706 In order to maximize inter-operability of ENRP servers, the following 707 rules MUST be followed: 709 1. At the startup time, a new ENRP server SHOULD make a decision on 710 whether it will enable IP multicast for ENRP announcements. This 711 decision should be based on factors such as the availability of 712 IP multicast and the security requirements from the user of 713 Rserpool. 715 2. If an ENRP server disables multicast, it then: 717 A. MUST NOT subscribe to the well-known server multicast 718 channel, i.e., it only receives peer announcements over SCTP 719 associations, and 721 B. MUST transmit all its out-going announcements over 722 point-to-point SCTP associations with its peers. 724 3. If an ENRP server enables itself to use multicast, it then: 726 A. MUST subscribe to the well-known server multicast channel to 727 ready itself for receiving peers' multicast announcements, 729 B. MUST also be prepared to receive peer announcements over 730 point-to-point SCTP associations from peers. 732 C. MUST track internally which peers are multicast-enabled and 733 which are not. Note: A peer is always assumed to be 734 multicast-disabled until/unless an ENRP message of any type 735 is received from that peer over the well-known server 736 multicast channel. 738 D. when sending out an announcement, MUST send a copy to the 739 well-known server multicast channel AND a copy to each of the 740 peers that are marked as multicast-disabled over a 741 point-to-point SCTP association. 743 4.2 ENRP Server Initialization 745 This section describes the steps a new ENRP server needs to take in 746 order to join the other existing ENRP servers, or to initiate the 747 namespace service if it is the first ENRP server started in the 748 operation scope. 750 4.2.1 Generate a Server Identifier 752 A new ENRP server MUST generate a non-zero, 32-bit server Id that is 753 as unique as possible in the operation scope and this server Id MUST 754 remain unchanged for the lifetime of the server. Normally, a good 755 32-bit random number will be good enough as the server Id ([12] 756 provides some information on randomness guidelines). 758 Note, there is a very remote chance (about 1 in 4 billion) that two 759 ENRP servers in an operation scope will generate the same server Id 760 and hence cause a server Id conflict in the pool. However, no severe 761 consequence of such a conflict has been identified. 763 4.2.2 Acquire Peer Server List 765 At startup, the ENRP server (initiating server) will first attempt to 766 learn all existing peer ENRP servers in the same operation scope, or 767 to determine that it is along in the scope. 769 The initiating server uses an existing peer server to bootstrap 770 itself into service. We call this peer server the mentor server. 772 4.2.2.1 Find the mentor server 774 If the initiating server is told about an existing peer server 775 through some administrative means (such as DNS query, configuration 776 database, startup scripts, etc), the initiating server SHOULD then 777 use this peer server as its mentor server and SHOULD skip the 778 remaining steps in this subsection. 780 If multiple existing peer servers are specified, the initiating 781 server SHOULD pick one of them as its mentor peer server, keep the 782 others as its backup mentor peers, and skip the remaining steps in 783 this subsection. 785 If no existing peer server is specified to the initiating server AND 786 if multicast is available in the operation scope, the following 787 mentor peer discovery procedures SHOULD be followed: 789 1. The initiating server SHOULD first join the well-known ENRP 790 server multicast channel. 792 2. Then the initiating server SHOULD send a PEER_PRESENCE message, 793 with the 'Reply_required' flag set, over the multicast channel. 794 Upon the reception of this PEER_PRESENCE message, a peer server 795 MUST send a PEER_PRESENCE, without the 'Reply_required' flag, 796 back to the initiating server. 798 3. When the first response to its original PEER_PRESENCE arrives, 799 the initiating server SHOULD take the sender of this received 800 response as its mentor peer server. This completes the discovery 801 of the mentor peer server. 803 If responses are also received from other peers (a likely event 804 when multiple peers exist in the operation scope at the time the 805 new server started), the initiating server SHOULD keep a list of 806 those responded as its backup mentor peers (see below). 808 4. If no response to its PEER_PRESENCE message are received after 809 TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat 810 steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After 811 that, if there is still no response, the initiating server MUST 812 assume that it is alone in the operation scope. 814 5. If the initiating server determined that it is alone in the 815 scope, it MUST skip the procedures in Section 4.2.2.2 and Section 816 4.2.3 and MUST consider its initialization completed and start 817 offering ENRP services. 819 Note, if multicast is not available (or not allowed for reasons such 820 as security concerns) in the operation scope, at least one peer 821 server MUST be specified to the initiating server through 822 administrative means, unless the initiation server is the first 823 server to start in the operation scope. 825 Note, if the administratively specified mentor peer(s) fails, the 826 initiating server SHOULD use the auto-discover procedure defined in 827 steps 1-5 above. 829 4.2.2.2 Request complete server list from mentor peer 831 Once the initiating server finds its mentor peer server (by either 832 discovery or administrative means), the initiating server MUST send a 833 PEER_LIST_REQUEST message to the mentor peer server to request a copy 834 of the complete server list maintained by the mentor peer (see 835 Section 4.9 for maintaining server list). 837 Upon the reception of this request, the mentor peer server SHOULD 838 reply with a PEER_LIST_RESPONSE message and include in the message 839 body all existing ENRP servers known by the mentor peer. 841 Upon the reception of the PEER_LIST_RESPONSE message from the mentor 842 peer, the initiating server MUST use the server information carried 843 in the message to initialize its own peer list. 845 However, if the mentor itself is in the process of startup and not 846 ready to provide a peer server list (for example, the mentor peer is 847 waiting for a response to its own PEER_LIST_REQUEST to another 848 server), it MUST reject the request by the initiating server and 849 respond with a PEER_LIST_RESPONSE message with the R flag set to '1', 850 and with no server information included in the response. 852 In the case where its PEER_LIST_REQUEST is rejected by the mentor 853 peer, the initiating server SHOULD either wait for a few seconds and 854 re-send the PEER_LIST_REQUEST to the mentor server, or if there is a 855 backup mentor peer available, select another mentor peer server and 856 send the PEER_LIST_REQUEST to the new mentor server. 858 4.2.3 Download ENRP Namespace Data from Mentor Peer 860 After a peer list download is completed, the initiating server MUST 861 request a copy of the current namespace data from its mentor peer 862 server, by taking the following steps: 864 1. The initiating server MUST first send a PEER_NAME_TABLE_REQUEST 865 message to the mentor peer, with W flag set to '0', indicating 866 that the entire namespace is requested. 868 2. Upon the reception of this message, the mentor peer MUST start a 869 download session in which a copy of the current namespace data 870 maintained by the mentor peer is sent to the initiating server in 871 one or more PEER_NAME_TABLE_RESPONSE messages (Note, the mentor 872 server may find it particularly desirable to use multiple 873 PEER_NAME_TABLE_RESPONSE messages to send the namespace when the 874 namespace is large, especially when forming and sending out a 875 single response containing a large namespace may interrupt its 876 other services). 878 If more than one PEER_NAME_TABLE_RESPONSE message are used during 879 the download, the mentor peer MUST use the M flag in each 880 PEER_NAME_TABLE_RESPONSE message to indicate whether this message 881 is the last one for the download session. In particular, the 882 mentor peer MUST set the M flag to '1' in the outbound 883 PEER_NAME_TABLE_RESPONSE if there is more data to be transferred 884 and MUST keep track of the progress of the current download 885 session. The mentor peer MUST set the M flag to '0' in the last 886 PEER_NAME_TABLE_RESPONSE for the download session and close the 887 download session (i.e., removing any internal record of the 888 session) after sending out the last message. 890 3. During the downloading, every time the initiating server receives 891 a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data 892 entries carried in the message into its local namespace database, 893 and then check whether or not this message is the last one for 894 the download session. 896 If the M flag is set to '1' in the just processed 897 PEER_NAME_TABLE_RESPONSE message, the initiating server MUST send 898 another PEER_NAME_TABLE_REQUEST message to the mentor peer to 899 request for the next PEER_NAME_TABLE_RESPONSE message. 901 4. When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE 902 message into its local namespace database, the initiating server 903 MUST handle each pool entry carried in the message using the 904 following rules: 906 A. If the pool does not exist in the local namespace, the 907 initiating server MUST creates the pool in the local 908 namespace and add the PE(s) in the pool entry to the pool. 910 When creating the pool, the initiation server MUST set the 911 overall member selection policy type of the pool to the 912 policy type indicated in the first PE. 914 B. If the pool already exists in the local namespace, but the 915 PE(s) in the pool entry is not currently a member of the 916 pool, the initiating server MUST add the PE(s) to the pool. 918 C. If the pool already exists in the local namespace AND the 919 PE(s) in the Pool entry is already a member of the pool, the 920 initiating server SHOULD replace the attributes of the 921 existing PE(s) with the new information. 923 5. When the last PEER_NAME_TABLE_RESPONSE message is received from 924 the mentor peer and unpacked into the local namespace, the 925 initialization process is completed and the initiating server 926 SHOULD start to provide ENRP services. 928 Under certain circumstances, the mentor peer itself may not be able 929 to provide a namespace download to the initiating server. For 930 example, the mentor peer is in the middle of initializing its own 931 namespace database, or it has currently too many download sessions 932 open to other servers. 934 In such a case, the mentor peer MUST reject the request by the 935 initiating server and respond with a PEER_NAME_TABLE_RESPONSE message 936 with the R flag set to '1', and with no pool entries included in the 937 response. 939 In the case where its PEER_NAME_TABLE_REQUEST is rejected by the 940 mentor peer, the initiating server SHOULD either wait for a few 941 seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server, 942 or if there is a backup mentor peer available, select another mentor 943 peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor 944 server. 946 A started namespace download session may get interrupted for some 947 reason. To cope with this, the initiating server SHOULD start a 948 timer every time it finishes sending a PEER_NAME_TABLE_REQUEST to its 949 mentor peer. If this timer expires without receiving a response from 950 the mentor peer, the initiating server SHOULD abort the current 951 download session and re-start a new namespace download with a backup 952 mentor peer, if one is available. 954 Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the 955 mentor peer has still more data to send, it SHOULD start a session 956 timer. If this timer expires without receiving another request from 957 the initiating server, the mentor peer SHOULD abort the session, 958 cleaning out any resource and record of the session. 960 4.3 Handle PE Registration 962 To register itself with the namespace, a PE sends a REGISTRATION 963 message to its home ENRP server. The format of REGISTRATION message 964 and rules of sending it are defined in [1]. 966 In the REGISTRATION message, the PE indicates the name of the pool it 967 wishes to join in a pool handle parameter, and its complete transport 968 information and any load control information in a PE parameter. 970 The ENRP server handles the REGISTRATION message according to the 971 following rules: 973 1. If the named pool does not exist in the namespace, the ENRP 974 server MUST creates a new pool with that name in the namespace 975 and add the PE to the pool as its first PE; 977 When a new pool is created, the overall member selection policy 978 of the pool MUST be set to the policy type indicated by the first 979 PE, the overall pool transport type MUST be set to the transport 980 type indicated by the PE, and the overall pool data/control 981 channel configuration MUST be set to what is indicated in the 982 Transport Use field of the User Transport parameter by the 983 registering PE. 985 2. If the named pool already exists in the namespace, but the 986 requesting PE is not currently a member of the pool, the ENRP 987 server will add the PE as a new member to the pool; 989 However, before adding the PE to the pool, the server MUST check 990 if the policy type, transport type, and transport usage indicated 991 by the registering PE is consistent with those of the pool. If 992 different, the ENRP server MUST either attempt to override the 993 PE's value(s) or to reject the registration if overriding is not 994 possible. 996 A. Inconsistent policy - If no additional policy-related 997 information are required to perform an override of pool 998 policy (e.g., overriding Least-used with Round-robin does not 999 require additional policy-related information), the ENRP 1000 server MUST replace the PE's policy type with the overall 1001 policy type of the pool. However, if additional policy 1002 information is required for the overriding (e.g., overriding 1003 Round-robin with Least-load will require the knowledge of the 1004 load factor of the PE), the ENRP server MUST reject the 1005 registration. 1007 B. Inconsistent transport type - The ENRP server MUST reject the 1008 registration. 1010 C. Inconsistent data/control configuration - If the overall pool 1011 configuration is "DATA ONLY", and the registering PE 1012 indicates "CONTORL plus DATA", the ENRP server SHOULD accept 1013 the registration but warn the PE that control channel cannot 1014 be used. If the pool configuration is "CONTROL plus DATA" 1015 and the PE indicates "DATA ONLY", the ENRP server MUST reject 1016 the registration. 1018 3. If the named pool already exists in the namespace AND the 1019 requesting PE is already a member of the pool, the ENRP server 1020 SHOULD consider this as a re-registration case. The ENRP server 1021 MUST perform the same tests on policy, transport type, transport 1022 use, as described above. If the re-registration is accepted 1023 after the test, the ENRP Server SHOULD replace the attributes of 1024 the existing PE with the information carried in the received 1025 REGISTRATION message. 1027 4. After accepting the registration, the ENRP server MUST assign 1028 itself the owner of this PE. If this is a re-registration, the 1029 ENRP server MUST take over ownership of this PE regardless of 1030 whether the PE was previously owned by this server or by another 1031 server. 1033 5. The ENRP server may reject the registration due to reasons such 1034 as invalid values, lack of resource, authentication failure, etc. 1036 In all above cases, the ENRP server MUST reply to the requesting PE 1037 with a REGISTRATION_RESPONSE message. If the registration is 1038 accepted, the ENRP server MUST set the 'R' flag in the 1039 REGISTRATION_RESPONSE to '0'. If the registration is rejected, the 1040 ENRP server MUST indicate the rejection by setting the 'R' flag in 1041 the REGISTRATION_RESPONSE to '1'. 1043 If the registration is rejected, the ENRP server SHOULD include the 1044 proper error cause(s) in the REGISTRATION_RESPONSE message. 1046 If the registration is granted but with an override of some PE's 1047 original values, in the REGISTRATION_RESPONSE message the ENRP server 1048 SHOULD include the proper error cause(s) so that the PE can be warned 1049 about the overriding and be informed about the new value(s). 1051 If the registration is granted (either a new registration or a 1052 re-registration case), the ENRP server MUST assign itself to be the 1053 home ENRP server of the PE, i.e., to "own" the PE. 1055 Implementation note: for better performance, the ENRP server may 1056 find it both efficient and convenient to internally maintain two 1057 separate PE lists or tables - one is for the PEs that are "owned" 1058 by the ENRP server and the other for all the PEs owned by its 1059 peer(s). 1061 Moreover, if the registration is granted, the ENRP server MUST take 1062 the namespace update action as described in Section 4.6 to inform its 1063 peers about the change just made. If the registration is denied, no 1064 message will be sent to its peers. 1066 4.3.1 Rules on PE Re-registration 1068 A PE may re-register itself to the namespace with a new set of 1069 attributes in order to, for example, extend its registration life, 1070 change its load factor value, etc. 1072 A PE may modify its load factor value at any time via 1073 re-registration. Based on the number of PEs in the pool and the 1074 pool's overall policy type, this operation allows the PE to 1075 dynamically control its share of inbound messages received by the 1076 pool (also see Section ???? in [1] for more on load control). 1078 Moreover, when re-registering, the PE MUST NOT change its policy 1079 type. The server MUST reject the re-registration if the PE attempt 1080 to change its policy type. In the rejection, the server SHOULD 1081 attach an error code "Pooling Policy Inconsistent". 1083 Regardless whether it is the current owner of the PE, if the 1084 re-registration is granted to the PE, the ENRP server MUST assign 1085 itself to be the new home ENRP server of the PE. 1087 Moreover, if the re-registration is granted, the ENRP server MUST 1088 take the namespace update action as described in Section 4.6 to 1089 inform its peers about the change just made. If the re-registration 1090 is denied, no message will be sent to its peers. 1092 4.4 Handle PE De-registration 1094 To remove itself from a pool, a PE sends a DEREGISTRATION message to 1095 its home ENRP server. The complete format of DEREGISTRATION message 1096 and rules of sending it are defined in [1]. 1098 In the DEREGISTRATION message the PE indicates the name of the pool 1099 it belongs to in a pool handle parameter and provides its PE 1100 identifier. 1102 Upon receiving the message, the ENRP server SHALL remove the PE from 1103 its namespace. Moreover, if the PE is the last one of the named 1104 pool, the ENRP server will remove the pool from the namespace as 1105 well. 1107 If the ENRP server fails to find any record of the PE in its 1108 namespace, it SHOULD consider the de-registration granted and 1109 completed. 1111 The ENRP server may reject the de-registration request for various 1112 reasons, such as invalid parameters, authentication failure, etc. 1114 In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE 1115 message to the PE. If the de-registration is rejected, the ENRP 1116 server MUST indicate the rejection by including the proper Operation 1117 Error parameter. 1119 It should be noted that de-registration does not stop the PE from 1120 sending or receiving application messages. 1122 Once the de-registration request is granted AND the PE removed from 1123 its local copy of the namespace, the ENRP server MUST take the 1124 namespace update action described in Section 4.6 to inform its peers 1125 about the change just made. Otherwise, NO message SHALL be send to 1126 its peers. 1128 4.5 Pool Handle Translation 1130 A PU uses the pool handle translation service of an ENRP server to 1131 resolve a pool handle to a list of accessible transport addresses of 1132 the member PEs of the pool. 1134 This requires the PU to send a NAME_RESOLUTION message to its home 1135 ENRP server and in the NAME_RESOLUTION message specify the pool 1136 handle to be translated in a Pool Handle parameter. Complete 1137 definition of the NAME_RESOLUTION message and the rules of sending it 1138 are defined in [1]. 1140 An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests 1141 from PUs either over an SCTP association on the well-know SCTP port, 1142 or over a TCP connection on the well-know TCP port. 1144 Upon reception of the NAME_RESOLUTION message, the ENRP server MUST 1145 first look up the pool handle in its namespace. If the pool exits, 1146 the home ENRP server MUST compose and send back a 1147 NAME_RESOLUTION_RESPONSE message to the requesting PU. 1149 In the response message, the ENRP server SHOULD list all the PEs 1150 currently registered in this pool, in a list of PE parameters. The 1151 ENRP server MUST also include a pool member selection policy 1152 parameter to indicate the overall member selection policy for the 1153 pool, if the current pool member selection policy is not round-robin 1154 (if the overall policy is round-Robin, this parameter MAY be 1155 omitted?). 1157 If the named pool does not exist in the namespace, the ENRP server 1158 MUST respond with a NAME_UNKNOWN message. 1160 The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN 1161 messages and the rules of receiving them are defined in [1]. 1163 4.6 Server Namespace Update 1165 This includes a set of update operations used by an ENRP server to 1166 inform its peers when its local namespace is modified, e.g., addition 1167 of a new PE, removal of an existing PE, change of pool or PE 1168 properties. 1170 4.6.1 Announcing Addition or Update of PE 1172 When a new PE is granted registration to the namespace or an existing 1173 PE is granted a re-registration, the home ENRP server uses this 1174 procedure to inform all its peers. 1176 This is an ENRP announcement and is sent to all the peer of the home 1177 ENRP server. See Section 4.1 on how announcements are sent. 1179 An ENRP server MUST announce this update to all its peers in a 1180 PEER_NAME_UPDATE message with the Update Action field set to ADD_PE, 1181 indicating the addition of a new PE or the modification of an 1182 existing PE. The complete new information of the PE and the pool its 1183 belongs to MUST be indicated in the message with a PE parameter and a 1184 Pool Handle parameter, respectively. 1186 The home ENRP server SHOULD fill in its server Id in the Sender 1187 Server's ID field and leave the Receiver Server's ID blank (i.e., all 1188 0's). 1190 When a peer receives this PEER_NAME_UPDATE message, it MUST take the 1191 following actions: 1193 1. If the named pool indicated by the pool handle does not exist in 1194 its local copy of the namespace, the peer MUST create the named 1195 pool in its local namespace and add the PE to the pool as the 1196 first PE. It MUST then copy in all other attributes of the PE 1197 carried in the message. 1199 When the new pool is created, the overall member selection policy 1200 of the pool MUST be set to the policy type indicated by the PE. 1202 2. If the named pool already exists in the peer's local copy of the 1203 namespace AND the PE does not exist, the peer MUST add the PE to 1204 the pool as a new PE and copy in all attributes of the PE carried 1205 in the message. 1207 3. If the named pool exists AND the PE is already a member of the 1208 pool, the peer MUST replace the attributes of the PE with the new 1209 information carried in the message. 1211 4.6.2 Announcing Removal of PE 1213 When an existing PE is granted de-registration or is removed from its 1214 namespace for some other reasons (e.g., purging an unreachable PE, 1215 see Section 4.7), the ENRP server MUST uses this procedure to inform 1216 all its peers about the change just made. 1218 This is an ENRP announcement and is sent to all the peer of the home 1219 ENRP server. See Section 4.1 on how announcements are sent. 1221 An ENRP server MUST announce the PE removal to all its peers in a 1222 PEER_NAME_UPDATE message with the Update Action field set to DEL_PE, 1223 indicating the removal of an existing PE. The complete information 1224 of the PE and the pool its belongs to MUST be indicated in the 1225 message with a PE parameter and a Pool Handle parameter, 1226 respectively. 1228 [editor's note: only the pool handle and the PE's id are needed, it 1229 should reduce the size of the message] 1230 The sending server MUST fill in its server ID in the Sender Server's 1231 ID field and leave the Receiver Server's ID blank (i.e., set to all 1232 0's). 1234 When a peer receives this PEER_NAME_UPDATE message, it MUST first 1235 find pool and the PE in its own namespace, and then remove the PE 1236 from its local namespace. If the removed PE is the last one in the 1237 pool, the peer MUST also delete the pool from its local namespace. 1239 If the peer fails to find the PE or the pool in its namespace, it 1240 SHOULD take no further actions. 1242 4.7 Detecting and Removing Unreachable PE 1244 Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE 1245 Notification, see section 10.2 of [7]), the PU SHOULD send an 1246 ENDPOINT_UNREACHABLE message to its home ENRP server. The message 1247 SHOULD contain the pool handle and the PE Id of the unreachable PE. 1249 Upon the reception of an ENDPOINT_UNREACHABLE message, a server MUST 1250 immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the 1251 PE in question. If this ENDPOINT_KEEP_ALIVE fails (e.g., it results 1252 in an SCTP SEND.FAILURE notification), the ENRP server MUST consider 1253 the PE as truly unreachable and MUST remove the PE from its namespace 1254 and take actions described in Section 4.6.2. 1256 If the ENDPOINT_UNREACHABLE message is transmitted successfully to 1257 the PE, the ENRP server MUST retain the PE in its namespace. 1258 Moreover, the server SHOULD keep a counter to record how many 1259 ENDPOINT_UNREACHABLE messages it has received reporting reachability 1260 problem relating to this PE. If the counter exceeds the protocol 1261 threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove the PE 1262 from its namespace and take actions described in Section 4.6.2. 1264 Optionally, an ENRP server may also periodically send point-to-point 1265 ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP 1266 server in order to check their reachability status. If the send of 1267 ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the 1268 PE as unreachable and MUST remove the PE from its namespace and take 1269 actions described in Section 4.6.2. Note, if an ENRP server owns a 1270 large number of PEs, the implementation should pay attention not to 1271 flood the network with bursts of ENDPOINT_KEEP_ALIVE messages. 1272 Instead, the implementation should try to smooth out the 1273 ENDPOINT_KEEP_ALIVE message traffic over time. 1275 The complete definition and rules of sending ENDPOINT_UNREACHABLE and 1276 receiving ENDPOINT_KEEP_ALIVE messages are described in [1]. 1278 4.8 Helping PE and PU to Discover Home ENRP Server 1280 At its startup time, or whenever its current home ENRP server is not 1281 providing services, a PE or PU will attempt to find a new home 1282 server. For this reason, the PE or PU will need to maintain a list 1283 of currently available ENRP servers in its scope. 1285 To help the PE or PU maintaining this list, an ENRP server, if it is 1286 enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE 1287 message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP 1288 multicast channel. And in the SERVER_ANNOUNE message the ENRP server 1289 SHOULD include all the transport addresses available for ASAP 1290 communications. If the ENRP server only supports SCTP for ASAP 1291 communications, the transport information MAY be omitted in the 1292 SERVER_ANNOUNCE message. 1294 For the complete procedure of this, see Section 3.6?? in [1]. 1296 4.9 Maintaining Peer List and Monitoring Peer Status 1298 An ENRP server MUST keep an internal record on the status of each of 1299 its known peers. This record is referred to as the server's "peer 1300 list" 1302 4.9.1 Discovering New Peer 1304 If a message of any type is received from a previously unknown peer, 1305 the ENRP server MUST consider this peer a new peer in the operation 1306 scope and add it to the peer list. 1308 The ENRP server MUST send a PEER_PRESENCE message with the 1309 Reply-required flag set to '1' to the source address found in the 1310 arrived message. This will force the new peer to reply with its own 1311 PEER_PRESENCE containing its full server information (see Section 1312 3.1). 1314 [editor's note: should we ask for a peer list from the new peer? 1315 this may help mending two split networks.] 1317 4.9.2 Server Sending Heartbeat 1319 Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its 1320 continued presence to all its peer with a PEER_PRESENCE message. In 1321 the PEER_PRESENCE message, the ENRP server MUST set the 1322 'Replay_required' flag to '0', indicating that no response is 1323 required. 1325 The arrival of this periodic PEER_PRESENCE message will cause all its 1326 peers to update their internal variable "peer.last.heard" for the 1327 sending server (see Section 4.9.3 for more details). 1329 4.9.3 Detecting Peer Server Failure 1331 An ENRP server MUST keep an internal variable "peer.last.heard" for 1332 each of its known peers and the value of this variable MUST be 1333 updated to the current local time every time a message of any type 1334 (point-to-point or announcement) is received from the corresponding 1335 peer. 1337 If a peer has not been heard for more than MAX-TIME-LAST-HEARD 1338 seconds, the ENRP server MUST immediately send a point-to-point 1339 PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer. 1341 If the send fails or the peer does not reply after 1342 MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer 1343 server dead and SHOULD initiate the takeover procedure defined in 1344 Section 4.10. 1346 4.10 Taking-over a Failed Peer Server 1348 In the following descriptions, We call the ENRP server that detects 1349 the failed peer server and initiates the take-over the "initiating 1350 server" and the failed peer server the "target server." 1352 4.10.1 Initiate Server Take-over Arbitration 1354 The initiating server SHOULD first start a take-over arbitration 1355 process by announcing a PEER_INIT_TAKEOVER message to all its peer 1356 servers. See Section 4.1 on how announcements are sent. In the 1357 message, the initiating server MUST fill in the Sender Server's ID 1358 and Target Server's ID. 1360 After announcing the PEER_INIT_TAKEOVER message, the initiating 1361 server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_ 1362 of its known peers, except of the target server. [editor's note: how 1363 long should it wait?] 1365 Each of the peer servers that receives the PEER_INIT_TAKEOVER message 1366 from the initiating server SHOULD take the following actions: 1368 1. If the peer server finds that itself is the target server 1369 indicated in the PEER_INIT_TAKEOVER message, it MUST immediately 1370 announce a PEER_PRESENCE message to all its peer ENRP servers in 1371 an attempt to stop this take-over process. This indicates a 1372 false failure detection case by the initiating server. 1374 2. If the peer server finds that itself has already started its own 1375 take-over arbitration process on the same target server, it MUST 1376 perform the following arbitration: 1378 A. if the peer's server ID is smaller in value than the Sender 1379 Server's ID in the arrived PEER_INIT_TAKEOVER message, the 1380 peer server SHOULD immediately abort its own take-over 1381 attempt. Moreover, the peer SHOULD mark the target server as 1382 "not active" on its internal peer list so that its status 1383 will no longer be monitored by the peer, and reply the 1384 initiating server with a PEER_INIT_TAKEOVER_ACK message. 1386 B. Otherwise, the peer MUST ignore the PEER_INIT_TAKEOVER 1387 message and take no action. 1389 3. If the peer finds that it is neither the target server nor is in 1390 its own take-over process, the peer SHOULD: a) mark the target 1391 server as "not active" on its internal peer list so that its 1392 status will no longer be monitored by this peer, and b) reply to 1393 the initiating server with a PEER_INIT_TAKEOVER_ACK message. 1395 Once the initiating server has received PEER_INIT_TAKEOVER_ACK 1396 message from _all_ of its currently known peers (except for the 1397 target server), it SHOULD consider that it has won the arbitration 1398 and SHOULD proceed to complete the take-over, following the steps 1399 described in Section 4.10.2. 1401 However, if it receives a PEER_PRESENCE from the target server at any 1402 point in the arbitration process, the initiating server SHOULD 1403 immediately abort the take-over process and mark the status of the 1404 target server as "active". 1406 4.10.2 Take-over Target Peer Server 1408 The initiating ENRP server SHOULD first send, via an announcement, a 1409 PEER_TAKEOVER_SERVER message to inform all its active peers that the 1410 take-over is enforced. The target server's ID MUST be filled in the 1411 message. The initiating server SHOULD then remove the target server 1412 from its internal peer list. 1414 [editor's note: peers should remove the target server from their list 1415 upon receiving this message. Do we really need this message? we can 1416 consolidate this with the ownership_change msg.] 1418 Then it SHOULD examine its local copy of the namespace and claim 1419 ownership of each of the PEs originally owned by the target server, 1420 by following these steps: 1422 1. mark itself as the home ENRP server of each of the PEs originally 1423 owned by the target server; 1425 2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the 1426 PEs. This will trigger the PE to adopt the initiating sever as 1427 its new home ENRP server; 1429 3. after claiming the ownership of all the PEs originally owned by 1430 the target server, announce the ownership changes of all the 1431 affected PEs in a PEER_OWNERSHIP_CHANGE message to all the 1432 currently known peers. Note, if the list of affected PEs is 1433 long, the sender MAY announce the ownership changes in multiple 1434 PEER_OWNERSHIP_CHANGE messages. 1436 When a peer receives the PEER_OWNERSHIP_CHANGE message from the 1437 initiating server, it SHOULD find each of the reported PEs in its 1438 local copy of the namespace and update the PE's home ENRP server to 1439 be the sender of the message (i.e., the initiating server). 1441 4.11 Namespace Data Auditing and Re-synchronization 1443 Message losses or certain temporary breaks in network connectivity 1444 may result in data inconsistency in the local namespace copy of some 1445 of the ENRP servers in an operation scope. Therefore, each ENRP 1446 server in the operation scope SHOULD periodically verify that its 1447 local copy of namespace data is still in sync with that of its peers. 1449 This section defines the auditing and re-synchronization procedures 1450 for an ENRP server to maintain its namespace data consistency. 1452 4.11.1 Auditing Procedures 1454 The auditing of namespace consistency is based on the following 1455 procedures: 1457 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1458 integer internal variable) for each of its known peers and for 1459 itself. For an ENRP server with 'k' known peers, we denote these 1460 internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ..., 1461 "pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE 1462 checksum. The definition and detailed algorithm for calculating 1463 these PE checksum variables are given in Section 4.11.2. 1465 2. Each time an ENRP server sends out a PEER_PRESENCE, it SHOULD 1466 include in the message its current PE checksum (i.e., 1467 "pe.checksum.pr0"). 1469 3. When an ENRP server (server A) receives a PE checksum (carried in 1470 an arrived PEER_PRESENCE) from a peer ENRP server (server B), 1471 server A SHOULD compare the PE checksum found in the 1472 PEER_PRESENCE with its own internal PE checksum of server B 1473 (i.e., "pe.checksum.prB"). 1475 4. If the two values match, server A will consider that there is no 1476 namespace inconsistency between itself and server B and should 1477 take no further actions. 1479 5. If the two values do NOT match, server A SHOULD consider that 1480 there is a namespace inconsistency between itself and server B 1481 and a re-synchronization process SHOULD be carried out 1482 immediately with server B (see Section 4.11.3). 1484 4.11.2 PE Checksum Calculation Algorithm 1486 When an ENRP server (server A) calculate an internal PE checksum for 1487 a peer (server B), it MUST use the following algorithm. 1489 Let us assume that in server A's internal namespace there are 1490 currently 'M' PEs that are owned by server B. Each of the 'M' PEs 1491 will then contribute to the checksum calculation with the following 1492 byte block: 1494 0 1 2 3 1495 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 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 : Pool handle string of the pool the PE belongs (padded with : 1498 : zeros to next 32-bit word boundary if needed) : 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | PE Id (4 octets) | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 Note, these are not TLVs. This byte block gives each PE a unique 1504 byte pattern in the scope. The 32-bit PE checksum for server B 1505 "pe.checksum.prB" is then calculated over the byte blocks contributed 1506 by the 'M' PEs one by one. 1508 Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") 1509 in the same fashion, using the byte blocks of all the PEs owned by 1510 itself. 1512 Note, whenever an ENRP finds that its internal namespace has changed 1513 (e.g., due to PE registration/deregistration, receiving peer updates, 1514 removing failed PEs, downloading namespace pieces from a peer, etc.), 1515 it MUST immediately update all its internal PE checksums that are 1516 affected by the change. 1518 Implementation Note: when the internal namespace changes (e.g., a new 1519 PE added or an existing PE removed), an implementation needs not to 1520 re-calculate the affected PE checksum; it should instead simply 1521 update the checksum by adding or subtracting the byte block of the 1522 corresponding PE from the previous checksum value. 1524 4.11.3 Re-synchronization Procedures 1526 Once an ENRP server determines that there is inconsistency between 1527 its local namespace data and a peer's namespace data with regarding 1528 to the PEs owned by that peer, it SHOULD perform the following steps 1529 to re-synchronize the data: 1531 1. The ENRP server SHOULD first "mark" every PE it knows about that 1532 is owned by the peer in its local namespace database; 1534 2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST 1535 message with W flag set to '1' to the peer to request a complete 1536 list of PEs owned by the peer; 1538 3. Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag 1539 set to '1', the peer server SHOULD immediately respond with a 1540 PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned 1541 by the peer. 1543 4. Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP 1544 server SHOULD transfer the PE entries carried in the message into 1545 its local namespace database. If an PE entry being transferred 1546 already exists in its local database, the ENRP server MUST 1547 replace the entry with the copy found in the message and remove 1548 the "mark" from the entry. 1550 5. After transferring all the PE entries from the received 1551 PEER_NAME_TABLE_RESPONSE message into its local database, the 1552 ENRP server SHOULD check whether there are still PE entries that 1553 remain "marked" in its local namespace. If so, the ENRP server 1554 SHOULD silently remove those "marked" entries. 1556 Note, similar to what is described in Section 4.2.3, the peer may 1557 reject the PEER_NAME_TABLE_REQUEST or use more than one 1558 PEER_NAME_TABLE_RESPONSE message to respond. 1560 4.12 Handling Unrecognized Message or Unrecognized Parameter 1562 When an ENRP server receives an ENRP message with an unknown message 1563 type or a message of known type that contains an unknown parameter, 1564 it SHOULD handle the unknown message or the unknown parameter 1565 according to the unrecognized message and parameter handling rules 1566 defined in Sections 3 and 4 in [10]. 1568 According to the rules, if an error report to the message sender is 1569 needed, the ENRP server that discovered the error SHOULD send back an 1570 ENRP_ERROR message with proper error cause code. 1572 5. Variables and Thresholds 1574 5.1 Variables 1576 peer.last.heard - the local time that a peer server was last heard 1577 (via receiving either a multicast or point-to-point message from 1578 the peer). 1580 pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server 1581 keeps for a peer. A separate PE checksum is kept for each of its 1582 known peers as well as for itself. 1584 5.2 Thresholds 1586 MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will 1587 make to contact an ENRP server (Default=3 times). 1589 TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will 1590 wait for a response from an ENRP server (Default=5 seconds). 1592 PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a 1593 heartbeat message to all its known peers. (Default=30 secs.) 1595 SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a 1596 SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) 1598 MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server 1599 will wait before considering a silent peer server potentially 1600 dead. (Default=61 secs.) 1602 MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message 1603 sender will wait for a response after sending out a message. 1604 (Default=5 secs.) 1606 MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a 1607 PE that an ENRP server will allow before purging this PE from the 1608 namespace. (Default=3) 1610 6. Security Considerations 1612 Threats Introduced by Rserpool and Requirements for Security in 1613 Response to Threats [11] describes the threats to the Rserpool 1614 architecture in detail and lists the security requirements in 1615 response to each threat. From the threats described in this 1616 document, the security services required for the Rserpool protocol 1617 are enumerated below. 1619 Threat 1) PE registration/deregistration flooding or spoofing 1620 ----------- 1621 Security mechanism in response: ENRP server authenticates the PE 1623 Threat 2) PE registers with a malicious ENRP server 1624 ----------- 1625 Security mechanism in response: PE authenticates the ENRP server 1627 Threat 1 and 2 taken together results in mutual authentication of the 1628 ENRP server and the PE. 1630 Threat 3) Malicious ENRP server joins the ENRP server pool 1631 ----------- 1632 Security mechanism in response: ENRP servers mutually authenticate 1634 Threat 4) A PU communicates with a malicious ENRP server for name 1635 resolution 1636 ----------- 1637 Security mechanism in response: The PU authenticates the ENRP server 1639 Threat 5) Replay attack 1640 ----------- 1641 Security mechanism in response: Security protocol which has 1642 protection from replay attacks 1644 Threat 6) Corrupted data which causes a PU to have misinformation 1645 concerning a pool handle resolution 1646 ----------- 1647 Security mechanism in response: Security protocol which supports 1648 integrity protection 1650 Threat 7) Eavesdropper snooping on namespace information 1651 ----------- 1652 Security mechanism in response: Security protocol which supports data 1653 confidentiality 1655 Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP 1656 server 1657 ----------- 1658 Security mechanism in response: ASAP must control the number of 1659 endpoint unreachable messages transmitted from the PU to the ENRP 1660 server. 1662 Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the 1663 ENRP server 1664 ----------- 1665 Security mechanism in response: ENRP server must control the number 1666 of Endpoint_KeepAlive messages to the PE 1668 To summarize the threats 1-7 require security mechanisms which 1669 support authentication, integrity, data confidentiality, protection 1670 from replay attacks. 1672 For Rserpool we need to authenticate the following: 1674 PU <---- ENRP Server (PU authenticates the ENRP server) 1675 PE <----> ENRP Server (mutual authentication) 1676 ENRP server <-----> ENRP Server (mutual authentication) 1678 We do not define any new security mechanisms specifically for 1679 responding to threats 1-7. Rather we use existing IETF security 1680 protocols to provide the security services required. TLS supports 1681 all these requirements and MUST be implemented. The 1682 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a 1683 minimum by implementers of TLS for Rserpool. For purposes of 1684 backwards compatibility, ENRP SHOULD support 1685 TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any 1686 other ciphersuite. 1688 Threat 8 requires the ASAP protocol to limit the number of 1689 Endpoint_Unreachable messages (see Section 3.5??? in [1]) to the ENRP 1690 server. 1692 Threat 9 requires the ENRP protocol to limit the number of 1693 Endpoint_KeepAlive messages to the PE (see Section x.y???). 1695 6.1 Implementing Security Mechanisms 1697 ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must 1698 support mutual authentication. ENRP servers must support mutual 1699 authentication among themselves. PUs MUST authenticate ENRP servers. 1701 ENRP servers and PEs SHOULD possess a site certificate whose subject 1702 corresponds to their canonical hostname. PUs MAY have certificates 1703 of their own for mutual authentication with TLS, but no provisions 1704 are set forth in this document for their use. All Rserpool elements 1705 that support TLS MUST have a mechanism for validating certificates 1706 received during TLS negotiation; this entails possession of one or 1707 more root certificates issued by certificate authorities (preferably 1708 well-known distributors of site certificates comparable to those that 1709 issue root certificates for web browsers). 1711 Implementations MUST support TLS with SCTP as described in RFC3436 1712 [8] or TLS over TCP as described in RFC2246 [6]. When using TLS/SCTP 1713 we must ensure that RSerPool does not use any features of SCTP that 1714 are not available to an TLS/SCTP user. This is not a difficult 1715 technical problem, but simply a requirement. When describing an API 1716 of the RSerPool lower layer we have also to take into account the 1717 differences between TLS and SCTP. 1719 7. Acknowledgements 1721 The authors wish to thank John Loughney, Lyndon Ong, and many others 1722 for their invaluable comments. 1724 8. References 1726 8.1 Normative References 1728 [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1729 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-09 1730 (work in progress), June 2004. 1732 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 1733 J. and M. Stillman, "Requirements for Reliable Server Pooling", 1734 RFC 3237, January 2002. 1736 [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, 1737 "Architecture for Reliable Server Pooling", 1738 draft-ietf-rserpool-arch-07 (work in progress), October 2003. 1740 [4] Bradner, S., "The Internet Standards Process -- Revision 3", 1741 BCP 9, RFC 2026, October 1996. 1743 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1744 Levels", BCP 14, RFC 2119, March 1997. 1746 [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1747 2246, January 1999. 1749 [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1750 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 1751 "Stream Control Transmission Protocol", RFC 2960, October 2000. 1753 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC 1754 3436, December 2002. 1756 [9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On 1757 the Use of Stream Control Transmission Protocol (SCTP) with 1758 IPsec", RFC 3554, July 2003. 1760 [10] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate 1761 Server Access Protocol (ASAP) and Endpoint Name Resolution 1762 (ENRP) common parameters document", 1763 draft-ietf-rserpool-common-param-06 (work in progress), June 1764 2004. 1766 [11] Stillman, M., "Threats Introduced by Rserpool and Requirements 1767 for Security in Response to Threats", 1768 draft-ietf-rserpool-threats-02 (work in progress), Sept 2003. 1770 8.2 Informative References 1772 [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1773 Recommendations for Security", RFC 1750, December 1994. 1775 Authors' Addresses 1777 Qiaobing Xie 1778 Motorola, Inc. 1779 1501 W. Shure Drive, 2-F9 1780 Arlington Heights, IL 60004 1781 US 1783 Phone: +1-847-632-3028 1784 EMail: qxie1@email.mot.com 1786 Randall R. Stewart 1787 Cisco 1788 24 Burning Bush Trail 1789 Crystal Lake, IL 60012 1790 US 1792 Phone: +1-815-477-2127 1793 EMail: rrs@cisco.com 1795 Maureen Stillman 1796 Nokia 1797 127 W. State Street 1798 Ithaca, NY 14850 1799 US 1801 Phone: +1 607 273 0724 62 1802 EMail: maureen.stillman@nokia.com 1804 Intellectual Property Statement 1806 The IETF takes no position regarding the validity or scope of any 1807 Intellectual Property Rights or other rights that might be claimed to 1808 pertain to the implementation or use of the technology described in 1809 this document or the extent to which any license under such rights 1810 might or might not be available; nor does it represent that it has 1811 made any independent effort to identify any such rights. Information 1812 on the procedures with respect to rights in RFC documents can be 1813 found in BCP 78 and BCP 79. 1815 Copies of IPR disclosures made to the IETF Secretariat and any 1816 assurances of licenses to be made available, or the result of an 1817 attempt made to obtain a general license or permission for the use of 1818 such proprietary rights by implementers or users of this 1819 specification can be obtained from the IETF on-line IPR repository at 1820 http://www.ietf.org/ipr. 1822 The IETF invites any interested party to bring to its attention any 1823 copyrights, patents or patent applications, or other proprietary 1824 rights that may cover technology that may be required to implement 1825 this standard. Please address the information to the IETF at 1826 ietf-ipr@ietf.org. 1828 Disclaimer of Validity 1830 This document and the information contained herein are provided on an 1831 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1832 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1833 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1834 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1835 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1836 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1838 Copyright Statement 1840 Copyright (C) The Internet Society (2004). This document is subject 1841 to the rights, licenses and restrictions contained in BCP 78, and 1842 except as set forth therein, the authors retain all their rights. 1844 Acknowledgment 1846 Funding for the RFC Editor function is currently provided by the 1847 Internet Society.