Movatterモバイル変換

Network Working Group                                   ISORequest for Comments:  892                              December 1983ISO Transport Protocol SpecificationThis document is distributed as an RFC for information only.It does not specify a standard for the ARPA Internet.Note:  This document appeared in:ISO/TC97/SC16/WG6.  Information Processing Systems - Open Systems    Interconnection - Transport Protocol Specification.  Computer    Communication Review 12, 3-4 (July/October 1982), pp.  24-67.and differs from it only in format.Table of Contents0.   Introduction1.   Scope and Field of Application2.   ReferencesSection One - General3.   Definitions4.   Symbols and Abbreviations5.   Overview     5.1  Service provided by the transport layer     5.2  Service assumed from the network layer     5.3  Functions of the transport layer     5.4  Model of the transport layerSection Two - Transport Protocol Specification6.   Protocol Mechanisms     6.1  Assignment to network connection     6.2  Transport protocol data unit (TPDU) transfer     6.3  Data TPDU length and segmenting     6.4  Concatenation and separation     6.5  Connection establishment     6.6  Connection refusal     6.7  Release     6.8  Implicit termination     6.9  Spurious disconnect     6.10 Data TPDU numbering     6.11 Expedited data transfer     6.12 Reassignment     6.13 Reassignment after failure

ISO Transport Protocol Specification                                    Page 2International Standards Organization     6.14 Retention until acknowledgement of TPDUs     6.15 Resynchronization     6.16 Multiplexing and demultiplexing     6.17 Explicit flow control     6.18 Checksum     6.19 Frozen references     6.20 Retransmission on timeout     6.21 Resequencing     6.22 Inactivity control     6.23 Treatment of protocol errors     6.24 Splitting and recombining7.   Protocol Classes     7.0  Protocol description of class 0:  simple class     7.1  Protocol description of class 1:  basic error recovery class     7.2  Protocol description of class 2:  multiplexing class     7.3  Protocol description of class 3:  error recovery and multiplexing                                            class     7.4  Protocol description of class 4:  error detection and recovery class8.   Encoding     8.1  Summary     8.2  Structure     8.3  Connection Request (CR)     8.4  Connection Confirm (CC)     8.5  Disconnect Request (DR)     8.6  Disconnect Confirm (DC)     8.7  Data (DT     8.8  Expedited Data (ED)     8.9  Data Acknowledgement (AK)     8.10 Expedited Data Acknowledgement (EA)     8.11 Reject (RJ)     8.12 TPDU Error (ERR)Section Three  -  Conformance9.   Conformance0.   Introduction        The Transport Protocol Standard is one of a set of InternationalStandards produced to facilitate the interconection of computersystems.  The set of standards covers the services and protocolsrequired to achieve such interconnection.        The Transport Protocol Standard is positioned with respect toother related standards by the layers defined in the Reference Modelfor Open Systems Interconnection (ISO 7498).  It is most closelyrelated to, and lies within the field of application of the Transport

ISO Transport Protocol Specification                                    Page 3International Standards OrganizationService Standard (DP aaaa).  It also uses and makes reference to theNetwork Service Standard (DP bbbb), whose provisions it assumes inorder to accomplish the transport protocol's aims.  Theinterrelationship of these standards is depicted in Figure 1.-----------------------------------TRANSPORT SERVICE DEFINITION----- Transport                --Reference to aims--------------- Protocol Specification            --Reference to assumptions--------------------------------------------NETWORK SERVICE DEFINITION------Figure 1  -  Relationship between the transport protocol and adjacent             services        The standard specifies a common encoding and a number ofclasses of transport protocol procedures to be used with differentnetwork qualities of service.        It is intended that the Transport Protocol should be simplebut general enough to cater for the total range of Network Servicequalities possible, without restricting future extensions.        The protocol is structured to give rise to classes of protocolwhich are designed to minimize possible incompatibilities andimplementation costs.        The classes are selectable with respect to the Transport andNetwork Services in providing the required quality of service for theinterconnection of two session entities (note that each class providesa different set of functions for enhancement of service qualities).        This protocol standard is concerned with optimisation of networktariffs and the following qualities of service:     a)  different throughput rates;     b)  different error rates;     c)  integrity of data requirements;     d)  reliability requirements.        The aim of this standard is primarily to provide a definitionfor implementors.  Since the protocol is complex, the document containsmuch material which is advisory or descriptive, but mandatoryrequirements on implementations are clearly identified.        It should be noted that, as the number of valid protocol sequencesis very large, it is not possible with current technology to verify that animplementation will operate the protocol defined in this documentcorrectly under all circumstances.  It is possible by means of testing

ISO Transport Protocol Specification                                    Page 4International Standards Organizationto establish confidence that an implementation correctly operates theprotocol in a representative sample of circumstances.  It is, however,intended that this standard can be used in circumstances where twoimplementations fail to communicate in order to determine whether oneor both have failed to operate the protocol correctly.        The variations and options available within this standard areessential to enable a Transport Service to be provided for a widevariety of applications over a variety of network qualities.  Thus, aminimally conforming implementation will not be suitable for use inall possible circumstances.  It is important therefore to qualify allreferences to this standard with statements of the options provided orrequired or with statements of the intended purpose of provision oruse.1.      Scope and Field of Application1.1     This International Standard Specifies:        a)  five classes of procedures                1) Class 0.  Simple class;                2) Class 1.  Basic error recovery class;                3) Class 2.  Multiplexing class;                4) Class 3.  Error recovery class;                5) Class 4.  Error detection and recovery class,                for the transfer of data and control information from                one transport entity to a peer transport entity;        b)  the means of negotiating the class of procedures to be            used by the transport entities;        c)  the encoding of the transport protocol data units used for            the transfer of data and control information;        d)  the functional requirements of equipment within a            computer system claiming to implement these procedures.1.2     The procedures are defined in terms of:        a)  the interactions between peer transport entities through            the exchange of transport protocol data units;        b)  the interactions between a transport entity and the            transport service user in the same system through the exchange of            transport service primitives;        c)  the interactions between a transport entity and the            network service provider through the exchange of network

ISO Transport Protocol Specification                                    Page 5International Standards Organization            service primitives.1.3     This International Standard is applicable to equipment which        supports the Transport Layer of the OSI Reference Model and which        wishes to interconnect in an open systems environment.2.      ReferencesISO 7498        Information processing systems - Open systems inter-                connection - Basic Reference ModelDP aaaa         Information processing systems - Open systems inter-                connection - Transport service definition (N1169).DP bbbb         Information processing systems - Open systems inter-                connection - Connection-oriented network service                definition (N729)Section One - General3.      Definitions3.1     Equipment:Hardware or software or a combination of both; it        need not be physically distinct within a computer system.3.2     Transport service user:An abstract representation of the        totality of those entities within a single system that make        use of the transport service.3.3     Network service provider:An abstract machine which models        the totality of the entities providing the network service,        as viewed by a transport entity.        Explanatory Notes        1.  Definitions 3.1 to 3.3 relate to terms used in clause 1.        2.  This standard makes use of the terms, concepts, and            definition defined in ISO 7498.4.      Symbols and Abbreviations4.1     Data Units        TPDU    Transport protocol data unit        TSDU    Transport service data unit        NSDU    Network service data unit4.2     Types of transport protocol data units

ISO Transport Protocol Specification                                    Page 6International Standards Organization        CR TPDU         Connection request TPDU        CC TPDU         Connection confirm TPDU        DR TPDU         Disconnect request TPDU        DC TPDU         Disconnect confirm TPDU        DT TPDU         Data TPDU        ED TPDU         Expedited data TPDU        AK TPDU         Data acknowledge TPDU        EA TPDU         Expedited acknowledge TPDU        RJ TPDU         Rejected TPDU        ERR TPDU        Error TPDU4.3     TPDU fields        LI              Length indicator (field)        CDT             Credit (field)        TSAP-ID         Transport service access point identifier                        (field)        DST-REF         Destination reference (field)        SCE-REF         Source reference (field)        EOT             End of TSDU mark        TPDU-NR         DT TPDU number (field)        ED-TPDU-NR      ED TPDU number (field)        YR-TU-NR        Sequence number response (field)4.4     Parameters        T (R)           Receive sequence number        T (S)           Send sequence number4.5     Timer variables        T1              Elapse time between retransmissions        N               The maximum number of retransmissions        L               Bound for the maximum time between the                        decision to transmit a TPDU and the receipt of                        any response relating to it        T-WAIT          Maximum time for a reassignment to take place                        before TC failure is assumed        I               Inactivity timer - Maximum time allowed to                        elapse between receipt of TPDUs before TC                        failure is assumed        W               Window timer - Maximum interval between trans-                        mission of up to date window information4.6     Other variables        n               The number of bits in the sequence number                        field        p               The number of bits in the credit field of a                        CR, CC or AK TPDU

ISO Transport Protocol Specification                                    Page 7International Standards Organization4.7     Miscellaneous        TS-user         Transport service user        TSAP            Transport service access point        NSAP            Network service access point        TC              Transport connection        NC              Network Connection5.      Overview of the Transport Protocol5.1     Service Provided by the Transport Layer        The services provided by the protocol described in thisdocument are connection-oriented services.  They are defined indocument DP aaaa.  The Transport Service primitives provided aresummarized in Figure 1.

ISO Transport Protocol Specification                                    Page 8International Standards Organization        Primitive                               Parameters------------------------------------------------------------------------T-CONNECT       Request                 To Transport Address, From                Indication              Transport Address, Expedited                                        Data Option, Quality of                                        Service, TS-User data.------------------------------------------------------------------------T-CONNECT       Response                Responding Address, Quality                Confirmation            of Service, Expedited Data                                        Option, TS-User data.------------------------------------------------------------------------T-DATA          Request                 TS-User data.                Indication------------------------------------------------------------------------T-EXPEDITED     Request                 TS-User data.DATA            Indication------------------------------------------------------------------------T-DISCONNECT    Request                 TS-User data.------------------------------------------------------------------------T-DISCONNECT    Indication              Disconnect reason, TS-User                                        data.------------------------------------------------------------------------                Figure 1.  Transport Service Primitives5.2     Service Assumed from the Network Layer        The transport protocol described in this document assumes ofthe Network Services described in DP bbbb.  The Network Serviceprimitives used are summarized in Figure 2.

ISO Transport Protocol Specification                                    Page 9International Standards Organization        Primitive               X/Y             Parameters      X/Y/Z------------------------------------------------------------------------N-CONNECT  Request               X              Called Address,    X           Indication            X              Calling Address,   X           Response              X              NS-User data,      Z           Confirmation          X              QOS.               X------------------------------------------------------------------------N-DATA     Request                X              NS-User data,      X           Indication             X              Conf. Request      Y------------------------------------------------------------------------N-DATA      Request               YACKNOWLEDGE Indication------------------------------------------------------------------------N-EXPEDITED Request               YDATA        Indication                            NS-User data       Y------------------------------------------------------------------------N-RESET      Request              X             Indication           X             Response             X             Confirmation         X------------------------------------------------------------------------N-DISCONNECT Request              X               NS-User data       Z             Indication           X------------------------------------------------------------------------        X - The Transport Protocol assumes that this facility is            provided in all networks.        Y - The Transport Protocol assumes that this facility is            provided in some networks and a mechanism is provided            to optionally use the facility.        Z - The Transport Protocol does not use this parameter.                Figure 2.  Network Service Primitives5.3     Functions of the Transport Layer5.3.1   Connection Oriented Functions5.3.1.1  Overview of Functions        The functions in the transport layer are at least thosenecessary to bridge the gap between the services available from thenetwork layer and those to be offered to the transport users.        The functions in the transport layer are concerned with theenhancement of quality of service, including all aspects of costoptimization.  They are described below; the descriptions are groupedinto those concerned with the establishment phase, the data transfer

ISO Transport Protocol Specification                                   Page 10International Standards Organizationphase, and the release phase.5.3.1.1.1  Establishment Phase        The goal of the establishment phase is to establish atransport connection, i.e., between two transport users.  Thefunctions of transport layer during this phase must match therequested class of services with the services provided by the networklayer as follows:        o  Select network service which best matches the requirement           of the TS-user taking into account charges for various           services.        o  Decide whether to multiplex multiple transport connection           onto a single network connection.        o  Establish the optimum TPDU size.        o  Select the functions that will be operational upon entering           the data transfer phase.        o  Map transport addresses onto network addresses.        o  Provide a means to distinguish between two different           transport connections.        o  Transportation of user's data.5.3.1.1.2  Data Transfer Phase        The purpose of the data transfer phase is to permit two-waysimultaneous transport of TSDUs between the session entities connectedby the transport connection.  This purpose is achieved by means oftwo-way simultaneous communication in the Transport protocol and bythe following functions. Each of these functions is used or not usedin accordance with the result of the selection performed in theestablishment phase.        o  Concatenation and Separation           A function used to collect several TPDUs into a single           NSDU; the destination transport entity separates the TPDUs.        o  Segmenting and Reassembling           The splitting of a single data TSDU into multiple TPDUs           which are reassembled into their original format at the           destination.

ISO Transport Protocol Specification                                   Page 11International Standards Organization        o  Multiplexing and Demultiplexing           A function used to share a single network connection           between two or more transport connections.        o  Splitting and Recombing           A function allowing the simultaneous use of two or more           network connections to support the same transport connec-           tion.        o  Flow Control           A function used to regulate the flow of TPDUs between two           transport entities on one transport connection.        o  Error Detection           A function used to detect the loss, corruption,           duplication, misordering or misdelivery of TPDUs.        o  Transport Connection Identification           A means to uniquely identify a transport connection           between the pair of transport entities supporting the           connection during the lifetime of the transport           connection.        o  Error Recovery           A function used to recover from detected and signalled           errors.        o  Expedited Data           A function used to bypass the flow control of normal data           TPDU.  Expedited data TPDUs' flow is controlled by           separate flow control.        o  TSDU Delimiting           A function used to determine the beginning and ending of           a TSDU.5.3.1.1.3  Release Phase        A function to provide a disconnection of the transport        connection, regardless of the current activity.5.3.1.2  Classes and Options

