Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 0892

ISO Transport Protocol specification

Pages: 82
Obsoleted by:  0905
Part 1 of 3 – Pages 1 to 24
None   None   Next

ToP   noToC   RFC0892 - Page 1
Network Working Group                                   ISO
Request for Comments:  892                              December 1983


                     ISO Transport Protocol Specification

This 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 Contents

0.   Introduction
1.   Scope and Field of Application
2.   References

Section One - General

3.   Definitions
4.   Symbols and Abbreviations
5.   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 layer

Section Two - Transport Protocol Specification

6.   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

ToP   noToC   RFC0892 - Page 2
     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 recombining

7.   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 class

8.   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  -  Conformance

9.   Conformance

0.   Introduction

        The Transport Protocol Standard is one of a set of International
Standards produced to facilitate the interconection of computer
systems.  The set of standards covers the services and protocols
required to achieve such interconnection.

        The Transport Protocol Standard is positioned with respect to
other related standards by the layers defined in the Reference Model
for Open Systems Interconnection (ISO 7498).  It is most closely
related to, and lies within the field of application of the Transport

ToP   noToC   RFC0892 - Page 3
Service Standard (DP aaaa).  It also uses and makes reference to the
Network Service Standard (DP bbbb), whose provisions it assumes in
order to accomplish the transport protocol's aims.  The
interrelationship 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 of 
classes of transport protocol procedures to be used with different 
network qualities of service.

        It is intended that the Transport Protocol should be simple 
but general enough to cater for the total range of Network Service
qualities possible, without restricting future extensions.

        The protocol is structured to give rise to classes of protocol 
which are designed to minimize possible incompatibilities and 
implementation costs.

        The classes are selectable with respect to the Transport and 
Network Services in providing the required quality of service for the
interconnection of two session entities (note that each class provides
a different set of functions for enhancement of service qualities).

        This protocol standard is concerned with optimisation of network
tariffs 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 definition 
for implementors.  Since the protocol is complex, the document contains
much material which is advisory or descriptive, but mandatory
requirements on implementations are clearly identified. 

        It should be noted that, as the number of valid protocol sequences 
is very large, it is not possible with current technology to verify that an
implementation will operate the protocol defined in this document
correctly under all circumstances.  It is possible by means of testing

ToP   noToC   RFC0892 - Page 4
to establish confidence that an implementation correctly operates the
protocol in a representative sample of circumstances.  It is, however,
intended that this standard can be used in circumstances where two
implementations fail to communicate in order to determine whether one
or both have failed to operate the protocol correctly.

        The variations and options available within this standard are
essential to enable a Transport Service to be provided for a wide
variety of applications over a variety of network qualities.  Thus, a
minimally conforming implementation will not be suitable for use in
all possible circumstances.  It is important therefore to qualify all
references to this standard with statements of the options provided or
required or with statements of the intended purpose of provision or
use.

1.      Scope and Field of Application

1.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

ToP   noToC   RFC0892 - Page 5
            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.      References

ISO 7498        Information processing systems - Open systems inter-
                connection - Basic Reference Model

DP 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 - General

3.      Definitions

3.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 Abbreviations

4.1     Data Units

        TPDU    Transport protocol data unit
        TSDU    Transport service data unit
        NSDU    Network service data unit

4.2     Types of transport protocol data units


ToP   noToC   RFC0892 - Page 6
        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 TPDU

4.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 number

4.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 information

4.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

ToP   noToC   RFC0892 - Page 7
4.7     Miscellaneous

        TS-user         Transport service user
        TSAP            Transport service access point
        NSAP            Network service access point
        TC              Transport connection
        NC              Network Connection

5.      Overview of the Transport Protocol

5.1     Service Provided by the Transport Layer

        The services provided by the protocol described in this
document are connection-oriented services.  They are defined in
document DP aaaa.  The Transport Service primitives provided are
summarized in Figure 1.

ToP   noToC   RFC0892 - Page 8
        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 Primitives

5.2     Service Assumed from the Network Layer

        The transport protocol described in this document assumes of
the Network Services described in DP bbbb.  The Network Service
primitives used are summarized in Figure 2.

