Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 0892

ISO Transport Protocol specification

Pages: 82
Obsoleted by:  0905
Part 2 of 3 – Pages 25 to 52
First   Prev   Next

ToP   noToC   RFC0892 - Page 25   prevText
has received a TPDU for the Transport Connection on a Network Connection
with calling and called network addresses which imply 
the same transport entities as the old.  The TPDU will have been sent 
as 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 been
assigned 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 connection
to which a transport connection is assigned, the transport connection must 
be reassigned by its initiator (see "Reassignment")

        If the reassignment has not successfully occurred within a time
of T-wait seconds, then the transport connection must be considered as
non-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 communicating
transport entities.  

6.14    Retention Until Acknowledgement of TPDUs

        Variants:  'confirmation of receipt' or 'AK'

        Purpose:  To enable and minimize retransmission after
possible loss of TPDUs.

        Network Service Primitives:

        N-DATA
        N-DATA ACKNOWLEDGE

        TPDUs and Fields Used:

        CR, CC, DR, DC

ToP   noToC   RFC0892 - Page 26
        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 transmission
to permit their later retransmission:

                CR, CC, DR, DT, ED.

        NOTE:  If DR is sent in response to CR there is no need to 
retain a copy of the DR.

        In the 'confirmation of receipt' variant, applicable only 
in Class 1, transport entities receiving N-DATA Indications which
convey DT TPDUs and have the confirmation request field set shall
issue a N-DATA Acknowledge Request at the earliest possible
opportunity (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 when
the 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

ToP   noToC   RFC0892 - Page 27
                        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 TPDUs

6.15    Resynchronization

        Purpose:  To restore the connection to normal after an 
error.  

        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 both
transport entities.  

        After a network connection failure, the reassignment after
failure 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)

ToP   noToC   RFC0892 - Page 28
        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 after 
receipt of the TPDU which commenced resynchronization.  This TPDU
therefore serves two purposes, namely indication of re-assignment
and 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 until 
CC becomes acknowledged, to prevent the network expedited overtaking the 
CC.  

        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


ToP   noToC   RFC0892 - Page 29
                        -       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 1
protocol to decide on a local basis to issue an N-RESET Request.  The effect
of this request at the remote transport entity is to force it to perform
the resynchronization mechanism.  This possibility may be used to remove 
congestion within the network connection.  

6.16    Multiplexing and Demultiplexing

        Purpose:  Concurrent sharing of a network connection by several
transport 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 transport 
connection can be simultaneously assigned to the same network connection.

        Every TPDU (including DT TPDUs) must carry the destination 
reference, to identify the transport connection to which it refers.  

6.17    Explicit Flow Control

        Purpose:  Regulation of flow of DT TPDUs independently of 
the 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)

ToP   noToC   RFC0892 - Page 30
        Description:

        The mechanism depends on the class.  Thus the description can
be found in the section describing the class. 

6.18    Checksum

        Purpose:  To detect corruption of TPDUs by the network service
provider.  

        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 the
checksum option, the sending transport entity must generate a checksum
for the TPDU and store it in the checksum parameter in the variable
part of the TPDU header.  The checksum must be generated as follows:

        1.      Set up the complete TPDU, including the header and 
user data (if any).  The header must include the checksum parameter in
its variable part.  The value field of the checksum parameter must be
set to zero at this point.  

        2.      Initialize two variables to zero.  Let these variables 
be 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 to 
C0, and then add the value of C0 to C1.  Octets should be processed
sequentially, starting with the first octet (the Length Indicator) and
proceeding through the TPDU.  All addition is to be performed modulo 255.

        4.      Calculate the value field of the checksum parameter as
follows.  Let the offset into the TPDU of the first octet of the value 
field be 'n' (where the first octet of the TPDU, the Length Indicator
of the header, is considered to be at offset 1).  Let the length 
of 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 appropriate
octets of the TPDU.  

ToP   noToC   RFC0892 - Page 31
                                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 option
has been selected, the TPDU must be verified to ensure that it has been
received correctly.  This is done by computing the checksum, using the
same algorithm by which it was generated.  The nature of the checksum
algorithm is such that it is not necessary to compare explicitly the stored
checksum bytes.  The procedure described below may be used to verify that 
a TPDU has been correctly received.  

        1.      Initialize two variable to zero.  Let these variables