ISO Transport Protocol Specification                                   Page 12International Standards Organization        A class defines a set of functions.   In this protocol five        classes are defined:        o  Class 0:  Simple Class        o  Class 1:  Basic Error Recovery Class        o  Class 2:  Multiplexing Class        o  Class 3:  Error Recovery and Multiplexing Class        o  Class 4:  Error Detection and Recovery Class.        Note that with the exception of classes 0 and 1, transport        connections of different class may be multiplexed together        onto the same network connection.5.3.1.2.2  Options within Classes        Options define potential functions which may be used within        a class.5.3.1.2.3  Negotiation        Classes and options within classes are negotiated during        the connection establishment phase.5.3.1.2.4  Choice of the Class of Protocol        The choice will be made by the transport entities according        to:        o  the users requirement expressed via T-CONNECT service           primitives.  In particular, for the choice of the           class of protocol, the following rules apply:           - if the TS-User requests either transmission of             user data during the connection phase, or use of             Expedited data transfer, then Class 0 cannot be             selected.           - if the TS-User requests use of Expedited data             transfer, then Class 2 with the non-explicit             flow control option cannot be selected.        o  the quality of the available Network services;        o  the user required service versus cost ratio           acceptable for the transport user.        The following is a classification of network services in termsof quality with respect to error behavior relative to the userrequirements.  Its main purpose is to provide a basis for the decisionregarding which class of transport connection should be used on top of

ISO Transport Protocol Specification                                   Page 13International Standards Organizationa given network connection.        Type A: Network connection with acceptable residual error                rate (for example not signalled by 'clear' or 'reset')                and acceptable rate of signalled failures.        Type B: Network connections with acceptable residual error                rate (for example not signalled by 'clear' or 'reset')                but unacceptable rate of signalled failures.        Type C: Network connections with residual error rate not                acceptable to the TS-user.        It is assumed that each transport entity is aware of thequality of service provided by particular Network connections.5.3.1.3  Potential Functions        The protocol described in this document does not include thefollowing set of functions which have been identified as potentialtransport layer functions:        o  provision for encryption        o  provision for accounting mechanisms        o  provision for status exchanges and monitoring of quality           of service        o  provision for blocking        o  temporary release of network connections5.4     Model of the Transport Layer             TSAP                               TSAP        Transport Protocol              Transport Protocol             Entity                           Entity              NSAP   -------                    NSAP  -------               |     (NSAP)                      |     (NSAP)               |       |                         |       |               |       |-------------------------|--------               |                                 |               -----------------------------------        A Transport Protocol entity within the Transport Layercommunicates with a Transport User through a TSAP by means of the

ISO Transport Protocol Specification                                   Page 14International Standards Organizationservice primitives as defined by the transport service definition DPaaaa.  Service primitives will cause or be the result of TransportProtocol Data Unit exchanges between the peer Transport Protocolentities supporting a Transport Connection.  These protocol exchangesare effected using the services of the Network Layer as defined by theNetwork Service Definition DP bbbb through one or more NSAPs.        Transport connection endpoints are identified in end systemsby an internal, implementation dependent, mechanism so that theTransport User and the Transport Protocol entity can refer to eachTransport connection.Section Two - Transport Protocol Specification6.      Protocol Mechanisms        Several functions are described as 'inherent' or 'pervasive'.Inherent functions must be invoked for every transport connection.Pervasive functions are optional, but if one is invoked for the firsttransport connection over a network connection, it must also be invokedfor any and all other transport connections which use that networkconnection during its lifetime.6.1     Assignment to Network Connection        Purpose:  Assignment of transport connections to network                  connections.        Network Service Primitives:        N-CONNECT        N-DISCONNECT        Description:        This function is inherent.        Before a transport connection can be created or used, it mustbe assigned to one (or more if splitting function is being used)network connection(s).  Both transport entities involved must becomeaware of this assignment.  A transport connection may be assigned to asuitable existing network connection; one or more new networkconnections may also be created for the purpose.        An existing network connection, which connects the relevanttransport entities, is unsuitable for assignment of a transportconnection if, for example:        o  the quality of service needed for the transport connection           can not be met by using or enhancing the network

ISO Transport Protocol Specification                                   Page 15International Standards Organization           connection.        o  the protocol class preferred or in use for the transport           connection is incompatible with the current usage of the           network connection as regards the use of pervasive           functions (e.g., multiplexing).        When a new network connection is created, the quality ofservice requested is a local matter, though it will normally berelated to the requirements of transport connection(s) expected to beassigned to it.        A Network Connection with no transport connections will beavailable after initial establishment or because explicitdisconnection of all the transport connections previously assigned toit has taken place.  Either Transport entity may as a localmatter choose to disconnect the Network Connection or assign otherTransport Connections to it.6.2     Transport Protocol Data Unit (TPDU) Transfer        Purpose:  To convey transport protocol data unit in user                  data fields of network service primitives.        Network Service Primitives        N-DATA        N-EXPEDITED DATA        Description:        This function is inherent.        The Transport Protocol Data Units (TPDUs) defined for theprotocol are listed in Figure 3.                TPDU name                Abbreviation        Connection Request                      CR        Connection Confirm                      CC        Disconnect Request                      DR        Disconnect Confirm                      DC        Data                                    DT        Expedited Data                          ED        Data Acknowledge                        AK        Expedited Acknowledge                   EA        Reject                                  RJ        TPDU Error                              ERR                Figure 3.  Transport Protocol Data Units

ISO Transport Protocol Specification                                   Page 16International Standards Organization        TPDUs are conveyed using the NS-User data parameters of theNetwork Service primitives, primarily with the N-DATA, but also withN-EXPEDITED primitives.        Transport entities shall accept all permissible assignments andmay issue any permissible assignments.  The permissible assignments ofTPDUs to these primitives are shown in Figure 4.  Concatenation ofTPDUs is also permitted (seesection 6.4).Primitive               Applicable TPDUs                        NoteN-DATA                  CR, CC, DR, DT, ED,                        AK, EA, RJ, DC, ERRN-EXPEDITED             ED, EA                                  1Notes:1.  This assignment is permissible only when using class 1 and when    the network expedited variant has been agreed.Figure 4.  Network Service Primitives which can convey TPDUs.6.3     Data TPDU Length and Segmenting        Purpose:  Mapping between one TSDU and TPDUs.        TPDUs and fields used:        DT        -  End of TSDU (1 bit)        Description:        The data field of Data TPDUs may contain any number of octetsup to an agreed maximum as negotiated at connection time.        A transport entity uses an End of TSDU mark as defined below:        In each Data TPDU a transport entity may indicate the end of aTSDU.        Category 1      Having the End of TSDU mark set to yes.  These                        TPDUs may or may not have the maximum length.        Category 2      Having the End of TSDU mark set to no.  These                        TPDUs do not necessarily have the maximum                        length.        A complete Data TPDU sequence is defined as being composed of

ISO Transport Protocol Specification                                   Page 17International Standards Organizationeither a single category 1 DT TPDU or consecutive category 2 followedby a category 1 DT TPDU.6.4     Concatenation and Separation        Pupose:  Conveyance of multiple TPDUs in one NSDU.        Description:        All TPDUs carry in their TPDU header a length indicator (seeSection 8.2.1).  Additionally, TPDUs are classified as either DataTPDUs or Control TPDUs.  Control TPDUs may or may not contain a datafield.  For TPDUs containing data the length of the data field isindicated by the length of the NSDU.  These provisions permit anynumber of Control TPDUs that may not contain data to be concatenatedwith a single control TPDU which may contain data or with a singleData TPDU.  The control TPDUs without data must precede the TPDU withdata, if any.  The number of TPDUs so concatenated is terminated bythe end of the NSDU.        The concatenated set of TPDUs may be for the same or differenttransport connections.  An implementation shall accept concatenatedTPDUs and may concatenate TPDUs before transmission.  The transportentity shall not send a concatenated set of TPDUs which exceeds twicethe overall maximum TPDU length for all the TCs assigned to thenetwork connection.6.5     Connection Establishment        Purpose:  Creation of a new transport connection.        Network Service Primitives:        N-DATA        TPDUs and fields used:        CR, CC        - source reference (16 bits)        - initial credit (if applicable)        - calling transport address (optional)        - called transport address (optional)        - user data (optional)        - TPDU size (optional)        - sequence number length (optional)        - checksum selection (optional)        - acknowledgement time (optional)        - quality of service (optional)        CR        - preferred protocol class

ISO Transport Protocol Specification                                   Page 18International Standards Organization        - alternative protocol classes (zero or more)        - version number (optional)        - security (optional)        - proposed options        CC        - destination reference (16 bits)        - selected protocol class        - selected options        Description:        This function is inherent:        A transport connection is established by means of onetransport entity (the initiator) transmitting a Connection Request(CR) TPDU to the other transport entity (the responder), which replieswith a Connection Confirm (CC) TPDU.  Before sending the CR TPDU, theinitiator assigns the transport connection being created to one (ormore if the splitting function is being used) network connection(s).It is this set of network connections over which the TPDUs are sent.During this exchange, all information and parameters needed for thetransport entities to operate must be exchanged or negotiated.        The following information is exchanged:        o  references.  Each transport entity chooses a reference which           is 16 bits long and which is arbitrary except for the following           restrictions:           - it cannot already be in use or "frozen" (see "Frozen             References",Section 6.19).           - it cannot be zero.        Each transport entity is responsible for selecting theReference which the partner will use.  This mechanism is symmetricaland therefore avoids the need to assign a status of master or slave topartners and avoids call collision.  This mechanism also providesidentification of the transport connection independent of the networkconnection. The range of References used for transport connections, ina given transport entity, is a local system parameter.        o  addresses (optional).  Indicate the calling and called           transport service access points.  When either network           address unambiguously defines the transport address this           information may be omitted.        o  initial credit.  Only relevant for classes which include           the Explicit Flow Control Function.

ISO Transport Protocol Specification                                   Page 19International Standards Organization        o  user data.  Not available in class 0.  Up to 32 octets in           in other classes.        The following negotiations take place:        o  protocol class.  The initiator shall propose a preferredclass and any number of alternatives.  (Except that no alternatives areallowed when class 0 is the preference.)  The initiator should assumewhen it sends the CR TPDU that its preferred class will be agreed to,and commence the functions associated with that class.        Note:  This means, for example, that when a class whichincludes resynchronization (see "Resynchronization",Section 6.15) ispreferred, resynchronization will occur if a reset is signalled duringconnection establishment.        When the responder has decided which class is to be used, itshall indicate this in the CC TPDU and shall invoke the appropriatefunctions for the class.  The responder may select the preferredclass, or any of the alternative classes or may select class 0 ifclass 1 is proposed or class 2 if class 3 or 4 is proposed. (seeSection 9)        If the preferred class is not selected, then on receipt of theCC TPDU, the initiator shall adjust its functions accordingly.        o  TPDU Size.  The initiator may propose a maximum size forTPDUs, and the responder may accept this value or respond with anyvalue between the proposed value and 128 in the set of valuesavailable (see "Encoding",Section 8).        o  sequence number length.  Either normal or extended isavailable.  When the sequence number is extended, the credit field (ifapplicable) is also extended.        o  checksum selection.  This defines whether or not TPDUs ofthe connection are to include a checksum.        o  version number.  This defines the version of the transportprotocol standard used for this connection.        o  security parameter.  This parameter and its semantics areuser defined.        o  quality of service parameter.  This defines the throughput,delay, priority and residual error rate.        o  The non-use of explicit flow control in class 2 isnegotiated.

ISO Transport Protocol Specification                                   Page 20International Standards Organization        o  The use of Network Receipt Confirmation and Networkexpedited is negotiated when class 1 is to be used.        The negotiation rules for the options are such that theinitiator may propose either to use or not to use the option.  Theresponder may either accept the proposed choice or select themandatory alternative defined inSection 9.        During the establishment phase of the transport connection,the use of the expedited data option field of CR/CC  allows bothTransport Service user to negotiate the use or non use of theexpedited data transport service as described in the transport servicedefinitions.        The following table summarizes the negotiation possibilitiesfor the options.                                Proposition Made        Possible                                by the Initiator        Selection by        Option                                          the ResponderTransport expedited data             Yes                  Yes or Notransfer service                     No                       NoUse of receipt confir-               Yes                  Yes or Nomation (class 1 only)                No                       NoUse of the network                   Yes                  Yes or Noexpedited variant                    No                       No(class 1 only)Non use of checksum                  Yes                  Yes or No(class 4 only)                       No                       NoNon use of explicit                  Yes                  Yes or Noflow control (class 2 only)          No                       NoUse of extended format               Yes                  Yes or No                                     No                       No        In class 2, whenever a transport entity requests or agrees tothe Transport Expedited data transfer service or to the use ofextended formats, it must also request or agree (respectively) to theuse of explicit flow control.6.6     Connection Refusal        Purpose:        Refusal of the transport connection.        TPDUs and fields used:

ISO Transport Protocol Specification                                   Page 21International Standards Organization        DR        -  reason (1 octet)        -  user data (maximum of 64 octets)        ERR        -  reject code (1 octet)        -  rejected TPDU parameter        Description:        If a transport connection cannot be accepted, the calledtransport entity shall respond to the CR TPDU with a DR TPDU.  Theclearing reason shall indicate why the connection was not accepted.The source reference field in the DR TPDU is set to zero to indicatean unassigned reference.        If the CR is regarded as an invalid TPDU, the called transportentity will respond by sending an ERR TPDU.  On receipt of this TPDU,the calling entity will regard the connection as closed.6.7     Release        Variants:  'implicit' or 'explicit'        Purpose:  Termination of the transport connection.        Network Service Primitives:        N-DISCONNECT (implicit variant only)        N-DATA        TPDUs and fields used:        DR        - clearing reason (1 octet)        - user data (maximum of 64 octets)        DC        Description:        This function is inherent.        In the 'implicit' variant, either transport entity disconnectsa transport connection by disconnecting the network connection towhich it is assigned.  Similarly when a transport entity is informedthat the network connection has been disconnected by the peertransport entity, this should be considered as a transportdisconnect.

ISO Transport Protocol Specification                                   Page 22International Standards Organization        In the 'explicit' variant, either transport entity transmits aDisconnect Request (DR) TPDU, and the other responds with a DisconnectConfirm (DC) TPDU.  When the DC TPDU is sent or received by atransport entity, that entity should consider the transport connectionnot to exist (note 1).  After the sending of a DR TPDU, other TPDUsreceived before the DC TPDU are ignored.  It is possible that adisconnect collision will occur, when both transport entities send aDR TPDU at about the same time.  This results in each transport entityreceiving a DR, after sending one.  Each transport entity shallconsider the received DR TPDU as a confirmation of its DR TPDU, andshall not send or expect to receive a DC TPDU.        The DR can convey a limited amount (up to 64 octets) of data.6.8     Implicit Termination        Purpose:  Termination of a Transport Connection on theoccurrence of a signalled error for which recovery functions are notoperative.        Network Service Primitives:        N-DISCONNECT Indication        N-RESET Indication        Description:        When, on the network connection to which a TransportConnection is assigned, an N-DISCONNECT or N-RESET Indication occurs,both transport entities shall consider that the transport connectionno longer exists, and so inform the session entities.Note 1:        When a connection has been released, after the exchange of DRand DC, the reference can be re-used immediately (except in Class 4,where the Frozen Reference function is used, seeSection 6.19).  Thisis because the releasing transport entity does not know with certaintythat the remote transport entity considers use of the reference to beended.  Therefore, the reference should not be re-used for furtherconnections.  (In practice, the reference may be re-used after areasonable period when it is possible to be reasonably certain thatthe remote transport entity will not continue to use it).6.9     Spurious Disconnect        Purpose:  To deal with the arrival of an "unknown" DR TPDU.        TPDUs and fields used:

ISO Transport Protocol Specification                                   Page 23International Standards Organization        DR, DC        - source reference        - destination reference        Description:        A DR TPDU can be received for a transport connection whichdoes not exist.  Rather than treating this as an error, a DC TPDUshould be send back which reflects the references of the DR TPDU.Note:        This only applies when one or more transport connections usinga multiplexing class exist over the network connection, or when notransport connections exist.  At other times it is a protocol error.6.10    Data TPDU Numbering        Variants:  'normal' or 'extended'        Purpose:   Numbering of DT TPDUs for use in recovery,                   flow control, or sequencing functions.        TPDUs and Fields Used:        DT        - TPDU-NR (7 or 31 bits)        Description:        DT TPDUs transmitted in each direction on a transportconnection bear a sequence number 'TPDU-NR'.  Its value in the firstDT TPDU in each direction after connection establishment will be zero.Thereafter each TPDU had 'TPDU-NR' one greater than the previous.Modulo 2**7 arithmetic is used in the 'normal' variant, and modulo 2**31in the 'extended' variant.        In the sections that follow, the relationships 'greater than'and 'less than' are used in connection with TPDU numbers.  In allsuch uses, the numbers being compared cover a range less than themodulus and in fact lie within a contiguous set of TPDU numbers calleda 'window'.  The window has a known starting TPDU number and finishingnumber.  The term 'less than' means 'occurring sooner in the windowsequence' and the term 'greater than' means 'occurring later in thewindow sequence'.6.11    Expedited Data Transfer        Variants:  'network expedited' or not        Purpose:  Provision of the expedited data service

ISO Transport Protocol Specification                                   Page 24International Standards Organization        Network Service Primitives:        N-DATA        N-EXPEDITED DATA        TPDUs and Fields Used:        ED        - ED TPDU-NR (7 or 31 bits)        EA        - YR-TU-NR (7 or 31 bits)        Description:        Each expedited TSDU is conveyed as the data field of an ExpeditedData (ED) TPDU.        Each ED TPDU received must be acknowledged by an ExpeditedAcknowledge (EA) TPDU.        There may only be one ED TPDU unacknowledged at any time for eachdirection of a transport connection.        In the 'network expedited' variant (available in class 1 only),ED and EA TPDUs are conveyed in the data fields of N-EXPEDITED DATAprimitives.  Otherwise, N-DATA is used.6.12    Reassignment        Purpose:  Assignment of a Transport Connection to a differentNetwork Connection.        TPDUs and Fields Used:        CR        - source reference        RJ, DR        - destination reference        Description:        When the Network Connection to which a Transport Connection wasassigned no longer exists, the Transport Connection can be assigned toanother Network Connection.        When one transport entity has assigned the Transport Connection,it is important that the other transport entity recognise to whichNetwork Connection it has been assigned.  This can only take place when it

ISO Transport Protocol Specification                                   Page 25International Standards Organizationhas received a TPDU for the Transport Connection on a Network Connectionwith calling and called network addresses which implythe same transport entities as the old.  The TPDU will have been sentas a result of the assigning transport entity commencing resynchronization,and will thus be a RJ, or a retransmitted CR or DR.        The Transport Connection shall be recognised as having beenassigned to the Network Connection on which the TPDU was received.6.13    Reassignment After Failure        Purpose:  Recovery from network provider initiated disconnect.        Network Service Primitives:        N-DISCONNECT Indication        Description:        When a N-DISCONNECT Indication arrives for the network connectionto which a transport connection is assigned, the transport connection mustbe reassigned by its initiator (see "Reassignment")        If the reassignment has not successfully occurred within a timeof T-wait seconds, then the transport connection must be considered asnon-existent by both transport entities.1        1.      The CR TPDU does not have a destination reference;                nevertheless it can be distinguished from a new                connection attempt by having the same source                reference.        NOTE:  The value of T-wait has to be agreed by the communicatingtransport entities.6.14    Retention Until Acknowledgement of TPDUs        Variants:  'confirmation of receipt' or 'AK'        Purpose:  To enable and minimize retransmission afterpossible loss of TPDUs.        Network Service Primitives:        N-DATA        N-DATA ACKNOWLEDGE        TPDUs and Fields Used:        CR, CC, DR, DC

ISO Transport Protocol Specification                                   Page 26International Standards Organization        RJ, AK, EA        - YR-TU-NR (7 or 31 bits)        DT        - TPDU-NR (7 or 31 bits)        ED        - ED TPDU-NR (7 or 31 bits)        Description:        Copies of the following TPDUs shall be retained upon transmissionto permit their later retransmission:                CR, CC, DR, DT, ED.        NOTE:  If DR is sent in response to CR there is no need toretain a copy of the DR.        In the 'confirmation of receipt' variant, applicable onlyin Class 1, transport entities receiving N-DATA Indications whichconvey DT TPDUs and have the confirmation request field set shallissue a N-DATA Acknowledge Request at the earliest possibleopportunity (1).        (1)     It is a local matter for each transport entity to                decide which N-DATA Requests should have the                confirmation request parameter set.  This decision                will normally be related to the amount of storage                available for retained copies of the DT TPDUs.                Use of the confirmation request parameter may                affect the quality of network service.        After each TPDU is acknowledged, as shown in Figure 5,the copy need not be retained.  Copies may also be discarded whenthe transport connection ceases to exist.        TPDU                            ACKNOWLEDGED BY        CR              receipt of CC, DR, or ERR, TPDU        DR              receipt of DC or DR (in case of collision)                        TPDU        CC              receipt of RJ, DT, AK, ED, EA TPDUs (or                        N-DATA ACKNOWLEDGE Indication.)        DT              N-DATA ACKNOWLEDGE Indication when the        (Note 1)        DT TPDU was sent before or with the oldest                        N-DATA which had the confirmation request

ISO Transport Protocol Specification                                   Page 27International Standards Organization                        field set.        DT              receipt of Data Acknowledge (AK) or        (Note 2)        Reject (RJ) TPDU for which 'YR-TU-NR'                        is greater than 'TPDU-NR' in the DT TPDU.        ED              receipt of EA TPDU for which 'YR-TU-NR'                        is equal to 'ED-TPDU-NR' in the ED TPDU.        Notes:        1.      Applies to 'confirmation of receipt' variant.        2.      Applies to 'AK' variant.                Figure 5.  Acknowledgement of TPDUs6.15    Resynchronization        Purpose:  To restore the connection to normal after anerror.        Network Service Primitives:        N-RESET Indication        TPDUs and Fields Used:        CR, DR, CC, DC        RJ, EA        - YR-TU-NR (7 or 31 bits)        DT        - TPDU-NR (7 or 31 bits)        ED        - ED TPDU-NR (7 or 31 bits)        Description:        After the reset of an underlying network connection,the resynchronization procedures below are carried out by bothtransport entities.        After a network connection failure, the reassignment afterfailure function is invoked and then the resynchronization function.The sequence of events at the two transport entities is the following:        Events at the transport entity initiating reassignment:        (the transport entity immediately commences resynchronization         by sending a TPDU)

ISO Transport Protocol Specification                                   Page 28International Standards Organization        o       if a CR is retained then retransmit it.        o       if a DR is retained then retransmit it.        o       otherwise, resynchronize data:                -       send RJ TPDU with 'YR-TU-NR' field set to                        the 'TPDU-NR' of the first unreceived DT                        TPDU                -       when RJ TPDU has been received retransmit any                        ED TPDUs then DT TPDUs which are unacknowledged                -       any ED TPDUs received which are duplicates shall                        be acknowledged (by EA TPDUs) and discarded.        Events at the other transport entity:        The transport entity shall not send any TPDUs until afterreceipt of the TPDU which commenced resynchronization.  This TPDUtherefore serves two purposes, namely indication of re-assignmentand commencement of resynchronization.        o       if the first received TPDU os a DR, then transmit                a DC TPDU.        o       if the first received TPDU is a CR and the transport                connection is not idle, this means that a CC TPDU is                retained:  then retransmit it followed by any ED TPDU                and then DT TPDUs which are outstanding (that may or                may not have been transmitted previously).        NOTE:  no TPDUs can be transmitted using network expedited untilCC becomes acknowledged, to prevent the network expedited overtaking theCC.        o       if the first received TPDU is a RJ, then act as follows:                -       if a DR TPDU is retained, then retransmit it                -       if a CC TPDU remains unacknowledged, then carry                        out the data resynchronization procedure described                        below                -       otherwise resynchronize data:                        -       send RJ TPDU with 'YR-TU-NR' field set to                                the 'TPDU-NR' of the first unreceived DT                                TPDU

ISO Transport Protocol Specification                                   Page 29International Standards Organization                        -       retransmit any ED TPDUs then DT TPDUs which                                are unacknowledged                        -       any ED TPDUs received which are duplicates                                should be acknowledged (by EA TPDUs) and                                discarded.        NOTE:  It is possible for a transport entity using the Class 1protocol to decide on a local basis to issue an N-RESET Request.  The effectof this request at the remote transport entity is to force it to performthe resynchronization mechanism.  This possibility may be used to removecongestion within the network connection.6.16    Multiplexing and Demultiplexing        Purpose:  Concurrent sharing of a network connection by severaltransport connections.        TPDUs and Fields Used:        CC, DR, DC, DT, AK, ED, EA, RJ, ERR        - destination reference        Description:        This function is pervasive.        When this function is in operation, more than one transportconnection can be simultaneously assigned to the same network connection.        Every TPDU (including DT TPDUs) must carry the destinationreference, to identify the transport connection to which it refers.6.17    Explicit Flow Control        Purpose:  Regulation of flow of DT TPDUs independently ofthe flow control in the other layers.        TPDUs and Fields Used:        CR, CC, AK, RJ        - CDT (4 or 16 bits)        DT        - TPDU-NR (7 or 31 bits)        AK, RJ        - YR-TU-NR (7 or 31 bits)        - subsequence number (optional)        - flow control confirmation (optional)

ISO Transport Protocol Specification                                   Page 30International Standards Organization        Description:        The mechanism depends on the class.  Thus the description canbe found in the section describing the class.6.18    Checksum        Purpose:  To detect corruption of TPDUs by the network serviceprovider.        TPDUs and Fields Used:        All TPDUs        - checksum (16 bits - 32 bits)        Description:        When a TPDU is to be transmited for a TC which has selected thechecksum option, the sending transport entity must generate a checksumfor the TPDU and store it in the checksum parameter in the variablepart of the TPDU header.  The checksum must be generated as follows:        1.      Set up the complete TPDU, including the header anduser data (if any).  The header must include the checksum parameter inits variable part.  The value field of the checksum parameter must beset to zero at this point.        2.      Initialize two variables to zero.  Let these variablesbe called C0 and C1.        3.      For each octet of the TPDU, including the header,variable part of the header and the user data, add the octet value toC0, and then add the value of C0 to C1.  Octets should be processedsequentially, starting with the first octet (the Length Indicator) andproceeding through the TPDU.  All addition is to be performed modulo 255.        4.      Calculate the value field of the checksum parameter asfollows.  Let the offset into the TPDU of the first octet of the valuefield be 'n' (where the first octet of the TPDU, the Length Indicatorof the header, is considered to be at offset 1).  Let the lengthof the TPDU, i.e. the number of times the above operation was repeated,be 'L'.  Let the first octet of the checksum value, i.e., the one at offset'n' be called 'X', and the second octet, at offset 'n+1', be called 'Y'.Then:        X = (((L - n) *  C0) - C1) modulo 255        Y = (((L - n + 1) * (-C0)) + C1) modulo 255        5.      Place the computed values of X and Y in the appropriateoctets of the TPDU.

ISO Transport Protocol Specification                                   Page 31International Standards Organization                                NOTE        An implementation may use one's complete arithmetic as an        alternative to modulo 255 arithmetic.  However, if either        of the checksum octets X and Y has the value minus zero        (i.e., 255) then it must be converted to plus zero        (i.e., 0) before being stored.        When a TPDU is received for a TC for which the checksum optionhas been selected, the TPDU must be verified to ensure that it has beenreceived correctly.  This is done by computing the checksum, using thesame algorithm by which it was generated.  The nature of the checksumalgorithm is such that it is not necessary to compare explicitly the storedchecksum bytes.  The procedure described below may be used to verify thata TPDU has been correctly received.        1.      Initialize two variable to zero.  Let these variablesbe called C0 and C1.        2.      For each octet in the received TPDU, add the value ofthe octet to C0 and then add the value of C0 to C1, starting with thefirst octet and proceeding sequentially through the TPDU.  Alladdition is to be performed modulo 255.        3.      When all octets have been sequentially processed, thevalues of C0 and C1 should be zero.  If either or both of them isnon-zero, the TPDU has been received incorrectly and the verificationhas failed.  Otherwise, the TPDU has been received correctly and theTPDU should be processed normally.                                NOTE        An implementation may use one's complement arithmetic as an        alternative to modulo 255 arithmetic.  In this case, if either        C0 or C1 has the value minus zero (i.e., 255) it is to be        regarded as though it was plus zero (i.e., 0)        If a checksum verification failure occurs, it is not possibleto determine the TC that the TPDU relates to, since the Reference fieldof the TPDU may have been received incorrectly.  Therefore, all TCsmultiplexed onto the same NC must be treated as though a network signallederror has occurred.6.19    Frozen References        Purpose:  To prevent re-use of a reference while TPDUs associatedwith the old use of the reference may still exist.        Description:  When a transport entity determines that a particularconnection has terminated, the reference shall be placed in a frozen state