ToP   noToC   RFC0892 - Page 9
        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               Y
ACKNOWLEDGE Indication
------------------------------------------------------------------------
N-EXPEDITED Request               Y     
DATA        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 Primitives

5.3     Functions of the Transport Layer

5.3.1   Connection Oriented Functions

5.3.1.1  Overview of Functions

        The functions in the transport layer are at least those
necessary to bridge the gap between the services available from the
network layer and those to be offered to the transport users.

        The functions in the transport layer are concerned with the
enhancement of quality of service, including all aspects of cost
optimization.  They are described below; the descriptions are grouped
into those concerned with the establishment phase, the data transfer

ToP   noToC   RFC0892 - Page 10
phase, and the release phase.

5.3.1.1.1  Establishment Phase

        The goal of the establishment phase is to establish a
transport connection, i.e., between two transport users.  The
functions of transport layer during this phase must match the
requested class of services with the services provided by the network
layer 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-way
simultaneous transport of TSDUs between the session entities connected
by the transport connection.  This purpose is achieved by means of
two-way simultaneous communication in the Transport protocol and by
the following functions. Each of these functions is used or not used
in accordance with the result of the selection performed in the
establishment 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.


ToP   noToC   RFC0892 - Page 11
        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

ToP   noToC   RFC0892 - Page 12
        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 terms
of quality with respect to error behavior relative to the user
requirements.  Its main purpose is to provide a basis for the decision
regarding which class of transport connection should be used on top of

ToP   noToC   RFC0892 - Page 13
a 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 the
quality of service provided by particular Network connections.

5.3.1.3  Potential Functions

        The protocol described in this document does not include the
following set of functions which have been identified as potential
transport 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 connections

5.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 Layer
communicates with a Transport User through a TSAP by means of the

ToP   noToC   RFC0892 - Page 14
service primitives as defined by the transport service definition DP
aaaa.  Service primitives will cause or be the result of Transport
Protocol Data Unit exchanges between the peer Transport Protocol
entities supporting a Transport Connection.  These protocol exchanges
are effected using the services of the Network Layer as defined by the
Network Service Definition DP bbbb through one or more NSAPs.

        Transport connection endpoints are identified in end systems
by an internal, implementation dependent, mechanism so that the
Transport User and the Transport Protocol entity can refer to each
Transport connection.

Section Two - Transport Protocol Specification

6.      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 first
transport connection over a network connection, it must also be invoked
for any and all other transport connections which use that network
connection 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 must
be assigned to one (or more if splitting function is being used)
network connection(s).  Both transport entities involved must become
aware of this assignment.  A transport connection may be assigned to a
suitable existing network connection; one or more new network
connections may also be created for the purpose.

        An existing network connection, which connects the relevant
transport entities, is unsuitable for assignment of a transport
connection if, for example:

        o  the quality of service needed for the transport connection
           can not be met by using or enhancing the network

ToP   noToC   RFC0892 - Page 15
           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 of
service requested is a local matter, though it will normally be
related to the requirements of transport connection(s) expected to be
assigned to it.

        A Network Connection with no transport connections will be
available after initial establishment or because explicit
disconnection of all the transport connections previously assigned to
it has taken place.  Either Transport entity may as a local
matter choose to disconnect the Network Connection or assign other
Transport 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 the
protocol 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

ToP   noToC   RFC0892 - Page 16
        TPDUs are conveyed using the NS-User data parameters of the
Network Service primitives, primarily with the N-DATA, but also with
N-EXPEDITED primitives.

        Transport entities shall accept all permissible assignments and
may issue any permissible assignments.  The permissible assignments of
TPDUs to these primitives are shown in Figure 4.  Concatenation of
TPDUs is also permitted (see section 6.4).

Primitive               Applicable TPDUs                        Note

N-DATA                  CR, CC, DR, DT, ED,
                        AK, EA, RJ, DC, ERR

N-EXPEDITED             ED, EA                                  1

Notes:

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 octets
up 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 a
TSDU.

        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

