tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 0905

 
 
 

ISO Transport Protocol specification ISO DP 8073

Part 3 of 5, p. 70 to 99
Prev RFC Part       Next RFC Part

 


prevText      Top       Page 70 
     6.14  Resynchronization

     6.14.1  Purpose

     The resynchronization procedures are used in Classes 1 and  3  to
     restore  the  transport  connection  to  normal  after a reset or
     during reassignment after failure according to 6.12.




     6.14.2  Network service primitives

     The  procedure  makes  use  of  the  following  network   service
     primitive:

          N-RESET indication.




     6.14.3  TPDUs and parameters used

     The procedure uses the following TPDUs and parameters:

        a)  CR, DR, CC and DC TPDUs

        b)  RJ TPDUs;

            - YR-TU-NR.

        c)  DT TPDU;

            - TPDU-NR

        d)  ED TPDU;

            - ED TPDU-NR.

        e)  EA TPDU;

            - YR-EDTU-NR.

Top       Page 71 
     6.14.4  Procedure

     A transport entity which is notified of the occurence  of  an  N-
     RESET   or  which  is  performing  'reassignment  after  failure'
     according to 6.12 shall carry out  the  active  resynchronization
     procedure (see 6.14.4.1) unless any of the following hold:

        a)  the transport entity is the responder (see note).  In this
            case  the  passive  resynchronization procedure is carried
            out (see 6.14.4.2).

        b)  the transport entity has  elected  not  to  reassign  (see
            6.12.3.c).  In this case no resynchronization takes place.




     6.14.4.1  Active resynchronization procedures

     The Transport  entity  shall  carry  out  one  of  the  following
     actions:

        a)  if the TTR timer has been previously started and  has  run
            out  (i.e. no valid TPDU has been received), the transport
            connection is considered as released and the reference  is
            frozen (see 6.18).

        b)  otherwise, the TTR timer shall be started  (unless  it  is
            already running) and the first applicable of the following
            actions shall be taken:

            1)  if a CR TPDU is  unacknowledged,  then  the  transport
                entity shall retransmit it;

            2)  if a DR TPDU is  unacknowledged,  then  the  transport
                entity shall retransmit it;

            3)  otherwise, the transport entity shall  carry  out  the
                data resynchronization procedures (6.14.4.3).

            The TTR timer is stopped when a valid TPDU is received.

Top       Page 72 
     6.14.4.2  Passive resynchronization procedures

     The transport entity shall not send any TPDUs until  a  TPDU  has
     been received.  The transport entity shall start its TWR timer if
     it was not already started (due to a previous N-DISCONNECT or  N-
     RESET indication).  If the timer runs out prior to the receipt of
     a valid TPDU which commence resynchronization (i.e. CR or  DR  or
     RJ  TPDU)  the transport connection is considered as released and
     the reference is released (see 6.18).

     When a valid TPDU is received the transport entity shall stop its
     TWR  timer  and  carry  out  the appropriate one of the following
     actions, depending on the TPDU:

        a)  if it is a DR TPDU, then the transport entity shall send a
            DC TPDU;

        b)  if it is  a  repeated  CR  TPDU  (see  note  1)  then  the
            transport  entity  shall  carry out the appropriate action
            from the following:

            1)  if a CC TPDU has already been sent, and  acknowledged:
                treat as a protocol error;

            2)  if a DR TPDU is unacknowledged (whether or  not  a  CC
                TPDU  is  unacknowledged): retransmit the DR TPDU, but
                setting the source reference to zero;

            3)  if the T-CONNECT response has not  yet  been  received
                from the user:  take no action;

            4)  otherwise; retransmit  the  CC  TPDU  followed  by  an
                unacknowledged ED TPDU (see note 2) and any DT TPDU;

         NOTES

            1.  A repeated CR TPDU can be identified  by  being  on  a
                network   connection   with  the  appropriate  network
                addresses and having a correct source reference.