be called C0 and C1.  

        2.      For each octet in the received TPDU, add the value of
the octet to C0 and then add the value of C0 to C1, starting with the
first octet and proceeding sequentially through the TPDU.  All 
addition is to be performed modulo 255.  

        3.      When all octets have been sequentially processed, the
values of C0 and C1 should be zero.  If either or both of them is 
non-zero, the TPDU has been received incorrectly and the verification
has failed.  Otherwise, the TPDU has been received correctly and the 
TPDU 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 possible
to determine the TC that the TPDU relates to, since the Reference field
of the TPDU may have been received incorrectly.  Therefore, all TCs
multiplexed onto the same NC must be treated as though a network signalled
error has occurred.  

6.19    Frozen References

        Purpose:  To prevent re-use of a reference while TPDUs associated
with the old use of the reference may still exist.  

        Description:  When a transport entity determines that a particular
connection has terminated, the reference shall be placed in a frozen state 

ToP   noToC   RFC0892 - Page 32
during which time it will not be reused.  The circumstances under which
this is done, and the period of time for which the reference remains
frozen depends on the class.   

6.20    Retransmission on Timeout

        Purpose:  To cope with unsignalled loss of TPDUs by the network
service 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 network
service 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 network
connection.  

        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.

ToP   noToC   RFC0892 - Page 33
        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 by
any operative function, or which is regarded as a violation of the protocol
rules of the class in use (e.g., receipt in a wrong state, window error,
sequencing error, TPDU with incorrect format), shall be considered as a 
protocol error.  Such an error shall be signalled to the transport entity
responsible by the sending of an TPDU Error (ERR) TPDU or by initiating a 
release.  The ERR TPDU conveys the octets of the offending TPDU up to
and including the octet where the error was detected.  

        In general, no further action is defined for the sender of 
ERR TPDU, since it is expected that the offender will either correct 
the error, or close the connection.  

        Action to be done by the receiver depends on local implementation
decision; e.g., freeze the connection, report to management, disconnect.  

NOTES:  

        1.      Further action is a local implementation issue.  Care
should be taken by the transport entity receiving several invalid TPDUs
or ERR TPDUs to avoid looping if the error is repeatedly generated.  

        2.      There are two cases in which specific action is defined
for the receiver of the ERR TPDU (see Sections 6.6 and 7.0.7).  

6.24    Splitting and Recombining

        Purpose:  To allow a transport connection to make use of 
multiple network connections to provide additional resilience against
network 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 is 
assigned (see Section 6.1) to multiple network connections. TPDUs for the 

ToP   noToC   RFC0892 - Page 34
connection may be sent over any assigned network connection.  The 
resequencing function of Class 4 (see Section 6.21) is used to ensure
that TPDUs are processed in the correct sequence.  

        If the use of Class 4 is not accepted by the remote transport
entity following the negotiation rules, only the network connection
over which the CR TPDU was sent may be used for this transport
connection.  

        The splitting function should only be used where the 
supporting network connections provide similar transmit delay.  

   Protocol Mechanism           Variant         0  1  2  3  4

Assignment 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  o

Expedited Data Transfer         network exp.      ao
                                not "              m  *  *  *
                                                     (1)

Reassigment                                        *     *

Reassignment after Failure                         *     *

Retention until Acknowledge-    Conf. Receipt     ao
ment of TPDUs                   AK                 m     *  *

Resynchronization                                  *     *

Multiplexing and                                      *  *  *
Demultiplexing


ToP   noToC   RFC0892 - Page 35
Explicit Flow Control With                            m  *  *
                      Without                   *  *  o 

Checksum   (use of)                                         m
           (non-use of)                         *  *  *  *  o

Frozen 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 flow
control is selected.  

7.      PROTOCOL CLASSES

        The details of the implementation of the protocol 
mechanisms are in certain cases different for different classes.  
For this reason, the following table is not intended to provide a 
complete description of the classes, but more to give an overview of 
how each class works.  The exact definition of the protocol is given 
in 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 CLASS

7.0.1   Characteristics of Class 0

        The characteristic of this class is that it provides 
the simplest type of transport connection and fully compatible 

