The drawings contained in this Recommendation have done in Autocad
Recommendation T.70
NETWORK–INDEPENDENT BASIC TRANSPORT SERVICE FOR THE TELEMATIC SERVICES
(Geneva, 1980, amended at Malaga–Torremolinos, 1984,
and Melbourne, 1988)

The CCITT,
considering
	(a)	that the Teletex service will be introduced in different types of network, i.e. circuit–switched public data networks (CSPDN), packet–switched public data networks (PSPDN) and the public switched telephone network (PSTN);
	(b)	that there is a need for international interworking  between terminals belonging to the same or different types of Telematic services;
unanimously declares the following view
1	Scope
1.1	This Recommendation defines the network–independent basic transport service applicable to Teletex and Group 4 facsimile terminals connected to the types of network mentioned in (a) above in terms of:
a)	the transport services provided to the higher layer [the transport services are provided by the transport layer (layer 4) in association with the underlying services provided by the supporting layers 1 to 3];
b)	the transport layer procedure (see § 5 below).
1.2	Paragraph 2 describes the transport service. Paragraph 3 describes the transport service implementation for different types of networks. Paragraph 4 outlines the guidelines for interworking between networks. Paragraph 5 specifies the transport layer procedure, and Annexes A and B provide associated state transition diagrams and tables respectively.
2	Transport service
2.1	Transport service objectives
2.1.1	The purpose of the transport service is to provide two communicating session entities within two terminals with transport services, i.e. the means for transparent and reliable end–to–end transfer of data between them irrespective of the particular type of network used.
2.1.2	The main requirements of the transport service to be provided by a transport entity to the local transport user, i.e. the session entity, are:
a)	Network independence. The transport service shall be homogeneous, while allowing a suitable wide variety of underlying communications media, protocols and mechanisms.
b)	End–to–end significance. The transport service shall have end–to–end significance, connecting the end users irrespective of the number of individual communication links used.
c)	Transparency. The transport service shall be octet transparent, i.e. not restrict the content, format or coding of the information (data or control) received from or delivered to the transport user.
d)	Error–free delivery. The transport service shall assure error–free delivery. Non–recoverable errors are to be visible to the transport service user.
e)	Cost efficiency. The transport service shall optimize the use of the available communication resources to provide the performance required by each communicating transport user at maximum efficiency.
2.2	General structure of the transport service
2.2.1	The general structure of the transport service is shown in Figure 1/T.70.
3	Transport service implementation for different types of networks
	Note – The transport layer procedure on all types of networks is defined in § 5. The network dependent control procedures of the underlying layers are described in the following.
3.1	Terminals connected to a PSPDN
3.1.1	Physical layer DTE/DCE interface characteristics
	The physical layer of Recommendation X.25 applies.
3.1.2	Link layer procedure
	The link layer procedure shall, unless otherwise specified, be the symmetrical procedures as specified in Recommendation X.25, LAPB (Link Access Procedure B).

Fig. 1/T.70 T0803680–89 = 20 cm

3.1.3	Network layer procedure
	Recommendation X.25 Virtual Call procedures apply. However the following points should be noted when using this transport protocol:
a)	The qualifier bit in data packets should always be set to 0.
b)	The delivery confirmation bits in all packets should be set to 0.
c)	The terminal should not send an interrupt request packet.
d)	Normal X.25 reset procedures will apply.
e)	Each control block or data block of the transport layer shall be carried in a complete data packet sequence.
f)	The terminal should not send a DTE REJ packet.
g)	Terminals shall use a specific protocol identifier within call request/incoming call packets for the Teletex service and Group 4 facsimile apparatus. This identifier is represented by the first octet of the call user data field (remaining octets, if any, should be ignored) as shown below:
bit		87654321
octet 1	00000010
In the case of CSPDN/PSPDN interworking the functional mapping of this protocol identifier requires further study.
h)	Terminals shall not use the fast select facility.
3.2	Terminals connected to the PSTN
3.2.1	Physical layer DTE/DCE interface characteristics
	The DTE/DCE physical layer element shall be in accordance with existing Series V Recommendations. The physical layer may provide for half–duplex or full–duplex transmission depending on the modem standard.
	Note – The PSTN modem standards are discussed in Study Group XVII. Furthermore, in the case of a modem integrated in the terminal, the interface may only be functionally equivalent to a Series V Recommendation. This is also for further consideration in Study Group XVII.
