INTERNET DRAFT A. Cornish, INETCO Systems Ltd. Category: Proposed Standard M. Cox, Alcatel Australia Pty. Ltd. Title: draft-cornish-qtp-01.txt R. Neill, INETCO Systems Ltd. I. Palmer, Ascend Communications, Inc. A. Telfer, INETCO Systems Ltd. C. Wignell, Ascend Communications, Inc. November 1999 Quick Transaction Protocol - QTP Status of this Memo This document is an individual contribution for inclusion in public internet standards of the Internet Engineering Task Force. Comments should be submitted to the qtp@inetco.com mailing list. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 This protocol fills a void for an open standard for connecting communications and computing equipment involved in the processing of short duration transactions. QTP is a simple connection-oriented protocol which can be used for concentrating dial-up Point-Of-Sale or other transaction terminals with transaction switches or hosts through a Network Access Server. These transactions require rapid connection times, short hold times, and the ability to transfer access network addressing information. Cornish et. al. expires April 2000 [Page 1] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 This document defines the message formats and sequences that are used for connection management, data transfer, and status reporting. Table of Contents 1. INTRODUCTION 3 1.1 Specification of Requirements 4 1.2 Terminology 4 2. QTP FRAMEWORK 5 3. QTP MESSAGE FORMAT 7 3.1 Message Header 7 3.2 Message Types 9 4. DETAILED MESSAGE TYPES 10 4.1 Call Request 10 4.2 Call Acknowledgement 12 4.3 Call Reject 14 4.4 Clear Request 15 4.5 Clear Acknowledgement 17 4.6 Status Request 18 4.7 Status Report 20 4.8 Data 22 5. ATTRIBUTES 23 5.1 Attribute Header 23 5.2 Attribute Classes 24 5.3 Attribute List 25 5.4 Message Type / Attribute Matrix 26 5.5 Attribute Definitions 28 6. PROTOCOL OPERATION 39 6.1 Protocol Startup 39 6.2 Call Request (incoming) 41 6.3 Call Request (outgoing) 41 6.4 Call Clearing (incoming) 42 6.5 Call Clearing (outgoing) 42 6.6 Status Request 42 6.7 Status Reporting 43 6.8 Data Transfer 43 6.9 Exception Handling 45 7. TRANSPORT 46 7.1 QTP over UDP 46 7.2 QTP over TCP 47 8. SECURITY CONSIDERATIONS 48 9. REFERENCES 49 10. AUTHORS' ADDRESSES 50 11. FULL COPYRIGHT STATEMENT 51 Cornish et. al. expires April 2000 [Page 2] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 1. INTRODUCTION This document describes the QTP interface that can be used to connect Network Access Server sessions associated with short-duration transaction terminals, such as Point-Of-Sale (POS) or Credit Authorization Terminals (CAT) with Transaction Switches or Transaction Processing Hosts. Earlier dial network POS or CAT transaction processing implementations were based on proprietary gateways integrating modem access and transaction switching. Use of QTP allows transaction communications to be handled by third party transaction Network Access Servers through an open interface. Key features of QTP are: * Rapid call setup time; * Transfers access network call information, including calling/called numbers and modem speed; * Independent of access network type (PSTN, ISDN, X.25, Frame Relay); * Operation over connectionless or connection-oriented transports; * Efficient concentration of connections at very high call rates; * Support for outgoing as well as incoming transaction initiation; * Dynamic adjustment to congestion or server failures; * Simple implementation for basic telephone dialup operation. Connection management and status reporting includes acknowledgements and error recovery within the QTP protocol. Cornish et. al. expires April 2000 [Page 3] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 1.1. 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 [2]. 1.2. Terminology This document uses the following terms: CAT Credit Authorization Terminal. 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 this document. TCP Transport Control Protocol UDP User Datagram Protocol. Cornish et. al. expires April 2000 [Page 4] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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. 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. Cornish et. al. expires April 2000 [Page 5] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 6] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 7] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 8] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 9] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 10] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 11] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 12] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 13] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 14] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 15] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 16] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 17] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 18] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 19] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 20] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 21] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 22] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 [14]. Cornish et. al. expires April 2000 [Page 23] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 24] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 Address Family 0x0107 0x01 0x07 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 April 2000 [Page 25] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 26] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 * * - - - - - - 0x0107 Addr Family * - - - - - - 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 April 2000 [Page 27] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 [3]. Support for this attribute is REQUIRED. 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 up to 40 characters. The default address family is E.164. Support for this attribute is REQUIRED. 5.5.3. Profile (0x0102) This Session Configuration 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. Cornish et. al. expires April 2000 [Page 28] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 The definition of standard strings associated with common device profiles is for further study. 5.5.4. Speed (0x0103) This Session Configuration 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 Session Configuration Attribute specifies the maximum time the QTP Session will be held 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 Session Configuration 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. The message size includes the QTP message header size and the sum of the sizes of all the message attributes. The default Maximum Message Size value is 512 (0x0200) octets. Support for this attribute is OPTIONAL. Cornish et. al. expires April 2000 [Page 29] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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. 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 Session Configuration 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 [14]. 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. 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. Cornish et. al. expires April 2000 [Page 30] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 31] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 32] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 33] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 34] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 35] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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. For example, the Remote Cause Attribute value could contain 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 April 2000 [Page 36] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 37] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 38] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 39] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 40] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 41] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 42] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 [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 April 2000 [Page 43] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 44] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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 April 2000 [Page 45] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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. However, this is only one example of a connectionless transport layer. The same general rules apply to other connectionless transport layers. 7.1.1. Normal Mode Initialization UDP transport does not supply the QTP Entity with connection indications or reliable message delivery. The recommended method of startup over UDP transport is the Safe Startup mode described earlier in this document. 7.1.2. QTP Message Transfer 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. 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. Cornish et. al. expires April 2000 [Page 46] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 7.1.3. Well Known UDP Port Number for QTP Source Port [7] Or other port number selected by the sender. Destination Port [7] Or other UDP port number pre-configured and agreed upon between the sender and receiver. 7.2. QTP over TCP The following section addresses the operation of QTP over TCP [8] transport. TCP is only one of many reliable connection-oriented transport layers. Use of QTP over other connection-oriented transport layers is for further study. 7.2.1. Initialization Either QTP Entity involved in a QTP connection MAY initiate the connection. QTP connections are established by the initiating QTP Entity opening a TCP session to the well known QTP/TCP port on the destination host. The transport layer in the destination host will inform its QTP Entity that a connection has been established. The Quick Startup sequence is acceptable for TCP/IP transports, QTP Session establishment may commence as soon as the TCP session has been established. 7.2.2. QTP Message Transfer Once a TCP connection is established, both QTP endpoints may send and receive QTP messages. Either QTP Entity may terminate the TCP session. If the TCP session is disconnected, all active QTP Sessions MUST be disconnected. 7.2.3. Well Known TCP Port Number for QTP Source Port Any port number chosen by the initiator. Destination Port [7] Or other port number configured and agreed upon between the initiator and receiver. Cornish et. al. expires April 2000 [Page 47] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 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. * 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. Cornish et. al. expires April 2000 [Page 48] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 9. REFERENCES [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, Harvard University, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Harvard University, March 1997. [3] ITU-T, E.164, "The International Public Telecommunication Numbering Plan", May 1997. [4] ITU CCITT, X.121, "International Numbering Plan for Public Data Networks", 1989 [5] IANA, "Address Family Numbers", http://www.iana.org/numbers.html [6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980. [7] IANA, "Port Numbers", http://www.iana.org/numbers.html [8] IANA, "Port Numbers", http://www.iana.org/numbers.html [9] ECMA-92, "Connectionless Internet Protocol", March 1984. [10] ISO 7498, "Open System Interconnection Reference Model". [11] ISO 7498, "Addendum 1 - OSI Reference Model Addendum for Connectionless Mode". [12] ISO 8348, "Addendum 1 - Network Service Definition - Addendum for Connectionless Mode". [13] ISO 8373, "Protocol for Providing the Connectionless Mode Network Services (including Addendum 1)". [14] IANA, "Protocol Numbers", http://www.iana.org/numbers.html [15] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. Palter, B., "Layer Two Tunneling Protocol "L2TP"", "work in progress", June 1999. Cornish et. al. expires April 2000 [Page 49] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 10. AUTHORS' 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 Ascend Communications, Inc. Level 38, ANZ Tower, 55 Collins Street Melbourne, Victoria, 3000 Australia Phone: +61 3-9656-7081 Fax: +61 3-9656-7005 Email: ipalmer@ascend.com.au 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 April 2000 [Page 50] INTERNET DRAFT Quick Transaction Protocol (QTP) November 1999 Cliff Wignell Ascend Communications, Inc. Level 38, ANZ Tower, 55 Collins Street Melbourne, Victoria 3000 Australia Phone: +61 3-9656-7081 Fax: +61 3-9656-7005 Email: cwignell@ascend.com.au 11. FULL COPYRIGHT STATEMENT Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Cornish et. al. expires April 2000 [Page 51]