ToP   noToC   RFC0892 - Page 36
with the CCITT recommendations S.70 for Teletex terminals.

        The class is designed for use in association with 
network 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 connection 
establishment with negotiation, data transfer with segmenting and 
protocol error reporting.

        Class 0 provides transport connections with flow 
control based on the network service provided flow control, and 
disconnection based on the network service disconnection.

7.0.3   Protocol Mechanisms of Class 0

7.0.3.1  Connection Establishment Phase

        Connection shall be made in accordance with the 
general rules (Assignment of Network Connection, Connection 
Establishment and Connection Refusal) with the following 
restrictions:

        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 release 
procedure for this class.  The lifetime of the transport connection 
is directly correlated to the lifetime of the network connection.

7.0.4   Connection Establishment for Class 0

        The connection establishment function is used 
with the contraint that only the transport entity which has 
requested the establishment of the network connection may send the 
CR TPDU.  If the calling transport entity receives a CR TPDU, it 
shall transfer a TPDU Error (ERR) TPDU to notify the called 
transport entity of the procedure error.


ToP   noToC   RFC0892 - Page 37
7.0.5   Data Transfer Procedures

7.0.5.1  General 

        The data transfer procedures described in the 
following subsections apply only when the transport layer is in the 
data transfer phase, that is after completion of Transport 
Connection establishment.

7.0.5.2  Transport Data TPDU maximum length

        For Class 0 the standard maximum transport data 
TPDU length is 128 octets including the data TPDU header octets.

        Other maximum TPDU lengths may be supported in 
conjunction with the optional transport data TPDU size negotiation 
function (see Section 8.3 and 8.4).  Optional maximum data field 
lengths shall be chosen from the following list:  256, 512, 1024 
and 2048 octets.

        TSDUs are transmitted using the segmenting function.

7.0.6   Release  Procedure

        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 the 
high layer is informed about this disconnection.

7.0.9   Supported Options

        None

7.1     PROTOCOL DESCRIPTION OF CLASS 1:  BASIC ERROR RECOVERY CLASS

7.1.1   Characteristics of Class 1

        The characteristic of this class is that it 
provides a basic transport connection with minimal overheads.

        The main purpose of the class if to recover from 
network signalled errors (network disconnect or reset).

        Selection of this class is usually based on 

ToP   noToC   RFC0892 - Page 38
reliability criteria.  Class 1 has been designed to be used in 
association with type B network connections.

7.1.2   Functions of Class 1

        Class 1 provides transport connections with flow 
control based on the network service provided flow control, error 
recovery, expedited data transfer, disconnection, and also the 
ability to support consecutive Transport connections on a network 
connection.

        This class provides the functionality of Class 0 
plus the ability to recover after a failure signalled by the Network 
Service, without involving the user of the Transport Service.

7.1.3   Protocol Mechanisms of Class 1

        Class 1 protocol mechanisms include Class 0 
protocol mechanisms plus the following:

7.1.3.1  User Data in the Connection Phase

        Class 1 provides the possibility of conveying 
data in the connection request and confirm commands.

7.1.3.2  Numbering of Data TPDU

        Each Data TPDU transmitted between transport entities for 
each direction of transmission in a transport connection is 
sequentially 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 transmitted 
TPDUs 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 determine
which TPDUs must be retransmitted.

        Resynchronization may also be invoked by a transport entity
as a local matter.  For that purpose the Resynchronization function is
used (see note at the end of Section 6.15).

7.1.3.5  Acknowledgement

        Acknowledgements are used to release copies of retained TPDUs.

ToP   noToC   RFC0892 - Page 39
Two methods of acknowledgment are provided in the Retention until 
Acknowledgement 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 the 
Connection Establishment Phase.  The default option is the "AK TPDU" 
variant.  Use of Network Layer Receipt Confirmation is allowed only 
in Class 1, and depends on the availability of the network layer 
receipt confirmation service, the expected cost reduction, and the 
agreement 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 at 
which a transport entity issues a CR proposing the use of Class 1 or 
a CC accepting the use of Class 1  the following mechanisms must be 
available to deal with signalled errors during connection 
establishment:

        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 be
acknowledged.