ISO Transport Protocol Specification                                   Page 32International Standards Organizationduring which time it will not be reused.  The circumstances under whichthis is done, and the period of time for which the reference remainsfrozen depends on the class.6.20    Retransmission on Timeout        Purpose:  To cope with unsignalled loss of TPDUs by the networkservice provider.        TPDUs and Fields Used:        CR, CC, DR, DT, ED, AK        Description:        The description is given in the section related to class 4.6.21    Resequencing        Purpose:  To cope with misordering of TPDUs by the networkservice provider.        TPDUs and Field Used:        DT        - TPDU NR        ED        - ED TPDU NR        Description:        The description is given in the section related to class 4.6.22    Inactivity Control        Purpose:  To cope with unsignalled termination of a networkconnection.        TPDUs and Fields Used:        AK        Description:        The description is given in the section related to class 4.6.23    Treatment of Protocol Errors        Purpose:  To deal with invalid TPDUs.

ISO Transport Protocol Specification                                   Page 33International Standards Organization        TPDUs and Fields Used:        ERR        - reject cause        - TPDU in error (string of octets)        DR        - reason code        Description:        This function is inherent.        Any received TPDU which is invalid or which cannot be dealt with byany operative function, or which is regarded as a violation of the protocolrules of the class in use (e.g., receipt in a wrong state, window error,sequencing error, TPDU with incorrect format), shall be considered as aprotocol error.  Such an error shall be signalled to the transport entityresponsible by the sending of an TPDU Error (ERR) TPDU or by initiating arelease.  The ERR TPDU conveys the octets of the offending TPDU up toand including the octet where the error was detected.        In general, no further action is defined for the sender ofERR TPDU, since it is expected that the offender will either correctthe error, or close the connection.        Action to be done by the receiver depends on local implementationdecision; e.g., freeze the connection, report to management, disconnect.NOTES:        1.      Further action is a local implementation issue.  Careshould be taken by the transport entity receiving several invalid TPDUsor ERR TPDUs to avoid looping if the error is repeatedly generated.        2.      There are two cases in which specific action is definedfor the receiver of the ERR TPDU (see Sections6.6 and7.0.7).6.24    Splitting and Recombining        Purpose:  To allow a transport connection to make use ofmultiple network connections to provide additional resilience againstnetwork failure, to increase throughput, or for other reasons.        Description:        This function is available only in Class 4.        When this function is being used, a transport connection isassigned (seeSection 6.1) to multiple network connections. TPDUs for the

ISO Transport Protocol Specification                                   Page 34International Standards Organizationconnection may be sent over any assigned network connection.  Theresequencing function of Class 4 (seeSection 6.21) is used to ensurethat TPDUs are processed in the correct sequence.        If the use of Class 4 is not accepted by the remote transportentity following the negotiation rules, only the network connectionover which the CR TPDU was sent may be used for this transportconnection.        The splitting function should only be used where thesupporting network connections provide similar transmit delay.   Protocol Mechanism           Variant         0  1  2  3  4Assignment to Network Conn.                     *  *  *  *  *TPDU Transfer                                   *  *  *  *  *DT TPDU Length and Segmenting                   *  *  *  *  *Concatenation and Separation                       *  *  *  *Connection Establishment                        *  *  *  *  *Connection Refusal                              *  *  *  *  *Release                         implicit        *                                explicit           *  *  *  *Implicit Termination                            *     *DT TPDU Numbering               normal             *  m  m  m                                extended            (1)o o  oExpedited Data Transfer         network exp.      ao                                not "              m  *  *  *                                                     (1)Reassigment                                        *     *Reassignment after Failure                         *     *Retention until Acknowledge-    Conf. Receipt     aoment of TPDUs                   AK                 m     *  *Resynchronization                                  *     *Multiplexing and                                      *  *  *Demultiplexing

ISO Transport Protocol Specification                                   Page 35International Standards OrganizationExplicit Flow Control With                            m  *  *                      Without                   *  *  oChecksum   (use of)                                         m           (non-use of)                         *  *  *  *  oFrozen References                                           *Retransmission on Timeout                                   *Resequencing                                                *Inactivity Control                                          *Treatment of Protocol Errors                    *  *  *  *  *Splitting and recombining                                   *(1)  not applicable in class 2 when the non use of explicit flowcontrol is selected.7.      PROTOCOL CLASSES        The details of the implementation of the protocolmechanisms are in certain cases different for different classes.For this reason, the following table is not intended to provide acomplete description of the classes, but more to give an overview ofhow each class works.  The exact definition of the protocol is givenin the subsequent sections.                            KEY        *  include in the class (always)        m  mandatory function (negotiable but always implemented)        o  additional function (negotiable but not necessarily implemented)        ao additional function (negotiable but not necessarily implemented).             Use of this option depends on the willingness of both transport             entities and availability of network service.        na not applicable.7.0     PROTOCOL DESCRIPTION OF CLASS 0: SIMPLE CLASS7.0.1   Characteristics of Class 0        The characteristic of this class is that it providesthe simplest type of transport connection and fully compatible

ISO Transport Protocol Specification                                   Page 36International Standards Organizationwith the CCITT recommendations S.70 for Teletex terminals.        The class is designed for use in association withnetwork connections of type A (see 5.3.1.2.4.).7.0.2   Functions of Class 0        This class is designed to have minimum functionality.It provides only the functions needed for connectionestablishment with negotiation, data transfer with segmenting andprotocol error reporting.        Class 0 provides transport connections with flowcontrol based on the network service provided flow control, anddisconnection based on the network service disconnection.7.0.3   Protocol Mechanisms of Class 07.0.3.1  Connection Establishment Phase        Connection shall be made in accordance with thegeneral rules (Assignment of Network Connection, ConnectionEstablishment and Connection Refusal) with the followingrestrictions:        o  No exchange of user data is allowed.        o  Only TSAP-ID and TPDU size parameters are allowed.7.0.3.2  Data Transfer Phase        o  Segmenting  (DT TDPU length and Segmenting)        o  Detection and indication of procedural errors.7.0.3.3  Release Phase        There is no explicit transport connection releaseprocedure for this class.  The lifetime of the transport connectionis directly correlated to the lifetime of the network connection.7.0.4   Connection Establishment for Class 0        The connection establishment function is usedwith the contraint that only the transport entity which hasrequested the establishment of the network connection may send theCR TPDU.  If the calling transport entity receives a CR TPDU, itshall transfer a TPDU Error (ERR) TPDU to notify the calledtransport entity of the procedure error.

ISO Transport Protocol Specification                                   Page 37International Standards Organization7.0.5   Data Transfer Procedures7.0.5.1  General        The data transfer procedures described in thefollowing subsections apply only when the transport layer is in thedata transfer phase, that is after completion of TransportConnection establishment.7.0.5.2  Transport Data TPDU maximum length        For Class 0 the standard maximum transport dataTPDU length is 128 octets including the data TPDU header octets.        Other maximum TPDU lengths may be supported inconjunction with the optional transport data TPDU size negotiationfunction (seeSection 8.3 and 8.4).  Optional maximum data fieldlengths shall be chosen from the following list:  256, 512, 1024and 2048 octets.        TSDUs are transmitted using the segmenting function.7.0.6   ReleaseProcedure        The "implicit" variant of the release function is used.7.0.7   Treatment of invalid TPDUs        The "treatment of protocol errors' function is used.7.0.8   Behaviour after an error signalled by the network service.        The implicit termination function is used and thehigh layer is informed about this disconnection.7.0.9   Supported Options        None7.1     PROTOCOL DESCRIPTION OF CLASS 1:BASIC ERROR RECOVERY CLASS7.1.1   Characteristics of Class 1        The characteristic of this class is that itprovides a basic transport connection with minimal overheads.        The main purpose of the class if to recover fromnetwork signalled errors (network disconnect or reset).        Selection of this class is usually based on

ISO Transport Protocol Specification                                   Page 38International Standards Organizationreliability criteria.  Class 1 has been designed to be used inassociation with type B network connections.7.1.2   Functions of Class 1        Class 1 provides transport connections with flowcontrol based on the network service provided flow control, errorrecovery, expedited data transfer, disconnection, and also theability to support consecutive Transport connections on a networkconnection.        This class provides the functionality of Class 0plus the ability to recover after a failure signalled by the NetworkService, without involving the user of the Transport Service.7.1.3   Protocol Mechanisms of Class 1        Class 1 protocol mechanisms include Class 0protocol mechanisms plus the following:7.1.3.1  User Data in the Connection Phase        Class 1 provides the possibility of conveyingdata in the connection request and confirm commands.7.1.3.2  Numbering of Data TPDU        Each Data TPDU transmitted between transport entities foreach direction of transmission in a transport connection issequentially numbered.7.1.3.3  Release        The "explicit" variant of the release function is used.7.1.3.4  Error Recovery        The sending Transport entity keeps a copy of transmittedTPDUs until it receives an acknowledgment which allows copies to be released.After a failure is indicated by the nerwork service (Reset,Disconnect), the resynchronization function is used to determinewhich TPDUs must be retransmitted.        Resynchronization may also be invoked by a transport entityas a local matter.  For that purpose the Resynchronization function isused (see note at the end ofSection 6.15).7.1.3.5  Acknowledgement        Acknowledgements are used to release copies of retained TPDUs.

ISO Transport Protocol Specification                                   Page 39International Standards OrganizationTwo methods of acknowledgment are provided in the Retention untilAcknowledgement of TPDUs function:        o  use of AK TPDU ("AK" variant) - mandatory           Note:  The credit field of the AK TPDU is           not used in this class (always Set to zero).        o  use of network layer Confirmation of Receipt Service.           ('confirmation of receipt' variant) - optional        The variant to be used is negotiated during theConnection Establishment Phase.  The default option is the "AK TPDU"variant.  Use of Network Layer Receipt Confirmation is allowed onlyin Class 1, and depends on the availability of the network layerreceipt confirmation service, the expected cost reduction, and theagreement of both transport entities to use it.7.1.4   Connection Establishment Procedures for Class 1        The 'assignment to network connection' and'connection establishment' mechanisms are used.  From the point atwhich a transport entity issues a CR proposing the use of Class 1 ora CC accepting the use of Class 1  the following mechanisms must beavailable to deal with signalled errors during connectionestablishment:        o  Reassignment after failure        o  Retention until Acknowledgement of TPDUs        o  Resynchronization        If no DT or ED TPDU is to be sent, receipt of a CC should beacknowledged.7.1.5   Data Transfer Phase        Data transfer is accomplished using the 'TPDUtransfer' 'Concatenation' and 'DT TPDU Length and Segmenting'mechanisms.  'DT TPDU Numbering' and 'Retention untilAcknowledgement of TPDUs' are used in support of error recovery.7.1.5.1  Behaviour after an error        After receiving a network reset, the Resynchronizationmechanism is invoked.  After receiving a network disconnect, the'Reassignment after Failure' mechanism is invoked after which the'Resynchronization' mechanism is invoked.        The 'Spurious Disconnect' mechanism is used todeal with receipt of a DR TPDU for an unrecognised Transport

ISO Transport Protocol Specification                                   Page 40International Standards OrganizationConnection.7.1.5.2  Procedure for Expedited Data Transfer        The Expedited Data Transfer mechanism is used.Two methods are possible to provide the function:        o  non network expedited variant           Note: (1) This method is always included in this class.           Note: (2) The EDTPDU-NR of the ED TPDU contains anidentification number.  This number must be different for successive ED TPDUs.That is, when an ED TPDU has been sent and an EA TPDU for the EDTPDU has been received, the next ED TPDU must have a different valuein the EDTPDU-NR field.  No other significance is attached toEDTPDU-NR field.  It is recommended but not essential, that thevalues used be consecutive modulo 128.        o  network expedited variant           Note: (1) The use of this method isdetermined through negotiation during transport connectionestablishment.7.1.6   Release Procedures        The 'explicit' variant of the Release mechanism is used.        Receipt of an error indication by a transportentity, which, prior to this event has sent a DR, causes thistransport entity to retransmit DR.  Only DC and DR will be acceptedand interpreted as the completion of the connection releasesequence.  The related Reference will become unassigned.7.1.7   Treatment of Unknown TPDUs        The 'Treatment of Protocol Errors' mechanism is used.7.1.8   Supported Options        Use of network receipt confirmation.        Use of network expedited.7.2     PROTOCOL DESCRIPTION OF CLASS 2: MULTIPLEXING CLASS7.2.1   Characteristics of Class 2        The characteristic of this class is to provide a

ISO Transport Protocol Specification                                   Page 41International Standards Organizationway to multiplex several transport connections onto a single networkconnection.  This class has been designed to be used in associationwith type A network connections.        Use of Explicit Flow Control        The objective is to provide flow control to helpavoid congestion at end-points and on the network connection.Typical use is when traffic is heavy and continuous, or when thereis intensive multiplexing.  Use of flow control can optimizeresponse times and resource utilization.        Non Use of Explicit Flow Control (optional)        The objective is to provide a basic transportconnection with minimal overheads suitable when independence oftransport and network connection lifetime is desirable.  The classwould typically be used for unsophisticated terminals, and when nomultiplexing onto network connections is required.  Expedited datais never available.7.2.2   Functions of Class 2        Class 2 provides transport connections with orwithout individual flow control - no error detection or errorrecovery is provided.        If the network resets or clears, the transportconnection is terminated without the transport clearing sequenceand the transport user is informed.        When explicit flow control is used a creditmechanism is defined allowing the receiver to inform the sender ofthe exact amount of data he is willing to receive and expedited datatransfer is available.7.2.3   Protocol Mechanisms of Class 27.2.3.1  Connection Establishment Phase        The connection establishment function shall be used.7.2.3.1.1  User Data in the Connection Phase        Class 2 provides the possibility to convey data in theconnection request and confirm commands.7.2.3.2  Connection Identification        In Class 2 each TPDU conveys a Destination Reference.

ISO Transport Protocol Specification                                   Page 42International Standards OrganizationThis uniquely identifies the transport connection within thereceiving transport entity and thus allows multiplexing.7.2.3.3  Release Phase        The release of a transport connection results eitherfrom the use of the 'explicit' variant of the release function orfrom the Implicit Termination function.7.2.3.4  Protocol Mechanisms when Explicit Flow Control is used.        The following mechanisms are provided:7.2.3.4.1  Numbering of Data TPDU        Each Data TPDU transmitted between transport entitiesfor each direction of transmission in a transport connection issequentially numbered.        Each Data TPDU contains a Send Sequence Number T(S).7.2.3.4.2  Flow Control Principles        The receiver of data TPDUs holds a count of the sequencenumber of the next expected TPDU.  This count is called theReceive Sequence Number, T(R). The receiver indicated to the senderthe number of Data TPDUs he is ready to receive by means of a 'credit'mechanism.  Credits are given using the credit field in the AK TPDU.The value of the credit field, in conjunction with the value of T(R)transported by the YR-TU-NR (your TPDU number) fieldof the AK TPDU, is used by the receiver of the AK TPDU to determinewhether and how many Data TPDUs may be accepted by the sender of theAK TPDU. Precise definition of flow control principles appears inSection7.2.5.5.3.7.2.3.4.3  Expedited Flow        The non network expedited variant is used.  Normalflow is the flow of data subject to the flow control mechanism,expedited flow is the flow of data that the sender may send withoutexplicit agreement of the receiver.  This expedited flow has alimited capability and could for example be used to carry sessionsupervisory commands.        The number of expedited data units outstanding at anytime is limited to one and the amount of TS-user data is limited (upto 16 octets).        An expedited data may arrive before normal data whichwas submitted earlier.  Normal data submitted after the expedited

