idnits 2.17.1 draft-ietf-rserpool-comp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1088. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2005) is 6868 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 1016, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-09 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3237 (ref. '2') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-09 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-09 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Loughney, Ed. 3 Internet-Draft Nokia 4 Expires: January 7, 2006 A. Silverton, Ed. 5 Motorola 6 M. Stillman 7 Nokia 8 Q. Xie 9 Motorola 10 R. Stewart 11 Cisco 12 July 6, 2005 14 Comparison of Protocols for Reliable Server Pooling 15 draft-ietf-rserpool-comp-10.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 7, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document compares protocols that may be applicable for the 49 Reliable Server Pooling problem space. This document discusses the 50 usage and applicability of these protocols for the Reliable Server 51 Pooling architecture. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Relation to Other Technologies . . . . . . . . . . . . . . . . 4 60 2.1 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.2 Technical Issues . . . . . . . . . . . . . . . . . . . 6 64 2.3 Dynamic Delegation Discovery System (DDDS) and URI . . . . 9 65 2.4 Service Location Protocol (SLP) . . . . . . . . . . . . . 12 66 2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . 12 67 2.4.2 What to Use . . . . . . . . . . . . . . . . . . . . . 12 68 2.4.3 Summary of SLP Issues . . . . . . . . . . . . . . . . 13 69 2.5 L4/L7 Switching . . . . . . . . . . . . . . . . . . . . . 15 70 2.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . 15 71 2.5.2 L4 Switching . . . . . . . . . . . . . . . . . . . . . 15 72 2.5.3 L7 Switching . . . . . . . . . . . . . . . . . . . . . 16 73 2.5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . 18 74 2.6 ASAP and ENRP . . . . . . . . . . . . . . . . . . . . . . 19 75 2.6.1 ASAP . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 2.6.2 ENRP . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 3. Comparison Against Requirements . . . . . . . . . . . . . . . 20 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22 83 7.2 Non-Normative References . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 85 Intellectual Property and Copyright Statements . . . . . . . . 25 87 1. Introduction 89 1.1 Overview 91 In creating a solution to provide reliable server pools [1], there 92 are a number of existing protocols, which appear to have similar 93 properties as to what RSerPool is trying to accomplish. This 94 document discusses the applicability of these protocols in meeting 95 the requirements of Reliable Server Pooling [2]. 97 This study does not intend to be complete, rather intends to 98 highlight several protocols which working group members have 99 suggested. 101 1.2 Terminology 103 This document uses the following terms: 105 Operational Scope: The part of the network visible to pool users by a 106 specific instance of the reliable server pooling protocols. 108 Pool: A collection of servers providing the same application 109 functionality. Also called a Server Pool. 111 Pool Handle: A logical pointer to a pool. Each server pool will be 112 identifiable in the operation scope of the system by a unique pool 113 handle or "name". Also called a Pool Name. 115 Pool Element: A server entity having registered to a pool. 117 Pool User: A server pool user. 119 Handle-Space: A cohesive structure of pool names and relations that 120 may be queried by an internal or external agent. 122 ENRP Server: Entity which is responsible for managing and maintaining 123 the handle-space within the RSerPool operational scope. 125 1.3 Abbreviations 127 DA: Directory Agent in SLP. 129 DPE: Distributed Processing Environment. 131 CORBA: Common Object Request Broker Architecture. 133 OMG: Object Management Group. 135 ORB: Object Request Broker. 137 PE: Pool Element. 139 PU: Pool User. 141 SA: Service Agent in SLP. 143 SLP: Service Location Protocol. 145 UA: User Agent in SLP. 147 TTL: Time to live in DNS. 149 2. Relation to Other Technologies 151 This section is intended to discuss the applicability of some 152 existing solutions with regards to Reliable Server Pooling 153 requirements [2]. The protocols discussed have been suggested as 154 possibly overlapping with the problems space of RSerPool. 156 2.1 CORBA 158 Often referred to as a Distributed Processing Environment (DPE), 159 CORBA was mainly designed to provide location transparency for 160 distributed applications. CORBA's distribution model encourages an 161 object-based view, i.e., each communication endpoint is normally an 162 object. 164 CORBA has a number of variants, such as fault-tolerant CORBA, Real- 165 time CORBA, etc. CORBA has been used in a number of situations, for 166 example, Real-time CORBA has been used in fighter aircraft and weapon 167 systems. Additionally, CORBA has been implemented in a wide range of 168 devices, from attack submarines to Palm Pilots - the MICO open source 169 ORB has been ported to the Palm Pilot, and the client- only 170 application is 45 KB in size. 172 CORBA, a DPE, sits above the communications layer that is the purview 173 of most IETF work, specifically, RSerPool. In a conceptual model of 174 a middleware stack for highly available clustering, CORBA is 175 considered an application service and not a messaging or clustering 176 service. A distributed application may utilize a CORBA ORB for 177 location transparency at the application layer, and the ORB may in 178 turn utilize RSerPool for its communications layer. For example, a 179 real-time CORBA ORB such as Tau, would benefit from having its 180 interfaces extended to take advantage of RSerPool concepts. 182 2.2 DNS 184 This section will answer the question why DNS is not appropriate as 185 the sole solution for RSerPool. In addition, it highlights specific 186 technical differences between RSerPool and DNS. 188 During the 49th IETF December 13, 2000 plenary meeting Randy Bush 189 presented a talk entitled "The DNS Today: Are we overloading the 190 Saddlebags on an Old Horse?" This talk underlined the issue that DNS 191 is currently overloaded with extraneous tasks and has the potential 192 to break down entirely due to a growing number of feature 193 enhancements. 195 RSerPool and DNS are protocols with very different objectives. 196 RSerPool is designed to provide a range of services up to the point 197 of relieving an application of the overhead of maintaining a session 198 with an active server. DNS was not intended to handle such a range 199 of functions. DNS may, however, be able to handle some of the lower 200 range of RSerPool functionality. 202 One requirement of any solution proposed by RSerPool would be to 203 avoid any additional requirements for DNS in order to support 204 Reliable Server Pooling. Interworking between DNS and RSerPool will 205 be considered so that additional burdens to DNS will not be added. 207 2.2.1 Requirements 209 Any solution for RSerPool should meet certain requirements [2]. 210 These requirements are discussed below in relation to DNS. 212 "Servers should be able to register to (become PEs) and deregister 213 from a server pool transparently without an interruption in 214 service. 216 The RSerPool mechanisms must be able to support different server 217 selection mechanisms. These are called server pool policies. 219 The RSerPool architecture must be able to detect server failure 220 quickly and be able to perform failover without service 221 interruption. 223 Server pools are identified by pool handles. These pool handles 224 are only valid inside the operation scope. Interoperability 225 between different namespaces has to be provided by other 226 mechanisms." 228 2.2.2 Technical Issues 230 This section discusses the relationship between DNS and the 231 requirements for RserPool. 233 2.2.2.1 Host Resolver Problems 235 A major issue that prevents the use of DNS as part of the RSerPool 236 solution is the architecture of host resolvers. These are stub 237 resolvers - which means that they require their local DNS servers to 238 do recursion for them. 240 In turn, this implies that setting TTL low or 0 will dramatically 241 increase the load not only on the authoritative DNS servers - but 242 also on these third party servers. 244 A secondary effect of this is that the authoritative DNS will not 245 know the IP address of the DNS client - only the IP address of the 246 local DNS. This affects the ability to do global load balancing 247 correctly. 249 There is no way to get around these issues unless one requires all 250 hosts to be full resolvers. Putting full resolvers on newer hosts 251 isn't sufficient because the issues would still exist for all the 252 legacy systems, which will form the bulk of the host population for 253 years to come. The solution is not to use third party servers. 255 Additionally, if the client can contact the server directly, then the 256 server knows the real IP address of the client. Since there is no 257 third party involved, the caching TTL can be set as low as desired 258 (even to zero). That will increase load on the server, but nowhere 259 else. 261 Finally, DNS is based on a recursion. This recursion presents 262 certain difficulties for RSerPool. Even if a host resolver is not a 263 stub resolver, it has to go to another full resolver where 2 264 possibilities exists: either the mapping name-IP address is found or 265 it has to do another recursive resolution of the name, staring from 266 that intermediate resolver, until there is a cache hit in one of the 267 intermediate resolvers or it is resolved by its root resolver (or 268 home DNS server). 270 This process of recursion means that there is no end-to-end 271 communication between the host and its server where the name-to-IP 272 mapping resides. That also means that a lot of timers are running in 273 intermediate systems. Any updating of the transient status of the 274 pool element or of the pool may need to be propagated through the 275 DNS. 277 2.2.2.2 Dynamic Registration 279 Registration / de-registration of servers is needed. It can be done 280 with DNS by NOTIFY/IXFR. However, frequent updates and replication 281 are incompatible. This is not a DNS problem per se, but it has an 282 effect on DNS as it is deployed. 284 RSerPool must allow software server entities (i.e., PEs) to register 285 themselves with a name server dynamically. They can also de-register 286 themselves for purposes of preventative maintenance or can be de- 287 registered by an ENRP server that believes the server entity is no 288 longer operational. This is a dynamic approach, which is coordinated 289 through servers in the pool and among RSerPool ENRP servers. 291 2.2.2.3 Load Balancing 293 RFC 2782 [3] itself points out some of the limitations of using DNS 294 SRV for load balancing between servers. 296 Weight is only intended for static, not dynamic, server selection. 297 Using SRV weight for dynamic server selection would require 298 assigning unreasonably short TTLs to the SRV RRs, which would 299 limit the usefulness of the DNS caching mechanism, thus increasing 300 overall network load and decreasing overall reliability. 302 Based on this, DNS can only really support stochastic load balancing, 303 redirecting clients to servers randomly as various caches in various 304 resolvers expire at random (although small) intervals. DNS offers 305 excellent network scalability but poor control over load balance. 307 As mentioned previously, the issue of doing DNS-based dynamic load 308 balancing on short time scales will have impacts on third parties, 309 due to the presence of stub resolvers. 311 2.2.2.4 Heartbeating & Status Monitoring 313 RSerPool working group has agreed that one of its main design goals 314 for RSerPool is "...performance for supporting real-time 315 applications", as reflected in RFC 3237 [2]. An example of such 316 real-time applications would be the IP-based call control 317 applications in a 3G cellular network. 319 To achieve this goal, it is felt critical that RSerPool monitors the 320 state of each server entity on various hosts on a continual basis and 321 collects several state variables including up/down state and current 322 load. If a server is no longer operational, eventually it will be 323 dropped from the list of available servers maintained by the ENRP 324 server, so that subsequent application name queries will not resolve 325 to this server address. 327 DNS does not incorporate an application layer heartbeat. 328 Heartbeating would dramatically boost traffic levels, and given the 329 unavoidable third party dependencies of DNS, the resulting loading 330 would be unacceptable. It is passive in the sense that it does not 331 monitor or store information on the state of the host such as whether 332 the host is up or down or what kind of load it is currently 333 experiencing. 335 It is not entirely impossible to make DNS utilize the assistance of 336 an external heartbeat function/protocol for this monitoring purpose. 337 However, to achieve the degree of real-time performance RSerPool is 338 seeking, one would most likely need a tight coupling of this external 339 function to the DNS operation. This in turn would likely result in 340 substantial modification of the existing DNS, which is what we want 341 to avoid. 343 2.2.2.5 Name/Address Resolution Granularity 345 The technical requirement for DNS name/address resolution is 346 basically that given a name, find a host associated with this name 347 and return its IP address(es). In other words, in DNS we have the 348 following mapping: 350 Name ; a host machine 352 -to- 354 Address ; IP address(es) to reach the host machine 356 The technical requirement for RSerPool name/address resolution is 357 that given a name (or pool handle), find a server pool associated 358 with this name and return a list of _transport_ addresses (i.e., IP 359 address(es) plus port number) for reaching a set of currently 360 operational servers inside the pool. In other words, in RSerPool we 361 have the following mapping: 363 Name ; a handle to a server pool 365 -to- 367 Address ; transport address(es) (i.e., IP plus port number) to 368 ; reach a set of functionally identical server entities 369 ; (software processes). These software entities can be 370 ; distributed across multiple host machines. 372 Without significant extensions, the current DNS would have difficulty 373 achieving this type of name mapping. 375 2.2.2.6 Lack of Support for Real-time Fault Detection and Recovery 377 Even if we could somehow overcome the aforementioned shortcomings of 378 DNS in terms of providing the name resolution service to RSerPool, we 379 still would not have the support for real-time fault detection and 380 recovery (i.e., failover) which is a key requirement in RSerPool. 382 To meet this requirement, a mechanism would need to be in place that 383 would detect the unreachability of a message recipient and re-direct 384 or re-route a user message to an alternate recipient in the same 385 destination pool in real-time or semi-real-time. DNS currently 386 contains no such mechanism. 388 2.2.2.7 Lack of Support for Redundancy Models 390 Server pooling as defined in RSerPool requires support for different 391 redundancy arrangements or models depending on the needs of the 392 specific application. Commonly used models in practice includes N+M, 393 N-active, etc. These models basically define how a PE behaves when 394 another PE in the same pool fails and it is often critical for the 395 application to have full control over this behavior of each PE in the 396 pool. Without major extensions, it seems difficult for DNS to 397 support such redundancy models. 399 2.3 Dynamic Delegation Discovery System (DDDS) and URI 401 In this section, we discuss the difficulties for RSerPool to make use 402 of DDDS and URI as building blocks for its distributed pool handle 403 database (i.e., RSerPool handle-space). 405 RFC 3401 [5] defines DDDS as an abstract algorithm for applying 406 dynamically retrieved string transformation rules to an application- 407 unique string. DDDS has been found useful for URI Resolution, ENUM 408 telephone number to URI resolution, and the NAPTR DNS resource 409 record. 411 As stated in [5], DDDS is "used to implement lazy binding of strings 412 to data, in order to support dynamically configured delegation 413 systems. The DDDS functions by mapping some unique string to data 414 stored within a DDDS Database by iteratively applying string 415 transformation rules until a terminal condition is reached." 417 In order to discuss the applicability of DDDS/URI in RSerPool, we 418 need first talk about some fundamental characteristics of pool 419 handles or names in RSerPool. 421 It is important to note that, handles or names in RSerPool are meant 422 to identify pools comprising of _generic_ communications nodes. 423 Those nodes in reality will be some kind of servers - service 424 applications that runs on some networked machines. However, it is 425 very important to note that the working group has never had the 426 intention to go beyond the "server of generic IP applications" in its 427 pool definition. Nor has it seen the need to categorize the types of 428 the service applications for the purpose of RSerPool. This is 429 fundamentally different from the assumption behind URI as well as the 430 Service Location Protocol (to be discussed below). 432 With the above noted, here are some additional characteristics of 433 RSerPool handles/names: 435 1. RSerPool handles have only local significance, i.e., there is no 436 requirement for pool handles to be globally unique. 438 This is because the first tier of applications we envision for 439 RSerPool is those tightly coupled local systems that can use 440 RSerPool to make its components highly available. For example, a 441 3G radio access network that contains charging server, call 442 controller, media server, etc. where RSerPool can make those 443 currently singleton elements into pools and thus gain high 444 availability. This type of local systems can be as compact as a 445 bunch of server blades located in a single high performance 446 chassis or a group of closely located boxes in a central office 447 or in a few closely located buildings. The use of RSerPool in 448 such scenarios can be totally transparent to the outside world. 450 For example, a SIP phone may be talking to a softswitch without 451 knowing that the call control elements inside the softswitch are 452 a bunch of RSerPool-enabled pools. In such cases, the pool names 453 has no need to be globally unique (there is even no need for the 454 outside to know they exist). They only need to be unique within 455 the softswitch itself. 457 We also have considered the possibility of supporting larger 458 scale (even global) deployment cases of RSerPool. In the 459 requirement, we indicate we want RSerPool to be able to do that 460 but we have made it clear that RSerPool will not be able to do 461 that by itself. Instead, it will rely on existing external 462 infrastructures (e.g., DNS, possibly URN/DDDS) to bridge locally 463 scoped RSerPool clouds into a larger scale deployment. 465 2. RSerPool handles have no need for supporting any structure/ 466 syntax. 468 As merely locally significant identifiers for distinguishing 469 pools of generic communication nodes, we consider adding 470 structure/syntax to RSerPool handle definition will buy us 471 nothing but will have real negative impact on the performance and 472 increase the implementation complexity. The only recommend we 473 have made so far is to use NULL-terminated ascii string for the 474 pool handles. This seems to meet our needs nicely. 476 3. RSerPool handles are relatively dynamic. 478 We consider that the pools may change relatively frequently; they 479 may come and go as the system re-adjusts its capacity or 480 configuration. We do not envision the handles to be long lived. 482 4. RSerPool handles are not for human readers. 484 Unlike UNIs (URN/URL), we do not envision RSerPool handles to 485 appear in e-mails, web documents, etc. for human viewing. 486 Probably the only case where RSerPool handles will be read by a 487 human is in a log file or configuration file, just like other 488 system configuration parameters. 490 Due to the aforementioned characteristics of RSerPool handles, we do 491 not see the benefit for directly using URNs/URIs for RSerPool 492 handles. The two rather fundamental requirements (per RFC 1737) that 493 brought us URNs - the global scope and persistence - do not apply to 494 RSerPool handles. Moreover, as mentioned above, we see little 495 benefit of making RSerPool handles human-readable or parsable in free 496 text. 498 In the future, there may be the possibility that URNs and the 499 associated infrastructure (e.g., DNS, DDDS) to play a vital role when 500 we start to consider wide area or global deployment scenarios for 501 RSerPool. For instance, a SIP client device that is looking for 502 certain network resource will start with a URN that is eventually 503 resolved to a pool handle that is then passed to an RSerPool 504 namespace server, which in turn will resolve the pool name to a list 505 of reachable/routable transport addresses of the server instances. 507 Similarly, since RSerPool handles are not global and have no 508 structure/syntax, we do not see that using DDDS inside RSerPool can 509 bring meaningful benefits. 511 2.4 Service Location Protocol (SLP) 513 2.4.1 Introduction 515 SLP [4] is comprised of three components: User Agents (UA), Service 516 Agents (SA) and Directory Agents (DA). User agents work on the 517 user's behalf to contact a service. The UA retrieves service 518 information from service agents or directory agents. A service agent 519 works on behalf of one or more services to advertise services. A 520 directory agent collects service advertisements. 522 The directory agent of SLP simply acts as a cache and is passive in 523 this regard. The directory agent is optional and SLP can function 524 without it. It is incumbent upon the servers to update the cache as 525 necessary by reregistering. The directory server is not required in 526 small networks as the user agents can contact service agents directly 527 using multicast. Unicast queries to SAs are possible subsequent to 528 the UA having discovered them. User agents are encouraged to locate 529 a directory at regular intervals if they can't find one initially, 530 otherwise they can detect DAs by listening passively for DA 531 advertisements. 533 2.4.2 What to Use 535 Figure 1 shows how SLP might be realized to provide RSerPool endpoint 536 name resolution (ENR) services: 538 Pool User (PU) ENR Service Pool Endpoint (PE) 539 +-------------+ +---------+ 540 | APPLICATION | | SERVICE | 541 +-+-------------+-+ +---+---------+---+ 542 |ASAP/RSerPool API| <--------------------> |ASAP/RSerPool API| 543 +-+----+--------+-+ +----------+ +-+--------+----+-+ 544 | | SLP UA | <----> | SLP DA | <----> | SLP SA | | 545 | +----+---+ +------+---+ +--------+ | 546 |SCTP |UDP| | SCTP |UDP| |UDP| SCTP | 547 +---------+---+ +------+---+ +---+---------+ 548 / \ 549 / mesh \ 550 +----+ +----+ 551 | DA |--------| DA | 552 +----+ +----+ 554 Figure 1: RSerPool entities employing SLP for ENR services 556 Notes: 558 o Each box constitutes a host (running a PU, PE or ENR server 559 'stack'), though one host could support more than one of these 560 functions. 562 o As far as the Application is concerned, it is using a framework 563 for exchanging messages with services reliably. 565 o As far as the Service is concerned, it is making itself available 566 to a reliable server pool by interacting with the framework API. 568 o The ASAP/RSerPool API obtains endpoint name resolution data in a 569 timely and robust manner and uses it to determine how to route PU 570 requests to PEs. 572 o The ENR service function is performed using SLP. The PU employs a 573 SLP UA to obtain information from a SLP DA. 575 o The PE employs a SLP SA to register information with a SLP DA. As 576 the SLP SA is 'mesh-enhanced,' it only registers with one DA of 577 this type (as long as it detects that this DA is alive & 578 responsive & returns 'OK' results). 580 o The SLP DA is part of a mesh. It will forward PE state to other 581 DAs in the mesh. For example, it will forward the registrations 582 the SLP SA made on behalf of the PE on right of Figure 1. 584 o SCTP is used for communication between entities. Multicast UDP is 585 used by SLP entities for active and passive discovery. While the 586 RSerPool architecture cannot rely upon multicast mechanisms, it 587 can profit from them when these are present in the network 589 SLPv2 will be needed, but SLPv2 alone does not fulfill RSerPool 590 update requirements for timeliness. This is achieved through mesh- 591 enhancements to the Service Location Protocol (mSLP) [6]. 593 These enhancements make it possible for SAs to know of only a subset 594 of all DAs. Mesh-enhanced SAs need only forward their registrations 595 to only one mesh-enhanced DA. The mesh takes care of forwarding the 596 message to the other DAs. 598 2.4.3 Summary of SLP Issues 600 A fundamental difference between SLP and RSerPool is that SLP is a 601 protocol that focuses on the service level, while RSerPool is at the 602 communication level. More specifically, what SLP provides to its 603 user is a mapping function from a name of a _service_ (e.g., b/w 604 printing, color printing, faxing) to the location of the service 605 provider, in the form of a URL string. The availability of the 606 service provider is outside of the scope of SLP. How a service is 607 accessible can be described by the SLP attribute list associated with 608 the service URL. SLP is essentially a discovery protocol, not a 609 transport protocol. Therefore, the granularity of SLP operation is 610 at application service level. 612 In contrast, what RSerPool provides to its user is a mapping function 613 from a communication destination name (i.e., a pool handle) to a set 614 of routable and reachable transport addresses that leads to a group 615 of distributed software server entities registered under that name. 616 RSerPool has NO intention to understand or convey to its user what is 617 the service (e.g., printing, faxing, document scanning) the named 618 pool is providing at the application level. In other words, the 619 responsibility of RSerPool is only to reliably deliver a user message 620 to one of those server entities in the destination pool. 622 In theory, information such as transport addresses and their 623 reachability could be represented in SLP attributes. Currently, mSLP 624 would need changes, for example it was designed to scale to ~10 DAs 625 not ~100 DAs. Additionally, SLP is currently designed to run on top 626 of UDP and TCP. If SCTP support is needed, some additional 627 specification work would be needed. 629 SLP security makes no attempt to address the confidentiality of data 630 transmitted between SLP agents. To properly address this concern, 631 SLP agents would need to establish secure communication with each 632 other. This would be achieved through the use of IPSec Encapsulating 633 Security Payload. 635 Server discovery, however, is something which SLP does well, and if 636 used for RSerPool, this would be useful. 638 Other difficulties and shortcomings for using SLP to implement 639 RSerPool include: 641 o Due to the fact that the resolution granularity of SLP is at the 642 service level, it relies on a syntax rich scheme to define 643 services (e.g., printers > color printers > color printers with 644 720+ resolution, etc). This implies that SLP implementation will 645 need to perform syntax analysis, filtering, and parsing when a 646 name is queried, and will need to dynamically search its name 647 space to identify which entities are to be included in the 648 response to a specific query. This type of complicated processing 649 and searching for each query may severely limit the performance of 650 SLP in a real-time world which is a key requirement of RSerPool. 652 o Without major extensions, SLP will not be able to provide a 653 solution for real-time or semi-real-time fault detection and 654 recovery. This is partially because SLP is a discovery protocol, 655 not a communication protocol. 657 2.5 L4/L7 Switching 659 2.5.1 Introduction 661 This section discusses L4 and L7 switching techniques and their 662 relation to the RSerPool architecture [2]. Since these technologies 663 are highly proprietary, it is difficult to discuss these techniques 664 in a thorough manner. 666 In both cases, the deployment of these techniques is dependent upon 667 the type of switching equipment deployed and breaks the end-to-end 668 communication model required by RSerPool. These devices provide a 669 specialized service intended to address a few network challenges, 670 e.g., web caching and web cache load balancing, firewall load 671 balancing, web server scaling, and streaming media load balancing. 672 They are not robust methods for providing network reliability or 673 highly reliable and highly available location transparent server 674 clustering as required by RSerPool. 676 The following sections will provide an overview and example of each 677 technique and an accounting for key RSerPool architectural 678 requirements not met. See Section 3 for a more detailed accounting 679 of requirements compliance. 681 2.5.2 L4 Switching 683 L4 devices make switching decisions based on the TCP or UDP port 684 numbers of the packet in transit. 686 2.5.2.1 Example 688 Web caching is an example of L4 switching. The topology requires the 689 introduction of an L4 capable switch in series with an existing 690 network connection and L2/L3 switch. This is of particular use to 691 web cache configurations where, for example, all traffic destined for 692 port 80 (HTTP) could be redirected to a web cache or distributed by 693 the switch across a number of web caches to achieve load balancing. 694 The L4 switch can react to a failed cache and cease to send traffic 695 to that device by automatically detecting that it is unreachable. 696 This is all accomplished without any configuration on a client 697 device. 699 An equally compelling use for this type of switching is load 700 balancing across firewalls. If the firewalls are employing stateful 701 packet inspection for TCP connections, then the L4 switch must track 702 which packets belong to which connection and see that all such 703 packets are switched to the same firewall. 705 An L4 switch is incapable of differentiating between packets 706 containing cacheable objects and non-cacheable objects, therefore, L7 707 devices, which look inside packets, are deployed where such 708 determinations must be made. In general, anytime that knowledge of 709 the application level data is required to make a switching decision, 710 L7 devices must be deployed. 712 2.5.2.2 Technical Issues 714 The more general behavior of L4 switching, redirecting traffic based 715 on destination UDP or TCP ports, is similar to a function provided by 716 RSerPool. Where it differs in this regard is that L4 switching is 717 dependent upon the network infrastructure and not peer-to-peer or 718 end-to-end as required by RSerPool. 720 L4 switching meets the requirement of forwarding to active elements 721 only, as a switch will detect unreachable PEs, but does not provide 722 for the necessary registration and deregistration of PEs or 723 resolution by name. L4 switches require the manual configuration of 724 access control lists to determine switching behavior. This is 725 achieved in RSerPool by more flexible means and without any 726 dependence on specialized network equipment. 728 Most of the features of ASAP [7] and ENRP [8] are not met by a device 729 employing L4 switching techniques. See the comparison table in 730 Section 5. 732 2.5.2.3 Security Issues 734 It is not clear that L4 switching introduces any new security 735 concerns. In fact, in a two-port security model, where secure 736 RSerPool services are provided on one port, and similar, but insecure 737 services, on another, L4 switching could be used to direct traffic to 738 a secure or insecure PE or ENRP server as necessary. 740 2.5.3 L7 Switching 742 As previously mentioned, L7 switching was developed to differentiate 743 between the type of objects being directed by network switches. In 744 the L4 case, the devices cannot differentiate between the types of 745 data, only the destination of the packets containing that data. L7 746 switches look at the application layer of a packet in transit to 747 determine what type of object is contained within. 749 2.5.3.1 Example 751 For an L7 switch to do this, it is necessary to intercept data 752 midstream. In the case of HTTP, which is carried over TCP, the L7 753 switch must break the TCP handshake when a new request is made to the 754 server attached to the switch. This process begins during the 755 initialization of the TCP connection and before the higher level 756 protocol, i.e., HTTP, sends its request. The switch acts as the 757 server during the TCP SYN, SYN ACK, ACK handshake between that server 758 and the client. Once the HTTP request is issued by the client and 759 the switch decides that this is non-cacheable data that should be 760 directed to the server as opposed to a web cache, the L7 switch sets 761 up a second connection with the actual server through an additional 762 three-way handshake. The switch will forward the client's request to 763 the server and for the duration of this connection, must graft the 764 client-switch and switch-server connections together by modifying IP 765 addresses and TCP ports on the fly. Cacheable data is handled 766 similarly, but is redirected to groups of web caches as opposed to 767 the web servers. 769 2.5.3.2 Technical Issues 771 It is not clear that L7 switching adds anything, as a general 772 mechanism, beyond what is provided by L4 switching, towards providing 773 a sufficient RSerPool architecture. 775 While this technique can be very valuable as a means to scale web 776 servers, it is apparent that it takes a significant amount of work on 777 the part of the switch to realize these gains. The nature of this 778 method also requires that for each type of application traffic 779 handled, a custom software module must be written and added to the 780 switch operating system. It is not known, due to the proprietary 781 nature of these devices, if this can be done by the end user and/or 782 added dynamically to deployed systems. 784 It may be possible to write custom modules for a switch, given the 785 appropriate access to hardware and software, to provide some type of 786 enhanced reliability in a controlled network. But, it is the aim of 787 RSerPool to provide a general mechanism that is widely deployable and 788 highly portable. L7 switching requires a significant amount of 789 development to customize each of the endpoint switches to which PUs 790 and PEs may be attached. 792 Also of concern is the compatibility of SCTP with L7 techniques. The 793 interception and subsequent splicing of sessions may nullify some of 794 the inherent benefits of SCTP and certainly add additional and 795 unnecessary complexity and latency to the transport layer. ASAP and 796 ENRP along with the multi-homing and stream based behavior of SCTP 797 provide more benefit than custom L7 switching would provide and at a 798 significantly lower cost. 800 2.5.3.3 Security Issues 802 While L7 switches do provide some robustness to TCP-based DoS attacks 803 directed at servers by requiring a proper three-way handshake, and 804 they can be used to redirect encrypted traffic to certain servers 805 better capable of processing that traffic, they may break the 806 security model of RSerPool. 808 It may not be possible to make all the routing and switching 809 decisions necessary to support RSerPool services without knowing more 810 than just the destination address and port of a packet. The 811 necessary extended attributes are not elements of L4 or L7 switching, 812 but are instead, parameters of ASAP and ENRP. As the ENRP traffic is 813 encrypted in RSerPool, the L7 devices would not be able to extract 814 the necessary session layer data without becoming potential third 815 party security liabilities. 817 2.5.4 Summary 819 The L4/L7 switching techniques, being network oriented services, are 820 not able to provide the communications session oriented behavior 821 required by RSerPool. 823 Adequate support for naming, as well as registration and 824 deregistration services, is not provided by these devices. RSerPool 825 requires a fault tolerant name service as well as the ability to 826 register and deregister PEs in real-time. To accomplish this with 827 L4/L7 switching, one would need to define a standard protocol to 828 allow the switches to communicate amongst themselves and, perhaps, 829 implement a co-resident name server on the switch. 831 The RSerPool communication model is broken as these mechanisms are 832 deployed on switch hardware as opposed to end devices such as PEs, 833 PUs, and ENRP servers. This implies a significant requirement for 834 processing power and a lack of support for mobility. It is unlikely 835 that one could or would build L4/L7 behavior into end devices and 836 RSerPool requires peer-to-peer functionality. 838 The equipment needed to deploy such solutions can be an order of 839 magnitude more expensive per port than a traditional L2/L3 device and 840 oftentimes must be deployed in addition to L2/L3 hardware. It has 841 been observed that L4/L7 devices show poor performance when acting as 842 an L2/L3 switch. This combined requirement for network 843 infrastructure is not appropriate for RSerPool. 845 L4/L7 switching while clearly good in certain areas, lacks the 846 ability to provide a robust framework for location transparent 847 clustering capable of scaling in size and performance from web server 848 or other Internet applications to real-time telecommunications 849 infrastructure. There are a host of concerns with the ability of 850 these techniques to meet critical RSerPool requirements in the areas 851 of flexibility, adaptability, timing, security, etc. The amount of 852 effort required to achieve RSerPool functionality across L4/L7 853 switches would amount to implementing RSerPool, as it is currently 854 defined, on those very switches. 856 2.6 ASAP and ENRP 858 ASAP [7] and ENRP [8] are being developed in the RSerPool working 859 group. Even though they are separate protocols, they are designed to 860 work together. 862 2.6.1 ASAP 864 ASAP uses a name-based addressing model which isolates a logical 865 communication endpoint from its IP address(es), thus effectively 866 eliminating the binding between the communication endpoint and its 867 physical IP address(es) which normally constitutes a single point of 868 failure. In addition, ASAP defines each logical communication 869 destination as a pool, providing full transparent support for server- 870 pooling and load sharing. If multiple endpoints register under a the 871 same name, a server pool is effectively created. It also allows 872 dynamic system scalability - members of a server pool can be added or 873 removed at any time without interrupting the service. 875 ASAP monitors the reachability of the Pool Elements in order to 876 provide fault tolerance. To support real-time or semi-real-time 877 fault detection and recovery, ASAP makes use of the peer reachability 878 feedback from either the transport layer (such as SCTP) or the upper 879 layer protocol and re-send (or failover) user messages to alternate 880 PEs in the destination pool. Load sharing and redundancy model 881 support is provided in ASAP at the message sender side. ASAP allows 882 extensions to be made in the future to accommodate new load sharing 883 policies and redundancy models. 885 ASAP supports the "keepalive" monitoring of PEs by the ENRP server 886 and session failover, in which a set of application messages are 887 defined as a "session" and ASAP provides best-effort transmission of 888 all the messages in the "session" to the same PE in the destination 889 pool. For some classes of service, ASAP can provide failover for the 890 remaining message in the "session" to an alternate PE if the first PE 891 fails. 893 2.6.2 ENRP 895 ENRP defines procedures and message formats of a pool registry 896 service (or name service) for storing, bookkeeping, retrieving, and 897 distributing pool operation and membership information. It allows 898 Pool Elements to be dynamically added, updated and removed from 899 service. There are also protocol mechanisms for detecting and 900 removing unreachable Pool Elements. 902 Within the operational scope of RSerPool, ENRP defines the procedures 903 and message formats of a distributed, fault-tolerant registry service 904 for storing, bookkeeping, retrieving, and distributing pool operation 905 and membership information. This is to avoid the name service itself 906 becoming a single point of failure in the system. 908 ENRP itself is dynamically scalable, meaning that new ENRP servers 909 can be added and existing servers can be removed as needed. This 910 feature can be used to achieve zero planned downtime upgrade of a 911 system - a common requirement for many mission critical applications. 913 ENRP is not designed to scale Internet wide. It uses a flat name 914 space model to gain performance. Other protocols, such as DNS could 915 be used to bridge small ENRP name spaces to create a large scale name 916 space. 918 3. Comparison Against Requirements 920 This section attempts to create a comparison table to compare the 921 technologies and protocols which have been suggested as applicable to 922 the RSerPool architecture. 924 ASAP 925 | CORBA | DNS | SLP | ENRP | L4/L7 | 926 -----------------------------+--------+-----+-----+------+-------+ 927 Robustness | Y | Y | Y | Y | Y | 928 -----------------------------+--------+-----+-----+------+-------+ 929 Failover Support | Y | P | P | Y | P | 930 -----------------------------+--------+-----+-----+------+-------+ 931 Communication Model | N | P | Y | Y | N | 932 -----------------------------+--------+-----+-----+------+-------+ 933 Processing Power | N | Y | Y | Y | N | 934 -----------------------------+--------+-----+-----+------+-------+ 935 Support of RSerPool | N | Y | N | N | N | 936 Unaware Clients | | | | | | 937 -----------------------------+--------+-----+-----+------+-------+ 938 Registering and | N | P | P | Y | N | 939 Deregistering | | | | | | 940 -----------------------------+--------+-----+-----+------+-------+ 941 Naming | Y | Y | Y | Y | N | 942 -----------------------------+--------+-----+-----+------+-------+ 943 Name Resolution only to | Y | N | Y | Y | Y | 944 Active Elements | | | | | | 945 -----------------------------+--------+-----+-----+------+-------+ 946 Server Selection Policies | Y | P | P | P | P | 947 -----------------------------+--------+-----+-----+------+-------+ 948 Timing Requirements and | P | N | Y | Y | P | 949 Scaling | | | | | | 950 -----------------------------+--------+-----+-----+------+-------+ 951 Scalability | N | Y | Y | Y | Y | 952 -----------------------------+--------+-----+-----+------+-------+ 953 Security - General | Y | P | P | P | P | 954 -----------------------------+--------+-----+-----+------+-------+ 955 Security - Name Space | P | P | P | P | N | 956 Services | | | | | | 957 -----------------------------+--------+-----+-----+------+-------+ 959 Y = Yes, meets requirement 960 P = Partially meets requirement 961 N = No, does not meet requirement 962 N/A = Not applicable 964 Table1: Comparison Against Requirements 966 4. Security Considerations 968 This type of non-protocol document does not directly affect the 969 security of the Internet. 971 5. IANA Considerations 973 This document creates no considerations for IANA. 975 6. Acknowledgements 977 The authors would like to thank Bernard Aboba, Erik Guttman, Matt 978 Holdrege, Lyndon Ong, Jon Peterson, Christopher Ross, Micheal Tuexen 979 and Werner Vogels for their invaluable comments and suggestions. 981 7. References 983 7.1 Normative References 985 [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and 986 A. Silverton, "Architecture for Reliable Server Pooling", 987 draft-ietf-rserpool-arch-09 (work in progress), February 2005. 989 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 990 J., and M. Stillman, "Requirements for Reliable Server Pooling", 991 RFC 3237, January 2002. 993 7.2 Non-Normative References 995 [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 996 specifying the location of services (DNS SRV)", RFC 2782, 997 February 2000. 999 [4] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service 1000 Location Protocol, Version 2", RFC 2608, June 1999. 1002 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 1003 One: The Comprehensive DDDS", RFC 3401, October 2002. 1005 [6] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced 1006 Service Location Protocol (mSLP)", RFC 3528, April 2003. 1008 [7] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate 1009 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-09 1010 (work in progress), June 2004. 1012 [8] Xie, Q., Stewart, R., and M. Stillman, "Enpoint Name Resolution 1013 Protocol (ENRP)", draft-ietf-rserpool-enrp-09 (work in 1014 progress), July 2004. 1016 [9] Bradner, S., "The Internet Standards Process -- Revision 3", 1017 BCP 9, RFC 2026, October 1996. 1019 Authors' Addresses 1021 John Loughney (editor) 1022 Nokia Research Center 1023 PO Box 407 1024 Nokia Group FIN-00045 1025 Finland 1027 Email: john.loughney@nokia.com 1029 Aron J. Silverton (editor) 1030 Motorola, Inc. 1031 1301 East Algonquin Road 1032 Mail Drop 2246 1033 Schaumburg, IL 60196 1034 USA 1036 Phone: +1 847-576-8747 1037 Email: aron.j.silverton@motorola.com 1039 Maureen Stillman 1040 Nokia 1041 127 W. State Street 1042 Ithaca, NY 14850 1043 USA 1045 Phone: +1 607-273-0724 1046 Email: maureen.stillman@nokia.com 1048 Qiaobing Xie 1049 Motorola, Inc. 1050 1501 W. Shure Drive, #2309 1051 Arlington Heights, IL 60004 1052 USA 1054 Phone: +1 847-632-3028 1055 Email: qxie1@email.mot.com 1056 Randall R. Stewart 1057 Cisco Systems, Inc. 1058 8725 West Higgins Road 1059 Suite 300 1060 Chicago, IL 60631 1061 USA 1063 Phone: +1 815-477-2127 1064 Email: rrs@cisco.com 1066 Intellectual Property Statement 1068 The IETF takes no position regarding the validity or scope of any 1069 Intellectual Property Rights or other rights that might be claimed to 1070 pertain to the implementation or use of the technology described in 1071 this document or the extent to which any license under such rights 1072 might or might not be available; nor does it represent that it has 1073 made any independent effort to identify any such rights. Information 1074 on the procedures with respect to rights in RFC documents can be 1075 found in BCP 78 and BCP 79. 1077 Copies of IPR disclosures made to the IETF Secretariat and any 1078 assurances of licenses to be made available, or the result of an 1079 attempt made to obtain a general license or permission for the use of 1080 such proprietary rights by implementers or users of this 1081 specification can be obtained from the IETF on-line IPR repository at 1082 http://www.ietf.org/ipr. 1084 The IETF invites any interested party to bring to its attention any 1085 copyrights, patents or patent applications, or other proprietary 1086 rights that may cover technology that may be required to implement 1087 this standard. Please address the information to the IETF at 1088 ietf-ipr@ietf.org. 1090 Disclaimer of Validity 1092 This document and the information contained herein are provided on an 1093 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1094 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1095 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1096 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1097 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1098 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1100 Copyright Statement 1102 Copyright (C) The Internet Society (2005). This document is subject 1103 to the rights, licenses and restrictions contained in BCP 78, and 1104 except as set forth therein, the authors retain all their rights. 1106 Acknowledgment 1108 Funding for the RFC Editor function is currently provided by the 1109 Internet Society.