7.1.5   Data Transfer Phase

        Data transfer is accomplished using the 'TPDU  
transfer' 'Concatenation' and 'DT TPDU Length and Segmenting' 
mechanisms.  'DT TPDU Numbering' and 'Retention until 
Acknowledgement of TPDUs' are used in support of error recovery.

7.1.5.1  Behaviour after an error

        After receiving a network reset, the Resynchronization
mechanism 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 to 
deal with receipt of a DR TPDU for an unrecognised Transport 

ToP   noToC   RFC0892 - Page 40
Connection.

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 an
identification 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 ED 
TPDU has been received, the next ED TPDU must have a different value 
in the EDTPDU-NR field.  No other significance is attached to 
EDTPDU-NR field.  It is recommended but not essential, that the 
values used be consecutive modulo 128.

        o  network expedited variant

           Note: (1) The use of this method is 
determined through negotiation during transport connection 
establishment.

7.1.6   Release Procedures

        The 'explicit' variant of the Release mechanism is used.

        Receipt of an error indication by a transport 
entity, which, prior to this event has sent a DR, causes this 
transport entity to retransmit DR.  Only DC and DR will be accepted 
and interpreted as the completion of the connection release 
sequence.  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 CLASS

7.2.1   Characteristics of Class 2

        The characteristic of this class is to provide a 

ToP   noToC   RFC0892 - Page 41
way to multiplex several transport connections onto a single network 
connection.  This class has been designed to be used in association 
with type A network connections.

        Use of Explicit Flow Control

        The objective is to provide flow control to help 
avoid congestion at end-points and on the network connection.  
Typical use is when traffic is heavy and continuous, or when there 
is intensive multiplexing.  Use of flow control can optimize 
response times and resource utilization.

        Non Use of Explicit Flow Control (optional)

        The objective is to provide a basic transport 
connection with minimal overheads suitable when independence of 
transport and network connection lifetime is desirable.  The class 
would typically be used for unsophisticated terminals, and when no  
multiplexing onto network connections is required.  Expedited data 
is never available.

7.2.2   Functions of Class 2

        Class 2 provides transport connections with or 
without individual flow control - no error detection or error 
recovery is provided.

        If the network resets or clears, the transport 
connection is terminated without the transport clearing sequence 
and the transport user is informed.

        When explicit flow control is used a credit 
mechanism is defined allowing the receiver to inform the sender of 
the exact amount of data he is willing to receive and expedited data 
transfer is available.

7.2.3   Protocol Mechanisms of Class 2

7.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 the 
connection request and confirm commands.

7.2.3.2  Connection Identification

        In Class 2 each TPDU conveys a Destination Reference.  

ToP   noToC   RFC0892 - Page 42
This uniquely identifies the transport connection within the 
receiving transport entity and thus allows multiplexing.

7.2.3.3  Release Phase

        The release of a transport connection results either 
from the use of the 'explicit' variant of the release function or  
from 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 entities 
for each direction of transmission in a transport connection is 
sequentially 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 sequence
number of the next expected TPDU.  This count is called the 
Receive Sequence Number, T(R). The receiver indicated to the sender
the 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) field
of the AK TPDU, is used by the receiver of the AK TPDU to determine
whether and how many Data TPDUs may be accepted by the sender of the
AK TPDU. Precise definition of flow control principles appears in Section 
7.2.5.5.3.

7.2.3.4.3  Expedited Flow

        The non network expedited variant is used.  Normal 
flow is the flow of data subject to the flow control mechanism, 
expedited flow is the flow of data that the sender may send without 
explicit agreement of the receiver.  This expedited flow has a 
limited capability and could for example be used to carry session 
supervisory commands.

        The number of expedited data units outstanding at any 
time is limited to one and the amount of TS-user data is limited (up 
to 16 octets).

        An expedited data may arrive before normal data which 
was submitted earlier.  Normal data submitted after the expedited 

ToP   noToC   RFC0892 - Page 43
data will arrive after the expedited data.

7.2.4   Connection Establishment Procedures for Class 2

7.2.4.1  References

        See Section 6.5 for reference assignment.  Receipt of 
any TPDU with a reference that is not assigned to a transport 
connection other than a Disconnect Request (DR) or Connection 
Request (CR) will be ignored.

        Receipt of a Disconnect Request (DR) for an unassigned