Top       Page 73 
            2.  The transport entity should not use network  expedited
                until  the  CC  TPDU  is acknowledged (see 6.5).  This
                rule prevents the network  expedited  from  overtaking
                the CC TPDU.

        c)  if it is an RJ or  ED  TPDU  then  one  of  the  following
            actions shall be taken:

            1)  if a DR TPDU is  unacknowledged,  then  the  transport
                entity shall retransmit it;

            2)  otherwise, the transport entity shall  carry  out  the
                data resynchronization procedures (6.14.4.3).

            3)  If a CC TPDU was unacknowledge,  the  RJ  or  ED  TPDU
                should  then  be  considered  as  acknowledging the CC
                TPDU.  If a CC TPDU was never sent, the RJ TPDU should
                then be considered as a protocol error.




     6.14.4.3  Data Resynchronization Procedures

     The transport entity shall carry out the following actions in the
     following order:

        a)  (re)transmit any ED TPDU which is unacknowledged,

        b)  transmit an RJ TPDU with YR-TU-NR field set to the TPDU-NR
            of the next expected DT TPDU;

Top       Page 74 
        c)  wait for the next TPDU from the  other  transport  entity,
            unless an RJ or DR TPDU has already been received; if a DR
            TPDU is received the transport entity  shall  send  a  DC,
            freeze   the   reference,   inform   the  TS-user  of  the
            disconnection and take no further action  (i.e.  it  shall
            not  follow  the procedures in 6.14.4.3.d).  If an RJ TPDU
            is  received,  the  procedure  of  6.14.4.3.d   shall   be
            followed.   If  an  ED  TPDU is received the procedures as
            described  in  6.11  shall  be  followed.   If  it  is   a
            duplicated  ED-TPDU the transport entity shall acknowledge
            it, with an EA TPDU, discard the duplicated  ED  TPDU  and
            wait again for the next TPDU.

        d)  (re)transmit  any  DT  TPDUs  which  are   unacknowledged,
            subject  to  any  applicable  flow control procedures (see
            note);

            NOTE - The RJ TPDU may have reduced the credit.




     6.15  Multiplexing and demultiplexing

     6.15.1  Purpose

     The  multiplexing  and  demultiplexing  procedures  are  used  in
     Classes  2,  3  and  4  to allow several transport connections to
     share a network connection at the same time.




     6.15.2  TPDUs and parameters used

     The procedure makes use of the following TPDUs and parameters:

        CC, DR, DC, DT, AK, ED, EA, RJ and ER TPDUs

        - DST-REF

Top       Page 75 
     6.15.3  Procedure

     The transport entities shall be able to send and receive  on  the
     same  network  connection  TPDUs belonging to different transport
     connections.

     NOTES

        1.  When performing demultiplexing the transport connection to
            which  the  TPDUs  apply  is  determined by the procedures
            defined in 6.9.

        2.  Multiplexing allows the concatenation of  TPDUs  belonging
            to  different  transport  connections to be transferred in
            the same N-DATA primitive (see 6.4).




     6.16  Explicit Flow Control

     6.16.1  Purpose

     The explicit flow control procedure is used in Classes 2, 3 and 4
     to  regulate  the  flow  of  DT  TPDUs  independently of the flow
     control in the other layers.




     6.16.2  TPDUs and parameters used

     The procedure makes use of the following TPDUs and parameters:

        a)  CR, CC, AK and RJ TPDUs

            - CDT.

        b)  DT TPDU

            - TPDU-NR.

Top       Page 76 
        c)  AK TPDU

            - YR-TU-NR;
            - subsequence number;
            - flow control confirmation.

        d)  RJ TPDU

            - YR-TU-NR.




     6.16.3  Procedure

     The procedures differ in different classes.  They are defined  in
     the clauses specifying the separate classes.




     6.17  Checksum

     6.17.1  Purpose

     The checksum procedure is used to detect corruption of  TPDUs  by
     the NS-provider.

     NOTE - Although a checksum algorithm has to  be  adapted  to  the
     type  of  errors  expected  on the network connection, at present
     only one algorithm is defined.




     6.17.2  TPDUs and parameters used

     The procedure uses the following TPDUs and parameters:

        All TPDUs
         - checksum

