5i' FASCICLE VII.5 Recommendations T.65-T.101, T.150-T.390 TERMINAL EQUIPMENT AND PROTOCOLS FOR TELEMATIC SERVICES BLANC MONTAGE: p. 2 = PAGE BLANCHE Recommendation T.65 APPLICABILITY OF TELEMATIC PROTOCOLS AND TERMINAL CHARACTERISTICS TO COMPUTERIZED COMMUNICATION TERMINALS (CCTs) (Melbourne, 1988) The CCITT, considering (a) that there is an increasingly growing base of computerized communication terminals, such as communicating personal computers; (b) that Administrations will require provisions to enable these devices to access CCITT-defined services, such as telematic services; (c) that communication of these devices with each other may use provisions specified for communication within telematic ser- vices; (d) that such devices may, due to their adaptive nature, require, in some areas, different protocols and terminal charac- teristics than existing telematic terminals; (e) that the various telematic services are defined in the F-Series of Recommendations; ( f ) that the reference model for open systems interconnec- tion is defined in the X-200-Series of Recommendations; (g) that the various telematic protocols and terminal charac- teristics are defined in the T-Series of Recommendations; (h) that there is a requirement to assess the applicability of the protocols and terminal characteristics defined in the CCITT telematic recommendations to computerized communication terminals; unanimously declares the view that the following technical provisions determine the applica- bility of protocols and terminal characteristics specified in CCITT Telematic Recommendations to Computerized Communication Terminals. CONTENTS 1 Scope 2 Characteristics and model 2.1 Definition 2.2 Characteristics 2.3 General model 2.4 Minimum capability 3 Access to the Teletex service 3.1 General 3.2 Characteristics 3.3 Applicability of the relevant CCITT Recommenda- tions 3.4 Access methods 4 Access to the Group 3 facsimile service 4.1 General 4.2 Characteristics 4.3 Applicability of the relevant CCITT Recommenda- tions 5 Access to the Group 4 facsimile service 6 Access to the mixed-mode option of the Teletex service 7 Access to the videotex service 7.1 General 7.2 Characteristics 7.3 Applicability of the relevant CCITT Recommenda- tions 8 Access to MHS 8.1 General 8.2 Characteristics 8.3 Applicability of the relevant CCITT Recommenda- tions 9 Access to the directory service 9.1 General 9.2 Characteristics 9.3 Applicability of the relevant CCITT Recommenda- tions 1 Scope 1.1 This Recommendation addresses the applicability of the protocol and terminal characteristics specified in CCITT-defined Recommendations to Computerized Communication Terminals (CCTs). It should be observed that the "adaptive" (as opposed to dedicated) nature of CCTs calls for, in certain areas, more flexibility, but without undue degradation of capabilities. The issues of flexibil- ity versus degradation of capabilities strongly influenced the pro- posals made in this Recommendation. 1.2 This Recommendation specifies how the various telematic Recommendations may be used, and any additional requirements, to enable computerized communication terminals to access the various telematic services. It is noted that while this Recommendation is applicable to CCTs only when accessing telematic services, con- sideration may be given to the use of the technical aspects of this Recommendation if CCTs communicate with each other utilizing the telematic protocols. 1.3 Section 2 describes the characteristics of computerized communication terminals. The remaining sections define how the relevant telematic Recommendations may be used to enable CCTs to access the telematic services. 1.4 Figure 1/T.65 shows various methods for CCTs to access the telematic services which are described in SS 3 to 9. Three methods are proposed: i) access to and from a telematic service via ser- vice access facility (SAF) (see S 3.4.2, for example); ii) direct access from and to a telematic service; iii) direct access from a CCT to a telematic ser- vice, reverse access via SAF (see S 3.4.3, for example). 2 Characteristics and model 2.1 Definition The term Computerized Communication Terminal (CCT) refers to a device or equipment, which may be portable, with a processor and communication facility, typically a user work station, which per- mits entry of various applications and which can access CCITT-defined services, such as telematics, as prescribed in this Recommendation. Figure 1/T.65, p.1 2.2 Characteristics Computerized communication terminals differ in certain charac- teristics from telematic terminals. The following subsections iden- tify the characteristics of CCTs. Characteristics specific to each case of the access to telematic services are given in SS 3 to 9. 2.2.1 Capability A CCT maybe used to access the telematic services. The provi- sions in this Recommendation provide a basic level of compatibility between CCTs and the telematic services. 2.2.2 Protocols In general, CCTs will use OSI protocols defined in the X.200-Series of Recommendations, but configured to meet the requirements defined in the relevant T-Series of Recommendations. Exceptions include the cases of access to the non-OSI-based telematic services, where the relevant T-Series of Recommendations apply. 2.2.3 Terminal requirements In general, the relevant T-Series Recommendations for terminal requirements apply. The details specified to each access to telematic services, and any additional (or relaxed) requirements are specified in SS 3 to 9. 2.3 General model A model for CCTs accessing telematic services based on OSI is given in Figure 2/T.65. The model identifies the relevant Recommen- dations applicable to each level in the OSI layers, for each case of access to telematic services. In particular, two sets of proto- cols are identified for access to OSI-based telematic services: a) A set of OSI protocols common to most accesses to telematic services is identified for the lower layers up to and including the session kernel in the session layer. The correspond- ing CCITT Recommendations required are identified. b) Above the common set of protocols, additional session layer functional units based on Recommendations X.215/X.225 are identified, together with any Recommendations required for each of the cases of the access to telematic services. There are telematic services which require the use of non-OSI-based protocols. In these cases, the common set of proto- cols may not be applicable and the relevant T-Series Recommendations must be used. Figure 2/T.65, p. 2.4 Minimum capability For a CCT to access an OSI-based telematic service it must support all the following capabilities, and any additional capabil- ity required for each case of access to telematic service as prescribed in SS 3, 5, 6, 7, 8 and 9: a) The appropriate network capability as prescribed in S 3 of Recommendation T.70. b) X.214/X.224 Class 0 Transport procedure. c) X.215/X.225 Kernel; together with half-duplex, or full-duplex functional units. Note - The applicability of the minimum capability to videotex access requires further study. 3 Access to the Teletex service 3.1 General The access of CCTs to the Teletex service is a common case of communication with an OSI-based telematic service due to the well defined nature of Teletex. The following sections describe the characteristics of such an access and specify how the various Teletex-related Recommendations may be used. 3.2 Characteristics 3.2.1 From the technical point of view, CCTs will be able to establish communications directly with a Teletex device and exchange documents on a real-time, end-to-end basis without the use of conversion facilities. 3.2.2 As far as possible, CCT access to the Teletex service should be done via message handling systems. The technical imple- mentation is a national matter. 3.2.3 CCTs may not necessarily be available continuously to receive incoming calls. However, when a CCT is available it will be technically able to receive calls directly from and exchange docu- ments with other Teletex devices. 3.2.4 CCTs may technically use the Teletex protocol and termi- nal characteristics as prescribed in S 3.3 of this Recommendation to exchange Teletex documents with each other. 3.2.5 If a Teletex device communicates with a CCT, it must be made aware of that fact. How this information is conveyed within the Teletex terminal identification with a specific value for Part 3 is described in S 3.4. 3.3 Applicability of the relevant CCITT Recommendations 3.3.1 Protocols a) The network capabilities are in accordance with S 3 of Recommendation T.70. b) The transport procedure is in accordance with either: - Class 0 of the OSI transport protocol, as speci- fied in Recommendations X.214/X.224, together with application rules to be compatible with and conform to the S 5 and Annexes of Recommendation T.70; or - Paragraph 5 and annexes of Recommendation T.70. c) The session layer procedure is in accordance with either: - Kernel with the functional units minor sync, half-duplex, capability data, activity management, and exceptions specified in Recommendations X.215/X.225 together with application rules to be compatible with and conform to Recommendation T.62; or - Recommendation T.62. d) The applicability of higher-layer Recommenda- tions, such as T.300 and T.400, requires further study. 3.3.2 Terminal requirements and character repertoire The terminal requirements and character repertoire specified in Recommendations T.60 and T.61 will apply except for the follow- ing: a) A CCT may or may not support full automatic operation. b) A CCT must be able to receive and store all characters belonging to the basic Teletex character repertoire. However, only those graphic characters which form the primary char- acter set of the basic Teletex character set as defined in Recommendation T.61 need to be presented. c) A CCT may require a different terminal identif- ication from that of a Teletex terminal. The format of this iden- tification is defined in S 3.4.3.1. d) Other items require further study. 3.4 Access methods 3.4.1 Introduction This paragraph describes a technical method for CCT access to and from the Teletex service. This access method is based on the assumption that CCTs should enjoy a maximum flexibility and that the service characteristics of Teletex should not be degraded. These prerequisites imply that the CCT must be supported by a service access facility (SAF) which emulates the Teletex service characteristics and provide for the handling of messages. 3.4.2 Description of the access method A CCT may establish a connection to the SAF at any time, from any network and from any access point within these networks. If a CCT wants to transmit a message but does not wish to receive a mes- sage, it need not be identified. The message will be received by the SAF and forwarded immediately to the Teletex destination. The SAF must add information which will indicate to the Teletex desti- nation that this message was originated by an unidentified CCT. If a CCT is to receive an answer to its previously transmitted message, it should be able to register itself temporarily using a password. The password will be provided by the CCT user. The mes- sage from the CCT will be forwarded immediately to the Teletex des- tination including information that the answer may be placed in the SAF under the given password. Provisions to allow positive or nega- tive acknowledgements to the Teletex source and to allow control of the status of messages sent by the Teletex source are technically feasible. In the following, the functions of the SAF are described which are needed to support CCTs for access to/from the Teletex service. 3.4.3 Model (see Figure 3/T.65) Figure 3/T.65, p. 3.4.3.1 CCT to Teletex The following functions will be provided by the SAF in order to enable a CCT to access the Teletex service: a) insertion of an appropriate information from which the Teletex subscribes can identify that the message is being sent from a CCT (e.g., the letters "CCT" into Part 3 of the Teletex-TID); b) temporary registration on an optional basis (to allow messages to be sent back to the CCT by a Teletex terminal, see S 3.4.3.2). 3.4.3.2 Teletex to CCT The following functions will be provided by the SAF in order to enable a Teletex terminal to send documents to a CCT: a) memory for storing messages sent by the Teletex terminal; b) allocation of stored messages to registration numbers to allow their retrieval by the CCT; c) means for a delivery notification call to the Teletex terminal to indicate that the CCT has retrieved the mes- sage; d) a time-out mechanism for deleting a message if not retrieved within a certain period of time; e) additional notification calls (e.g., status of stored messages) are for further study. 4 Access to the Group 3 facsimile service 4.1 General A CCT may be used to access the Group 3 facsimile service. 4.2 Characteristics A CCT accessing the Group 3 facsimile service will operate in accordance with the CCITT Recommendations T.4 and T.30. 4.3 Applicability of the relevant CCITT Recommendations 4.3.1 Protocols The requirements defined in the CCITT Recommendation T.30 apply. 4.3.2 Modulation systems The requirements defined in the CCITT Recommendation T.4 apply. 5 Access to the Group 4 facsimile service (For further study.) 6 Access to the mixed-mode option of the Teletex service (For further study.) 7 Access to the videotex service 7.1 General A CCT may be used to access the videotex service. Since a videotex service will not distinguish between what type of terminal is connected to it, there are no special requirements for CCTs above those which apply to dedicated videotex terminals. 7.2 Characteristics 7.2.1 CCTs accessing the videotex service should emulate videotex terminal characteristics. In the emulation, attention should be given to the profiles, ranks or service reference modes of the videotex terminals concerned as used in the various videotex services. Where insufficient display capabilities are available, a CCT should provide fall-back by graceful degradation of capabili- ties so that the integrity of the information content is preserved. For example, a wide range of colours may fall back to fewer related colours, or to grey scales, or an accented character may fall back to a character without accent. 7.2.2 Videotex services are interactive and CCTs should be able to transmit and receive data interactively. 7.3 Applicability of the relevant CCITT Recommendations 7.3.1 Protocols To be defined. 7.3.2 Data syntax and terminal requirements The requirements defined in CCITT Recommendation T.101 (Annexes B, C and D) apply. 8 Access to MHS 8.1 General This paragraph describes the characteristics of CCTs to access MHS and specifies how the various related Recommendations may be used. 8.2 Characteristics In its present form, the message handling system has as its fundamental component the message transfer system (MTS), which comprises a number of message transfer agents (MTAs). A CCT can then access MHS in two ways as described in Figure 4/T.65 and the text below. Figure 4/T.65, p. i) The CCT can access MHS through a telematic interworking facility (TIF) as defined in Recommendations T.300-Series. ii) The CCT can support the MHS user agent functions to access the MTS directly. 8.3 Applicability of the relevant CCITT Recommendations When a CCT does not support the MHS user agent functions it shall access MHS through a TIF, which provides for interworking between Telematic services and MHS. In this case the relevant sec- tions of Recommendations T.300-Series and T.65 apply, depending on the choice of protocols and terminal characteristics. When a CCT supports the MHS user agent functions in addition to the Telematic protocols and terminal characteristics, it will use the relevant sections in the series of Recommendations X.400. 9 Access to the directory service 9.1 General The access of CCTs to the directory service will often precede the other CCITT-defined services such as MHS, Teletex, or telephony, in order to determine or ascertain the address of a user or service. This section describes the characteristics of such an access and specifies how the various related Recommendations may be used. 9.2 Characteristics In its present form, the directory system has two fundamental components: the directory user agent (DUA) and the directory (see Figure 5/T.65). Figure 5/T.65, p. In terms of this model two ways of CCT access are possible: i) The CCT can access the DUA using suitable telematic protocols and terminal characteristics defined in the T-Series of Recommendations. ii) The CCT can support DUA functions to access the directory directly. It should be noted that directory access is essentially an interactive application. Therefore, this interactive nature influ- ences the protocol and terminal requirements. 9.3 Applicability of the relevant CCITT Recommendations When a CCT does not support DUA functions, it shall access the directory through a DUA. In this case the relevant sections of the Recommendations X.500 and T.65 apply, depending on the choice of protocols and terminal characteristics. When a CCT supports DUA functions in addition to the Telematic protocols and terminal characteristics it will use the relevant sections in the series of Recommendations X.500. 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 pub- lic 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 ter- minals 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 S 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 pro- cedure, 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 pro- vide 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 S 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). Figure 1/T.70 TO803680-89, p.6 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 tran- sport 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 identif- ier within call request/incoming call packets for the Teletex ser- vice and Group 4 facsimile apparatus. This identifier is represented by the first octet of the call user data field (remain- ing octets, if any, should be ignored) as shown below: bit 87654321 octet 1 00000010 In the case of CSPDN/PSPDN interworking the functional map- ping of this protocol identifier requires further study. h) Terminals shall not use the fast select facil- ity. 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 termi- nal, 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 SS 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. Figure 2/T.70 p. 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 S 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 con- form 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 for- mat 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, Recommenda- tion 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 fol- lowing 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. Figure 3/T.70, p. 3.3.2.3 Link layer implementation rules In order to achieve full compatibility between different implementations, the rules below for the implementation of Recom- mendation X.75 shall be followed. 3.3.2.3.1 General rules a) The 1984 version (Red Book ) of CCITT Recommendation X.75, S 2, shall be used as the reference specifi- cation. 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) S 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) S 2.3.5.3 The DTE and the CSPDN are not octet aligned and the last paragraph is therefore not valid. e) S 2.3.5.5 Higher layers should be notified when timer T3 expires (excessive idle state). f ) S 2.4.3 Related to the first paragraph, read instead of "next response" "corresponding response". g) S 2.4.4.1 In the active channel state, the DTE shall transmit con- tiguous 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) S 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, S 2.4.4.5). In the disconnected phase, it is the calling DTE which may initiate link set up. i) S 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 con- dition). j) S 2.4.5.9, fifth paragraph If a RNR is received, the DTE shall not resume I-frame transmission or retransmission. k) S 2.4.5.9, last paragraph If the transmission attempt variable is equal to N2, the DTE shall enter the disconnected phase. l) S 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) S 2.4.7.3, second paragraph (see Note 2) Only the DTE which caused the FRMR condition may try to reset the link. n) S 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) S 2.4.8.1 (see Note 4) The timer T1 shall be started at the end of frame transmis- sion. 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 represent- ing both T2 and the transmission delay [see S 3.3.2.3.2 | )]. The recommended value range is: 1.5-15 s. p) S 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) S 2.4.8.3, second paragraph 30 s T3 60 s r) S 2.4.8.4 N2 x T1 _" 60 s s) S 2.4.8.5 N1 = 1080 + (n x 1024) bits; n = 0 or 1 or 3 or 7 or 15. t) S 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 x T1. Note 4 - The acknowledgement strategy used by the receiv- ing DTE should be independent of any knowledge about the value of k used by the sending DTE. This can be achieved by either acknowledg- ing every correctly received I-frame as soon as possible or by implementing an acknowledgement timer, i.e., a T2 timer as defined above [see S 3.3.2.3.2 | )]. 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. Figure 4/T.70, p. 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 seg- menting 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 com- posite 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 tele- phone 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 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 S 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 hierar- chy 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 nego- tiated according to the following rules: - the calling terminal indicates the transport pro- tocol class and (if applicable) the optional functions required; - the called terminal indicates the transport pro- tocol class and (if applicable) the optional functions that it is willing to support; - all parameters to be used in the transport con- nection must be explicity indicated, otherwise default values will apply. 5.1.2.3 The basic transport service described here is ful- filled 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 tran- sport 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 pro- vided by transport layer functions which are performed by transport layer protocol elements . 5.1.3.2 Transport protocol data units (TPDUs) carrying tran- sport 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 proto- col class, and optional functions, applying to a transport connec- tion. 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 per- formed at the network/link layer as appropriate; c) error: no mechanism is provided within the tran- sport 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 ter- mination 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 tran- sport 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 identif- ication 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 con- nection request by transferring a TCR block to the remote terminal. The TCR block includes the transport functions (e.g. source refer- ence, class, and optional functions) for negotiation of the charac- teristics 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 pro- cedure 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 exten- sion address is for further study. 5.2.6.2 The receiving terminal shall respond with a TCA according to Table 1/T.70. H.T. [T1.70] TABLEAU 1/T.70 _____________________________________________________________________ Receiver reaction { Received TCR Stand-alone terminal _____________________________________________________________________ Without extended addressing { Send TCA with extended addressing } { Send TCA without extended addressing } _____________________________________________________________________ With extended addressing { Send TCA with extended addressing | ub) } { 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. Table 1/T.70 [T1.70], p. 5.2.6.3 The calling terminal may, when receiving a called ter- minal address in the TCA, act as specified in Table 2/T.70. H.T. [T2.70] TABLE 2/T.70 __________________________________________________________________________________ Calling terminal reaction Sent TCR TCA received with: __________________________________________________________________________________ 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. Table 2/T.70 [T2.70], p. 5.3 Description of data 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 S 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 SS 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 S 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 tran- sport 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. Exception- ally, 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 send- ing 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 tran- sport service (TS) user information or control information are called blocks (see S 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 con- trol the transport protocol functions, including optional func- tions. 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. Figure 5/T.70 p. 5.5.1.6 The parameter code field is binary coded and, without extension, provides for a maximum of 255 para meters. Parameter code 11111111 is reserved for extension of the parameter code 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 parame- ter 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. Figure 6/T.70, p. Figure 7/T.70, p. 5.5.2.2 Length indicator (LI) field 5.5.2.2.1 Octet 1 contains the length indicator (LI) of this indi- cator 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. Figure 8/T.70, p. 5.5.4 Transport connection request (TCR) block format 5.5.4.1 Figure 9/T.70 illustrates the format of the TCR block. Figure 9/T.70 p. 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 address- ing should be ignored by the transport layer. The use of more than one called extension address is for further study. Figure 10/T.70, p. 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. Figure 11/T.70, p. 5.5.5 Transport connection accept (TCA) block format 5.5.5.1 Figure 12/T.70 illustrates the format of the TCA block. Figure 12/T.70 p. 5.5.5.2 Parameters for extended addressing See S 5.5.4.2. 5.5.5.3 Parameter for transport data block size negotiation See S 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. Figure 13/T.70, p. 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. Figure 14/T.70 p. 5.5.7 Transport block reject (TBR) block format 5.5.7.1 Figure 15/T.70 illustrates the format of the TBR block. Figure 15/T.70, p. 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 rejec- tion. 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. Figure 16/T.70 p. 5.5.8 Transport data block (TDT) format 5.5.8.1 Figure 17/T.70 illustrates the format of the TDT block. Figure 17/T.70 p. ANNEX A (to Recommendation T.70) A.1 Transport and network service The transport service (TS) is provided by the transport proto- col (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 primi- tives 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 direc- tion. "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 con- nection (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 Figures A-1/T.70 and A-2/T.70 p. A.1.1.2 Transfer phase Figure A-3/T.70 p. A.1.1.3 Transport service error reporting Figure A-4/T.70 p. A.1.1.4 TC release At present only the implicit release of TC is defined (see S 5.2.4.1 of this Recommendation). Figures A-5/T.70 and A-6/T.70 p. A.1.2 Network service Figures A-7/T.70 to A-12/T.70 show the relationships of net- work service (NS) primitives at both sides of an NC. A.1.2.1 Network connection establishment Figures A-7/T.70 and A-8/T.70 p. A.1.2.2 Network data transfer Figure A-9/T.70 p. A.1.2.3 Network service error reporting Figure A-10/T.70 p. A.1.2.4 Network connection release Figures A-11/T.70 and A-12/T.70 p. 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 activi- ties 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 com- plete 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. Figure A-13/T.70 p.37 Figure A-14/T.70 p.38 Figure A-15/T.70 p.