Reference will result in a Disconnect Confirm (DC) response.

7.2.4.2  Connection Eastablishment

        This phase is achieved by exchange of CR/CC TPDU using 
the 'connection establishment' function.  Since the multiplexing 
function is in use, then more than one transport connection may be 
assigned to the same network connection concurrently.  The 
restrictions of Class 0 does not apply to this class and the other 
higher classes.

7.2.5   Data Transfer Procedures for Class 2

        The data transfer procedures described in the 
following section apply independently to each transport connection 
existing between two transport entities.

7.2.5.1  TPDU Maximum Length and Segmenting

        The general rules defined in Section 6.3 apply.

7.2.5.2  Concatenation

        The general rules defined in Section 6.4 apply.

7.2.5.3  Sending Data TPDU (No Explicit Flow Control Option)

        In this case the data TPDU is built in accordance 
with the rules stated in Section 6.2 and 6.3 and sent without any 
additional mechanisms.  Thus, the DT TPDU NR field may take any 
value 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 Data 
TPDUs is controlled separately for each direction and is based on 
authorization from the receiver.


ToP   noToC   RFC0892 - Page 44
        This authorization is provided through the use of 
the TPDUs Credit field.  Credit field values are only present in 
the 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, is 
sequentially numbered.

        The sender of Data TPDUs holds a count of the next 
TPDU to be sent.  This count is called the Send Sequence Number
T(S).  The sender indicates to the receiver the number of the data 
TPDU he sends by putting the current T(S) value into the TPDU-NR 
field of the data TPDU.

        Sequence numbering is performed modulo 2**n, where n 
is 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 Transport 
entities initialize their T(S) and T(R) counts to zero (i.e. the 
first Data TPDU to be transmitted between transport entities for a 
given direction of data transmission after the connection 
establishment has a TPDU-NR field set to zero).

        Receipt of a Data TPDU whose TPDU-NR field is not 
equal to the expected value T(R), is to be regarded as a protocol 
error.

        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)


ToP   noToC   RFC0892 - Page 45
7.2.5.4.2  Window Definition

        For each transport connection and for each direction 
of data transmission a 'transmit window' is defined as the (possibly 
null) ordered set of consecutive data TPDUs authorized to be 
transmitted in that direction.  At any given time, the lowest 
sequence number of a data TPDU which a transport entity is 
authorized to transmit is referred to as the 'lowest window edge'.  
The 'upper window edge' is calculated  by adding the credit 
allocation, given by the value of the Credit (CDT) field contained 
in a received TPDU, to the lower window edge.  Note that a transport 
entity is authorized to send data TPDUs with sequence numbers up to 
but 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.

ToP   noToC   RFC0892 - Page 46
7.2.5.4.4  Reducing the Upper Window Edge

        The value of the upper window edge cannot be decreased 
in this class.  If, at a certain point of time, the upper window edge 
value is U, the reception of an AK TPDU having YR-TU-NR = M and CDT 
= N such that:

        (U-M) (mod. 2**n) > N

is a protocol error

        Provided the previous statements are respected, CDT 
field may take any value including zero.

7.2.5.4.5  Procedure for Expedited Data Transfer

        The procedure of expedited data transfer allows a 
transport entity to transmit data to the remote transport entity 
without following the flow control procedure of the normal data 
flow.  This procedure can only apply in the transfer phase.

        The expedited procedure has no effect on the transfer 
and flow control applying to normal Data TPDUs.

        To transmit expedited data, the transport entity sends 
an expedited data TPDU (ED TPDU).  The size of a data field is 
limited (up to 16 octets).  The data field contains a complete ED 
TSDU.  The remote transport will then confirm the receipt of the ED 
TPDU by transmitting an expedited TPDU acknowledgement (EA TPDU).  
A transport entity can send another ED TPDU only after having 
received an EA TPDU for the previously transmitted ED TPDU.  In 
class 2 the ED TPDU NR field of the ED and YR-TU-NR field of the EA 
TPDU 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 sent 
or received a Disconnect Request (DR).  The transport entity will 
ignore any incoming TPDU except DC or DR.

        If the network resets or clears the network 
