!===========================================================================! ! TOWARDS A PORTABLE IMPLEMENTATION OF THE TRANSPORT SERVICE FOR SUNET. ! !===========================================================================! Contractor : SUNET, (Swedish University Network). Thomas Sjöland 83 06 02 Keywords : Computer Communication Layered Architecture Transport Service Portable Implementation in Pascal Message Passing for Interprocess Communication Abstract Interface to Local Operating System Abstract : An implementation of the Teletex Transport Service according to the ISO document ISO/TC 97/SC 16 N 1169 of June 1982, classes 0 and 1, (class 0 is identical to the CCITT recommendation S.70), is described. The use of message passing between concurrent processes for the implementation of the transport service handler is discussed. The design of the two interfaces required and the assumed services regarding message passing between concurrent processes are described. Table of contents: ================== 1. The Transport Layer. -------------------- What is it ? Why is it needed ? What does it demand from the operating system ? 2. The Network Service Interface. ------------------------------ What is required by the network layer ? How is this supported by our interface design ? 3. The Transport Service Interface. -------------------------------- What services are available ? How can they be accessed by the user ? 4. The Message Passing System. --------------------------- What services are required ? How can these services be implemented in different systems ? 5. Conclusions and Remarks. ------------------------- Is this an appropriate approach ? What is needed for portation ? What are the alternatives ? 1. The Transport Layer. ==================== The transport layer, level 4 in the OSI layered architecture model, is expected to provide connection oriented services and is concerned with the "enhancement of quality of service". It should be possible to establish a transport connection between two end users initiated by either of them. The connection should be a two-way simultaneous datapath with appropriate error-checking concerning the format and sequence of the participating interaction packets and the status of the underlying network-service. The transport layer can be implemented with varying qualities of service concerning the data-packet-size, multiplexing, expedited data transfer, error recovery, flow control etc. To accomplish this in a standardized manner ISO has defined five different classes with optional additional functions for each class: Class 0 : Simple Class Class 1 : Basic Error Recovery Class Class 2 : Multiplexing Class Class 3 : Error Recovery and Multiplexing Class Class 4 : Error Detection and Recovery Class Class 0 is identical to the CCITT recommendation S.70. Connections using classes 2-4 may be multiplexed together onto the same network connection. The classes and options are negotiated during the connection establishment phase. For SUNET we have decided to implement classes 0 and 1 . The purpose of the transport layer is to enable the transfer of Transport Service Data Units (TSDU's) between two end users of the service. The transport connection, which is the metaphore for this service, is established by using the X.25-based packet-switched network service supplied by the Swedish PTT, Telepak, but it could also be applied to other network layer solutions. Once successfully connected, the two end users of the service can exchange Transport Service Data Units (TSDU's) between one another. The SUNET-transport service is identified among other users of the X.25-network by using the PID (=protocol identifier) field value 2. This is the same approach that has been taken by the GILT project for interconnecting different research institutions throughout Europe, although, GILT has decided only to implement class 0 of the transport layer. Therefore GILT services are accessible through this service. The Conceptual Framework of the Transport Service. ================================================== Transport connections can be established and maintained through the lower levels by exchanging Transport Protocol Units in a standardized manner on a network connection. In order to guarantee the correctness of the traffic on the net and to enable answering of incoming calls to users who are not currently available to the service, a so called Transport Protocol Handler has been implemented using the language PASCAL. The assumption was made that the users of the service are communicating with the handler using an Interprocess Communication Facility. The interface to this local IPC-facility and the one to the network service is what has to be coded locally when portating this software. A TSDU has an unspecified size and is transferred between the two Transport Connection Endpoints (TCEP's). A TSDU is transmitted by the Transport Protocol Handler through the network connection by means of Transport Protocol Data Units (TPDU's). In the header of a data-TPDU is contained a bit that tells whether this is the last data-TPDU in the currently transferred TSDU and also a sequence number, a so called TPDU-number, used to check if TPDU's are duplicated or lost during the transmission. The user, who is expected to be an entity in the session layer, supplies the transport station with data in Transport Interface Data Units (TIDU's). An upper bound to the size of a TIDU is the largest buffer size available in the message passing system. A t- dataready interaction is sent to the user as soon as the transport station is ready to receive a TIDU from the user. Data-TPDU's from the remote user are received as NSDU's in interaction with the net and are forwarded to the user as TIDU's. The user controls the flow in this direction by sending t-dataready requests to the transport station. There are also TPDU's that enable the establishment and disconnection of a transport connection and also for error-indication. In the establishment interactions the information concerning the negotiation on the quality of service are encoded. The TPDU's are transferred in Network Service Data Units (NSDU's) using the X.25-protocol. Concatenation of several TPDU's into a single NSDU is not implemented in the current version of the Transport Service, but an NSDU may be divided into several NPDU's (Network Protocol Data Units). Class 1 is available to increase the reliability of a network connection, and is able to handle reestablishment of a prematurely lost network connection as well as resynchronisation in the case of a received network-reset indication which means that some previously sent TPDU's may have been lost. This is accomplished in the specification of this protocol class through the use of explicit end-to-end acknowledge packets for data. The price paid is of course some overhead in the network-traffic and therefore class 0 should be used whenever possible. The classes 2,3 and 4 were not implemented because they were not found to be essential for the desired purposes. The extension of the protocol handler to implement these classes of the protocol specification does not need to affect the specified interfaces in any way that can now be conceived. It is a matter of adding code to the protocol handler module, to handle the semantics of the protocol units for these classes. In class 0, the service offered to the user is an improved error detection and a more flexible datatransfer phase compared to using the network service directly. Subaddressing for different users on the same host using the same protocol simultaneously is available, but multiplexing of several transport connections using the same network connection (virtual circuit) simultaneously is not available in classes 0 and 1. A user program may establish several connections simultaneously to several other users of the transport service, possibly located on different sites. Detected errors in the underlying network service, in the use of the primitives by the user, or errors in the transferred TPDU's lead to disconnection of the datapath. In some cases a detected error is so severe that all transport connections currently active are disconnected. Attempts are always made to inform the users in both ends of the connection about the state of affairs.( A t-disconnect message is sent to the local user of the service). The network connection is disconnected, thereby causing the other end user to disconnect its part of the transport connection. There are cases when this mechanism will fail, however. (For instance if the local message passing system is not functioning properly or if the underlying network service has broken down.) These errors are visible to the users of the service when they try to send their next packet on the transport connection by error returns from the interface primitives. In all classes, a disconnection can be initiated by either of the two end users by sending a t-disconnect packet or by the protocol handler disconnecting the network connection. In class 1, however, the disconnection of the transport connection should be acknowledged. In the case of a prematurely received n-disconnect packet at the network connection endpoint associated with a still connected transport connection on the end that initiated the call, an attempt is made to reestablish the lost network connection. Time-outs are not handled by the protocol handler but are instead expected to be handled by the user or the network layer. This disconnection confirmation procedure is handled without direct interaction with the user. When the interface described in appendix D is used, the state variables in the interface keep a consistent view of the state of the connection. In order to shut down a connection, the procedure shut_tcep is used. It has been our goal to make an implementation which is compatible with the ISO-documents for classes 0 and 1. A main goal of our implementation is the portability of the Transport Protocol Handler and the interface to the user and the network layer. An implementation of the transport layer according to our model demands a system for passing messages between concurrently running programs and a network layer that works according to our expectations (see "network interface"). In order to portate the Transport Protocol Handler, two pascal procedure interfaces should be implemented locally according to the specifications available in the appendix. 1) The interface to the local interprocess communication system. 2) The interface to the network layer. The structure of the implementation basically looks like this: user <--> IPC <--> protocol handler <--> IPC <--> network handler <--> net INTER45 TSAP-HAND NET-PROC 2. The Network Service Interface. ================================= The minimum required network service in a connection oriented service is described in the ISO document previously mentioned. The essential service primitives are: Primitive Parameters --------- ---------- N-connect request Called Address indication Calling Address response NS-User-Data confirmation N-data request NS-User-Data indication N-reset request indication response confirmation N-disconnect request NS-User-Data indication response confirmation (See fig. 2, p. 9, in ISO TC97/SC16 N1169 june 1982) This service specification, however, is not an implementation description. Certain functions like the method of flow control used in the interactions (explicit with n-dataready or invisible with "backpressure") are not explained. Our implementation of the network service interface is based on message passing and uses a procedure package with request routines for the packing and sending of network interaction packets and indication routines for the unpacking of received network interaction packets through this IPC facility. A short description of the interactions in our implementation and their counterparts in the ISO model migth clarify the situation: The parameter "ncep-id" is used to name a virtual channel in the network layer and is needed to identify different users of the network service uniquely. Prot-id is used to identify different protocol handlers, residing in the same host, which all use the X.25-network. In our implementation our own DTE-address is implicitly known by the network layer but the DTE-address of the other end has to be specified when a connection attempt is made. Our Model ISO ========= === N-CONNECT (req ind) N-CONNECT (req ind) ncep_id, < not specified > < implicit > calling-address prot-id, remote-dte called-address user-data (not used) NS-user-data (should not be used) N-ACCEPT (req ind) N-CONNECT (resp conf) ncep-id, < not specified > < implicit > called-address < implicit > calling-address < no counterpart > NS-user-data N-DATA (req ind) N-DATA (req ind) ncep-id, < not specified > user_data, NS-user-data m-bit < marks end of NSDU > q-bit < not used > N-RESET ( ind ) N-RESET ( ind ) ncep-id, < not specified > cause-code, < no counterpart > diagnostic-code < no counterpart > < NO COUNTERPART > N-RESET ( req resp conf ) N-DISCONNECT ( req ind ) N-DISCONNECT ( req ind ) ncep-id, < not specified > cause-code, < no counterpart > diagnostic-code < no counterpart > < no counterpart > NS-user-data < NO COUNTERPART > N-DISCONNECT ( resp conf ) The expedited data interaction of the net-layer is not applicable in the current implementation and therefore lead to disconnection of the transport service if it occurs. The actual implementation of these interface primitives are a set of PASCAL procedures for sending network interface protocol units to the network protocol entity and to receive and unpack arriving packets from the net. It is assumed that the interaction with the network-layer takes place by exchanging Network Interface Units through the local interprocess communication system. The specifications of these procedure heads and the corresponding constants and variables are in the files NET-CONST, NET-TYPE, NET-VAR and NET-HEAD respectively. In order to portate the Transport Protocol Handler, it is necessary to code the procedure bodies for the procedures included in NET-HEAD. The bodies of these routines should be placed in the file NET-LOCAL. 3. The Transport Service Interface. =================================== The transport layer is visible to the user through a procedure interface. This interface uses the message passing system for sending transport request units to the local transport station and to receive indication units from it. The receiving function t-wait is designed so that the user can decide whether he wants to use it for polling with time-out or in a "hanging read" fashion. The necessary services that are assumed from the transport layer are defined in the ISO-document mentioned above. To simplify the interaction with the transport layer a set of routines have been implemented using the interface described below. This is not strictly necessary and for instance the file-transfer service does not use this interface. It is contained in the files INTER45-CONST, ..- TYPE, ..-VAR, ..-PROC and uses a set of queue handling routines defined in the files QUEUES-CONST, ..-TYPE, ..-VAR, ..-PROC. The advantage of this interface is that the state of a transport connection endpoint can be reduced to the simplest possible and contains no reflection of the fact that the local interprocess communication is used to realize this service. The description of this interface is included as an appendix to this document. A more detailed description is available in the documentation for the session layer implementation. Here is a description of the services primitives of the transport layer, that occur on the lower of the two user interfaces: Primitive Parameter --------- -------- T-connect request To Transport Address indication From Transport Address Expedited Data Option Quality of Service TS-User-Data T-connect response Quality of service confirmation Expedited Data Option TS-User-Data T-data Request TS-User-Data Indication T-expedited-data Request TS-User-data ( In class 1 only ) Indication T-disconnect Request TS-User-Data T-disconnect Indication Disconnect Reason TS-User-Data (See fig 1, in ISO TC97/SC16 N1169 june 1982) This service description, however, is not equivalent to an interface description. Therefore a description of the mapping of the interface routines to the service might be appropriate: Tcep-id is needed to identify a user to the transport station. It is returned as a parameter by t-attach. Our implementation ISO ------------------ --- T-INIT < not specified > ( local procedure to initalize data, datapaths and processes needed. ) T-ATTACH < not specified > my-addr-ext tcep-id ( allocate message queue to user, inform transport station about the user's transport address and queue identifier.) T-DETACH < not specified > tcep-id ( deallocate message queue, inform the transport station that the user is no longer available for connections.) T-CONNREQ T-CONNECT req tcep-id < not specified > remote-addr-ext to transport address remote-user - " - < implicit > from transport address tpdu-size < not specified > < implicit > quality of service < not used > TS-user-data T-ACCREQ T-CONNECT response tcep-id < not specified > tpdu-size < not specified > < no meaning > expedited data option < implicit > quality of service < not used > TS-user-data T-DISCREQ T-DISCONNECT request user-reason < not specified > < not specified > TS-user-data T-TIMEOUTREQ < not specified > time (local procedure to be issued when the user is no longer interested in waiting for the reestablishment of a lost network connection. Semantically it is equivalent to a T-DISCREQ call.) T-DATAREQ T-DATA request tcep-id < not specified > tidu TS-user-data eod < not specified > T_DRDYREQ < not specified > tcep-id cdts T-CONNIND T-CONNECT indication < implicit > to transport address dte-calling from transport address user-calling - " - < no meaning in class 0 > expedited data option < implicit > quality of service tpdu-size < not specified > user-data TS-user-data T-ACCIND T-CONNECT confirmation < implicit > quality of service < no meaning in class 0 > expedited data option tpdu-size < not specified > T-DISCIND T-DISCONNECT indication reason disconnect reason user-reason < not specified > < not specified > TS-user-data T-TIMEOUTIND < not specified > time (local procedure to indicate to the user that the transport protocol handler is in the process of reestablishing a lost network connection. This primitive only applies to class 1). T-DATAIND T-DATA indication tidu TS-user-data eod < not specified > T-DRDYIND < not specified > tcep-id cdts ( allowed to send message ) T-WAIT < not specified > tcep-id time-out ( local function for receipt of transport message without explicit use of the message passing primitives. Result is message type. If time-out<0 "hanging read" is implied. ) T-RESTART < not specified > tcep-id ( local procedure to ask the transport station to restart itself completely. This affects all users currently attached to the station. They will be informed by a t-disconnect packet that their connections are broken.) T-STOP < not specified > tcep-id ( local procedure to ask the transport station to close all datapaths and stop its execution.) T-RESTART and T-STOP are meant for debugging use only and should not be used in a normal user program. 4. The Message Passing System. ------------------------------ Our implementation of the OSI model utilizes message passing between concurrently executing processes. Most operating systems have at least rudimentary possibilities to handle this. To make the implementation as easily portable as possible we have designed an interface for the message passing system to support the required services of this kind. The model used is one of message channels. A channel can be established by issuing a msg-call to another process listening at a listening port. The listening process (this is typically the Transport Station itself) must be ready to receive messages from any userprocess at any time. The establishing of the channel is handled inside the message-passing interface and requires no interaction from the using processes. The channel can be shut down by either side at any time (though the process at the listening site cannot shut down channels selectively) by using the msg-close or msg-mclose primitives. An attempt to send a message on a channel can always fail. This means either that the other process has shut down the message channel in an orderly manner or that an error has occurred inside the message passing system. Note the asymmetry in the primitives used: Listener: MSG-ATTACH, MSG-MPXGET, MSG-MCLOSE Initiator: MSG-CALL, MSG-GET, MSG-CLOSE Both: MSG-INIT, MSG-ALLOCATE, MSG-RELEASE, MSG-PUT The Buffers. ============ The abstract message passing system contains a pool of message frames of type 'buffer'. Message frames are identified using pointers of type 'bufptr'. The allocation and deallocation of message frames is administered dynamically using the primitives 'msg_allocate' and 'msg_release' respectively. It is important to understand that this allocation/deallocation is only an abstract concept describing the way the message passing system should appear to a user of it. In a particular implementation these primitives could be mapped onto some other mechanism. The possible operations on the message frames of type 'buffer' are defined by a set of procedures. The subfields in the 'buffer' type records should not be altered using an ordinary assignment statement but only through this set of procedures. The sending of messages between processes is handled using a concept of 'message channels'. A channel is initiated by one process by use of the primitive msg_call and is identified with a channel identifier which is an integer. Once the channel is succesfully established, the initiator can use the primitive msg_put to send message frames to the other process and the primitive msg_get to receive message frames from it. The other process on the other hand is more passive. It informs the message passing system that it is ready to establish channels by using the primitive msg_attach. This process is called the 'listener' and it is implied that it is ready to establish several channels to all users of the message passing system. Therefore a different primitive is used to receive messages on this set of the channels, msg_mpxget. To identify the set of channel identifiers currently associated with this process the parameter 'refno' of type integer is used. The listener can also send messages on a channel using the primitive msg_put. The initiator can release the channel by using the primitive msg_close. The listener can release all channels in its set of channels by using the primitive msg_mclose. A process can be both initiator and listener at the same time. An example of this is the transport station which is initiator for the channel to the net entity and listener for the channels to the different transport service users. Implementation suggestions: =========================== The implementation of these primitives might vary. It could involve copying of the contents of the message frames or possibly just a transfer of pointers to a globally known area where the buffers reside. On some systems some of them /like msg_init/ might not be necessary. How the message passing is used by the transport station: The transport station and the associated interfaces to the net-entity and the t-users are designed to demand only one buffer at a time. (One for TSAP-HAND, one for the user program.) Therefore the primitives msg_allocate and msg_release can be implemented as a reservation mechanism for one buffer if the sole purpose of the interface is to facilitate portation of the transport station software. The model is general though and it can not be guaranteed that future software based on this model will be constructed in this way. Message Passing Facility Primitives. ==================================== Primitive Explanation --------- ----------- MSG-INIT initialize message passing system MSG-ALLOCATE allocate buffer MSG-RELEASE release buffer MSG-ATTACH make a name available for connections through the message passing system, establish a listening site, ("I am listening for several calls") MSG-CALL find out if a given name is attached to the message passing system, establish a connection channel to it and return channel-identifier MSG-CLOSE shut down communications channel that has been opened using MSG-CALL MSG-MCLOSE shut down all communications channels established through calls to a listening site MSG-GET check if a message has been received on a channel established with MSG-CALL, if so return it, otherwise return with error code MSG-MPXGET check if a message has been received on any of the channels established at a listening site, if so return it and a channel identifier, otherwise return with error code MSG-PUT send message on a channel Certain primitives operate on the buffers used in the message passing system and are included in the file BUFF-PROC. Primitive Explanation --------- ---------- length(buff) returns valid length of buffer stringcurpos(buff) returns current position in buffer zstring(buff) clears buffer resetstring(buff) resets current position putbyte(buff,integer) write octet to buffer, increment current position pointer charstr(chars,buff) copy contents of char array[16] to buff (used to put string constants in a buffer) putword(buff,integer) write a word (two octets) to buffer, changebyte(buff,i,val) change the byte i in buff to val lookbyte(buff,i) returns value in buff[i] getbyte(buff) return next octet from buffer getword(buff) return next word from buffer morebytes(buff) check if there are more unread bytes in buff getstring(buff1,buff2,length) copy length octets from buff1 to buff2, buff2 is cleared first putstring(buff1,buff2) append buff2 to buff1 copystring(buff1,buff2,length) append length octets from buff1 to buff2 writestr(buff) write buffer to terminal etc. 5. Conclusions and remarks. ======================== We have chosen to use message passing between concurrently running processes to implement the transport station. The interfaces to the network-service and the message passing service must be written locally using the procedure heads of our design. Thereafter the transport station could be compiled and run as a background program. The user interface is meant to be included in the user program. It could also be rewritten in another language to make it possible to use the service not only from PASCAL programs. The use of the message passing system is hidden from the user who only applies the transport service interface procedures to accomplish the different services. The compiler used is NORD Pascal version H running under Sintran/III version G using the software service XMSG and the X25 service software supplied by Norsk Data. Another possible approach to this problem is to let a procedure interface take care of the decoding. A "listener" who takes care of incoming calls must be active in the host in any case to ensure that the protocol is handled properly (i.e. calls to a user who is not attached to the TSAP should be properly disconnected). We find that the approach used in the current implementation is quite appropriate for the purpose, although some improvements could be made to speed and memory utilization in the program. The current implementation copies the buffers also where it is not absolutely necessary. It has been our opinion that the readability that comes from using elementary primitives like putbyte/getbyte on the buffers instead of writing into them in a random access fashion is worth the extra overhead that follows this model. It should also be noted that a multi-user system like SINTRAN/III that we have used has in itself so much runtime overhead that the extra cost of copying the buffers is of no significance. It is, though, possible to optimize the transport station so that the buffer space is used in a better way without modifying the model. Acknowledgements: Thanks to Jan Linnell, Andrzej Ciepilewski and Manuel Guzman at the Dept. of Telecommunications and Computer Systems (TTDS) of The Royal Institute of Technology, Stockholm for valuable remarks to this document and to Hans Nilsson, project leader for the SUNET project, for guidance in the implementation work and design and coding of the IPC and network layer interfaces. Appendix A: State Transitions in a TCEP. ============================ The state of a TCEP can be altered by messages from the users in both ends. The messages from the local user are encoded and passed using the message passing service to the transport service program. This is accomplished using the request procedures in the user interface package. The messages from the remote user arrive in n-data packets and are disassembled by the transport service program. Illegal messages from the net like n-int, n-disc, n-reset etc. also lead to a state transition in the TCEP connected to the NCEP receiving messages. In all these cases the state is reset to connect-ready, the TCEP disconnected from the NCEP and the local user informed by sending a t- disc message to him. The messages t-rst and t-halt are meant for debugging use only and should not be included in normal user interaction. Illegal messages from users in both ends or illegal messages from the network layer lead to disconnection of the transport connection. The state of the tcep will then be set to connect-ready and the users will be informed by a t-disc message to the local user and a n-disc message to the net disconnecting the remote user. The state diagram below describes the state transitions occurring when the transport service program receives user packets from either side of the connection a disconnection indication received from the Transport Protocol Handler always leads to the state 'connect-ready' but this is not shown in the picture in order to simplify it. State Transitions Of a TCEP (Transport Connection Endpoint) =========================================================== Initiated by Transport Protocol Messages (class 0): =================================================== --------------------- ! initial ! --------------------- ^ ! t-att t-det ! V --------------------- ! connect-ready ! --------------------- t-conn ! ! cr-tpdu V V ------------------ ----------------- ! req-establish ! ! ind-establish ! ------------------ ----------------- cc-tpdu ! ! t-acc V V ------------------ ! connected ! ------------------ t-data ! ^ dt-tpdu ->_____! t-drdy APPENDIX B: State Transition Table for TCEP. (Class 0) ------------------------------------------ CURRENT STATE INPUT ACTION OUTPUT NEXT STATE ======================================================================== all states t-rst shut tceps t-disc tceps:initial and nceps n-disc nceps:n-initial ------------------------------------------------------------------------ all states t-halt shut tceps t-disc end of service and nceps, n-disc stop service ======================================================================== initial t-att get tcep n-disc connect-ready ======================================================================== connect- t-det shut tcep n-disc initial -ready and ncep ------------------------------------------------------------------------ connect- t-conn store cr-tpdu n-conn req-establish -ready packet, assign ncep to tcep ======================================================================== req- n-accept connect nceps n-data req-establish -establish send cr-tpdu as n-data ------------------------------------------------------------------------ req- t-disc shut tcep t-disc connect-ready -establish n-disc ------------------------------------------------------------------------ req- cc-tpdu inform user t-acc connected -establish about n-drdy connection ------------------------------------------------------------------------ req- dr-tpdu shut tcep t-disc connect-ready -establish n-disc ------------------------------------------------------------------------ req- err-tpdu shut tcep t-disc connect-ready -establish n-disc ======================================================================== ======================================================================== ind- t-disc shut tcep t-disc connect-ready -establish n-disc ------------------------------------------------------------------------ ind- t-acc send cc-code n-data connected -establish ------------------------------------------------------------------------ ind- dr-tpdu shut tcep t-disc connect-ready -establish n-disc ------------------------------------------------------------------------ ind- err-tpdu shut tcep t-disc connect-ready -establish n-disc ======================================================================== connected n-drdy increment t-drdy connected send-credit ------------------------------------------------------------------------ connected t-drdy increment n-drdy connected receive-credit ------------------------------------------------------------------------ connected t-disc shut tcep t-disc connect-ready n-disc ------------------------------------------------------------------------ connected dr-tpdu shut tcep t-disc connect-ready n-disc ------------------------------------------------------------------------ connected t-data buffer data, n-data connected send if t-drdy buffer full ------------------------------------------------------------------------ connected dt-tpdu send tpdu t-data connected content to user ======================================================================== APPENDIX C: ================================================================== A Description in Backus-Naur Form of the TPDU-formats. (Class 0). ================================================================== < TPDU > ::= < < header > < data > > < header > ::= < < li > < fixed part > < variable part > ! < empty > > < data > ::= < < octet > < empty > ! < data > > ( implicit size ) < li > ::= < octet > ( value 255 reserved for extensions > < fixed part > ::= < < < cr-code > < 0-octet > < 0-octet > < source reference > < class > > ! < < cc-code > < destination reference > < source reference > < class > > ! < < dr-code > < destination reference > < source reference > < reason > > ! < < dt-code > < eot > < tpdu-nr > > ! < < err-code > < destination reference > < reject cause > > > < variable part > ::= < < parameter > < variable part > ! < empty > > < destination reference > ::= < < octet > < octet > > < source reference > ::= < < octet > < octet > > < class > ::= < octet > < reason > ::= < octet > < reject cause > ::= < octet > < eot > ::= < bit > < tpdu-nr > ::= < < bit > < bit > < bit > < digit > > < parameter > ::= < < parameter code > < parameter length indication > < parameter value > > < parameter code > ::= < octet > ( 255 reserved for extensions ) ( b7b8=01 -> CCITT parameter ) ( b7b8=10 -> ISO parameter ) ( b7b8=11 -> Common parameter ) < parameter length indication > ::= < octet > < parameter value > ::= < < octet > < octet > ! < empty > > ( number of octets given in parameter length indication field ) < octet > ::= < < digit > < digit > > < digit > ::= < bit > < bit > < bit > < bit > < 0-octet > ::= < < 0-digit > < 0-digit > > < 0-digit > ::= < < 0 > < 0 > < 0 > < 0 > > < bit > ::= < < 0 > ! < 1 > > < empty > ::= < > ======================================================================== Appendix D: A Description of the 4/5-interface. =================================== The interface between layers 4 and 5 is implemented as two sets of procedures: 1) Lowest we have interface routines to pack and unpack the occurring messages and send them to the transport station. These procedures are contained in user-proc and have no knowledge whatsoever of the state of the TCEPs it services. 2) On top of (1) we have the state-handling interface routines. Declarations for this interface are contained in 'INTER45-type' , 'INTER45-const', 'INTER45-var' and 'INTER45-proc' respectively. These routines give a user of the transport layer access to the basic functionality of it without the need of an extensive state automaton. The TCEPs (Transport Connection Endpoints) on this level are considered to be in either of three states: closed,listening or open. The phases of connection and disconnection as well as the handling of incoming credit packets are handled implicitly by the procedures which give these functions: a) Try to establish a transport connection (with timeout for failure). b) Try to establish a transport layer listener. c) Listen for incoming calls on listener-TCEP with time_out. If an incoming call is detected during this time the call is answered positively and the user is informed on the identity of the remote party. d) Shut down a connected TCEP and deallocate its message passing channel. e) Try to send a (TIDU) Transport Interface Data Unit if credits are available and a connection exists. If the parameter careful_send is true the attempt fails if an incoming data-packet is available on the message passing channel. f) Try to receive incoming data on a specified previously opened TCEP. The attempt ends either with failure or with the receipt of a tidu from the remote party within the specified time. Expedited data cannot be handled by this interface but are considered to be protocol errors if occurring. These interface primitives restrict the possible sequences of interactions on the 4/5 interface to a minimum, thereby simplifying the stateautomaton for layer 5 regarding its contact with the transport layer. The interface can prohibit the user from sending data if an unprocessed incoming packet is present. Primitive Precondition State Resulting State ========== ================== =============== Success: Failure: t_init_interface -- all closed -- t_est_conn -- open closed t_est_listener -- listening closed t_listen listening open listening/closed t_send open open open/closed t_receive open open open/closed t_give_cdts open open closed shut_tcep -- closed -- -------------------------------------------------------------------------- *)