3.2.2	Link layer procedure
3.2.2.1	Depending on the service provided by the physical layer, the link layer procedures over a single physical circuit between two terminals have to cater for a half–duplex or full–duplex transmission facility to provide a full–duplex service to the network layer. For full–duplex physical layer service, the link layer procedure shall conform to the Link Access Procedure described in Recommendation X.75, for single link operation. For addressing assignments and the system parameters see §§ 3.2.2.2 and 3.2.2.3 respectively. For half–duplex physical layer service the link layer procedure is as defined in Recommendation T.71. This is a half–duplex Link Access Procedure, based on Recommendation X.75 for single link operation.
3.2.2.2	The following describes the application of the link addressing procedure of Recommendation X.75. Link addresses (A and B) shall be assigned dynamically or on a per–call basis according to the following rules:
a)	the calling terminal shall take Address A;
b)	the called terminal shall take Address B;
c)	commands and responses shall be transferred as shown in Figure 2/T.70;
d)	A and B addresses are coded as follows:
Address	12345678
  A	11000000
  B	10000000
	Note – The terminal will discard all frames received with an address other than A and B.

Fig. 2/T.70 T0803690-89 = 4 cm

3.2.2.3	System parameters are:
a)	timer, T1;
b)	maximum number of retransmissions, N2;
c)	maximum number of bits in an I frame, N1;
d)	maximum number of outstanding I frames, k.
	The above system parameters are to be specified by the Administration. However, the possible range of values that may be attributed to each parameter is to be standardized. Such values are for further study.
3.2.3	Network layer procedure
3.2.3.1	See § 3.1.3. In addition, for all calls (PSTN only, PSTN–PSPDN, PSTN–PSPDN–PSTN) second stage addressing will apply using X.25 virtual call procedures. The calling terminal should include the called address and the calling address (see Note 2) in call request packets. The format of the called address shall conform to:
a)	the telephone network addressing scheme for PSTN only calls;
b)	the telephone network addressing scheme with an X.121 DNIC for PSTN–PSPDN calls (see Note 3);
c)	the X.121 addressing scheme for PSTN–PSPDN calls (see Note 1).
	Note 1 – For other cases of internetworking the above rule shall apply.
	Note 2 – In the case of PSTN–PSPDN calls the verification of the calling address by the network requires further study. The format of the calling address is for further study.
	Note 3 – The feasibility of such connections is for further study.
3.3	Terminals connected to a CSPDN
3.3.1	Physical layer DTE/DCE interface characteristics
	The DTE/DCE physical interface characteristics shall be in accordance with Recommendation X.21, or as an option, Recommendation X.22 for multi–call operation.
3.3.2	Link layer procedure
3.3.2.1	General
	The link layer procedure shall be used during the data phase of Recommendation X.21 (or X.22) for data interchange over a single physical circuit between two terminals operating in User Classes of Services 3 to 7 and 30 as defined in Recommendation X.1. The link layer procedure shall consist of a fully symmetrical HDLC procedure as defined in Recommendation X.75 for single link operation.
3.3.2.2	Link layer address procedure
	The following describes the application of the link addressing procedures of Recommendation X.75. Link addresses (A and B) shall be assigned dynamically on a per–call basis according to the following rules:
a)	the calling terminal shall take address A;
b)	the called terminal shall take address B;
c)	commands and responses shall be transferred as shown in Figure 3/T.70;
d)	A and B addresses are coded as follows:
Address	12345678
  A	11000000
  B	10000000
	Note – The terminal will discard all frames received with an address other than A and B.
Fig. 3/T.70 T0801300-87 = 4 cm

3.3.2.3	Link layer implementation rules
	In order to achieve full compatibility between different implementations, the rules below for the implementation of Recommendation X.75 shall be followed.
3.3.2.3.1	General rules
a)	The 1984 version (Red Book) of CCITT Recommendation X.75, § 2, shall be used as the reference specification.
b)	The term “STE” shall be read as “DTE”.
c)	The Non–Extended mode of operation (modulo 8) shall be used.
d)	Only the single link procedure (SLP) shall be used.
3.3.2.3.2	Specific rules
	The following rules refer to the indicated sections and tables of Recommendation X.75.