connection, all transport connections are terminated without the 
transport clearing sequence.  The References become frozen.

        For Class 2 the explicit variant of the 'release' 
mechanism is used, enabling transport connections to be cleared 
independently of the underlying network connection.

7.2.7   Treatment of Invalid TPDUs


ToP   noToC   RFC0892 - Page 47
        The 'Treatment of Protocol Error' mechanism in Section 
6.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 CLASS

7.3.1   Characteristics of Class 3

        The characteristics of Class 3 in addition to those of 
Class 2 is to mask errors indicated by the network.  Selection of 
this class is usually based upon reliability criteria.  Class 3 has 
been 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 (with 
use of explicit flow control) plus the ability to recover after a 
failure signalled by the Network Layer without involving the user 
of the transport service.

        The mechanisms used to achieve this functionality also 
allow the implementation of more flexible flow control.

7.3.3   Protocol Mechanisms of Class 3

        Class 3 mechanisms include Class 2 (with use of 
explicit flow control option) mechanisms and the ability to recover 
after a failure signalled by the network without informing the user 
of the transport connection.

7.3.3.1  Error Recovery Principles

        The sending transport entity keeps a copy of 
transmitted Data TPDUs and ED TPDUs until it receives a positive 
aknowledgement which allows copies to be released.  It may also 
receive an RJ command inviting it to retransmit or transmit all Data 
TPDUs, if any, from the point in the sequence indicated in the  RJ 
command.

        This is especially the case, when a failure is 
indicated by the network.  The transport entity sends an RJ command 
in order to indicate the sequence number of the next expected TPDU.

ToP   noToC   RFC0892 - Page 48
        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 may
be equal to or greater than zero.  Thus it is possible to acknowledge
data 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 flow 
control) apply with the addition of the following rules which apply 
on 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 3

7.3.5.1  Acknowledgement

        The 'AK' variant of the Retention until 
Acknowledgement of TPDUs function is used.

7.3.5.2  Retransmission Procedure

        TPDU retransmission is a procedure which allows 
a transport entity to request retransmission of one or several 
consecutive Data TPDUs from the remote transport entity.  A 

ToP   noToC   RFC0892 - Page 49
transport reject condition is signalled to the remote transport 
entity by transmission of an RJ TPDU whose YR-TU-NR field indicates 
the sequence number of the next expected Data TPDU.

        On receipt of a RJ TPDU, a Transport entity shall 
accept credit to the value contained in the credit field and shall 
re-transmit TPDUs, starting with the one whose number is specified in 
the YR-TU-NR field of the received RJ TPDU, subject to the new 
credit.

        The transport entity shall not specify a T(R) in the 
RJ TPDU less than that which has previously been acknowledged.  
Receipt of an RJ TPDU with a T(R) which has been previously
acknowledged will be considered a protocol error.

        Additional DT TPDUs pending initial transmission may 
follow 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 upper 
window edge down to the sequence number transported by YR-TU-NR 
field of the RJ TPDU.  Receipt of an DT TPDU which would have been 
inside the window before the reduction is not a protocol error and 
this TPDU may be discarded.

        Note:  In such a case the credit equal to zero  
achieves 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 Network 
Service, the transport entity shall tranmit to the remove entity an 
RJ TPDU with YR-TU-NR field indicating the sequence number of the 
next expected Data TPDU.

7.3.5.5  Procedure for Expedited Data Transfer

        In Class 3, the ED TPDU-NR field of the Expedited 
Data (ED) TPDU contains an identification 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 ED TPDU has been received, the next 
ED TPDU must have a different value in the NR field of the ED 
TPDU.  No other significance is attached to this field.  It is 
recommended, however, that the values used be consecutive modulo 
2**n.  When a transport entity receives an ED TPDU for a transport 
connection, it shall respond by transmitting an expedited 
acknowledgement (EA) TPDU.

        It places in the YR-TU-NR field the value contained in 

ToP   noToC   RFC0892 - Page 50
the NR field of the received ED TPDU.  If, and only if, this value 
is 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 is 
received before the receipt of the expected Expedited Acknowledgement 
(EA) TPDU, the transport entity shall retransmit the ED TPDU with 
the same value in the NR field.  By the rule described in the 
previous paragraph, the session entity does not receive data 
corresponding 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 the  
following rule:

        Receipt of an eror indication by a transport entity, 
