idnits 2.17.1 draft-evans-tip-functions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft K. Evans 2 Expires in 6 months J. Klein 3 Tandem Computers 4 J. Lyon 5 Microsoft 6 July 4 1997 8 Transaction Internet Protocol - Requirements 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Distribution of this document is unlimited. Please send comments to 32 the authors at , , 33 or . 35 Abstract 37 This document describes the purpose (usage scenarios) and 38 requirements for the Transaction Internet Protocol [1]. It is 39 intended to help qualify the necessary features and functions of 40 the protocol. 42 Introduction 44 Transactions are a very useful programming paradigm, greatly 45 simplifying the writing of distributed applications. When 46 transactions are employed, no matter how many distributed 47 application components participate in a particular unit-of-work, 48 the number of possible outcomes is reduced to only two; that is, 49 either all of the work completed successfully, or none of it did 50 (this characteristic is known as atomicity). Applications 51 programming is therefore much less complex since the programmer 52 does not have to deal with a multitude of possible failure 53 scenarios. Typically, transaction semantics are provided by some 54 underlying system infrastructure (usually in the form of products 55 such as Transaction Processing Monitors, and/or Databases). This 56 infrastructure deals with failures, and performs the necessary 57 recovery actions to guarantee the property of atomicity. The use 58 of transactions enables the development of reliable distributed 59 applications which would otherwise be difficult, if not impossible. 61 A key technology required to support distributed transactions is 62 the two-phase commit protocol (2-pc). 2-pc protocols have been used 63 in commercial Transaction Processing (TP) systems for many years, 64 and are well understood (e.g. the LU6.2 2-pc (syncpoint) protocol 65 was first implemented more than 12 years ago). Today a number of 66 different 2-pc protocols are supported by a variety of TP monitor 67 and database products. 2-pc is used between the components 68 participating in a distributed unit-of-work (transaction) to 69 ensure agreement by all parties regarding the outcome of that work 70 (regardless of any failure). 72 Today both standard and proprietary 2-pc protocols exist. These 73 protocols typically employ a "one-pipe" model. That is, the 74 transaction and application protocols are tightly-integrated, 75 executing over the same communications channel. An application may 76 use only the particular communications mechanism associated with 77 the transaction protocol. The older standard protocols (OSI TP, 78 LU6.2) are complex, with a large footprint and extensive 79 configuration and administration requirements. For these reasons 80 they are not very widely deployed. A new protocol, CORBA OTS, still 81 adheres to the one-pipe model, and is tightly coupled with a 82 particular application environment. The net of all this is 83 restricted application flexibility and interoperability if 84 transactions are to be used. Applications may wish to use a number 85 of communications protocols for which there are no transactional 86 variants (e.g. HTTP), and be deployed in very heterogeneous 87 application environments. 89 In summary, transactions greatly simplify the programming of 90 distributed applications, and the 2-pc protocol is a key 91 transactional technology. Current 2-pc protocols only offer 92 transaction semantics to a limited set of applications, operating 93 within a special-purpose (complex, homogeneous) infrastructure, 94 using a particular set of intercommunication protocols. The 95 restrictions thus imposed by current 2-pc protocols limits the 96 widespread use of the transaction paradigm, thereby inhibiting the 97 development of new distributed business applications. 99 (See [2] for more information re transactions, atomicity, and 100 two-phase commit protocols in general.) 102 The Transaction Internet Protocol (TIP) 104 TIP is a 2-pc protocol which is intended to provide ubiquitous 105 distributed transaction support, in a heterogeneous (networked) 106 environment. TIP removes the restrictions of current 2-pc 107 protocols and enables the development of new distributed business 108 applications. 110 This goal is achieved primarily by satisfying two key 111 requirements: 113 1. Keep the protocol simple (yet functionally sufficient). If the 114 protocol is complex it will not be widely deployed or quickly 115 adopted. Simplicity also means suitability to a wide range of 116 application environments. 118 2. Enable the protocol to be used with any applications 119 communications protocol (e.g. HTTP). This ensures heterogeneous 120 environments can participate in distributed work. 122 TIP does not reinvent the 2-pc protocol itself, the well-known 123 presumed-abort 2-pc protocol is used as a basis. Rather the novelty 124 and utility of TIP is in its separation from the application 125 communications protocol (the two-pipe model). 127 Scope 129 Note that TIP does not describe how business transactions or 130 electronic commerce are to be conducted on the internet, it 131 specifies only the 2-pc transaction protocol (which is an aid in 132 the development of such applications). TIP does not specify 133 Application Programming Interfaces. 135 Anticipated Usage of TIP 137 As described above, transactions are a very useful tool in 138 simplifying the programming of distributed applications. TIP is 139 therefore targeted at any application that involves distributed 140 work. Such applications may comprise components executing within a 141 single system, across a corporate intranet, across the internet, or 142 any other distributed system configuration. The application 143 may be of "enterprise" class (requiring high-levels of performance 144 and availability), or be less demanding. TIP is intended to 145 be generally applicable, meeting the requirements of any 146 application type which would benefit from the provision of 147 transaction semantics. 149 TIP Compliant Systems 151 There are two classes of TIP compliant Transaction Manager system: 153 1. Client-only systems. Those which provide an application 154 interface to demarcate TIP transactions, but which do not offer 155 access to local recoverable resources. Such a lightweight 156 implementation is useful for systems which host client 157 applications only (e.g. desktop machines). Such client systems 158 may be unreliable, and are not appropriate as transaction 159 coordinators (their unavailability might cause resources on 160 other transaction participant systems to remain locked and 161 unavailable). These so-called "volatile client" systems 162 therefore delegate the responsibility to coordinate the 163 transaction (and recover from failures), to other "full" 164 (server) TIP system implementations. For these lightweight 165 systems, only the TIP IDENTIFY, BEGIN, COMMIT, and ABORT 166 commands are needed; no transaction log is required. 168 2. Server systems. Those which offer the above support, plus TIP 169 transaction coordination and recovery services. These systems 170 may also provide access to recoverable resources 171 (e.g. relational databases). Server systems support all TIP 172 commands, and provide a recoverable transaction log. 174 A TIP compliant Transaction Manager (TM), will also supply 175 application programming interfaces to demarcate transactions 176 (e.g. the X/Open TX interface [3]), plus commands to generate TIP 177 URLs, to PUSH/PULL TIP transactions, and to set the current TIP 178 transaction context. TIP support can be added to TMs with existing 179 APIs and 2-pc protocols, and transactions may comprise both 180 proprietary and TIP transaction branches (it is assumed existing TM 181 implementations will provide "TIP gateway" facilities which will 182 coordinate between TIP and other transaction protocols). 184 Relationship to the X/Open DTP Model 186 The X/Open Distributed Transaction Processing (DTP) Model [4] 187 defines four components: 1) Application Program (AP), 188 2) Transaction Manager (TM), 3) Resource Manager (RM), 189 and 4) Communications Resource Manager (CRM). In this model, TIP 190 defines a TM to TM interoperability protocol, which is independent 191 of application communications (there is no such equivalent protocol 192 specified by X/Open, where all transaction and application 193 communication occurs between CRMs (the one-pipe model)). 194 Programmatic interfaces between the AP and TM/RM are unaffected by, 195 and may be used with TIP. The TM to RM interaction is defined via 196 the X/Open XA interface specification [5]. TIP is compatible with 197 XA, and a TIP transaction may comprise applications accessing 198 multiple RMs where the XA interface is being used to coordinate 199 the RM transaction branches. 201 Example TIP Usage Scenario 203 It is expected that a typical internet usage of TIP will involve 204 applications using the agency model. In this model, the client node 205 itself is not directly involved in the TIP protocol at all, and 206 does not need the services of a local TIP TM. Instead, an agency 207 (server) application handles the dialogue with the client, and is 208 responsible for the coordination of the TIP transaction. The agency 209 works with other service providers to deliver the service to the 210 client. e.g. as a Travel Agency acts as an intermediate between 211 airlines/hotels/etc and the customer. A big benefit of this model 212 is that the agency is trusted by the service providers, and there 213 are fewer such agencies (compared to user clients), so issues of 214 security and performance are reduced. 216 Consider a Travel Agency example. A client running a web browser 217 on a network PC accesses the Travel Agency web page. Via pages 218 served up by the agency (which may in turn may be constructed from 219 pages provided by the airline and hotel servers), the client 220 creates an itinerary involving flights and hotel choices. Finally, 221 the client clicks the "make reservation" button. At this point the 222 following sequence of events occurs (user-written application code 223 is invoked by the various web servers, via any of the standard or 224 proprietary techniques available (e.g. CGI)): 226 1. The travel agency begins a local transaction, and gets a TIP URL 227 for this transaction (both of these functions are performed 228 using the API of the local TM). The TIP URL contains the 229 listening endpoint IP address of the local TM and the 230 transaction identifier of the current transaction. 232 2. The travel agency application sends a request to the airline 233 server (via some protocol (e.g. HTTP) specified via some URL), 234 requesting the "book_flight" service, passing the flights 235 selected by the client, and the TIP URL (obtained in 1. above). 237 3. The request is received by the airline server which invokes the 238 book_flight application. This application retrieves the TIP URL 239 from the input data, and passes this on a "tip_pull" API request 240 to its local TM. The tip_pull function causes the following to 241 occur: 243 a. the local TM creates a transaction branch (under which the 244 work will be performed), 246 b. if a TIP connection does not already exist to the superior 247 (travel agency) TM (as identified via the IP address passed 248 in the TIP URL), one is created and an IDENTIFY exchange 249 occurs (if multiplexing is to be used on the connection, this 250 is followed by a MULTIPLEX exchange), 252 c. a PULL command is sent to the superior TM, 254 d. in response to the PULL, the superior TM associates the 255 subordinate (airline) TM with the transaction (by associating 256 the connection with the transaction), 258 e. the subordinate TM returns control to the book_flight 259 application, which is now executing in the context of the 260 newly created local transaction branch. 262 4. The book_flight application does its work (which may involve 263 access to a recoverable resource manager (e.g. an RDBMS), in 264 which case the local TM will associate the RM with the 265 transaction branch (via the XA interface or whatever)). 267 5. The book_flight application returns to the travel agency 268 application indicating success. 270 6. Steps 2-5 are then repeated with the hotel server "book_room" 271 application. At the conclusion of this, the superior TM has 272 registered two subordinate TMs as participants in the 273 transaction, there are TIP connections between the agency TM and 274 the airline and hotel TMs, and there are inflight transactions 275 at the airline and hotel servers. [Note that steps 2-5 and 6 276 could be performed in parallel.] 278 7. The travel agency application issues a "commit transaction" 279 request (using the API of the local TM). The local TM sends a 280 PREPARE command on the TIP connections to the airline and hotel 281 TMs (as these are registered as subordinate transaction 282 participants). 284 8. The TMs at the airline and hotel servers perform the 285 necessary steps to prepare their local recoverable resources 286 (e.g. by issuing xa_prepare requests). If successful, the 287 subordinate TMs change their TIP transaction state to Prepared, 288 and log recovery information (e.g. local and superior 289 transaction branch identifiers, and the IP address of the 290 superior TM). The subordinate TMs then send PREPARED commands to 291 the superior TM. 293 9. If both subordinates respond PREPARED, the superior TM logs that 294 the transaction is Committed, with recovery information 295 (e.g. local and subordinate transaction identifiers, and 296 subordinate TM IP addresses). The superior TM then sends COMMIT 297 commands on the two subordinate TIP connections. 299 10. The TMs at the airline and hotel servers perform the 300 necessary steps to commit their local recoverable resources 301 (e.g. by issuing xa_commit requests). The subordinate TMs 302 forget the transaction. The subordinate TMs then send COMITTED 303 commands to the superior TM. 305 11. The superior TM forgets the transaction. The TIP connections 306 between the superior and subordinate TMs return to Idle state 307 (not associated with any transaction). The superior TM returns 308 success to the travel agency application "commit transaction" 309 request. 311 12. The travel agency application returns "reservation made" to the 312 client. 314 TIP Transaction Recovery 316 Until the transaction reaches the Prepared state, any failure 317 results in the transaction being aborted. If an error occurs once 318 the transaction has reached the Prepared state, then transaction 319 recovery must be performed. Recovery behaviour is different for 320 superior and subordinate; the details depend upon the outcome of 321 the transaction (committed or aborted), and the precise point at 322 which failure occurs. 324 In the travel agency application for example, if the connection to 325 the hotel server fails before the COMMIT command has been received 326 by the hotel TM, then (once the connection is restored): 328 1. The superior (travel agency) TM sends a RECONNECT command 329 (passing the subordinate transaction identifier (recovered from 330 the transaction log if necessary)). 332 2. The subordinate (hotel) TM responds RECONNECTED (since it never 333 received the COMMIT command, and still has the transaction in 334 Prepared state (if the failure had occurred after the 335 subordinate had responded COMMITTED, then the subordinate would 336 have forgotten the transaction, and responded NOTRECONNECTED to 337 the RECONNECT command)). 339 3. The superior TM sends a COMMIT command. The subordinate TM 340 commits the transaction and responds COMMITTED. The transaction 341 is now resolved. 343 4. If the subordinate TM restores the connection to the superior TM 344 before receiving a RECONNECT command, then it may send a QUERY 345 command. In this case, the superior TM will respond 346 QUERIEDEXISTS, and the subordinate TM should wait for the 347 superior to send a RECONNECT command. If the transaction had 348 been aborted, then the superior may respond QUERIEDNOTFOUND, in 349 which case the subordinate should abort the transaction (note 350 that the superior is not obliged to send a RECONNECT command for 351 an aborted transaction (i.e. it could just forget the 352 transaction after sending ABORT and before receiving an ABORTED 353 response)). 355 Security 357 The means by which applications communicate and perform distributed 358 work are outside the scope of the TIP protocol. The mechanisms used 359 for authentication and authorisation of clients to access programs 360 and information on a particular system are part of the application 361 communications protocol and the application execution 362 infrastructure. Use of the TIP protocol does not affect these 363 considerations. 365 Security relates to the TIP protocol itself inasmuch that systems 366 require to protect themselves from the receipt of unauthorised TIP 367 commands, or the impersonation of a trusted partner TIP TM. 368 Probably the worst consequence of this is the possibility of 369 undetected data inconsistency resulting from violations of the TIP 370 commitment protocol (e.g. a COMMIT command is injected on a TIP 371 connection in place of an ABORT command). TIP implementations 372 concerned about this kind of attack can use the Secure Socket Layer 373 protocol [6] to restrict access to only trusted partners (i.e. to 374 control from which remote endpoints TIP transactions will be 375 accepted, and to verify that an end-point is genuine), and to 376 encrypt TIP commands. 378 TIP TM implementations will also likely provide local means to 379 time-out and abort transactions which have not completed within 380 some time period (thereby preventing unavailability of resources 381 due to malicious intent). 383 TIP Requirements 385 Most of these requirements stem from the primary objective of 386 making transactions a ubiquitous system service, available to all 387 application classes (much as TCP may be assumed to be available 388 everywhere). In general this requires imposing as few restrictions 389 regarding the use of TIP as possible (applications should not be 390 required to execute in some "special" environment in order to use 391 transactions), and keeping the protocol simple and efficient. This 392 enables the widespread implementation of TIP (it's cheap to do), on 393 a wide range of systems (it's cheap to run). 395 1. Application Communications Protocol Independence 397 The TIP protocol must be defined independently of the 398 communications protocol used for transferring application data, 399 to allow TIP usage in conjunction with any application protocol. 400 It must be possible for applications using arbitrary 401 communications protocols to begin, end, and propagate TIP 402 transactions. 404 This implies that the TIP protocol employ a 2-pipe model of 405 operation. This model requires the separation of application 406 communications and transaction coordination, into two discrete 407 communication channels (pipes). This separation enables the use 408 of the transaction coordination protocol (TIP), with any 409 application communications protocol (e.g. HTTP, ODBC, plain 410 TCP/UDP, etc). 412 2. Support for Transaction Semantics 414 The TIP protocol must provide the functionality of the de-facto 415 standard presumed-abort 2-pc protocol, to guarantee 416 transactional atomicity even in the event of failure. It should 417 provide a means to construct the transaction tree, as well as 418 provide commitment and recovery functions. 420 3. Application Transaction Propagation and Interoperability 422 In order to facilitate protocol independence, application 423 interoperability, and provide a means for TIP transaction 424 context propagation, a standard representation of the TIP 425 transaction context information is required (in the form of a 426 URL). This information must include the listening endpoint 427 address of the partner TIP TM, and transaction identifier 428 information. 430 4. Ease of Implementation 432 The TIP protocol must be simple to implement. It should support 433 only those features necessary to provide a useful, performant 434 2-pc protocol service. The protocol should not add complexity in 435 the form of extraneous optimisations. 437 5. Suitability for All Application Classes 439 The TIP protocol should be complete and robust enough not only 440 for electronic commerce on the web, but also for intranet 441 applications and for traditional TP applications spanning 442 heterogenous transaction manager environments. The protocol 443 should be performant and scaleable enough to meet the needs of 444 low to very high throughput applications. 446 - the TIP protocol should support the concept of client-only 447 transaction participants (useful for ultra-lightweight 448 implementations on low-end platforms) 450 - since some clients may be unreliable, TIP must provide support 451 for delegation of transaction coordination (to a more reliable 452 (trusted) node) 454 - the TIP protocol must scale between 1 and n (> 1) concurrent 455 transactions per TCP connection 457 - TIP commands should be able to be concatenated (pipelined) 459 - TIP should be compatible with the X/Open XA interface 460 6. Security 462 The TIP protocol must be compatible with existing security 463 mechanisms, potentially including encryption, firewalls, and 464 authorization mechanisms (e.g. SSL should be used to 465 authenticate the sender of a TIP command, and for encryption of 466 TIP commands). Nothing in the protocol definition should prevent 467 TIP working within any security environment. 469 7. TIP Protocol Transport Independence 471 It would be beneficial to some applications (though not 472 mandatory) to define the TIP protocol independently of the 473 transport for the TIP protocol itself. This would allow the TIP 474 protocol to flow over multiple different transport protocols. 475 The benefit is when using different transport protocols for the 476 application data, the same transport can be used for the TIP 2PC 477 protocol. 479 8. Recovery 481 Recovery semantics need to be defined sufficiently to avoid 482 ambiguous results in the event of any type of communications 483 transport failure. 485 References 487 [1] Internet Draft "The Transaction Internet Protocol" 488 J. Lyon et al. 490 [2] Transaction Processing: Concepts and Techniques 491 Morgan Kaufmann Publishers (ISBN 1-55860-190-2) 492 J. Gray, A. Reuter. 494 [3] X/Open CAE Specification, April 1995, Distributed Transaction 495 Processing: The TX Specification (ISBN 1-85912-094-6) 497 [4] X/Open Guide, November 1993, Distributed Transaction 498 Processing: Reference Model Version 2 (ISBN 1-85912-019-9) 500 [5] X/Open CAE Specification, December 1991, Distributed 501 Transaction Processing: The XA Specification 502 (ISBN 1-872630-24-3) 504 [6] Internet Draft "The SSL Protocol Version 3.0" 505 A. Freier, P. Karlton, P. Kocher. 507 Authors' Addresses 509 Jim Lyon Keith Evans 510 Microsoft Corporation Tandem Computers Inc, LOC 252-30 511 One Microsoft Way 5425 Stevens Creek Blvd 512 Redmond, WA 98052-6399, USA Santa Clara, CA 95051-7200, USA 514 Phone: +1 (206) 936 0867 Phone: +1 (408) 285 5314 515 Fax: +1 (206) 936 7329 Fax: +1 (408) 285 5245 516 Email: JimLyon@Microsoft.Com Email: Evans_Keith@Tandem.Com 517 Johannes Klein 518 Tandem Computers Inc. 519 10555 Ridgeview Court 520 Cupertino, CA 95014-0789, USA 522 Phone: +1 (408) 285 0453 523 Fax: +1 (408) 285 9818 524 Email: Klein_Johannes@Tandem.Com