a)	Table 1/X.75 (see Note 1)
I–frame must not be sent with an empty I–field.
N ³ 0
N £ N1 – 32
A received empty I–frame shall be treated as a valid I–frame.
b)	§ 2.3.4.9
Subparagraphs 5), 6) and 7) are not valid (shall not result in the sending of a FRMR). Instead the following actions shall be implemented:
–	Not expected supervisory frames with the F bit set to 1 shall be ignored.
–	Not expected UA or DM response shall be ignored.
–	Frames with an invalid N(S) shall be responded to by sending REJECT.
Frames with a FRMR cntrol field shall not be responded by sending a FRMR.
c)	Table 7/X.75
Bits W, X, Y and Z set to 0 indicate that no reason for frame rejection is given.

d)	§ 2.3.5.3
The DTE and the CSPDN are not octet aligned and the last paragraph is therefore not valid.
e)	§ 2.3.5.5
Higher layers should be notified when timer T3 expires (excessive idle state).
f)	§ 2.4.3
Related to the first paragraph, read instead of “next response” “corresponding response”.
g)	§ 2.4.4.1
In the active channel state, the DTE shall transmit contiguous flags independent of the other DTE.
The calling DTE shall initialize the link by sending a SABM command with the P bit set to 1.
h)	§ 2.4.4.4.1
A condition for entering the disconnected phase is also that no unacknowledged DISC command exists, because of collision cases (Ref. X.75, § 2.4.4.5).
In the disconnected phase, it is the calling DTE which may initiate link set up.
i)	§ 2.4.5.9, fourth paragraph
If a RNR is received, the DTE shall remain in the timer recovery condition (because the other DTE is still in the busy condition).
j)	§ 2.4.5.9, fifth paragraph
If a RNR is received, the DTE shall not resume I–frame transmission or retransmission.
k)	§ 2.4.5.9, last paragraph
If the transmission attempt variable is equal to N2, the DTE shall enter the disconnected phase.
l)	§ 2.4.7.3
In the frame rejection condition, the DTE shall only check the commands and react with a FRMR according to the P bit.
The frame rejection condition is cleared when the DTE receives a SABM, or, receives or transmits a DISC command.
m)	§ 2.4.7.3, second paragraph (see Note 2)
Only the DTE which caused the FRMR condition may try to reset the link.
n)	§ 2.4.7.3, third paragraph (see Note 3)
After N2 attempts to get the other DTE to reset the link, the DTE shall enter the disconnected phase.
o)	§ 2.4.8.1 (see Note 4)
The timer T1 shall be started at the end of frame transmission. The value of T1 depends on the data signalling rate, the frame length, the value of N2 and a fixed time of 1.5 s representing both T2 and the transmission delay [see § 3.3.2.3.2 r)]. The recommended value range is: 1.5–15 s.
p)	§ 2.4.8.2 (see Note 4)
T1 > T2
T2 £ 1 s
Depending on the acknowledgement strategy used, the DTE designer may regard T2 as a decision parameter only, in which case the DTE is not obliged to implement a corresponding timer.
q)	§ 2.4.8.3, second paragraph
30 s  T3  60 s
r)	§ 2.4.8.4
N2 × T1  60 s
s)	§ 2.4.8.5
N1 = 1080 + (n × 1024) bits; n = 0 or 1 or 3 or 7 or 15.
t)	§ 2.4.8.6 (see Note 4)
k = 2 – 7 (modulo 8)
Note 1 – Terminals complying with the Red Book version of Recommendation T.70 may react by DL Reset ind. (FRMR).
Note 2 – Terminals complying with the Red Book version of Recommendation T.70 may react differently.
Note 3 – It is not meaningful to reset the link if the other DTE is not responding for N2 × T1.
Note 4 – The acknowledgement strategy used by the receiving DTE should be independent of any knowledge about the value of k used by the sending DTE. This can be achieved by either acknowledging every correctly received I–frame as soon as possible or by implementing an acknowledgement timer, i.e., a T2 timer as defined above [see § 3.3.2.3.2 p)].
3.3.3	Network layer procedure
3.3.3.1	Call control phase
	The call control procedure conforms to Recommendation X.21, or as an option, Recommendation X.22 for multi–call operation.
3.3.3.2	Data transfer phase
	A minimal network layer is present during the data transfer phase and accommodated through the use of a two–octet network block header. The header comprises a one–octet length indicator followed by a network block type code specified below. The only network block currently defined is a network protocol data block as shown in Figure 4/T.70.
Fig. 4/T.70 = 9 cm