ISO Transport Protocol Specification                                   Page 43International Standards Organizationdata will arrive after the expedited data.7.2.4   Connection Establishment Procedures for Class 27.2.4.1  References        SeeSection 6.5 for reference assignment.  Receipt ofany TPDU with a reference that is not assigned to a transportconnection other than a Disconnect Request (DR) or ConnectionRequest (CR) will be ignored.        Receipt of a Disconnect Request (DR) for an unassignedReference will result in a Disconnect Confirm (DC) response.7.2.4.2  Connection Eastablishment        This phase is achieved by exchange of CR/CC TPDU usingthe 'connection establishment' function.  Since the multiplexingfunction is in use, then more than one transport connection may beassigned to the same network connection concurrently.  Therestrictions of Class 0 does not apply to this class and the otherhigher classes.7.2.5   Data Transfer Procedures for Class 2        The data transfer procedures described in thefollowing section apply independently to each transport connectionexisting between two transport entities.7.2.5.1  TPDU Maximum Length and Segmenting        The general rules defined inSection 6.3 apply.7.2.5.2  Concatenation        The general rules defined inSection 6.4 apply.7.2.5.3  Sending Data TPDU (No Explicit Flow Control Option)        In this case the data TPDU is built in accordancewith the rules stated inSection 6.2 and 6.3 and sent without anyadditional mechanisms.  Thus, the DT TPDU NR field may take anyvalue and no AK TPDU is used.7.2.5.4  Sending Data TPDU (When Explicit Flow Control is Used)        On each transport connection the transmission of DataTPDUs is controlled separately for each direction and is based onauthorization from the receiver.

ISO Transport Protocol Specification                                   Page 44International Standards Organization        This authorization is provided through the use ofthe TPDUs Credit field.  Credit field values are only present inthe following TPDUs:  CR, CC, AK..7.2.5.4.1  Numbering of Data TPDUs        Each Data TPDU transmitted between transport entities,for each direction of transmission in a transport connection, issequentially numbered.        The sender of Data TPDUs holds a count of the nextTPDU to be sent.  This count is called the Send Sequence NumberT(S).  The sender indicates to the receiver the number of the dataTPDU he sends by putting the current T(S) value into the TPDU-NRfield of the data TPDU.        Sequence numbering is performed modulo 2**n, where nis the number of bits of the sequence number field.  The T(S)counter cycles through the entire range 0 to (2**n)-1.        At connection establishment time both Transportentities initialize their T(S) and T(R) counts to zero (i.e. thefirst Data TPDU to be transmitted between transport entities for agiven direction of data transmission after the connectionestablishment has a TPDU-NR field set to zero).        Receipt of a Data TPDU whose TPDU-NR field is notequal to the expected value T(R), is to be regarded as a protocolerror.        Operations described above are summarized as follows:        o  initalization           T(S) = 0     T(R) = 0               Sending of Data TPDU                         put T(S) into the TPDU-NR field of                         the Data TPDU to be sent                         T(S) = (T(S) + 1) (modulo 2**n)               Receiving of Data TPDU                         TPDU-NR field of the received data                         TPDU which is not equal to T(R) is                         a protocol error.                         T(R) = (T(R) + 1) (modulo 2**n)