Top       Page 77 
     6.17.3  Procedure

     The checksum is used only in Class 4.  It is always used for  the
     CR TPDU, and is used for all other TPDUs except if the non-use of
     the procedure was agreed during connection establishment.

     The sending  transport  entity  shall  transmit  TPDUs  with  the
     checksum  parameter  set  such  that  the  following formulas are
     satisfied:

        SUM(from i=1 to i=L) OF a[i] EQUALS <zero> (module 255)

        SUM(from i=1 to i=L) OF i*a[i] EQUALS <zero> (module 255)

     where

        i    = number (i.e. position) of an octet within the TPDU
               (see 13.2);
        a[i] = value of octet in position 1;
        L    = length of TPDU in octets.

     A  transport  entity  which  receives  a  TPDU  for  a  transport
     connection  for  which  the  use  of checksum has been agreed and
     which does not satisfy the above formulas shall discard the  TPDU
     (see also note 2).

     NOTES

        1.  An  efficient  algorithm  for  determining  the   checksum
            parameters is given in annex B.

        2.  If the checksum is incorrect, it is not possible  to  know
            with  certainty  to which transport connection the TPDU is
            related; further action may be taken for all the transport
            connections assigned to the network connection (see 6.9).

        3.  The checksum proposed is easy to calculate and so will not
            impose  a  heavy  burden  on implementations.  However, it
            will not detect insertion or loss of leading  or  trailing
            zeros and will not detect some octets misordering.

Top       Page 78 
     6.18  Frozen references

     6.18.1  Purpose

     This procedure is used in order to prevent re-use of a  reference
     while  TPDUs  associated  with  the  old use of the reference may
     still exist.




     6.18.2  Procedure

     When a transport entity determines that a  particular  connection
     is  released  it shall place the reference which it has allocated
     to the connection in a frozen state according to  the  procedures
     of the class.  While frozen, the reference shall not be re-used.

     NOTE - The  frozen  reference  procedure  is  necessary   because
     retransmission or misordering can cause TPDUs bearing a reference
     to arrive at an entity after it has released the  connection  for
     which  it  allocated the reference.  Retransmission, for example,
     can arise when the class includes either  resynchronization  (see
     6.14) or retransmission on time out (see 6.19).




     6.18.2.1  Procedure for classes 0 and 2

     The frozen reference procedure is never used for these classes.

     NOTE - However for consistency with the  other  classes  freezing
     the references may be done as a local decision.

Top       Page 79 
     6.18.2.2  Procedure for classes 1 and 3

     The frozen reference procedure is used except  in  the  following
     cases (see note 1):

        a)  when the transport entity receives a DC TPDU  in  response
            to a DR TPDU which it has sent (see note 2);

        b)  when the transport  entity  sends  a  DR  or  ER  TPDU  in
            response to a CR TPDU which it has received (see note 3);

        c)  when the transport entity has considered the connection to
            be  released  after  the  expiration of the TWR timer (see
            note 4);

        d)  when the transport entity receives a  DR  or  ER  TPDU  in
            response to a CR TPDU which it has sent.

     The period of time for which the reference remains  frozen  shall
     be greater than the TWR time.

     NOTES

        1.  However, even in these cases, for consistency freezing the
            reference may be done as a local decision.

        2.  When the DC TPDU is received it is certain that the  other
            transport entity considers the connection released.

        3.  When the DR or ER TPDU is sent the peer  transport  entity
            has not been informed of any reference assignment and thus
            cannot possibly make use of a reference (this includes the
            case where a CC TPDU was sent, but was lost).

        4.  In 6.18.2.c the transport entity has  already  effectively
            frozen the reference for an adequate period.

