idnits 2.17.1 draft-tuexen-rserpool-reqts-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 681 has weird spacing: '... having a wid...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 24, 2000) is 8554 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 2719 ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 INTERNET DRAFT Siemens AG 4 Q. Xie 5 Motorola 6 R. Stewart 7 E. Lear 8 Cisco 9 L. Ong 10 Nortel Networks 11 M. Stillman 12 Nokia 13 expires May 24, 2001 November 24, 2000 15 Requirements for Reliable Server Pooling 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with all 21 provisions of Section 10 of [RFC2026]. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other groups 25 may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 The goal is to develop an architecture and protocols for the management 41 and operation of server pools supporting highly reliable applications, 42 and for client access mechanisms to a server pool. 44 This document defines requirements and architecture for management and 45 access to server pools, including requirements from a variety of 46 applications, building blocks and interfaces, different styles of 47 pooling, security requirements and performance requirements such as 48 failover times and coping with heterogeneous latencies. 50 Important requirements of this architecture are 52 - network fault tolerance, 54 - highly available services, 56 - resistance against malicious attacks, 58 - and scalability. 60 1. Introduction 62 1.1. Overview 64 This document defines the reliable server pooling architecture and the 65 requirements for the protocols used. Reliable server pools can be used 66 for providing high available services by using a set of servers in a 67 pool. 69 Real time applications must also be supported which leads to 70 requirements on the processing time needed. Scalability is another 71 important requirement. 73 Given that the server pool can be attacked by hackers, if one or more of 74 the servers are hijacked then the server pool is compromised. 75 Therefore, the security requirement is to catalog the threats to the 76 reliable server pool and identify appropriate responses to those 77 threats. 79 1.2. Terminology 81 Operation scope: 82 the part of the network visible by ENRP. 84 Pool: 85 A collection of clients or servers providing the same service. 87 Pool Element: 88 A client or server which belongs to a pool. 90 Pool User: 91 A client which gets served by a pool element. 93 1.3. Abbreviations 95 ASAP: Aggregate Server Access Protocol 97 ENRP: Endpoint Name Resolution Protocol 99 PE: Pool element 101 PU: Pool user 103 SCTP: Stream Control Transmission Protocol 105 TCP: Transmission Control Protocol 107 2. Reliable Server Pooling Architecture 109 In this section, we discuss what a typical reliable server pool 110 architecture may look like. 112 2.1. Common Rserpool Functional Areas 114 The following functional areas or components may likely be present in a 115 typical Rserpool system architecture: 117 - A number of logical "Server Pools" to provide distinct 118 application services. 120 Each of those server pools will likely be composed of some 121 number of "Pool Elements (PEs)" - which are application 122 programs running on distributed host machines, collectively 123 providing the desired application services via, for example, 124 data sharing and/or load sharing. 126 Each server pool will be identifiable in the operation scope 127 of the system by a unique "name". 129 - Some "Pool Users (PUs)" which are the users of the application 130 services provided by the various server pools. 132 - PUs may or may not be part of a server pool themselves, 133 depending on whether or not they wish to be accessed by pool 134 name by others in the operation scope of the system. 136 - A "Name Space" which contains all the defined names within the 137 operation scope of the system. 139 - One or more "Name Servers" which carry out various maintenance 140 functions (e.g., registration and de-registration, integrity 141 checking) for the "Name Space". 143 2.2. Rserpool protocol overview 145 ENRP is designed to provide a fully distributed fault-tolerant real-time 146 translation service that maps a name to a set of transport addresses 147 pointing to a specific group of networked communication endpoints 148 registered under that name. ENRP employs a client-server model with 149 which an ENRP server will respond to the name translation service 150 requests from endpoint clients on both the local host and remote hosts. 152 Aggregate Server Access Protocol (ASAP) in conjunction with ENRP 153 provides a fault tolerant data transfer mechanism over IP networks. 154 ASAP uses a name-based addressing model which isolates a logical 155 communication endpoint from its IP address(es), thus effectively 156 eliminating the binding between the communication endpoint and its 157 physical IP address(es) which normally constitutes a single point of 158 failure. 160 In addition, ASAP defines each logical communication destination as a 161 named group, providing full transparent support for server-pooling and 162 load sharing. It also allows dynamic system scalability - members of a 163 server pool can be added or removed at any time without interrupting the 164 service. 166 The fault tolerant server pooling is gained by combining two parts, 167 namely ASAP and the Endpoint Name Resolution Part (ENRP). ASAP provides 168 the user interface for name to address translation, load sharing 169 management, and fault management. ENRP defines the fault tolerant name 170 translation service. 172 2.3. Typical Interactions between Rserpool Components 174 The following drawing shows the typical Rserpool components and their 175 possible interactions with each other: 177 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 178 ~ Name space ~ 179 ~ ~ 180 ~ ......................... ......................... ~ 181 ~ . Server Pool 1 . . Server Pool 2 . ~ 182 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 183 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 184 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 185 ~ . ^ ^ . . ^ ^ . | ~ 186 ~ . | (a) | . . | | . | ~ 187 ~ . +----------+ | . . | | . | ~ 188 ~ . +-------+ | | . . | | . | ~ 189 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 190 ~ . +-------+ | | | . . | | . | ~ 191 ~ . ^ | | | . . | | . | ~ 192 ~ .......|........|.|.|.... .......|.........|....... | ~ 193 ~ | | | | | | | ~ 194 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 195 ~ | | | | | | | ~ 196 ~ | v v v v v | ~ 197 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 198 ~ | + ENRP-Server +<---------->+ ENRP-Server + | ~ 199 ~ | +++++++++++++++ +++++++++++++++ | ~ 200 ~ v ^ ^ | ~ 201 ~ ********* | | | ~ 202 ~ * PU(A) *<-------+ (b)| | ~ 203 ~ ********* (b) | | ~ 204 ~ v | ~ 205 ~ ::::::::::::::::: ***************** | ~ 206 ~ : Other Clients :<------------->* Proxy/Gateway * <---+ ~ 207 ~ ::::::::::::::::: ***************** ~ 208 ~ ~ 209 ~ ~ 210 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 211 Figure 2.1 Rserpool components and their possible interactions. 213 Note, the "Proxy/Gateway" in Figure 2.1 is just a special kind of PU 214 which is designed to allow non-Rserpool (e.g., legacy) clients to access 215 services provided by Rserpool applications. 217 In Figure 2.1 we can identify the following possible interactions: 219 (a) Server Pool Elements <-> ENRP Server: (ASAP) 221 Each PE in a pool uses ASAP to register or de-register itself 222 as well as to exchange other auxiliary information with the 223 ENRP Server. The ENRP Server also uses ASAP to monitor the 224 operational status of each PE in a pool. 226 (b) PU <-> ENRP Server: (ASAP) 228 A PU normally uses ASAP to request the ENRP Server for a name- 229 to-address translation service before the PU can send user 230 messages addressed to a server pool by the pool's name. 232 (c) PU <-> PE: (ASAP) 234 ASAP can be used to exchange some auxiliary information of the 235 two parties before they engage in user data transfer. 237 (d) Server Pool <-> Server Pool: (ASAP) 239 A PE in a server pool can become a PU to another pool when the 240 PE tries to initiate communication with the other pool. In 241 such a case, the interactions described in B) and C) above 242 will apply. 244 (e) ENRP Server <-> ENRP Server: (ENRP) 246 ENRP can be used to fulfill various Name Space operation, 247 administration, and maintenance (OAM) functions. 249 2.4. Typical Protocol Architecture for Rserpool 251 Some text is needed. 252 ********* *********** 253 * PE/PU * *ENRP Srvr* 254 ********* *********** 256 +-------+ +----+----+ 257 To other <-->| ASAP |<------>|ASAP|ENRP| <---> To Peer ENRP 258 PE/PU +-------+ +----+----+ Name Servers 259 | SCTP | | SCTP | 260 +-------+ +---------+ 261 | IP | | IP | 262 +-------+ +---------+ 264 2.5. Two file Transfer examples 266 In this section we present two separate file transfer examples using 267 ENRP and ASAP. We present two separate examples demonstrating an 268 ENRP/ASAP aware client and a client that is using a Proxy or Gateway to 269 perform the file transfer. In this example we will use a FTP [RFC959] 270 model with some modifications. The first example (the rserpool aware 271 one) will modify FTP concepts slightly so that the file transfer takes 272 place over SCTP streams. In the second example we will use TCP between 273 the unaware client and the Proxy. The Proxy itself will use the 274 modified FTP with SCTP as illustrated in the first example. 276 Please note that in the example when using SCTP it does NOT follow FTP 277 [RFC959] precisely but we use FTP like concepts and attempt to adhere to 278 the basic FTP model. These examples use FTP for illustrative purposes, 279 FTP was chosen since many of the basic concept are well known and should 280 be familiar to readers. 282 2.5.1. The ENRP/ASAP aware file transfer over SCTP. 284 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 285 ~ Name space ~ 286 ~ ~ 287 ~ ~ 288 ~ ......................... ~ 289 ~ . "File Transfer Pool" . ~ 290 ~ . +-------+ +-------+ . ~ 291 ~ . |PE(1,A)| |PE(1,C)| . ~ 292 ~ . +-------+ +-------+ . ~ 293 ~ . ^ ^ . ~ 294 ~ . +----------+ | . ~ 295 ~ . +-------+ | | . ~ 296 ~ . |PE(1,B)|<---+ | | . ~ 297 ~ . +-------+ | | | . ~ 298 ~ .......|........|.|.|.... ~ 299 ~ | | | | ~ 300 ~ ASAP| ASAP| | |ASAP ~ 301 ~ | | | | ~ 302 ~ v v v v ~ 303 ~ ********* +++++++++++++++ ~ 304 ~ * PU(X) * + ENRP-Server + ~ 305 ~ ********* +++++++++++++++ ~ 306 ~ ^ ^ ~ 307 ~ | ASAP | ~ 308 ~ +--------------+ ~ 309 ~ ~ 310 ~ ~ 311 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 313 To effect a file transfer the following steps would take place. 315 1) The application in PU(X) would send a login request to the 316 Pool name "File Transfer Pool". 318 2) PU(X)'s ASAP layer would not find the name in its local cache, 319 I.e. it encounters a "cache miss". 321 3) PU(X)'s ASAP layer would send an ASAP request to its "local" 322 ENRP server to request the list of Pool Elements (PE's). The 323 ASAP layer queues the data to be sent in local buffers until 324 the ENRP server responds. 326 4) The ENRP server would return a list of the three PE's A, B and 327 C to the ASAP layer in PU(X). 329 5) PU(X)'s ASAP layer would now populate its local cache with the 330 name mapping "File Transfer Pool" to the returned list and, 331 using the server selection algorithm in the reply message from 332 the ENRP server, would select a member of the pool and 333 transmit its request. Note that the selection algorithm could 334 involve queries to other entities, but for illustrative 335 purposes we will assume that the "File Transfer Pool" is using 336 a simple round robin selection scheme that would not involve 337 any reference to other balancing or plug in agents. 339 6) The sending of the "login" request to the selected PE would 340 implicitly bring up an SCTP association. In our example the 341 requesting PU would allow a large number of streams inbound to 342 it. 344 7) The selected server (for illustrative purposes 'PE(1,A)') 345 would respond on stream 0 of the SCTP association with a 346 challenge for a password. 348 8) The user would type the password in, and send it to the handle 349 returned to it in the successful send call (the send of the 350 login) over stream 0 to complete the login. 352 9) PE(1,A) would accept the password and send back a prompt on 353 stream 0. 355 10) The user would now type a "get filename" to retrieve the file 356 he wanted. This would generate a send of a request to stream 0 357 but it would specify a particular SCTP stream in place of an 358 IP address and port for the server to connect to. 360 11) The server would read the command on stream 0 and begin 361 sending the file according to its file transfer protocol on 362 the specified SCTP stream number. 364 12) If during the file transfer conversation, PE(1,A) fails, 365 assuming the PE's were sharing state of file transfer, a fail- 366 over to PE(1,B) could be initiated. PE(1,B) would continue the 367 transfer until complete. In parallel a request would be made 368 to ENRP to request a cache update for the server pool "File 369 Transfer Pool" and a report would also be made that PE(1,A) is 370 non-responsive (this would cause appropriate audits that may 371 remove PE(1,A) from the pool if the ENRP servers had not 372 already detected the failure). 374 13) At file transfer completion the "end of transfer" record would 375 be passed over our stream. 377 14) The user now types quit, ending our session and shutting down 378 the SCTP association. 380 15) A subsequent request for login would result in a 'cache hit' 381 using the last cache entry and possibly picking PE(1,C), 382 repeating the sequence between (6) to (14). 384 2.5.2. The ENRP/ASAP unaware client file transfer using TCP and SCTP. 386 In this example we investigate the use of a Proxy server assuming the 387 same set of scenario as illustrated above. 388 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 389 ~ Name space ~ 390 ~ ~ 391 ~ ~ 392 ~ ......................... ~ 393 ~ . "File Transfer Pool" . ~ 394 ~ . +-------+ +-------+ . ~ 395 ~ . |PE(1,A)| |PE(1,C)| . ~ 396 ~ . +-------+ +-------+ . ~ 397 ~ . ^ ^ . ~ 398 ~ . +----------+ | . ~ 399 ~ . +-------+ | | . ~ 400 ~ . |PE(1,B)|<---+ | | . ~ 401 ~ . +-------+ | | | . ~ 402 ~ .......|........|.|.|.... ~ 403 ~ | | | | ~ 404 ~ | ASAP| | |ASAP ~ 405 ~ | | | | ~ 406 ~ | v v v ~ 407 ~ | +++++++++++++++ +++++++++++++++ ~ 408 ~ | + ENRP-Server +<--ENRP-->+ ENRP-Server + ~ 409 ~ | +++++++++++++++ +++++++++++++++ ~ 410 ~ | ^ ~ 411 ~ | ASAP | ~ 412 ~ +---------------------------------+ ASAP| ~ 413 ~ | | ~ 414 ~ v v ~ 415 ~ ::::::::::::::::: ***************** ~ 416 ~ : FTP Client :<------------->* Proxy/Gateway * ~ 417 ~ ::::::::::::::::: ***************** ~ 418 ~ ~ 419 ~ ~ 420 ~ ~ 421 ~ ~ 422 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 424 In this example the steps will occur: 426 A) The Proxy/Gateway listens on the TCP port for FTP. 428 B) The Client connects to the Proxy and sends a login request. 430 C) The Proxy/Gateway follows steps (1) - (7) above to find and 431 begin the login process. 433 D) When the challenge for password arrives at the Proxy (Step 8) 434 it is forwarded to the FTP client. 436 E) The user responds on the TCP connection which is forwarded 437 completing step 8) above. 439 F) When step 9 above happens, the login acceptance is forwarded 440 through the TCP connection. 442 G) A new TCP connection is established between the listening FTP 443 client and the proxy. Then the get command is forwarded 444 through the proxy to the selected PE. 446 H) As the subsequent steps commence, the data is transmitted from 447 the selected PE to the proxy server and then forwarded from 448 the proxy over the new TCP data connection to the client. 449 Commands from the server are forwarded to the command TCP 450 connection by the proxy and user input (from the FTP client) 451 is forwarded to stream 0 by the proxy. 453 Note that in this example high availability is maintained 454 between the Proxy and the server pool but a single point of 455 failure exists between the FTP client and the Proxy, i.e. the 456 command TCP connection and its one IP address it is using for 457 commands. 459 2.6. Telephony Signaling Example 461 This example shows the use of ASAP/Rserpool to support server pooling 462 for high availability of a telephony application such as a Voice over IP 463 Gateway Controller service. 465 2.6.1. Initial Server Selection using RSerpool 467 In this stage, the Signaling Gateway (SG) attempts to locate the Gateway 468 Controller server to handle an incoming signaling message. 469 ........................................ 470 . Gateway Controller Pool . 471 . +-------+ . 472 . |PE(1,C)|-+ . 473 . +-------+ | . 474 . +-------+ | . 475 . |PE(1,A)|-----+ | . 476 . +-------+ | | . 477 . +-------+ | | . 478 . |PE(1,B)|---------+ | | . 479 . +-------+ | | | . 480 ...................... |..|..| ......... 481 | | | 482 | | |ASAP 483 | | | 484 v v v 485 ********* +++++++++++++++ 486 * SG(X) * + ENRP-Server + 487 ********* +++++++++++++++ 488 ^ ^ 489 | | 490 | ASAP | 491 +-------------------+ 492 As shown in the figure, the following sequence takes place: 494 - the Pool Elements (PEs) in the pool have registered with the 495 ENRP Name Server(s) under the appropriate name for the GWC 496 function 498 - the Signaling Gateway (SG) receives an incoming signaling 499 message to be forwarded to the GWC. SG(X)'s ASAP layer would 500 send an ASAP request to its "local" ENRP server to request the 501 list of Pool Elements (PE's). The ASAP layer queues the data 502 to be sent in local buffers until the ENRP server responds. 504 - the ENRP server would return a list of the three PE's A, B AND 505 C to the ASAP layer in SG(X) together with information to be 506 used for load-sharing traffic across the gateway controller 507 pool. 509 2.6.2. Access to the Pool 511 ASAP then uses this information to decide which server to send the 512 message to, using an adaptation layer MxUA, as defined in [RFC2719], and 513 an SCTP association to that server. 514 ........................................ 515 . Gateway Controller Pool . 516 . +-------+ . 517 . |PE(1,C)| . 518 . +-------+ . 519 . +-------+ ^ . 520 . |PE(1,A)| | . 521 . +-------+ | . 522 . +-------+ ^ | . 523 . |PE(1,B)| | | . 524 . +-------+ | | . 525 .........^......|..... |. . ......... 526 | +----+ | 527 | | +----------+ 528 | | | MxUA/SCTP 529 | | | 530 ********* +++++++++++++++ 531 * SG(X) * + ENRP-Server + 532 ********* +++++++++++++++ 534 As shown in the figure, subsequent signaling messages may be sent to 535 different servers in the pool according to the load sharing method 536 agreed upon between the ENRP server and the pool elements. 538 2.6.3. Variations 540 Some possible variations in this architecture might include: 542 - combining the ENRP-Server function internally into the same 543 physical system as the SG 545 3. General Requirements 547 The general architecture should be based on a peer to peer model. 548 However, the binding should be based on a client server model. 550 It should be possible to use the protocol stack in small devices, like 551 cellular phones. Therefore it must be possible to implement the 552 protocols on clients with a large range of processing power. 554 Furthermore, it is expected that there will be a transition phase with 555 some systems supporting the rserpool architecture and some are not. To 556 make this transition as seamless as possible it should be possible for 557 hosts not supporting this architecture to use also the new pooling 558 services via some mechanism. 560 Another important requirement is that servers should be able to enter 561 (become PEs) and leave server pools transparently without an 562 interruption in service. It must also be possible that ENRP servers 563 integrate themselves into the name space system. 565 The protocols used for the pool handling should not cause network 566 congestion. This means that it should not generate heavy traffic, even 567 in case of failures, and has to use flow control and congestion 568 avoidance algorithms which are interoperable with currently deployed 569 techniques, especially the flow control of TCP [RFC793] and SCTP 570 [RFC2960]. Therefore, for large pools, only a subset of all possible IP- 571 addresses are returned by the system. 573 There must be a way for the client to provide information to the ENRP 574 server about the pool elements. 576 The architecture should not rely on multicast capabilities of the 577 underlying layer. Nevertheless, it can make use of it if multicast 578 capabilities are available. 580 4. Namespaces and Pools 582 Services are provided to the clients through a pool of servers. Clients 583 will access these servers by name. The namespaces are flat. Selection 584 of a server in the pool will be performed on behalf of the client. If 585 more that one server registers under a name, this name becomes a name of 586 a server pool. The name resolution results in access to one specific 587 server out of a pool of servers. The selection of the server is 588 transparent to the client and is governed by server pool policy. 590 Servers are registered by name in a namespace to join a server pool. 591 There will be no globally unique namespace available, so multiple 592 independent namespaces must be supported. 594 Since it is necessary to support multiple namespaces, it should also be 595 possible for a host to refer to entities in namespaces the host does not 596 belong to. 598 It must also be possible for a host to be registered in more than one 599 namespace or using multiple names in one namespace. 601 A namespace can consist of a large number (up to 500) of pools. This 602 upper limit is important since the system will be used for real time 603 applications. So handling of name resolution has to be fast. Another 604 consequence of the real time requirement is the supervision on the pool 605 entities. The name resolution should not result in a pool element which 606 is not able to provide the required service. 608 The registration and deregistration process is a dynamic one. It must 609 be possible for hosts to register in a pool without affecting the other 610 elements of a pool. This will be used for example, if a pool is under 611 high load and more servers are installed to provide the service of the 612 pool. It must also be possible to remove host from a pool without 613 affecting the rest. 615 5. Server selection 617 Services are provided by a pool of servers. If a client wants to connect 618 to a server one of the servers of the pool has to be chosen. This 619 functionality is called server selection. 621 Server selection is driven by server pool policy. Some examples of 622 selection policies are load balancing and round robin. The set of 623 supported policies should be extensible in the sense that new policies 624 can be added as required. 626 The ENRP servers should be extensible using a plug-in architecture. 627 Then clients can provide some hints for the ENRP servers. Combining this 628 information with the plug-ins will result in a more refined server 629 selection by ENRP servers. 631 The server selection should not be based on internal features of the 632 underlying transport protocol. This means, for example, in the case of 633 SCTP that only the state of associations will be taken into account and 634 not the state of the paths of the associations. 636 For some applications it is important that a client repeatedly connect 637 to the same server in a pool. This feature should be supported if it is 638 possible, i. e. if that server is still alive. 640 6. Reliability aspects 642 Host failures are handled by the pool concept. If one pool element fails 643 and there are other pool elements which are able to provide the service 644 than the other pool elements will be used. 646 Transaction failover is not provided by reliable server pooling. If a 647 host fails during processing of a transaction this transaction may be 648 lost. Some services may provide a way to handle the failure, but this is 649 not guaranteed. 651 Network failures have to be handled by the transport protocol. This 652 means that the underlying layer protocol must provide at least a 653 acknowledged error-free non-duplicated transfer data delivery service. 654 Therefore SCTP is the preferred (required) transport protocol for 655 Rserpool. 657 7. Security aspects 659 Security is a major point of this architecture. There are several 660 aspects which have to be considered: 662 - The transport layer protocol used should support concepts for 663 dealing with denial of service attacks. 665 - The security architecture must be scalable. 667 - The ENRP Client has to use authentication before registration, 668 deregistration. 670 - It should be possible that the name resolution is encrypted. 672 - The communication between ENRP Servers must fulfill the same 673 requirements as the communication between ENRP clients and 674 servers. 676 - Different trust relationships should be supported. 678 - The server registration (becoming a PE) should be based on an 679 authentication. 681 - The security architecture must support hosts having a wide 682 range of processing power. 684 - It should be possible to encrypt the communication between the 685 client and the host. 687 8. Acknowledgements 689 The authors would like to thank Melinda Shore, Werner Vogels and many 690 others for their valuable comments and suggestions. 692 9. References 694 [RFC793] J. B. Postel, "Transmission Control Protocol", RFC 793, 695 September 1981. 697 [RFC959] J. B. Postel, J. Reynolds, "File Transfer Protocol (FTP)", 698 RFC 959, October 1985. 700 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 701 RFC 2026, October 1996. 703 [RFC2719] L. Ong et al., "Framework Architecture for Signaling 704 Transport", RFC 2719, October 1999. 706 [RFC2960] R. R. Stewart et al., "Stream Control Transmission 707 Protocol", RFC 2960, November 2000. 709 10. Authors' Addresses 711 Michael Tuexen Tel.: +49 89 722 47210 712 Siemens AG e-mail: Michael.Tuexen@icn.siemens.de 713 ICN WN CS SE 51 714 D-81359 Munich 715 Germany 717 Qiaobing Xie Tel.: +1 847 632 3028 718 Motorola, Inc. e-mail: qxie1@email.mot.com 719 1501 W. Shure Drive, #2309 720 Arlington Heights, Il 60004 721 USA 723 Randall Stewart Tel.: +1 815 477 2127 724 Cisco Systems, Inc. e-mail: rrs@cisco.com 725 24 Burning Bush Trail 726 Crystal Lake, Il 60012 727 USA 729 Eliot Lear Tel.: +1 730 Cisco Systems, Inc. e-mail: lear@cisco.com 732 USA 733 Lyndon Ong Tel.: +1 408 495 5072 734 Nortel Networks e-mail: long@nortelnetworks.com 735 4401 Great America Parkway 736 Santa Clara, CA 95054 737 USA 739 Maureen Stillman Tel.: +1 607 273 0724 62 740 Nokia e-mail: maureen.stillman@nokia.com 741 127 W. State Street 742 Ithaca, NY 14850 743 USA 745 This Internet Draft expires May 24, 2001.