idnits 2.17.1 draft-xie-rserpool-enrp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1725 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 2 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. == There are 19 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack 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 1622, 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: 10 errors (**), 0 flaws (~~), 4 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 October 31,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 fault tolerant 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 fault tolerant 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 1. Introduction 45 1.1 Motivation 46 1.1.1 CORBA and Its Limitations 47 1.1.2 DNS and Its Limitations 48 1.2 Protocol overview 49 1.3 Organization of this document 50 1.4 Definitions 51 2. The ENRP interface 52 2.1 Functional Summary 53 2.1.1 Basic ENRP Operations 54 2.1.1.1 Endpoint Registration 55 2.1.1.2 Endpoint De-registration 56 2.1.1.3 Name Translation 57 2.1.1.4 Server Name Space Update 58 2.1.1.4.1 Addition of a New DDP Endpoint 59 2.1.1.4.2 Removal of a DDP Endpoint 60 2.1.1.4.3 Removal of a DDP Endpoint with no Ownership 61 2.1.1.4.4 Update Endpoint Attributes 62 2.1.1.4.5 Claim Endpoint Ownership 63 2.1.1.4.6 Report Endpoint Failure 64 2.1.1.5 Endpoint Change Routing Value 65 2.1.1.6 Server Down Load Name Space from a Peer 66 2.1.1.7 Server Monitor Peer Status 67 2.1.1.8 Server Down Load Peer List 68 2.1.1.9 Endpoint Initialization 69 2.1.1.10 Server Initialization 70 2.1.2 Fault Management Operations 71 2.1.2.1 Detect and Report Unreachable Endpoint 72 2.1.2.2 ENRP Server Heartbeat 73 2.1.2.3 ENRP Server Hunt 74 2.1.2.4 ENRP Server Detect and Take-over Inactive Peer 75 2.1.2.5 Register Homeless Endpoints 76 2.1.3 Maintenance Operations 77 2.1.3.1 Forceful Removal of Endpoint 78 2.1.3.2 Dump Home Endpoint List 79 2.1.3.3 Dump Remote Endpoint List 80 2.1.3.4 Dump Peer Server List 81 3. Message Summary 82 3.1 Endpoint Entry 83 3.2 PEER_NAME_TABLE_REQUEST message 84 3.3 PEER_NAME_TABLE_RESPONSE message 85 3.4 PEER_LIST_REQUEST message 86 3.5 PEER_LIST_RESPONSE message 87 3.6 PEER_NAME_UPDATE message 88 3.7 PEER_PRESENCE message 89 3.8 TAKEOVER_INITIATE message 90 3.9 TAKEOVER_INITIATE_RESPONSE message 91 3.10 TAKEOVER_PEER_SERVER message 92 3.11 SERVER_DUMP message 93 3.12 SERVER_DUMP_RESPONSE message 94 4 Variables, Time Values, and Thresholds 95 4.1 Variables 96 4.2 Time values 97 4.3 Thresholds 98 5. References 100 1. Introduction 102 ENRP is designed to provide a fully distributed fault-tolerant 103 real-time translation service that maps a name to a set of transport 104 addresses pointing to a specific group of networked communication 105 endpoints registered under that name. ENRP employs a client-server 106 model with which an ENRP server will respond to the name translation 107 service requests from endpoint clients on both the local host and 108 remote hosts. 110 This document defines ENRP client-server interface and the 111 ENRP server functionalities, including the establishment and 112 management of a fully distributed fault-tolerant endpoint name space. 114 1.1 Motivation 116 In this section, we will discuss the motivation for developing 117 ASAP. Our discussion will be focused on the analysis of the 118 inadequateness of two existing technologies, namely CORBA and DNS, 119 in providing solutions to fault-tolerance design of IP distributed 120 applications. 122 1.1.1 CORBA and Its Limitations 124 Often referred to as a Distributed Processing Environment (DPE), 125 CORBA was mainly desinged to provide location transparency for 126 distributed applications. However, the following limitations may exist 127 when applying CORBA to the design of real time fault-tolerant system: 129 1) CORBA is traditionally weak in fault tolerance. The recent 130 development of a fault tolerant version of CORBA by OMG is perhaps 131 a step in the right direction towards fixing this 132 weakness. Nevertheless, the maturity, implementablity, and 133 real-time performance of the design is yet to be proven. 135 [Editor's Note: the fault tolerance mechanism being developed by 136 OMG for CORBA bears quite some similarities to ASAP.] 138 2) CORBA's distribution model encourages an object-based view, 139 i.e., each communication endpoint is normally an object. We 140 consider this kind of granularity too fine to be efficient and 141 effective for designing real-time fault-tolerant applications. 143 3) CORBA in general has a large signature that makes the use of it a 144 challenge in real-time environments. Small devices with limited 145 memory and CPU resource (e.g., H323 or SIP terminals) will find 146 CORBA hard to fit in. 148 4) CORBA uses TCP as its transport (Note, some effort is currently 149 underway to separate CORBA from its transport). This makes CORBA 150 suffer from the same limitations of TCP in terms of real-time and 151 fault-tolerance performance. 153 5) CORBA has long lacked easily usable support for the asynchronous 154 communication model, and this may be an issue in many 155 applications. An apparently improved API for asynchronous 156 communication has been added to the CORBA standards only recently, 157 and many, if not most, CORBA implementations still do not support 158 it. There is as yet insufficient user experience with it to make 159 conclusions regarding this new feature's usability. 161 1.1.2 DNS and Its Limitations 163 Undoubtedly DNS is the best-known and proven IP namespace mechanism. 164 However, namespace function alone does NOT provide real time 165 fault-tolerance solution. Other mechanisms and procedures, such as 166 server process failure detection, back-up server control and 167 selection, fast fail-over/switch-over, load balancing, etc., also play 168 crucial roles. These functions are supported by ASAP but not by DNS 169 DNS provides a loose binding where as ASAP and ENRP are designed to 170 provide a tight binding. 172 As will be further elaborated later in this document, the fault 173 tolerant design for server pools is made up in two parts, namely ASAP 174 and ENRP, where ENRP defines a light-weight yet highly efficient 175 namespace mechanism optimized for building real time fault-tolerant 176 applications. Nevertheless, ASAP does not restrict itself to ENRP for 177 namespace services. In fact, it is not only feasible but also 178 desirable in the future to generalize ASAP design so that the ENRP can 179 provide a generic interface that is capable of inter-working with 180 different namespace, including DNS, at the ASAP implementor's choice. 182 In the following, we list some limitations of the current DNS 183 namespace capability when compared to that of ENRP: 185 1) DNS name registration and translation services have been primarily 186 optimized for host names. But we consider namespace services 187 optimized for process names or endpoint names more appropriate and 188 efficient for supporting real time server-level fault-tolerance 189 applications. 191 2) DNS is primarily passive. It provides a query/response database 192 that allows one to find information, but does NOT provide 193 monitoring of hosts or processes to assure consistency within 194 its database. 196 3) DNS has dynamic extensions but is not designed around the 197 dynamic fast changing process address space that is typical to 198 real time distributed applications. 200 It has also been suggested that ASAP be extended to work with DNS to 201 bridge multiple ASAP planes and provide an "inter-ASAP-Domain" bridging 202 function. 204 1.2 Protocol overview 206 At startup, each endpoint in a ASAP operational domain registers its 207 name to the name space. Here a name is defined as a NULL terminated 208 ASCII string of fixed length. 210 When sending a message, the sender addresses the receiver endpoint by 211 its name and passes the message to its ASAP layer. The ASAP layer, with 212 the help from the ENRP name space daemon server(s), translates the 213 name to a valid transport address (or a list of transport addresses if 214 the receiver is multi-homed) and route the message to the receiving 215 endpoint. 217 The following diagram illustrates the components of ASAP and their 218 relationships. 220 Figure 1. 222 Data Sender Data Receiver 223 ENRP (ASAP-user) (ASAP-user) 224 Server +---------+ +---------+ 225 | ASAP |<---//---->| ASAP | 226 +------+ |------+ | |------+ | 227 <----->| ENRP |<---->| ENRP | | | ENRP | | 228 To peer +------+ +---------+ +---------+ 229 ENRP server| SCTP | | SCTP | | SCTP | 230 +------+ +---------+ +---------+ 231 | IP | | IP | | IP | 232 +------+ +---------+ +---------+ 233 |_______________|_____________________| 235 Multiple endpoints can register themselves under the same name. In 236 that case they will be treated as a receiver pool, and ASAP, when 237 routing a message destined to that name, will use a predefined 238 load-sharing policy to determine which endpoint(s) in the pool will 239 receive the message. 241 ASAP design has a high emphasis on seamless support of "server 242 pooling", system fault tolerance, dynamic scalability, and 243 close-to-real-time name translation. 245 In particular, ASAP can be characterized by: 247 A) Seamless support of "server pooling" --- ASAP allows multiple 248 servers to register under the same name. It also allows servers to 249 be dynamically add to or remove from a server pool without any 250 reconfiguration. 252 B) Support automatic receiver "fail-over" --- when the chosen message 253 receiver fails, ASAP, with pre-stated permission from its upper 254 layer, can automatically re-direct the message to an alternative 255 server under the same name if one exists. 257 C) Transaction management by nickname or "association handle" --- this 258 is to allow a continuous transaction or session consisting of 259 multiple interactions be held between a client endpoint and and one 260 particular server in a server pool. 262 Note: For details on ASAP please see [ASAP]. 264 D) Fully distributed name space --- For achieving a high degree of 265 fault tolerance and operation efficiency, the ENRP daemons which 266 provide name translation service and the name space data are 267 distributed across the operational scope of the network. 269 ENRP daemon servers can be added to or removed from the operation 270 scope dynamically, without interrupting the current name translation 271 service. 273 For example, a node may be originally configured to operate without a 274 local ENRP server. When the load condition changes, one can start a 275 new ENRP server on that node to increase the operation capacity. The 276 new ENRP server will automatically integrate itself with the existing 277 ENRP server(s) in the scope. 279 Similarly, when an ENRP server becomes unavailable for service (e.g., 280 being intentionally shutdown, or suffered failure), its ASAP clients 281 will be automatically taken-over by a remote ENRP server and 282 continuously be served. 284 E) Network failure detection and automatic recovery --- In the case 285 when a major network failure breaks the operation scope into 286 isolated communication islands, the name translation service will 287 survive and continue inside each island so long as there is one or 288 more ENRP servers present in that island. Endpoints inside each 289 island will still continue to be able to communicate with each other. 290 Moreover, when the network recovers, the isolated ENRP servers will 291 re-discover each other and re-integrate the name space back into 292 its original form. 294 Figure 2. shows an example of distributed applications operating in a 295 scope that is connected by a pare of redundant networks. 297 Figure 2. 299 Node 1 Node 2 300 +--------------+ || +--------------+ 301 | | || || | | 302 | Apps1 | |+===||==| | 303 | | || || | Apps2 | 304 | |===+| || | | 305 | Apps2 | || |+==| Apps3 | 306 | | || || | | 307 | |========+| | | 308 | (ENRP Svr) | || || | (ENRP Svr) | 309 +--------------+ || || +--------------+ 310 || || 311 Node 3 || || Node 4 312 +--------------+ || || +--------------+ 313 | | || || | | 314 | Apps2 | || || | | 315 | |========+| | Apps3 | 316 | | || || | | 317 | Apps4 | || || | | 318 | |===+| |+==| Apps1 | 319 | | || || | | 320 | (ENRP Svr) | |+===||==| | 321 +--------------+ || || +--------------+ 322 || || 323 network1 network2 325 In this example, there are four nodes in the scope, as shown in Figure 326 2. On Node 1, Node 2, and Node 3, there is an ENRP server running. On 327 each of the nodes, there are also some applications running. Each 328 application has a registered name in the name space collectively 329 managed by the three ENRP servers. In the example, the registered 330 names are "Apps1", "Apps2", "Apps3", and "Apps4". Some of the 331 applications (Apps1, Apps2, and Apps3) are distributed as server 332 pools. 334 When sending messages to each other, the sender application simply 335 addresses the recipient by its registered name. The ASAP layer inside 336 the sender application will query its home ENRP server to obtain the 337 transport address(es) and load control information of the recipient 338 before sending the message out. 340 Also note in the example, there is no ENRP server on Node 4. But the 341 applications on Node 4 will be served by one of the ENRP servers on 342 other nodes. 344 1.3 Organization of this document 346 Chapter 2 entails the ENRP description. ENRP defines the messaging 347 structure and relevant rules for communications between an ASAP 348 endpoint and an ENRP server. This chapter discusses how ENRP maintains 349 the name space in a fault tolerant manner. Chapter 3 defines the 350 message format and structures used by ENRP (in conjunction with those 351 used by ASAP). Chapter 4 provides settable protocol values. 353 1.4 Definitions 355 This document uses the following terms: 357 Operation scope --- the part of the network visible by ENRP. 359 ASAP Endpoint --- a logical entity in the operation scope which 360 implements the ASAP stack and is capable of sending and receiving 361 messages. 363 ASAP Node --- a host machine in the network which contains one or 364 more ASAP endpoints. 366 Endpoint name --- the registered tag of a ASAP endpoint, consisting of 367 a NULL terminated ASCII string of fixed length. 369 Named group --- a group of ASAP endpoints sharing the same endpoint 370 name in the name space. 372 Endpoint handle --- a logical pointer, consisting of a name and the 373 primary destination transport address to a particular endpoint in a 374 named group. 376 ENRP client --- a ASAP endpoint using ENRP to obtain name translation 377 and other related services. In this document, the term "ASAP endpoint" is 378 exchangeable with "ENRP client", unless otherwise stated. 380 ENRP maintenance client --- a ASAP endpoint that has the additional 381 capability of exchanging ENRP maintenance messages with an ENRP 382 server in order to perform certain maintenance functions. 384 ENRP server --- a server program running on a node that manages the 385 name space collectively with its peer ENRP servers and replies to the 386 service requests from any ENRP client. 388 Home ENRP server --- the ENRP server to which an endpoint currently 389 belongs. Endpoints normally choose the ENRP server on their local 390 host as the home ENRP server, if one exists. An endpoint shall only 391 have one home ENRP server at any given time, and both the endpoint and 392 the server shall keep track of this master/slave relationship between 393 them. 395 ENRP server takeover --- the event that a remote ENRP server takes the 396 ownership of all the ENRP endpoints on a node and becomes their home 397 server. 399 Caretaker ENRP server --- The ENRP server on a remote node which takes 400 ownership of all endpoints on the local node because of the absence of 401 an active local server. 403 ENRP client channel --- the communication channel through which a ASAP 404 endpoint requests for ENRP service. The ENRP client channel is usually 405 defined by the transport address of the home server and a well known 406 port number. 408 ENRP server channel --- defined by a well known multicast IP address 409 and a well known port number. All ENRP servers in an operation scope 410 can communicate with one another through this channel. Endpoints are 411 also allowed to communicate on this channel occasionally. 413 ENRP name domain --- defined by the combination of the ENRP client 414 channel and the ENRP server channel in the operation scope. 416 Network Byte Order: Most significant byte first, a.k.a Big Endian. 418 2. The ENRP interface 420 This section discusses the messages and procedures for communicating 421 between the ASAP layer of a ASAP endpoint and an ENRP name space server, 422 as well as that between peer ENRP servers. 424 2.1 Functional Summary 426 In this section, we discuss the functions defined by ENRP. The 427 functions are divided into three groups, namely the basic ENRP 428 operations, fault management, and control and maintenance functions. 430 Most of the ENRP operations involve message exchanges between an ENRP 431 server and a ASAP endpoint, as well as message exchanges between the 432 ENRP server and its peers. Some of the ENRP message formats are 433 also found in [ASAP] 435 2.1.1 Basic ENRP Operations 437 2.1.1.1 Endpoint Registration 439 ENRP server <-> endpoint: 441 A ASAP endpoint shall send a REGISTRATION message, over the ENRP client 442 channel, to its home ENRP server, in order to register itself with the 443 name space. 445 In the REGISTRATION message, the endpoint shall indicate its name in 446 the form of a character string, network access information (e.g., a 447 list of valid transport addresses with which the endpoint 448 can be reached), and load control information. 450 The ENRP server shall handle the REGISTRATION message following the 451 rules listed below: 453 o If the name does not exist in the name space, the ENRP server shall 454 create the name and add the new endpoint under that name. 456 o If the name already exists in the name space, the requesting 457 endpoint shall be added under the same name and be made a member of 458 the named group. 460 o If both the name and the requesting endpoint already exist in the 461 name space, i.e., a case of duplicated registration, the ENRP 462 server shall grant the request without taking any further actions. 464 o The ENRP server may reject the registration due to reasons such as 465 invalid values, lack of resource, etc. 467 In all the above cases, if the REGISTRATION request is granted, the 468 ENRP server shall assume the ownership of the requesting endpoint. 470 In response, the home ENRP server shall reply to the requesting 471 endpoint with a REGISTRATION_RESPONSE message, and shall indicate in 472 the message body whether the registration is granted or rejected. 474 ENRP server <-> peers: 476 If the registration request is not a duplicate and is granted, the 477 home ENRP server shall take the name space modification action 478 described in section 3.1.1.8??. Otherwise, no message shall be 479 exchanged with its peers. 481 2.1.1.2 Endpoint De-registration 483 ENRP server <-> endpoint: 485 A ASAP endpoint shall send a DEREGISTRATION message, over the ENRP 486 client channel, to its home ENRP server in order to remove itself from 487 the name space. 489 If the endpoint is the last one under that name in the name space the 490 home ENRP server shall remove the name from its space as well. 492 The ENRP server may reject the de-registration request due to reasons 493 such as invalid parameters, etc. 495 In response, the home ENRP server shall send a REGISTRATION_RESPONSE 496 message to the endpoint, and shall indicate in the message body 497 whether the request is granted or rejected. 499 It should be noted that de-registration does not stop the ASAP endpoint 500 from sending or receiving messages. It only means that other ASAP 501 endpoints will no longer be able to send message to that endpoint by 502 name. 504 ENRP server <-> peers: 506 Once the de-registration request is granted and the endpoint removed 507 from its local copy of the name space, the home ENRP server shall take 508 the name space modification action described in section 2.1.1.9. 510 2.1.1.3 Name Translation 512 ENRP server <-> endpoint: 514 An endpoint shall send a NAME_REQUEST messages to its home ENRP server 515 to get a name translation service. In the NAME_REQUEST message, the 516 endpoint shall include the name it wants to be translated. 518 If the name exits in the name space, the ENRP server shall send back a 519 NAME_INFORMATION message that shall carry all information of the ASAP 520 endpoint(s) currently registered under that name, including current 521 load control policy of the group, routing value of each endpoint in 522 the group, and a list of transport addresses for each endpoint in the 523 group with which the endpoint can be reached, etc. 525 If the name does not exist in the name space, the ENRP server shall 526 respond with a NAME_UNKNOWN message. 528 ENRP server <-> peers: 530 None. 532 2.1.1.4 Server Name Space Update 534 This includes a set of update operations used by an ENRP server to 535 inform its peer(s) the addition a new ASAP endpoint, removal of an 536 existing ASAP endpoint, change property of a named group, etc. 538 2.1.1.4.1 Addition of a New ASAP Endpoint 540 When a new ASAP endpoint is granted registration to the name space, the 541 home ENRP server uses this procedure to inform all its peers. 543 ENRP server <-> endpoint: 545 None: 547 ENRP server <-> peers: 549 An ENRP server shall multicast over the ENRP server channel a 550 PEER_NAME_UPDATE message with the appropriate flag set to indicate to its 551 peers about the addition of the new endpoint to the name space. 553 Upon the reception of this PEER_NAME_UPDATE message, each of the peer ENRP 554 servers shall take the following actions: 556 o If the name does not exist in its local copy of the name space, the 557 peer ENRP server shall create the name and add the new endpoint 558 under that name in its local name space copy, along with other 559 attributes about the endpoint carried in the message. 561 o If the name already exists in the peer server's local copy of the 562 name space, the new endpoint endpoint shall be added as a new member 563 of the named group. 565 o If both the same ASAP endpoint already exists in the named group in 566 the local copy of the name space of the peer, the peer ENRP server 567 shall take no actions. 569 After adding the endpoint into its local copy of name space, the peer 570 ENRP server shall check if this endpoint is located on the same host 571 as the peer ENRP server itself does. If so, the peer ENRP server shall 572 assume the ownership of the endpoint, and take the ?? actions 573 described in section 2.1.1.12??. 575 2.1.1.4.2 Removal of a ASAP Endpoint 577 This procedure is used by an ENRP server to inform its peer(s) to 578 remove an existing ASAP endpoint, regardless of the ownership of the 579 endpoint. 581 ENRP server <-> endpoint: 583 None: 585 ENRP server <-> peers: 587 The ENRP server shall multicast over the ENRP server channel a 588 PEER_NAME_UPDATE message with the appropriate flag set to instruct its 589 peers to remove of the endpoint from their local copy of the name 590 space. 592 On the reception of this PEER_NAME_UPDATE message, each peer ENRP 593 server shall find and remove the ASAP endpoint from its local copy of 594 the name space regardless whether or not it has ownership on the 595 endpoint. 597 2.1.1.4.3 Removal of a ASAP Endpoint with no Ownership 599 This operation is used by an ENRP server to instruct its peers to 600 remove an existing ASAP endpoint which the peer does not have an 601 ownership on. 603 ENRP server <-> endpoint: 605 None: 607 ENRP server <-> peers: 609 An ENRP server shall multicast over the ENRP server channel a 610 PEER_NAME_UPDATE message with the appropriate flag set to instruct its 611 peers to remove the specified endpoint from its local copy of the name 612 space IF the peer does not have ownership on the endpoint. 614 On the reception of this PEER_NAME_UPDATE message, a peer ENRP server 615 shall find and remove the endpoint from its local copy of the name 616 space only if the peer server does not own this endpoint. 618 2.1.1.4.4 Update Endpoint Attributes 620 This operation is used by an ENRP server to inform its peers to update 621 the attributes of an existing ASAP endpoint. 623 ENRP server <-> endpoint: 625 None: 627 ENRP server <-> peers: 629 An ENRP server shall multicast over the ENRP server channel a 630 PEER_NAME_UPDATE message with the appropriate flag set to instruct 631 its peers to replace the attributes of an existing ASAP endpoint in its 632 local copy of the name space. 634 On the reception of this PEER_NAME_UPDATE message, a peer ENRP server 635 shall replace the attributes of the existing endpoint with the new 636 information carried in the message if the endpoint exists in its local 637 copy of the name space. If the specified endpoint is not found in its 638 local name space copy, the peer server shall add the endpoint 639 following the steps in Section 2.1.1.4.1??. 641 2.1.1.4.5 Claim Endpoint Ownership 643 This operation is used by an ENRP server to claim the ownership on a 644 specific endpoint and to inform its peers about its claim. 646 ENRP server <-> endpoint: 648 An ENRP server shall send an ENDPOINT_KEEP_ALIVE message to the 649 endpoint. This message will cause the endpoint to adopt this ENRP 650 server as its new home ENRP server (see Section 2.5.3). 652 ENRP server <-> peers: 654 An ENRP server shall multicast over the ENRP server channel a 655 PEER_NAME_UPDATE message with the appropriate flag set to inform its 656 peers that it has taken the ownership of the specified endpoint. 658 Upon the reception of this PEER_NAME_UPDATE message, a peer server 659 shall check whether it is the current owner of the endpoint. If so, 660 this peer server shall relinquish its ownership on that 661 endpoint. Otherwise, no action is needed. 663 2.1.1.4.6 Report Endpoint Failure 665 This operation is used by an ENRP server to warn its peers that it has 666 noticed a potentially unreachable endpoint that the server does not 667 have ownership on. 669 ENRP server <-> endpoint: 671 None: 673 ENRP server <-> peers: 675 An ENRP server shall multicast over the ENRP server channel a 676 PEER_NAME_UPDATE message with the appropriate flag set to indicate 677 that the specified ASAP endpoint is potentially unreachable. 679 On the reception of this message, each peer ENRP server shall check 680 whether it owns the specified endpoint. If it does, the peer server 681 shall increase the counter of the specified 682 endpoint by 1. If the value of the counter 683 has exceeded the protocol parameter Max-Endpoint-Report-Failures, the 684 peer server shall remove the endpoint from its local name space and 685 take actions described in Section 2.1.1.4.3. If the peer server does 686 not own the specified endpoint, it shall take no action. 688 2.1.1.5 Endpoint Change Routing Value 690 A ASAP endpoint can modify its routing value at any time. Depending on 691 the current number of members in the named group and the routing 692 policy, this operation allows the ASAP endpoint to control its share of 693 inbound messages received within the named group dynamically (also see 694 Section 2.1.5.1 for more on load control). 696 ENRP server <-> endpoint: 698 A ASAP endpoint shall send an UPDATE_ROUTING_VALUE message over the 699 ENRP client channel to its home ENRP server in order to modify its 700 routing value. The new routing value shall be indicated in the 701 message. 703 Upon the reception of this UPDATE_ROUTING_VALUE message, the home ENRP 704 server shall replace the routing value of that endpoint in its local 705 copy of the name space with the new value indicated in the message. 707 ENRP server <-> peers: 709 If the update on its local copy of the name space is successful, the 710 home ENRP server shall take the Server Name Space Update actions as 711 described in Section 2.1.1.4.4. 713 2.1.1.6 Server Down Load Name Space from a Peer 715 This operation allows an ENRP server to request and receive a copy of 716 a specific portion of the name space from one of its peer ENRP servers. 717 This is useful for a newly started ENRP server to initiate its local 718 copy of the name space, or for correcting name space inconsistency. 720 ENRP server <-> endpoint: 722 None. 724 ENRP server <-> peers: 726 An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message 727 directly to one of its peers. In the message, it shall indicate which 728 portion of the name space is requested. 730 Upon the reception of this message, the peer server shall initiate a 731 download session in which the requested portion of the name space 732 shall be sent to the requesting ENRP server in one or more 733 PEER_NAME_TABLE_RESPONSE messages. 735 If the sending ENRP server determines that multiple 736 PEER_NAME_TABLE_RESPONSE messages are needed for the session, it shall 737 set the appropriate flag in each PEER_NAME_TABLE_RESPONSE message to 738 inform the receiving ENRP server whether or not the data in this 739 message is the last piece of the transfer. 741 Every time the requesting ENRP server receives a 742 PEER_NAME_TABLE_RESPONSE message, it shall transfer the data entries 743 carried in the message into its local name space database, and then 744 check whether or not the data in this message is the last piece to be 745 transfered. If more data transfer is indicated, the requesting ENRP 746 server shall send another PEER_NAME_TABLE_REQUEST message to the same 747 peer to prompt for the next piece. 749 When transferring the data entries from the PEER_NAME_TABLE_RESPONSE 750 message into its local name space database, the requesting ENRP server 751 shall follow the same procedures as described in section 2.1.1.4.1 752 when parsing through the endpoints carrying in the message one by one. 754 2.1.1.7 Server Monitor Peer Status 756 ENRP server <-> endpoint: 758 None: 760 ENRP server <-> peers: 762 An ENRP server shall keep a record on the status of each of its peers. 764 If a message of any type is received from a peer, the server shall 765 update that peers status as . If a message of any type is 766 received from a peer previously unknown to this server, i.e., a new 767 peer, the server shall create a record for the new peer and mark the 768 new peer as . 770 2.1.1.8 Server Down Load Peer List 772 This operation allows an ENRP server to request from a peer server a 773 copy of its internal peer list. This is useful for a new ENRP server 774 to initiate its own peer list at startup. 776 ENRP server <-> endpoint: 778 None. 780 ENRP server <-> peers: 782 An ENRP server shall send a PEER_LIST_REQUEST message to a peer to 783 request a copy of its peer list. 785 Upon the reception of this message, the peer server shall reply with a 786 PEER_LIST_RESPONSE message and include in the message body a copy of its 787 internal peer list, if the peer itself is in operational state. 789 If the peer itself is in the process of startup, it shall response 790 with a PEER_LIST_RESPONSE message but set the appropriate flag to 791 indicate that it can not grant the PEER_LIST_REQUEST. In such a case, 792 the requesting ENRP server shall select another peer and repeat the 793 peer list request with the new peer at a later time. 795 2.1.1.9 Endpoint Initialization 797 At startup, a ASAP endpoint shall always assume the existence of a local 798 ENRP server on the local host and mark it as its home ENRP server, and 799 initiate the registration procedure described in 2.1.1.1??. 801 2.1.1.10 Server Initialization 803 At startup, before getting into service, an ENRP server (initiating 804 server) shall multicast a PEER_PRESENCE message with reply required 805 flag set over the ENRP server channel, in order to inform any other 806 active peers in the operation scope about its presence. 808 Upon the reception of this message, a peer shall send a PEER_PRESENCE 809 without reply required flag back to the initiating server, in order to 810 help the initiating server to build its peer list. 812 If no response to its PEER_PRESENCE message are received, the 813 initiating server shall assume that it is alone in the operation scope 814 and shall mark the initialization process as completed. 816 If there are responses to its PEER_PRESENCE message, the initiating 817 server shall then take the actions described in 2.1.1.8 to request a 818 peer list from one of the peers that have responded. 820 Upon the reception of the PEER_LIST_RESPONSE message from that peer, 821 the initiating server shall use the information carried in the message 822 to build a complete peer list, including both active and inactive 823 peers in the operation scope. 825 Then, the initiating server shall perform a name database download, as 826 described in 2.1.1.6, with each of the active peers on the peer list, 827 indicating that the portion of the name database to download shall 828 only include the endpoints owned by that peer. 830 Moreover, the initiating server shall also pick one of the active peer 831 and request to that peer for a download of the table of remote 832 endpoints. 834 2.1.2 Fault Management Operations 836 The following operations are used to detect and recover from various 837 system faults. 839 2.1.2.1 Detect and Report Unreachable Endpoint 841 Two mechanisms exist to detect and report an unreachable ASAP endpoint: 843 1) Home ENRP server periodic sanity check 845 An ENRP server shall send, in every seconds, 846 an ENDPOINT_KEEP_ALIVE message to each of the endpoints it owns, and 847 shall keep the number of consecutive failed send attempts in the 848 counter of that endpoint. 850 If the value of of an endpoint exceeds the 851 pre-set threshold Max-endpoint-sanity-failures, the home ENRP server 852 shall remove the endpoint from its copy of the name database and take 853 the actions described in section 2.1.1.4.3 to inform its peers. 855 The handling of the ENDPOINT_KEEP_ALIVE message by the endpoint is 856 described in Section 2.5.3??. 858 2) Detection by peer endpoints 860 Whenever a ASAP endpoint finds a peer unreachable (e.g., via an SCTP 861 SEND.FAILURE Notification, see Section 2.2.5??), the endpoint shall 862 send an ENDPOINT_UNREACHABLE message over the ENRP client channel to 863 its home ENRP server. The message shall contain one of the transport 864 addresses of the unreachable peer and have the severity flag set to 865 NORMAL_REPORT. 867 Upon the reception of this message, the home ENRP server shall first 868 check whether it owns the unreachable endpoint. If not, the server 869 shall take the actions described in section 2.1.1.4.6??. 871 Otherwise, the server shall increase the 872 counter of the unreachable endpoint by 1. If the value of the 873 counter has exceeded 874 Max-endpoint-report-failures, the server shall remove the endpoint 875 from its name database and take actions described in 2.1.1.4.3??. 877 2.1.2.2 ENRP Server Heartbeat 879 An ENRP server shall multicast, in every 880 seconds, a PEER_PRESENCE message over the ENRP server channel to 881 inform its peers that it is still operational. In the PEER_PRESENCE 882 message, the sending ENRP server shall set the appropriate flag to 883 indicate that no reply is required. 885 >From time to time, an ENRP server may also send a point-to-point 886 PEER_PRESENCE message to a specific peer server, with the flag setting 887 in the message indicates that a reply is required. In such a case, the 888 peer server shall immediately respond to the sender with its own 889 point-to-point PEER_PRESENCE message, and shall indicate in the 890 message that no reply is required. 892 2.1.2.3 ENRP Server Hunt 894 An endpoint shall initiate the following home server hunt procedure if 895 it fails to send to, or times out on a service request with its 896 current home server. 898 In the home server hunt procedure, the endpoint shall multicast a 899 SERVER_HUNT message over the ENRP client channel, and shall repeat 900 sending this message every seconds until a 901 SERVER_HUNT_RESPONSE message is received from an ENRP server. Each 902 time the 'Timeout-server-hunt' timer expires the criticality should 903 be raised (initially criticality should be set to LOW_CRITICALITY). 905 Then the endpoint shall pick one of the servers that have responded as 906 its new home server, and continue the service request with that 907 server. 909 Upon the reception of the SERVER_HUNT message, a server shall reply to 910 the endpoint with a SERVER_HUNT_RESPONSE message, unless: 912 1) its peer status information indicates that there is a caretaker 913 server other than itself for the node where the endpoint is from, 914 AND 916 2) the criticality flag in the SERVER_HUNT message is not 917 HIGH_CRITICALITY. 919 2.1.2.4 ENRP Server Detect and Take-over Inactive Peer 921 An ENRP server shall keep track the time when the last message 922 (multicast or point-to-point) was received from each known peer. 924 If a peer has not been heard for more than Max-time-last-heard, the 925 ENRP server shall send a point-to-point PEER_PRESENCE with reply 926 request to that peer. 928 If the send fails or the peer does not reply after 929 Max-time-no-response seconds, the ENRP server shall initiate the 930 following server take-over procedures: 932 1) Initiate Server Take-over Arbitration 934 The ENRP server (the initiating server) shall initiate a take-over 935 arbitration on the inactive peer (the target server) by multicasting a 936 TAKEOVER_INITIATE message over the ENRP server channel. In the 937 message, the initiating server shall specify the identification of the 938 target server. 940 After multicasting the TAKEOVER_INITIATE message, the initiating 941 server shall wait for a TAKEOVER_INITIATE_RESPONSE message from each 942 of its active peers. 944 Upon the reception of this message, other peer servers shall take the 945 following actions accordingly: 947 o If the peer server finds that itself is the target server indicated 948 in the TAKEOVER_INITIATE message, it shall immediately multicast a 949 PEER_PRESENCE message over the ENRP server channel in an attempt of 950 stopping the take-over process. 952 o If the peer server finds that itself has also initiated a take-over 953 process on the same target server and its IP address is smaller in 954 value than that of the sender of the TAKEOVER_INITIATE message, it 955 shall abort its own take-over process. 957 o Peers other than the target peer and the peer that is taking-over 958 shall mark the target server as and mark the initiating 959 server as the caretaker of the target server and reply to the 960 initiating server with a TAKEOVER_INITIATE_RESPONSE message. 962 Once it has received TAKEOVER_INITIATE_RESPONSE message from all of 963 its active peers, the initiating server shall consider it won 964 the arbitration and shall then take the actions in 2) in order to 965 complete the take-over. 967 However, if it receives a PEER_PRESENCE from the target server at any 968 point of the take-over, the initiating server shall immediately abort 969 the take-over process and re-mark the target server as . 971 2) Take-over the target peer server 973 An ENRP server shall multicast a TAKEOVER_PEER_SERVER message over the 974 ENRP server channel in order to inform all its peers about the 975 take-over. In the message, identification of the inactive peer server 976 targeted for the take-over shall be included. 978 The server shall mark the target server as and mark itself 979 as the caretaker of the target server. 981 Then it shall assume ownership on each of the endpoints originally 982 owned by the target server. 984 The server shall also check whether there are any other inactive peers 985 which has designated the target server as their caretaker. The server 986 shall perform the above take-over procedure on each one of those 987 inactive peers as well. 989 2.1.2.5 Register Homeless Endpoints 991 When an ENRP server receives a REGISTRATION message from an endpoint 992 located on a remote node, it shall always accept and grant the 993 registration, unless its peer status information indicates that the 994 peer on that node is inactive and a caretaker other than itself exists 995 for that node. In that case, the server shall reject the registration 996 and take no further actions. 998 If the server has no record about the peer on that node, the 999 server shall grant the registration and then create a record about 1000 that peer, mark it as inactive, and initiate a take-over procedure on 1001 it, as described in 2.1.2.4??. 1003 2.1.3 Maintenance Operations 1005 The following operations are used by an ENRP maintenance client to 1006 monitor the name space data and perform maintenances on ENRP servers 1007 in an operation scope. 1009 2.1.3.1 Forceful Removal of Endpoint 1011 A maintenance endpoint shall send a ENDPOINT_UNREACHABLE message to an 1012 ENRP server, in order to force the removal of another endpoint from 1013 the name space. The message shall contain one of the transport 1014 addresses of the target endpoint and have the severity flag set to 1015 FINAL_REPORT. 1017 Upon the reception of this message, the ENRP server shall immediately 1018 remove the target endpoint from its copy of the name database and take 1019 actions described in Section 2.1.1.4.2. 1021 2.1.3.2 Dump Home Endpoint List 1023 A maintenance endpoint shall send a SERVER_DUMP message with type flag 1024 set to HOME_LIST to a server, in order to require a copy of the 1025 information on all the endpoints owned by that server. 1027 Upon receiving this message, the server shall response with a 1028 SERVER_DUMP_RESPONSE message with the type flag set to HOME_LIST to 1029 the maintenance endpoint. In the message body, the server shall 1030 include information on all the endpoints the server currently owns. 1032 2.1.3.3 Dump Remote Endpoint List 1034 A maintenance endpoint shall send a SERVER_DUMP message with type flag 1035 set to REMOTE_LIST to a server, in order to require a copy of the 1036 information on all the endpoints NOT owned by that server. 1038 Upon receiving this message, the server shall response with a 1039 SERVER_DUMP_RESPONSE message with the type flag set to REMOTE_LIST to 1040 the maintenance endpoint. In the message body, the server shall 1041 include information on all the endpoints the server currently does NOT 1042 owns. 1044 2.1.3.4 Dump Peer Server List 1046 A maintenance endpoint shall send a SERVER_DUMP message with the type 1047 flag set to PEER_SERVER_LIST to a server, in order to require a copy 1048 of the peer list known to that server. 1050 Upon receiving this message, the server shall response with a 1051 SERVER_DUMP_RESPONSE message with the type flag set to 1052 PEER_SERVER_LIST to the maintenance endpoint. In the message body, the 1053 server shall include information on all the peers that server 1054 currently knows. 1056 3 Message Summary 1058 All messages as well as their fields described below shall be in 1059 Network Byte Order during transmission. For fields with a length 1060 bigger than 4 octets, a number in a pair of parentheses may follow the 1061 filed name to indicate the length of the field in number of octets. 1063 3.1 Endpoint Entry 1065 This field is used to represent a ASAP endpoint and the associated 1066 information, such as its transport address(es), load control, and 1067 other operational status information. 1069 The field is defined to support endpoint with up to 8 different 1070 transport addresses. 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | IP address #0 | 1076 +-------------------------------+-------------------------------+ 1077 | IP address #1 | 1078 +-------------------------------+-------------------------------+ 1079 \ \ \ \ 1080 / / / / 1081 \ \ \ \ 1082 +-------------------------------+-------------------------------+ 1083 | IP address #7 | 1084 +-------------------------------+-------------------------------+ 1085 | SCTP Port | Padding | 1086 +-------------------------------+-------------------------------+ 1087 | Routing Policy | Routing Value | 1088 +---------------+---------------+---------------+---------------+ 1090 The size of the endpoint entry is 40 octets. 1092 3.2 PEER_NAME_TABLE_REQUEST message 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | ENRP server message identifier #1 = 0x27047729 | 1098 +-------------------------------+-------------------------------+ 1099 | ENRP server message identifier #2 = 0x53829149 | 1100 +-------------------------------+-------------------------------+ 1101 | Type = 0x102 | 1102 +-------------------------------+-------------------------------+ 1103 | sending server's IP address | 1104 +-------------------------------+-------------------------------+ 1105 | sender's SCTP port | padding | 1106 +-------------------------------+-------------------------------+ 1107 | receiving server's IP address | 1108 +-------------------------------+-------------------------------+ 1109 | receiver's SCTP port | padding | 1110 +-------------------------------+-------------------------------+ 1111 | Table type = (see below) | 1112 +-------------------------------+-------------------------------+ 1114 Note, the receiver's IP address and port do not need to be filled in 1115 if the message is being multicasted. 1117 The requested table type shall take one of the following values: 1118 0x1 --- HOME_LIST: endpoints owned by the server. 1119 0x2 --- REMOTE_LIST: endpoint NOT owned by the server. 1121 3.3 PEER_NAME_TABLE_RESPONSE message 1123 0 1 2 3 1124 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 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | ENRP server message identifier #1 = 0x27047729 | 1127 +-------------------------------+-------------------------------+ 1128 | ENRP server message identifier #2 = 0x53829149 | 1129 +-------------------------------+-------------------------------+ 1130 | Type = 0x103 | 1131 +-------------------------------+-------------------------------+ 1132 | sender's IP address | 1133 +-------------------------------+-------------------------------+ 1134 | sender's SCTP port | padding | 1135 +-------------------------------+-------------------------------+ 1136 | receiver's IP address | 1137 +-------------------------------+-------------------------------+ 1138 | receiver's SCTP port | padding | 1139 +-------------------------------+-------------------------------+ 1140 | Table type = (see below) | 1141 +-------------------------------+-------------------------------+ 1142 | More to send = (see below) | 1143 +-------------------------------+-------------------------------+ 1144 | number of names = n | 1145 +-------------------------------+-------------------------------+ 1146 | | 1147 | Name entry 1 (see below) | 1148 | | 1149 +-------------------------------+-------------------------------+ 1150 / / 1151 \ \ 1152 / / 1153 +-------------------------------+-------------------------------+ 1154 | | 1155 | Name entry n (see below) | 1156 | | 1157 +-------------------------------+-------------------------------+ 1159 'Table type' shall take one of the following values: 1160 0x1 --- HOME_LIST: endpoints owned by the server. 1161 0x2 --- REMOTE_LIST: endpoint NOT owned by the server. 1163 'More to send' flag shall be set to 0x1 if there are more name entries 1164 to be sent for the requested table type. Otherwise, it shall be set to 1165 0x0. 1167 Each 'Name entry' represents an endpoint and shall consist of the 1168 following: 1170 +-------------------------------+-------------------------------+ 1171 | | 1172 | Endpoint name (32) | 1173 | | 1174 +-------------------------------+-------------------------------+ 1175 | number of endpoints = m | 1176 +-------------------------------+-------------------------------+ 1177 | | 1178 | endpoint entry 1 (40) | 1179 | | 1180 +-------------------------------+-------------------------------+ 1181 / / 1182 \ \ 1183 / / 1184 +-------------------------------+-------------------------------+ 1185 | | 1186 | endpoint entry m (40) | 1187 | | 1188 +-------------------------------+-------------------------------+ 1190 3.4 PEER_LIST_REQUEST message 1192 0 1 2 3 1193 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 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | ENRP server message identifier #1 = 0x27047729 | 1196 +-------------------------------+-------------------------------+ 1197 | ENRP server message identifier #2 = 0x53829149 | 1198 +-------------------------------+-------------------------------+ 1199 | Type = 0x10b | 1200 +-------------------------------+-------------------------------+ 1201 | sender's IP address | 1202 +-------------------------------+-------------------------------+ 1203 | sender's SCTP port | padding | 1204 +-------------------------------+-------------------------------+ 1205 | receiver's IP address | 1206 +-------------------------------+-------------------------------+ 1207 | receiver's SCTP port | padding | 1208 +-------------------------------+-------------------------------+ 1210 The receiver's IP address and port do not need to be filled in if 1211 the message is being multicasted. 1213 3.5 PEER_LIST_RESPONSE message 1215 This message shall contain all the peer information of the sending server. 1217 0 1 2 3 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | ENRP server message identifier #1 = 0x27047729 | 1221 +-------------------------------+-------------------------------+ 1222 | ENRP server message identifier #2 = 0x53829149 | 1223 +-------------------------------+-------------------------------+ 1224 | Type = 0x10c | 1225 +-------------------------------+-------------------------------+ 1226 | sender's IP address | 1227 +-------------------------------+-------------------------------+ 1228 | senders SCTP port | padding | 1229 +-------------------------------+-------------------------------+ 1230 | receiver's IP address | 1231 +-------------------------------+-------------------------------+ 1232 | receiver's SCTP port | padding | 1233 +-------------------------------+-------------------------------+ 1234 | responseIndication (see below) | 1235 +-------------------------------+-------------------------------+ 1236 | number of peers = n | 1237 +-------------------------------+-------------------------------+ 1238 | | 1239 | Peer entry 1 (see below) | 1240 | | 1241 +-------------------------------+-------------------------------+ 1242 / / 1243 \ \ 1244 / / 1245 +-------------------------------+-------------------------------+ 1246 | | 1247 | Peer entry n (see below) | 1248 | | 1249 +-------------------------------+-------------------------------+ 1251 The 'responseIndication' flag shall be set to 0x2 to indicate a 1252 rejection to the request, and no 'Peer entry' shall be attached if the 1253 request is rejected. 1255 Otherwise, the 'responseIndication' flag shall be set to 0x1 and n 1256 'Peer entries' attached. 1258 Each 'Peer entry' shall consist of the following fields: 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Peer's IP address | 1264 +-------------------------------+-------------------------------+ 1265 | Peer's SCTP port | padding | 1266 +-------------------------------+-------------------------------+ 1267 | Caretaker's IP address | 1268 +-------------------------------+-------------------------------+ 1269 | caretaker's SCTP port | padding | 1270 +-------------------------------+-------------------------------+ 1272 The peer's IP address and port number serve as the identification of 1273 that peer. If the peer is inactive, its caretaker's IP address and port 1274 number shall be filled in. Otherwise, the caretaker IP and port fields 1275 shall be set to zeros. 1277 3.6 PEER_NAME_UPDATE message 1279 0 1 2 3 1280 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 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | ENRP server message identifier #1 = 0x27047729 | 1283 +-------------------------------+-------------------------------+ 1284 | ENRP server message identifier #2 = 0x53829149 | 1285 +-------------------------------+-------------------------------+ 1286 | Type = 0x104 | 1287 +-------------------------------+-------------------------------+ 1288 | sender's IP address | 1289 +-------------------------------+-------------------------------+ 1290 | sender's SCTP port | padding | 1291 +-------------------------------+-------------------------------+ 1292 | receiver's IP address | 1293 +-------------------------------+-------------------------------+ 1294 | receiver's SCTP port | padding | 1295 +-------------------------------+-------------------------------+ 1296 | | 1297 | Endpoint name (32) | 1298 | | 1299 +-------------------------------+-------------------------------+ 1300 | | 1301 | endpoint entry (40) | 1302 | | 1303 +-------------------------------+-------------------------------+ 1304 | Update action (see below) | 1305 +-------------------------------+-------------------------------+ 1307 The receiver's IP address and port do not need to be filled in if 1308 the message is being multicasted. 1310 'Update action' shall take one of the following values: 1311 0x0 --- ADD_ENDPOINT: add a new endpoint, as specified by 'Endpoint 1312 name' and 'endpoint entry' fields, to the name space. 1313 0x1 --- DELETE_ENDPOINT: delete the named endpoint from the name 1314 database, if the receiving server owns the endpoint. 1315 0x2 --- REMOVE_ENDPOINT: remove the named endpoint from the name 1316 database, regardless who owns the endpoint. 1317 0x3 --- UPDATE_ENDPOINT: replace the endpoint's attributes with the 1318 new information carried in this message. 1319 0x4 --- ENDPOINT_FAILURE: warn the receiver that the named endpoint 1320 is potentially unreachable. 1321 0x5 --- CLAIM_ENDPOINT: inform the receiver that the sender has 1322 taken the ownership of the specified endpoint. 1324 3.7 PEER_PRESENCE message 1326 0 1 2 3 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | ENRP server message identifier #1 = 0x27047729 | 1330 +-------------------------------+-------------------------------+ 1331 | ENRP server message identifier #2 = 0x53829149 | 1332 +-------------------------------+-------------------------------+ 1333 | Type = 0x100 | 1334 +-------------------------------+-------------------------------+ 1335 | sender's IP address | 1336 +-------------------------------+-------------------------------+ 1337 | sender's SCTP port | padding | 1338 +-------------------------------+-------------------------------+ 1339 | receiver's IP address | 1340 +-------------------------------+-------------------------------+ 1341 | receiver's SCTP port | padding | 1342 +-------------------------------+-------------------------------+ 1343 | Reply required | 1344 +-------------------------------+-------------------------------+ 1346 The receiving server's IP address and port do not need to be filled in 1347 if the message is being multicasted. 1349 'Reply required' shall be set to 0x1 if response to this message is 1350 required, otherwise set to 0x0. 1352 3.8 TAKEOVER_INITIATE message 1354 0 1 2 3 1355 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 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | ENRP server message identifier #1 = 0x27047729 | 1358 +-------------------------------+-------------------------------+ 1359 | ENRP server message identifier #2 = 0x53829149 | 1360 +-------------------------------+-------------------------------+ 1361 | Type = 0x106 | 1362 +-------------------------------+-------------------------------+ 1363 | sending server's IP address | 1364 +-------------------------------+-------------------------------+ 1365 | sender's SCTP port | padding | 1366 +-------------------------------+-------------------------------+ 1367 | receiving server's IP address | 1368 +-------------------------------+-------------------------------+ 1369 | receiver's SCTP port | padding | 1370 +-------------------------------+-------------------------------+ 1371 | Target server's IP address | 1372 +-------------------------------+-------------------------------+ 1373 | Target server's SCTP port | padding | 1374 +-------------------------------+-------------------------------+ 1376 The receiving server's address and port do not need to be filled in if 1377 the message is being multicasted. 1379 'Target server's IP address and port number must be supplied. 1381 3.9 TAKEOVER_INITIATE_RESPONSE message 1383 0 1 2 3 1384 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 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | ENRP server message identifier #1 = 0x27047729 | 1387 +-------------------------------+-------------------------------+ 1388 | ENRP server message identifier #2 = 0x53829149 | 1389 +-------------------------------+-------------------------------+ 1390 | Type = 0x107 | 1391 +-------------------------------+-------------------------------+ 1392 | sending server's IP address | 1393 +-------------------------------+-------------------------------+ 1394 | sender's SCTP port | padding | 1395 +-------------------------------+-------------------------------+ 1396 | receiving server's IP address | 1397 +-------------------------------+-------------------------------+ 1398 | receiver's SCTP port | padding | 1399 +-------------------------------+-------------------------------+ 1400 | Target server's IP address | 1401 +-------------------------------+-------------------------------+ 1402 | Target server's SCTP port | padding | 1403 +-------------------------------+-------------------------------+ 1405 The receiving server's address and port do not need to be filled in if 1406 the message is being multicasted. 1408 'Target server's IP address and port number must be supplied. 1410 3.10 TAKEOVER_PEER_SERVER message 1412 0 1 2 3 1413 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 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | ENRP server message identifier #1 = 0x27047729 | 1416 +-------------------------------+-------------------------------+ 1417 | ENRP server message identifier #2 = 0x53829149 | 1418 +-------------------------------+-------------------------------+ 1419 | Type = 0x108 | 1420 +-------------------------------+-------------------------------+ 1421 | sending server's IP address | 1422 +-------------------------------+-------------------------------+ 1423 | sender's SCTP port | padding | 1424 +-------------------------------+-------------------------------+ 1425 | receiving server's IP address | 1426 +-------------------------------+-------------------------------+ 1427 | receiver's SCTP port | padding | 1428 +-------------------------------+-------------------------------+ 1429 | Target server's IP address | 1430 +-------------------------------+-------------------------------+ 1431 | Target server's SCTP port | padding | 1432 +-------------------------------+-------------------------------+ 1434 The receiving server's address and port do not need to be filled in if 1435 the message is being multicasted. 1437 'Target server's IP address and port number must be supplied. 1439 3.11 SERVER_DUMP message 1441 0 1 2 3 1442 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 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | ENRP endpoint message identifier #1 = 0x18038688 | 1445 +-------------------------------+-------------------------------+ 1446 | ENRP endpoint message identifier #2 = 0x77734683 | 1447 +-------------------------------+-------------------------------+ 1448 | Type = 0x7 | 1449 +-------------------------------+-------------------------------+ 1450 | | 1451 | Endpoint name (32) | 1452 | | 1453 +-------------------------------+-------------------------------+ 1454 | Dump Type (see below) | 1455 +-------------------------------+-------------------------------+ 1457 The 'Dump Type' field shall take one of the following values: 1458 0x0 --- HOME_LIST: dump a copy of the home endpoint portion of the 1459 name database of the server (i.e., endpoints owned by the 1460 server). 1461 0x1 --- REMOTE_LIST: dump a copy of the remote endpoint portion of the 1462 name database of the server (i.e., endpoints NOT owned by the 1463 server). 1464 0x2 --- PEER_LIST: dump a copy of a list containing all the peers 1465 known to the server. 1467 3.12 SERVER_DUMP_RESPONSE message 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 | ENRP endpoint message identifier #1 = 0x18038688 | 1473 +-------------------------------+-------------------------------+ 1474 | ENRP endpoint message identifier #2 = 0x77734683 | 1475 +-------------------------------+-------------------------------+ 1476 | Type = 0x8 | 1477 +-------------------------------+-------------------------------+ 1478 | | 1479 | Endpoint name (32) | 1480 | | 1481 +-------------------------------+-------------------------------+ 1482 | Dump Type (see below) | 1483 +-------------------------------+-------------------------------+ 1484 | Number of Entries = n (see below) | 1485 +-------------------------------+-------------------------------+ 1486 | | 1487 | Dump entry 1 (see below) | 1488 | | 1489 +-------------------------------+-------------------------------+ 1490 / / 1491 \ \ 1492 / / 1493 +-------------------------------+-------------------------------+ 1494 | | 1495 | Dump entry n (see below) | 1496 | | 1497 +-------------------------------+-------------------------------+ 1499 The 'Dump Type' fields shall take the same values as defined in 1500 Section 3.2.29??. 1502 If 'Dump Type' is HOME_LIST, or REMOTE_LIST, the 'Number of Entries' 1503 field shall be the number of endpoint entries carried in the message, 1504 and each 'Dump entry' field shall contain an endpoint entry and shall 1505 be defined as: 1507 0 1 2 3 1508 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 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | | 1511 | Endpoint name (32) | 1512 | | 1513 +-------------------------------+-------------------------------+ 1514 | number of endpoints = m | 1515 +-------------------------------+-------------------------------+ 1516 | | 1517 | endpoint entry 1 (40) | 1518 | | 1519 +-------------------------------+-------------------------------+ 1520 / / 1521 \ \ 1522 / / 1523 +-------------------------------+-------------------------------+ 1524 | | 1525 | endpoint entry m (40) | 1526 | | 1527 +-------------------------------+-------------------------------+ 1529 If 'Dump Type' is PEER_LIST, the 'Number of Entries' field shall be 1530 the number of peer entries carried in the message, and each 'Dump 1531 entry' field shall contain a peer entry and shall be defined as: 1533 0 1 2 3 1534 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 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Peer's IP address | 1537 +-------------------------------+-------------------------------+ 1538 | Peer's SCTP port | padding | 1539 +-------------------------------+-------------------------------+ 1540 | Caretaker's IP address | 1541 +-------------------------------+-------------------------------+ 1542 | caretaker's SCTP port | padding | 1543 +-------------------------------+-------------------------------+ 1545 In a peer entry, the peer's IP address and port number serve as the 1546 identification of that peer. If the peer is inactive, its caretaker's 1547 IP address and port number shall be filled in. Otherwise, the 1548 caretaker IP and port fields shall be zeroed out. 1550 4. Variables, Time Values, and Thresholds 1552 The following is a summary of the variables, time values, and pre-set 1553 thresholds used in ASAP and ENRP protocol. 1555 4.1 Variables 1557 Endpoint-report-failures --- per endpoint; keeps the number of 1558 endpoint-unreachable reports concerning this endpoint. 1560 Endpoint-sanity-failures --- per endpoint; keeps the number of failed 1561 sanity message send attempts concerning this endpoint. 1563 Peer-server-last-heard --- per peer server; a time stamp on when the 1564 last message was received from this peer server. 1566 4.2 Time values 1568 Endpoint-sanity-cycle --- the period for a home ENRP server to start a 1569 new round of endpoint sanity check. 1571 Peer-heartbeat-cycle ---the period for an ENRP server to send out a 1572 heart heat message. 1574 T1-ENRPrequest - A timer started when a request is sent by ASAP to the 1575 ENRP server (providing application information is queued). Normally set 1576 to 15 seconds. 1578 T2-registration - A timer started when sending a registration request 1579 to the local ENRP server, normally set to 30 seconds. 1581 T3-registration-reattempt - If the registration cycle does not complete 1582 this timer is begun to restart the registration process. Normal value 1583 for this timer is 10 minutes. 1585 T4-reregistration - This timer is started after successful registration 1586 into the ASAP name space and is used to cause a re-registration at a 1587 periodic interval. This timer is normally set to 10 minutes. 1589 4.3 Thresholds 1591 Max-endpoint-sanity-failures --- pre-set threshold for 1592 Endpoint-sanity-failures. 1594 Max-endpoint-report-failures --- pre-set threshold for 1595 Endpoint-report-failures. 1597 Max-time-last-heard --- pre-set threshold for Peer-last-heard. 1599 Max-time-no-response --- pre-set threshold for a peer server to answer 1600 a PEER_PRESENCE message with reply required. 1602 Timeout-registration --- pre-set threshold; how long an endpoint will 1603 wait for the REGISTRATION_RESPONSE from its home ENRP server. 1605 Timeout-server-hunt --- pre-set threshold; how long an endpoint will 1606 wait for the REGISTRATION_RESPONSE from its home ENRP server. 1608 num-of-serverhunts - The current count of server hunt messages that 1609 have been transmitted. 1611 registration-count - The current count of attempted registrations. 1613 max-reg-attempt - The maximum number of registration attempts to be 1614 made before a server hunt is issued. 1616 max-request-retransmit - The maximum number of attempts to be made 1617 when requesting information from the local ENRP server before 1618 a server hunt is issued. 1620 5. References 1622 [SCTP] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, 1623 T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, "Stream 1624 Control Transmission Protocol," , October 2000. 1626 [ASAP] Q. Xie, R. R. Stewart "Aggregate Server Access Protocol", 1627 draft-stewart-rserpool-asap-00.txt, work in progress.