idnits 2.17.1 draft-ietf-rserpool-arch-12.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 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1187. ** 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 issues found here. 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 (November 14, 2006) is 6372 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2026' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'RFC2608' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC2719' is defined on line 1080, but no explicit reference was found in the text == Unused Reference: 'RFC2960' is defined on line 1085, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-rserpool-threats-05 == Outdated reference: A later version (-11) exists of draft-ietf-rserpool-comp-10 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen, Ed. 3 Internet-Draft Muenster Univ. of Applied Sciences 4 Intended status: Informational Q. Xie 5 Expires: May 18, 2007 Motorola, Inc. 6 R. Stewart 7 M. Shore 8 Cisco Systems, Inc. 9 J. Loughney 10 Nokia Research Center 11 A. Silverton 12 Motorola Labs 13 November 14, 2006 15 Architecture for Reliable Server Pooling 16 draft-ietf-rserpool-arch-12.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 28 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 May 18, 2007. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Abstract 49 This document describes an architecture and protocols for the 50 management and operation of server pools supporting highly reliable 51 applications, and for client access mechanisms to a server pool. 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 The Problem Space . . . . . . . . . . . . . . . . . . . . . 3 57 1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 6 60 2 Reliable Server Pooling Architecture . . . . . . . . . . . . . 6 61 2.1 RSerPool Functional Components . . . . . . . . . . . . . . 7 62 2.1.1 Pool Elements . . . . . . . . . . . . . . . . . . . . . 7 63 2.1.2 ENRP Servers . . . . . . . . . . . . . . . . . . . . . 7 64 2.1.3 Pool Users . . . . . . . . . . . . . . . . . . . . . . 8 65 2.2 RSerPool Protocol Overview . . . . . . . . . . . . . . . . 8 66 2.2.1 Endpoint Handlespace Redundancy Protocol . . . . . . . 8 67 2.2.2 Aggregate Server Access Protocol . . . . . . . . . . . 9 68 2.2.3 PU <-> ENRP Server Communication . . . . . . . . . . . 9 69 2.2.4 PE <-> ENRP Server Communication . . . . . . . . . . . 10 70 2.2.5 PU <-> PE Communication . . . . . . . . . . . . . . . . 10 71 2.2.6 ENRP Server <-> ENRP Server Communication . . . . . . . 11 72 2.2.7 PE <->PE Communication . . . . . . . . . . . . . . . . 12 73 2.3 Failover Support . . . . . . . . . . . . . . . . . . . . . 12 74 2.3.1 Business Cards . . . . . . . . . . . . . . . . . . . . 12 75 2.3.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . 14 76 2.4 Typical Interactions between RSerPool Components . . . . . 14 77 3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 3.1 Two File Transfer Examples . . . . . . . . . . . . . . . . 16 79 3.1.1 The RSerPool Aware Client . . . . . . . . . . . . . . . 17 80 3.1.2 The RSerPool Unaware Client . . . . . . . . . . . . . . 18 81 3.2 Load Balancing Example . . . . . . . . . . . . . . . . . . 19 82 3.3 Telephony Signaling Example . . . . . . . . . . . . . . . . 20 83 3.3.1 Decomposed GWC and GK Scenario . . . . . . . . . . . . 21 84 3.3.2 Collocated GWC and GK Scenario . . . . . . . . . . . . 22 85 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 23 86 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 87 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 23 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 7.1 Normative References . . . . . . . . . . . . . . . . . . . 24 90 7.2 Informative References . . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 92 Intellectual Property and Copyright Statements . . . . . . . . . . 27 94 1 Introduction 96 1.1 The Problem Space 98 Fault tolerance is a difficult and challenging problem space. Most 99 of the solutions in this space involve an extensive effort on the 100 part of an application programmer and oftentimes the result is a 101 proprietary solution. There are a number of issues concerning 102 developers of fault tolerant applications including: 104 1. How to find a server that provides the service desired? 106 2. If the server that is providing me the service dies, how do I 107 find another one? 109 3. What type of redundancy model will I use, 2N or N+K? 111 4. How does a server providing a service share state with potential 112 peer servers in case of a failure? 114 5. How does a server assure that when it fails (or dies), the 115 clients will access the "best" server that is able to handle the 116 failure (or if you will take over for the departed server)? 118 6. From an operations and maintenance standpoint how do we add or 119 subtract capacity dynamically without reconfiguring our network? 121 A fault tolerant application needs to deal with these issues and many 122 more. Often an application is developed and then later, it is 123 realized that the application needs to be fault tolerant. The 124 response to this new requirement mandates either a hack or re-write 125 of the application. 127 So how can application writers solves these issues and makes it easy 128 for the application designer to add fault tolerance without hacking 129 or rewriting the application code? We use layering to solve this 130 problem. A session layer is inserted below the application layer to 131 provide a framework for fault tolerance. This removes some of the 132 complexity from the application writers hands thus freeing the 133 application writer to concentrate on the application. Note that not 134 all of the issues listed above can be solved by the session layer 135 framework alone, in particular the application will still need to 136 deal with state sharing, however the session layer framework will 137 also provide small tools when it can to help make even this job 138 easier for the application writer. 140 A second important point is that this layering no longer requires 141 each application to be custom programmed for fault tolerance. By 142 running an application on top of the session layer fault tolerant 143 services, there is no longer the need to design and implement fault 144 tolerance one application at a time. There are several benefits to 145 this approach: 147 1. Time and cost savings for the developers of the application 149 2. Experts in the area have developed the session layer fault 150 tolerance mechanism 152 3. An application can be developed without a fault tolerant 153 requirement and later in the life cycle, if this requirement 154 emerges, it can be met with Rserpool without a costly redesign. 156 4. Rserpool provides a set of APIs and hooks for the application 157 developer to implement fault tolerance 159 5. Rserpool provides a simple building block to the application for 160 rudimentary state sharing. 162 The above summary is the overall goal of Rserpool. We strive to 163 remove the details and complexity of fault tolerance from the 164 application writer and, when the session layer cannot solve the issue 165 (such as state sharing), give the application writer some small 166 building blocks on which they can solve the problem with minimal 167 effort. 169 In this document you will be introduced to a set of concepts for 170 solving a number of these problems. Often times the document will 171 refer to a named element (e.g Pool User) in the architecture sending 172 or receiving a message. When seeing this, please note that this is 173 NOT the application sending or receiving the query, but the session 174 layer below. Envision if you will the application opening up a 175 special form of socket. This socket will allow reading and writing 176 of data, but underneath will have special properties that allow it to 177 send and receive additional messages when the upper layer user 178 requests some service such as sending a message or binding a name. 179 Note again, the goal of RSERPOOL is NOT to solve all of the problems, 180 but to instead solve a subset of the fault tolerant issues and at the 181 same time provide a toolkit of standard utilities that will help an 182 application solve the remaining items in an easier way. 184 1.2 Overview 186 A server pool is defined as a set of one or more servers providing 187 the same application functionality. These servers are called Pool 188 Elements (PEs). PEs form the first class of entities in the RSerPool 189 architecture. Multiple PEs in a server pool can be used to provide 190 fault tolerance or load sharing, for example. 192 Each server pool is identified by a unique identifier which is simply 193 a byte string, called the pool handle. This allows binary 194 identifiers to be used. 196 These pool handles are not valid in the whole internet but only in 197 smaller domains, called the operational scope. Furthermore, the 198 handle-space is assumed to be flat, so that multiple levels of query 199 are not necessary to resolve a pool handle. 201 The second class of entities in the RSerPool architecture is the 202 class of Endpoint haNdlespace Redundancy Protocol (ENRP) servers. 203 ENRP servers are designed to provide a fully distributed fault- 204 tolerant real-time translation service that maps a pool handle to set 205 of transport addresses pointing to a specific group of networked 206 communication endpoints registered under that pool handle. To be 207 more precise, ENRP servers can resolve a pool handle to a list of 208 information which allows the Pool User (PU) to access a PE of the 209 server pool identified by the handle. This information includes: 211 o A list of IPv4 and/or IPv6 addresses. 213 o A protocol field specifying the transport layer protocol. 215 o A port number associated with the transport protocol, e.g. SCTP, 216 TCP or UDP. 218 Note that the RSerPool architecture supports both IPv4 and IPv6 219 addressing. 221 In each operational scope there must be at least one ENRP server. 222 All ENRP servers within the operational scope have knowledge of all 223 server pools within the operational scope. 225 RFC3237 [RFC3237] also requires that the ENRP servers should not 226 resolve a pool handle to a transport layer address of a PE which is 227 not in operation. Therefore each PE is supervised by one specific 228 ENRP server, called the home ENRP server of that PE. If it detects 229 that the PE is out of service all other ENRP servers are informed. 231 1.3 Terminology 233 This document uses the following terms: 235 Home ENRP Server: The ENRP server a Pool Element has registered 236 with. This ENRP server supervises the Pool Element. 238 Operational scope: The part of the network visible to pool users by 239 a specific instance of the reliable server pooling protocols. 241 Pool (or server pool): A collection of servers providing the same 242 application functionality. 244 Pool handle: A logical pointer to a pool. Each server pool will be 245 identifiable in the operational scope of the system by a unique 246 pool handle. 248 Pool element: A server entity having registered to a pool. 250 Pool user: A server pool user. 252 Pool element handle (or endpoint handle): A logical pointer to a 253 particular pool element in a pool, consisting of the pool handle 254 and a destination transport address of the pool element. 256 Handle space: A cohesive structure of pool handles and relations 257 that may be queried by an internal or external agent. 259 ENRP server: Entity which is responsible for managing and 260 maintaining the handle space within the RSerPool operational 261 scope. 263 1.4 Abbreviations 265 ASAP: Aggregate Server Access Protocol 267 ENRP: Endpoint haNdlespace Redundancy Protocol 269 PE: Pool element 271 PU: Pool user 273 SCTP: Stream Control Transmission Protocol 275 TCP: Transmission Control Protocol 277 2 Reliable Server Pooling Architecture 279 In this section, we define a reliable server pool architecture. 281 2.1 RSerPool Functional Components 283 There are three classes of entities in the RSerPool architecture: 285 o Pool Elements (PEs). 287 o ENRP Servers. 289 o Pool Users (PUs). 291 2.1.1 Pool Elements 293 A server pool is defined as a set of one or more servers providing 294 the same application functionality. These servers are called Pool 295 Elements (PEs). PEs form the first class of entities in the RSerPool 296 architecture. Multiple PEs in a server pool can be used to provide 297 fault tolerance or load sharing. 299 Each server pool is identified by a unique identifier which is simply 300 a byte string, called the pool handle. This allows binary 301 identifiers to be used. 303 These pool handles are not valid in the whole internet but only in 304 smaller domains, called the operational scope. Furthermore, the 305 handle-space is assumed to be flat, so that multiple levels of query 306 are not necessary to resolve a pool handle. 308 2.1.2 ENRP Servers 310 The second class of entities in the RSerPool architecture is the 311 class of ENRP servers. ENRP servers are designed to provide a fully 312 distributed fault-tolerant real-time translation service that maps a 313 pool handle to set of transport addresses pointing to a specific 314 group of networked communication endpoints registered under that pool 315 handle. To be more precise, ENRP servers can resolve a pool handle 316 to a list of information which allows the PU to access a PE of the 317 server pool identified by the handle. This information includes: 319 o A list of IPv4 and/or IPv6 addresses. 321 o A protocol field specifying the transport layer protocol. 323 o A port number associated with the transport protocol, e.g. SCTP, 324 TCP or UDP. 326 Note that the RSerPool architecture supports both IPv4 and IPv6 327 addressing. 329 In each operational scope there must be at least one ENRP server. 330 All ENRP servers within the operational scope have knowledge of all 331 server pools within the operational scope. 333 RFC3237 [RFC3237] also requires that the ENRP servers should not 334 resolve a pool handle to a transport layer address of a PE which is 335 not in operation. Therefore each PE is supervised by one specific 336 ENRP server, called the home ENRP server of that PE. If it detects 337 that the PE is out of service all other ENRP servers are informed. 339 2.1.3 Pool Users 341 A third class of entities in the architecture is the Pool User (PU) 342 class, consisting of the clients being served by the PEs of a server 343 pool. 345 2.2 RSerPool Protocol Overview 347 Based on the requirements in RFC3237 [RFC3237], the architecture of 348 two new protocols is introduced in this document: ENRP (Endpoint 349 haNdlespace Redundancy Protocol) and ASAP (Aggregate Server Access 350 Protocol). These are used because no existing protocols are suitable 351 (for a detailed discussion of comparisons please see 352 [I-D.ietf-rserpool-comp]). 354 2.2.1 Endpoint Handlespace Redundancy Protocol 356 The ENRP servers use a protocol called Endpoint haNdlespace 357 Redundancy Protocol (ENRP) for communication with each other to 358 exchange information and updates about the server pools. 360 ENRP guarantees the integrity of the RSerPool handlespace by 361 providing the means for an ENRP server to 363 o update its peers regarding changes to the handlspace caused by the 364 addition of a PE or the status change of an existing PE, 366 o monitor the health of its peers, and, if necessary, take over the 367 responsibility of being the home ENRP server for a set of PEs when 368 the ENRP server previously responsible for those PEs has failed, 369 and 371 o audit the handlespace for inconsistencies and synchronize the 372 handlespace amongst its peers when inconsistencies have been 373 found. 375 2.2.2 Aggregate Server Access Protocol 377 The PU wanting service from the pool uses the Aggregate Server Access 378 Protocol (ASAP) to access members of the pool. Depending on the 379 level of support desired by the application, use of ASAP may be 380 limited to an initial query for an active PE, or ASAP may be used to 381 mediate all communication between the PU and PE, so that automatic 382 failover from a failed PE to an alternate PE can be supported. 384 ASAP uses pool handles for addressing which isolates a logical 385 communication endpoint from its IP address(es), thus effectively 386 eliminating the binding between the communication endpoint and its 387 physical IP address(es) which normally constitutes a single point of 388 failure. 390 In addition, ASAP provides some mechanisms to support loadsharing 391 between PEs within the same pool and to support the upper layer in 392 case of a failover between PEs becomes necessary. 394 ASAP is also used by a PE to join or leave a server pool. The PE 395 registers or deregisters itself by communicating with an ENRP server, 396 which will normally be the home ENRP server. ASAP allows dynamic 397 system scalability, allowing the pool membership to change at any 398 time. 400 ASAP is used by a home ENRP server to supervise the PEs that have 401 registered with that ENRP server. If the home ENRP server detects 402 that a PE is out of service via ASAP, it notifies its peers using 403 ENRP as described previously. 405 2.2.3 PU <-> ENRP Server Communication 407 The PU <-> ENRP server communication is used for resolving pool 408 handles and uses ASAP. The PU sends a pool handle to the ENRP server 409 and gets back the information necessary for accessing a server in a 410 server pool. 412 This communication can be based on SCTP or TCP if the PU does not 413 support SCTP. The protocol stack for a PU is shown in Figure 1. 415 ********** ************ 416 * PU * * ENRP * 417 * * * server * 418 ********** ************ 420 +--------+ +--------+ 421 | ASAP | | ASAP | 422 +--------+ +--------+ 423 |SCTP/TCP| |SCTP/TCP| 424 +--------+ +--------+ 425 | IP | | IP | 426 +--------+ +--------+ 428 Protocol stack between PU and ENRP server 430 Figure 1 432 2.2.4 PE <-> ENRP Server Communication 434 The PE <-> ENRP server communication is used for registration and 435 deregistration of the PE in one or more pools and for the supervision 436 of the PE by the home ENRP server. This communication uses ASAP and 437 is based on SCTP, the protocol stack is shown in the following 438 figure. 440 ******** ********** 441 * PE * * ENRP * 442 * * * server * 443 ******** ********** 445 +------+ +------+ 446 | ASAP | | ASAP | 447 +------+ +------+ 448 | SCTP | | SCTP | 449 +------+ +------+ 450 | IP | | IP | 451 +------+ +------+ 452 Protocol stack between PE and ENRP server 454 Figure 2 456 2.2.5 PU <-> PE Communication 458 The PU <-> PE communication can be divided into two parts: 460 o control channel 461 o data channel 463 The data channel is used for the transmission of the upper layer 464 data, the control channel is used to exchange RSerPool information. 466 There are two supported scenarios: 468 o Multiplexed data and control channel. Both channels are 469 transported over one transport connection. This can either be an 470 SCTP association, with data and control channel are separated by 471 the PPID, or a TCP connection, with data and control channel being 472 handled by a TCP mapping layer. 474 o Data channel and no control channel. There is no restriction on 475 the transport protocol in this case. Note that certain enhanced 476 failover services (e.g. business cards, state cookies, message 477 failover described in Section 2.3) are not available when this 478 method is used. 480 For a given pool, all PUs and PEs should make the same choice for the 481 style of interaction between each other: that is, for a given pool, 482 either all PEs and PUs in that pool use a multiplexed control/data 483 channel for PU-PE communication, or all PEs and PUs in that pool use 484 a data channel only for PU-PE communication. 486 When the multiplexed data and control channel is used, enhanced 487 failover services may be provided, including: 489 o The PE can send a business card to the PU which provides 490 information as to which other PE the PU should failover to in case 491 of a failure in the serving PE (a last will and testament so to 492 speak). 494 o The PE can send cookies to the PU. The PU would store only the 495 last cookie and send it to the new PE in case of a failover. This 496 provides a small hook that a PE can use to propagate small amounts 497 of state information upon failure. 499 See Section 2.3 for further details. 501 2.2.6 ENRP Server <-> ENRP Server Communication 503 The communication between ENRP servers is used to share the knowledge 504 about all server pools between all ENRP servers in an operational 505 scope. 507 For this communication ENRP over SCTP is used and the protocol stack 508 is shown in Figure 3. 510 ********** ********** 511 * ENRP * * ENRP * 512 * server * * server * 513 ********** ********** 515 +------+ +------+ 516 | ENRP | | ENRP | 517 +------+ +------+ 518 | SCTP | | SCTP | 519 +------+ +------+ 520 | IP | | IP | 521 +------+ +------+ 522 Protocol stack between ENRP servers 524 Figure 3 526 When a ENRP server initializes a UDP multicast message may be 527 transmitted for initial detection of other ENRP servers in the 528 operational scope. The other ENRP servers send a response using a 529 unicast UDP message. 531 2.2.7 PE <->PE Communication 533 This is a special case of the PU <-> PE communication. In this case 534 the PU is also a PE in a server pool, this means that one PE is 535 acting like a PU during the communication setup. 537 The difference between a pure PU <-> PE communication is that the PE 538 acting as a PU can send the PE the information that it is actually a 539 PE of a pool. This means that the pool handle is transferred via the 540 control channel. See Section 2.3 for further details. 542 2.3 Failover Support 544 If the PU detects the failure of a PE it may fail over to a different 545 PE. The selection to a new PE should be made such that most likely 546 the new PE is not affected by the failed one. 548 There are some mechanisms provided by RSerPool to support the 549 failover to a new PE. 551 2.3.1 Business Cards 553 A PE can send a business card to its peer (PE or PU) containing its 554 pool handle and optionally information to which other PEs the peer 555 should failover. This gives a PE a form of last will and testament 556 that can be used to guide a PU to select the "next best" PE. This 557 determination may be made by the PE giving the business card in such 558 a way as to spread the load evenly across the server pool, or it may 559 be given with the knowledge that certain PE's will have a more 560 current set of state available to service the PU. 562 Presenting the pool handle is important in case of PE <-> PE 563 communication in which one of the PEs acts as a PU for establishing 564 the communication. This can yield fault tolerance in both directions 565 in cases where instead of client/ server, peer to peer concepts are 566 being used and both are members of separate server pools. Often 567 times in such a case, the PE selected does not know the name of the 568 PU's server pool, by providing that information both PE's will be 569 capable of failing over to an alternate. 571 Providing information to which PE the PU should failover can also be 572 very important. Consider the scenario presented in the following 573 figure. 575 ....................... 576 . +-------+ . 577 . | | . 578 . | PE 1 | . 579 . | | . 580 . +-------+ . 581 . . 582 . server pool . 583 . . 584 . . 585 +-------+ . +-------+ . +-------+ 586 | | . | | . | | 587 | PU 1 |------.------| PE 2 |------.-------| PU 2 | 588 | | . | | . | | 589 +-------+ . +-------+ . +-------+ 590 . . 591 . . 592 . . 593 . . 594 . +-------+ . 595 . | | . 596 . | PE 3 | . 597 . | | . 598 . +-------+ . 599 ....................... 600 Two PUs accessing the same PE 602 PU 1 is using PE 2 of the server pool. Assume that PE 1 and PE 2 603 share state but not PE 2 and PE 3. Using the business card of PE 2 604 it is possible for PE 2 to inform PU 1 that it should fail over to PE 605 1 in case of a failure. 607 A slightly more complicated situation is if two pool users, PU 1 and 608 PU 2, use PE 2 but both, PU 1 and PU 2, need to use the same PE. 609 Then it is important that PU 1 and PU 2 fail over to the same PE. 610 This can be handled in a way such that PE 2 gives the same business 611 card to PU 1 and PU 2. 613 2.3.2 Cookies 615 Cookies may optionally be sent from the PE to the PU. The PU only 616 stores the last received cookie. In case of fail over the PU sends 617 this last received cookie to the new PE. This method provides a 618 simple way of state sharing between the PEs. Please note that the 619 old PE should sign the cookie and the receiving PE should verify the 620 signature. For the PU, the cookie has no structure and is only 621 stored and transmitted to the new PE. 623 2.4 Typical Interactions between RSerPool Components 625 The following drawing shows the typical RSerPool components and their 626 possible interactions with each other: 628 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 629 ~ operational scope ~ 630 ~ ......................... ......................... ~ 631 ~ . server pool 1 . . server pool 2 . ~ 632 ~ . +-------+ +-------+ . (d) . +-------+ +-------+ . ~ 633 ~ . |PE(1,A)| |PE(1,C)|<-------------->|PE(2,B)| |PE(2,A)|<---+ ~ 634 ~ . +-------+ +-------+ . . +-------+ +-------+ . | ~ 635 ~ . ^ ^ . . ^ ^ . | ~ 636 ~ . | (a) | . . | | . | ~ 637 ~ . +----------+ | . . | | . | ~ 638 ~ . +-------+ | | . . | | . | ~ 639 ~ . |PE(1,B)|<---+ | | . . | | . | ~ 640 ~ . +-------+ | | | . . | | . | ~ 641 ~ . ^ | | | . . | | . | ~ 642 ~ .......|........|.|.|.... .......|.........|....... | ~ 643 ~ | | | | | | | ~ 644 ~ (c)| (a)| | |(a) (a)| (a)| (c)| ~ 645 ~ | | | | | | | ~ 646 ~ | v v v v v | ~ 647 ~ | +++++++++++++++ (e) +++++++++++++++ | ~ 648 ~ | + ENRP server +<---------->+ ENRP server + | ~ 649 ~ | +++++++++++++++ +++++++++++++++ | ~ 650 ~ v ^ ^ | ~ 651 ~ ********* | | | ~ 652 ~ * PU(A) *<-------+ (b)| | ~ 653 ~ ********* (b) | | ~ 654 ~ v | ~ 655 ~ ::::::::::::::::: (f) ***************** | ~ 656 ~ : other clients :<------------->* proxy/gateway * <---+ ~ 657 ~ ::::::::::::::::: ***************** ~ 658 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 659 RSerPool components and their possible interactions. 661 Figure 5 663 In this figure we can identify the following possible interactions: 665 (a) server pool elements <-> ENRP server: (ASAP) Each PE in a pool 666 uses ASAP to register or de-register itself as well as to exchange 667 other auxiliary information with the ENRP server. The ENRP server 668 also uses ASAP to monitor the operational status of each PE in a 669 pool. 671 (b) PU <-> ENRP server: (ASAP) A PU normally uses ASAP to request 672 the ENRP server for a pool handle to address translation service 673 before the PU can send user messages addressed to a server pool by 674 the pool's handle. 676 (c) PU <-> PE: (ASAP) ASAP can be used to exchange some auxiliary 677 information of the two parties before they engage in user data 678 transfer. 680 (d) server pool <-> server pool: (ASAP) A PE in a server pool can 681 become a PU to another pool when the PE tries to initiate 682 communication with the other pool. In such a case, the 683 interactions described in (a) and (c) above will apply. 685 (e) ENRP server <-> ENRP server: (ENRP) ENRP can be used to fulfill 686 various handle space operation, administration, and maintenance 687 (OAM) functions. 689 (f) Other Clients <-> Proxy/Gateway: standard protocols The proxy/ 690 gateway enables clients ("other clients"), which are not RSerPool 691 aware, to access services provided by an RSerPool based server 692 pool. It should be noted that these proxies/gateways may become a 693 single point of failure. 695 3 Examples 697 In this section the basic concepts behind ENRP and ASAP are 698 illustrated through examples. First, an RSerPool aware FTP server 699 and Rserpool aware clients are presented. Secondly, a scenario with 700 an RSerPool aware server with an Rserpool non-aware client shows how 701 to effectively use Rserpool with legacy clients or in a situation 702 where exposure to the PU of the list of addresses associated with the 703 handlespace is undesirable. This requirement has been expressed by 704 some telephony network operators who are concerned about potential 705 network address mapping. The last two examples illustrate load 706 balancing and telephony scenarios. 708 3.1 Two File Transfer Examples 710 In this section we present two file transfer examples using ENRP and 711 ASAP. We present two separate examples demonstrating an RSerPool- 712 aware client and an RSerPool-unaware client that is using a Proxy or 713 Gateway to perform the file transfer. In these examples we will use 714 a FTP RFC959 [RFC0959] model with some modifications. In the first 715 example (client is RSerPool-aware) we will modify FTP concepts so 716 that the file transfer takes place over SCTP. In the second example, 717 we will use TCP between the RSerPool-unaware client and the Proxy. 718 The Proxy itself will use the modified FTP with RSerPool as 719 illustrated in the first example. 721 Please note that in the example we do NOT follow FTP RFC959 [RFC0959] 722 precisely but use FTP-like concepts and attempt to adhere to the 723 basic FTP model. These examples use FTP for illustrative purposes. 724 FTP was chosen since many of the basic concept are well known and 725 should be familiar to readers. 727 3.1.1 The RSerPool Aware Client 729 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 730 ~ operational scope ~ 731 ~ ......................... ~ 732 ~ . "file transfer pool" . ~ 733 ~ . +-------+ +-------+ . ~ 734 ~ +-> |PE(1,A)| |PE(1,C)| . ~ 735 ~ |. +-------+ +-------+ . ~ 736 ~ |. ^ ^ . ~ 737 ~ |. +----------+ | . ~ 738 ~ |. +-------+ | | . ~ 739 ~ |. |PE(1,B)|<---+ | | . ~ 740 ~ |. +-------+ | | | . ~ 741 ~ |. ^ | | | . ~ 742 ~ |.......|........|.|.|.... ~ 743 ~ | ASAP | ASAP| | |ASAP ~ 744 ~ |(d) |(c) | | | ~ 745 ~ | v v v v ~ 746 ~ | ********* +++++++++++++++ ~ 747 ~ + ->* PU(X) * + ENRP server + ~ 748 ~ ********* +++++++++++++++ ~ 749 ~ ^ ASAP ^ ~ 750 ~ | <-(b) | ~ 751 ~ +--------------+ ~ 752 ~ (a)-> ~ 753 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 755 Architecture for RSerPool aware client. 757 Figure 6 759 To effect a file transfer the following steps would take place. 761 1. The application in PU(X) sends a login request. The PU(X)'s ASAP 762 layer sends an ASAP request to an ENRP server to request the list 763 of pool elements (using (a)). The pool handle to identify the 764 pool is "File Transfer Pool". The ASAP layer queues the login 765 request. 767 2. The ENRP server returns a list of the three PEs PE(1,A), PE(1,B) 768 and PE(1,C) to the ASAP layer in PU(X) (using (b)). 770 3. The ASAP layer selects one of the PEs, for example PE(1,B). It 771 transmits the login request and the other FTP control data. 772 Finally, it starts the transmission of the requested files (using 773 (c)). Note that optionally, the multiple stream feature of SCTP 774 could be used. 776 4. Suppose that during the file transfer transmission, PE(1,B) 777 fails. If the PE's are sharing file transfer state, a fail-over 778 to PE(1,A) could be initiated. PE(1,A) then continues the 779 transfer until complete (see (d)). In parallel, a request from 780 PE(1,A) is made to the ENRP server to request a cache update for 781 the server pool "File Transfer Pool". Furthermore, a report is 782 generated that PE(1,B) is non-responsive. This would trigger 783 appropriate audits that may remove PE(1,B) from the pool if the 784 ENRP server had not already detected the failure) (using (a)). 786 3.1.2 The RSerPool Unaware Client 788 In this example we investigate the use of a Proxy server assuming the 789 same set of scenario as illustrated above. 791 In this example the steps will occur: 793 1. The FTP client and the Proxy/Gateway are using the TCP-based ftp 794 protocol. The client sends the login request to the proxy (using 795 (e)). 797 2. The proxy behaves like a client and performs the actions 798 described under (1), (2) and (3) of the above description (using 799 (a), (b) and (c)). 801 3. The ftp communication continues and will be translated by the 802 proxy into the RSerPool aware dialect. This interworking uses 803 (f) and (c). 805 Note that in this example high availability is maintained between the 806 Proxy and the server pool but a single point of failure exists 807 between the FTP client and the Proxy, i.e. the command TCP connection 808 and its one IP address it is using for commands. 810 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 811 ~ operational scope ~ 812 ~ ......................... ~ 813 ~ . "file transfer pool" . ~ 814 ~ . +-------+ +-------+ . ~ 815 ~ . |PE(1,A)| |PE(1,C)| . ~ 816 ~ . +-------+ +-------+ . ~ 817 ~ . ^ ^ . ~ 818 ~ . +----------+ | . ~ 819 ~ . +-------+ | | . ~ 820 ~ . |PE(1,B)|<---+ | | . ~ 821 ~ . +-------+ | | | . ~ 822 ~ .......^........|.|.|.... ~ 823 ~ | | | | ~ 824 ~ | ASAP| | |ASAP ~ 825 ~ | | | | ~ 826 ~ | v v v ~ 827 ~ | +++++++++++++++ +++++++++++++++ ~ 828 ~ | + ENRP server +<--ENRP-->+ ENRP server + ~ 829 ~ | +++++++++++++++ +++++++++++++++ ~ 830 ~ | ASAP ^ ~ 831 ~ | ASAP (c) (b) | ^ ~ 832 ~ +---------------------------------+ | | | ~ 833 ~ | v | (a) ~ 834 ~ v v ~ 835 ~ ::::::::::::::::: (e)-> ***************** ~ 836 ~ : FTP client :<------------->* proxy/gateway * ~ 837 ~ ::::::::::::::::: (f) ***************** ~ 838 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 839 Architecture for RSerPool unaware client. 841 Figure 7 843 3.2 Load Balancing Example 845 This example is similar to the one above describing an RSerPool 846 unaware client. In both examples the clients do not need to support 847 the RSerPool protocol suite. 849 There are several servers in a pool and the traffic from clients is 850 distributed among them by a load balancer. The load balancer can 851 make use of load information provided by the servers for optimal load 852 distribution. 854 One possibility of using RSerPool for this application is described 855 in the next figure. The servers become pool elements in a pool and 856 register themselves with ENRP servers. They can also provide load 857 information. The load balancer acts as a pool user and gets the 858 addresses and possibly the load information via ASAP communication 859 with ENRP servers. The communication between the clients and servers 860 is not affected. 862 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 863 ~ operational scope ~ 864 ~ ......................... ~ 865 ~ . "server pool" . ~ 866 ~ . +-------+ +-------+ . ~ 867 ~ . |PE(1,A)| |PE(1,C)| . ~ 868 ~ . +-------+ +-------+ . ~ 869 ~ . ^ ^ . ~ 870 ~ . +----------+ | . ~ 871 ~ . +-------+ | | . ~ 872 ~ . |PE(1,B)|<---+ | | . ~ 873 ~ . +-------+ | | | . ~ 874 ~ .......^........|.|.|.... ~ 875 ~ | | | | ~ 876 ~ | ASAP| | |ASAP ~ 877 ~ | | | | ~ 878 ~ | v v v ~ 879 ~ | +++++++++++++++ +++++++++++++++ ~ 880 ~ | + ENRP server +<--ENRP-->+ ENRP server + ~ 881 ~ | +++++++++++++++ +++++++++++++++ ~ 882 ~ | ^ ~ 883 ~ | (c) | ~ 884 ~ +---------------------------------+ | ASAP ~ 885 ~ | | (a) ~ 886 ~ v v ~ 887 ~ ::::::::::::::::: (b) ********************** ~ 888 ~ : client :<----------->* load balancer (PU) * ~ 889 ~ ::::::::::::::::: ********************** ~ 890 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 891 Architecture for an RSerPool based load balancer. 893 Figure 8 895 3.3 Telephony Signaling Example 897 This example shows the use of ASAP/RSerPool to support server pooling 898 for high availability of a telephony application such as a Voice over 899 IP Gateway Controller (GWC) and Gatekeeper services (GK). 901 In this example, we show two different scenarios of deploying these 902 services using RSerPool in order to illustrate the flexibility of the 903 RSerPool architecture. 905 3.3.1 Decomposed GWC and GK Scenario 907 In this scenario, both GWC and GK services are deployed as separate 908 pools with some number of PEs, as shown in the following diagram. 909 Each of the pools will register their unique pool handle with the 910 ENRP server. We also assume that there are a Signaling Gateway (SG) 911 and a Media Gateway (MG) present and both are RSerPool aware. 913 ................... 914 . gateway . 915 . controller pool . 916 ................. . +-------+ . 917 . gatekeeper . . |PE(2,A)| . 918 . pool . . +-------+ . 919 . +-------+ . . +-------+ . 920 . |PE(1,A)| . . |PE(2,B)| . 921 . +-------+ . . +-------+ . 922 . +-------+ . (d) . +-------+ . 923 . |PE(1,B)|<------------>|PE(2,C)|<-------------+ 924 . +-------+ . . +-------+ . | 925 ................. ........^.......... | 926 | | 927 (c)| (e)| 928 | v 929 +++++++++++++++ ********* ***************** 930 + ENRP server + * SG(X) * * media gateway * 931 +++++++++++++++ ********* ***************** 932 ^ ^ 933 | | 934 | <-(a) | 935 +-------------------+ 936 (b)-> 938 Deployment of Decomposed GWC and GK. 940 Figure 9 942 As shown in the previous figure, the following sequence takes place: 944 1. The Signaling Gateway (SG) receives an incoming signaling message 945 to be forwarded to the GWC. SG(X)'s ASAP layer sends an ASAP 946 request to its "local" ENRP server to request the list of pool 947 elements (PE's) of GWC (using (a)). The handle used for this 948 query is the pool handle of the GWC. The ASAP layer queues the 949 data to be sent to the GWC in local buffers until the ENRP server 950 responds. 952 2. The ENRP server returns a list of the three PE's A, B and C to 953 the ASAP layer in SG(X) together with information to be used for 954 load-sharing traffic across the gateway controller pool (using 955 (b)). 957 3. The ASAP layer in SG(X) will select one PE (e.g., PE(2,C)) and 958 send the signaling message to it (using (c)). The selection is 959 based on the load sharing information of the gateway controller 960 pool. 962 4. To progress the call, PE(2,C) finds that it needs to talk to the 963 Gatekeeper. Assuming it has the gatekeeper pool's information in 964 its local cache (e.g., obtained and stored from a recent query to 965 ENRP server), PE(2,C) selects PE(1,B) and sends the call control 966 message (using (d)). 968 5. We assume PE(1,B) responds to PE(2,C) and authorizes the call to 969 proceed. 971 6. PE(2,C) issues media control commands to the Media Gateway (using 972 (e)). 974 RSerPool will provide service robustness to the system if some 975 failure occurs in the system. 977 For example, if PE(1, B) in the Gatekeeper Pool crashed after 978 receiving the call control message from PE(2, C) in step (d) above. 979 What most likely will happen is that, due to the absence of a reply 980 from the Gatekeeper, a timer expiration event will trigger the call 981 state machine within PE(2, C) to resend the control message. The 982 ASAP layer at PE(2, C) will then notice the failure of PE(1, B) 983 through the endpoint unreachability detection by the transport 984 protocol beneath ASAP and automatically deliver the re-sent call 985 control message to the alternate GK pool member PE(1, A). With 986 appropriate intra-pool call state sharing support, PE(1, A) will 987 correctly handle the call and reply to PE(2, C) and hence progress 988 the call. 990 3.3.2 Collocated GWC and GK Scenario 992 In this scenario, the GWC and GK services are collocated (e.g., they 993 are implemented as a single process). In this case, one can form a 994 pool that provides both GWC and GK services as shown in the figure 995 below. 997 The same sequence as described in 5.2.1 takes place, except that step 998 (4) now becomes internal to the PE(3,C). Again, we assume server C 999 is selected by SG. 1001 ........................................ 1002 . gateway controller/gatekeeper pool . 1003 . +-------+ . 1004 . |PE(3,A)| . 1005 . +-------+ . 1006 . +-------+ . 1007 . |PE(3,C)|<---------------------------+ 1008 . +-------+ . | 1009 . +-------+ ^ . | 1010 . |PE(3,B)| | . | 1011 . +-------+ | . | 1012 ................|....................... | 1013 | | 1014 +-------------+ | 1015 | | 1016 (c)| (e)| 1017 v v 1018 +++++++++++++++ ********* ***************** 1019 + ENRP server + * SG(X) * * media gateway * 1020 +++++++++++++++ ********* ***************** 1021 ^ ^ 1022 | | 1023 | <-(a) | 1024 +-------------------+ 1025 (b)-> 1027 Deployment of Collocated GWC and GK. 1029 Figure 10 1031 4 Security Considerations 1033 The RSerPool protocol must allow us to secure the RSerPool 1034 infrastructure. There are security and privacy issues that relate to 1035 the handle space, pool element registration and user queries of the 1036 handle space. In [I-D.ietf-rserpool-threats] a complete threat 1037 analysis of RSerPool components is presented. 1039 5 IANA Considerations 1041 There are no actions needed. 1043 6 Acknowledgments 1045 The authors would like to thank Bernard Aboba, Phillip Conrad, Harrie 1046 Hazewinkel, Matt Holdrege, Lyndon Ong, Christopher Ross, Maureen 1047 Stillman, Werner Vogels and many others for their invaluable comments 1048 and suggestions. 1050 7. References 1052 7.1. Normative References 1054 [I-D.ietf-rserpool-threats] 1055 Stillman, M., "Threats Introduced by Rserpool and 1056 Requirements for Security in response to Threats", 1057 draft-ietf-rserpool-threats-05 (work in progress), 1058 July 2005. 1060 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1061 3", BCP 9, RFC 2026, October 1996. 1063 7.2. Informative References 1065 [I-D.ietf-rserpool-comp] 1066 Loughney, J., "Comparison of Protocols for Reliable Server 1067 Pooling", draft-ietf-rserpool-comp-10 (work in progress), 1068 July 2005. 1070 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1071 RFC 793, September 1981. 1073 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 1074 STD 9, RFC 959, October 1985. 1076 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 1077 "Service Location Protocol, Version 2", RFC 2608, 1078 June 1999. 1080 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 1081 L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, 1082 "Framework Architecture for Signaling Transport", 1083 RFC 2719, October 1999. 1085 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1086 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1087 Zhang, L., and V. Paxson, "Stream Control Transmission 1088 Protocol", RFC 2960, October 2000. 1090 [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 1091 Loughney, J., and M. Stillman, "Requirements for Reliable 1092 Server Pooling", RFC 3237, January 2002. 1094 Authors' Addresses 1096 Michael Tuexen (editor) 1097 Muenster Univ. of Applied Sciences 1098 Stegerwaldstr. 39 1099 48565 Steinfurt 1100 Germany 1102 Email: tuexen@fh-muenster.de 1104 Qiaobing Xie 1105 Motorola, Inc. 1106 1501 W. Shure Drive, #2309 1107 Arlington Heights, IL 60004 1108 USA 1110 Phone: +1-847-632-3028 1111 Email: qxie1@email.mot.com 1113 Randall R. Stewart 1114 Cisco Systems, Inc. 1115 8725 West Higgins Road 1116 Suite 300 1117 Chicago, IL 60631 1118 USA 1120 Phone: +1-815-477-2127 1121 Email: rrs@cisco.com 1123 Melinda Shore 1124 Cisco Systems, Inc. 1125 809 Hayts Rd 1126 Ithaca, NY 14850 1127 USA 1129 Phone: +1 607 272 7512 1130 Email: mshore@cisco.com 1131 John Loughney 1132 Nokia Research Center 1133 PO Box 407 1134 FIN-00045 Nokia Group FIN-00045 1135 Finland 1137 Email: john.loughney@nokia.com 1139 Aron J. Silverton 1140 Motorola Labs 1141 1301 E. Algonquin Road 1142 Room 2246 1143 Schaumburg, IL 60196 1144 US 1146 Phone: +1 847-576-8747 1147 Email: aron.j.silverton@motorola.com 1149 Full Copyright Statement 1151 Copyright (C) The Internet Society (2006). 1153 This document is subject to the rights, licenses and restrictions 1154 contained in BCP 78, and except as set forth therein, the authors 1155 retain all their rights. 1157 This document and the information contained herein are provided on an 1158 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1159 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1160 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1161 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1162 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1163 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1165 Intellectual Property 1167 The IETF takes no position regarding the validity or scope of any 1168 Intellectual Property Rights or other rights that might be claimed to 1169 pertain to the implementation or use of the technology described in 1170 this document or the extent to which any license under such rights 1171 might or might not be available; nor does it represent that it has 1172 made any independent effort to identify any such rights. Information 1173 on the procedures with respect to rights in RFC documents can be 1174 found in BCP 78 and BCP 79. 1176 Copies of IPR disclosures made to the IETF Secretariat and any 1177 assurances of licenses to be made available, or the result of an 1178 attempt made to obtain a general license or permission for the use of 1179 such proprietary rights by implementers or users of this 1180 specification can be obtained from the IETF on-line IPR repository at 1181 http://www.ietf.org/ipr. 1183 The IETF invites any interested party to bring to its attention any 1184 copyrights, patents or patent applications, or other proprietary 1185 rights that may cover technology that may be required to implement 1186 this standard. Please address the information to the IETF at 1187 ietf-ipr@ietf.org. 1189 Acknowledgment 1191 Funding for the RFC Editor function is provided by the IETF 1192 Administrative Support Activity (IASA).