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