Internet DRAFT - draft-cornish-qtp
draft-cornish-qtp
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:
+-<NAS>-+ +-<TP>
<Terminal>--<Access>-| |-<IP>-|
+-<NAS>-+ +-<TP>
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]
<QTP Entity Startup> <QTP Entity Startup>
<or Transport layer> <or Transport layer>
<connection rcvd > <connection rcvd >
<Ready for > <Ready for >
<QTP Sessions> <QTP Sessions>
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]
<QTP Entity Startup>
<or Transport layer>
<failure detected >
Status Request
M=1, MI=x
FlowCtrl=Shutdown
---------------->
<If already running >
<QTP Entity restarts >
<clearing QTP Sessions>
Status Report
A=1, MIA=x
<----------------
Status Request
M=1, MI=y
FlowCtrl=Available
---------------->
Status Report
A=1, MIA=y
<----------------
<Ready for >
<QTP Sessions>
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]