3.3.3.3	Data transfer procedure
3.3.3.3.1	Handling of the M–bit
	The calling DTE shall negotiate the TPDU size with the called DTE at the transport layer, based on either the maximum TPDU size supported or the optimum TPDU size for the specific call, unless the default value of 128 octets is used. The agreed value will allow the sending DTE to transfer TPDUs without the need for segmenting at the Network layer and consequently the M–bit is set to zero.
	However, receiving DTEs must always be capable of reassembling segmented TPDUs by using the M–bit, since segmenting may take place in the network in some interworking situations, e.g., when the composite network connection comprises a PSDN.
3.3.3.3.2	Error procedures
	A Data PDU with a length indicator different from hexadecimal “01” and/or with less than three octets shall be discarded and the physical network connection shall be cleared.
3.4	Terminals connected to an ISDN
	See Recommendation T.90.
4	Interworking between networks
4.1	It is the responsibility of Administrations to decide in which network(s) the telematic services are to be provided.
4.2	Four possibilities are considered below:
a)	Terminals connected to a circuit switched public data network (CSPDN);
b)	Terminals connected to a packet switched public data network (PSPDN);
c)	Terminals connected to a public switched telephone network (PSTN);
d)	Terminals connected to an integrated services digital network (ISDN).
4.3	Interworking between telematic terminals connected to any network must be possible.
4.4	International interworking between telematic terminals shall preferably take place between networks of the same type when these networks are provided by both countries involved.
4.5	In the case of international interworking between telematic terminals connected to dissimilar networks, Recommendation X.300 shall apply.
	The interworking between CSPDNs and PSPDNs is described in Recommendation X.82 (Detailed arrangements for interworking between CSPDNs and PSPDNs based on Recommendation T.70).
5	Transport layer procedure
5.1	Transport functions
5.1.1	General
5.1.1.1	The transport layer will perform all those functions that are necessary to bridge the gap between the services provided by the network layer and the services needed by the session layer. Therefore, the functions performed are dependent on two criteria: the services provided by the underlying network layer and the services required by the session layer.
5.1.1.2	It is the responsibility of the transport service user to select a given quality of service, which may imply the use of certain transport layer functions such as:
a)	establishment of a transport connection
–	transport connection identification
–	transport connection multiplexing;
b)	data transfer
–	sequence control
–	error detection
–	error recovery
–	segmenting and reassembling
–	flow control
–	purge;
c)	termination of a transport connection.
Note – Not all of the above functions will be available in the basic transport service (see § 5.1.3).
5.1.2	Transport protocol classes
5.1.2.1	Transport layer functions are grouped (for ease of negotiation) into a hierarchical system of transport protocol classes whereby classes occupying superior positions in the hierarchy implement functions of the lower classes together with the optional functions identified for their own class.
5.1.2.2	During transport connection establishment the use of a given transport protocol and optional functions should be negotiated according to the following rules:
–	the calling terminal indicates the transport protocol class and (if applicable) the optional functions required;
–	the called terminal indicates the transport protocol class and (if applicable) the optional functions that it is willing to support;
–	all parameters to be used in the transport connection must be explicity indicated, otherwise default values will apply.
5.1.2.3	The basic transport service described here is fulfilled by a protocol denoted in Recommendation X.224 as transport protocol class 0. That protocol class is compatible with Recommendation T.70. In the event of a discrepancy between transport protocol class 0 as described in Recommendation X.224 and Recommendation T.70, the latter takes precedence.
5.1.3	The basic transport service (TS)
5.1.3.1	A limited set of transport layer functions is defined for a basic transport service. The basic transport service is provided by transport layer functions which are performed by transport layer protocol elements.
5.1.3.2	Transport protocol data units (TPDUs) carrying transport service (TS) user information or control information are called blocks.
5.1.3.3	Transport layer block types are as follows:
a)	transport connection request (TCR) block;
b)	transport connection accept (TCA) block;
c)	transport connection clear (TCC) block;
d)	transport data (TDT) block;
e)	transport block reject (TBR) block.
5.1.3.4	The TCR and TCA blocks are used to indicate the protocol class, and optional functions, applying to a transport connection. The TCC block is used to indicate the reason for refusing a connection establishment. The TDT block carries information of the transport service user. The TBR block is used to report procedure errors to the remote terminal.
5.1.4	Transport layer functions
5.1.4.1	Basic class functions and associated transport layer protocol elements, i.e. blocks, include:
a)	transport connection establishment, transport connection identification, optional extended addressing and optional transport data block size negotiation (TCR, TCA and TCC blocks);
b)	data delimitation, segmentation/reassembling of arbitrarily long transport service data units (TSDU). These are contained within TDT blocks. The end of a TSDU is indicated by a TSDU end mark in the last data block;
c)	detection and indication of procedural errors (TBR block).
5.1.4.2	Other characteristics of the basic transport service are:
a)	maintenance of TSDU integrity;
b)	overflow: if the user cannot absorb new data and if the appropriate buffers are not available, flow control is performed at the network/link layer as appropriate;
c)	error: no mechanism is provided within the transport layer to facilitate recovery from detected errors. Where such errors are detected the user of the transport service should be informed so that appropriate recovery action may be taken.