Top       Page 80 
     6.18.2.3  Procedure for classes 4

     The frozen reference procedure is always used in  class  4.   The
     period  for  which the reference remains frozen should be greater
     than L (see 12.2.1.1.6).




     6.19  Retransmission on time-out

     6.19.1  Purpose

     The procedure is used in Class 4 to cope with unsignalled loss of
     TPDUs by the NS-provider.




     6.19.2  TPDUs used

     The procedure makes use of the following TPDUs:

        CR, CC, DR, DT, ED, AK TPDUs.




     6.19.3  Procedure

     The procedure is specified in the procedures  for  Class  4  (see
     12.2.1.2.j).




     6.20  Resequencing

Top       Page 81 
     6.20.1  Purpose

     The resequencing procedure is  used  in  Class  4  to  cope  with
     misordering of TPDUs by the network service provider.




     6.20.2  TPDUs and parameters used

     The procedure uses the following TPDUs and parameters:

        a)  DT TPDU;
            - TPDU-NR.

        b)  ED TPDU
            - ED TPDU-NR




     6.20.3  Procedure

     The procedure is specified in the procedures  for  Class  4  (see
     12.2.3.5).




     6.21  Inactivity control

     6.21.1  Purpose

     The inactivity control procedure is used in Class 4 to cope  with
     unsignalled termination of a network connection.

Top       Page 82 
     6.21.2  Procedure

     The procedure is specified in the procedures  for  Class  4  (see
     12.2.3.3).




     6.22  Treatment of protocol errors

     6.22.1  Purpose

     The procedure for treatment of protocol errors  is  used  in  all
     classes to deal with invalid TPDUs.




     6.22.2  TPDUs and parameters used

     The procedure uses the following TPDUs and parameters:

        a)  ER TPDU;
            - reject cause;
            - TPDU in error.

        b)  DR TPDU;
            - reason code.




     6.22.3  Procedure

     A transport entity that receives a TPDU that can be associated to
     a  transport  connection and is invalid or constitutes a protocol
     error (see 3.2.16 and 3.2.17) shall take  one  of  the  following
     actions  so  as not to jeopardize any other transport connections
     not assigned to that network connection:

        a)  ignoring the TPDU;

        b)  transmitting an ER TPDU;

Top       Page 83 
        c)  resetting or closing the network connection; or

        d)  invoking the release procedures appropriate to the class.

     If an ER TPDU is sent in Class 0 it shall contain the  octets  of
     the  invalid  TPDU  up to and including the octet where the error
     was detected (see notes 3, 4 and 5).

     If the TPDU  cannot  be  associated  to  a  particular  transport
     connection then see 6.9.

     NOTES

        1.  In  general,  no  further  action  is  specified  for  the
            receiver  of  the  ER  TPDU  but it is recommended that it
            initiates the release procedure appropriate to the  class.
            If the ER TPDU has been received as an answer to a CR TPDU
            then the connection is regarded as released (see 6.6).

        2.  Care should be  taken  by  a  transport  entity  receiving
            several  invalid TPDUs or ER TPDUs to avoid looping if the
            error is generated repeatedly.

        3.  If the invalid received TPDU is greater than the  selected
            maximum  TPDU  size  it  is  possible  that  it  cannot be
            included in the invalid TPDU parameter of the ER TPDU.

        4.  It is recommended that the sender of the ER TPDU starts an
            optional   timer   TS2   to  ensure  the  release  of  the
            connection.  If the timer expires,  the  transport  entity
            shall  initiate  the release procedures appropriate to the
            class.  The timer should be stopped when a DR TPDU  or  an
            N-DISCONNECT indication is received.

        5.  In classes other  than  0,  it  is  recommended  that  the
            invalid TPDU be also included in the ER TPDU.

