idnits 2.17.1 draft-xie-rserpool-enrp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1708 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 21 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([ASAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'SCTP' is defined on line 1584, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) -- No information found for draft-stewart-rserpool-asap - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ASAP' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 November 15,2000 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 all 14 provisions of Section 10 of RFC 2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 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 Aggregate Server Access Protocol (ASAP) [ASAP]. ENRP when 29 combined with ASAP provdes a high availablitity data transfer mechanism 30 over IP networks. ASAP uses a name-based addressing model which 31 isolates a logical communication endpoint from its IP address(es), 32 thus effectively eliminating the binding between the communication 33 endpoint and its physical IP address(es) which normally constitutes a 34 single point of failure. 36 The high availablitity server pooling is gained by combining the two parts, 37 namely ASAP and the Endpoint Name Resolution Part (ENRP). ASAP 38 provides the user interface for name to address translation, load 39 sharing management, and fault management. ENRP defines the fault 40 tolerant name translation service. 42 Table Of Contents 44 46 1. Introduction 48 ENRP is designed to provide a fully distributed fault-tolerant 49 real-time translation service that maps a name to a set of transport 50 addresses pointing to a specific group of networked communication 51 endpoints registered under that name. ENRP employs a client-server 52 model with which an ENRP server will respond to the name translation 53 service requests from endpoint clients on both the local host and 54 remote hosts. 56 This document defines ENRP client-server interface and the 57 ENRP server functionalities, including the establishment and 58 management of a fully distributed fault-tolerant endpoint name space. 60 1.1 Motivation 62 In this section, we will discuss the motivation for developing 63 ASAP. Our discussion will be focused on the analysis of the 64 inadequateness of two existing technologies, namely CORBA and DNS, 65 in providing solutions to fault-tolerance design of IP distributed 66 applications. 68 1.1.1 CORBA and Its Limitations 70 Often referred to as a Distributed Processing Environment (DPE), 71 CORBA was mainly desinged to provide location transparency for 72 distributed applications. However, the following limitations may exist 73 when applying CORBA to the design of real time fault-tolerant system: 75 1) CORBA is traditionally weak in fault tolerance. The recent 76 development of a high availablitity version of CORBA by OMG is perhaps 77 a step in the right direction towards fixing this 78 weakness. Nevertheless, the maturity, implementablity, and 79 real-time performance of the design is yet to be proven. 81 [Editor's Note: the fault tolerance mechanism being developed by 82 OMG for CORBA bears quite some similarities to ASAP.] 84 2) CORBA's distribution model encourages an object-based view, 85 i.e., each communication endpoint is normally an object. We 86 consider this kind of granularity too fine to be efficient and 87 effective for designing real-time fault-tolerant applications. 89 3) CORBA in general has a large signature that makes the use of it a 90 challenge in real-time environments. Small devices with limited 91 memory and CPU resource (e.g., H323 or SIP terminals) will find 92 CORBA hard to fit in. 94 4) CORBA uses TCP as its transport (Note, some effort is currently 95 underway to separate CORBA from its transport). This makes CORBA 96 suffer from the same limitations of TCP in terms of real-time and 97 fault-tolerance performance. 99 5) CORBA has long lacked easily usable support for the asynchronous 100 communication model, and this may be an issue in many 101 applications. An apparently improved API for asynchronous 102 communication has been added to the CORBA standards only recently, 103 and many, if not most, CORBA implementations still do not support 104 it. There is as yet insufficient user experience with it to make 105 conclusions regarding this new feature's usability. 107 1.1.2 DNS and Its Limitations 109 Undoubtedly DNS is the best-known and proven IP namespace mechanism. 110 However, namespace function alone does NOT provide real time 111 fault-tolerance solution. Other mechanisms and procedures, such as 112 server process failure detection, back-up server control and 113 selection, fast fail-over/switch-over, load balancing, etc., also play 114 crucial roles. These functions are supported by ASAP but not by DNS 115 DNS provides a loose binding where as ASAP and ENRP are designed to 116 provide a tight binding. 118 As will be further elaborated later in this document, the fault 119 tolerant design for server pools is made up in two parts, namely ASAP 120 and ENRP, where ENRP defines a light-weight yet highly efficient 121 namespace mechanism optimized for building real time fault-tolerant 122 applications. Nevertheless, ASAP does not restrict itself to ENRP for 123 namespace services. In fact, it is not only feasible but also 124 desirable in the future to generalize ASAP design so that the ENRP can 125 provide a generic interface that is capable of inter-working with 126 different namespace, including DNS, at the ASAP implementor's choice. 128 In the following, we list some limitations of the current DNS 129 namespace capability when compared to that of ENRP: 131 1) DNS name registration and translation services have been primarily 132 optimized for host names. But we consider namespace services 133 optimized for process names or endpoint names more appropriate and 134 efficient for supporting real time server-level fault-tolerance 135 applications. 137 2) DNS is primarily passive. It provides a query/response database 138 that allows one to find information, but does NOT provide 139 monitoring of hosts or processes to assure consistency within 140 its database. 142 3) DNS has dynamic extensions but is not designed around the 143 dynamic fast changing process address space that is typical to 144 real time distributed applications. 146 It has also been suggested that ASAP be extended to work with DNS to 147 bridge multiple ASAP planes and provide an "inter-ASAP-Domain" bridging 148 function. 150 1.2 Definitions 152 This document uses the following terms: 154 Operation scope --- the part of the network visible by ENRP. 156 ASAP Endpoint --- a logical entity in the operation scope which 157 implements the ASAP stack and is capable of sending and receiving 158 messages. 160 ASAP Node --- a host machine in the network which contains one or 161 more ASAP endpoints. 163 ASAP Plane or ASAP operational domain --- A relam of tight binding 164 controlled by a set of one or more ENRP deamons. A process or application 165 entitiy registers its name within this "plane" and is peroidically 166 checked for sanity. Note that a plane does not imply geographical locality. 168 Endpoint name --- the registered tag of a ASAP endpoint, consisting of 169 a NULL terminated ASCII string of fixed length. 171 Named group --- a group of ASAP endpoints sharing the same endpoint 172 name in the name space. 174 Endpoint handle --- a logical pointer, consisting of a name and the 175 primary destination transport address to a particular endpoint in a 176 named group. 178 ENRP client --- a ASAP endpoint using ENRP to obtain name translation 179 and other related services. In this document, the term "ASAP endpoint" is 180 exchangeable with "ENRP client", unless otherwise stated. 182 ENRP maintenance client --- a ASAP endpoint that has the additional 183 capability of exchanging ENRP maintenance messages with an ENRP 184 server in order to perform certain maintenance functions. 186 ENRP server --- a server program running on a node that manages the 187 name space collectively with its peer ENRP servers and replies to the 188 service requests from any ENRP client. 190 Home ENRP server --- the ENRP server to which an endpoint currently 191 belongs. Endpoints normally choose the ENRP server on their local 192 host as the home ENRP server, if one exists. An endpoint shall only 193 have one home ENRP server at any given time, and both the endpoint and 194 the server shall keep track of this master/slave relationship between 195 them. 197 ENRP server takeover --- the event that a remote ENRP server takes the 198 ownership of all the ENRP endpoints on a node and becomes their home 199 server. 201 Caretaker ENRP server --- The ENRP server on a remote node which takes 202 ownership of all endpoints on the local node because of the absence of 203 an active local server. 205 ENRP client channel --- the communication channel through which a ASAP 206 endpoint requests for ENRP service. The ENRP client channel is usually 207 defined by the transport address of the home server and a well known 208 port number. 210 ENRP server channel --- defined by a well known multicast IP address 211 and a well known port number. All ENRP servers in an operation scope 212 can communicate with one another through this channel. Endpoints are 213 also allowed to communicate on this channel occasionally. 215 ENRP name domain --- defined by the combination of the ENRP client 216 channel and the ENRP server channel in the operation scope. 218 Network Byte Order: Most significant byte first, a.k.a Big Endian. 220 1.3 Protocol overview 222 At startup, each endpoint in a ASAP operational domain registers its 223 name to in name space. Here a name is defined as a NULL terminated 224 ASCII string of fixed length. 226 When sending a message, the sender addresses the receiver endpoint by 227 its name and passes the message to its ASAP layer. The ASAP layer, with 228 the help from the ENRP name space daemon server(s), translates the 229 name to a valid transport address (or a list of transport addresses if 230 the receiver is multi-homed) and sends the message to the receiving 231 endpoint. 233 The following diagram illustrates the components of ASAP and their 234 relationships. 236 Figure 1. 238 Data Sender Data Receiver 239 ENRP (ASAP-user) (ASAP-user) 240 Server +---------+ +---------+ 241 | ASAP |<---//---->| ASAP | 242 +------+ |------+ | |------+ | 243 <----->| ENRP |<---->| ENRP | | | ENRP | | 244 To peer +------+ +---------+ +---------+ 245 ENRP server| SCTP | | SCTP | | SCTP | 246 +------+ +---------+ +---------+ 247 | IP | | IP | | IP | 248 +------+ +---------+ +---------+ 249 |_______________|_____________________| 251 Multiple endpoints can register themselves under the same name. In 252 that case they will be treated as a receiver pool, and ASAP, when 253 sending a message addressed to that name, will use a predefined 254 load-sharing policy to determine which endpoint(s) in the pool to 255 send (or address) the message. 257 ASAP design has a high emphasis on seamless support of "server 258 pooling", high availability, dynamic scalability, and 259 close-to-real-time name translation. 261 In particular, ASAP can be characterized by: 263 A) Seamless support of "server pooling" --- ASAP allows multiple 264 servers to register under the same name. It also allows servers to 265 be dynamically add to or removed from a server pool without any 266 reconfiguration. 268 B) Support automatic receiver "fail-over" --- when the chosen message 269 receiver fails, ASAP, with pre-stated permission from its upper 270 layer, can automatically re-direct the message to an alternative 271 server under the same name if one exists. 273 C) Transaction management by nickname or "association handle" --- this 274 is to allow a continuous transaction or session consisting of 275 multiple interactions be held between a client endpoint and and one 276 particular server in a server pool. 278 Note: For details on ASAP please see [ASAP]. 280 D) Fully distributed name space --- For achieving a high degree of 281 fault tolerance and operation efficiency, the ENRP daemons which 282 provide name translation service and the name space data are 283 distributed across the operational scope of the network. 285 ENRP daemon servers can be added to or removed from the operation 286 scope dynamically, without interrupting the current name translation 287 service. 289 For example, a node may be originally configured to operate without a 290 local ENRP server. When the load condition changes, one can start a 291 new ENRP server on that node to increase the operation capacity. The 292 new ENRP server will automatically integrate itself with the existing 293 ENRP server(s) in the scope. 295 Similarly, when an ENRP server becomes unavailable for service (e.g., 296 being intentionally shutdown, or suffered failure), its ASAP clients 297 will be automatically taken-over by a remote ENRP server and 298 continuously have ENRP services provided. 300 E) Network failure detection and automatic recovery --- In the case 301 when a major network failure breaks the operation scope into 302 isolated communication islands, the name translation service will 303 survive and continue inside each island so long as there is one or 304 more ENRP servers present in that island. Endpoints inside each 305 island will still continue to be able to communicate with each other. 306 Moreover, when the network recovers, the isolated ENRP servers will 307 re-discover each other and re-integrate the name space back into 308 its original form. 310 Figure 2. shows an example of distributed applications operating in a 311 scope that is connected by a pair of redundant networks. 313 Figure 2. 315 Node 1 Node 2 316 +--------------+ || +--------------+ 317 | | || || | | 318 | Apps1 | |+===||==| | 319 | | || || | Apps2 | 320 | |===+| || | | 321 | Apps2 | || |+==| Apps3 | 322 | | || || | | 323 | |========+| | | 324 | (ENRP Svr) | || || | (ENRP Svr) | 325 +--------------+ || || +--------------+ 326 || || 327 Node 3 || || Node 4 328 +--------------+ || || +--------------+ 329 | | || || | | 330 | Apps2 | || || | | 331 | |========+| | Apps3 | 332 | | || || | | 333 | Apps4 | || || | | 334 | |===+| |+==| Apps1 | 335 | | || || | | 336 | (ENRP Svr) | |+===||==| | 337 +--------------+ || || +--------------+ 338 || || 339 network1 network2 341 In this example, there are four nodes in the scope, as shown in Figure 342 2. On Node 1, Node 2, and Node 3, there is an ENRP server running. On 343 each of the nodes, there are also some applications running. Each 344 application has a registered name in the name space collectively 345 managed by the three ENRP servers. In the example, the registered 346 names are "Apps1", "Apps2", "Apps3", and "Apps4". Some of the 347 applications (Apps1, Apps2, and Apps3) are distributed as server 348 pools. 350 When sending messages to each other, the sender application simply 351 addresses the recipient by its registered name. The ASAP layer inside 352 the sender application will query its home ENRP server to obtain the 353 transport address(es) and load control information of the recipient 354 before sending the message out. 356 Also note in the example, there is no ENRP server on Node 4. But the 357 applications on Node 4 will be served by one of the ENRP servers on 358 other nodes. 360 1.4 Organization of this document 362 Chapter 2 we give the details of the ENRP interface. ENRP defines the 363 messaging structure and relevant rules for communications between an 364 ASAP endpoint and an ENRP server. This chapter discusses how ENRP 365 maintains the name space in a high availablitity manner. Chapter 3 366 defines the message format and structures used by ENRP (in conjunction 367 with those used by ASAP). Chapter 4 provides settable protocol values. 369 1.5 Scope of ENRP 371 The scope of the ASAP/ENRP is NOT Internet wide. The namespace is neither 372 hierarchical nor arbitrarily large like DNS. We propose a flat peer-to-peer 373 model. Pools of servers will exist in different administrative domains. For 374 example, suppose I want to use ASAP/ENRP. First, the PU will use DNS to 375 contact an ENRP server. Suppose a PU in North America and wish to contact 376 the server pool in Japan instead of North America. The PU would use DNS to 377 get the IP address of the Japanese server pool domain, that is, the address 378 of an ENRP server('s) in Japan. 380 2. The ENRP interface 382 This section discusses the messages and procedures for communicating 383 between the ASAP layer of a ASAP endpoint and an ENRP name space server, 384 as well as that between peer ENRP servers. 386 2.1 Functional Summary 388 In this section, we discuss the functions defined by ENRP. The 389 functions are divided into three groups, namely the basic ENRP 390 operations, fault management, and control and maintenance functions. 392 Most of the ENRP operations involve message exchanges between an ENRP 393 server and a ASAP endpoint, as well as message exchanges between the 394 ENRP server and its peers. Some of the ENRP message formats are 395 also found in [ASAP] 397 2.1.1 Basic ENRP Operations 399 2.1.1.1 Endpoint Registration 401 ENRP server <-> endpoint: 403 A ASAP endpoint shall send a REGISTRATION message, over the ENRP client 404 channel, to its home ENRP server, in order to register itself with the 405 name space. 407 In the REGISTRATION message, the endpoint shall indicate its name in 408 the form of a character string, network access information (e.g., a 409 list of valid transport addresses with which the endpoint 410 can be reached), and load control information. 412 The ENRP server shall handle the REGISTRATION message following the 413 rules listed below: 415 o If the name does not exist in the name space, the ENRP server shall 416 create the name and add the new endpoint under that name. 418 o If the name already exists in the name space, the requesting 419 endpoint shall be added under the same name and be made a member of 420 the named group. 422 o If both the name and the requesting endpoint already exist in the 423 name space, i.e., a case of duplicated registration, the ENRP 424 server shall grant the request without taking any further actions. 426 o The ENRP server may reject the registration due to reasons such as 427 invalid values, lack of resource, etc. 429 In all the above cases, if the REGISTRATION request is granted, the 430 ENRP server shall assume the ownership of the requesting endpoint. 432 In response, the home ENRP server shall reply to the requesting 433 endpoint with a REGISTRATION_RESPONSE message, and shall indicate in 434 the message body whether the registration is granted or rejected. 436 ENRP server <-> peers: 438 If the registration request is not a duplicate and is granted, the 439 home ENRP server shall take the name space modification action 440 described in section 3.1.1.8??. Otherwise, no message shall be 441 exchanged with its peers. 443 2.1.1.2 Endpoint De-registration 445 ENRP server <-> endpoint: 447 A ASAP endpoint shall send a DEREGISTRATION message, over the ENRP 448 client channel, to its home ENRP server in order to remove itself from 449 the name space. 451 If the endpoint is the last one under that name in the name space the 452 home ENRP server shall remove the name from its space as well. 454 The ENRP server may reject the de-registration request due to reasons 455 such as invalid parameters, etc. 457 In response, the home ENRP server shall send a REGISTRATION_RESPONSE 458 message to the endpoint, and shall indicate in the message body 459 whether the request is granted or rejected. 461 It should be noted that de-registration does not stop the ASAP endpoint 462 from sending or receiving messages. It only means that other ASAP 463 endpoints will no longer be able to send message to that endpoint by 464 name. 466 ENRP server <-> peers: 468 Once the de-registration request is granted and the endpoint removed 469 from its local copy of the name space, the home ENRP server shall take 470 the name space modification action described in section 2.1.1.9. 472 2.1.1.3 Name Translation 474 ENRP server <-> endpoint: 476 An endpoint shall send a NAME_REQUEST messages to its home ENRP server 477 to get a name translation service. In the NAME_REQUEST message, the 478 endpoint shall include the name it wants to be translated. 480 If the name exits in the name space, the ENRP server shall send back a 481 NAME_INFORMATION message that shall carry all information of the ASAP 482 endpoint(s) currently registered under that name, including current 483 load control policy of the group, policy value of each endpoint in 484 the group, and a list of transport addresses for each endpoint in the 485 group with which the endpoint can be reached, etc. 487 If the name does not exist in the name space, the ENRP server shall 488 respond with a NAME_UNKNOWN message. 490 ENRP server <-> peers: 492 None. 494 2.1.1.4 Server Name Space Update 496 This includes a set of update operations used by an ENRP server to 497 inform its peer(s) the addition a new ASAP endpoint, removal of an 498 existing ASAP endpoint, change property of a named group, etc. 500 2.1.1.4.1 Addition of a New ASAP Endpoint 502 When a new ASAP endpoint is granted registration to the name space, the 503 home ENRP server uses this procedure to inform all its peers. 505 ENRP server <-> endpoint: 507 None: 509 ENRP server <-> peers: 511 An ENRP server shall multicast over the ENRP server channel a 512 PEER_NAME_UPDATE message with the appropriate flag set to indicate to its 513 peers about the addition of the new endpoint to the name space. 515 Upon the reception of this PEER_NAME_UPDATE message, each of the peer ENRP 516 servers shall take the following actions: 518 o If the name does not exist in its local copy of the name space, the 519 peer ENRP server shall create the name and add the new endpoint 520 under that name in its local name space copy, along with other 521 attributes about the endpoint carried in the message. 523 o If the name already exists in the peer server's local copy of the 524 name space, the new endpoint endpoint shall be added as a new member 525 of the named group. 527 o If both the same ASAP endpoint already exists in the named group in 528 the local copy of the name space of the peer, the peer ENRP server 529 shall take no actions. 531 After adding the endpoint into its local copy of name space, the peer 532 ENRP server shall check if this endpoint is located on the same host 533 as the peer ENRP server itself does. If so, the peer ENRP server shall 534 assume the ownership of the endpoint, and take the ?? actions 535 described in section 2.1.1.12??. 537 2.1.1.4.2 Removal of a ASAP Endpoint 539 This procedure is used by an ENRP server to inform its peer(s) to 540 remove an existing ASAP endpoint, regardless of the ownership of the 541 endpoint. 543 ENRP server <-> endpoint: 545 None: 547 ENRP server <-> peers: 549 The ENRP server shall multicast over the ENRP server channel a 550 PEER_NAME_UPDATE message with the appropriate flag set to instruct its 551 peers to remove of the endpoint from their local copy of the name 552 space. 554 On the reception of this PEER_NAME_UPDATE message, each peer ENRP 555 server shall find and remove the ASAP endpoint from its local copy of 556 the name space regardless whether or not it has ownership on the 557 endpoint. 559 2.1.1.4.3 Removal of a ASAP Endpoint with no Ownership 561 This operation is used by an ENRP server to instruct its peers to 562 remove an existing ASAP endpoint which the peer does not have an 563 ownership on. 565 ENRP server <-> endpoint: 567 None: 569 ENRP server <-> peers: 571 An ENRP server shall multicast over the ENRP server channel a 572 PEER_NAME_UPDATE message with the appropriate flag set to instruct its 573 peers to remove the specified endpoint from its local copy of the name 574 space IF the peer does not have ownership on the endpoint. 576 On the reception of this PEER_NAME_UPDATE message, a peer ENRP server 577 shall find and remove the endpoint from its local copy of the name 578 space only if the peer server does not own this endpoint. 580 2.1.1.4.4 Update Endpoint Attributes 582 This operation is used by an ENRP server to inform its peers to update 583 the attributes of an existing ASAP endpoint. 585 ENRP server <-> endpoint: 587 None: 589 ENRP server <-> peers: 591 An ENRP server shall multicast over the ENRP server channel a 592 PEER_NAME_UPDATE message with the appropriate flag set to instruct 593 its peers to replace the attributes of an existing ASAP endpoint in its 594 local copy of the name space. 596 On the reception of this PEER_NAME_UPDATE message, a peer ENRP server 597 shall replace the attributes of the existing endpoint with the new 598 information carried in the message if the endpoint exists in its local 599 copy of the name space. If the specified endpoint is not found in its 600 local name space copy, the peer server shall add the endpoint 601 following the steps in Section 2.1.1.4.1??. 603 2.1.1.4.5 Claim Endpoint Ownership 605 This operation is used by an ENRP server to claim the ownership on a 606 specific endpoint and to inform its peers about its claim. 608 ENRP server <-> endpoint: 610 An ENRP server shall send an ENDPOINT_KEEP_ALIVE message to the 611 endpoint. This message will cause the endpoint to adopt this ENRP 612 server as its new home ENRP server (see Section 2.5.3). 614 ENRP server <-> peers: 616 An ENRP server shall multicast over the ENRP server channel a 617 PEER_NAME_UPDATE message with the appropriate flag set to inform its 618 peers that it has taken the ownership of the specified endpoint. 620 Upon the reception of this PEER_NAME_UPDATE message, a peer server 621 shall check whether it is the current owner of the endpoint. If so, 622 this peer server shall relinquish its ownership on that 623 endpoint. Otherwise, no action is needed. 625 2.1.1.4.6 Report Endpoint Failure 627 This operation is used by an ENRP server to warn its peers that it has 628 noticed a potentially unreachable endpoint that the server does not 629 have ownership on. 631 ENRP server <-> endpoint: 633 None: 635 ENRP server <-> peers: 637 An ENRP server shall multicast over the ENRP server channel a 638 PEER_NAME_UPDATE message with the appropriate flag set to indicate 639 that the specified ASAP endpoint is potentially unreachable. 641 On the reception of this message, each peer ENRP server shall check 642 whether it owns the specified endpoint. If it does, the peer server 643 shall increase the counter of the specified 644 endpoint by 1. If the value of the counter 645 has exceeded the protocol parameter Max-Endpoint-Report-Failures, the 646 peer server shall remove the endpoint from its local name space and 647 take actions described in Section 2.1.1.4.3. If the peer server does 648 not own the specified endpoint, it shall take no action. 650 2.1.1.5 Endpoint Change Policy Value 652 A ASAP endpoint can modify its policy value at any time. Depending on 653 the current number of members in the named group and the server pooling 654 policy, this operation allows the ASAP endpoint to control its share of 655 inbound messages received within the named group dynamically (also see 656 Section 2.1.5.1 for more on load control). 658 ENRP server <-> endpoint: 660 A ASAP endpoint shall send an UPDATE_POLICY_VALUE message over the 661 ENRP client channel to its home ENRP server in order to modify its 662 policy value. The new policy value shall be indicated in the 663 message. 665 Upon the reception of this UPDATE_POLICY_VALUE message, the home ENRP 666 server shall replace the policy value of that endpoint in its local 667 copy of the name space with the new value indicated in the message. 669 ENRP server <-> peers: 671 If the update on its local copy of the name space is successful, the 672 home ENRP server shall take the Server Name Space Update actions as 673 described in Section 2.1.1.4.4. 675 2.1.1.6 Server Down Load Name Space from a Peer 677 This operation allows an ENRP server to request and receive a copy of 678 a specific portion of the name space from one of its peer ENRP servers. 679 This is useful for a newly started ENRP server to initiate its local 680 copy of the name space, or for correcting name space inconsistency. 682 ENRP server <-> endpoint: 684 None. 686 ENRP server <-> peers: 688 An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message 689 directly to one of its peers. In the message, it shall indicate which 690 portion of the name space is requested. 692 Upon the reception of this message, the peer server shall initiate a 693 download session in which the requested portion of the name space 694 shall be sent to the requesting ENRP server in one or more 695 PEER_NAME_TABLE_RESPONSE messages. 697 If the sending ENRP server determines that multiple 698 PEER_NAME_TABLE_RESPONSE messages are needed for the session, it shall 699 set the appropriate flag in each PEER_NAME_TABLE_RESPONSE message to 700 inform the receiving ENRP server whether or not the data in this 701 message is the last piece of the transfer. 703 Every time the requesting ENRP server receives a 704 PEER_NAME_TABLE_RESPONSE message, it shall transfer the data entries 705 carried in the message into its local name space database, and then 706 check whether or not the data in this message is the last piece to be 707 transfered. If more data transfer is indicated, the requesting ENRP 708 server shall send another PEER_NAME_TABLE_REQUEST message to the same 709 peer to prompt for the next piece. 711 When transferring the data entries from the PEER_NAME_TABLE_RESPONSE 712 message into its local name space database, the requesting ENRP server 713 shall follow the same procedures as described in section 2.1.1.4.1 714 when parsing through the endpoints carrying in the message one by one. 716 2.1.1.7 Server Monitor Peer Status 718 ENRP server <-> endpoint: 720 None: 722 ENRP server <-> peers: 724 An ENRP server shall keep a record on the status of each of its peers. 726 If a message of any type is received from a peer, the server shall 727 update that peers status as . If a message of any type is 728 received from a peer previously unknown to this server, i.e., a new 729 peer, the server shall create a record for the new peer and mark the 730 new peer as . 732 2.1.1.8 Server Down Load Peer List 734 This operation allows an ENRP server to request from a peer server a 735 copy of its internal peer list. This is useful for a new ENRP server 736 to initiate its own peer list at startup. 738 ENRP server <-> endpoint: 740 None. 742 ENRP server <-> peers: 744 An ENRP server shall send a PEER_LIST_REQUEST message to a peer to 745 request a copy of its peer list. 747 Upon the reception of this message, the peer server shall reply with a 748 PEER_LIST_RESPONSE message and include in the message body a copy of its 749 internal peer list, if the peer itself is in operational state. 751 If the peer itself is in the process of startup, it shall response 752 with a PEER_LIST_RESPONSE message but set the appropriate flag to 753 indicate that it can not grant the PEER_LIST_REQUEST. In such a case, 754 the requesting ENRP server shall select another peer and repeat the 755 peer list request with the new peer at a later time. 757 2.1.1.9 Endpoint Initialization 759 At startup, a ASAP endpoint shall always assume the existence of a local 760 ENRP server on the local host and mark it as its home ENRP server, and 761 initiate the registration procedure described in 2.1.1.1??. 763 2.1.1.10 Server Initialization 765 At startup, before getting into service, an ENRP server (initiating 766 server) shall multicast a PEER_PRESENCE message with reply required 767 flag set over the ENRP server channel, in order to inform any other 768 active peers in the operation scope about its presence. 770 Upon the reception of this message, a peer shall send a PEER_PRESENCE 771 without reply required flag back to the initiating server, in order to 772 help the initiating server to build its peer list. 774 If no response to its PEER_PRESENCE message are received, the 775 initiating server shall assume that it is alone in the operation scope 776 and shall mark the initialization process as completed. 778 If there are responses to its PEER_PRESENCE message, the initiating 779 server shall then take the actions described in 2.1.1.8 to request a 780 peer list from one of the peers that have responded. 782 Upon the reception of the PEER_LIST_RESPONSE message from that peer, 783 the initiating server shall use the information carried in the message 784 to build a complete peer list, including both active and inactive 785 peers in the operation scope. 787 Then, the initiating server shall perform a name database download, as 788 described in 2.1.1.6, with each of the active peers on the peer list, 789 indicating that the portion of the name database to download shall 790 only include the endpoints owned by that peer. 792 Moreover, the initiating server shall also pick one of the active peer 793 and request to that peer for a download of the table of remote 794 endpoints. 796 2.1.2 Fault Management Operations 798 The following operations are used to detect and recover from various 799 system faults. 801 2.1.2.1 Detect and Report Unreachable Endpoint 803 Two mechanisms exist to detect and report an unreachable ASAP endpoint: 805 1) Home ENRP server periodic sanity check 807 An ENRP server shall send, in every seconds, 808 an ENDPOINT_KEEP_ALIVE message to each of the endpoints it owns, and 809 shall keep the number of consecutive failed send attempts in the 810 counter of that endpoint. 812 If the value of of an endpoint exceeds the 813 pre-set threshold Max-endpoint-sanity-failures, the home ENRP server 814 shall remove the endpoint from its copy of the name database and take 815 the actions described in section 2.1.1.4.3 to inform its peers. 817 The handling of the ENDPOINT_KEEP_ALIVE message by the endpoint is 818 described in Section 2.5.3??. 820 2) Detection by peer endpoints 822 Whenever a ASAP endpoint finds a peer unreachable (e.g., via an SCTP 823 SEND.FAILURE Notification, see Section 2.2.5??), the endpoint shall 824 send an ENDPOINT_UNREACHABLE message over the ENRP client channel to 825 its home ENRP server. The message shall contain one of the transport 826 addresses of the unreachable peer and have the severity flag set to 827 NORMAL_REPORT. 829 Upon the reception of this message, the home ENRP server shall first 830 check whether it owns the unreachable endpoint. If not, the server 831 shall take the actions described in section 2.1.1.4.6??. 833 Otherwise, the server shall increase the 834 counter of the unreachable endpoint by 1. If the value of the 835 counter has exceeded 836 Max-endpoint-report-failures, the server shall remove the endpoint 837 from its name database and take actions described in 2.1.1.4.3??. 839 2.1.2.2 ENRP Server Heartbeat 841 An ENRP server shall multicast, in every 842 seconds, a PEER_PRESENCE message over the ENRP server channel to 843 inform its peers that it is still operational. In the PEER_PRESENCE 844 message, the sending ENRP server shall set the appropriate flag to 845 indicate that no reply is required. 847 >From time to time, an ENRP server may also send a point-to-point 848 PEER_PRESENCE message to a specific peer server, with the flag setting 849 in the message indicates that a reply is required. In such a case, the 850 peer server shall immediately respond to the sender with its own 851 point-to-point PEER_PRESENCE message, and shall indicate in the 852 message that no reply is required. 854 2.1.2.3 ENRP Server Hunt 856 An endpoint shall initiate the following home server hunt procedure if 857 it fails to send to, or times out on a service request with its 858 current home server. 860 In the home server hunt procedure, the endpoint shall multicast a 861 SERVER_HUNT message over the ENRP client channel, and shall repeat 862 sending this message every seconds until a 863 SERVER_HUNT_RESPONSE message is received from an ENRP server. Each 864 time the 'Timeout-server-hunt' timer expires the criticality should 865 be raised (initially criticality should be set to LOW_CRITICALITY). 867 Then the endpoint shall pick one of the servers that have responded as 868 its new home server, and continue the service request with that 869 server. 871 Upon the reception of the SERVER_HUNT message, a server shall reply to 872 the endpoint with a SERVER_HUNT_RESPONSE message, unless: 874 1) its peer status information indicates that there is a caretaker 875 server other than itself for the node where the endpoint is from, 876 AND 878 2) the criticality flag in the SERVER_HUNT message is not 879 HIGH_CRITICALITY. 881 2.1.2.4 ENRP Server Detect and Take-over Inactive Peer 883 An ENRP server shall keep track the time when the last message 884 (multicast or point-to-point) was received from each known peer. 886 If a peer has not been heard for more than Max-time-last-heard, the 887 ENRP server shall send a point-to-point PEER_PRESENCE with reply 888 request to that peer. 890 If the send fails or the peer does not reply after 891 Max-time-no-response seconds, the ENRP server shall initiate the 892 following server take-over procedures: 894 1) Initiate Server Take-over Arbitration 896 The ENRP server (the initiating server) shall initiate a take-over 897 arbitration on the inactive peer (the target server) by multicasting a 898 TAKEOVER_INITIATE message over the ENRP server channel. In the 899 message, the initiating server shall specify the identification of the 900 target server. 902 After multicasting the TAKEOVER_INITIATE message, the initiating 903 server shall wait for a TAKEOVER_INITIATE_RESPONSE message from each 904 of its active peers. 906 Upon the reception of this message, other peer servers shall take the 907 following actions accordingly: 909 o If the peer server finds that itself is the target server indicated 910 in the TAKEOVER_INITIATE message, it shall immediately multicast a 911 PEER_PRESENCE message over the ENRP server channel in an attempt of 912 stopping the take-over process. 914 o If the peer server finds that itself has also initiated a take-over 915 process on the same target server and its IP address is smaller in 916 value than that of the sender of the TAKEOVER_INITIATE message, it 917 shall abort its own take-over process. 919 o Peers other than the target peer and the peer that is taking-over 920 shall mark the target server as and mark the initiating 921 server as the caretaker of the target server and reply to the 922 initiating server with a TAKEOVER_INITIATE_RESPONSE message. 924 Once it has received TAKEOVER_INITIATE_RESPONSE message from all of 925 its active peers, the initiating server shall consider it won 926 the arbitration and shall then take the actions in 2) in order to 927 complete the take-over. 929 However, if it receives a PEER_PRESENCE from the target server at any 930 point of the take-over, the initiating server shall immediately abort 931 the take-over process and re-mark the target server as . 933 2) Take-over the target peer server 935 An ENRP server shall multicast a TAKEOVER_PEER_SERVER message over the 936 ENRP server channel in order to inform all its peers about the 937 take-over. In the message, identification of the inactive peer server 938 targeted for the take-over shall be included. 940 The server shall mark the target server as and mark itself 941 as the caretaker of the target server. 943 Then it shall assume ownership on each of the endpoints originally 944 owned by the target server. 946 The server shall also check whether there are any other inactive peers 947 which has designated the target server as their caretaker. The server 948 shall perform the above take-over procedure on each one of those 949 inactive peers as well. 951 2.1.2.5 Register Homeless Endpoints 953 When an ENRP server receives a REGISTRATION message from an endpoint 954 located on a remote node, it shall always accept and grant the 955 registration, unless its peer status information indicates that the 956 peer on that node is inactive and a caretaker other than itself exists 957 for that node. In that case, the server shall reject the registration 958 and take no further actions. 960 If the server has no record about the peer on that node, the 961 server shall grant the registration and then create a record about 962 that peer, mark it as inactive, and initiate a take-over procedure on 963 it, as described in 2.1.2.4??. 965 2.1.3 Maintenance Operations 967 The following operations are used by an ENRP maintenance client to 968 monitor the name space data and perform maintenances on ENRP servers 969 in an operation scope. 971 2.1.3.1 Forceful Removal of Endpoint 973 A maintenance endpoint shall send a ENDPOINT_UNREACHABLE message to an 974 ENRP server, in order to force the removal of another endpoint from 975 the name space. The message shall contain one of the transport 976 addresses of the target endpoint and have the severity flag set to 977 FINAL_REPORT. 979 Upon the reception of this message, the ENRP server shall immediately 980 remove the target endpoint from its copy of the name database and take 981 actions described in Section 2.1.1.4.2. 983 2.1.3.2 Dump Home Endpoint List 985 A maintenance endpoint shall send a SERVER_DUMP message with type flag 986 set to HOME_LIST to a server, in order to require a copy of the 987 information on all the endpoints owned by that server. 989 Upon receiving this message, the server shall response with a 990 SERVER_DUMP_RESPONSE message with the type flag set to HOME_LIST to 991 the maintenance endpoint. In the message body, the server shall 992 include information on all the endpoints the server currently owns. 994 2.1.3.3 Dump Remote Endpoint List 996 A maintenance endpoint shall send a SERVER_DUMP message with type flag 997 set to REMOTE_LIST to a server, in order to require a copy of the 998 information on all the endpoints NOT owned by that server. 1000 Upon receiving this message, the server shall response with a 1001 SERVER_DUMP_RESPONSE message with the type flag set to REMOTE_LIST to 1002 the maintenance endpoint. In the message body, the server shall 1003 include information on all the endpoints the server currently does NOT 1004 owns. 1006 2.1.3.4 Dump Peer Server List 1008 A maintenance endpoint shall send a SERVER_DUMP message with the type 1009 flag set to PEER_SERVER_LIST to a server, in order to require a copy 1010 of the peer list known to that server. 1012 Upon receiving this message, the server shall response with a 1013 SERVER_DUMP_RESPONSE message with the type flag set to 1014 PEER_SERVER_LIST to the maintenance endpoint. In the message body, the 1015 server shall include information on all the peers that server 1016 currently knows. 1018 3 Message Summary 1020 All messages as well as their fields described below shall be in 1021 Network Byte Order during transmission. For fields with a length 1022 bigger than 4 octets, a number in a pair of parentheses may follow the 1023 filed name to indicate the length of the field in number of octets. 1025 3.1 Endpoint Entry 1027 This field is used to represent a ASAP endpoint and the associated 1028 information, such as its transport address(es), load control, and 1029 other operational status information. 1031 The field is defined to support endpoint with up to 8 different 1032 transport addresses. 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | IP address #0 | 1038 +-------------------------------+-------------------------------+ 1039 | IP address #1 | 1040 +-------------------------------+-------------------------------+ 1041 \ \ \ \ 1042 / / / / 1043 \ \ \ \ 1044 +-------------------------------+-------------------------------+ 1045 | IP address #7 | 1046 +-------------------------------+-------------------------------+ 1047 | SCTP Port | Padding | 1048 +-------------------------------+-------------------------------+ 1049 | Server Pooling Policy | Policy Value | 1050 +---------------+---------------+---------------+---------------+ 1052 The size of the endpoint entry is 40 octets. 1054 3.2 PEER_NAME_TABLE_REQUEST message 1056 0 1 2 3 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | ENRP server message identifier #1 = 0x27047729 | 1060 +-------------------------------+-------------------------------+ 1061 | ENRP server message identifier #2 = 0x53829149 | 1062 +-------------------------------+-------------------------------+ 1063 | Type = 0x102 | 1064 +-------------------------------+-------------------------------+ 1065 | sending server's IP address | 1066 +-------------------------------+-------------------------------+ 1067 | sender's SCTP port | padding | 1068 +-------------------------------+-------------------------------+ 1069 | receiving server's IP address | 1070 +-------------------------------+-------------------------------+ 1071 | receiver's SCTP port | padding | 1072 +-------------------------------+-------------------------------+ 1073 | Table type = (see below) | 1074 +-------------------------------+-------------------------------+ 1076 Note, the receiver's IP address and port do not need to be filled in 1077 if the message is being multicasted. 1079 The requested table type shall take one of the following values: 1080 0x1 --- HOME_LIST: endpoints owned by the server. 1081 0x2 --- REMOTE_LIST: endpoint NOT owned by the server. 1083 3.3 PEER_NAME_TABLE_RESPONSE message 1085 0 1 2 3 1086 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 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | ENRP server message identifier #1 = 0x27047729 | 1089 +-------------------------------+-------------------------------+ 1090 | ENRP server message identifier #2 = 0x53829149 | 1091 +-------------------------------+-------------------------------+ 1092 | Type = 0x103 | 1093 +-------------------------------+-------------------------------+ 1094 | sender's IP address | 1095 +-------------------------------+-------------------------------+ 1096 | sender's SCTP port | padding | 1097 +-------------------------------+-------------------------------+ 1098 | receiver's IP address | 1099 +-------------------------------+-------------------------------+ 1100 | receiver's SCTP port | padding | 1101 +-------------------------------+-------------------------------+ 1102 | Table type = (see below) | 1103 +-------------------------------+-------------------------------+ 1104 | More to send = (see below) | 1105 +-------------------------------+-------------------------------+ 1106 | number of names = n | 1107 +-------------------------------+-------------------------------+ 1108 | | 1109 | Name entry 1 (see below) | 1110 | | 1111 +-------------------------------+-------------------------------+ 1112 / / 1113 \ \ 1114 / / 1115 +-------------------------------+-------------------------------+ 1116 | | 1117 | Name entry n (see below) | 1118 | | 1119 +-------------------------------+-------------------------------+ 1121 'Table type' shall take one of the following values: 1122 0x1 --- HOME_LIST: endpoints owned by the server. 1123 0x2 --- REMOTE_LIST: endpoint NOT owned by the server. 1125 'More to send' flag shall be set to 0x1 if there are more name entries 1126 to be sent for the requested table type. Otherwise, it shall be set to 1127 0x0. 1129 Each 'Name entry' represents an endpoint and shall consist of the 1130 following: 1132 +-------------------------------+-------------------------------+ 1133 | | 1134 | Endpoint name (32) | 1135 | | 1136 +-------------------------------+-------------------------------+ 1137 | number of endpoints = m | 1138 +-------------------------------+-------------------------------+ 1139 | | 1140 | endpoint entry 1 (40) | 1141 | | 1142 +-------------------------------+-------------------------------+ 1143 / / 1144 \ \ 1145 / / 1146 +-------------------------------+-------------------------------+ 1147 | | 1148 | endpoint entry m (40) | 1149 | | 1150 +-------------------------------+-------------------------------+ 1152 3.4 PEER_LIST_REQUEST message 1154 0 1 2 3 1155 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 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | ENRP server message identifier #1 = 0x27047729 | 1158 +-------------------------------+-------------------------------+ 1159 | ENRP server message identifier #2 = 0x53829149 | 1160 +-------------------------------+-------------------------------+ 1161 | Type = 0x10b | 1162 +-------------------------------+-------------------------------+ 1163 | sender's IP address | 1164 +-------------------------------+-------------------------------+ 1165 | sender's SCTP port | padding | 1166 +-------------------------------+-------------------------------+ 1167 | receiver's IP address | 1168 +-------------------------------+-------------------------------+ 1169 | receiver's SCTP port | padding | 1170 +-------------------------------+-------------------------------+ 1172 The receiver's IP address and port do not need to be filled in if 1173 the message is being multicasted. 1175 3.5 PEER_LIST_RESPONSE message 1177 This message shall contain all the peer information of the sending server. 1179 0 1 2 3 1180 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 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | ENRP server message identifier #1 = 0x27047729 | 1183 +-------------------------------+-------------------------------+ 1184 | ENRP server message identifier #2 = 0x53829149 | 1185 +-------------------------------+-------------------------------+ 1186 | Type = 0x10c | 1187 +-------------------------------+-------------------------------+ 1188 | sender's IP address | 1189 +-------------------------------+-------------------------------+ 1190 | senders SCTP port | padding | 1191 +-------------------------------+-------------------------------+ 1192 | receiver's IP address | 1193 +-------------------------------+-------------------------------+ 1194 | receiver's SCTP port | padding | 1195 +-------------------------------+-------------------------------+ 1196 | responseIndication (see below) | 1197 +-------------------------------+-------------------------------+ 1198 | number of peers = n | 1199 +-------------------------------+-------------------------------+ 1200 | | 1201 | Peer entry 1 (see below) | 1202 | | 1203 +-------------------------------+-------------------------------+ 1204 / / 1205 \ \ 1206 / / 1207 +-------------------------------+-------------------------------+ 1208 | | 1209 | Peer entry n (see below) | 1210 | | 1211 +-------------------------------+-------------------------------+ 1213 The 'responseIndication' flag shall be set to 0x2 to indicate a 1214 rejection to the request, and no 'Peer entry' shall be attached if the 1215 request is rejected. 1217 Otherwise, the 'responseIndication' flag shall be set to 0x1 and n 1218 'Peer entries' attached. 1220 Each 'Peer entry' shall consist of the following fields: 1222 0 1 2 3 1223 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 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | Peer's IP address | 1226 +-------------------------------+-------------------------------+ 1227 | Peer's SCTP port | padding | 1228 +-------------------------------+-------------------------------+ 1229 | Caretaker's IP address | 1230 +-------------------------------+-------------------------------+ 1231 | caretaker's SCTP port | padding | 1232 +-------------------------------+-------------------------------+ 1234 The peer's IP address and port number serve as the identification of 1235 that peer. If the peer is inactive, its caretaker's IP address and port 1236 number shall be filled in. Otherwise, the caretaker IP and port fields 1237 shall be set to zeros. 1239 3.6 PEER_NAME_UPDATE message 1241 0 1 2 3 1242 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 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | ENRP server message identifier #1 = 0x27047729 | 1245 +-------------------------------+-------------------------------+ 1246 | ENRP server message identifier #2 = 0x53829149 | 1247 +-------------------------------+-------------------------------+ 1248 | Type = 0x104 | 1249 +-------------------------------+-------------------------------+ 1250 | sender's IP address | 1251 +-------------------------------+-------------------------------+ 1252 | sender's SCTP port | padding | 1253 +-------------------------------+-------------------------------+ 1254 | receiver's IP address | 1255 +-------------------------------+-------------------------------+ 1256 | receiver's SCTP port | padding | 1257 +-------------------------------+-------------------------------+ 1258 | | 1259 | Endpoint name (32) | 1260 | | 1261 +-------------------------------+-------------------------------+ 1262 | | 1263 | endpoint entry (40) | 1264 | | 1265 +-------------------------------+-------------------------------+ 1266 | Update action (see below) | 1267 +-------------------------------+-------------------------------+ 1269 The receiver's IP address and port do not need to be filled in if 1270 the message is being multicasted. 1272 'Update action' shall take one of the following values: 1273 0x0 --- ADD_ENDPOINT: add a new endpoint, as specified by 'Endpoint 1274 name' and 'endpoint entry' fields, to the name space. 1275 0x1 --- DELETE_ENDPOINT: delete the named endpoint from the name 1276 database, if the receiving server owns the endpoint. 1277 0x2 --- REMOVE_ENDPOINT: remove the named endpoint from the name 1278 database, regardless who owns the endpoint. 1279 0x3 --- UPDATE_ENDPOINT: replace the endpoint's attributes with the 1280 new information carried in this message. 1281 0x4 --- ENDPOINT_FAILURE: warn the receiver that the named endpoint 1282 is potentially unreachable. 1283 0x5 --- CLAIM_ENDPOINT: inform the receiver that the sender has 1284 taken the ownership of the specified endpoint. 1286 3.7 PEER_PRESENCE message 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | ENRP server message identifier #1 = 0x27047729 | 1292 +-------------------------------+-------------------------------+ 1293 | ENRP server message identifier #2 = 0x53829149 | 1294 +-------------------------------+-------------------------------+ 1295 | Type = 0x100 | 1296 +-------------------------------+-------------------------------+ 1297 | sender's IP address | 1298 +-------------------------------+-------------------------------+ 1299 | sender's SCTP port | padding | 1300 +-------------------------------+-------------------------------+ 1301 | receiver's IP address | 1302 +-------------------------------+-------------------------------+ 1303 | receiver's SCTP port | padding | 1304 +-------------------------------+-------------------------------+ 1305 | Reply required | 1306 +-------------------------------+-------------------------------+ 1308 The receiving server's IP address and port do not need to be filled in 1309 if the message is being multicasted. 1311 'Reply required' shall be set to 0x1 if response to this message is 1312 required, otherwise set to 0x0. 1314 3.8 TAKEOVER_INITIATE message 1316 0 1 2 3 1317 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 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | ENRP server message identifier #1 = 0x27047729 | 1320 +-------------------------------+-------------------------------+ 1321 | ENRP server message identifier #2 = 0x53829149 | 1322 +-------------------------------+-------------------------------+ 1323 | Type = 0x106 | 1324 +-------------------------------+-------------------------------+ 1325 | sending server's IP address | 1326 +-------------------------------+-------------------------------+ 1327 | sender's SCTP port | padding | 1328 +-------------------------------+-------------------------------+ 1329 | receiving server's IP address | 1330 +-------------------------------+-------------------------------+ 1331 | receiver's SCTP port | padding | 1332 +-------------------------------+-------------------------------+ 1333 | Target server's IP address | 1334 +-------------------------------+-------------------------------+ 1335 | Target server's SCTP port | padding | 1336 +-------------------------------+-------------------------------+ 1338 The receiving server's address and port do not need to be filled in if 1339 the message is being multicasted. 1341 'Target server's IP address and port number must be supplied. 1343 3.9 TAKEOVER_INITIATE_RESPONSE message 1345 0 1 2 3 1346 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 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | ENRP server message identifier #1 = 0x27047729 | 1349 +-------------------------------+-------------------------------+ 1350 | ENRP server message identifier #2 = 0x53829149 | 1351 +-------------------------------+-------------------------------+ 1352 | Type = 0x107 | 1353 +-------------------------------+-------------------------------+ 1354 | sending server's IP address | 1355 +-------------------------------+-------------------------------+ 1356 | sender's SCTP port | padding | 1357 +-------------------------------+-------------------------------+ 1358 | receiving server's IP address | 1359 +-------------------------------+-------------------------------+ 1360 | receiver's SCTP port | padding | 1361 +-------------------------------+-------------------------------+ 1362 | Target server's IP address | 1363 +-------------------------------+-------------------------------+ 1364 | Target server's SCTP port | padding | 1365 +-------------------------------+-------------------------------+ 1367 The receiving server's address and port do not need to be filled in if 1368 the message is being multicasted. 1370 'Target server's IP address and port number must be supplied. 1372 3.10 TAKEOVER_PEER_SERVER message 1374 0 1 2 3 1375 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 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | ENRP server message identifier #1 = 0x27047729 | 1378 +-------------------------------+-------------------------------+ 1379 | ENRP server message identifier #2 = 0x53829149 | 1380 +-------------------------------+-------------------------------+ 1381 | Type = 0x108 | 1382 +-------------------------------+-------------------------------+ 1383 | sending server's IP address | 1384 +-------------------------------+-------------------------------+ 1385 | sender's SCTP port | padding | 1386 +-------------------------------+-------------------------------+ 1387 | receiving server's IP address | 1388 +-------------------------------+-------------------------------+ 1389 | receiver's SCTP port | padding | 1390 +-------------------------------+-------------------------------+ 1391 | Target server's IP address | 1392 +-------------------------------+-------------------------------+ 1393 | Target server's SCTP port | padding | 1394 +-------------------------------+-------------------------------+ 1396 The receiving server's address and port do not need to be filled in if 1397 the message is being multicasted. 1399 'Target server's IP address and port number must be supplied. 1401 3.11 SERVER_DUMP message 1403 0 1 2 3 1404 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 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | ENRP endpoint message identifier #1 = 0x18038688 | 1407 +-------------------------------+-------------------------------+ 1408 | ENRP endpoint message identifier #2 = 0x77734683 | 1409 +-------------------------------+-------------------------------+ 1410 | Type = 0x7 | 1411 +-------------------------------+-------------------------------+ 1412 | | 1413 | Endpoint name (32) | 1414 | | 1415 +-------------------------------+-------------------------------+ 1416 | Dump Type (see below) | 1417 +-------------------------------+-------------------------------+ 1419 The 'Dump Type' field shall take one of the following values: 1420 0x0 --- HOME_LIST: dump a copy of the home endpoint portion of the 1421 name database of the server (i.e., endpoints owned by the 1422 server). 1423 0x1 --- REMOTE_LIST: dump a copy of the remote endpoint portion of the 1424 name database of the server (i.e., endpoints NOT owned by the 1425 server). 1426 0x2 --- PEER_LIST: dump a copy of a list containing all the peers 1427 known to the server. 1429 3.12 SERVER_DUMP_RESPONSE message 1431 0 1 2 3 1432 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 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | ENRP endpoint message identifier #1 = 0x18038688 | 1435 +-------------------------------+-------------------------------+ 1436 | ENRP endpoint message identifier #2 = 0x77734683 | 1437 +-------------------------------+-------------------------------+ 1438 | Type = 0x8 | 1439 +-------------------------------+-------------------------------+ 1440 | | 1441 | Endpoint name (32) | 1442 | | 1443 +-------------------------------+-------------------------------+ 1444 | Dump Type (see below) | 1445 +-------------------------------+-------------------------------+ 1446 | Number of Entries = n (see below) | 1447 +-------------------------------+-------------------------------+ 1448 | | 1449 | Dump entry 1 (see below) | 1450 | | 1451 +-------------------------------+-------------------------------+ 1452 / / 1453 \ \ 1454 / / 1455 +-------------------------------+-------------------------------+ 1456 | | 1457 | Dump entry n (see below) | 1458 | | 1459 +-------------------------------+-------------------------------+ 1461 The 'Dump Type' fields shall take the same values as defined in 1462 Section 3.2.29??. 1464 If 'Dump Type' is HOME_LIST, or REMOTE_LIST, the 'Number of Entries' 1465 field shall be the number of endpoint entries carried in the message, 1466 and each 'Dump entry' field shall contain an endpoint entry and shall 1467 be defined as: 1469 0 1 2 3 1470 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 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | | 1473 | Endpoint name (32) | 1474 | | 1475 +-------------------------------+-------------------------------+ 1476 | number of endpoints = m | 1477 +-------------------------------+-------------------------------+ 1478 | | 1479 | endpoint entry 1 (40) | 1480 | | 1481 +-------------------------------+-------------------------------+ 1482 / / 1483 \ \ 1484 / / 1485 +-------------------------------+-------------------------------+ 1486 | | 1487 | endpoint entry m (40) | 1488 | | 1489 +-------------------------------+-------------------------------+ 1491 If 'Dump Type' is PEER_LIST, the 'Number of Entries' field shall be 1492 the number of peer entries carried in the message, and each 'Dump 1493 entry' field shall contain a peer entry and shall be defined as: 1495 0 1 2 3 1496 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 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | Peer's IP address | 1499 +-------------------------------+-------------------------------+ 1500 | Peer's SCTP port | padding | 1501 +-------------------------------+-------------------------------+ 1502 | Caretaker's IP address | 1503 +-------------------------------+-------------------------------+ 1504 | caretaker's SCTP port | padding | 1505 +-------------------------------+-------------------------------+ 1507 In a peer entry, the peer's IP address and port number serve as the 1508 identification of that peer. If the peer is inactive, its caretaker's 1509 IP address and port number shall be filled in. Otherwise, the 1510 caretaker IP and port fields shall be zeroed out. 1512 4. Variables, Time Values, and Thresholds 1514 The following is a summary of the variables, time values, and pre-set 1515 thresholds used in ASAP and ENRP protocol. 1517 4.1 Variables 1519 Endpoint-report-failures --- per endpoint; keeps the number of 1520 endpoint-unreachable reports concerning this endpoint. 1522 Endpoint-sanity-failures --- per endpoint; keeps the number of failed 1523 sanity message send attempts concerning this endpoint. 1525 Peer-server-last-heard --- per peer server; a time stamp on when the 1526 last message was received from this peer server. 1528 4.2 Time values 1530 Endpoint-sanity-cycle --- the period for a home ENRP server to start a 1531 new round of endpoint sanity check. 1533 Peer-heartbeat-cycle ---the period for an ENRP server to send out a 1534 heart heat message. 1536 T1-ENRPrequest - A timer started when a request is sent by ASAP to the 1537 ENRP server (providing application information is queued). Normally set 1538 to 15 seconds. 1540 T2-registration - A timer started when sending a registration request 1541 to the local ENRP server, normally set to 30 seconds. 1543 T3-registration-reattempt - If the registration cycle does not complete 1544 this timer is begun to restart the registration process. Normal value 1545 for this timer is 10 minutes. 1547 T4-reregistration - This timer is started after successful registration 1548 into the ASAP name space and is used to cause a re-registration at a 1549 periodic interval. This timer is normally set to 10 minutes. 1551 4.3 Thresholds 1553 Max-endpoint-sanity-failures --- pre-set threshold for 1554 Endpoint-sanity-failures. 1556 Max-endpoint-report-failures --- pre-set threshold for 1557 Endpoint-report-failures. 1559 Max-time-last-heard --- pre-set threshold for Peer-last-heard. 1561 Max-time-no-response --- pre-set threshold for a peer server to answer 1562 a PEER_PRESENCE message with reply required. 1564 Timeout-registration --- pre-set threshold; how long an endpoint will 1565 wait for the REGISTRATION_RESPONSE from its home ENRP server. 1567 Timeout-server-hunt --- pre-set threshold; how long an endpoint will 1568 wait for the REGISTRATION_RESPONSE from its home ENRP server. 1570 num-of-serverhunts - The current count of server hunt messages that 1571 have been transmitted. 1573 registration-count - The current count of attempted registrations. 1575 max-reg-attempt - The maximum number of registration attempts to be 1576 made before a server hunt is issued. 1578 max-request-retransmit - The maximum number of attempts to be made 1579 when requesting information from the local ENRP server before 1580 a server hunt is issued. 1582 5. References 1584 [SCTP] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, 1585 T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, "Stream 1586 Control Transmission Protocol," , October 2000. 1588 [ASAP] Q. Xie, R. R. Stewart "Aggregate Server Access Protocol", 1589 draft-stewart-rserpool-asap-00.txt, work in progress. 1591 6. Acknowledgements 1593 The authors wish to thank John Loughney, Lyndon Ong, and 1594 Maureen Stillman and many others for their invaluable comments. 1596 7. Authors' Addresses 1598 Randall R. Stewart 1599 24 Burning Bush Trail. 1600 Crystal Lake, IL 60012 1601 USA 1603 Phone: +1-815-477-2127 1604 EMail: rrs@cisco.com 1606 Qiaobing Xie 1607 Motorola, Inc. 1608 1501 W. Shure Drive, #2309 1609 Arlington Heights, IL 60004 1610 USA 1612 Phone: +1-847-632-3028 1613 EMail: qxie1@email.mot.com