5.2	Description of connection establishment and termination procedures
5.2.1	General
5.2.1.1	The transport layer connection establishment and termination procedures shall also be used for negotiating transport protocol class and, if applicable, optional transport connection functions.
5.2.1.2	For the basic transport service, means are provided to establish a transport connection using a TCR block and a TCA block. This exchange provides:
a)	a way to negotiate options;
b)	a transport connection identification. The transport connection is identified by use of cross–references. Each end of the connection is responsible for selecting a suitable transport connection identifier.
5.2.1.3	This mechanism also provides an identification of the transport connection independent of any network connection identification and therefore provides independence from the life of the network connection. The binary value 0 should not be used as an identifier. The use of such references for reconnection requires further definition.
5.2.2	Transport connection request (TCR) block
5.2.2.1	The calling terminal shall indicate a transport connection request by transferring a TCR block to the remote terminal. The TCR block includes the transport functions (e.g. source reference, class, and optional functions) for negotiation of the characteristics of the transport connection being established.
5.2.3	Transport connection accept (TCA) block
5.2.3.1	The called terminal shall indicate its acceptance of the transport connection by transferring a TCA block to the remote terminal. The TCA block includes the transport parameters applying to the connection and to be used by the calling terminal.
5.2.3.2	If a terminal receives the request for an optional TDT block size it may either:
–	indicate its support by reproducing the requested value in the TCA block;
–	request in the TCA block the use of a shorter allowable TDT block. The calling side either accepts this size by sending the first TDT block or disconnects the network connection;
–	not accept the requested TDT block size parameter value by sending a TCA block without a TDT block size parameter. Therefore, the standardized TDT block size will apply.
	A TCR requesting an optional TDT block size not supported by the called side should not be answered with TBR.
5.2.4	Transport connection clear (TCC) block
5.2.4.1	If a transport connection cannot be established, the called terminal shall respond to the TCR block with a TCC block. The clearing cause shall indicate why the connection was not accepted.
	It is up to the calling side whether the receipt of a TCC will cause complete disconnection or whether a new TCR with a parameter different from the first one will be sent (e.g. another extended transport layer address). In order to allow for subsequent TCRs, the sender of TCC may provide in the optional parameter field an appropriate parameter and associated value to indicate that another TCR is invited. The new optional parameter and its associated value(s) are for further study.
	Note – There is no explicit transport connection termination procedure in this Recommendation. Therefore, the lifetime of the transport connection is directly correlated to the lifetime of the supporting network connection.
5.2.5	Transport connection collision
5.2.5.1	If the calling terminal receives a TCR block, it shall transfer a TBR block to notify the called terminal of the procedure error (see Annex B).
5.2.6	Extended addressing
5.2.6.1	The extended addressing capability may be used to address terminals in a multiterminal configuration.
	The extension addresses for called and calling terminals are optional parameters to TCR and TCA. The use of the calling extension address is for further study.
5.2.6.2	The receiving terminal shall respond with a TCA according to Table 1/T.70.
TABLE 1/T.70

	Receiver reaction		
Received TCR	Multi–terminal
with extended addressing a)	Stand–alone terminal	
Without extended addressing	Send TCA
with extended addressing	Send TCA
without extended addressing	
With extended addressing	Send TCA
with extended addressing b)	Send TCA
without extended addressing	
a)	Multi–terminal configuration, with capability for extended addressing.
b)	If the called terminal is occupied or out of order, the call should be routed to a default terminal or mailbox. The sender will then be informed of the routing by the extension address of the connected terminal. The receiver of TCR may also in this case react by sending TCC.
5.2.6.3	The calling terminal may, when receiving a called terminal address in the TCA, act as specified in Table 2/T.70.
TABLE 2/T.70
	Calling terminal reaction			