Top       Page 84 
     6.23  Splitting and recombining

     6.23.1  Purpose

     This procedure is used only in  class  4  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.




     6.23.2  Procedure

     When this procedure is being used, a transport connection may  be
     assigned  (see 6.1) to multiple network connections (see note 1).
     TPDUs for the connection  may  be  sent  over  any  such  network
     connection.

     If the use of Class 4 is not accepted  by  the  remote  transport
     entity   following   the   negotiation  rules,  then  no  network
     connection except that over which the CR TPDU was sent  may  have
     this transport connection assigned to it.

     NOTES

        1.  The resequencing function of Class 4 (see 6.20) is used to
            ensure that TPDUs are processed in the correct sequence.

        2.  Either transport  entity  may  assign  the  connection  to
            further  network  connections  of which it is the owner at
            any time during the life of the transport connection.

Top       Page 85 
        3.  In order to enable the detection  of  unsignalled  network
            connection   failures,   a   transport  entity  performing
            splitting should ensure that TPDUs are sent  at  intervals
            on  each  supporting  network  connection, for example, by
            sending   successive   TPDUs   on    successive    network
            connections,  where the set of network connections is used
            cyclically.  By  monitoring  each  network  connection,  a
            transport entity may detect unsignalled network connection
            failures, following the inactivity procedures  defined  in
            12.2.3.3.   Thus,  for each network connection no period I
            (see 12.2.3.1) may elapse without the receipt of some TPDU
            for some transport connection.

Top       Page 86 
     7  Protocol Classes

     Table 6 gives an overview of  which  elements  of  procedure  are
     included  in  each  class.   In  certain  cases  the  elements of
     procedure within different classes are  not  identical  and,  for
     this  reason,  table  6  cannot  be  considered  as  part  of the
     definitive specification of the protocol.



     KEY TO TABLE 6

     +---|---------------------------------------------------------+
     | * |Procedure always included in class                       |
     |---|---------------------------------------------------------|
     |   |Not applicable                                           |
     |---|---------------------------------------------------------|
     | m |Negotiable procedure whose implementation in equipment is|
     |   |mandatory                                                |
     |---|---------------------------------------------------------|
     | o |Negotiable procedure whose implementation in equipment is|
     |   |optional                                                 |
     |---|---------------------------------------------------------|
     | ao|Negotiable procedure whose implementation in equipment is|
     |   |optional and where use depends on availability within the|
     |   |network service                                          |
     |---|---------------------------------------------------------|
     |(1)|Not applicable in class 2 when non-use of explicit flow  |
     |   |control is selected                                      |
     |---|---------------------------------------------------------|
     |(2)|When non use of explicit flow control has been selected, |
     |   |multiplexing may lead to degradation of quality of       |
     |   |service                                                  |
     |---|---------------------------------------------------------|
     |(3)|This function is provided in class 4 using procedures    |
     |   |other than those in the cross reference.                 |
     +-------------------------------------------------------------+

Top       Page 87 
     +----------------------------------------------------------------+
     |                             |Cross |            |  |  |  |  |  |
     |     Protocol Mechanism      |refe- |   Variant  | 0| 1| 2| 3| 4|
     |                             |rence |            |  |  |  |  |  |
     |-----------------------------|------|------------|--|--|--|--|--|
     | Assignment to network Conn. | 6.1  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | TPDU Transfer               | 6.2  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Segmenting and Reassembling | 6.3  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Concatenation and Separation| 6.4  |            |  | *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Connection Establishment    | 6.5  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Connection Refusal          | 6.6  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Normal Release              | 6.7  | implicit   | *|  |  |  |  |
     |                             |      | explicit   |  | *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Error Release               | 6.8  |            | *|  | *|  |  |
     |-----------------------------|------|------------|--|--|--|--|--|
     | Association of TPDUs with   |      |            |  |  |  |  |  |
     | Transport Connection        | 6.9  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | DT TPDU Numbering           | 6.10 | normal     |  | *|m(1)m| m|
     |                             |      | extended   |  |  |o(1)o| o|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Expedited Data Transfer     | 6.11 | network    |  |  | *|  |  |
     |                             |      | normal     |  | m|(1) *| *|
     |                             |      | network    |  |  |  |  |  |
     |                             |      | expedited  |  |ao|  |  |  |
     |-----------------------------|------|------------|--|--|--|--|--|
     | Reassignment after failure  | 6.12 |            |  | *|  | *|(3)
     +----------------------------------------------------------------+

    Table 6. (First of 2 pages) Allocation of procedures within classes