ISO Transport Protocol Specification                                   Page 45International Standards Organization7.2.5.4.2  Window Definition        For each transport connection and for each directionof data transmission a 'transmit window' is defined as the (possiblynull) ordered set of consecutive data TPDUs authorized to betransmitted in that direction.  At any given time, the lowestsequence number of a data TPDU which a transport entity isauthorized to transmit is referred to as the 'lowest window edge'.The 'upper window edge' is calculated  by adding the creditallocation, given by the value of the Credit (CDT) field containedin a received TPDU, to the lower window edge.  Note that a transportentity is authorized to send data TPDUs with sequence numbers up tobut not including the upper window edge.7.2.5.4.3  Flow Control        Flow control is performed as follows:        o  initialization time           Lower window edge = 0           Upper window edge = N (Credit received either in           CR or in CC and N < 2**p < 2** (n-1), where P is the number of           bits in credit field of CR and CC.        o  Sending of a Data TPDU           Send data TPDUs while T(S) is less than the upper window           edge.  If T(S) equals the upper window edge then wait for           additional credit before sending.        o  Reception of Data TPDU (with TPDU NR = T(R)           If T(R) is greater than or equal to the upper window edge           authorized to the sending transport entity, then the receiving           transport entity shall use the Treatment of Protocol Errors           function.  Otherwise T(R) shall be incremented.           Sending Credit                    Send AK TPDU with YR-TU-NR = T(R) and Credit equals N.                    (Where N = number of additional data                    TPDUs the entity is prepared to receive.)           Receiving Credit in AK.                    Lower window edge = YR-TU-NR received.                    Upper window edge =  Lower window edge + N.

ISO Transport Protocol Specification                                   Page 46International Standards Organization7.2.5.4.4  Reducing the Upper Window Edge        The value of the upper window edge cannot be decreasedin this class.  If, at a certain point of time, the upper window edgevalue is U, the reception of an AK TPDU having YR-TU-NR = M and CDT= N such that:        (U-M) (mod. 2**n) > Nis a protocol error        Provided the previous statements are respected, CDTfield may take any value including zero.7.2.5.4.5  Procedure for Expedited Data Transfer        The procedure of expedited data transfer allows atransport entity to transmit data to the remote transport entitywithout following the flow control procedure of the normal dataflow.  This procedure can only apply in the transfer phase.        The expedited procedure has no effect on the transferand flow control applying to normal Data TPDUs.        To transmit expedited data, the transport entity sendsan expedited data TPDU (ED TPDU).  The size of a data field islimited (up to 16 octets).  The data field contains a complete EDTSDU.  The remote transport will then confirm the receipt of the EDTPDU by transmitting an expedited TPDU acknowledgement (EA TPDU).A transport entity can send another ED TPDU only after havingreceived an EA TPDU for the previously transmitted ED TPDU.  Inclass 2 the ED TPDU NR field of the ED and YR-TU-NR field of the EATPDU are not defined and may take any value.7.2.6   Release Procedures for Class 2        The data phase ends after a transport entity has sentor received a Disconnect Request (DR).  The transport entity willignore any incoming TPDU except DC or DR.        If the network resets or clears the networkconnection, all transport connections are terminated without thetransport clearing sequence.  The References become frozen.        For Class 2 the explicit variant of the 'release'mechanism is used, enabling transport connections to be clearedindependently of the underlying network connection.7.2.7   Treatment of Invalid TPDUs

ISO Transport Protocol Specification                                   Page 47International Standards Organization        The 'Treatment of Protocol Error' mechanism in Section6.23 is used.7.2.8   Behaviour after an Error signalled by the Network Layer.        The implicit termination mechanism is used.7.2.9   Supported Options        Non use of explicit flow control.        Extended formats.7.3     PROTOCOL DESCRIPTION OF CLASS 3: ERROR RECOVERY AND MULTIPLEXING CLASS7.3.1   Characteristics of Class 3        The characteristics of Class 3 in addition to those ofClass 2 is to mask errors indicated by the network.  Selection ofthis class is usually based upon reliability criteria.  Class 3 hasbeen designed to be used in association with type B network connections.7.3.2   Functions of Class 3        This class provides the functionality of Class 2 (withuse of explicit flow control) plus the ability to recover after afailure signalled by the Network Layer without involving the userof the transport service.        The mechanisms used to achieve this functionality alsoallow the implementation of more flexible flow control.7.3.3   Protocol Mechanisms of Class 3        Class 3 mechanisms include Class 2 (with use ofexplicit flow control option) mechanisms and the ability to recoverafter a failure signalled by the network without informing the userof the transport connection.7.3.3.1  Error Recovery Principles        The sending transport entity keeps a copy oftransmitted Data TPDUs and ED TPDUs until it receives a positiveaknowledgement which allows copies to be released.  It may alsoreceive an RJ command inviting it to retransmit or transmit all DataTPDUs, if any, from the point in the sequence indicated in the  RJcommand.        This is especially the case, when a failure isindicated by the network.  The transport entity sends an RJ commandin order to indicate the sequence number of the next expected TPDU.

ISO Transport Protocol Specification                                   Page 48International Standards Organization        Error recovery for ED TPDU is achieved by retransmission(see 7.3.5.3).7.3.3.2  Relationship between Flow Control and Error Recovery        Acknowledgement is performed by use of the T(R) count.          A credit is associated with this acknowledgement which maybe equal to or greater than zero.  Thus it is possible to acknowledgedata without giving the right to send new data.        Credit may be reduced, by the use of the RJ TPDU.7.3.4   Connection Establishment Procedure for Class 3        The rules for Class 2 (with use of explicit flowcontrol) apply with the addition of the following rules which applyon receipt of an eror indication from the Network layer.        o  Reception of an error indication by a           transport entity which, prior to this event, has           sent a CR and has not yer received a CC, causes           the transport entity to retransmit CR.        o  Reception of an error indication by a           transport entity to wait for reception of CR, RJ           or DR TPDU.  In this case:           - Reception of CR will cause the transport             entity to retransmit CC.           - Reception of RJ will cause the transport             entity to transmit an RJ with a YR-TU-NR             equal to zero and enter the data phase.           - Reception of a DR will cause termination             of the transport connection as for Classes 1             and 2 (see 7.1.4).7.3.5   Data Transfer Procedures for Class 37.3.5.1  Acknowledgement        The 'AK' variant of the Retention untilAcknowledgement of TPDUs function is used.7.3.5.2  Retransmission Procedure        TPDU retransmission is a procedure which allowsa transport entity to request retransmission of one or severalconsecutive Data TPDUs from the remote transport entity.  A

ISO Transport Protocol Specification                                   Page 49International Standards Organizationtransport reject condition is signalled to the remote transportentity by transmission of an RJ TPDU whose YR-TU-NR field indicatesthe sequence number of the next expected Data TPDU.        On receipt of a RJ TPDU, a Transport entity shallaccept credit to the value contained in the credit field and shallre-transmit TPDUs, starting with the one whose number is specified inthe YR-TU-NR field of the received RJ TPDU, subject to the newcredit.        The transport entity shall not specify a T(R) in theRJ TPDU less than that which has previously been acknowledged.Receipt of an RJ TPDU with a T(R) which has been previouslyacknowledged will be considered a protocol error.        Additional DT TPDUs pending initial transmission mayfollow the retransmitted DT TPDU(s) if the window is not closed.7.3.5.3  Reducing the upper window edge        It is possible to decrease the value of the upperwindow edge down to the sequence number transported by YR-TU-NRfield of the RJ TPDU.  Receipt of an DT TPDU which would have beeninside the window before the reduction is not a protocol error andthis TPDU may be discarded.        Note:  In such a case the credit equal to zeroachieves the effect of a Receive not Ready Condition.7.3.5.4  Behaviour after an error signalled by the network layer        After receiving an error indication from the NetworkService, the transport entity shall tranmit to the remove entity anRJ TPDU with YR-TU-NR field indicating the sequence number of thenext expected Data TPDU.7.3.5.5  Procedure for Expedited Data Transfer        In Class 3, the ED TPDU-NR field of the ExpeditedData (ED) TPDU contains an identification number.  This number mustbe different for successive ED TPDUs.  That is, when an ED TPDU hasbeen sent and an EA TPDU for the ED TPDU has been received, the nextED TPDU must have a different value in the NR field of the EDTPDU.  No other significance is attached to this field.  It isrecommended, however, that the values used be consecutive modulo2**n.  When a transport entity receives an ED TPDU for a transportconnection, it shall respond by transmitting an expeditedacknowledgement (EA) TPDU.        It places in the YR-TU-NR field the value contained in

ISO Transport Protocol Specification                                   Page 50International Standards Organizationthe NR field of the received ED TPDU.  If, and only if, this valueis different from the NR field of the previously received ED TPDU,the data contained in the TPDU is to be passed to the session entity.        If an error indication from the Network layer isreceived before the receipt of the expected Expedited Acknowledgement(EA) TPDU, the transport entity shall retransmit the ED TPDU withthe same value in the NR field.  By the rule described in theprevious paragraph, the session entity does not receive datacorresponding to the same expedited TPDU more than once.7.3.6   Release Procedures for Class 3        The rules for Class 2 apply with the addition of thefollowing rule:        Receipt of an eror indication by a transport entity,which prior to this event has sent a DR, causes this transportentity to retransmit DR.  Only DC and DR will be accepted andinterpreted as the completion of the connection clearing sequence.The related Reference will become unassigned.7.3.7   Treatment of Invalid TPDUs        The 'Treatment of Protocol Errors' mechanism is used.7.3.8   Supported Options        Extended formats.7.4     PROTOCOL DESCRIPTION OF CLASS 4: ERROR DETECTION AND RECOVERY CLASS7.4.1   Characteristics of Class 4        The characteristic of Class 4, in addition to those ofClass 3, is the detection of errors which occur as a result of thelow grade of service available from the network layer.  The kinds oferrors to be detected include:  TPDU loss, TPDU delivery out ofsequence, TPDU duplication.  These errors may afect control TPDUs aswell as Data TPDUs.        Class 4 has been designed to be usd in associationwith network connections of type C.7.4.2   Functions of Class 4        This class provides the functionality of Class 3, plusthe ability to detect and recover from lost, duplicated or out ofsequence TPDUs without involving the user of the transport service.

ISO Transport Protocol Specification                                   Page 51International Standards Organization        This detection of errors is made by extended use ofthe sequence numbering of Classes 2 and 3, by a timeout mechanism,and by additional protocol mechanisms.        This class additionally detects and recovers fromdamaged TPDUs by using a checksum mechamism.  The use of thechecksum mechanism must be available but its use or its non use issubject to negotiation.  Class 4 does not attempt to deal withdetection of errors due to the misdelivery of TPDUs.7.4.3   Protocol Mechanisms of Class 47.4.3.1  Network Service Data Unit Lifetime        The network layer is assumed to provide, as an aspectof its grade of service, for a bound on the maximum lifetime ofNSDUs in the network.  This value is known by the Transport Layer.The maximum time which may elapse between the transmission of anNSDU into the network layer and the receipt of any copy of it isreferred to as M.7.4.3.2  Average Transit Delay        It is assumed that there is some value of transmitdelay in the network, typically much less than M, which will be themaximum delay suffered by all but a small proportion of NSDUs.  Thisvalue is referred to as E.7.4.3.3  Remote Acknowledge Time Assumptions        Any transport entity is assumed to provide a bound for themaximum time which can elapse between its receipt of a TPDU fromthe Network Layer and its transmisssion of the Corresponding response.this value is referred to as A/L.  The corresponding time given by theremote transport entity is referred to as A/R.  The values for thesetimers may be conventionally established or may be establishedat connection establishment time.7.4.3.4  Local Retransmission Time        The local transport entity is assumed to maintain abound on the time it will wait for an acknowledgement beforeretransmitting the TPDU.  This time is the local retransmission timeand is referred to as T1.                  T1 = 2*E +  X  + Ar?             Where X is a value to allow for TPDU processing in thelocal transport entity.

ISO Transport Protocol Specification                                   Page 52International Standards Organization7.4.3.5  Persistence Time        The local transport entity is assumed to provide abound for the maximum time for which it may continue to retransmita TPDU requiring positive acknowledgment.  This value is referred toas R.        The value is clearly related to the time elapsedbetween retransmission, T1, and the maximum number ofretransmissions, N.  It is not less than T1*N+X, where X is smallquantity to allow for additional internal delays, the granularity ofthe mechanism used to implement T1 and so on.  Because R is a bound,the exact value of X is unimportant as long as it is bounded andthe value of a bound is known.7.4.3.6  Bound on Reference Identifier and Sequence Numbers        Using the above values, a bound L may be establishedfor the maximum time between the decision to transmit a TPDU and thereceipt of any response relating to it.  The value of L is given by:                  L = 2*M+R+Ar        It is necessary to wait for a period L before reusingany reference or sequence number, to avoid confusion in case a TPDUreferring to it may be duplicated or delayed.        (Note:  In practive, the value of L may beunacceptably large.  It may also be only a statistical figure at acertain confidence level.  A smaller value may therefore be usedwhere this still allows the required quality of service to beprovided).7.4.3.7  Inactivity Time        To protect against unsignalled breaks in the networkconnection (Half-open connections), each transport entity maintainsan inactivity time interval.   If the interval passes withoutreceipt of some TPDU, the transport entity will terminate the TC bymaking use of the release procedure.  This interval is referred toas I.7.4.3.8  Window Time        A transport entity maintains a time to ensure thatthere is a maximum interval between transmission of up-to-datewindow information.  This interval is referred to as the windowtime, W.7.4.3.9  Class 4 Error Recovery Principles

ISO Transport Protocol Specification                                   Page 53International Standards Organization        In class 4, the transport entity associates a response timewith TPDUs sent requiring a response.  If an appropriate response isnot received within time T1, the recovery procedure must be invokedby the sender.  This will usually involve the retransmission of thecorresponding TPDU.        A TPDU may be transmitted a maximum number of times,This number is referred to a N.  The value of N is chosen so thatthe required quality of service can be provided given the knowncharacteristics of the network connection.7.4.3.10  Relationship of Times and Intervals        The following note describes the relationship betweenthe time described inSection 7.4.3.1 - 7.4.3.9.        Note:             a.   The interrelationship of times for the worst case                  is as follows:                  M:   maximum transit delay of the network (see                       7.4.3.1)                  Ar  maximum acknowledgement time of the remote                       transport entity (see 7.4.3.3)                  R:   maximum local retransmission time (see                       7.4.3.5)                  N:   maximum number of transmission for a single                       TPDU (see 7.4.3.9)                  L:   maximum time for a TPDU to be valid (see                       7.4.3.6)                                             R = T * (N-1)                                                  1                            R                            *                            M             L              *                            A                =2*M  +  A   + R                             R                         R                            *                            M

ISO Transport Protocol Specification                                   Page 54International Standards Organization                                 t      t             b.   The interrelationship of times for the average                  case is as follows (see 7.4.3.4)                  E:        average transit delay for the network                            (E<<M)                  X:        TPDU processing time                  T :       average time from sending a TPDU until                   1        the receipt of its acknowledgement (see                            7.4.3.4)                  A :       maximum acknowledgement time of the                   R        remote transport entity (see 7.4.3.3)                         X                         E                         A         T  = 2*E + X + A                          R         1              R                         Et                t7.4.3.11  Sequence Numbering        In Class 4 sequence numbering is applied to certaincontrol TPDUs and their acknowledgements, as well as to DT TPDUs.These are ED and its acknowledgement EA.        The length of sequence numbers may be negotiated atconnection establishment.  Where other than the default length isused, an extended header format is used for sequenced TPDUscontaining additional octets of sequence numbers.  Extended headerformat includes a credit field on the appropriate TPDU typesallowing extended credit allocation.7.4.4   Procedures for Connection Establishment Phase        The following features pertain to connectionestablishment for Class 4:        o  In Class 4, a connection is not considered           established until the successful completion           of a 3-way TPDU exchange.  The sender of a           CR TPDU must respond to the corresponding CC

ISO Transport Protocol Specification                                   Page 55International Standards Organization           TPDU by immediately sending a DT, ED or AK TPDU.        o  As a result of duplication, a CR TPDU may be           received specifying a source reference which           is already in use with the sending transport           entity.  If the receiving transport entity           is in the data transfer phase, having           completed the 3-way TPDU exchange procedure,           the receiving transport entity should ignore           such a TPDU.  Otherwise a CC TPDU should be           transmitted.        o  As a result of duplication or           retransmission, a CC TPDU may be received           specifying a paired reference which is           already in use.  The receiving transport           entity should ignore such a CC TPDU.        o  A CC TPDU may be received specifying a           reference which is in the frozen state.  The           response to such a TPDU should be a DR TPDU.7.4.4.1  Connection Request        When a transport entity transmits a CR TPDU it startstimer T1.  If this timer expires before a CC TPDU is received, theCR TPDU is retransmitted and the timer restarted.  Aftertransmission of the CR TPDU N times, the connection establishmentprocedure is abandoned and the failure reported to the transportuser.  The reference must be placed in the frozen state for a periodL (seesection 7.4.3.6).7.4.4.2  Incomimg Connection Request        An incoming connection request is processed as for Class 37.4.4.3  Connection Confirm        When a transport entity transmits a CC TPDU it startstimer T1.  If this timer expires before an AK or DT TPDU isreceived, the CC TPDU is retransmitted according to theretransmission principles inSection 7.4.3.97.4.4.4  Incoming Connection Confirm        When a CC TPDU is received, the receiving transport entityenters the data transfer phase.  It must immediately transmit anAK, ED or DT TPDU to complete the 3-way TPDU exchange.  TheCC TPDU is subject to the usual rules of the data transfer phaseregarding retransmission, seeSection 7.4.5.3.

ISO Transport Protocol Specification                                   Page 56International Standards Organization7.4.4.5  Incoming Acknowledgement        When an AK, DT or ED TPDU is received the receivingtransport entity can enter the data transfer phase.  If the entityhas data to send it may send DT TPDUs or an ED TPDU.  The DT TPDUsare subject to flow control.  Otherwise, the transport entity mustobey the inactivity principles (seeSection 7.4.5.8).7.4.4.6  Unsuccessful Connection        When a DR TPDU is received in response to a CR TPDU,the timer T1 is cancelled and the reference placed in the frozenstate for a period L (seeSection 7.4.6.1).7.4.4.7  Initial Credit Allocation        The CR and CC TPDUs may allocate an initial credit valueto their respective recipients.  This value is limited to 15 by theencoding of the TPDU.  Where the extended header format is in use,credit values greater than 15 must be allocated using AK TPDUs.7.4.4.8  Exchange of Acknowledge Time        A transport entity may transmit the value it intendsto use for AL at connection establishment, as the 'AcknowledgeTime' parameter in the CR or CC TPDU (depending on whether thetransport entity is initiating or accepting the transportconnection).  If this parameter is present in a received CR or CCTPDU, the value of AR should be set accordingly.  If thisparameter is not present, AR may be assumed to be insignificant incomparison to E the typical maximum transit delay.7.4.5   Procedure for Data Transfer Phase7.4.5.1  Sequence Control        The receiving transport entity is responsible formaintaining the proper sequence of DT TPDUs.        DT TPDUs received out of sequence must not bedelivered to the TS-user until in-sequence TPDUs have also beenreceived.        AK TPDUs also contain information allowing thereceiving transport entity to process them in the correct order.7.4.5.2  Duplicate DT TPDUs        Duplicate TPDUs can be detected because the T(S) valuematches that of previously received TPDUs.  T(S) values must not be

ISO Transport Protocol Specification                                   Page 57International Standards Organizationreused for the period L after their previous use.  Otherwise, anew, valid TPDU could be confused with a duplicated TPDU which hadpreviously been received and acknowledged.        Duplicated DT TPDUs must be acknowledged, since theduplicated TPDU may be the result of a retransmission resulting fromthe loss of an AK TPDU.        The data contained in a duplicated DT TPDU should beignored.7.4.5.3  Retransmission Principles        When a transport entity has some outstanding DT or EDTPDUs that require acknowledgement, it will check that no T1interval elapses without the arrival of an AK or EA TPDU thatacknowledges one of them.  If the timer expires, the first TPDU isretransmitted and the timer is restarted.  After N transmissions(N-1 retransmissions) the connection is assumed to have failed andthe release phase is entered, and the transport user is informed.        DT TPDUs which fall beyond the current window (due toreduction of the upper window edge) are not retransmitted untiladvancement of the upper window edge so permits.     Note:     This requirement can be met by different                       means, for example.             1.   One timer is associated with each TPDU.  If the                  timer expires, the associated TPDU will be                  retransmitted, and the timer T1 will be                  restarted for all subsequent DT TPDUs.             2.   One timer is associated with each TC:                  if the transport entity transmits a DT TPDU                  requiring acknowledgement, it starts timer                  T1,                  if the transport entity receives a TPDU that                  acknowledges one of the TPDUs to be                  acknowledged, timer T1 is restarted,                  if the transport entity receives a TPDU that                  acknowledges the last TPDU to be                  acknowledged, timer T1 is stopped.        For the decision whether the retransmission timer T1is maintained on a per TPDU or on a per TC basis, throughputconsiderations have to be taken into account.

ISO Transport Protocol Specification                                   Page 58International Standards Organization7.4.5.4  Acknowledgement Principles        A transport entity operating class 4 must acknowledgeall TPDUs received requiring acknowledgment.  To avoid unnecessaryretransmissions and to avoid delays to transmission by the remotetransport entity, the delay for acknowledgement should not exceedtimer A  (seeSection 7.4.3.2).       L        There are two TPDU types that must be acknowledged:ED and DT.  Receipt of an ED TPDU must be acknowledged by an EATPDU.  A DT TPDU is acknowledged with an AK TPDU.        An AK TPDU has the sequence number of the next DTTPDU the receiving transport entity expects to receive.  It thusacknowledges receipt of all DT TPDUs with sequence numbers less thanthe acknowledgement number.        An AK TPDU may be repeated at any time, using thesequence number in the last AK TPDU sent.7.4.5.5  Flow Control Principles        Flow control in Class 4 is subject to the sameprinciples as in Classes 2 and 3.  The credit mechanism and windowprinciple of those classes still apply, except that in class 4, theupper window edge can be reduced by the receiving transport entityby sending an AK TPDU with a smaller credit.        A receiving transport entity may send an AK TPDU atany time to change the window size.  This AK TPDU may acknowledge anew DT TPDU or may repeat a previous acknowledgement.7.4.5.6  Window Synchronization Principles        To ensure the synchronization of flow controlinformation the window timer provokes the frequent exchange of AKTPDUs between transport entities.  The window timer maintains aminimum level of TPDU traffic between transport entities cooperatingin a transport connection.        In Class 4 the window size can be reduced in any AKTPDU.  Due to the possibility of misordering of AK TPDUs and theassociated loss of efficiency, the AK TPDU for class 4includes an additional field called the AK TPDU  subsequenceparameter.        An AK TPDU should contain the subsequence parameterwhenever a duplicate AK TPDU is sent with the same sequence numberbut with reduced credit.  The value of the subsequence parameter is

ISO Transport Protocol Specification                                   Page 59International Standards Organizationset to one for the first time the AK TPDU is resent with reducedcredit.        When an AK TPDU is transmitted whose sequencenumber is increased, the 'sub-sequence' parameter is omitteduntil credit reduction takes place.        When an AK TPDU is received, it must be processed(i.e., its contents made use of) only if:        o  The sequence number is greater than in any           previously received AK TPDU, or,        o  The sequence number is equal to the highest           in any previously received AK TPDU, and the           sub-sequence parameter is greater than in           any previously received AK TPDU having the           same sequence number (where an           absent sub-sequence parameter is regarded           as having a value of zero), or        o  The sequence number and sub-sequence           parameter are both equal to the highest in           any previously received AK TPDU (where an           absent sub-sequence parameter is regarded as           having a value of zero), and the credit           field is greater than in any previously           received AK TPDU having the same sequence           and sub-sequence numbers.        When an AK TPDU is transmitted which opens a closedwindow (i.e. increases credit from zero), it should be retransmittedat an interval of T1.  Transmission should occur a maximum of Ntimes, after which the usual inactivity retransmission timer shouldbe reverted to.  Retransmission may also cease if the localtransport entity becomes sure that the new credit information hasbeen received by the remote transport entity.        If a transport entity receives an AK TPDU containinga 'Flow Control Confirmation' parameter, whose Lower Window Edge andYour-Sub-Sequence fields are equal to its own lower window edge andsub-sequence number, it may note that the credit available at theremote transport entity (relative the Lower Window Edge field) is atleast equal to the value conveyed as Your Credit.  This enables thetransport entity to cease the frequent retransmission of windowinformation, if it thereby knows that the remote window is open.        A transport entity need not retransmit windowinformation (except as described under Inactivity Principles) if itis aware by the receipt of DT TPDUs that the remote transport entity

ISO Transport Protocol Specification                                   Page 60International Standards Organizationhas sufficient credit to prevent deadlock.  When an AK TPDU istransmitted in response to a DT TPDU, the transport entity maynormally assume that the transmitter of the DT TPDU will ensure thatthe AK TPDU is received, be retransmission of the DT TPDU ifnecessary.  Therefore, it can normally be assumed that the creditconveyed in such an AK TPDU will be available to the remotetransport entity, and frequent retransmission is unnecessary.        The assumption that the DT TPDU will be retransmittedmay be incorrect if credit reduction has taken place.  Therefore, atransport entity may not make this assumption if thesequence number of the DT TPDU is less than or equal to the highestvalue for which permission to transmit (i.e., credit) has been givenand subsequently withdrawn.        Upon receipt of an AK TPDU which increases the upperwindow edge, a transport entity may transmit an AK TPDU whichrepeats the information contained in the received TPDU in a 'FlowControl Confirmation' parameter in its variable part an therebyassures the transmitter of the original AK TPDU of its own state.Such an AK TPDU may be tranmmitted:        o  Upon receipt of a duplicated AK TPDU           (i.e., one which is identical in all fields,           including the sub-sequence parameter if           present, to the most recently received AK           TPDU which was not discarded due to           detection of a sequence error), not           containing the 'Flow Control Confirmation'           parameter.        o  Upon receipt of an AK TPDU which increases           the upper window edge but does not increase           the lower window edge, when the upper window           edge was formerly equal to the lower window           edge.7.4.5.7  Procedure for Expedited Data        The procedure for expedited data is as for Class 3,with the following exceptions.        The ED TPDU has a sequence number which is allocatedfrom a separate sequence space from that of the DT TPDUs.  The EATPDU carries the same sequence number as the corresponding ED TPDU.Only a single ED TPDU may be transmitted and awaitingacknowledgements at any time.        Upon receipt of an unduplicated ED TPDU, a transportentity immediately forwards the data to the transport user.  The ED

ISO Transport Protocol Specification                                   Page 61International Standards OrganizationTPDU sequence number is recorded in an EA TPDU sent to the othertransport entity.        The sender of an ED TPDU shall not send any new DTTPDU with higher T(S) until it receives the EA TPDU.  Thisguarantees the arrival of the ED TPDU before any subsequently sentDT TPDUs.7.4.5.8  Inactivity Principles        If the Inactivity Time I passes without receipt ofsome TPDU, the transport entity will terminate the TC by making useof the release procedure.  To present expiration of the remotetransport entity's inactivity times when no data is being sent, thelocal transport entity must send AK TPDUs at suitable intervals inthe absence of data, having regard to the probability of TPDU loss.The Window Synchronization Principles (see 7.4.5.6) may ensure thatthis requirement is met.        Note: It is likely that the release procedureinitiated due to inactivity timer expiration will fail, as suchexpiration indicates probable failure of the supporting NC or of theremote transport entity.  This case is described inSection 7.4.6.7.4.6   Procedures for Release Phase        The rules for class 3 apply.  The DR TPDU is subjectto the usual retransmission procedure.  After N retransmissions, thetransport connection is considered disconnected, the Reference isplaced in the frozen state for a period L and retransmission ceases.        The DC TPDU is sent only in response to a DR TPDU, andis not subject to the retransmission procedure.        The DC TPDU when received allows the transport entityto release all resources maintained for the transport connection.        The DR TPDU does not carry a sequence number.  Anypreviously transmitted TPDUs (including DT and ED) which arereceived after the DR TPDU result in a further DR TPDU but areotherwise ignored.  After disconnection, for whatever reason, theReference is placed in the frozen state for a period L.7.4.6.1  Unassigned Frozen References        When a transport connection is terminated, thecorresponding references cannot be immediately reused since TPDUscontaining these references may continue to exist in the network fora time up to L.  Therefore, these references will be placed in anunassignable, frozen state for this peiod.

ISO Transport Protocol Specification                                   Page 62International Standards Organization        After an event involving loss of transport entitystate information, including the status of reference assignments,all references relating to network connections whose transportstate information has been lost must be placed in the frozen statefor a period L.        If a DC TPDU is received for a local reference whichis in the frozen state, or with a remore reference not matching thealready recorded one, this DC TPDU shall be ignored.7.4.7   Treatment of Invalid TPDUs        The 'Treatment of Protocol Erorrs' function is used.7.4.8   Supported Options        Non use of checksum.        Use of extended formats.8.      ENCODING8.1     Summary                                    Classes                                  0  1  2  3  4   Sect.       CodeCR Connection Request             x  x  x  x  x   8.3      1110xxxxCC Connection Confirm             x  x  x  x  x   8.4      1101xxxxDR Disconnect Request             x  x  x  x  x   8.5      10000000DC Disconnect Confirm                x  x  x  x   8.6      11000000DT Data                           x  x  x  x  x   8.7      11110000ED Expedited Data                    x  NF x  x   8.8      00010000AK Data Acknowledgement            NRC  NF x  x   8.9      0110xxxx    (Note 1)EA Expedited Data                    x  NF x  x   8.10     00100000   AcknowledgementRJ Reject (Note 1)                   x     x      8.11     0101xxxxERR TPDU Error                    x  x  x  x  x   8.12     01110000not available (Note 2)                             -      00000000

ISO Transport Protocol Specification                                   Page 63International Standards Organizationnot available (Note 2)                             -      00110000not available (Note 2)                             -      1001xxxxnot available (Note 2)                             -      1010xxxxWhere xxxx (bits 4-1) is used to signal the CDTNote 1: In extended header format, the code for AK=0110 0000 and the        code for RJ=0101 0000.Note 2: These codes are already in use in compatible protocols        defines by standards organizations other than CCITT/ISO.NF:     Not available when the non explicit flow control option is        selected.NRC:    Not available when the receipt confirmation option is        selected.8.2     Structure        As defined in the previous sections, all the TransportProtocol Data Units (TPDU) shall contain an integral number ofoctets.  The octets in a TPDU are numbered starting from 1 andincreasing in the order of transmission.  The bits in an octet arenumbered from 1 to 8, where bit 1 is the low-ordered bit.        There are tao types of TPDUs:        o  Data TPDUs, used to transfer Transport Service           Data Units (TSDUs).  The structure of the TSDUs is           maintained by means of the TSDU End Mark.        o  Control TPDUs, used to control the transport           protocol functions, including the optional           functions.Octets  1  2  3  4           n  n+1          p  p+1        ------------      --------------   --------------   --------        LI|  | |  |  ...    |  |   |    .... | |    |   .... |        ------------      --------------   --------------   --------         <--- Fixed Part -----><-- Variable Part->                                   (including checksum                                    where applicable)        <--------------Header-------------------><----Data Field->A TPDU is divided into four parts:

ISO Transport Protocol Specification                                   Page 64International Standards Organization        o  Length Indicator Field (LI)        o  Fixed Part        o  Variable Part (may be omitted)        o  Data Field (may be omitted)The length Indicator Field, Fixed Part and Variable Part constitutethe Header of the TPDU.8.2.1   Length Indicator Field        This field is contained in the first octet of theTPDUs.  The length is indicated by a binary number, with a maximumvalue of 254 (11111110).  The length indicated is the header length,including parameters, but excluding the length indicator field anduser data, if any.  The value 255 (11111111) is reserved forpossible extensions.8.2.2   Fixed Part        The fixed part contains frequently occurring functionsincluding the code of the TPDU.  The length and the structure of thefixed part are defined by the TPDU code, defined by bits 5 to 8 ofthe second octet of the header.8.2.2.1  TPDU Code        This field contains the TPDU code and is contained inOctet 2 of the header.  It is used to define the structure of theremaining header.  This field is a full octet except in thefollowing cases:             1110 xxxx      Connecting Request             1101 xxxx      Connection Confirm             0101 xxxx      Reject             0110 xxxx      Data Acknowledgement        Where xxxx (bits 4-1) is used to signal the CDT.        Any other bit pattern may be used to define a TPDU Code.        Only those codes defined inSection 8.1 are currently valid.8.2.3   Variable Part        The variable part is used to define parametersrelating to optional functions.  If the variable part is present, itshall contain one or more parameters.  The number of parameters thatmay be contained in the varialbe part is indicated by the length of

ISO Transport Protocol Specification                                   Page 65International Standards Organizationthe variable part which is a LI minus the length of the fixed part.        Since the currently defined minimum fixed part forheaders which allow parameters is four octets, and since the lengthindication field is limited to a maximum of 254, the maximum lengthof the variable part is 250 octets.        Each parameter contained within the variable part iscoded as follows:                      Bits 8   7   6   5   4   3   2   1        Octets        n+1                            Parameter Code        n+2                            Parameter Length                                        Indication (e.g."m")        n+3                            Parameter Value        n+2+m        o       The parameter code field is coded in binary and,                without extensions, provides a maximum number of                255 different parameters.  However, as noted below,                bits 8 and 7 indicates the source of definition,                so the practical maximum number of different                parameters is less.  Parameter code 1111 1111 is                reserved for possible extensions of the parameter code.        o       The parameter length indication indicates the length,                in octets, of the parameter value field.  The length                is indicated by a binary number, "m" with a theoretical                maximum value of 255.  The practical maximum value of                "m" is lower.  For example, in the case of a single parameter                contained within the variable part, two octets                are required for the Parameter Code and the Parameter Length                Indication itself.  Thus, the value of "m"  is limited                to 248.  For larger fixed parts of the header and for                each succeedimg parameter, the maximum value of "m" decreases.        o       The parameter value field contains the value of the                parameter identified in the parameter code field.        o       No standard parameter codes use bits 8 and 7 with the                value 00.        o       Implementations shall accept the parameters defined in                the variable part in any order.  If any parameter is                duplicated then the later value will be used.8.2.3.1  Checksum Parameter (Class 4 only)

ISO Transport Protocol Specification                                   Page 66International Standards Organization        All TPDU types may contain a checksum parameter intheir variable part.  This parameter must always be present exceptwhen the non use of checksum option is selected.             Parameter Code:     1100 0011             Parameter Length:      2             Parameter Value:    Result of checksum algorithm.                                 This algorithm is specified inSection 6.18.8.2.4   Data Field    This field contains transparent user data.Restrictions on its size are noted for each command.8.3     Connections Request (CR)8.3.1   Structure        1     2         3        4     5    6     7     8     p   p+1        LI  CR  CDT 00000000 00000000 SOURCE-   class  VARIABLE  USER DATA                                      REFERENCE options   PART8.3.2   LI        See Section  8.2.18.3.3   Fixed Part (Octets 2 to 7)             CR:       Connection Request Code:      1110             CDT:      Initial Credit Allocation (set to 0000 in                       Classes 0 and 1 when specified as preferred class).             SOURCE REFERENCE:        Reference selected by the transport                                      entity initiating the CR TPDU to                                      identify the requested TC.             CLASSES:   Bits 8-5 octer 7 defines the preferred Transport                        Protocol class to be operated over the requested                        TC.  This field may take on one of the following                        values.                                 0000           Class 0                                 0001           Class 1                                 0010           Class 2                                 0011           Class 3                                 0100           Class 4        The CR contains the first choice of class in the fixedpart as above.  Second and subsequent choices are listed in thevariable part if required.

ISO Transport Protocol Specification                                   Page 67International Standards Organization        Bits 4-1 of octet 7 are reserved for options to beused on the requested transport connection.        The use of bits 4-1 is as follows:                  BIT            OPTION                  4              0    always                  3              0    always                  2              =0   use of normal formats                                 =1   use of extended formats                  1              =0   use of explicit flow control                                      in Class 2                                 =1   no use of explicit flow                                      control in Class 2        Note:        1.  It is not valid to request 'use of expedited data            transfer' (Additional option parameter) and no use of            explicit flow control in Class 2' (bit 1 = 1).        2.  Bits 4 to 1 are always zero in Class 0 and have            no meaning.8.3.4   Variable Part (Octets 8 to p)        The following parameters are permitted in the variable part:        o  Transport Service Access Point Identifier (TSAP-ID)           Parameter code 11000001 for the identifier of the Calling TSAP.           11000010 for the identifier of the Called TSAP.        If a TSPA-ID is given in the request it may bereturned in the confirmation.        o  TPDU size        This parameter defines the proposed maximum TPDU size(in octets including the header) to be used over the requestedtransport connection.  The coding of this parameter is:        Parameter Code 11000000

ISO Transport Protocol Specification                                   Page 68International Standards Organization        Parameter value field        00001101  8192 octets (not allowed in Class 0 of 1)        00001100  4096 octets (not allowed in Class 0 of 1)        00001011  2048 octets        00001010  1024 octets        00001001  512 octets        00001000  256 octets        00000111  128 octets        Default value is 00000111 (128 octets)        Version Number (not used in Class 0)        Parameter code 11000100        Parameter value field 00000001        Default value 00000001        Default value 00000001 (not used in Class 0)       o Security Parameter (not used in Class 0)         This parameter is user defined.         Parameter code 11000101         Parameter value and length field are user defined       o Checksum (not used in Classes 0 through 3)             SeeSection 8.2.3.1         This parameter must always be present in a CR TPDU         requesting Class 4, even if the checksum selection         parameter is used to request non-use of the checksum facility.       o Additional Option Selection (not used in Class 0)        This parameter defines the selection to be made as to        whether or not additional options are to be used.        Parameter code 11000110

ISO Transport Protocol Specification                                   Page 69International Standards Organization        Parameter length:  1        Parameter value field:        Bits related to options particular to one class are        not meaningful and may take any value in the other classes.             BITS                OPTION             4    1=   Use of network expedited in Class 1                  0=   Non use of network expedited in Class 1             3    1=   Use of receipt confirmation in Class 1                  0=   Use of explicit AK variant in Class 1             2    0=   Checksums are to be used in Class 4                  1=   Checksums are not to be used in Class 4             1    1=   Use of transport expedited data transfer                       service                  0=   No use of transport expedited data transfer                       service             Default falue is 00000001        o Alternative protocol class (not used in Class 0)             Parameter code 11000111             Parameter length  n        Parameter value encoded as a sequence of singleoctets.  Each octet is encoded as for octet 7 but with bits 4-1 setto zero (i.e., no alternative option selections permitted).        o  Acknowledge Time        This parameter conveys the maximum acknowledge time        AL to the remote transport entity.  It is an indication only, and        is not subject to negotiation (seesection 7.4.5.3).        Parameter Code 10000101        Parameter Value field: n a binary number (2 octets)        n is the maximum acknowledge time, expressed in        milliseconds.        o  Throughput      Parameter code:    10001001                            Length         :    12

ISO Transport Protocol Specification                                   Page 70International Standards Organization                            1st 3 octets   :    Targer value,                                                calling-called user                                                direction                            2nd 3 octets   :    Min. acceptable,                                                calling-called                                                user direction                            3rd 3 octets    :   Target value,                                                called-calling user                                                direction                            4th 3 octets  :     Min. acceptable,                                                called-calling user                                                direction             Values are expressed in octets per second.        o Residual          Parameter code:     10000110          error rate                            Length        :     3                            1st octet     :     Target value, power                                                of 10                            2nd octet     :     Min. acceptable,                                                power of 10                            3rd octet     :     TSDU size of                                                interest, expressed                                                as a power of 2        o  Priority         Parameter code:     10000111                            Length        :     2                            Value         :     Integer        o  Transit          Parameter code:     10001000             delay                            Length        :     8                            1st 2 octets  :     Target value,                                                calling-called user                                                direction                            2nd 2 octets  :     Max. acceptable,                                                calling-called user                                                direction.

ISO Transport Protocol Specification                                   Page 71International Standards Organization                            3rd 2 octets  :     Target value,                                                called-calling user                                                direction.                            4th 2 octets  :     Max. acceptable,                                                called-calling user                                                direction             Values are expressed in milliseconds.8.3.5   User Data (Octets p+1 to the end)        No user data are permitted in class 0, and areoptional in the other classes.  Where permitted, it may not exceed32 octets.8.4     Connection Confirm (CC)8.4.1   Structure        1     2     3     4     5     6    7    8    p   p+1        LI CC  CDT DST-REF SOURCE-REF  class  VARIABLE  USER DATA          1101                         options  Part8.4.2   LT        SeeSection 8.2.1.8.4.3   Fixed Part (Octets 2 to 7)             CC                      :          Connection Confirm                                                Code:  1101             CDT                     :          Initial Credit                                                Allocation (set to                                                0000 in Classes 0                                                and 1).             DST-REFERENCE           :          Reference                                                identifying the                                                requested transport                                                connection at the                                                remote transport                                                entity.             SOURCE REFERENCE        :          Reference selected                                                by the transport                                                entity initiating                                                the CC TPDU to

ISO Transport Protocol Specification                                   Page 72International Standards Organization                                                identify the                                                confirmed TC.             CLASSES                 :          Defines the selected                                                transport protocol class to                                                be operated over the accepted                                                TC according to the                                                negotiation rules specified                                                inSection 6.5.8.4.4   Variable part (Octet 8 to p)        SeeSection 8.3.48.4.5   User Data (Octets p+1 to the end)        SeeSection 8.3.58.5     Disconnect Request (DR)8.5.1   StructureLI  DR        DST-REF   SOURCE-REF    REASON    VARIABLE  USER DATA   10000000                                       PART8.5.2   LI             SeeSection 8.2.18.5.3   Fixed Part (Octets 2 to 7)        DR                :      Disconnect Request Code:   1000        DST-REFERENCE     :      Reference identifying the TC at                                 the remote transport entity.        SOURCE REFERENCE  :      Reference identifying the TC at                                 the transport entity initiating                                 the command.  Value zero when                                 reference is unassigned.        REASON            :      Defines the reason for                                 disconnecting the TC.  This field                                 shall take one of the following                                 values:                                 The following values can be used                                 for class 1 to 4:                                 128 + 0 - Normal disconnect

ISO Transport Protocol Specification                                   Page 73International Standards Organization                                 initiated by session entity.                                 128 + 1 - Remote transport entity                                 congestion at connect request time                                *128 + 2 - Connection negotiation failed                                (i.e. proposed class(es) not supported).                                 128 + 3 - Duplicated connection detected                                 128 + 4 - Mismatched references                                 128 + 5 - Protocol error                                 128 + 6 - Not used                                 128 + 7 - Reference overflow                                 128 + 8 - Connection request refused on this                                 network connection                                 128 + 9 - Not used                                 128 + 10 - Header or parameter length invalid             The following values can be used for all classes.                  0 -  Reason not specified                  1 -  Congested at TSAP                  *2   Session entity not attached to TSAP                  *3   Address unknown             Note:     Reasons marked with '*' may be reported to                       the TS-user as 'persistent', other reasons                       as 'transient'.8.5.4   Variable Part (Octets 8 to 10)        o    A parameter may be provided to allow additional             information related to the clearing of the connection.             Parameter code:       11100000             Parameter Value Field:  Additional information.  This             field is intended to be used by the transport service             provider for internal purposes.

ISO Transport Protocol Specification                                   Page 74International Standards Organization        o    Checksum (see 8.2.3.1)8.5.5   User Data (Octets p+1 to the end)        Not allowed in class 0,        This field may not exceed 64 octers and is usedto carry TS-User data.  The successful transfer of this data is notguaranteed.8.6     Disconnect Confirm (DC)        (Not used in Class 0)8.6.1   Structure        1     2         3       4       5      6        7        p        LI             DST-REFERENCE  SOURCE-REFERENCE  Variable Part           110000008.6.2   LI        SeeSection 8.2.18.6.3   Fixed Part (Octets 2 to 6)             DC            :     Disconnect Confirm Code:  1100             DST-REFERENCE :     SeeSection 8.3.3             SOURCE-REFERENCE:   SeeSection 8.4.38.6.4   Variable Part             Checksum (see 8.2.3.1)8.7     Data (DT)8.7.1   Structure             Normal Format for Class 0 to 1        1     2          3           4         5        LI   DT     E    TPDU-NR    User Data           11110000 0                    T             Normal format for Class 2, 3 and 4

ISO Transport Protocol Specification                                   Page 75International Standards Organization1        2      3        4          5          6       p     p+1LI             DST-REFERENCE    E   TPDU-NR   Variable Part  User Data   11110000                     O                                T        Extended Format for optional use in Classes 2,3 and 4        1       2      3       4     5,6,7,8    9        p p+1        LI   DT     DST-REFERENCE  E  TPDU-NR  Variable  User Data           11110000                O                                   T8.7.2   LISection 8.2.18.7.3   Fixed Part        (Classes 0 to 1  : -  Octets  2 to 3; classes 2,3,4normal format:  Octets 2 to 5; classes 2,3,4 extended format: -Octets 2 to 8)             DT             :    Data Transfer Code:  1111             DST-REFERENCE  :    SeeSection 8.4.3             EOT            :    When set to ONE, indicates that                                 the current DT TPDU is the last                                 Data Unit of a complete DT TPDU                                 sequence (End of TSDU).             TPDU-NR        :    TPDU Send Sequence Number (Zero in                                 Class 0), may take any value in                                 Class 2 without explicit flow                                 control.8.7.4   Variable Part        Checksum (See 8.2.3.1)8.7.5   User Data Field        This field contains data of the TSDU being transmitted.The length of this field is limited to the negotiated TPDU size forthis transport connection minus 3 octets in Classes 0 and 1,and minus 5 octets (normal header format) or8 octets (extended header format) in the other classes.Thevariable part, if presemt, amy further reduce the size of the userdata field.

ISO Transport Protocol Specification                                   Page 76International Standards Organization8.8     Expedited Data (ED)        (Not used in Class 2 when "no explicit flow         control" option is selected.)8.8.1   Structure        Normal Format     1        2      3        4        EOT 5        6     p        p + 1     LI       ED    DST-REFERENCE     EDTPDU-NR    Variable Part  User Data           00010000                 1.        Extended Format     1        2        3      4        EOT 5,6,7,8  9    p          p + 1     LI       ED     DST-REFERENCE       EDTPDU-NR  Variable Part   User Data           00010000                    1.8.8.2   LI        SeeSection 8.2.18.8.3   Fixed Part        (Octets 2 to 5, normal format: 2 to 8, extended format)        ED:            Expedited Data command code: 0001        DST-REFERENCE: Same asSection 8.4.3        ED TPDU-NR:    Expedited TPDU identification number                       (Classes 1, 3, and 4; may take any value in                       Class 2).8.8.4   Variable Part        Checksum (See 8.2.3.1)8.8.5   User Data Field        This field contains an expedited TSDU.  Up to 16 octets.8.9     Data Acknowledgement (AK)        Not applicable for Class 0 and Class 2 when the "noexplicit flow control" option is selected, and for Class 1 when thenetwork receipt confirmation option is selected.

ISO Transport Protocol Specification                                   Page 77International Standards Organization        Flow Control Confirmation (class 4 only - optionally used)        This parameter contains a copy of the information receivedin an AK TPDU, to allow the transmitter of the AK TPDU to be certainof the state of the receiving transport entity (SeeSection 7.4.5.6).        Parameter Code:  100001011        Parameter value field 64 bits, used as follows:        o  Lower Window Edge (32 bits)           Bit 32 is set to zero, bits 31 to 1 contain the           YR-TU-NR value of the received AK TPDU.  When normal           format is in use, only the least significant seven           bits (bits 1 to 7) of this field are significant.        o  Your Sub-Sequence (16 bits)           Contains the value of the sub-sequence parameter of           the received AK TPDU, or zero if this parameter was           not present.        o  Your Credit (16 bits)           Contains the value of the CDT field of the received AK           TPDU.  When normal format is in use, only the least           significant four bits (bits 1 to 4) of this field are           significant.8.10    Expedited Data Acknowledgement (EA)        (Not applicable for Class 0 and Class 2 when the no        explicit flow control option is selected).8.10.1  Structure        Normal Format     1       2       3       4         5               6         p     LI      EA      DST-REFERENCE      . YR-TU-NR     Variable Part            00100000                  0.        Extended Format     1      2         3       4          5,6,7,8            9      p     LI     EA        DST-REFERENCE       . YR-TU-NR        Variable Part           00100000                     0.8.9.1   Structure

ISO Transport Protocol Specification                                   Page 78International Standards Organization        Normal Format      1       2          3          4         5            6       p      LI      AK CDT     DST-REFERENCE         . YR-TU-NR  Variable Part             0110                            0.        Extended Format     1      2         3       4        5,6,7,8       9,10    11    p     LI     AK        DST-REFERENCE     . YR-TU-NR   CDT     Variable Part           01100000                   0.8.9.2   LI        SeeSection 8.2.18.9.3   Fixed Part        (Octets 2 to 5, normal format:  2 to 10, extended format)        AK:            Acknowledgement command code:  0110        CDT:           Credit Value (set to 0 in class 1)        DST-REFERENCE: Same asSection 8.4.3        YR-TU-NR:      Sequence number indicating the next expected                       DT TPDU number.8.9.4   Variable Part        Checksum (See 8.2.3.1)        Sub-sequence number (class 4 only - optionally used).        This parameter is used to ensure that AK TPDUs are        processed in the correct sequence.  If it is absent, this is        equivalent to transmitting the parameter with a value of zero.        Parameter Code:  100001010        Parameter Value: 16-bit sub-sequence number.8.10.2  LI        SeeSection 8.2.18.10.3  Fixed Part

ISO Transport Protocol Specification                                   Page 79International Standards Organization        (Octets 2 to 5, normal format; 2 to 8, extended        format)        EA:            Acknowledgement command code:  0010        DST-REFERENCE: Same asSection 8.4.3        YR-TU-NR:      Identification of the ED TPDU being                       acknowledged.  May take any value in Class 2.8.10.4  Variable Part        Checksum (See 8.2.3.1)8.11    Reject (RJ)        (Not used in Classes 0, 2, and 4)8.11.1  Structure        Normal Format       1       2        3       4          EOT 5          6       p       LI      RJ CDT   DST-REFERENCE       . YR-TU-NR    Variable Part              0101                        0.        Extended Format      1        2       3        4          EOT 5,6,7,8    9,10     11      p      LI       RJ      DST-REFERENCE        .  YR-TU-NR   CDT      Variable              0l0l0000                                              Part8.11.2  LI        SeeSection 8.2.18.11.3  Fixed Part        (Octets 2 to 5, normal format; 2 to 10, extended format)        RJ:            Reject Command Code:  0101        CDT:           Credit Value (set to 0 in class 1)        DST-REFERENCE: Same asSection 8.4.3        YR-TU-NR:      Sequence number indicating the next expected                       TPDU from which retransmission should occur.

ISO Transport Protocol Specification                                   Page 80International Standards Organization8.11.4  Variable Part        No parameters exclusive to this TPDU type.8.12    TPDU Error (ERR)      1         2          3        4        5             6      LI        ERR        DST-REFERENCE     Reject        Parameters               01110000                      Cause8.12.1  LI        SeeSection 8.2.18.12.2  Fixed Part        ERR:           TPDU Error Code: 0111        DST-REFERENCE: Same asSection 8.4.3        REJECT CAUSE:                       00000000  Reason not specified                       00000001  Invalid parameter code                       00000010  Invalid TPDU type                       00000011  Invalid parameter value8.12.3  Variable Part (Octets 6 to the end)        Parameter Code:  1100001        Parameter Value Field:        Contains the bit pattern of the rejected TPDU up to andincluding the octet which caused the rejection.  This parameter ismandatory in Class 0.        Checksum (SeeSection 8.2.3.1)SECTION THREE - CONFORMANCE9.      CONFORMANCE        Implementations claiming conformance to this standard shall:        1.   Implement either Class 0 or Class 2 or both.

ISO Transport Protocol Specification                                   Page 81International Standards Organization        2.   If other classes are implemented, the following rules             shall be observed:             a)  If Class 3 or Class 4 is implemented then Class 2             must be implemented             b)  If Class 1 is implemented then Class 0 must be             implemented.        3.   The following table defines the requirements for the             implementation of the options defined in previous             sections:                                                Class                                            0     1    2     3    4        TPDU with Checksum                 no    no   no    no    m        TPDU without Checksum               m     m    m     m    o        Expedited Data Transfer            no     m    m     m    m        No Expedited Data Transfer          m     m    m     m    m        Flow Control in Class 2            no    no    m    no   no        No Flow Control in Class 2         no    no    o    no   no        7 bits format (normal)             m     m    m     m    m        31 bits format (extended)          no    no    o     o    o        Use of Receipt Confirmation in     no     o   no    no   no        Class 1        No use of Receipt Confirmation in  no     m   no    no   no        Class 1        Use of Network Expedited in Class  no     o   no    no   no        1, if T-EXPEDITED DATA necessary        No use of Network Expedited in     no     m   no    no   no        Class 1, if T-EXPEDITED DATA necessary        o  -  optional:     An implementation may or may not                            provide this user-selected option.        m  -  mandatory:    An implementation must provide for this                            option        no  -               An implementation shall not provide                            this option.        4.   Implementations claiming conformance shall support a             TPDU length of 128 octets.  If larger maximum TPDU

ISO Transport Protocol Specification                                   Page 82International Standards Organization             sizes can be supported in Classes 1,2,3, or 4, then             all permitted TPDU sizes between the maximum and 128             octets shall be supported.        5.   Claims of conformance shall state:             a)  which class of protocol is supported.             b)  which additional options indicated by the letter             'o' in the above table are supported.