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