INTERNET DRAFT A. Cornish, INETCO Systems Ltd. Category: Informational M. Cox, Alcatel Australia Pty. Ltd. Title: draft-cornish-qtp-05.txt R. Neill, INETCO Systems Ltd. I. Palmer, Lucent Technologies A. Telfer, INETCO Systems Ltd. C. Wignell, CoSine Communications C. Young October 2002 Quick Transaction Protocol - QTP Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract QTP is a simple protocol for multiplexing short-duration connections over an arbitrary transport service such as UDP. QTP is an open standard to allow dial-up Credit Authorization Terminals (CAT) or Point-Of-Sale (POS) terminals to connect into IP hosts. These transactions require fast connection times, efficient concentration of many sessions, fault tolerant operation, and the ability to transfer access network addressing (called and calling numbers) along with transaction data. Table of Contents Cornish et. al. expires May 2005 [Page 1] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 1. INTRODUCTION 3 1.1 Typical Application 3 1.2 Protocol Requirements 4 1.3 Other Approaches 4 1.4 QTP Attributes 5 1.5 Specification of Requirements 6 1.6 Terminology 6 2. QTP FRAMEWORK 7 3. QTP MESSAGE FORMAT 9 3.1 Message Header 9 3.2 Message Types 11 4. DETAILED MESSAGE TYPES 12 4.1 Call Request 12 4.2 Call Acknowledgement 14 4.3 Call Reject 16 4.4 Clear Request 17 4.5 Clear Acknowledgement 19 4.6 Status Request 20 4.7 Status Report 22 4.8 Data 24 5. ATTRIBUTES 25 5.1 Attribute Header 25 5.2 Attribute Classes 26 5.3 Attribute List 27 5.4 Message Type / Attribute Matrix 28 5.5 Attribute Definitions 30 6. PROTOCOL OPERATION 41 6.1 Protocol Startup 41 6.2 Call Request (incoming) 43 6.3 Call Request (outgoing) 43 6.4 Call Clearing (incoming) 44 6.5 Call Clearing (outgoing) 44 6.6 Status Request 44 6.7 Status Reporting 45 6.8 Data Transfer 45 6.9 Exception Handling 47 7. TRANSPORT 48 7.1 QTP over UDP 48 7.2 QTP over TCP 49 8. SECURITY CONSIDERATIONS 49 9. REFERENCES 50 10. AUTHORS' ADDRESSES 51 11. FULL COPYRIGHT STATEMENT 52 12. INTELLECTUAL PROPERTY 52 Cornish et. al. expires May 2005 [Page 2] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 1. INTRODUCTION This document describes the QTP interface that can be used to carry short duration transactions. QTP was created to address the specific need for a multi-session protocol to connect dial-up transaction terminal sessions to an IP host. 1.1. Typical Application At the time of creation of this protocol, most existing Point-Of-Sale (POS) and Credit Authorization Terminal (CAT) devices connect to telephone or X.25 access networks. In many cases, these transactions are routed to an IP-based Transaction Processor (TP). A simplified POS system includes: +--+ +- ---| |--| +--+ +- where: Terminal is the CAT or POS terminal device Access is an Access Network such as telephone or X.25 NAS is a Network Access Server IP is an IP network (usually private and secured) TP is an authorizing Transaction Processing host When a transaction occurs, a telephone or X.25 connection is initiated by a Terminal to a NAS. The NAS answers the call and establishes a data connection. Once connected, the terminal sends the transaction request, and waits for a transaction response. When received, the terminal may disconnect immediately, or send an acknowledgement prior to disconnecting. Request and response messages rarely exceed 200 octets. The entire sequence takes only a few seconds. The NAS acts as an IP network gateway, and routes the transaction request through to a TP. It also ensures the transaction response is returned to the appropriate terminal. The application logic in both the NAS and TP may use access network addressing (called and calling numbers) and the contents of the transaction message to route and process the transaction. Cornish et. al. expires May 2005 [Page 3] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 While most calls are initiated by terminals in response to customer transactions, there are some cases where the TP initiates connections to terminals. This mode is usually associated with the TP soliciting audit information from the terminals or downloading "hot card" lists to terminals. Due to the high availability requirements of production transaction systems, live NAS and TP hosts are essential. 1.2. Protocol Requirements A protocol suitable for this application must address the following requirements. * The number of terminals concentrated into a single host may be in the tens of thousands. * Each transaction, including connection, data transfer and disconnection occurs in a few seconds. The protocol must be efficient and low-latency. * Data transfer must support asynchronous message transfer. Either the terminal or TP may initiate data exchanges. * Application-layer logic includes aggressive measures for error recovery if data is lost or corrupted. It is undesireable for lower-level transport services to provide recovery mechanisms operating on longer timeouts. * An outage during a peak retail time is intolerable. The overall system must include provisions for fault tolerance. * The access network source and destination addresses are correlated with the transaction data. The protocol must transfer called and calling number along with transaction data. * The application logic invokes specific error recovery mechanisms if the access network connection terminates. The protocol must provide connection information. 1.3. Other Approaches Alternate were considered prior to undertaking the creation of a new protocol. These were ruled out on the basis that they did not suitably address Cornish et. al. expires May 2005 [Page 4] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 the problem space defined by this application. 1.3.1. Mapping to TCP Connections It is possible to map access network connections to corresponding TCP connections. Access network addressing may be carried in a header, or mapped to specific TCP ports. If the access network connection is broken, the corresponding TCP connection is disconnected. This approach is common in small-scale transaction processing systems, but experience indicates it is not scalable to large applications. * At peak connection arrival rates, the overhead associated with setting up TCP sessions becomes prohibitive. * During peak usage, the TCP port number resource within a TP becomes exhausted. * In the event of dropped or corrupted IP datagrams, TCP will undertake retransmission, potentially delivering a message well after the application logic has undertaken recovery. * It is prohibitively expensive to secure each transient TCP connection using methods such as SSL or TLS. 1.3.2. Vendor Protocols Several vendor protocols are widely used for these types of applications. In particular, Hypercom and Visa each have proprietary protocols for which they have assigned TCP and UDP port numbers [2]. QTP was created to provide a public and non-restrictive alternative to these approaches. 1.4. QTP Attributes Key features of QTP are: * Efficient connection setup; * Transfers access network call information, including calling/called numbers and modem speed; * Independent of access network type (telephone, ISDN, X.25,...); Cornish et. al. expires May 2005 [Page 5] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 * Operation over connectionless or connection-oriented transports; * Efficient concentration of connections at very high call rates; * Support for outgoing and incoming transaction initiation; * Dynamic adjustment to congestion or server failures; 1.5. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 1.6. Terminology This document uses the following terms: CAT Credit Authorization Terminal. FI Financial Institution. IP Internet Protocol. ISDN Integrated Services Digital Network LCN Logical Channel Number Message A single complete QTP unit, including message header and attributes. POS Point-Of-Sale. PSTN Public Switched Telephone Network QTP Entity The QTP software element on a QTP host. A QTP Entity is responsible for all the QTP sessions between it and other QTP entities. QTP Host The computing environment in which one or more QTP entities resides. QTP Session One logical connection provided by QTP Entities between a single application endpoint on one host and single application endpoint on a remote QTP entity. QTP Quick Transaction Protocol. The protocol as described in Cornish et. al. expires May 2005 [Page 6] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 this document. TCP Transport Control Protocol UDP User Datagram Protocol. 2. QTP FRAMEWORK In this document, the following framework is used to describe the operation of QTP. This framework is not intended to imply a design or implementation architecture. [Transaction Terminals] | | | | +--------------+ ( Access ) ( Networks ) +--------------+ | | | | +-----------------------+ +-----------------------+ | +----------------+ | | +-----------------+ | | | Network Access | | | | Transaction | | | | Application(s) | | | | Processing | | | | Supporting | | | | Application(s) | | | | Multiple | | | | Serving many | | | | Transaction | | | | Transaction | | | | Connections | | | | Connections | | | +----------------+ | | +-----------------+ | | | | | | | | | | | | | | Logical Channels | | Logical Channels | | 1 2 3 n | | 1 2 3 n | | | | | | | | | | | | | | +-------------+ | | +-------------+ | | | |<-------------------->| | | | | QTP Entity |<--------QTP--------->| QTP Entity | | | | |<------Sessions------>| | | | | [Control] |<-------------------->| [Control] | | | +---------------+-+ | | +---------------+-+ | | |Transport Service|==|============|==|Transport Service| | | +-----------------+ | Network | +-----------------+ | | QTP Host A | | QTP Host B | |(Network Access Server)| |(Transaction Processor)| +-----------------------+ +-----------------------+ In this framework, QTP Host A and QTP Host B exist in a network. Cornish et. al. expires May 2005 [Page 7] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 QTP Host A acts as a Network Access Server, concentrating connections from multiple Transaction Terminals arriving from one or more Access Networks. QTP Host B acts as a Transaction Processor, responding to transaction messages from terminals. Each Host supplies a Transport Service for a QTP Entity, which permits QTP messages to be exchanged between hosts. Each QTP Entity contains a Control point responsible for call control and management functions for the QTP Entity. Higher level applications establish or accept QTP Sessions with remote applications. Each QTP Session is an independent logical connection between one specific channel on one QTP Entity and a specific channel on another QTP Entity. Higher level applications access individual QTP Sessions using a Logical Channel Number on the local QTP Entity. QTP Sessions are defined by the Logical Channel Numbers on both QTP Entities involved in the connection. QTP is independent of the underlying Transport Service. The Transport Service may be connectionless or connection-oriented, and provide reliable or unreliable message delivery. Cornish et. al. expires May 2005 [Page 8] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 3. QTP MESSAGE FORMAT 3.1. Message Header Each QTP message includes a message header as described below. All numbers are unsigned and are in network byte order (i.e. big endian). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Rsvd |M|A|P|0| Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LCN | Destination LCN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier (opt) | Message Identifier Ack (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data/Control Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Version (bits 0 through 3) Protocol Version. Set to 0x1. Rsvd (bits 4 through 7) Reserved for future use. Must be zero. Message Identifier Flag (bit 8) Indicates that the Message Identifier field exists. Message Identifier Ack Flag (bit 9) Indicates that the Message Identifier Ack field exists. Message Priority Flag (bit 10) If zero (0), indicates the QTP message is of normal priority. If set to one (1), the QTP message is of high priority. Type (bits 12 through 15) The type of QTP message as in Section 3.2 of this document. Cornish et. al. expires May 2005 [Page 9] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Message Length (two octets) The length in bytes of the entire QTP message including header. Source LCN (two octets) A Logical Channel Number used to identify the specific QTP Session originating a QTP message. QTP Messages returned by the receiving QTP Entity to this LCN will be associated with the same higher-layer application endpoint. This number need not have any direct relationship with respect to physical ports. Both the Source LCN and Destination LCN are required in a QTP Message to uniquely identify a specific QTP Session. When a QTP Session is disconnected, the LCN becomes invalid until a new QTP Session is established which involves that LCN. An LCN value of zero (0) MUST NOT be used as a transaction source, but MAY be interpreted as the Control point within the QTP Entity. Destination LCN (two octets) A Logical Channel Number used to identify the specific QTP Session on the destination QTP Entity. This number need not have any direct relationship with respect to physical ports. Both the Source LCN and Destination LCN are required in a QTP Message to uniquely identify a specific QTP Session. When a QTP Session is disconnected, the LCN becomes invalid until a new QTP Session is established which involves that LCN. Except where otherwise noted in this document, an LCN value of zero (0) MUST NOT be used as a transaction destination, but MAY be interpreted as the Control point on the destination QTP Entity. Message Identifier (two octets) Present if the "Message Identifier Flag" is set in the QTP header. This is a number which uniquely identifies the QTP message for the indicated QTP Session. If this is present, a message on the same QTP Session MUST be Cornish et. al. expires May 2005 [Page 10] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 returned which includes this value in the "Message Identifier Ack" field. Use of a Message Identifier in any message is optional. If two messages are received on the same QTP Session with the same Message Identifier value, then the second message MUST be discarded, and a Message Identifier Ack MUST be returned. Message Identifier Ack (two octets) Present if the "Message Identifier Ack Flag" is set in the QTP header. This field explicitly acknowledges reception of a QTP Message to the remote end of the QTP Session. The Message Identifier Ack field contains the same value as the Message Identifier field in the message being acknowledged. Data/Control The remainder of the QTP Message contains data and/or control information formatted as Attributes, as described in this document. 3.2. Message Types The following QTP message types have been defined. Message Type Type Code ------------ --------- Call Request 0x1 Call Ack 0x2 Call Reject 0x3 Clear Request 0x5 Clear Ack 0x6 Status Request 0x9 Status Report 0xA Data 0xD Cornish et. al. expires May 2005 [Page 11] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 4. DETAILED MESSAGE TYPES 4.1. Call Request The QTP header for a Call Request message is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Rsvd |M|0|P|0| Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LCN | Destination LCN (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier (opt) | Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Version 0x1 Message Identifier Flag Indicates whether the Message Identifier field exists. Message Identifier Ack Flag 0 Priority The message priority, normally zero (0). Type 0x1 for Call Request Message Length The length in bytes of the entire QTP message including header. Source LCN A non-zero unique number identifying the logical connection associated with the QTP Session on the host initiating the Call Request message. Destination LCN Call Request messages MUST include a destination LCN value of zero (0). This directs the Call Request message to the Control point on the destination QTP Entity. The Control point in the destination QTP Entity is responsible for assigning an LCN at the destination if and only if the Call Request is accepted and a Call Acknowledgement is returned. Cornish et. al. expires May 2005 [Page 12] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Message Identifier Use of a Message Identifier is OPTIONAL. If a Message Identifier is included, the corresponding Call Acknowledgement or Call Reject message returned by the destination QTP Entity MUST include a matching Message Identifier Ack value. If a Message Identifier is not included, the corresponding Call Acknowledgement or Call Reject message MUST NOT include a Message Identifier Ack field. Attributes Multiple attributes are REQUIRED within a Call Request message, including sufficient information for transaction connection establishment. Valid Call Request attribute(s) are as described elsewhere in this document. Cornish et. al. expires May 2005 [Page 13] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 4.2. Call Acknowledgment The QTP header for a Call Acknowledgment message is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Rsvd |M|A|P|0| Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LCN | Destination LCN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier (opt) | Message Identifier Ack (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+- Version 0x1 Message Identifier Flag Indicates whether the Message Identifier field exists. Message Identifier Ack Flag Indicates whether the Message Identifier Ack field exists. Priority The message priority, normally zero (0). Type 0x2 for Call Ack. Message Length The length in bytes of the entire QTP message including header. Source LCN A returned Call Ack message MUST include a non-zero Source LCN value, which is to be used to identify the QTP Session for the remainder of the life of the QTP Session. This value is assigned upon acceptance of the QTP Session. Destination LCN Set to the Source LCN supplied in the originating Call Request message. Message Identifier Use of a Message Identifier is OPTIONAL. If a Message Identifier is included, the receiving QTP Entity MUST respond with a Cornish et. al. expires May 2005 [Page 14] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 matching Message Identifier Ack field in a returned QTP message within the same QTP Session. Message Identifier Ack A Message Identifier Ack field MUST be present if the originating Call Request message included a Message Identifier field. Attributes Valid Call Ack attribute(s) are as described elsewhere in this document. Cornish et. al. expires May 2005 [Page 15] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 4.3. Call Reject The QTP header for a Call Reject message is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Rsvd |0|A|P|0| Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LCN (0) | Destination LCN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier Ack (opt) | Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Version 0x1 Message Identifier Flag 0. The Call Reject message MUST NOT contain a Message Identifier, as the QTP Session becomes invalid after the Call Reject is issued. Message Identifier Ack Flag Indicates whether the Message Identifier Ack field exists. Priority The message priority, normally zero (0). Type 0x3 for Call Reject Message Length The length in bytes of the entire QTP message including header. Source LCN A returned Call Reject MUST include a zero (0) Source LCN value. Destination LCN Set to the Source LCN supplied in the originating Call Request message. Message Identifier Ack A Message Identifier Ack field MUST be included if the corresponding Call Request message included a Message Identifier field. Cornish et. al. expires May 2005 [Page 16] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Attribute(s) Valid Call Reject attribute(s) are as described elsewhere in this document. 4.4. Clear Request The QTP header for a Clear Request message is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Rsvd |M|A|P|0| Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LCN | Destination LCN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier (opt) | Message Identifier Ack (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+- Version 0x1 Message Identifier Flag Indicates whether the Message Identifier field exists. Message Identifier Ack Flag Indicates whether the Message Identifier Ack field exists. Priority The message priority, normally zero (0). Type 0x5 for Clear Request Message Length The length in bytes of the entire QTP message including header. Source LCN The number indicating the QTP Session on the QTP Entity originating the Clear Request message. Destination LCN The number indicating the LCN on the remote QTP Entity, supplied by the remote QTP Entity as the Source LCN in either the Call Request or Call Acknowledge message. Cornish et. al. expires May 2005 [Page 17] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Message Identifier Use of a Message Identifier is OPTIONAL. If a Message Identifier is included, the corresponding Clear Ack message MUST include a matching Message Identifier Ack value. If a Message Identifier is not included, the corresponding Clear Ack message MUST NOT include a Message Identifier Ack field. Message Identifier Ack A Message Identifier Ack field MUST be included if the preceding message received from the remote QTP Entity involving the same QTP Session included a Message Identifier field. Attribute(s) Valid Call Reject attribute(s) are as described elsewhere in this document. Cornish et. al. expires May 2005 [Page 18] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 4.5. Clear Acknowledgement The QTP header for a Clear Acknowledgement message is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Rsvd |0|A|P|0| Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LCN | Destination LCN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier Ack (opt) | Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Version 0x1 Message Identifier Flag 0. The Clear Ack message MUST NOT contain a Message Identifier, as the QTP Session becomes invalid after the Clear Ack is issued. Message Identifier Ack Flag Indicates whether the Message Identifier Ack field exists. Priority The message priority, normally zero (0). Type 0x6 for Clear Ack Message Length The length in bytes of the entire QTP message including header. Source LCN The number indicating the QTP Session on the QTP Entity originating the Clear Ack message. Destination LCN The number indicating the LCN on the remote QTP Entity, supplied by the remote QTP Entity as the Source LCN in either the Call Request or Call Acknowledge message. Message Identifier Ack A Message Identifier Ack field MUST be included if the corresponding Clear Request message included a Message Identifier field. Cornish et. al. expires May 2005 [Page 19] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Attribute(s) Valid Clear Ack attribute(s) are as described elsewhere in this document. 4.6. Status Request Status Request messages are used to solicit Status Reports, as well as to deliver Status and Statistics attributes. The QTP header for a Status Request message is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Rsvd |M|0|P|0| Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LCN | Destination LCN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier (opt) | Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Version 0x1 Message Identifier Flag Indicates whether the Message Identifier field exists. Message Identifier Ack Flag 0 Priority The message priority, normally zero (0). Type 0x9 for Status Request. Message Length The length in bytes of the entire QTP message including header. Source LCN A non-zero number indicating the QTP Session number or zero (0) for the Control point on the originating QTP Entity. A source LCN value of zero (0) indicates that status is being requested by the Control point in the QTP Entity. A non-zero source LCN value indicates that status is being requested by a specific QTP Session. Cornish et. al. expires May 2005 [Page 20] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Destination LCN Either zero (0) for the Control point on the destination QTP Entity, or a non-zero number indicating the LCN for an individual QTP Session on the remote QTP Entity. A destination LCN value of zero (0) indicates that global status is being requested from the Control point on the destination QTP Entity. A destination LCN value which is non-zero indicates that status is being requested for a specific QTP Session. Message Identifier Use of a Message Identifier field is OPTIONAL. If a Message Identifier is included, the corresponding Status Report message MUST include a matching Message Identifier Ack value. If a Message Identifier is not included, a corresponding Status Report message MUST be returned, but MUST NOT include a Message Identifier Ack field. Attribute n Except as specified elsewhere in this document, Status and Statistics attributes delivered in a Status Request have the same meaning as if delivered in a Status Report. Valid Status Request attribute(s) are as described elsewhere in this document. Cornish et. al. expires May 2005 [Page 21] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 4.7. Status Report Status Reports MAY be solicited via a Status Request, or MAY be unsolicited. A Status Report MAY be used by a QTP Entity to advertise its level of availability. The QTP header for a Status Report message is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Rsvd |0|A|P|0| Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LCN | Destination LCN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier Ack (opt) | Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version 0x1 Message Identifier Flag 0. The Status Report message MUST NOT contain a Message Identifier. Message Identifier Ack Flag Indicates whether the Message Identifier Ack field exists. Priority The message priority, normally zero (0). Type 0xA for Status Report. Message Length The length in bytes of the entire QTP message including header. Source LCN A non-zero number indicating the QTP Session number or zero (0) for the Control point on the originating QTP Entity. A source LCN value of zero (0) indicates that status is being supplied by the Control point in the QTP Entity which supplies status for the entire QTP Entity. A non-zero source LCN value indicates that status is being supplied for a specific QTP Session. Cornish et. al. expires May 2005 [Page 22] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Destination LCN A non-zero number indicating the QTP Session number or zero (0) for the Control point on the destination QTP Entity. A destination LCN value of zero (0) indicates that status is being supplied to the Control point on the destination QTP Entity. A destination LCN value which is non-zero indicates that status is being supplied to a specific QTP Session. Message Identifier Ack A Message Identifier Ack field MUST be included if the corresponding Status Request message included a Message Identifier field. Attribute(s) Valid Status Report attribute(s) are as described elsewhere in this document. Cornish et. al. expires May 2005 [Page 23] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 4.8. Data The QTP header for a Data message is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Rsvd |M|A|P|0| Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source LCN | Destination LCN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier (opt) | Message Identifier Ack (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute(s)... +-+-+-+-+-+-+-+-+-+-+-+-+- Version 0x1 Message Identifier Use of a Message Identifier field is OPTIONAL. If a Message Identifier is included, a corresponding Data or Clear Request message MUST include a matching Message Identifier Ack value. Message Identifier Ack This is only included if a preceding Call Ack or Data message involving the same QTP Session was received which included a Message Identifier. Priority The message priority, normally zero (0). Type 0xD for Data. Source LCN The number indicating the QTP Session on the QTP Entity originating the Data message. Destination LCN The number indicating the QTP Session on the QTP Entity to which the Data message is being sent. Attribute(s) Valid Data attribute(s) are as described elsewhere in this document. Cornish et. al. expires May 2005 [Page 24] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 5. ATTRIBUTES Attributes are used within QTP to pass additional information not contained in the QTP message header. Attributes MUST NOT be nested. That is, attributes MUST NOT be put within attributes. Attributes are divided into two categories. "Core Attributes" perform session establishment and clearing, data transfer, and status reporting operations. Core Attributes are sufficient for transaction communication. Within the set of Core Attributes, some are classed as REQUIRED and some classed as OPTIONAL. "Vendor Attributes" are provided as a means to extend QTP to address implementation specific capabilities included in commercial products. Support for Vendor Attributes is OPTIONAL. 5.1. Attribute Header 5.1.1. Core Attributes Each Core Attribute consists of a 16 bit attribute number in the range 0x0000 to 0x9FFF, a 16 bit length field (that includes the attribute number and length fields), and the attribute value as shown below. Numeric attribute values are in network byte order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Core Attribute n | Attribute n Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute n Value . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.2. Vendor Attributes Each Vendor Attribute consists of a 16 bit attribute number in the range 0xA000 to EFFF, a 16 bit length field (including the entire attribute header), a 16 bit Vendor Identifier field, and the attribute value(s) as specified by the vendor. The Vendor Identifier value is assigned and managed by IANA as the "SMI Network Management Private Enterprise Codes" available from the IANA Protocol Numbers list [4]. Cornish et. al. expires May 2005 [Page 25] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Numeric attribute values are in network byte order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute n | Attribute n Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | Attribute n Value . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 5.2. Attribute Classes Core Attribute values have been grouped into five (5) classes related to the phase of the transaction and other "out-of-band" control activities. A range of attribute values are available for vendor specific extensions. The classes include: * Reserved (class 0x00) * Session Establishment (class 0x01) * Data Transfer (class 0x02) * Session Management (class 0x03) * Element Status (class 0x04) * Statistical Information (class 0x05) * Unassigned (class 0x06-0x9F) * Vendor Specific (class 0xA0-0xEF) * Reserved (class 0xF0-0xFF) Cornish et. al. expires May 2005 [Page 26] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 5.3. Attribute List For each attribute value, the first 8 bits indicate the Attribute Class, and the remaining 8 bits indicate the member of the class. Attribute Name Attribute Class Member Value ------------------------------ ------- ------- ------- *Session Establishment Called Party Address 0x0100 0x01 0x00 Calling Party Address 0x0101 0x01 0x01 Profile 0x0102 0x01 0x02 Speed 0x0103 0x01 0x03 Idle Time-out 0x0104 0x01 0x04 Max Message 0x0106 0x01 0x06 Called Party Subaddr 0x0108 0x01 0x08 Calling Party Subaddr 0x0109 0x01 0x09 Protocol Identifier 0x010B 0x01 0x0B Cust Group Identifier 0x010C 0x01 0x0C *Data Transfer Data 0x0200 0x02 0x00 Management Info 0x0201 0x02 0x01 Qualified Data 0x0202 0x02 0x02 Data Block 0x0203 0x02 0x03 Call Data 0x0204 0x02 0x04 *Session Management Cause 0x0300 0x03 0x00 Remote Cause 0x0301 0x03 0x01 *Element Status Flow Control 0x0400 0x04 0x00 Station Status 0x0401 0x04 0x01 Ping 0x0402 0x04 0x02 Call State 0x0403 0x04 0x03 *Statistical Information Num Messages Received 0x0500 0x05 0x00 Num Messages Transmitted 0x0501 0x05 0x01 Num Unacked Messages 0x0502 0x05 0x02 Time Since Last Restart 0x0503 0x05 0x03 Cornish et. al. expires May 2005 [Page 27] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 5.4. Message Type / Attribute Matrix The following matrix indicates the valid attributes which must be, may be, or must not be, used and the number of occurrences of each attribute permitted for each message type. - Indicates Attribute MUST NOT be used in the corresponding Message Type. * Indicates exactly zero (0) or one (1) instance of this Attribute MAY be used in the corresponding Message Type. 1 Indicates exactly one (1) instance of this Attribute MUST be used in the corresponding Message Type. 0+ Indicates zero (0) or more instances of this Attribute MAY be used in the corresponding Message Type. Cornish et. al. expires May 2005 [Page 28] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Message Type Call Call Call Clear Clear Status Status Data Req Ack Reject Req Ack Req Report ------------ ---- ---- ---- ---- ---- ---- ---- ---- 0x01 0x02 0x03 0x05 0x06 0x09 0x0a 0x0D ------------ ---- ---- ---- ---- ---- ---- ---- ---- Attributes: 0x0100 CalledAddr * - - - - - - - 0x0101 CallingAddr * - - - - - - - 0x0102 Profile * * - - - - - - 0x0103 Speed * * - - - - - - 0x0104 IdleTimeout * * - - - - - - 0x0106 MaxMsg * * - - - - - - 0x0108 CalledSub * - - - - - - - 0x0109 CallingSub * - - - - - - - 0x010B Protocol ID * * - - - - - - 0x010C Cust GID * * - - - - - - 0x0200 Data * * - * - - - * 0x0201 Mgmt Info * * - * - - - * 0x0202 Q Data * * - * - - - * 0x0203 Data Block - - - - - - - * 0x0204 Call Data * * - * - - - - 0x0300 Cause - - 1 1 * - - - 0x0301 Rem Cause - - * * * - - - 0x0400 Flow Cntrl - - - - - * * - 0x0401 Stn Status - - - - - * * - 0x0402 Ping - - - - - * * - 0x0403 Call State - - - - - * * - 0x0500 #MsgRxIF - - - - - * * - 0x0501 #MsgTxIF - - - - - * * - 0x0502 #Unack - - - - - * * - 0x0503 Time - - - - - * * - Cornish et. al. expires May 2005 [Page 29] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 5.5. Attribute Definitions This section defines the format of each attributes. The hexadecimal value of each attribute is shown in brackets after the attribute name. 5.5.1. Called Party Address (0x0100) This attribute specifies the access network address (i.e. telephone number) supplied by the call originator. For transaction terminal initiated calls, this is the number dialed to connect to the transaction processing host. For calls originated by the transaction processor, this is the number dialed to reach a specific transaction terminal. The attribute value is an ASCII string of up to 40 characters. The default address family is E.164 [5]. Support for this attribute is REQUIRED. The field may be used for other address families (such as X.25 or Frame Relay network addressing) with pre-arrangement by sender and receiver. Per-call configuration of the address family is for further study. 5.5.2. Calling Party Address (0x0101) This attribute specifies the Calling Line Identity, indicating the access network address of the call originator. For transaction terminal initiated calls, this is the telephone number associated with the terminal. For calls originated by the transaction processor, this is the telephone number associated with the service under the control of the transaction processor. The attribute value is an ASCII string of up to 40 characters. The default address family is E.164. Support for this attribute is REQUIRED. The field may be used for other address families (such as X.25 or Frame Relay network addressing) with pre-arrangement by sender and receiver. Per-call configuration of the address family is for Cornish et. al. expires May 2005 [Page 30] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 further study. 5.5.3. Profile (0x0102) This attribute enables access providers to classify user connections, such as indicating the local modem configuration profile to be used in the connection. Its value is an ASCII string of up to 40 characters. Support for this attribute is OPTIONAL. The definition of standard strings associated with common device profiles is for further study. 5.5.4. Speed (0x0103) This attribute specifies the speed of the connection at the access point. This value may be used by transaction processing systems to adjust timeouts or pace data messages. Its value is a ASCII string of up to 10 characters indicating the speed in bits per second. The default value for this attribute is "2400". Support for this attribute is OPTIONAL. 5.5.5. Idle Time-out Delay (0x0104) This attribute specifies the time for which the QTP Session will be maintained in the absence of any data traffic. If it is exceeded, the connection MAY be cleared by either end of the QTP Session. The value is a 16 bit number indicating the idle timer delay in seconds. A zero value disables the timer. If not specified, idle QTP Sessions MAY be disconnected by either end of a QTP Session according to local policies. Support for this attribute is OPTIONAL. 5.5.6. Maximum Message Size (0x0106) This attribute specifies the maximum QTP message size supported by the sender of the attribute. The value is a 16 bit number indicating the message size in octets. Cornish et. al. expires May 2005 [Page 31] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 The message size includes the QTP message header size and the sum of the sizes of all the message attributes. Support for this attribute is OPTIONAL. 5.5.7. Called Party Subaddress (0x0108) This attribute specifies the access network subaddress for the destination of a connection. For the default address family the attribute specifies an ISDN subaddress. Use of other address families is for further study. The attribute value is an ASCII string of up to 20 characters. Support for this attribute is OPTIONAL. 5.5.8. Calling Party Subaddress (0x0109) This attribute specifies the access network subaddress for the initiator of a connection. For the default address family the attribute specifies an ISDN subaddress. The attribute value is an ASCII string up to 20 characters. Support for this attribute is OPTIONAL. 5.5.9. Protocol Identifier (0x010B) This attribute identifies the protocol of the higher-level application data supplied by the sender. The value is an 8 bit number and is obtained from the IANA administered Protocol Number list [4]. If not specified, the contents of the Data Attributes are unknown to the QTP Entity, and data transparency MUST be maintained. Support for this attribute is OPTIONAL. Cornish et. al. expires May 2005 [Page 32] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 5.5.10. Customer Group Identifier (0x010C) This attribute specifies a Customer Group with which a QTP Session is to be associated. Selection and assignment of Customer Groups are the responsibility of higher-level management applications. The attribute value is an ASCII string of up to 20 characters. If not specified, a QTP Session is not associated with a Customer Group. Support for this attribute is OPTIONAL. 5.5.11. Data (0x0200) This attribute identifies transaction data. The attribute value consists of a string of octets of arbitrary length. Support for this attribute is REQUIRED. 5.5.12. Management Information (0x0201) This attribute provides the ability to transfer unformatted control and response data between QTP Entities out-of-band from the transaction data. The attribute value is a string of octets of arbitrary length. Support for this attribute is OPTIONAL. 5.5.13. Qualified Data (0x0202) This attribute identifies that the data is to be used for session management (e.g. X.29 control messages, QLLC XID's, etc.). The attribute value is a string of octets of arbitrary length. Support for this attribute is OPTIONAL. Cornish et. al. expires May 2005 [Page 33] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 5.5.14. Data Block (0x0203) This attribute identifies a beginning, intermediate or final data block for segmented data transfers where the data object exceeds the maximum size of a single Data Attribute. The attribute value consists of a block header followed by segmented data. The contents of the data block header are as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|F| Reserved | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Start Data Block Flag (bit 0) Set to 1 only on the first data message in a block. Final Data Block Flag (bit 1) Set to 1 only on the final data message in block. Reserved (bits 2 to 15) Set to 0. Sequence Number (bits 16 to 31) A sequence number for each data block. The starting block in the sequence MUST have a sequence number of zero (0), and increment by one (1) for each subsequent Data Block Attribute until the final Data Block is sent. The sequence number is included to enable the receiver to re-assemble the original data in the correct order. Block Data (bits 32 ...) The segmented data message, consisting of a string of octets of arbitrary length. Support for this attribute is OPTIONAL. Cornish et. al. expires May 2005 [Page 34] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 5.5.15. Call Data (0x0204) This attribute contains unformatted Call Data that is supplied by a calling or called entity during session establishment. The attribute value is a string of octets of arbitrary length. Support for this attribute is OPTIONAL. 5.5.16. Cause (0x0300) This attribute specifies a QTP Session release cause. The format of the Cause Attribute Value field is as follows: Cause Value 8 bits Broken down into Class and Member subfields as follows 3 Bits (0-2) : Class 5 Bits (3-7) : Member Diagnostic 8 bits This is an optional supplemental field that may be supplied. The Diagnostic field MUST be present when an Information field is supplied. Use of this field is for further study. Information An ASCII string of up to 40 characters. This optional field permits additional information to be supplied regarding the cause of a call clear or call reject. 5.5.16.1. Cause Classes The following cause classes are used to separate causes. Protocol Error (%000) The cause class "Protocol Error" is used for situations where a message format is invalid, a message field is invalid, or an attribute is invalid. Procedure Error (%001) The cause class "Procedure Error" is used in situations in which there is an inconsistency between messages, or between fields within a message. Cornish et. al. expires May 2005 [Page 35] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Invalid Message (%010) The cause class "Invalid Message" is used when there are syntax errors within individual attributes, or when a required attribute is missing. Network (%011) The cause class "Network" is used if a network destination is not reachable. Resource (%100) The cause class "Resource" is used when a required communications system resource is not available. User (%101) The cause class "User" is used in situations where the higher- layer application disconnects or refuses to accept an incoming connection, or a management entity is disabling call completion. Reserved (%110 and %111) 5.5.16.2. Cause Values The following table contains the list of valid Cause Values per Class. Cornish et. al. expires May 2005 [Page 36] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Class Member Value ----- ------------------------------ ----- %000 Protocol Error %00001 Unsupported Version 0x01 %00010 Invalid Use Of Flag 0x02 %00011 Invalid Message Type 0x03 %00100 Invalid Message Length 0x04 %00101 Invalid Source LCN 0x05 %00110 Invalid Dest LCN 0x06 %00111 Invalid Attribute 0x07 %01000 Invalid Attribute Length 0x08 %001 Procedure Error %00001 Invalid LCN Pair 0x21 %00010 Invalid Attribute Usage 0x22 %00011 Time-out 0x23 %00100 Unsupported Attribute 0x24 %010 Invalid Message %00001 Bad Calling Party Number 0x41 %00010 Bad Called Party Number 0x42 %00011 Bad Profile 0x43 %00100 Bad Speed 0x44 %00101 Missing Attribute 0x45 %011 Network %00001 Number Busy 0x61 %00010 No Network User Responding 0x62 %00011 Destination Unreachable 0x63 %00100 Synchronization Error 0x64 %00101 Network Congestion 0x65 %100 Resource %00001 No Channel Available 0x81 %00010 SW Resources Unavailable 0x82 %00011 Network Resource Unavailable 0x83 %101 User %00001 Normal Clearing 0xA1 %00010 Maximum Packet Size Exceeded 0xA2 %00011 Flooding 0xA3 %00100 Out Of Order 0xA4 %00101 Invalid Response 0xA5 %00110 User Not Responding 0xA6 Support for the Cause attribute is REQUIRED. Cornish et. al. expires May 2005 [Page 37] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 5.5.17. Remote Cause (0x0301) This attribute contains a release cause supplied by the remote device or network. The Remote Cause Attribute is independent of the Cause Attribute generated by the QTP Entity. This attribute would be used to supply the Q.931 release cause supplied by an ISDN access network. The value is a string of octets of arbitrary length. Support for this attribute is OPTIONAL. 5.5.18. Flow Control (0x0400) This attribute is a global state value which indicates the ability of a QTP Entity to service further transactions with a remote QTP Entity. The attribute value is an 8 bit number indicating: Value Transaction Call State ----- ---------------------- 0x01 Available(REQUIRED) 0x02 Partially Congested(OPTIONAL) 0x03 Congested(OPTIONAL) 0x04 Shutdown(REQUIRED) A Flow Control state of "Available" indicates a QTP Entity is operational, and able to accept new QTP Sessions. A Flow Control state of "Partially Congested" indicates a QTP Entity is nearing capacity, but remains able to accept new QTP Sessions. A Flow Control state of "Congested" indicates a QTP Entity is at capacity, and is unable to create new QTP Sessions. QTP messages associated with already-connected QTP sessions will continue without interruption. A Flow Control state of "Shutdown" indicates a QTP Entity has restarted or shutdown. In this state, a QTP Entity MUST NOT accept new QTP Sessions, and QTP Sessions in progress prior to entering "Shutdown" state must be immediately terminated. Support for the attribute and "Available" and "Shutdown" states is REQUIRED. Support for the "Partially Congested" and "Congested" states is OPTIONAL. Cornish et. al. expires May 2005 [Page 38] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 5.5.19. Station Status (0x0401) This attribute indicates the Primary or Secondary role of the sending QTP Entity with respect to the receiving QTP Entity. A QTP Entity can advertise itself to another QTP Entity as either a primary route choice, or a secondary ("hot standby") alternative. In this way, standby hosts are available to process transactions during situations of overload or host failures. When there are multiple QTP Entities with which QTP Sessions may be connected, where one or more QTP Entities are Primary and one or more QTP Entities are Secondary, the Primary QTP Entities SHOULD be used as the first choice in route selection. If all Primary QTP Entities become unavailable, the Secondary QTP Entities MAY be used. The attribute value is an 8 bit number with one (1) indicating Primary and two (2) indicating Secondary. Support for the Station Status Attribute and Primary value is REQUIRED. Support for the Secondary value is OPTIONAL. 5.5.20. Ping (0x0402) This attribute is used to identify if a remote QTP Entity exists and to determine network timing. When present in a Status Request message, it represents an echo request. It MUST be responded to in a QTP Status Report regardless of the ability of the receiving QTP Entity to accept QTP Sessions. When present in a Status Report message, it represents an echo response. It MUST contain the value supplied in the preceding Status Request. This attribute MUST NOT be contained in an unsolicited Status Report. The attribute value is a string of octets of arbitrary length. Support for this attribute is OPTIONAL. 5.5.21. Call State (0x0403) This attribute is used to identify the local state of a QTP Session. Cornish et. al. expires May 2005 [Page 39] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 The attribute value is an 8 bit number indicating: Value Transaction Call State ----- ---------------------- 0x00 Disconnected 0x01 QTP Call received 0x02 QTP Call sent 0x03 QTP Clear received 0x04 QTP Clear sent 0x05 QTP Connected Support for this attribute is OPTIONAL. 5.5.22. Number Of Messages Received on an Interface (0x0500) This attribute is used to indicate the number of QTP messages the QTP Entity has received. The value of this attribute is a 32 bit number. Support for this attribute is OPTIONAL. 5.5.23. Number Of Messages Transmitted on an Interface (0x0501) This attribute is used to indicate the number of QTP messages the QTP Entity has sent. The value of this attribute is a 32 bit number. Support for this attribute is OPTIONAL. 5.5.24. Number Of Unacknowledged Messages (on the system) (0x0502) This attribute is a global counter on a QTP Entity used to indicate the number of unacknowledged QTP messages identified by the system. The value of this attribute is a 32 bit number. Support for this attribute is OPTIONAL. 5.5.25. Time Since Last Restart (0x0503) This attribute specifies the period of time over which the statistics have been collected. The value of the attribute is a 32 bit number indicating the time since last restart in seconds. Support for this attribute is OPTIONAL. Cornish et. al. expires May 2005 [Page 40] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 6. PROTOCOL OPERATION QTP is a symmetrical protocol. QTP Sessions may be initiated by either QTP Entity, hence transaction connections can be originated by either transaction terminals or transaction processing applications. QTP may be used over either unreliable transports or over reliable transports. Unreliable transports may be acceptable for transaction data, but are not sufficient for passing call establishment and other control information. For this reason, session establishment and status messages are defined in command / response pairs. The following sequences show protocol operation in some of the more common environments. This does not preclude the use of the protocol in other environments. 6.1. Protocol Startup There are two basic startup methods a QTP Entity can employ. The selection will depend primarily on the nature of the underlying transport service. 6.1.1. Quick Startup In Quick Startup mode, a QTP Entity starts in the "Available" Flow Control state. As soon as a transport layer is available, a QTP Entity may initiate or accept QTP Sessions. In some cases it may be advisable to solicit the status of the remote QTP Entity prior to initiating QTP Sessions, however it is not a requirement for startup. Quick Startup Scenario [QTP Entity A] [QTP Entity B] This method of startup is acceptable when the transport service Cornish et. al. expires May 2005 [Page 41] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 provides reliable message delivery. 6.1.2. Safe Startup In Safe Startup mode, a QTP Entity starts in a "Shutdown" Flow Control state. As soon as a transport layer is available, it periodically issues Status Requests with a Message Identifier, and containing the Flow Control Attribute with a value of "Shutdown". Upon receipt of the acknowledging Status Report, it periodically issues Status Requests with a Message Identifier, and containing the Flow Control Attribute with a value of "Available". Upon receipt of the acknowledging Status Report, it is completed startup and may proceed to establish or accept QTP Sessions. Safe Startup using Status Reports [QTP Entity A] [QTP Entity B] Status Request M=1, MI=x FlowCtrl=Shutdown ----------------> Status Report A=1, MIA=x <---------------- Status Request M=1, MI=y FlowCtrl=Available ----------------> Status Report A=1, MIA=y <---------------- Cornish et. al. expires May 2005 [Page 42] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 This method of startup is recommended when the transport service provides unreliable message delivery. 6.2. Call Request (incoming) On receiving an incoming CALL SETUP from a dial-up line or other access network, the QTP Entity on the Network Access Server host initiates a QTP Call Request to the QTP Entity on the appropriate Server. The QTP Entity on the Server has the option of accepting the call with a Call Ack or rejecting it with a Call Reject. Call Acceptance [Terminal] [Access Device] [Server] CALL SETUP Call Request ------------------> ----------------> Call Ack <---------------- Call Rejection [Terminal] [Access Device] [Server] CALL SETUP Call Request ------------------> ----------------> Call Reject <---------------- 6.3. Call Request (outgoing) QTP is a bi-directional protocol. As such, the Transaction Processing host may also set up an outgoing call to a terminal through a dial-up line or other access network. As in the incoming case, this Call Request may be accepted or rejected. The Call Rejection will contain the reason why the call was not accepted. Call Acceptance [Terminal] [Access Device] [Server] CALL SETUP Call Request <------------------ <---------------- Call Ack ----------------> Cornish et. al. expires May 2005 [Page 43] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Call Rejection [Terminal] [Access Device] [Server] CALL SETUP Call Request <------------------ <---------------- (busy, reorder, Call Reject no answer ...) ----------------> 6.4. Call Clearing (incoming) When the access network connection with the terminal is disconnected, or if the Network Access Server chooses to terminate the connection, a Clear Request will be generated from the Access Device indicating the call is cleared and the reason for the clear. The Clear Request message may contain transaction data. [Terminal] [Access Device] [Server] Clear Request CALL CLEAR Cause=Normal Clr ------------------> ----------------> Clear Ack <---------------- 6.5. Call Clearing (outgoing) A connection can be cleared at any time although normally this is only done if a transaction is complete. In the case of a Server clearing the call the reason for clearing the call will be contained in the Clear Request message. The Clear Request message may contain transaction data. [Terminal] [Access Device] [Server] Clear Request CALL CLEAR Cause=Normal Clr <-------------------- <---------------- Clear Ack ----------------> 6.6. Status Request Status messages may be requested by either QTP Entity involved in a QTP connection. Cornish et. al. expires May 2005 [Page 44] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 [Terminal] [Access Device] [Server] Status Request <---------------- Status Report ----------------> 6.7. Status Reporting Status Reports may be initiated by either QTP Entity in response to Status Requests, or without being solicited by a Status Request. These may be used as a "keep-alive" indication. [Terminal] [Access Device] [Server] Status Report <---------------- 6.7.1. Status Reporting on Flow Control State Change When the Flow Control state changes in a QTP Entity, is SHOULD immediately notify the remote QTP Entity via a Status Report including the Flow Control Attribute. Alternatively, it MAY send a Status Request which includes a Message Identifier and the Flow Control attribute. This approach is recommended when the transport layer does not provide reliable message delivery. 6.8. Data Transfer Data messages may be issued with or without a Message Identifier. If absent, data messages are not acknowledged in any way. If present, the receiver is required to respond with an acknowledgement in the form of a Message Identifier Ack. The acknowledgements may be used for two purposes. When the underlying transport service is not reliable, it provides feedback to the sender that a data message was successfully delivered. Secondly, the receiver can withhold acknowledgements for the purpose of throttling a sender. Using data message acknowledgements is useful if the data ingress rate can exceed the egress rate at the data receiver, and the sender has the ability to source throttle the data originator. The following sequence indicates the operation of data messages which Cornish et. al. expires May 2005 [Page 45] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 do not require acknowledgement. Incoming Data [Terminal] [Access Device] [Server] DATA Data (M=0) ------------------> ----------------> Outgoing Data [Terminal] [Access Device] [Server] DATA Data (M=0) <-------------------- <---------------- The following sequences indicates the operation of data messages which include the Message Identifier, and therefore require acknowledgement. For the Incoming Data example, Data messages from the QTP Entity on the Access Device includes the Message Identifier, and the Server responds with Message Identifier Acknowledgements. In the Outgoing Data example, Data messages from the QTP Entity in the Server requests acknowledgements, and the Access Device responds with Message Identifier Acknowledgements. Incoming Data [Terminal] [Access Device] [Server] DATA A, DATA B Data A (M=1,MI=w) ------------------> ----------------> DATA a Data a (A=1,MIA=w) <------------------ <---------------- Data B (M=1,MI=x) ----------------> DATA b Data b (A=1,MIA=x) <------------------ <---------------- Cornish et. al. expires May 2005 [Page 46] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Outgoing Data [Terminal] [Access Device] [Server] DATA A Data A (M=1, MI=y) <-------------------- <---------------- DATA a Data a (A=1,MIA=y) --------------------> ----------------> DATA B Data B (M=1, MI=z) <-------------------- <---------------- DATA b Data b (A=1,MIA=z) --------------------> ----------------> 6.9. Exception Handling 6.9.1. No Response to Call Request If an initiator does not receive a response to a Call Request message within a timeout period, it MUST re-send the Call Request. The recommended value for the timeout is two (2) seconds. If the second attempt is unsuccessful, the higher-layer application should be notified of a connection request failure. 6.9.2. No Response to Clear Request The originator of a Clear Request Message MAY enter a "Clear Ack Pending" state awaiting a Clear Ack message. In the event that the Clear or Clear Ack is lost, the QTP Entity originating the Clear Request message MUST resend the Clear Request message and release all transaction resources associated with that QTP Session. 6.9.3. No Response to Data Message requiring Acknowledgement If an initiator does not receive an acknowledgement to a Data message requiring acknowledgement within a timeout period, the initiator MUST resend the original message. If the second message is also not acknowledged, the sender must clear the call and release all QTP Session resources. 6.9.4. No Response to Status Request If an initiator does not receive a response to a Status Request message within a timeout period, it MAY re-send the Status Request. This may be repeated indefinitely. Cornish et. al. expires May 2005 [Page 47] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 If a QTP Entity fails to receive one or more Status Reports in response to a Status Requests, it MAY declare the transport connection to be inoperative. In this event, a QTP Entity MUST terminate all QTP Sessions and attempt to restart. 6.9.5. Remote QTP Entity Shutdown or Restart If a QTP Entity receives a QTP Status Report in which the Flow Control Attribute is "Shutdown" all QTP Sessions involving the Shutdown QTP Entity MUST be terminated. 7. TRANSPORT QTP may operate over a connectionless or connection-oriented transport layer. 7.1. QTP over UDP The following section addresses the operation of QTP over UDP [6] transport. UDP is preferable to TCP for short duration transactions as it does not include provisions for reliable message delivery. This is well explained in Section 2.3 the RADIUS specification [7] 7.1.1. Initialization Since UDP is connectionless and unreliable, the Safe Startup mode MUST be used. 7.1.2. QTP Message Transfer and Message Size Restriction One or more QTP messages MAY be encapsulated into a single UDP datagram. However, a QTP message MUST NOT be split over a UDP datagram boundary. The upper size limit of a QTP message carried over UDP is therefore restricted by the maximum UDP message size. Since this limit varies in different UDP drivers, implementions SHOULD allow the upper size limit to be restricted as a configuration option. A conservative value for the maximum QTP message size which should be Cornish et. al. expires May 2005 [Page 48] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 supported by any driver and network is 512 bytes. If the end-to-end transaction application layer deals with unreliable message delivery, data messages MAY be sent without requiring QTP acknowledgements. If the application layer expects reliable message delivery, the QTP Message Identifier flag MUST be set for all Data messages, which requires a corresponding Message Identifier Acknowledgement for each Data message. 7.1.3. Well Known UDP Port Number for QTP Source Port 2935 [2] Or other port number selected by the sender. Destination Port 2935 [2] Or other UDP port number pre-configured and agreed upon between the sender and receiver. 7.2. QTP over TCP The use of QTP over TCP [8] transport is for further study. 8. SECURITY CONSIDERATIONS The QTP protocol is intended to connect transaction processing systems supplied by different vendors through an open interface. In many cases, at least one of the QTP Entities will be a transaction processing host, which requires physical and logical isolation from untrusted network entities. The QTP protocol is intended for use in the associated secured financial transaction networks. Use of QTP in public or unsecured network environments without careful security precautions is not recommended or expected due to the following risks: * Inbound communication requests are serviced without authenticating the message source. This potentially permits any device with network access to emulate a transaction network access server or a transaction processing host. * Potentially sensitive transaction call information is sent in clear text which could be easily monitored and recorded. This would include telephone numbers for transaction terminals and transaction processing hosts. Cornish et. al. expires May 2005 [Page 49] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 * Transaction messages are sent in the form supplied by terminals, which are not always in encrypted form. This may expose user's credit card numbers, bank account numbers and other sensitive financial information; Use of QTP is not precluded from use in other applications which may require transport through public or other untrusted networks. Securing QTP requires that the underlying transport make available encryption, integrity and authentication services for all QTP traffic. This secure transport operates on the entire QTP packet and is functionally independent of QTP and the transaction data being carried by QTP. Protecting the QTP packet stream via a secure transport does, in turn, also protect the transaction data within the QTP packets. The selection of a secure transport service is for further study. 9. REFERENCES [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, Harvard University, October 1996. [2] IANA, "Port Numbers", http://www.iana.org/numbers.html [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Harvard University, March 1997. [4] IANA, "Protocol Numbers", http://www.iana.org/numbers.html [5] ITU-T, E.164, "The International Public Telecommunication Numbering Plan", May 1997. [6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980. [7] Rigney, et. al., "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, Livingston, April 1997. [8] Postel, J., "Transmission Control Protocol", STD 7, RFC 793 Cornish et. al. expires May 2005 [Page 50] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 10. AUTHOR'S ADDRESSES Allan Cornish INETCO Systems Limited 201-3773 Still Creek Ave. Burnaby, B.C., V5C 4E2 Canada Phone: +1 604-451-1567 Fax: +1 604-451-1565 Email: allan_cornish@inetco.com Michael Cox Alcatel Australia Pty. Ltd. 280 Botany Rd. Alexandria, NSW, 2015 Australia Phone: +61 2-9699-0044 Fax: +61 2-9690-5247 Email: Michael.Cox@alcatel.com.au Robert Neill INETCO Systems Limited 201-3773 Still Creek Ave. Burnaby, B.C., V5C 4E2 Canada Phone: +1 604-451-1567 Fax: +1 604-451-1565 Email: robert_neill@inetco.com Ian Palmer Lucent Technologies 79 Victoria Parade, Collingwood, Victoria Australia. 3066. Phone: +61 3 8413 9022 Fax: +61 3 8413 9000 Email: ipalmer@lucent.com Angus Telfer INETCO Systems Limited 201-3773 Still Creek Ave. Burnaby, B.C., V5C 4E2 Canada Phone: +1 604-451-1567 Fax: +1 604-451-1565 Email: angus_telfer@inetco.com Cornish et. al. expires May 2005 [Page 51] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 Cliff Wignell CoSine Communications Level 50, 120 Collins Street, Melbourne, Victoria Australia, 3000. Phone: +61 3 9225 5288 Fax: +61 3 9225 5172 Email: cwignell@cosinecom.com Cameron Young 19111 - 117A Ave. Pitt Meadows, B.C. V3Y 2R3 Canada Phone: +1 604-465-9100 Fax: +1 604-465-9149 Email: cn_young@attcanada.ca 11. FULL COPYRIGHT STATEMENT Copyright (C) The Internet Society 2004. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. INTELLECTUAL PROPERTY The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed t pertain to the implementation or use of the technology described i this document or the extent to which any license under such right might or might not be available; nor does it represent that it ha made any independent effort to identify any such rights Information on the procedures with respect to rights in RFC document can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and an assurances of licenses to be made available or the result of an attempt made to obtain a general licens or permission for the use of such proprietary rights by implementer or users of this specification Cornish et. al. expires May 2005 [Page 52] INTERNET DRAFT Quick Transaction Protocol (QTP) October 2002 can be obtained from the IETF on-lin IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention an copyrights, patents or patent applications, or other proprietar rights that may cover technology that may be required to implemen this standard. Please address the information to the IETF a ietf- ipr@ietf.org Cornish et. al. expires May 2005 [Page 53]