Sent TCR	TCA received with:			
	No extended
addressing	Correct extended addressing	Incorrect extended addressing	
Without extended addressing	OK	Neglect extension
(See Note)	
With extended addressing	a)	OK	a)	
a)	Reaction left to the discretion of the calling terminal.
Note – Terminal complying with the 1980–1984 version of Recommendation T.70 may react by releasing the network connection.
5.3	Description ofdata transfer procedures
5.3.1	General
5.3.1.1	The data transfer procedure described in the following subsections applies only when the transport layer is in the data transfer phase, i.e. after completion of transport connection establishment and prior to clearing.
	Note – When a connection is cleared, transport data blocks may be discarded. Hence it is left to the transport service user to define protocols able to cope with the various possible situations that may occur.
5.3.2	Transport data block (TDT) length
5.3.2.1	The standard maximum TDT block length to be supported by all terminals is 128 octets including the data block header octets. However, the TDT block length may be restricted to a lower value when the TDT block is concatenated with other TDT blocks (see § 5.5.3).
5.3.2.2	Other maximum data field lengths may be supported in conjunction with an optional TDT block size negotiation connection function (see §§ 5.5.4.3 and 5.5.5.3). Optional maximum data field lengths shall be chosen from the following: 256, 512, 1024 and 2048 octets. If the requested optional TDT block size cannot be supported, a shorter allowable TDT block size must be selected (see § 5.2.3.2).
	The agreed maximum TDT block size should be aimed at for TDT blocks having the TSDU end mark set to 0 and a number of octets less than the agreed maximum shall not cause the receiving transport entity to reject this TDT block.
5.3.3	Transport service data unit (TSDU) end
5.3.3.1	The TSDU end mark is used to preserve the integrity of the TSDU. The TSDU end mark is set to binary 1 in the last TDT data block carrying information related to a certain TSDU. Exceptionally, this TDT block may be sent without carrying user information in order to allow for an immediate termination of a TSDU in certain error conditions.
	In case of a TSDU that comprises a single TDT block the TSDU end mark is also set to 1. In all other cases the TSDU end mark is set to zero.
5.4	Treatment of procedure errors
5.4.1	A terminal shall send a TBR block to the remote terminal to report the receipt of an invalid or not implemented block (if not explicitly specified otherwise in this Recommendation). During the establishment of a transport connection, terminals shall not send a TBR block upon the receipt of a TCR block whose parameters or parameter values are invalid or not implemented. In this case, terminals shall act as if no errors have occurred and send the appropriate response (if any).
	A terminal receiving a TBR block shall take appropriate recovery action.
	Note 1 – A TBR whether invalid or valid shall not be answered by sending a TBR block.
	Note 2 – Terminals complying with the Recommendation T.70 version of the 1981–1984 study period may react to all of the above indicated conditions by sending TBR.
	Note 3 – The definition of invalid block/parameter, etc. is provided by the state transition tables (see Annex B).
	Note 4 – A TCR of which the PV of the TPDU size parameter is less than 07 (which is the basic length of the transport block size) shall be considered as an invalid TPDU.
	Note 5 – In the states 1.1 for the calling side and 2.1 for the calling and called side the terminal may react either by sending TBR or by releasing the network connection.
	Attention : The state tables and state transition diagrams have to be read according to Notes 4 and 5 above.
5.5	Formats
5.5.1	General
5.5.1.1	Transport protocol data units (TPDUs) carrying transport service (TS) user information or control information are called blocks (see § 5.1.3). All blocks contain an integral number of octets.
5.5.1.2	Bits of an octet are numbered 8 to 1 where bit 1 is the low order bit and is transmitted first. Octets of a block are consecutively numbered starting from 1 and are transmitted in this order.
	When consecutive octets are used to represent a binary number, the lower octet has the most significant value.
5.5.1.3	TDT block(s) are used to transfer a transport service data unit (TSDU) transparently whilst maintaining the structure of the latter by means of the TSDU end mark.
5.5.1.4	Control blocks (TCR, TCA, TCC, TBR) are used to control the transport protocol functions, including optional functions.
5.5.1.5	A parameter field is present in all control blocks within the basic transport service to indicate optional functions. The parameter field contains one or more parameter elements. The first octet of each parameter element contains a parameter code to indicate the function(s) requested.
	The general coding structure is shown in Figure 5/T.70.