Top       Page 88 
     +----------------------------------------------------------------+
     | Retention until Acknowledge-|      |Conf.Receipt|  |ao|  |  |  |
     | ment of TPDUs               | 6.13 |AK          |  | m|  |  | *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Resynchronisation           | 6.14 |            |  | *|  | *|(3)
     |-----------------------------|------|------------|--|--|--|--|--|
     | Multiplexing and            |      |            |  |  |(2)  |  |
     | Demultiplexing              | 6.15 |            |  |  | *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Explicit Flow Control With  | 6.16 |            |  |  | m| *| *|
     |                    Without  |      |            | *| *| o|  |  |
     |-----------------------------|------|------------|--|--|--|--|--|
     | Checksum (use of)           | 6.17 |            |  |  |  |  | m|
     |          (non-use of)       |      |            | *| *| *| *| o|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Frozen References           | 6.18 |            |  | *|  | *| *|
     |------------------------------------|------------|--|--|--|--|--|
     | Retransmission on Timeout   | 6.19 |            |  |  |  |  | *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Resequencing                | 6.20 |            |  |  |  |  | *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Inactivity Control          | 6.21 |            |  |  |  |  | *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Treatment of Protocol Errors| 6.22 |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Splitting and Recombining   | 6.23 |            |  |  |  |  | *|
     +----------------------------------------------------------------+

     Table 6. (2nd of 2 pages) Allocation of procedures within classes

Top       Page 89 
     8  SPECIFICATION FOR CLASS 0. SIMPLE CLASS

     8.1  Functions of class 0

     Class 0 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.




     8.2  Procedures for class 0

     8.2.1  Procedures applicable at all times

     The transport entities shall use the following procedures:

        a)  TPDU transfer (see 6.2);

        b)  association of TPDUs with transport connections (see 6.9);

        c)  treatment of protocol errors (see 6.22);

        d)  error release (see 6.8).




     8.2.2  Connection establishment

     The transport entities shall use the following procedures:

        a)  assignment to network connection (see 6.1); then

        b)  connection establishment (see 6.5)  and,  if  appropriate,
            connection refusal (see 6.6);

        subject to the following constraints:

Top       Page 90 
        c)  the CR and CC TPDUs shall contain no parameter field other
            than those for TSAP-ID and maximum TPDU size;

        d)  the CR and CC TPDUs shall not contain a data field.




     8.2.3  Data transfer

     The transport entities shall use the segmenting and  reassembling
     procedure (see 6.3).




     8.2.4  Release

     The transport entities shall use  the  implicit  variant  of  the
     normal release procedure (see 6.7).

     NOTE - the lifetime  of  the  transport  connection  is  directly
     correlated with the lifetime of the network connection.

Top       Page 91 
     9  SPECIFICATION FOR CLASS 1: BASIC ERROR RECOVERY CLASS

     9.1  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 TS-user.




     9.2  Procedures for Class 1

     9.2.1  Procedures applicable at all times

     The transport entities shall use the following procedures:

        a)  TPDU transfer (see 6.2);

        b)  association of TPDU with transport connections (see 6.9);

        c)  treatment of protocol errors (see 6.22);

        d)  reassignment after failure (see 6.12);

        e)  resynchronization  (see  6.14),  or   reassignment   after
            failure  (see  6.12)  together with resynchronization (see
            6.14);

        f)  concatenation and separation (see 6.4);

        g)  retention until acknowledgement of TPDU  (see  6.13);  the
            variant  used,  AK or confirmation of receipt, shall be as
            selected during connection establishment (see notes);

        h)  frozen references (see 6.18).