ToP   noToC   RFC0892 - Page 17
either a single category 1 DT TPDU or consecutive category 2 followed
by 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 (see
Section 8.2.1).  Additionally, TPDUs are classified as either Data
TPDUs or Control TPDUs.  Control TPDUs may or may not contain a data
field.  For TPDUs containing data the length of the data field is
indicated by the length of the NSDU.  These provisions permit any
number of Control TPDUs that may not contain data to be concatenated
with a single control TPDU which may contain data or with a single
Data TPDU.  The control TPDUs without data must precede the TPDU with
data, if any.  The number of TPDUs so concatenated is terminated by
the end of the NSDU.

        The concatenated set of TPDUs may be for the same or different
transport connections.  An implementation shall accept concatenated
TPDUs and may concatenate TPDUs before transmission.  The transport
entity shall not send a concatenated set of TPDUs which exceeds twice
the overall maximum TPDU length for all the TCs assigned to the
network 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

ToP   noToC   RFC0892 - Page 18
        - 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 one
transport entity (the initiator) transmitting a Connection Request
(CR) TPDU to the other transport entity (the responder), which replies
with a Connection Confirm (CC) TPDU.  Before sending the CR TPDU, the
initiator assigns the transport connection being created to one (or
more 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 the
transport 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 the
Reference which the partner will use.  This mechanism is symmetrical
and therefore avoids the need to assign a status of master or slave to
partners and avoids call collision.  This mechanism also provides
identification of the transport connection independent of the network
connection. The range of References used for transport connections, in
a 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.


ToP   noToC   RFC0892 - Page 19
        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 preferred
class and any number of alternatives.  (Except that no alternatives are
allowed when class 0 is the preference.)  The initiator should assume
when 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 which
includes resynchronization (see "Resynchronization", Section 6.15) is
preferred, resynchronization will occur if a reset is signalled during
connection establishment.

        When the responder has decided which class is to be used, it
shall indicate this in the CC TPDU and shall invoke the appropriate
functions for the class.  The responder may select the preferred
class, or any of the alternative classes or may select class 0 if
class 1 is proposed or class 2 if class 3 or 4 is proposed. (see
Section 9)

        If the preferred class is not selected, then on receipt of the
CC TPDU, the initiator shall adjust its functions accordingly.

        o  TPDU Size.  The initiator may propose a maximum size for
TPDUs, and the responder may accept this value or respond with any
value between the proposed value and 128 in the set of values
available (see "Encoding", Section 8).

        o  sequence number length.  Either normal or extended is
available.  When the sequence number is extended, the credit field (if
applicable) is also extended.

        o  checksum selection.  This defines whether or not TPDUs of
the connection are to include a checksum.

        o  version number.  This defines the version of the transport
protocol standard used for this connection.

        o  security parameter.  This parameter and its semantics are
user 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 is
negotiated.


ToP   noToC   RFC0892 - Page 20
        o  The use of Network Receipt Confirmation and Network
expedited is negotiated when class 1 is to be used.

        The negotiation rules for the options are such that the
initiator may propose either to use or not to use the option.  The
responder may either accept the proposed choice or select the
mandatory alternative defined in Section 9.

        During the establishment phase of the transport connection,
the use of the expedited data option field of CR/CC  allows both
Transport Service user to negotiate the use or non use of the
expedited data transport service as described in the transport service
definitions.

        The following table summarizes the negotiation possibilities
for the options.

                                Proposition Made        Possible
                                by the Initiator        Selection by 
        Option                                          the Responder

Transport expedited data             Yes                  Yes or No
transfer service                     No                       No

Use of receipt confir-               Yes                  Yes or No
mation (class 1 only)                No                       No

Use of the network                   Yes                  Yes or No
expedited variant                    No                       No
(class 1 only)

Non use of checksum                  Yes                  Yes or No
(class 4 only)                       No                       No

Non use of explicit                  Yes                  Yes or No
flow control (class 2 only)          No                       No

Use of extended format               Yes                  Yes or No
                                     No                       No

        In class 2, whenever a transport entity requests or agrees to
the Transport Expedited data transfer service or to the use of
extended formats, it must also request or agree (respectively) to the
use of explicit flow control.

6.6     Connection Refusal

        Purpose:        Refusal of the transport connection.

        TPDUs and fields used:

ToP   noToC   RFC0892 - Page 21
        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 called
transport entity shall respond to the CR TPDU with a DR TPDU.  The
clearing reason shall indicate why the connection was not accepted.
The source reference field in the DR TPDU is set to zero to indicate
an unassigned reference.

        If the CR is regarded as an invalid TPDU, the called transport
entity 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 disconnects
a transport connection by disconnecting the network connection to
which it is assigned.  Similarly when a transport entity is informed
that the network connection has been disconnected by the peer
transport entity, this should be considered as a transport
disconnect.


ToP   noToC   RFC0892 - Page 22
        In the 'explicit' variant, either transport entity transmits a
Disconnect Request (DR) TPDU, and the other responds with a Disconnect
Confirm (DC) TPDU.  When the DC TPDU is sent or received by a
transport entity, that entity should consider the transport connection
not to exist (note 1).  After the sending of a DR TPDU, other TPDUs
received before the DC TPDU are ignored.  It is possible that a
disconnect collision will occur, when both transport entities send a
DR TPDU at about the same time.  This results in each transport entity
receiving a DR, after sending one.  Each transport entity shall
consider the received DR TPDU as a confirmation of its DR TPDU, and
shall 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 the
occurrence of a signalled error for which recovery functions are not
operative.

        Network Service Primitives:

        N-DISCONNECT Indication
        N-RESET Indication

        Description:

        When, on the network connection to which a Transport
Connection is assigned, an N-DISCONNECT or N-RESET Indication occurs,
both transport entities shall consider that the transport connection
no longer exists, and so inform the session entities.

Note 1:

        When a connection has been released, after the exchange of DR
and DC, the reference can be re-used immediately (except in Class 4,
where the Frozen Reference function is used, see Section 6.19).  This
is because the releasing transport entity does not know with certainty
that the remote transport entity considers use of the reference to be
ended.  Therefore, the reference should not be re-used for further
connections.  (In practice, the reference may be re-used after a
reasonable period when it is possible to be reasonably certain that
the 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:


ToP   noToC   RFC0892 - Page 23
        DR, DC
        - source reference
        - destination reference

        Description:

        A DR TPDU can be received for a transport connection which
does not exist.  Rather than treating this as an error, a DC TPDU
should be send back which reflects the references of the DR TPDU.

Note:
        This only applies when one or more transport connections using
a multiplexing class exist over the network connection, or when no
transport 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 transport 
connection bear a sequence number 'TPDU-NR'.  Its value in the first
DT 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**31
in the 'extended' variant.

        In the sections that follow, the relationships 'greater than'
and 'less than' are used in connection with TPDU numbers.  In all 
such uses, the numbers being compared cover a range less than the 
modulus and in fact lie within a contiguous set of TPDU numbers called
a 'window'.  The window has a known starting TPDU number and finishing 
number.  The term 'less than' means 'occurring sooner in the window
sequence' and the term 'greater than' means 'occurring later in the
window sequence'.

6.11    Expedited Data Transfer

        Variants:  'network expedited' or not

        Purpose:  Provision of the expedited data service

ToP   noToC   RFC0892 - Page 24
        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 Expedited
Data (ED) TPDU.  

        Each ED TPDU received must be acknowledged by an Expedited
Acknowledge (EA) TPDU.  

        There may only be one ED TPDU unacknowledged at any time for each
direction 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 DATA
primitives.  Otherwise, N-DATA is used.  

6.12    Reassignment

        Purpose:  Assignment of a Transport Connection to a different
Network Connection.

        TPDUs and Fields Used:

        CR
        - source reference

        RJ, DR
        - destination reference

        Description:

        When the Network Connection to which a Transport Connection was
assigned no longer exists, the Transport Connection can be assigned to
another Network Connection.  

        When one transport entity has assigned the Transport Connection,
it is important that the other transport entity recognise to which 
Network Connection it has been assigned.  This can only take place when it



(next page on part 2)

Next Section