Fig. 5/T.70 = 6 cm

5.5.1.6	The parameter code field is binary coded and, without extension, provides for a maximum of 255 parameters. Parameter code 11111111 is reserved for extension of the parameter code. The extension mechanism is for further study.
	Octet 2 indicates the length, in octets, of the parameter value field. The parameter field length is binary coded and bit 1 is the low order bit of this indicator.
	Octet 3 and subsequent octets contain the value of the parameter identified in the parameter code field. The coding of the parameter value field is dependent on the function being requested.
5.5.2	Structure of transport control and transport data blocks
5.5.2.1	Figure 6/T.70 illustrates the general structure of transport layer blocks. A summary of transport layer blocks is given in Figure 7/T.70.
Fig. 6/T.70 /CCITT-43961 = 3 cm

Fig. 7/T.70 /CCITT 43971 = 9 cm

5.5.2.2	Length indicator (LI) field
5.5.2.2.1	Octet 1 contains the length indicator (LI). The value of this indicator is a binary number that represents the length in octets of the control block (including parameters) and the header length in octets of data blocks (excluding any subsequent user information). In both cases this length does not include octet 1.
5.5.2.2.2	The basic LI value shall be restricted to 127 (i.e., a binary value of 01111111). The use of higher LI values and the use of the binary value 11111111 for extension purposes is for further study.
5.5.2.3	Block type field
5.5.2.3.1	Octet 2 contains the block type code. Bits 1 to 4 of octet 2 are set to 0 for all transport layer blocks currently defined. It is for further study to determine whether or not bits 1 to 4 are required for future extension to the range of transport layer blocks currently defined or are used for other functions.
5.5.2.4	Functional code field
5.5.2.4.1	Octet 3 and subsequent octets contain functional codes in a fixed format as per the block type (see Figure 7/T.70).
5.5.2.5	Parameter or TSDU field
5.5.2.5.1	A parameter field or a data field containing transport service (TS) user data may optionally follow the functional code field.
5.5.3	Concatenation
5.5.3.1	Concatenation of transport control and/or transport data blocks is currently not applicable to this Recommendation. However, where concatenation is used in the future, the arrangement shown in Figure 8/T.70 would apply.

Fig. 8/T.70 = 15 cm

5.5.4	Transport connection request (TCR) block format
5.5.4.1	Figure 9/T.70 illustrates the format of the TCR block.
Fig. 9/T.70 = 12 cm

5.5.4.2	Parameters for extended addressing
	Separate parameters are provided for the indication of called and calling extension addresses. The coding of these parameters is shown in Figure 10/T.70. The setting of bit 8 for extended addressing should be ignored by the transport layer.
	The use of more than one called extension address is for further study.
Fig. 10/T.70 = 5 cm

5.5.4.3	Parameter for transport data block size negotiation
	This parameter defines the proposed maximum transport data block size (in octets including the transport data block header) to be used over the requested transport connection. The coding of this parameter is shown in Figure 11/T.70.
Fig. 11/T.70 = 6 cm

5.5.5	Transport connection accept (TCA) block format
5.5.5.1	Figure 12/T.70 illustrates the format of the TCA block.

Fig. 12/T.70 = 7 cm

5.5.5.2	Parameters for extended addressing
	See § 5.5.4.2.
5.5.5.3	Parameter for transport data block size negotiation
	See § 5.5.4.3. The parameter value shall be equal to or less than the value specified in the TCR block.
5.5.6	Transport connection clear (TCC) block format
5.5.6.1	Figure 13/T.70 illustrates the format of the TCC block.

Fig. 13/T.70 = 13 cm

5.5.6.2	Parameter for additional clearing information
	This parameter is provided to allow additional information relating to the clearing of the connection. The coding of this parameter is given in Figure 14/T.70 below.
Fig. 14/T.70 = 5 cm

5.5.7	Transport block reject (TBR) block format
5.5.7.1	Figure 15/T.70 illustrates the format of the TBR block.

Fig. 15/T.70 = 12 cm

5.5.7.2	Rejected block parameter (mandatory)
	This parameter is used to indicate the bit pattern of the rejected block up to and including the octet that caused the rejection. Only the first detected procedural error or parameter, which cannot be acted upon, shall be indicated by this method. The coding of this parameter is given in Figure 16/T.70.