Top       Page 92 
     NOTES

        1.  The  negotiation  of  the  variant  of   retention   until
            acknowledgement  of  TPDUs  procedure  to be used over the
            transport connection has been designed such  that  if  the
            initiator  proposes  the  use  of the AK variant (i.e. the
            mandatory implementation option),  the  responder  has  to
            accept  use  of  this option and if the initiator proposes
            use of the confirmation of receipt variant  the  responder
            is entitled to select use of the AK variant.

        2.  The AK variant makes use of AK TPDUs to release copies  of
            retained DT TPDUs.  The CDT parameter of AK TPDUs in class
            1 is not significant, and is set to 1111.

        3.  The confirmation of receipt variant is restricted to  this
            class  and  its  use  depends  on  the availability of the
            network  layer  receipt  confirmation  service,  and   the
            expected cost reduction.




     9.2.2  Connection establishment

     The transport entities shall use the following procedures:

        a)  assignment to network connection (see 6.1); then

        b)  connection establishment (see 6.5)  and,  if  appropriate,
            connection refusal (see 6.6).




     9.2.3  Data Transfer

     9.2.3.1  General

     The sending transport entity shall use the following procedures;

        a)  segmenting (see 6.3); then

Top       Page 93 
        b)  the normal format variant of DT TPDU numbering (see 6.10).

        The  receiving  transport  entity  shall  use  the   following
        procedures;

        c)  the normal variant of DT TPDU numbering (see 6.10,; then

        d)  reassembling (see 6.3).

     NOTES

        1.  The use of RJ TPDU during resynchronization (see 6.14) can
            lead  to  retransmission.  Thus the receipt of a duplicate
            DT TPDU is possible; such a DT TPDU is discarded.

        2.  It is possible to decide on a local basis to issue  an  N-
            RESET request in order to force the remote entity to carry
            out the resynchronization (see 6.14).




     9.2.3.2  Expedited Data

     The transport entities shall use either the network  normal  data
     or  the network expedited variants of the expedited data transfer
     procedure (see 6.11)  if  their  use  has  been  selected  during
     connection establishment (see note 1).

     The sending transport entity shall  not  allocate  the  same  ED-
     TPDU-NR to successive ED TPDUs (see notes 2 and 3).

     When acknowledging  an  ED  TPDU  by  sending  and  EA  TPDU  the
     transport  entity  shall put into the YR-EDTU-NR parameter of the
     EA TPDU the value received in the ED-TPDU-NR parameter of the  ED
     TPDU.

     NOTES

        1.  The negotiation of the variant of expedited data  transfer
            procedure  to  be  used  over the transport connection has
            been designed such that if the initiator proposes the  use
            of  the  network  normal  data variant (i.e. the mandatory

Top       Page 94 
            implementation option), the responder has to accept use of
            this  option  and  if  the  initiator  proposes use of the
            network expedited variant, the responder  is  entitled  to
            select use of the network normal data variant.

        2.  This numbering enables the receiving transport  entity  to
            discard  repeated  ED  TPDUs  when  resynchronization (see
            6.14) has taken place.

        3.  No other  significance  is  attached  to  the  ED  TPDU-NR
            parameter.  It is recommended, but not essential, that the
            values used be consecutive modulo 128.




     9.2.4  Release

     The transport entities shall use  the  explicit  variant  of  the
     release procedure (see 6.7).

Top       Page 95 
     10  SPECIFICATION FOR CLASS 2 - MULTIPLEXING CLASS

     10.1  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 connection resets or  disconnects,  the  transport
     connection  is terminated without the transport release procedure
     and the TS-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.




     10.2  Procedures for class 2

     10.2.1  Procedures applicable at all times

     The transport entities shall use the following procedures

        a)  association of TPDUs with transport connection (see 6.9);

        b)  TPDU transfer (see 6.2);

        c)  treatment of protocol errors (see 6.22);

        d)  concatenation and separation (see 6.4);

        e)  error release (see 6.8).

        Additionally the transport  entities  may  use  the  following
        procedure:

        f)  multiplexing and demultiplexing (see 6.15).

