- Email: [email protected]
Open systems interconnection — the transport layer protocol
Open systems interconnection -- the transport layer protocol Ray Hunt examines the functions and mechanisms of the transport layer of the ISO's model for OSI
There is considerable activity within ISO, ECMA and CCITT in establishing an international standard for the transport layer of the ISO OSI modeL Standardization of this layer will provide end users with a choice of quality-of-service from the end-to-end transport mechanism. The need for variations in this quality-of-service arises from the very diverse nature of transport system applications. Currently, applications include teletex, videotex, electronic mail systems, facsimile, digitized voice etc. The draft standards so far developed assume a very detailed knowledge o f the ongoing developm en t work. This paper presents a description of the functions, architecture and protocol mechanisms of the transport layer. It then shows how the various transport layer functions can be grouped in order to define the five protocol classes. The detailed encoding and formal mechanisms of the transport protocol data units (TPDUs) are also described. Keywords: open systems interconnection, protocols, transport service, transport protocol data unit, flow control, error control A number of recent papers I'2 have provided a good introduction to the function of the transport layer within the context of International Standards Organization (ISO) open systems interconnection (OSI) model 3. Considerable activity has recently occurred within ECMA, CCITT and ISO in an effort to provide a transport layer standard. Interest within CCITT results from the requirement of member organizations for international standards on such application-oriented systems as teletex, facsimile, videotex, message handling systems etc. Standards for some of these have Department of Computer Science,Universityof Canterbury,Christchurch, New Zealand
already been finalized, in particular CCll-r Recommendation S.70--'Network independent basic transport service for teletex' (being compatible with a subset of the class 0 transport layer protocol). Interest within ECMA results from the desire to manufacture compatible systems conforming to the standards. Although differences exist between the draft standards produced by these organizations, they are primarily matters of detail relating to parameter options in various classes and not of transport layer philosophy. In the sections which follow, many of the detailed formats and mechanisms of the transport layer protocol will be described. The draft standards are highly technical documents, and the intention of this paper is to assist in explaining many of the mechanisms of these draft standards. Although some of the finer detail may change as the documents pass through the draft protocol (DP) and draft international standard (DIS) phases, it is most unlikely that any major changes will result. An understanding of the functions and terminology of the ISO OSI model3is assumed. The purpose of the transport layer is to provide the application-oriented layers with an end-to-end transport mechanism at a specified quality of service. It provides a link from the network layer to the session layer. In this way the data processing functions (layers 5-7) are kept separate from the communications service functions (layers 1-4), as shown in Figure 1. It is the requirement of the transport service to provide the end users with transparent and reliable communications, without regard to the underlying communications medium. In fact, it should be possible to change one protocol for another at a lower layer, as long as the specification for this service at that layer remains unaltered. The quality-of-service which must be provided by the transport layer protocol includes control of the parameters such as transit delay, residual
0140-3664/84/040186-12503.00 © 1984 Butterworth & Co (Publishers) Ltd. 186
computer communications
n
n
Transport service user B
Transport service user A
Layer 5
Transport service accesspoint... ~
Service.
A n II ! II Transport
~.
" Primitives
t
Lservice s
I -II provided i I1 by layer 4
Transport protocol
Transport
Layer 4
entity
~
Aservices hi- required
Network
Layer 2
Link
Layer 1
Physical
Figure 1.
Services required by layer 4
I bylayer4 Layer 3
Transport interface
Transport
entity
--
Transport services provided by layer 4
Users of transport service i.e. data processing oriented functions
Providers of transport service J.e. communication oriented functions
Network Link
Communications medium
Physical
Transport layer in context of ISO OSI m o d e l 3'4
error rate, throughput, security, priority etc. One important aspect of the transport layer protocol lies in its ability to map the throughput requirements to network connections. This can result in many transport connections being mapped (multiplexed) onto one network connection or, conversely, one transport connection being mapped onto many network connections. The transport layer is end-system oriented and only operates between OSI end systems. Any relay functions or service-enhancement protocols used to support the network service are transparent to the transport layer.
• Transport service data unit (TSDU) - - a piece of data
for the TS user transferred by the TS provider. The maximum size is subject to negotiation by the TS users. • Transportprotocol data unit (TPDU) - - a unit of data containing control information and possibly TS user data. • E n t i t y - a logical object that performs functions in cooperation with other entities to achieve some specific objective. • P r o t o c o l - - a means by which entities in different systems communicate and coordinate their operations.
Symbols and abbreviations TRANSPORT
LAYER ARCHITECTURE Data units
Definitions and terminology
This paper uses the definitions and terminology of the ISO OSI model, and thus only those terms particular to layer 4 will be defined here. • Transport address - - the means by which transport
service users (TS users) are known to the transport service provider (TS provider). • Transport connection ( T C ) - - a two-way simultaneous data path between a pair of transport add resses. • Transport connection end points ( T C E P ) - a TC provided by the TS provider, as seen by its users. • Transport service access point (TSAP) - - the means by which the TS user accesses the TS. Each TSAP has a unique transport address.
vol 7 no 4 august 1984
TPDU transport protocol data unit TSDU transport service data unit NSDU network service data unit Types of transport protocol data units
CR TPDU CC TPDU DR TPDU DC TPDU DT TPDU ED TPDU AK TPDU EA TPDU RJ TPDU ERR TPDU
connection request TPDU connection confirm TPDU disconnect request TPDU disconnect confirm TPDU data TPDU expedited data TPDU data acknowledge TPDU expedited acknowledge TPDU reject TPDU error TPDU
187
TPDU fields LI CDT TSAP-ID DST-REF SCE-REF EOT TPDU-NR ED-TPDU-NR YR-TU-NR
length indicator credit tra.nsport service access point identifier destination reference source reference end of TSDU mark DT TPDU number ED TPDU number sequence number response
Timer variables TI N L T-WAIT
I W
elapse time between retransmissions the maximum number of retransmissions bound for the maximum time between the decision to transmit a TPDU and the receipt of any response relating to it maximum time for a reassignment to take place before TC failure is assumed inactivity timer -- maximum time allowed to elapse between receipt of TPDUs before TC failure is assumed window timer-- maximum interval between transmission of up-to-date window information
Transport service The layer 4 standards have been designed in accordance with the ISO OSI model 3, and in particular, knowledge of Section 7.4 of this reference, 'The transport layer', is assumed. The general characteristics of the transport service (TS) are as follows.
Network independence No restrictions shall be communications medial of the ISO OSI model protocols at the lower transport service.
placed upon the underlying Providing that the principles are adhered to, changes in layers must not affect the
Cost optimization The transport service shall endeavour to balance the use of communications resources with the requirements of the transport service users (TS users). End-to-end significance The transport service has end-to-end significance, and any relay functions existing between the end users shall be transparent to this layer. Error control The users of the transport service can assume errorfree information exchange. Only major errors such as total network failure shall be signalled to the network service users Transport information exchange The transport service has no requirement to understand the format or structure of the user information being exchanged, whether it be data or control information.
188
User addressing The transport service uses a system of addressing which is mapped onto the addressing scheme of the supporting communications medium. Thus, transport addresses can be used by the TS users to refer unambiguously to one another without regard to physical locations. The transport service defines a set of service primitives for the purpose of establishing and terminating a connection, as well as exchanging data. It is from these transport service primitives that the detailed structure of specific interface primitives such as transport protocol data units (TPDUs) results, although in principle a variety of transport layer protocols could be designed upon the same set of service primitives. These interface primitives may well be affected by local operating conditions, such as operating systems and language restrictions. Thus, such interface primitives, while described in detail below, are not suitable for a general description. Neither is there necessarily a one-to-one correspondence between transport service and interface primitives. The transport service provides a delivery of transport service data units (TSDUs) to the TS users via transport connections (TCs) established between pairs of transport addresses identifying the corresponding TS users. These TS users are provided with the means to establish, maintain and terminate TCs which represent a full duplex data path between them. The transport service also defines grades of quality-of-service, which may be selected on a per-connection basis. This quality-of-service is defined in terms of parameters such as transit delay, residual error rate and throughput. The TS primitives and their parameters for TC establishment, data transfer and TC release are shown in Table 1. Figure 2 shows these TS primitives applied to the transport connection end points (TCEPs) as timesequence diagrams. Figure 3 shows the state transition diagram for the allowable sequence of TS primitives at a TC end point.
Protocol mechanisms A brief description is given below of some of the more characteristic transport protocol mechanisms. The ISO standard 6'7 defines 24 different protocol mechanisms, but in this discussion, related mechanisms are discussed as a group. See also Table 2.
Transport protocol data unit (TPDU) transfer The TPDUs (control and normal) are listed in Table 3. These are used by all classes, and are conveyed using network service data unit (NSDU) parameters of the network service primitives 8, primarily with N-data (network data) but also with N-expedited (network expedited) primitives.
Connection establishment, termination, reassignment and acknowledgement Creation of a new TC is established by use of CR and CC TPDUs. A variety of mandatory fields (e.~ source/ destination reference (SCE/DST-RFF), initial credit
computer communications
T - CONNECT request
request
D w
I
.~.~
T - DISCONNECT indication
Tindication - DISCONNECT
J T - DISCONNECT request
T - EXPEDITED DATA request
T - DATA request
T - EXPEDITED DATA indication
T - DATA indication Expedited data transfer ( user option )
Normal data transfer
T - DISCONNECT indication
TC release initiated by TS user
T - DISCONNECT request
T - DISCONNECT request
T - DISCONNECT request
Rejection of TC establishment request by TS provider
Rejection of TC establishment request by TS user
Successful TC establishment
T - DISCONNECT indication
/V
N T - DISCONNECT indication
TC release initiated by both TS users
Figure 2.
T - CONNECT request
T - CONNECT indication T-'DiSCONNECT request
T - CONNECT indication T - CONNECT response T - CONNECT confirm
~
T - DISCONNECT indication
TC release initiated by TS user and TS provider
TC releaseinitiated by TS provider
Transport service primitive time sequence diagrams 5
T - DISCONNECT ~
reou.,
Idle T
.T - D I S C O N N E C T / /
J~
T - DISCONNECT
\\
eoue.t ~
r ~, DISCONNECT
confir~
T - CONNECT I T - CONNECT
T -- DATA T - EXPEDITEDDATA primitives
Figure 3. State transition diagram for allowable IS primitive sequences
vol 7 n o 4 a u g u s t 1 9 8 4
a l l o c a t i o n (CDT), p r e f e r r e d / a l t e r n a t i v e p r o t o c o l ) a n d o p t i o n a l fields (e.g. c a l l i n ~ c a l l e d t r a n s p o r t services access p o i n t identifiers (TSAP-I Ds), T P D U size, s e q u e n c e n u m b e r length, user data, c h e c k s u m , a c k n o w l e d g e m e n t t i m e , quality-of-service, security, v e r s i o n n u m b e r ) are s p e c i f i e d . T h e p r o c e d u r e for TC e s t a b l i s h m e n t f o l l o w s t h e p r i n c i p l e of V C e s t a b l i s h m e n t in X.25; h o w e v e r , b e f o r e s e n d i n g t h e CR T P D U , t h e s e n d e r assigns t h e TC t o o n e o r m o r e n e t w o r k c o n n e c t i o n s a n d it is o v e r this set o f n e t w o r k c o n n e c t i o n s t h a t T P D U s are sent. D u r i n g this phase, i n f o r m a t i o n n e e d e d b y t r a n s p o r t e n t i t i e s is e x c h a n g e d o r n e g o t i a t e d w i t h a p p r o p r i a t e parameters. If a TC c a n n o t b e a c c e p t e d , t h e c a l l e d e n t i t y r e p o n d s w i t h a DR T P D U , i n d i c a t i n g t h e reason a c c o r d i n g l y . H o w e v e r , n o r m a l d i s c o n n e c t i o n is carried o u t b y use of DR a n d D C TPDUs, t h e c o m b i n a t i o n d e p e n d i n g u p o n t h e class selected. S p u r i o u s DR T P D U s r e c e i v e d w h e n a TC d o e s n o t exist are c o n f i r m e d w i t h TC TPDUs. When a network connection to which a target c o n n e c t i o n ( s ) has b e e n assigned n o l o n g e r exists, t h e
189
Table 1.
Transport service primitives s
Phase
Service
Primitive
Parameters
TC establishment
TC establishment
T.CONNECT request
(Called address, calling address, expedited data option, quality of service, TS user data) (Called address, calling address, expedited data option, quality of service, TS user data) (Quality of service, responding address, expedited data option, TS user data) (Quality of service, responding address, expedited data option, TS user data)
T-CON N ECT indication T-CON N ECT response T-CON N ECT confirm
Data transfer
Normal data transfer Expedited data transfer*
TC release
TC release
T-DATA request T- DATA indication T-EXPEDITED-DATA request T-EXPEDITED-DATA indication
(TS (TS (TS (TS
T-DISCONNECT request T-DISCON N ECT indication
(TS user data) (Disconnect reason, TS user data)
user user user user
data) data) data) data)
*User option: provided only upon TS user request TC(s) can be assigned to other network connections. Reassignment following resynchronization is carried out with a RJ or retransmitted CR or DR TPDU. Copies of CR, CC, DR, DT and ED TPDUs are retained to permit later retransmission in the event of loss of the originals. As each of these TPDUs is acknowledged, either explicitly or implicitly, the copy can then be released.
TPDU length, segmenting and concatenation A transport entity can map a transport service data unit (TSDU) onto one or more DT TPDUs, where the data field of these DT TPDUs contains any number of octets, up to an agreed maximum. Control TPDUs may contain user data, depending upon the class of operation. Also, the length of the TPDU is specified in the header, meaning that any number of control TPDUs, not containing user data, can be concatenated with a single control TPDU containing user data or a single DT TPDU. These TPDUs may be the same or different TCs. This mechanism provides for greater efficiency of the TC.
Data TPDU numbering In accordance with layers 2 and 3 of the ISO OSI model, all DT TPDUs are numbered so that sequencin~ recovery and flow control can be implemented. Each DT TPDU contains a sequence number, 'TPDUN R'. These are then compared with the' next expected TPDU-NR' by the end transport entities. Two numbering methods are in use: • normal - - 7 bit, providing for modulo 2 7 arithmetic, • extended - - 31 bit, providing for modulo 231 arithmetic. The first bit of the TPDU-NR field (normal and extended) is used as an 'end of transport service data
190
unit marker' (EOT) to specify the end of a TSDU sequence. Similarly bit 5/octet 3 of an X.25 data packet is used as an M (more data) bit, and bit 5 of the control byte in HLDC may be used as an F(final) bit.
Expedited data (ED) transfer A DT TPDU which is not subject to queueing, resource restrictions or any other impediment to its rapid delivery is known as an ED TPDU. Subsequent ED TPDUs in each direction may not be transmitted until the first ED TPDU has been acknowledged with an EA TPDU. They could be used to convey network functions, such as X.25 interrupt and interrupt confirmation packets.
Multiplexing, splitting and recombining Several TCs may share one network connection simultaneously. This mechanism provides for more efficient use of the networks's resources but is only used in classes 2, 3 and 4. Classes will be described in a subsequent section. Every TPDU must carry the DSTREF to identify the TC to which it refers. Class 4 provides an option whereby a TC can be assigned to multiple network connections for the purpose of security and reliability. Providing that the supporting network connections have similar transit delays, the TPDUs may then be sent over any of the assigned network connections. The TPDUs must then be resequenced on arrival.
Explicit flow control Sometimes it is desirable to regulate the flow of DT TPDUs independently of the layer 2 and 3 flow-control mechanisms. This is carried out by control of the credit mechanism (octet 3 of CR, CC, AK and RJ TPD Us) but is only available in classes 2, 3 and 4.
computer communications
Table 2.
Transport protocol mechanisms and classes for which they apply 1'6
Function
Protocol mechanism
Establishment phase TC-establishment
TC- rejection
0 Transport/network address mapping Assignment to network connection Connection by CR, CC, TPDUs Termination by DR TPDU Termination by DR, DC TPDU
Negotiation of option Protocol class TPDU size Extended sequence nr. Flow control Use of expedited TSDUs Checksum Receipt confirm Use of network expedited data Transfer of user connection data Alternative protocol class
Fixed part of CR, CC TPDU (bits 5-8) Variable part of CR, CC TPDU Fixed part of CR, CC TPDU (bit 2) Fixed part of CR, CC TPDU (bit 1) Variable part of CR, CC TPDU Variable part of CR, CC TPDU Variable part of CR, CC TPDU Variable part of CR, CC TPDU CR, CC TPDU user data field (max 32 octets) CR, CC TPDU
Release phase TC release Transfer of user disconnect data
Termination by DR, DC TPDUs DR TPDU user data field (max 64 octets)
Data Transfer phase Optimization of network connection Segmenting Data Transfer
Data flow control
Expedited data transfer Expedited data flow control Error detection of
Error recovery from
TPDU loss TPDU corruption TPDU duplication TPDU misordering Protocol error Unsignalled network break TPDU loss TPDU corruption TPDU duplication TPDU misordering Protocol error Network reset Network disconnection Unsignalled network break
Class
Concatenation Multiplexing using TPDU destination reference Splitting using TPDU reordering Delimination by TPDU EOT field Use of DT TPDU no numbering normal numbering (7 bit) extended numbering (31 bit) Use of credit fields Normal numbering (7 bit) Extending numbering (31 bit) Window reduction ED, EA TPDUs EA TPDU
2
3
X
X
X
4 X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X --
X --
X --
X
--
X
X
--
X
--
X
X
X
X
--
X
X
X
X
--
X
X
X
X
--
X
X
X
X
--
X
X
X
X
X
M
x
x
X
X
X
X
x
M
M
M
A
A x M A
A x M A
X X X
-M
M A --
TPDU NR field Time out TPDU checksum parameter TPDU NR field TPDU NR field TPDU type field checking Activity time-out, transmission of AK TPDU while inactive Retransmission request by RJ TPDU Retransmission on time-out TPDU discard, recovery from loss TPDU discard TPDU NR field Error notification by ERR TPDU Retransmission request by RJ TPDU Retransmission on time-out Reassignment of network connection, retransmission request by RJ TPDU Reassignment of network connection, retransmission on time-out Reassignment of network connection, retransmission on time-out
1
--
X
X
x
x
x
M
M
x
M
x
x
M
X
M
X
X
X
X
X
X
X
X
X
X
m
X
M X
x X
x --
X X
X --
X X
X --
X --
X
--
X
--
x
Key: x, always provided; --, never provided; M, mandatory option; A, additional option; f, for further study
vol 7 no 4 august 1984
191
Table 3.
the same network connection, they too must be treated as though a network-signalled error had occurred.
Transport protocol data units Mnemonic Control Data
TPDU name Connection request Connection confirm Disconnect request Disconnect confirm Data Expedited data Data acknowledge Expedited acknowledge Reject TPDU error
Protocol errors
CR CC DR DC
Any TPDU received which cannot be handled by the previously described mechanisms constitutes a protocol error. Such violations of the class rules might result from w i n d o w errors, sequencing errors, incorrect formats etc. The error is signalled to the sending end by an ERR TPDU, which contains the offending TPDU up to and including the first octet where the error was detected. Action by the sender is not specifically defined by the protocol, but it would be appropriate to:
DT ED AK EA RJ ERR
• correct the error and retransmit if possible, • close down the connection and report to the upper layers; in any case, the receiving end would temporarily 'freeze' the connection.
Timeout Procedures for retransmission on timeout are designed to be used in class 4 to cope with unsignalled loss of TPDUs by the network. If acknowledgement of a TPDU is required and yet not received within time T1, then up to N-1 retransmissions will occur, after which a DR TPDU is transmitted and the TC closed down for a minimum period of time L No specific values for these parameters are given in the standards, although suggestions are made on how to calculate appropriate values.
DESCRIPTION
A class defines a set of functions, and five classes are defined, so that the user can select the one which best fits the required quality-of-service. The intention was to develop the standards such that each lower class would be a subset of the functions of the next higher class, although the standards have not entirely turned out this way. During connection establishment, classes and options within classes may be negotiated by use of CR and CC TPDUs. For example, the requestor can state a preferred class, followed by a range of alternatives in order of preference. Also, the requestor may propose a maximum DT TPDU size, and if the receiver does not accept this size it can be negotiated downwards as far as the default length of 128 octets. In general, the receiver will accept the proposed option or indicate refusal in the CC TPDU. Most options have default values which depend upon the class to which they apply; for example:
Checksum The purpose of the checksum algorithm is to detect corruption of TPDUs, and it is primarily intended for use in class 4, where there is likely to be a high residual error rate. When a TPDU is transmitted on a TC for which the checksum option parameter has been selected, the following checksum algorithm is used. The TPDU is set up with the checksum octets (X and Y) set to zero. Temporary variables CO and C1 are initialized to zero. For each octet of the TPD U from I to L (see Figure 4) add the octet value to CO, and then add CO to C1. All addition is performed modulo 255. The values of the checksum octets, X and Y, are then calculated according to equations (1) and (2) respectively, where the first octet (X) becomes the nth octet of the TPDU. X = (((L -- n)*CO) - C 1 ) modulo 255 Y = (((L -- n + 1)*(--CO)) +C1) modulo 255
• use of the checksum parameter is the default for class 4, while nonuse is the default for other classes, • use of the flow-control option is the default for class 2, • extended header format provides four octet sequence numbers and two octet credit allocations for classes 1-4; its nonuse is the default.
(1) (2)
A simpler implementation may use one's complement arithmetic instead of modulo 255. However, if either X or Y end up with the value - 0 , then it must be converted to 4-0 before being stored in the checksum parameter. The same algorithm is used to compute the checksum at the receiving end. If checksum failure occurs, it is not possible to determine the TC to which the faulty TPDU relates, since the reference field itself may have been corrupted. Hence, if other TCs are multiplexed onto 1
2 3 4
F,x pa
k
k+l
I
Parameters which do not have default values must be specified in both CR and CC TPDUs. A classification of network services in terms of quality-of-service, with respect to error behaviour, has been developed. Its main purpose is to provide a basis for the selection of an appropriate class for a particular TC in association with a given network connection.
n
V0riab'epa
I
n+l
x
OF C L A S S E S
I
•
Y
m
I
-,y
p
J /
p+l
L
Data field
]
Checksum parameter
Figure 4.
192
TPDU showing two octet checksum parameters
computer communications
A--network connection with acceptable residual error rate (for example not signalled by 'clear' or 'reset') and acceptable rate of signalled failures. • Type B ~ as for type A, but unacceptable rate of signalled failures. • Type C - - network connections with residual error rate not acceptable to the TS user. • Type
Table 2 provides a summary of the transport protocol functions and mechanisms applicable to each of the five classes.
Simple class (class O) This class provides the most basic form of TC. As such, it has few of the more sophisticated features available in some of the other classes. It has been defined by CCITT (S.70) and used to specify teletex networking. This class only provides the facilities for connection establishment, data transfer with segmenting and treatment of protocol errors. There are no facilities for multiplexing, flow control, error recovery or expedited data transfer. It is intended to be used for type A network connections.
Basic error and recovery class (class 1) This class provides a TC with minimal overhead. It functions like class O, but can recover from network disconnections without involving the end users, and is primarily designed to be used for type B network connections. In particular, it provides facilities for connection establishment/disestablishment, normal and expedited data transfer, error recovery and flow control.
Like class O, there are no facilities for error recovery, but user data may be appended to CR, CC and DR TPDUs in the same way as up to 16 octets of user data can be optionally incorporated into an X.25 call request packet.
Error recovery class (class 3) This class provides the facilities of class 2, with the ability to recover from errors generated by network disconnection and resetting without involving the TS users. This class would be selected where both multiplexing and reliability were required, and would be used for type B network connections. When an error is signalled by the network layer, RJ TPDUs are exchanged with sequence number response fields (YRTU-NR) set to the next expected TPDU. This may then be followed by exchange of previously transmitted DT TPDUs, in order to restore the required sequence.
Error detection and recovew class (class 4) Class 4 provides the facilities of class 3, along with mechanisms to detect TPDU errors resulting from a low-grade network service. The types of errors which can be detected include lost, duplicated, out-ofsequence and corrupted TPDUs (control and data). Error detection is implemented by extending the use of sequence numbering to certain control TPDUs and their acknowledgements, as well as DT TPDUs. A variety of time-out and retransmission mechanisms are also used. Use of the checksum enables detection and retransmission of damaged TPDUs.
S T R U C T U R E A N D E N C O D I N G OF T P D U s Multiplexing class (class 2)
Basic structure
The aim of this class is to provide a method of multiplexing several TCs over one network connection, and it is intended to be used for type A network connections. Flow control is optional, but is 'explicitly' used with heavy traffic when performance (e.g. response time) must meet specific standards. Where there is endpoint congestion, perhaps caused by intensive multiplexing, then flow control is desirable. Without flow control, multiplexing is still possible, but the performance of the network cannot be guaranteed, and this option is more appropriate for dumb terminals where minimal overhead is desirable and where network connection utilization is low. When flow control is used, a credit mechanism exists for allowing the receiving station to set up a receive window. Expedited data is only available with explicit flow control. Care must be taken that nonuse of flow control does not delay traffic on other multiplexed channels, thus forcing flow control back to the network layer. I
LI
I_ I Figure 5.
I
Fixedpart
I
Header field
Variablepart
I
All TPDUs consist of a header followed by an optional data field. The header comprises the length indicator field (LI), a fixed part and an optional variable part. The LI field contains a length of the fixed and variable parts of the header, (see Figure 5). TPDUs are of two basic types. used to control transport protocol functions and in particular for setting up and clearing down a TC in a similar manner to the way in which X.25 sets up a VC by way of call establishment/ cleardown. However, unlike X.25, classes of service can be negotiated during the TC set-up phase. The control TPDUs are CR, CC, DR, DC as well as RJ and ERR. • D a t a - - may be of two types; normal (DT, AK) and expedited (ED, EA). • Control-
TPDU names, code and classes to which they apply are shown in Table 4.
Data field
I
~i I
TPDU structure
vol 7 no 4 august 1984
193
Table 4.
Summary of T P D U names, codes and classes 6
Classes 0 CR connection request CC connection confirm DR disconnect request DC disconnect confirm DT data ED expedited data AK data acknowledgement EA expedited data acknowledgement RJ reject ERR TPDU error
x x x x
x
1
Code 2
3
4 (bits 8-5, octet 2)
x x x x x x x x x x x (2) (3) (2) x (2) x x x
x x x x x x x x x x
x x x x x x x x
1110xxxx 1101xxxx 10000000 11000000 11110000 00010000 0110xxxx(1) 00100000 0101xxxx (1) x 01110000
xxxx (bits 4-1) used to signal the credit allocation (CDT) (1) In extended header format, the code for AK = 01100000 and the code for RJ= 01010000 (2) Not available when nonexplicit flow control option is selected (3) Not available when receipt confirmation option is selected
• TPDU sequence numbering is discussed in association with specific TPDU structures (see below).
Fixed part
fixed part of the TPDU contains frequently occurring functions, including the TPDU code (bits 85, octet 2). The length and structure of the fixed part is specific to each TPDU. The most common fields are as follows. The
• The initial credit allocation (CDT) field (bits 4-1, octet 2: CR, CC, AK, RJ TPDUs only) is not significant for classes 0 and 1, but for classes 2-4 it shall contain the number of DT TPDUs which are allowed by the 'window allocation'. This means that the receiver may inform the sender of the amount of data he is willing to receive. • The source reference (SCE-REF) field (octets 5-6: CR, CC, DR, DC TPDUs only) contains the reference (address) selected by a control TPDU to identify the source end of the TC. • The destination reference (DST-REF) field (octets 34:, CC, DR, DC, DT, ED, AK, EA, R], ERR TPDUs), is the same as the SCE-REF, but identifies the destination end of the TC. • The class field (bits 8-5, octet 7: CR, CC TPDUs only) specifies the preferred protocol class required for the TC. However, if this is not available, choices of 'alternative protocol classes' may optionally be specified as a parameter in the variable-field part of a control TPDU (see Table 5). • The options field (bits 4-1, octet 7: CR, CC TPDUs only) comprises the second half of octet 7, which is reserved for the specification of standard options to be made available as part of the requested TC for classes 1-4. In particular, normal/extended format (bit 2) and optional flow control for class 2 (bit 1) can be specified. Table 5.
194
Class encoding
Class
Bits 8-5, octet 7
0 1 2 3 4
0000 0001 0010 0011 0100
Variable part
The variable part of a TPDU is optional, specify parameters relating to optional similar fashion to specifying optional X.25 call establishment packets. The consists of:
and is used to functions in a parameters in format always
• parameter code (1 octet), • parameter length (I octet), • parameter value (octet 3 on). Bits 8-7 of the parameter code are always used to indicate the source of the definition, e.g. 01 --CCITT, 1 0 - - ISO, 11 - - common to CCITT and ISO. The following parameters can be used in the variable part of various TPDUs. the exception of class O, all TPDUs may have checksums, used as the default option for class 4. The specific algorithm has already been discussed. • Transport service access p o i n t identifiers (TSAP119) - - these parameters are used to specify the calling and called access points. • T P D U s i z e - - this parameter proposes the maximum size of the data units to be used over the requested TC (see Table 6). • Version n u m b e r - - where different versions of the transport protocol are available, the preferred version can be specified. It is not used with class 0 and defaults to 00000001. • Checksum--with
Table 6.
T P D U size coding
Length (octets) Bit pattern 8192 4096 2048 1024 512 256 128
00001101 (except classes 0 and I) 00001100 (except classes 0 and 1) 00001011 00001010 00001001 00001000 00000111
computer communications
TPDU encoding
• S e c u r i t y - - this allows the user to identify security •
•
•
•
•
•
•
information. It is not used with class 0. Alternative p r o t o c o l c l a s s - the TS users may request use of alternative classes if the one specified in octet 7 of CR and CC TPDUs is not available. They must be specified in order of preference, according to Table 5. It is not used with class 0. A d d i t i o n a l o p t i o n s - - a selection of options, such as use of network expedited data (class 1), receipt of confirmation (class 1), checksums (class 4) and expedited TSDUs can be specified in the class options octet. A c k n o w l e d g e t i m e - - this parameter indicates the maximum acknowledge time to the remote end. It may be specifying during connection establishment in CR or CC TPDUs, but is an indication only and not subject to negotiation. If not specified, it may be assumed to be insignificant in comparison with transit delay. T h r o u g h p u t - these parameters specify the minimum and target throughput speed (octet/s) for both the called-calling and calling-called user directions. Residual error rate - - these parameters specify the minimum and target residual error rates for a specified TSDU size. P r i o r i t y - - t h i s parameter contains user-specified integers which define the relative importance of the TC with respect to the order in which the connection is to have its quality-of-service degraded, or even broken if it becomes necessary to recover resources. Transit d e l a y - - these parameters specify the target and maximum acceptable transit delays (ms) for both the called-calling and calling-called user directions.
The full structure of the establishment and release TPDU formats are shown in Figure 6. All fields have been previously defined, with the exception of octet 7 of the DR, which merely specifies the reason for disconnection in a similar fashion to the way in which a clearing cause field is specified in an X.25 clear request/indication packet; for example, normal disconnection, remote congestion, connection negotiation failed, duplicate address, connection request refused, parameter mismatch etc. More specifically, for teletex (class 0), the following values have been defined by the CCITT: 1 0 0 0 0 0 0 0 - - n o r m a l disconnection (no specified reason), 10000001 - - terminal occupied, 1 0 0 0 0 0 1 0 - terminal out of order, 10000011 - - address unknown. The structure of the normal data TPDUs, including those for acknowledgement and rejection, are shown in Figure 7. For classes 0 and 1, no parameters can be spe~cified in the variable part of the header field. The EO~- bit indicates whether the DTTPDU is the last data uni~of the sequence or not. For AK, EA and RJ TPDUs, EO~,= 0, and for ED TPDUs, EOT = 1. The TPDU-NR field contains the sequence number of the DT TPDU, but it has no significance in class 0 or for class 2 without explicit flow control. A similar definition applies to the ED TPDU-NR field. The YR-TU-NR field contains: • the sequence of the next expected DTTPDU forAK format, • identification of the ED TPDU being acknowledged for EA format, • the next expected DT TPDU for which retransmission should occur for RJ format.
Data field This field contains transport user data, and may be attached to CR, CC, DR, EA and DT TPDUs, with restrictions on length and classes as follows:
Extended number format options provide for a 31 bit sequence number field (octets 5-8) in DT, ED, AK, EA and RJ TPDUs, and a 2 octet credit allocation field in AK and RJ TPDUs (see Figure 8). The ERR-TPDU format is shown in Figure 9 and contains a 'reject cause' octet, specifying invalid parameter code, parameter value or TPDU type. The contents of the rejected TPDU, up to and including the octet which caused the rejection, is specified in the variable part of the header field.
• CR, CC not permitted for class 0, otherwise--< 32 octets, • DR not permitted for class 0, otherwise-< 64 octets, • EA not permitted for class 0 or class 2 without explicit flow control, otherwise _< 16 octets, • DT length restricted only by maximum TPDU length selected during connection set up.
1
2
1"
LI
ICR ICDT[ 0
I
L. Icc lcoTI
L
LI
3
4 0
0
6
7
8
p
p+l
l
SCE-REF
osT-.EF
I
SCE-.EF
I C,a.s,o0t,ons I
Var,ab.epa I
Userda.a I
IDR I 0 I
DST-REF
[
SCE-REF
I
Reason
I
Variablepart I
Userdata
l
I°cl°l
osT.EF
I
SCE.EF
I
Variablepart
I
Figure 6.
Establishment and release TPDU formats 7
vol 7 no 4 august 1984
0
5
!
195
E 0
1
,,
2
T
3
o~! o i i ~.oo-.. 4
I
( Specific to claues 0 and 1 only )
1
2
•,
o~1o I
o~-.~
I
TPDU-NR
•,
EOIo I
osr-R,~,=
I'
'~°-rP°"-"RI
,,
I'.,~Ico, I
.,ST-RE,=
Io
,',=,- r,., - ,,,,., I
,,
E,,iol
osr_R,=,=
Io
YR-,O-,,,R
L,
RJIcoTI
OSTREF
I0
YRTO-NRI
Figure 7.
3
User data E O T
5
6
I
p
p+l
Variablepart I
User data
Var,ab,eo.,,t I
U~rO,,ta
t
Var,ab,eo,,r, I
I V,,ri,,b,e,,.,r,
I
Var,ab,.0..
Normal data reject TPDU formats
E
2
1
I"
3
4
-~ 5
I°~1°1
°~-~
II
6
7
8
~°°-~
9
I
p
I
User data
Variab,e~a~ I
O~r~.t.
v'"'~'e~'~
i
L,
iEol01
osT-REF
IllEo-TPOO-N~I
!
LI
IAK I 0 I
DST-REF
10 I Y R - T U - N R
ICDTI
I
LI
lEA I 0 I
DST-REF
]0 I Y R - T U - N R
I
I"'1°1
osr-,E,=
Iol
Icorl
I" Figure 8.
I
2
LI
IERRI 0 I
3
4
DST-REF
5
I
Rejectcause
Variablepart
I
]
V.ria,,,eo.rt
I
6
I
p
Variablepart
I
Error TPDU format
CONCLUSION
Transport layer standardization has now reached a point where designers and implementors can select a preferred quality-of-service. Already class 0 has been adopted in the form of CCITT S.70 for teletex networking. X.25 based packet switching networks lack full end-to-end significance, and the transport protocol has the ability to provide a secure connection to cope with problems such as lost packets resulting from virtual circuit resetting or cleardown. At the other
196
Variablepart
1
Extended data and reject TPDU formats
1
Figure 9.
~,~-ro-,,,,.,
p+l
extreme, developments in local area network technology require connection oriented and connectionless services, for which the error detection and recovery facilities of class 4 are ideal. REFERENCES
1
yon Studnitz, P'Transport protocols: their performance and status in international standardization' Comput. Net. Vol 7 (1983) pp 27-35
computer communications
2
3
4
5
Knightson, K G 'The transport layer' Comput. Commun. Rev. Vol 12 No 3/4 (July/October 1982) pp 14-23 Reference model of open system interconnection - - D r a f t Revised Recommendation X,200 CCI]-I-, Switzerland (July 1983) Standard ECMA-72 Transport Protocol 2nd Ed, ECMA, USA (September 1982)
6 7
Transport service d e f i n i t i o n - Draft Recommendation X.214 CCITT, Switzerland (June 1983) Transport protocol s p e c i f i c a t i o n - Draft Recommendation X.224 CCITT, Switzerland (June 1983) Alternative text for the transport protocol ISO/ TC97/SC16 N1297, ISO, Switzerland (December
1982) 8
Network service definition - - Draft Recommendation X.213 CCITT, Switzerland (June 1983)
Corrisendum The authors of the paper 'Computer network capacity in robotic neural systems',published in the April 1984 issue,would like to point out that the first line of the right hand column on page 87 should read: k
T. Coi
where 0_
i=1
Co
>0
the quarterly international journal for practitioners in computer performance, evaluation and tuning Coverage: • • • • •
measurement applications measurement technology analytic methods measurement notes design techniques
• •
modelling techniques capacity planning
• •
performance theory product descriptions
For further details please contact: Sheila King Butterworth Scientific Limited PO Box 63 Westbury House Bury Street Guildford SurreyGU25BH Telephone: 0483 31261 Telex: 859556SCITECG
vol 7 no 4 august 1984
197
There is considerable activity within ISO, ECMA and CCITT in establishing an international standard for the transport layer of the ISO OSI modeL Standardization of this layer will provide end users with a choice of quality-of-service from the end-to-end transport mechanism. The need for variations in this quality-of-service arises from the very diverse nature of transport system applications. Currently, applications include teletex, videotex, electronic mail systems, facsimile, digitized voice etc. The draft standards so far developed assume a very detailed knowledge o f the ongoing developm en t work. This paper presents a description of the functions, architecture and protocol mechanisms of the transport layer. It then shows how the various transport layer functions can be grouped in order to define the five protocol classes. The detailed encoding and formal mechanisms of the transport protocol data units (TPDUs) are also described. Keywords: open systems interconnection, protocols, transport service, transport protocol data unit, flow control, error control A number of recent papers I'2 have provided a good introduction to the function of the transport layer within the context of International Standards Organization (ISO) open systems interconnection (OSI) model 3. Considerable activity has recently occurred within ECMA, CCITT and ISO in an effort to provide a transport layer standard. Interest within CCITT results from the requirement of member organizations for international standards on such application-oriented systems as teletex, facsimile, videotex, message handling systems etc. Standards for some of these have Department of Computer Science,Universityof Canterbury,Christchurch, New Zealand
already been finalized, in particular CCll-r Recommendation S.70--'Network independent basic transport service for teletex' (being compatible with a subset of the class 0 transport layer protocol). Interest within ECMA results from the desire to manufacture compatible systems conforming to the standards. Although differences exist between the draft standards produced by these organizations, they are primarily matters of detail relating to parameter options in various classes and not of transport layer philosophy. In the sections which follow, many of the detailed formats and mechanisms of the transport layer protocol will be described. The draft standards are highly technical documents, and the intention of this paper is to assist in explaining many of the mechanisms of these draft standards. Although some of the finer detail may change as the documents pass through the draft protocol (DP) and draft international standard (DIS) phases, it is most unlikely that any major changes will result. An understanding of the functions and terminology of the ISO OSI model3is assumed. The purpose of the transport layer is to provide the application-oriented layers with an end-to-end transport mechanism at a specified quality of service. It provides a link from the network layer to the session layer. In this way the data processing functions (layers 5-7) are kept separate from the communications service functions (layers 1-4), as shown in Figure 1. It is the requirement of the transport service to provide the end users with transparent and reliable communications, without regard to the underlying communications medium. In fact, it should be possible to change one protocol for another at a lower layer, as long as the specification for this service at that layer remains unaltered. The quality-of-service which must be provided by the transport layer protocol includes control of the parameters such as transit delay, residual
0140-3664/84/040186-12503.00 © 1984 Butterworth & Co (Publishers) Ltd. 186
computer communications
n
n
Transport service user B
Transport service user A
Layer 5
Transport service accesspoint... ~
Service.
A n II ! II Transport
~.
" Primitives
t
Lservice s
I -II provided i I1 by layer 4
Transport protocol
Transport
Layer 4
entity
~
Aservices hi- required
Network
Layer 2
Link
Layer 1
Physical
Figure 1.
Services required by layer 4
I bylayer4 Layer 3
Transport interface
Transport
entity
--
Transport services provided by layer 4
Users of transport service i.e. data processing oriented functions
Providers of transport service J.e. communication oriented functions
Network Link
Communications medium
Physical
Transport layer in context of ISO OSI m o d e l 3'4
error rate, throughput, security, priority etc. One important aspect of the transport layer protocol lies in its ability to map the throughput requirements to network connections. This can result in many transport connections being mapped (multiplexed) onto one network connection or, conversely, one transport connection being mapped onto many network connections. The transport layer is end-system oriented and only operates between OSI end systems. Any relay functions or service-enhancement protocols used to support the network service are transparent to the transport layer.
• Transport service data unit (TSDU) - - a piece of data
for the TS user transferred by the TS provider. The maximum size is subject to negotiation by the TS users. • Transportprotocol data unit (TPDU) - - a unit of data containing control information and possibly TS user data. • E n t i t y - a logical object that performs functions in cooperation with other entities to achieve some specific objective. • P r o t o c o l - - a means by which entities in different systems communicate and coordinate their operations.
Symbols and abbreviations TRANSPORT
LAYER ARCHITECTURE Data units
Definitions and terminology
This paper uses the definitions and terminology of the ISO OSI model, and thus only those terms particular to layer 4 will be defined here. • Transport address - - the means by which transport
service users (TS users) are known to the transport service provider (TS provider). • Transport connection ( T C ) - - a two-way simultaneous data path between a pair of transport add resses. • Transport connection end points ( T C E P ) - a TC provided by the TS provider, as seen by its users. • Transport service access point (TSAP) - - the means by which the TS user accesses the TS. Each TSAP has a unique transport address.
vol 7 no 4 august 1984
TPDU transport protocol data unit TSDU transport service data unit NSDU network service data unit Types of transport protocol data units
CR TPDU CC TPDU DR TPDU DC TPDU DT TPDU ED TPDU AK TPDU EA TPDU RJ TPDU ERR TPDU
connection request TPDU connection confirm TPDU disconnect request TPDU disconnect confirm TPDU data TPDU expedited data TPDU data acknowledge TPDU expedited acknowledge TPDU reject TPDU error TPDU
187
TPDU fields LI CDT TSAP-ID DST-REF SCE-REF EOT TPDU-NR ED-TPDU-NR YR-TU-NR
length indicator credit tra.nsport service access point identifier destination reference source reference end of TSDU mark DT TPDU number ED TPDU number sequence number response
Timer variables TI N L T-WAIT
I W
elapse time between retransmissions the maximum number of retransmissions bound for the maximum time between the decision to transmit a TPDU and the receipt of any response relating to it maximum time for a reassignment to take place before TC failure is assumed inactivity timer -- maximum time allowed to elapse between receipt of TPDUs before TC failure is assumed window timer-- maximum interval between transmission of up-to-date window information
Transport service The layer 4 standards have been designed in accordance with the ISO OSI model 3, and in particular, knowledge of Section 7.4 of this reference, 'The transport layer', is assumed. The general characteristics of the transport service (TS) are as follows.
Network independence No restrictions shall be communications medial of the ISO OSI model protocols at the lower transport service.
placed upon the underlying Providing that the principles are adhered to, changes in layers must not affect the
Cost optimization The transport service shall endeavour to balance the use of communications resources with the requirements of the transport service users (TS users). End-to-end significance The transport service has end-to-end significance, and any relay functions existing between the end users shall be transparent to this layer. Error control The users of the transport service can assume errorfree information exchange. Only major errors such as total network failure shall be signalled to the network service users Transport information exchange The transport service has no requirement to understand the format or structure of the user information being exchanged, whether it be data or control information.
188
User addressing The transport service uses a system of addressing which is mapped onto the addressing scheme of the supporting communications medium. Thus, transport addresses can be used by the TS users to refer unambiguously to one another without regard to physical locations. The transport service defines a set of service primitives for the purpose of establishing and terminating a connection, as well as exchanging data. It is from these transport service primitives that the detailed structure of specific interface primitives such as transport protocol data units (TPDUs) results, although in principle a variety of transport layer protocols could be designed upon the same set of service primitives. These interface primitives may well be affected by local operating conditions, such as operating systems and language restrictions. Thus, such interface primitives, while described in detail below, are not suitable for a general description. Neither is there necessarily a one-to-one correspondence between transport service and interface primitives. The transport service provides a delivery of transport service data units (TSDUs) to the TS users via transport connections (TCs) established between pairs of transport addresses identifying the corresponding TS users. These TS users are provided with the means to establish, maintain and terminate TCs which represent a full duplex data path between them. The transport service also defines grades of quality-of-service, which may be selected on a per-connection basis. This quality-of-service is defined in terms of parameters such as transit delay, residual error rate and throughput. The TS primitives and their parameters for TC establishment, data transfer and TC release are shown in Table 1. Figure 2 shows these TS primitives applied to the transport connection end points (TCEPs) as timesequence diagrams. Figure 3 shows the state transition diagram for the allowable sequence of TS primitives at a TC end point.
Protocol mechanisms A brief description is given below of some of the more characteristic transport protocol mechanisms. The ISO standard 6'7 defines 24 different protocol mechanisms, but in this discussion, related mechanisms are discussed as a group. See also Table 2.
Transport protocol data unit (TPDU) transfer The TPDUs (control and normal) are listed in Table 3. These are used by all classes, and are conveyed using network service data unit (NSDU) parameters of the network service primitives 8, primarily with N-data (network data) but also with N-expedited (network expedited) primitives.
Connection establishment, termination, reassignment and acknowledgement Creation of a new TC is established by use of CR and CC TPDUs. A variety of mandatory fields (e.~ source/ destination reference (SCE/DST-RFF), initial credit
computer communications
T - CONNECT request
request
D w
I
.~.~
T - DISCONNECT indication
Tindication - DISCONNECT
J T - DISCONNECT request
T - EXPEDITED DATA request
T - DATA request
T - EXPEDITED DATA indication
T - DATA indication Expedited data transfer ( user option )
Normal data transfer
T - DISCONNECT indication
TC release initiated by TS user
T - DISCONNECT request
T - DISCONNECT request
T - DISCONNECT request
Rejection of TC establishment request by TS provider
Rejection of TC establishment request by TS user
Successful TC establishment
T - DISCONNECT indication
/V
N T - DISCONNECT indication
TC release initiated by both TS users
Figure 2.
T - CONNECT request
T - CONNECT indication T-'DiSCONNECT request
T - CONNECT indication T - CONNECT response T - CONNECT confirm
~
T - DISCONNECT indication
TC release initiated by TS user and TS provider
TC releaseinitiated by TS provider
Transport service primitive time sequence diagrams 5
T - DISCONNECT ~
reou.,
Idle T
.T - D I S C O N N E C T / /
J~
T - DISCONNECT
\\
eoue.t ~
r ~, DISCONNECT
confir~
T - CONNECT I T - CONNECT
T -- DATA T - EXPEDITEDDATA primitives
Figure 3. State transition diagram for allowable IS primitive sequences
vol 7 n o 4 a u g u s t 1 9 8 4
a l l o c a t i o n (CDT), p r e f e r r e d / a l t e r n a t i v e p r o t o c o l ) a n d o p t i o n a l fields (e.g. c a l l i n ~ c a l l e d t r a n s p o r t services access p o i n t identifiers (TSAP-I Ds), T P D U size, s e q u e n c e n u m b e r length, user data, c h e c k s u m , a c k n o w l e d g e m e n t t i m e , quality-of-service, security, v e r s i o n n u m b e r ) are s p e c i f i e d . T h e p r o c e d u r e for TC e s t a b l i s h m e n t f o l l o w s t h e p r i n c i p l e of V C e s t a b l i s h m e n t in X.25; h o w e v e r , b e f o r e s e n d i n g t h e CR T P D U , t h e s e n d e r assigns t h e TC t o o n e o r m o r e n e t w o r k c o n n e c t i o n s a n d it is o v e r this set o f n e t w o r k c o n n e c t i o n s t h a t T P D U s are sent. D u r i n g this phase, i n f o r m a t i o n n e e d e d b y t r a n s p o r t e n t i t i e s is e x c h a n g e d o r n e g o t i a t e d w i t h a p p r o p r i a t e parameters. If a TC c a n n o t b e a c c e p t e d , t h e c a l l e d e n t i t y r e p o n d s w i t h a DR T P D U , i n d i c a t i n g t h e reason a c c o r d i n g l y . H o w e v e r , n o r m a l d i s c o n n e c t i o n is carried o u t b y use of DR a n d D C TPDUs, t h e c o m b i n a t i o n d e p e n d i n g u p o n t h e class selected. S p u r i o u s DR T P D U s r e c e i v e d w h e n a TC d o e s n o t exist are c o n f i r m e d w i t h TC TPDUs. When a network connection to which a target c o n n e c t i o n ( s ) has b e e n assigned n o l o n g e r exists, t h e
189
Table 1.
Transport service primitives s
Phase
Service
Primitive
Parameters
TC establishment
TC establishment
T.CONNECT request
(Called address, calling address, expedited data option, quality of service, TS user data) (Called address, calling address, expedited data option, quality of service, TS user data) (Quality of service, responding address, expedited data option, TS user data) (Quality of service, responding address, expedited data option, TS user data)
T-CON N ECT indication T-CON N ECT response T-CON N ECT confirm
Data transfer
Normal data transfer Expedited data transfer*
TC release
TC release
T-DATA request T- DATA indication T-EXPEDITED-DATA request T-EXPEDITED-DATA indication
(TS (TS (TS (TS
T-DISCONNECT request T-DISCON N ECT indication
(TS user data) (Disconnect reason, TS user data)
user user user user
data) data) data) data)
*User option: provided only upon TS user request TC(s) can be assigned to other network connections. Reassignment following resynchronization is carried out with a RJ or retransmitted CR or DR TPDU. Copies of CR, CC, DR, DT and ED TPDUs are retained to permit later retransmission in the event of loss of the originals. As each of these TPDUs is acknowledged, either explicitly or implicitly, the copy can then be released.
TPDU length, segmenting and concatenation A transport entity can map a transport service data unit (TSDU) onto one or more DT TPDUs, where the data field of these DT TPDUs contains any number of octets, up to an agreed maximum. Control TPDUs may contain user data, depending upon the class of operation. Also, the length of the TPDU is specified in the header, meaning that any number of control TPDUs, not containing user data, can be concatenated with a single control TPDU containing user data or a single DT TPDU. These TPDUs may be the same or different TCs. This mechanism provides for greater efficiency of the TC.
Data TPDU numbering In accordance with layers 2 and 3 of the ISO OSI model, all DT TPDUs are numbered so that sequencin~ recovery and flow control can be implemented. Each DT TPDU contains a sequence number, 'TPDUN R'. These are then compared with the' next expected TPDU-NR' by the end transport entities. Two numbering methods are in use: • normal - - 7 bit, providing for modulo 2 7 arithmetic, • extended - - 31 bit, providing for modulo 231 arithmetic. The first bit of the TPDU-NR field (normal and extended) is used as an 'end of transport service data
190
unit marker' (EOT) to specify the end of a TSDU sequence. Similarly bit 5/octet 3 of an X.25 data packet is used as an M (more data) bit, and bit 5 of the control byte in HLDC may be used as an F(final) bit.
Expedited data (ED) transfer A DT TPDU which is not subject to queueing, resource restrictions or any other impediment to its rapid delivery is known as an ED TPDU. Subsequent ED TPDUs in each direction may not be transmitted until the first ED TPDU has been acknowledged with an EA TPDU. They could be used to convey network functions, such as X.25 interrupt and interrupt confirmation packets.
Multiplexing, splitting and recombining Several TCs may share one network connection simultaneously. This mechanism provides for more efficient use of the networks's resources but is only used in classes 2, 3 and 4. Classes will be described in a subsequent section. Every TPDU must carry the DSTREF to identify the TC to which it refers. Class 4 provides an option whereby a TC can be assigned to multiple network connections for the purpose of security and reliability. Providing that the supporting network connections have similar transit delays, the TPDUs may then be sent over any of the assigned network connections. The TPDUs must then be resequenced on arrival.
Explicit flow control Sometimes it is desirable to regulate the flow of DT TPDUs independently of the layer 2 and 3 flow-control mechanisms. This is carried out by control of the credit mechanism (octet 3 of CR, CC, AK and RJ TPD Us) but is only available in classes 2, 3 and 4.
computer communications
Table 2.
Transport protocol mechanisms and classes for which they apply 1'6
Function
Protocol mechanism
Establishment phase TC-establishment
TC- rejection
0 Transport/network address mapping Assignment to network connection Connection by CR, CC, TPDUs Termination by DR TPDU Termination by DR, DC TPDU
Negotiation of option Protocol class TPDU size Extended sequence nr. Flow control Use of expedited TSDUs Checksum Receipt confirm Use of network expedited data Transfer of user connection data Alternative protocol class
Fixed part of CR, CC TPDU (bits 5-8) Variable part of CR, CC TPDU Fixed part of CR, CC TPDU (bit 2) Fixed part of CR, CC TPDU (bit 1) Variable part of CR, CC TPDU Variable part of CR, CC TPDU Variable part of CR, CC TPDU Variable part of CR, CC TPDU CR, CC TPDU user data field (max 32 octets) CR, CC TPDU
Release phase TC release Transfer of user disconnect data
Termination by DR, DC TPDUs DR TPDU user data field (max 64 octets)
Data Transfer phase Optimization of network connection Segmenting Data Transfer
Data flow control
Expedited data transfer Expedited data flow control Error detection of
Error recovery from
TPDU loss TPDU corruption TPDU duplication TPDU misordering Protocol error Unsignalled network break TPDU loss TPDU corruption TPDU duplication TPDU misordering Protocol error Network reset Network disconnection Unsignalled network break
Class
Concatenation Multiplexing using TPDU destination reference Splitting using TPDU reordering Delimination by TPDU EOT field Use of DT TPDU no numbering normal numbering (7 bit) extended numbering (31 bit) Use of credit fields Normal numbering (7 bit) Extending numbering (31 bit) Window reduction ED, EA TPDUs EA TPDU
2
3
X
X
X
4 X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X --
X --
X --
X
--
X
X
--
X
--
X
X
X
X
--
X
X
X
X
--
X
X
X
X
--
X
X
X
X
--
X
X
X
X
X
M
x
x
X
X
X
X
x
M
M
M
A
A x M A
A x M A
X X X
-M
M A --
TPDU NR field Time out TPDU checksum parameter TPDU NR field TPDU NR field TPDU type field checking Activity time-out, transmission of AK TPDU while inactive Retransmission request by RJ TPDU Retransmission on time-out TPDU discard, recovery from loss TPDU discard TPDU NR field Error notification by ERR TPDU Retransmission request by RJ TPDU Retransmission on time-out Reassignment of network connection, retransmission request by RJ TPDU Reassignment of network connection, retransmission on time-out Reassignment of network connection, retransmission on time-out
1
--
X
X
x
x
x
M
M
x
M
x
x
M
X
M
X
X
X
X
X
X
X
X
X
X
m
X
M X
x X
x --
X X
X --
X X
X --
X --
X
--
X
--
x
Key: x, always provided; --, never provided; M, mandatory option; A, additional option; f, for further study
vol 7 no 4 august 1984
191
Table 3.
the same network connection, they too must be treated as though a network-signalled error had occurred.
Transport protocol data units Mnemonic Control Data
TPDU name Connection request Connection confirm Disconnect request Disconnect confirm Data Expedited data Data acknowledge Expedited acknowledge Reject TPDU error
Protocol errors
CR CC DR DC
Any TPDU received which cannot be handled by the previously described mechanisms constitutes a protocol error. Such violations of the class rules might result from w i n d o w errors, sequencing errors, incorrect formats etc. The error is signalled to the sending end by an ERR TPDU, which contains the offending TPDU up to and including the first octet where the error was detected. Action by the sender is not specifically defined by the protocol, but it would be appropriate to:
DT ED AK EA RJ ERR
• correct the error and retransmit if possible, • close down the connection and report to the upper layers; in any case, the receiving end would temporarily 'freeze' the connection.
Timeout Procedures for retransmission on timeout are designed to be used in class 4 to cope with unsignalled loss of TPDUs by the network. If acknowledgement of a TPDU is required and yet not received within time T1, then up to N-1 retransmissions will occur, after which a DR TPDU is transmitted and the TC closed down for a minimum period of time L No specific values for these parameters are given in the standards, although suggestions are made on how to calculate appropriate values.
DESCRIPTION
A class defines a set of functions, and five classes are defined, so that the user can select the one which best fits the required quality-of-service. The intention was to develop the standards such that each lower class would be a subset of the functions of the next higher class, although the standards have not entirely turned out this way. During connection establishment, classes and options within classes may be negotiated by use of CR and CC TPDUs. For example, the requestor can state a preferred class, followed by a range of alternatives in order of preference. Also, the requestor may propose a maximum DT TPDU size, and if the receiver does not accept this size it can be negotiated downwards as far as the default length of 128 octets. In general, the receiver will accept the proposed option or indicate refusal in the CC TPDU. Most options have default values which depend upon the class to which they apply; for example:
Checksum The purpose of the checksum algorithm is to detect corruption of TPDUs, and it is primarily intended for use in class 4, where there is likely to be a high residual error rate. When a TPDU is transmitted on a TC for which the checksum option parameter has been selected, the following checksum algorithm is used. The TPDU is set up with the checksum octets (X and Y) set to zero. Temporary variables CO and C1 are initialized to zero. For each octet of the TPD U from I to L (see Figure 4) add the octet value to CO, and then add CO to C1. All addition is performed modulo 255. The values of the checksum octets, X and Y, are then calculated according to equations (1) and (2) respectively, where the first octet (X) becomes the nth octet of the TPDU. X = (((L -- n)*CO) - C 1 ) modulo 255 Y = (((L -- n + 1)*(--CO)) +C1) modulo 255
• use of the checksum parameter is the default for class 4, while nonuse is the default for other classes, • use of the flow-control option is the default for class 2, • extended header format provides four octet sequence numbers and two octet credit allocations for classes 1-4; its nonuse is the default.
(1) (2)
A simpler implementation may use one's complement arithmetic instead of modulo 255. However, if either X or Y end up with the value - 0 , then it must be converted to 4-0 before being stored in the checksum parameter. The same algorithm is used to compute the checksum at the receiving end. If checksum failure occurs, it is not possible to determine the TC to which the faulty TPDU relates, since the reference field itself may have been corrupted. Hence, if other TCs are multiplexed onto 1
2 3 4
F,x pa
k
k+l
I
Parameters which do not have default values must be specified in both CR and CC TPDUs. A classification of network services in terms of quality-of-service, with respect to error behaviour, has been developed. Its main purpose is to provide a basis for the selection of an appropriate class for a particular TC in association with a given network connection.
n
V0riab'epa
I
n+l
x
OF C L A S S E S
I
•
Y
m
I
-,y
p
J /
p+l
L
Data field
]
Checksum parameter
Figure 4.
192
TPDU showing two octet checksum parameters
computer communications
A--network connection with acceptable residual error rate (for example not signalled by 'clear' or 'reset') and acceptable rate of signalled failures. • Type B ~ as for type A, but unacceptable rate of signalled failures. • Type C - - network connections with residual error rate not acceptable to the TS user. • Type
Table 2 provides a summary of the transport protocol functions and mechanisms applicable to each of the five classes.
Simple class (class O) This class provides the most basic form of TC. As such, it has few of the more sophisticated features available in some of the other classes. It has been defined by CCITT (S.70) and used to specify teletex networking. This class only provides the facilities for connection establishment, data transfer with segmenting and treatment of protocol errors. There are no facilities for multiplexing, flow control, error recovery or expedited data transfer. It is intended to be used for type A network connections.
Basic error and recovery class (class 1) This class provides a TC with minimal overhead. It functions like class O, but can recover from network disconnections without involving the end users, and is primarily designed to be used for type B network connections. In particular, it provides facilities for connection establishment/disestablishment, normal and expedited data transfer, error recovery and flow control.
Like class O, there are no facilities for error recovery, but user data may be appended to CR, CC and DR TPDUs in the same way as up to 16 octets of user data can be optionally incorporated into an X.25 call request packet.
Error recovery class (class 3) This class provides the facilities of class 2, with the ability to recover from errors generated by network disconnection and resetting without involving the TS users. This class would be selected where both multiplexing and reliability were required, and would be used for type B network connections. When an error is signalled by the network layer, RJ TPDUs are exchanged with sequence number response fields (YRTU-NR) set to the next expected TPDU. This may then be followed by exchange of previously transmitted DT TPDUs, in order to restore the required sequence.
Error detection and recovew class (class 4) Class 4 provides the facilities of class 3, along with mechanisms to detect TPDU errors resulting from a low-grade network service. The types of errors which can be detected include lost, duplicated, out-ofsequence and corrupted TPDUs (control and data). Error detection is implemented by extending the use of sequence numbering to certain control TPDUs and their acknowledgements, as well as DT TPDUs. A variety of time-out and retransmission mechanisms are also used. Use of the checksum enables detection and retransmission of damaged TPDUs.
S T R U C T U R E A N D E N C O D I N G OF T P D U s Multiplexing class (class 2)
Basic structure
The aim of this class is to provide a method of multiplexing several TCs over one network connection, and it is intended to be used for type A network connections. Flow control is optional, but is 'explicitly' used with heavy traffic when performance (e.g. response time) must meet specific standards. Where there is endpoint congestion, perhaps caused by intensive multiplexing, then flow control is desirable. Without flow control, multiplexing is still possible, but the performance of the network cannot be guaranteed, and this option is more appropriate for dumb terminals where minimal overhead is desirable and where network connection utilization is low. When flow control is used, a credit mechanism exists for allowing the receiving station to set up a receive window. Expedited data is only available with explicit flow control. Care must be taken that nonuse of flow control does not delay traffic on other multiplexed channels, thus forcing flow control back to the network layer. I
LI
I_ I Figure 5.
I
Fixedpart
I
Header field
Variablepart
I
All TPDUs consist of a header followed by an optional data field. The header comprises the length indicator field (LI), a fixed part and an optional variable part. The LI field contains a length of the fixed and variable parts of the header, (see Figure 5). TPDUs are of two basic types. used to control transport protocol functions and in particular for setting up and clearing down a TC in a similar manner to the way in which X.25 sets up a VC by way of call establishment/ cleardown. However, unlike X.25, classes of service can be negotiated during the TC set-up phase. The control TPDUs are CR, CC, DR, DC as well as RJ and ERR. • D a t a - - may be of two types; normal (DT, AK) and expedited (ED, EA). • Control-
TPDU names, code and classes to which they apply are shown in Table 4.
Data field
I
~i I
TPDU structure
vol 7 no 4 august 1984
193
Table 4.
Summary of T P D U names, codes and classes 6
Classes 0 CR connection request CC connection confirm DR disconnect request DC disconnect confirm DT data ED expedited data AK data acknowledgement EA expedited data acknowledgement RJ reject ERR TPDU error
x x x x
x
1
Code 2
3
4 (bits 8-5, octet 2)
x x x x x x x x x x x (2) (3) (2) x (2) x x x
x x x x x x x x x x
x x x x x x x x
1110xxxx 1101xxxx 10000000 11000000 11110000 00010000 0110xxxx(1) 00100000 0101xxxx (1) x 01110000
xxxx (bits 4-1) used to signal the credit allocation (CDT) (1) In extended header format, the code for AK = 01100000 and the code for RJ= 01010000 (2) Not available when nonexplicit flow control option is selected (3) Not available when receipt confirmation option is selected
• TPDU sequence numbering is discussed in association with specific TPDU structures (see below).
Fixed part
fixed part of the TPDU contains frequently occurring functions, including the TPDU code (bits 85, octet 2). The length and structure of the fixed part is specific to each TPDU. The most common fields are as follows. The
• The initial credit allocation (CDT) field (bits 4-1, octet 2: CR, CC, AK, RJ TPDUs only) is not significant for classes 0 and 1, but for classes 2-4 it shall contain the number of DT TPDUs which are allowed by the 'window allocation'. This means that the receiver may inform the sender of the amount of data he is willing to receive. • The source reference (SCE-REF) field (octets 5-6: CR, CC, DR, DC TPDUs only) contains the reference (address) selected by a control TPDU to identify the source end of the TC. • The destination reference (DST-REF) field (octets 34:, CC, DR, DC, DT, ED, AK, EA, R], ERR TPDUs), is the same as the SCE-REF, but identifies the destination end of the TC. • The class field (bits 8-5, octet 7: CR, CC TPDUs only) specifies the preferred protocol class required for the TC. However, if this is not available, choices of 'alternative protocol classes' may optionally be specified as a parameter in the variable-field part of a control TPDU (see Table 5). • The options field (bits 4-1, octet 7: CR, CC TPDUs only) comprises the second half of octet 7, which is reserved for the specification of standard options to be made available as part of the requested TC for classes 1-4. In particular, normal/extended format (bit 2) and optional flow control for class 2 (bit 1) can be specified. Table 5.
194
Class encoding
Class
Bits 8-5, octet 7
0 1 2 3 4
0000 0001 0010 0011 0100
Variable part
The variable part of a TPDU is optional, specify parameters relating to optional similar fashion to specifying optional X.25 call establishment packets. The consists of:
and is used to functions in a parameters in format always
• parameter code (1 octet), • parameter length (I octet), • parameter value (octet 3 on). Bits 8-7 of the parameter code are always used to indicate the source of the definition, e.g. 01 --CCITT, 1 0 - - ISO, 11 - - common to CCITT and ISO. The following parameters can be used in the variable part of various TPDUs. the exception of class O, all TPDUs may have checksums, used as the default option for class 4. The specific algorithm has already been discussed. • Transport service access p o i n t identifiers (TSAP119) - - these parameters are used to specify the calling and called access points. • T P D U s i z e - - this parameter proposes the maximum size of the data units to be used over the requested TC (see Table 6). • Version n u m b e r - - where different versions of the transport protocol are available, the preferred version can be specified. It is not used with class 0 and defaults to 00000001. • Checksum--with
Table 6.
T P D U size coding
Length (octets) Bit pattern 8192 4096 2048 1024 512 256 128
00001101 (except classes 0 and I) 00001100 (except classes 0 and 1) 00001011 00001010 00001001 00001000 00000111
computer communications
TPDU encoding
• S e c u r i t y - - this allows the user to identify security •
•
•
•
•
•
•
information. It is not used with class 0. Alternative p r o t o c o l c l a s s - the TS users may request use of alternative classes if the one specified in octet 7 of CR and CC TPDUs is not available. They must be specified in order of preference, according to Table 5. It is not used with class 0. A d d i t i o n a l o p t i o n s - - a selection of options, such as use of network expedited data (class 1), receipt of confirmation (class 1), checksums (class 4) and expedited TSDUs can be specified in the class options octet. A c k n o w l e d g e t i m e - - this parameter indicates the maximum acknowledge time to the remote end. It may be specifying during connection establishment in CR or CC TPDUs, but is an indication only and not subject to negotiation. If not specified, it may be assumed to be insignificant in comparison with transit delay. T h r o u g h p u t - these parameters specify the minimum and target throughput speed (octet/s) for both the called-calling and calling-called user directions. Residual error rate - - these parameters specify the minimum and target residual error rates for a specified TSDU size. P r i o r i t y - - t h i s parameter contains user-specified integers which define the relative importance of the TC with respect to the order in which the connection is to have its quality-of-service degraded, or even broken if it becomes necessary to recover resources. Transit d e l a y - - these parameters specify the target and maximum acceptable transit delays (ms) for both the called-calling and calling-called user directions.
The full structure of the establishment and release TPDU formats are shown in Figure 6. All fields have been previously defined, with the exception of octet 7 of the DR, which merely specifies the reason for disconnection in a similar fashion to the way in which a clearing cause field is specified in an X.25 clear request/indication packet; for example, normal disconnection, remote congestion, connection negotiation failed, duplicate address, connection request refused, parameter mismatch etc. More specifically, for teletex (class 0), the following values have been defined by the CCITT: 1 0 0 0 0 0 0 0 - - n o r m a l disconnection (no specified reason), 10000001 - - terminal occupied, 1 0 0 0 0 0 1 0 - terminal out of order, 10000011 - - address unknown. The structure of the normal data TPDUs, including those for acknowledgement and rejection, are shown in Figure 7. For classes 0 and 1, no parameters can be spe~cified in the variable part of the header field. The EO~- bit indicates whether the DTTPDU is the last data uni~of the sequence or not. For AK, EA and RJ TPDUs, EO~,= 0, and for ED TPDUs, EOT = 1. The TPDU-NR field contains the sequence number of the DT TPDU, but it has no significance in class 0 or for class 2 without explicit flow control. A similar definition applies to the ED TPDU-NR field. The YR-TU-NR field contains: • the sequence of the next expected DTTPDU forAK format, • identification of the ED TPDU being acknowledged for EA format, • the next expected DT TPDU for which retransmission should occur for RJ format.
Data field This field contains transport user data, and may be attached to CR, CC, DR, EA and DT TPDUs, with restrictions on length and classes as follows:
Extended number format options provide for a 31 bit sequence number field (octets 5-8) in DT, ED, AK, EA and RJ TPDUs, and a 2 octet credit allocation field in AK and RJ TPDUs (see Figure 8). The ERR-TPDU format is shown in Figure 9 and contains a 'reject cause' octet, specifying invalid parameter code, parameter value or TPDU type. The contents of the rejected TPDU, up to and including the octet which caused the rejection, is specified in the variable part of the header field.
• CR, CC not permitted for class 0, otherwise--< 32 octets, • DR not permitted for class 0, otherwise-< 64 octets, • EA not permitted for class 0 or class 2 without explicit flow control, otherwise _< 16 octets, • DT length restricted only by maximum TPDU length selected during connection set up.
1
2
1"
LI
ICR ICDT[ 0
I
L. Icc lcoTI
L
LI
3
4 0
0
6
7
8
p
p+l
l
SCE-REF
osT-.EF
I
SCE-.EF
I C,a.s,o0t,ons I
Var,ab.epa I
Userda.a I
IDR I 0 I
DST-REF
[
SCE-REF
I
Reason
I
Variablepart I
Userdata
l
I°cl°l
osT.EF
I
SCE.EF
I
Variablepart
I
Figure 6.
Establishment and release TPDU formats 7
vol 7 no 4 august 1984
0
5
!
195
E 0
1
,,
2
T
3
o~! o i i ~.oo-.. 4
I
( Specific to claues 0 and 1 only )
1
2
•,
o~1o I
o~-.~
I
TPDU-NR
•,
EOIo I
osr-R,~,=
I'
'~°-rP°"-"RI
,,
I'.,~Ico, I
.,ST-RE,=
Io
,',=,- r,., - ,,,,., I
,,
E,,iol
osr_R,=,=
Io
YR-,O-,,,R
L,
RJIcoTI
OSTREF
I0
YRTO-NRI
Figure 7.
3
User data E O T
5
6
I
p
p+l
Variablepart I
User data
Var,ab,eo.,,t I
U~rO,,ta
t
Var,ab,eo,,r, I
I V,,ri,,b,e,,.,r,
I
Var,ab,.0..
Normal data reject TPDU formats
E
2
1
I"
3
4
-~ 5
I°~1°1
°~-~
II
6
7
8
~°°-~
9
I
p
I
User data
Variab,e~a~ I
O~r~.t.
v'"'~'e~'~
i
L,
iEol01
osT-REF
IllEo-TPOO-N~I
!
LI
IAK I 0 I
DST-REF
10 I Y R - T U - N R
ICDTI
I
LI
lEA I 0 I
DST-REF
]0 I Y R - T U - N R
I
I"'1°1
osr-,E,=
Iol
Icorl
I" Figure 8.
I
2
LI
IERRI 0 I
3
4
DST-REF
5
I
Rejectcause
Variablepart
I
]
V.ria,,,eo.rt
I
6
I
p
Variablepart
I
Error TPDU format
CONCLUSION
Transport layer standardization has now reached a point where designers and implementors can select a preferred quality-of-service. Already class 0 has been adopted in the form of CCITT S.70 for teletex networking. X.25 based packet switching networks lack full end-to-end significance, and the transport protocol has the ability to provide a secure connection to cope with problems such as lost packets resulting from virtual circuit resetting or cleardown. At the other
196
Variablepart
1
Extended data and reject TPDU formats
1
Figure 9.
~,~-ro-,,,,.,
p+l
extreme, developments in local area network technology require connection oriented and connectionless services, for which the error detection and recovery facilities of class 4 are ideal. REFERENCES
1
yon Studnitz, P'Transport protocols: their performance and status in international standardization' Comput. Net. Vol 7 (1983) pp 27-35
computer communications
2
3
4
5
Knightson, K G 'The transport layer' Comput. Commun. Rev. Vol 12 No 3/4 (July/October 1982) pp 14-23 Reference model of open system interconnection - - D r a f t Revised Recommendation X,200 CCI]-I-, Switzerland (July 1983) Standard ECMA-72 Transport Protocol 2nd Ed, ECMA, USA (September 1982)
6 7
Transport service d e f i n i t i o n - Draft Recommendation X.214 CCITT, Switzerland (June 1983) Transport protocol s p e c i f i c a t i o n - Draft Recommendation X.224 CCITT, Switzerland (June 1983) Alternative text for the transport protocol ISO/ TC97/SC16 N1297, ISO, Switzerland (December
1982) 8
Network service definition - - Draft Recommendation X.213 CCITT, Switzerland (June 1983)
Corrisendum The authors of the paper 'Computer network capacity in robotic neural systems',published in the April 1984 issue,would like to point out that the first line of the right hand column on page 87 should read: k
T. Coi
where 0_
i=1
Co
>0
the quarterly international journal for practitioners in computer performance, evaluation and tuning Coverage: • • • • •
measurement applications measurement technology analytic methods measurement notes design techniques
• •
modelling techniques capacity planning
• •
performance theory product descriptions
For further details please contact: Sheila King Butterworth Scientific Limited PO Box 63 Westbury House Bury Street Guildford SurreyGU25BH Telephone: 0483 31261 Telex: 859556SCITECG
vol 7 no 4 august 1984
197