which prior to this event has sent a DR, causes this transport 
entity to retransmit DR.  Only DC and DR will be accepted and 
interpreted 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 CLASS

7.4.1   Characteristics of Class 4

        The characteristic of Class 4, in addition to those of 
Class 3, is the detection of errors which occur as a result of the 
low grade of service available from the network layer.  The kinds of 
errors to be detected include:  TPDU loss, TPDU delivery out of 
sequence, TPDU duplication.  These errors may afect control TPDUs as 
well as Data TPDUs.

        Class 4 has been designed to be usd in association 
with network connections of type C.

7.4.2   Functions of Class 4

        This class provides the functionality of Class 3, plus 
the ability to detect and recover from lost, duplicated or out of 
sequence TPDUs without involving the user of the transport service.


ToP   noToC   RFC0892 - Page 51
        This detection of errors is made by extended use of 
the sequence numbering of Classes 2 and 3, by a timeout mechanism, 
and by additional protocol mechanisms.

        This class additionally detects and recovers from 
damaged TPDUs by using a checksum mechamism.  The use of the 
checksum mechanism must be available but its use or its non use is 
subject to negotiation.  Class 4 does not attempt to deal with 
detection of errors due to the misdelivery of TPDUs.

7.4.3   Protocol Mechanisms of Class 4

7.4.3.1  Network Service Data Unit Lifetime

        The network layer is assumed to provide, as an aspect 
of its grade of service, for a bound on the maximum lifetime of 
NSDUs in the network.  This value is known by the Transport Layer.  
The maximum time which may elapse between the transmission of an 
NSDU into the network layer and the receipt of any copy of it is 
referred to as M.

7.4.3.2  Average Transit Delay

        It is assumed that there is some value of transmit 
delay in the network, typically much less than M, which will be the 
maximum delay suffered by all but a small proportion of NSDUs.  This  
value is referred to as E.

7.4.3.3  Remote Acknowledge Time Assumptions

        Any transport entity is assumed to provide a bound for the 
maximum time which can elapse between its receipt of a TPDU from
the Network Layer and its transmisssion of the Corresponding response.
this value is referred to as A/L.  The corresponding time given by the 
remote transport entity is referred to as A/R.  The values for these
timers may be conventionally established or may be established
at connection establishment time.  

7.4.3.4  Local Retransmission Time

        The local transport entity is assumed to maintain a 
bound on the time it will wait for an acknowledgement before 
retransmitting the TPDU.  This time is the local retransmission time 
and is referred to as T1.

                  T1 = 2*E +  X  + Ar?

             Where X is a value to allow for TPDU processing in the 
local transport entity.


ToP   noToC   RFC0892 - Page 52
7.4.3.5  Persistence Time

        The local transport entity is assumed to provide a 
bound for the maximum time for which it may continue to retransmit 
a TPDU requiring positive acknowledgment.  This value is referred to 
as R.

        The value is clearly related to the time elapsed 
between retransmission, T1, and the maximum number of 
retransmissions, N.  It is not less than T1*N+X, where X is small 
quantity to allow for additional internal delays, the granularity of 
the 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 and 
the 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 established 
for the maximum time between the decision to transmit a TPDU and the 
receipt 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 reusing 
any reference or sequence number, to avoid confusion in case a TPDU 
referring to it may be duplicated or delayed.

        (Note:  In practive, the value of L may be 
unacceptably large.  It may also be only a statistical figure at a 
certain confidence level.  A smaller value may therefore be used 
where this still allows the required quality of service to be 
provided).

7.4.3.7  Inactivity Time

        To protect against unsignalled breaks in the network 
connection (Half-open connections), each transport entity maintains 
an inactivity time interval.   If the interval passes without 
receipt of some TPDU, the transport entity will terminate the TC by 
making use of the release procedure.  This interval is referred to 
as I.

7.4.3.8  Window Time

        A transport entity maintains a time to ensure that 
there is a maximum interval between transmission of up-to-date 
window information.  This interval is referred to as the window 
time, W.

7.4.3.9  Class 4 Error Recovery Principles



(next page on part 3)

Next Section