Fig. 16/T.70 = 5 cm

5.5.8	Transport data block (TDT) format
5.5.8.1	Figure 17/T.70 illustrates the format of the TDT block.

Fig. 17/T.70 = 8 cm

ANNEX A
(to Recommendation T.70)
A.1	Transport and network service
	The transport service (TS) is provided by the transport protocol (TP) making use of the services available from the network layer. This Annex also defines the TS characteristics which the TS users may exploit.
	Interactions between TS users and the TS provider take place at the two TS access points (TSAP) (see Figures A–1/T.70 to A–6/T.70). Information is passed between a TS user and a TS provider by means of primitives, which may convey parameters.
	Primitives are abstract representations of interactions. They are solely descriptive and do not represent a specification or implementation.
	The occurrence of a primitive is a logically instantaneous and indivisible event. The event occurs at a logically separate instant, which cannot be interrupted by another event. Only primitives of global significance are mentioned (having an impact on the remote user).
	The following types of primitives are defined:
a)	request primitive
b)	indication primitive
c)	response primitive
d)	confirm primitive.
	The primitives a) and c) are directed from the service user to the service provider, b) and d) are going in the opposite direction.
	“Transport” is designated by T, “Network” is designated by N. The terms CONNECT, DATA, DISCONNECT as part of a primitive name indicate that the primitive is used for establishment, data transfer, release of a transport connection (TC) or network connection (NC).
	Examples:
T–CONNECT request		request to establish a TC
T–DATA request		request to transmit TS user data
N–DISCONNECT indication	indication that the NC has been released.
	The relationship between valid sequences of TS primitives and the appropriate protocol elements is shown in Figures A–1/T.70 to A–6/T.70. The sequences of valid network service (NS) primitives are illustrated in      Figures A–7/T.70 to A–12/T.70.
A.1.1	Transport service
	The interactions shown in Figures A–1/T.70 to A–6/T.70 are not exhaustive.
A.1.1.1	Transport connection establishment
Figs. A–1/T.70 and A–2/T.70 /CCITT-83930 = 8 cm

A.1.1.2	Transfer phase
Fig. A–3/T.70 /CCITT 83940 = 7 cm

A.1.1.3	Transport service error reporting

Fig. A–4/T.70 /CCITT-83950 = 6 cm

A.1.1.4	TC release
	At present only the implicit release of TC is defined (see § 5.2.4.1 of this Recommendation).
Figs. A–5/T.70 and A–6/T.70 /CCITT-83960 and CCITT-83950 = 5 cm

A.1.2	Network service
	Figures A–7/T.70 to A–12/T.70 show the relationships of network service (NS) primitives at both sides of an NC.
A.1.2.1	Network connection establishment

Figs. A–7/T.70 and A–8/T.70 /CCITT-83930 = 6 cm

A.1.2.2	Network data transfer
Fig. A–9/T.70 /CCITT-83960 = 3 cm

A.1.2.3	Network service error reporting
Fig A–10/T.70 /CCITT-83950 = 3 cm

A.1.2.4	Network connection release
Figs. A–11/T.70 and A–12/T.70 /CCITT-83960 and CCITT-83950 = 6 cm

A.2	State transition diagrams for the basic transport layer procedures
	This part represents detailed state transition diagrams for the basic transport procedures.
	Two description levels are used:
a)	Protocol level
This level addresses only the peer to peer protocol activities between two transport entities. It identifies the protocol state, events [receipt of transport protocol data units (TPDUs)] and actions (sending of TPDUs).
b)	Detailed level
This level addresses the inter–layer and local activities. It identifies the events, actions, conditions and states within each of the protocol level states. The inter–layer activities are described using the transport service primitives defined in the first part of this Annex.
	Example (see Figure A–13/T.70)
	For pure illustrative reasons, the example shows a simplified description of state 1 (response pending, called side) of the state transition diagram of this Recommendation. The event R–TCR may be answered either by sending the action S–TCA or S–TCC.
	The events and actions are not interruptable. They will complete their transfer irrespective of the occurrence of other events.
	The detailed state transition diagrams are given in Figures A–14/ and A–15/T.70.
Fig. A–13/T.70 CCITT-83970 = 6 cm

Fig. A–14/T.70 CCITT-60581 = 11 cm

Fig. A–15/T.70 CCITT-60591 = 25 cm