Top       Page 96 
     10.2.2  Connection establishment

     The transport entities shall use the following procedures:

        a)  assignment to network connection (see 6.1); then

        b)  connection establishment  (see  6.5)  and,  if  applicable
            connection refusal (see 6.6).




     10.2.3  Data transfer when non use of explicit flow control

             has been selected

     If this option has been selected as a result  of  the  connection
     establishment,  the  transport  entities shall use the segmenting
     procedure (see 6.3).

     The TPDU-NR field of DT TPDUs is not significant and may take any
     value.

     NOTE- -Expedited data transfer is not applicable (see 6.5).




     10.2.4  Data transfer when use of explicit flow control

             has been selected



     10.2.4.1  General

     The sending transport entity shall use the following procedures:

        a)  segmenting (see 6.3); then

        b)  DT TPDU numbering (see 6.10);

Top       Page 97 
        The  receiving  transport  entity  shall  use  the   following
        procedures:

        c)  DT TPDU numbering (see 6.10); if a  DT  TPDU  is  received
            which is out of sequence it shall be treated as a protocol
            error; then

        d)  reassembling (see 6.3).

        The variant of the DT TPDU numbering which  is  used  by  both
        transport   entities   shall  be  that  which  was  agreed  at
        connection establishment.




     10.2.4.2  Flow control

     The transport entities shall send an initial credit (which may be
     zero)  in  the  CDT  field  of  the  CR  or CC TPDU.  This credit
     represents the initial value of the upper window  edge  allocated
     to the peer entity.

     The transport entity that receives the CR or the  CC  TPDU  shall
     consider its lower window edge as zero, and its upper window edge
     as the value of the CDT field in the received TPDU.

     In order to authorize the transmission of DT TPDUs, by its  peer,
     a  transport  entity may transmit an AK TPDU at any time, subject
     to the following constraints:

        a)  the YR-TU-NR parameter shall be at most one  greater  than
            the TPDU-NR field of the last received DT TPDU or shall be
            zero if no DT TPDU has been received;

        b)  if an AK TPDU has previously been sent the  value  of  the
            YR-TU-NR  parameter  shall  not  be lower than that in the
            previously sent AK TPDU.

        c)  the sum of the YR-TU-NR and CDT fields shall not  be  less
            than  the upper window edge allocated to the remote entity
            (see note 1).

Top       Page 98 
     A transport entity which receives an AK TPDU shall  consider  the
     YR-TU-NR  field  as its new lower window edge, and the sum of YR-
     TU-NR and CDT as its new upper window edge.  If either  of  these
     have  been  reduced  or  if the lower window edge has become more
     than one greater than the TPDU-NR  of  the  last  transmitted  DT
     TPDU, this shall be treated as a protocol error (see 6.22).

     A transport entity shall not  send  a  DT  TPDU  with  a  TPDU-NR
     outside of the transmit window (see notes 2 and 3).

     NOTES

        1.  This means that credit reduction is not applicable.

        2.  This means that a transport entity  is  required  to  stop
            sending  if  the  TPDU-NR  field of the next DT TPDU which
            would be sent would be the upper window edge.  Sending  of
            DT  TPDU  may  be  resumed if an AK TPDU is received which
            increases the upper window edge.

        3.  The rate at which a transport entity progresses the  upper
            window  edge  allocated  to its peer entity constrains the
            throughput attainable on the transport connection.




     10.2.4.3  Expedited data

     The transport entities shall follow the network normal variant of
     the expedited data transfer procedure in 6.11 if its use has been
     agreed  during  connection  establishment.   ED  and   EA   TPDUs
     respectively  are  not  subject to the flow control procedures in
     10.2.4.2.  The ED-TPDU-NR and YR-ETDU-NR  fields  of  ED  and  EA
     TPDUs respectively are not significant and may take any value.

Top       Page 99 
     10.2.5  Release

     The transport entities shall use  the  explicit  variant  of  the
     release procedure in 6.7.


Next RFC Part