tech-invite   World Map     

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

RFC 0905

 
 
 

ISO Transport Protocol specification ISO DP 8073

Part 4 of 5, p. 100 to 129
Prev RFC Part       Next RFC Part

 


prevText      Top       Page 100 
     11  SPECIFICATION FOR CLASS 3: ERROR  RECOVERY  AND  MULTIPLEXING
     CLASS

     11.1  Functions of Class 3

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




     11.2  Procedures for Class 3

     11.2.1  Procedures applicable at all times

     The transport entities shall use the following procedures:

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

        b)  TPDU   transfer   (see   6.2)    and    retention    until
            acknowledgement of TPDUs (AK variant only) (see 6.13);

        c)  treatment of protocol errors (see 6.22);

        d)  concatenation and separation (see 6.4);

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

        f)  frozen references (see 6.18).

     Additionally,  the  transport  entities  may  use  the  following
     procedure:

        g)  multiplexing and demultiplexing (see 6.15);

Top       Page 101 
     11.2.2  Connection Establishment

     The transport entities shall use the following procedures;

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

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




     11.2.3  Data Transfer

     11.2.3.1  General

     The sending transport entity shall use the following procedures:

        a)  segmenting (see 6.3), then

        b)  DT TPDU numbering (see 6.10); after receipt of an RJ  TPDU
            (see  11.2.3.2)  the  next  DT  TPDU to be sent may have a
            value which is not the previous value of TPDU-NR plus one.

     The  receiving  transport  entity   shall   use   the   following
     procedures:

        c)  DT TPDU numbering (see 6.10); the TPDU-NR  field  of  each
            received  DT  TPDU shall be treated as a protocol error if
            it exceeds the greatest such value received in a  previous
            DT TPDU by more than one (see note); then

        d)  reassembling  (see  6.3);  duplicated   TPDUs   shall   be
            eliminated before reassembling is performed.

     NOTE - The  use  of  RJ  TPDUs  (see  11.2.3.2)   can   lead   to
     retransmission and reduction of credit.  Thus the receipt of a DT
     TPDU which is a duplicate, or which is greater than or  equal  to
     the  upper  window edge allocated to the peer entity, is possible
     and is therefore not treated as a protocol error.

Top       Page 102 
     11.2.3.2  Use of RJ TPDU

     A transport entity may send an RJ TPDU at any time  in  order  to
     invite   retransmission  or  to  reduce  the  upper  window  edge
     allocated to the peer entity (see note 1).

     When an RJ TPDU is  sent,  the  following  constraints  shall  be
     respected:

        a)  the YR-TU-NR parameter shall be at most one  greater  than
            the greatest such value received in a previous DT TPDU, or
            shall be zero if no DT TPDU has  yet  been  received  (see
            note 2);

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

     When a transport entity receives an RJ TPDU (see note 3):

        c)  the next DT TPDU  to  be  transmitted,  or  retransmitted,
            shall be that for which the value of the TPDU-NR parameter
            is equal to the value of the YR-TU-NR parameter of the  RJ
            TPDU;

        d)   the sum of the values of the YR-TU-NR and CDT  parameters
            of the RJ TPDU becomes the new upper window edge (see note
            4).

     NOTES

        1.  An  RJ  TPDU  can  also   be   sent   as   part   of   the
            resynchronization   (see   6.14)  and  reassignment  after
            failure (see 6.12) procedures.

        2.  It is recommended that the YR-TU-NR parameter be equal  to
            the TPDU-NR parameter of the next expected DT TPDU.

        3.  These rules are a subset of those specified for when an RJ
            TPDU  is  received during resynchronization (see 6.14) and
            reassignment after failure (see 6.12).

Top       Page 103 
        4.  This means that RJ TPDU can be used to  reduce  the  upper
            window   edge   allocated   to  the  peer  entity  (credit
            reduction).




     11.2.3.3  Flow Control

     The procedures shall be as defined in 10.2.4.2, except that:

        a)  a credit reduction may lead to the reception of a DT  TPDU
            with  a  TPDU-NR  parameter  whose value is not, but would
            have been less than the upper window edge allocated to the
            remote  entity  prior to the credit reduction.  This shall
            not be treated as a protocol error;

        b)  receipt of an AK TPDU which sets  the  lower  window  edge
            more  than  one  greater  than  the  TPDU-NR  of  the last
            transmitted DT TPDU shall not be  treated  as  a  protocol
            error,  provided  that all acknowledged DT TPDUs have been
            previously transmitted (see notes 1 and 2).
     NOTES

        1.  This  can  only  occur  during  retransmission   following
            receipt of an RJ TPDU.

        2.  The transport entity may either continue retransmission as
            before or retransmit only those DT TPDUs, not acknowledged
            by  the  AK  TPDU.   In  either  case,   copies   of   the
            acknowledged DT TPDUs, need not be retained further.




     11.2.3.4  Expedited data

     The transport entities  shall  follow  the  network  normal  data
     variant  of  expedited data transfer procedure in 6.11 if its use
     has been agreed during connection establishment.

     The sending transport entity shall  not  allocate  the  same  ED-
     TPDU-NR to successive ED TPDUs.

Top       Page 104 
     The receiving transport entity shall transmit an EA TPDU with the
     same  value  in  its YR-EDTU-NR parameter.  If, and only if, this
     number is different from that of the previously received ED  TPDU
     shall  it  generate  a  T-EXPEDITED DATA indication to convey the
     data to the TS-user (see note 2).

     NOTES

        1.  No  other  significance  is  attached  to  the  ED-TPDU-NR
            parameter.  It is recommended, but not essential, that the
            values be consecutive modulo 2**n, where n is  the  number
            of bits of the parameter.

        2.  This procedure ensures that the TS-user does  not  receive
            data corresponding to the same ED TPDU more than once.




     11.2.4  Release

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

Top       Page 105 
     12  SPECIFICATION FOR CLASS 4: ERROR DETECTION AND RECOVERY CLASS

     12.1  Functions of Class 4

     Class 4 provides the functionality of Class 3, plus  the  ability
     to  detect  and recover from lost, duplicated, or out of sequence
     TPDUs without involving the TS-user.

     This detection of errors is made by extended use of the  DT  TPDU
     numbering  of Class 2 and Class 3, by time-out mechanisms, and by
     additional procedures.

     This class additionally detects and recovers from  damaged  TPDUs
     by using a checksum mechanism.  The use of the checksum mechanism
     must be available but its  use  or  its  non-use  is  subject  to
     negotiation.

     Further on this  class  provides  additional  resilience  against
     network failure and increased throughput capability by allowing a
     transport connection to make use of multiple network connections.




     12.2  Procedures for Class 4

     12.2.1  Procedures available at all times

     12.2.1.1  Timers used at all times

     This subclause defines timers that apply at all times in class 4.
     These timers are listed in table 7.

     This International Standard does not define specific  values  for
     the  timers,  and the derivations described in this subclause are
     not mandatory.  The values should be chosen so that the  required
     quality   of   service   can   be   provided,   given  the  known
     characteristics of the network.

     Timers that apply only to specific procedures are  defined  under
     the appropriate procedure.

Top       Page 106 
     +---------------------------|------------------------------------+
     |Symbol|        Name        |            Definition              |
     |------|--------------------|------------------------------------|
     | MLR  |NSDU lifetime       | A bound for the maximum time which |
     |      |local-to-remote     | may elapse between the transmis-   |
     |      |                    | sion of an NSDU by a local trans-  |
     |      |                    | port entity and the receipt of any |
     |      |                    | copy of it by a remote peer entity.|
     |      |                    |                                    |
     | MRL  |NSDU lifetime       | A bound for the maximum time which |
     |      |remote-to-local     | may elapse between the transmission|
     |      |                    | of an SNDU from a remote transport |
     |      |                    | entity to a remote peer entity.    |
     |      |                    |                                    |
     | ELR  |Expected maximum    | A bound for the maximum delay suf- |
     |      |transit delay       | fered by all but a small proportion|
     |      |local-to-remote     | of NSDUs transferred from the local|
     |      |                    | transport entity to a remote peer  |
     |      |                    | entity.                            |
     |      |                    |                                    |
     | ERL  |Expected maximum    | A bound for the maximum delay suf- |
     |      |transit delay       | fered by all but a small proportion|
     |      |remote-to-local     | of NSDUs transferred from a remote |
     |      |                    | transport entity to the local peer |
     |      |                    | entity.                            |
     |      |                    |                                    |
     |  AL  |Local acknowledge   | A bound for the maximum time which |
     |      |time                | can elapse between the receipt of  |
     |      |                    | a TPDU by the local transport en-  |
     |      |                    | tity from the network layer and    |
     |      |                    | the transmission of the corres-    |
     |      |                    | ponding acknowledgement.           |
     |      |                    |                                    |
     |  AR  |Remote acknow-      | As AL, but for the remote entity.  |
     |      |ledgement time      |                                    |
     +----------------------------------------------------------------+

      Table 7. (First of 2 pages) Time Parameters related to class 4

Top       Page 107 
     +----------------------------------------------------------------+
     |  T1  |Local retrans-      | A bound for the maximum time that  |
     |      |mission time        | the local transport entity will    |
     |      |                    | wait for acknowledgement before re-|
     |      |                    | transmitting a TPDU.               |
     |      |                    |                                    |
     |  R   |Persistence time    | A bound for the maximum time the   |
     |      |                    | the local transport entity will    |
     |      |                    | continue to transmit a TPDU that   |
     |      |                    | requires acknowledgement.          |
     |      |                    |                                    |
     |  N   |Maximum number of   | A bound for the maximum number of  |
     |      |transmissions       | times which the local transport    |
     |      |                    | entity will continue to transmit a |
     |      |                    | TPDU that requires acknowledgement.|
     |      |                    |                                    |
     |  L   |Bound on references | A bound for the maximum time       |
     |      |and sequence        | between the transmission of a TPDU |
     |      |numbers             | and the receipt of any acknow-     |
     |      |                    | ledgement relating to it.          |
     |      |                    |                                    |
     |  I   |Inactivity time     | A bound for the time after which   |
     |      |                    | a transport entity will, if it     |
     |      |                    | does not receive a TPDU, initiate  |
     |      |                    | the release procedure to terminate |
     |      |                    | the transport connection.          |
     |      |                    |                                    |
     |      |                    | NOTE - This parameter is required  |
     |      |                    | for protection against unsignalled |
     |      |                    | breaks in the network connection.  |
     |      |                    |                                    |
     |  W   |Window time         | A bound for the maximum time a     |
     |      |                    | transport entity will wait before  |
     |      |                    | retransmitting up to date window   |
     |      |                    | information.                       |
     +----------------------------------------------------------------+

      Table 7. (Second of 2 pages) Time Parameters related to class 4

Top       Page 108 
     12.2.1.1.1  NSDU lifetime (MLR, MRL)

     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 may be different in  each  direction  of
     transfer  through  a network between two transport entities.  The
     values, for both directions of transfer, are assumed to be  Known
     by  the  transport entities.  The maximum NSDU lifetime local-to-
     remote (MLR) is the maximum time which  may  elapse  between  the
     transmission  of  an  NSDU from the local transport entity to the
     network and receipt of any copy of the NSDU from the  network  at
     the  remote  transport entity.  The maximum NSDU lifetime remote-
     to-local (MRL) is the maximum time which may elapse  between  the
     transmission  of  an NSDU from the remote transport entity to the
     network and receipt of any copy of the NSDU from the  network  at
     the local transport entity.




     12.2.1.1.2  Expected maximum transit delay (ELR, ERL)

     The network layer is assumed to provide,  as  an  aspect  of  its
     grade  of service, an expected maximum transit delay for NSDUs in
     the network.  This value may be different in  each  direction  of
     transfer  through  a network between two transport entities.  The
     values, for both directions of transfer, are assumed to be  Known
     by  the  transport  entities.  The expected maximum transit delay
     local-to-remote (ELR) is the maximum delay suffered by all but  a
     small  proportion  of  NSDUs transferred through the network from
     the local transport entity to the remote transport  entity.   The
     expected  maximum  transit  delay  remote-to-local  (ERL)  is the
     maximum delay suffered by all but a  small  proportion  of  NSDUs
     transfer  through the network from the remove transport entity to
     the local transport entity.

Top       Page 109 
     12.2.1.1.3  Acknowledge Time (AR, AL)

     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  transmission  of  the  corresponding
     response.   This  value  is referred to as AL.  The corresponding
     time given by the remote transport entity is referred to as AR.




     12.2.1.1.4  Local retransmission time (T1)

     The local transport entity is assumed to maintain a bound on  the
     time  it  will  wait for an acknowledgement before retransmitting
     the TPDU.  Its value is given by:

        T1 = ELR + ERL + AR + X

     where:

        ELR = Expected maximum transit delay local-to-remote,
        ERL = Expected maximum transit delay remote-to-local,
        AR  = Remote acknowledge time, and
        X   = local processing time for a TPDU.




     12.2.1.1.5  Persistence Time (R)

     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 acknowledgement.  This value is referred to as
     R.

     The  value  is  clearly  related  to  the  time  elapsed  between
     retransmission,  T1,  and the maximum number of transmissions, N.
     It is not less than T1 * N + X, where X is a  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.

Top       Page 110 
     12.2.1.1.6  Bound on References and Sequence Numbers (L)

     A bound for the maximum time between the decision to  transmit  a
     TPDU  and the receipt of any response relating to it (L) is given
     by:

        L = MLR + MRL + R + AR

     where:

        MLR = NSDU lifetime local-to-remote,
        MRL = NSDU lifetime remote-to-local,
        R   = Persistence time, and
        AR  = Remote acknowledgement time.

     It is necessary to  wait  for  a  period  L  before  reusing  any
     reference  of  sequence number, to avoid confusion in case a TPDU
     referring to it may be duplicated or delayed.

     NOTES

        1.  In practice, 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.

        2.  The  relationships  between  times  discussed  above   are
            illustrated in figures 3 and 4.

            [Figures 3 and 4 are omitted from this copy.]




     12.2.1.2  General Procedures

     The transport entity shall use the following procedures:

        a)  TPDU transfer (see 6.2);

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

Top       Page 111 
        c)  treatment of protocol errors (see 6.22);

        d)  checksum (see 6.17);

        e)  splitting and recombining (see 6.23);

        f)  multiplexing and demultiplexing (see 6.15);

        g)  retention until acknowledgement of TPDUs (see 6.13);

        h)  frozen references (see 6.18).

        j)  retransmission procedures; when  a  transport  entity  has
            some  outstanding  TPDUs  that require acknowledgement, it
            will check that no T1 interval elapses without the arrival
            of   a   TPDU  that  acknowledges  at  least  one  of  the
            outstanding TPDUs.

            If  the  timer  expires,  except  if  the   TPDU   to   be
            retransmitted  is a DT TPDU and it is outside the transmit
            window  due  credit   reduction,   the   first   TPDU   is
            retransmitted   and  the  timer  is  restarted.   After  N
            transmissions (i.e. N-1  retransmissions)  it  is  assumed
            that  useful  two-way  communication is no longer possible
            and the release procedure is  used,  and  the  TS-user  is
            informed.

        NOTES

        1)  This procedure may be implemented by different means.  For
            example:

            a)  one interval is associated with  each  TPDU.   If  the
                timer  expires the associated TPDU will be transmitted
                and the timer T1 will be restarted for all  subsequent
                TPDUs; or

            b)  one  interval  is  associated  with   each   transport
                connection:

                1)  if the transport entity transmits a TPDU requiring
                    acknowledgement, it starts timer T1;

Top       Page 112 
                2)  if the  transport  entity  receives  a  TPDU  that
                    acknowledges  one of the TPDUs to be acknowledged,
                    it restarts timer T1 unless the received  TPDU  is
                    an AK which explicitly closes the transmit window.

                3)  if the  transport  entity  receives  a  TPDU  that
                    acknowledges  the last TPDU to be acknowledged, it
                    stops timer T1.

            For a decision whether  the  retransmission  timer  T1  is
            maintained  on a per TPDU or on a per transport connection
            basis, throughput considerations have  to  be  taken  into
            account.

        2.  For DT TPDUs it is a local  choice  to  retransmit  either
            only  the  first  DT  TPDU  or  all  TPDUs  waiting for an
            acknowledgement up to the upper window edge.

        3.  It is recommended that after N transmissions of a DT TPDU,
            the  transport  entity  waits  T1 + W + MRL  to  provide a
            higher possibility of receiving an acknowledgement  before
            entering  the  release  phase.  For other TPDU types which
            may be retransmitted,  it  is  recommended  that  after  N
            transmissions  the  transport  entity  waits  T1 + MRL  to
            provide a higher possibility  of  receiving  the  expected
            reply.




     12.2.2  Procedures for Connection Establishment

     12.2.2.1  Timers used in Connection Establishment

     There are no timers specific to connection establishment.

Top       Page 113 
     12.2.2.2  General Procedures

     The transport entities shall use the following procedures:

        a)  assignment to network connection (see 6.1);

        b)  connection establishment  (see  6.5)  and  if  appropriate
            connection  refusal (see 6.6) together with the additional
            procedures:

            1)  a connection is not considered established  until  the
                successful  completion  of a 3-way TPDU exchange.  The
                sender of a CR TPDU shall respond to the corresponding
                CC  TPDU  by  immediately  sending  a DT, ED, DR or AK
                TPDU;

            2)  as a result of duplication  or  retransmission,  a  CR
                TPDU  may  be  received  specifying a source reference
                which is already in use  with  the  sending  transport
                entity.   If  the receiving transport entity is in the
                data transfer phase, having completed the  3-way  TPDU
                exchange  procedure,  or  is waiting for the T-CONNECT
                response from the  TS-user,  the  receiving  transport
                entity  shall ignore such a TPDU.  Otherwise a CC TPDU
                shall be transmitted;

            3)  as a result of duplication  or  retransmission,  a  CC
                TPDU  may  be  received  specifying a paired reference
                which is already  in  use.   The  receiving  transport
                entity  shall  only  acknowledge the duplicate CC TPDU
                according to the procedure in 12.2.2.2.b.1.

            4)  a CC TPDU may be received specifying a reference which
                is  in  the frozen state.  The response to such a TPDU
                shall be a DR TPDU;

            5)  the retransmission procedures (see 12.2.1.2) are  used
                for both the CR TPDU and CC TPDU.

Top       Page 114 
     12.2.3  Procedures for Data Transfer

     12.2.3.1  Timers used in Data Transfer

     The data transfer procedures use two additional timers:

        a)  Inactivity Time (I)

        To  protect  against  unsignalled  breaks   in   the   network
        connection  or failure of the peer transport entity (half-open
        connections), each transport entity  maintains  an  inactivity
        interval.  The interval must be greater than E.

        NOTE - A suitable value for I is given by
        2 * (N * maximum of (T1, W))
        unless local needs indicate another more appropriate value.

        b)  Window Time (W)

        A transport entity maintains a timer interval to  ensure  that
        there  is  a  bound  on  the  maximum  interval between window
        updates.




     12.2.3.2  General Procedures for data transfer

     The transport entities shall use the following procedures:

        a)  inactivity control    (see 6.21);

        b)  expedited data        (see 6.11);

        c)  explicit flow control (see 6.16).

     The sending transport entity shall use the  following  procedures
     in the following order:

        d)  segmenting            (see 6.3);

        e)  DT TPDU numbering     (see 6.10).

Top       Page 115 
     The receiving transport entity shall use the following procedures
     in the following order:

        f)  DT TPDU numbering     (see 6.10);

        g)  resequencing          (see 6.20);

        h)  reassembling          (see 6.3).




     12.2.3.3  Inactivity Control

     If the interval of the inactivity timer I expires without receipt
     of  some  TPDU,  the  transport entity shall initiate the release
     procedures.   To  prevent  expiration  of  the  remote  transport
     entity's  inactivity  timer when no data is being sent, the local
     transport entity must send AK TPDUs at suitable intervals in  the
     absence  of  data, having regard to the probability of TPDU loss.
     The window synchronization procedures (see 12.2.3.8) ensure  that
     this requirement is met.

     NOTE - It is likely that the release procedure initiated  due  to
     the  expiration  of  the  inactivity  timer  will  fail,  as such
     expiration indicates probable failure of the  supporting  network
     connection or of the remote transport entity.




     12.2.3.4  Expedited Data

     The transport entities  shall  follow  the  network  normal  data
     variant  of the expedited data transfer procedures (see 6.11), if
     the use of transport expedited service  option  has  been  agreed
     during connection establishment.

     The ED TPDU shall have  a  TPDU-NR  which  is  allocated  from  a
     separate sequence space from that of the DT TPDUs.

     A transport entity shall allocate the sequence number zero to the
     ED  TPDU-NR  of  the  first  ED  TPDU  which  it  transmits for a

Top       Page 116 
     transport connection.  For subsequent ED TPDU sent  on  the  same
     transport  connection,  the  transport  entity  shall  allocate a
     sequence number one greater than the previous one.

     Modulo 2**7 arithmetic shall be used  when  normal  formats  have
     been  selected  and  modulo  2**31  arithmetic shall be used when
     extended formats have been selected.

     The receiving transport entity shall transmit an EA TPDU with the
     same  sequence number in its YR-ETDU-NR field.  If this number is
     one greater than in the previously in sequence received ED  TPDU,
     the  receiving transport entity shall transfer the data in the ED
     TPDU to the TS-user.

     If  a  transport  entity  does  not  receive  an   EA   TPDU   in
     acknowledgement  to an ED TPDU it shall follow the retransmission
     procedures (see note and 12.2.1.2).

     The sender of an ED TPDU shall not send  any  new  DT  TPDU  with
     higher TPDU-NR until it receives the EA TPDU.

     NOTE - This procedure ensures that ED TPDUs are delivered to  the
     TS-user  in  sequence  and that the TS-user does not receive data
     corresponding to the same  ED  TPDU  more  than  once.   Also  it
     guarantees  the  arrival  of  the ED TPDU before any subsequently
     sent DT TPDU.




     12.2.3.5  Resequencing

     The receiving transport entity shall deliver all DT TPDUs to  the
     TS-user in the order specified by the sequence number field.

     DT TPDUs received out-of-sequence but within the transmit  window
     shall not be delivered to the TS-user until all in-sequence TPDUs
     have been received.  DT TPDU received out-of-sequence and outside
     the transmit window shall be discarded.

     Duplicate TPDUs can  be  detected  because  the  sequence  number
     matches  that  of  preciously  received  TPDUs.  Sequence numbers
     shall not be reused for the period L after  their  previous  use.

Top       Page 117 
     Otherwise,  a new, valid TPDU could be confused with a duplicated
     TPDU which had previously been received and acknowledged.

     Duplicated DT TPDUs shall be acknowledged, since  the  duplicated
     TPDU  may  be  the  result of a retransmission resulting from the
     loss of an AK TPDU.

     The data contained in a duplicated DT TPDU shall be ignored.




     12.2.3.6  Explicit Flow Control

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

     The transport entity which receives the CR TPDU or CC TPDU  shall
     consider  its lower window edge as zero and its upper window edge
     as the value in 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.

     The sequence number of an AK TPDU shall not exceed  the  sequence
     number of the next expected DT TPDU, i.e. it shall not be greater
     than the highest sequence number of a received DT TPDU, plus one.

     A transport entity may send a duplicate AK  TPDU  containing  the
     same  sequence  number,  CDT, and subsequence number field at any
     time.

     A transport entity which receives an AK TPDU shall  consider  the
     value of the YR-TU-NR field as its new lower window edge if it is
     greater than any previously received in a YR-TU-NR field, and the
     sum  of  YR-TU-NR and CDT as its new upper window edge subject to
     the  procedures  for  sequencing  AK  TPDUs  (see  12.2.3.8).   A
     transport  entity shall not transmit or retransmit a DT TPDU with
     a sequence number outside the transmit window.

Top       Page 118 
     12.2.3.7  Sequencing of received AK TPDUs

     To allow a receiving transport  entity  to  properly  sequence  a
     series  of AK TPDUs that all contain the same sequence number and
     thereby use the  correct  CDT  value,  AK  TPDUs  may  contain  a
     subsequence  parameter.   For  the  purpose  of  determining  the
     correct sequence of AK TPDUs,  the  absence  of  the  subsequence
     parameter  shall  be equivalent to the value of the parameter set
     to zero.

     An AK TPDU is defined to be in sequence if:

        a)  the sequence number is  greater  than  in  any  previously
            received AK TPDU, or

        b)  the sequence  number  is  equal  to  the  highest  in  any
            previously received AK TPDU, and the subsequence parameter
            is greater than in any previously received AK TPDU  having
            the same value for YR-TU-NR field, or

        c)  the sequence number and  subsequence  parameter  are  both
            equal  to  the  highest in any previously received AK TPDU
            and the credit field is greater than or equal to  that  in
            any  previously  received AK TPDU having the same YR-TU-NR
            field.

     A transport entity is not required  to  include  the  subsequence
     number  in  its  AK  TPDUs.   It  may  also choose not to use the
     subsequence parameter in sequencing  received  AK  TPDUs.   If  a
     transport   entity  chooses  not  to  recognize  the  subsequence
     parameter it shall still sequence received AK TPDUs according  to
     12.2.3.7.a.

     When the receiving transport entity recognizes an out of sequence
     AK TPDU it shall ignore it.

Top       Page 119 
     12.2.3.8  Procedure for transmission of AK TPDUs

     12.2.3.8.1  Retransmission of AK TPDUs for window synchronization

     A transport entity shall not allow an interval W to pass  without
     the  transmission  of an AK TPDU.  if the transport entity is not
     using  the  procedure  following  setting  CDT   to   zero   (see
     12.2.3.8.3)   or   reduction   of  the  upper  window  edge  (see
     12.2.3.8.4), and does not have to acknowledge receipt of  any  DT
     TPDU,  then  it  shall achieve this by retransmission of the most
     recent AK TPDU, with up-to-date window information.

     NOTE - The use  of  the  procedures  defined  in  12.2.3.8.3  and
     12.2.3.8.4  are  optional for any transport entity.  The protocol
     operates correctly either with or without these procedures  which
     are defined to enhance the efficiency of its operation.  However,
     if these procedures are not used then W must  be  set  to  ensure
     enough  retransmissions  of  the AK TPDU so that release of TC is
     avoided.    The   value   of   W    should    be    approximately
     W = (T1 * N)/(N-1) when the procedures are not used.




     12.2.3.8.2  Sequence control for transmission of AK TPDUs

     To allow the receiving transport entity to process  AK  TPDUs  in
     the  correct  sequence, as described in 12.2.3.7, the subsequence
     parameter may be included following reduction  of  CDT.   If  the
     value  of  the subsequence number to be transmitted is zero, then
     the parameter should be omitted.

     The value of the subsequence parameter, if used,  shall  be  zero
     (either  explicitly  or  by  absence  of  the  parameter)  if the
     sequence number is greater than the field in previous  AK  TPDUs,
     sent by the transport entity.

     If the sequence number is the same as the previous AK  TPDU  sent
     and  the  CDT  field is equal to or greater than the CDT field in
     the previous AK TPDU sent  then  the  subsequence  parameter,  if
     used, shall be equal to that in the previously sent AK TPDU.

     If the sequence number is the same as the previous AK  TPDU  sent

Top       Page 120 
     and  the CDT field is less than the value of the CDT field in the
     previous AK TPDU sent than the subsequence  parameter,  if  used,
     shall be one greater than the value in the previous AK TPDU..




     12.2.3.8.3  Retransmission of AK TPDUs after CDT set to zero

     Due to the possibility of loss of AK TPDUs, the upper window edge
     as  perceived by the transport entity transmitting an AK TPDU may
     differ from that perceived by the intended recipient.   To  avoid
     the possibility of extra delay, the retransmission procedure (see
     12.2.1.2) should be followed for an AK  TPDU,  if  it  opens  the
     transmit window which has previously been closed by sending an AK
     TPDU with CDT field set to zero.

     The  retransmission  procedure,  if  used,  terminates  and   the
     procedure in 12.2.3.8.1 is used when:

        a)  an  AK  TPDU  is  received  containing  the  flow  control
            confirmation  parameter,  whose lower window edge and your
            subsequence fields are equal to the  sequence  number  and
            subsequence  number  in  the  retained  AK  TPDU and whose
            credit field is not zero.

        b)  an AK TPDU is transmitted with a  sequence  number  higher
            than  that  in the retained AK TPDU, due to reception of a
            DT TPDU whose sequence number is equal to the lower window
            edge;

        c)  N transmissions of the retained AK TPDU have taken  place.
            In  this  case  the  transport  entity  shall  continue to
            transmit the AK TPDU at an interval of W.

     An AK TPDU which is subject to the retransmission procedure shall
     not  contain  the  flow control confirmation parameter.  If it is
     required to transmit this parameter concurrently,  an  additional
     AK  TPDU  shall  be  transmitted  having  the  same values in the
     sequence, subsequence (if applicable) and credit fields.

Top       Page 121 
     12.2.3.8.4  Retransmission procedures following reduction of the

                 upper window edge

     This subclause specifies the procedure for retransmission  of  AK
     TPDUs  after a transport entity has reduced the upper window edge
     (see 12.2.3.6) or for an AK TPDU with the  credit  field  set  to
     zero.  This procedure is used until the lower window edge exceeds
     the highest value of the upper window edge ever transmitted (i.e.
     the  value  existing  at  the  time of credit reduction, unless a
     higher value is retained from a previous credit reduction).

     This retransmission procedure should be followed for any AK  TPDU
     which increases the upper window edge, unless an AK TPDU has been
     received containing a flow control confirmation parameter,  which
     corresponds to an AK TPDU transmitted following credit reduction,
     for which the sum of the credit  and  lower  window  edge  fields
     (i.e.  the  upper  window  edge  value) is greater than the lower
     window edge (YR-TU-NR field) of the transmitted AK TPDU.

     This retransmission procedure for any particular  AK  TPDU  shall
     terminate when:

        a)  an  AK  TPDU  is  received  containing  the  flow  control
            confirmation  parameter,  whose lower window edge and your
            subsequence fields are equal to the lower window edge  and
            subsequence number in the retained AK TPDU; or

        b)  N transmissions of the retained AK TPDU have taken  place.
            In  this  case  the  transport  entity  shall  continue to
            transmit the AK TPDU at an interval of W.

     An AK TPDU which is subject to the retransmission procedure shall
     not  contain  the  flow control confirmation parameter.  If it is
     required to transmit this parameter concurrently,  an  additional
     AK  TPDU  shall  be  transmitted  having  the  same values in the
     sequence, subsequence (if applicable) and credit fields.

        NOTE - Retransmission of AK TPDUs is normally  not  necessary,
        except   following   explicit  closing  of  the  window  (i.e.
        transmission of an AK TPDU with CDT field set  to  zero).   If
        data  is  available  to  be  transmitted,  the  retransmission
        procedure for DT TPDUs will ensure that an AK TPDU is received

Top       Page 122 
        granting  further  credit  where this is available.  Following
        credit  reduction,  this  may  no  longer   be   so,   because
        retransmission  may be inhibited by the credit reduction.  The
        rules described in this clause avoid extra delay.

     The rules for determining whether  to  apply  the  retransmission
     procedure  to  an  AK  TPDU  may  be  expressed  alternatively as
     follows.  Let:

          LWE  = lower window edge
          UWE  = upper window edge
          KUWE = lower bound on upper window edge
                 held by remote transport entity

     The retransmission procedure is to be used whenever:

          (UWE>LWE) and (KUWE = LWE)

     i.e. when the window is opened and it  is  not  known  definitely
     that the remote transport entity is aware of this.

     KUWE is maintained as follows.  When credit is reduced,  KUWE  is
     set to LWE.  Subsequently, it is increased only upon receipt of a
     valid flow control  confirmation  (i.e.  one  which  matches  the
     retained  lower  window edge and subsequence).  In this case KUWE
     is set to the implied upper  window  edge  of  the  flow  control
     confirmation,  i.e.  the  sum  of  its lower window edge and your
     credit fields.  By this means, it can be  ensured  that  KUWE  is
     always  less than or equal to the actual upper window edge in use
     by the transmitter of DT TPDUs.




     12.2.3.9  Use of Flow Control Confirmation parameter

     At any time, an AK TPDU may  be  transmitted  containing  a  flow
     control  confirmation  parameter.   The  lower  window edge, your
     subsequence and your credit fields  shall  be  set  to  the  same
     values  as the corresponding fields in the most recently received
     in sequence AK TPDU.

Top       Page 123 
     An AK TPDU  containing  a  flow  control  confirmation  parameter
     should be transmitted whenever:

        a)  a duplicate AK TPDU is received, with the value of  YR-TU-
            NR, CDT, and subsequence fields equal to the most recently
            received AK TPDU,  but  not  itself  containing  the  flow
            control confirmation parameter;

        b)  an AK TPDU is received which increases  the  upper  window
            edge  but  not the lower window edge, and the upper window
            edge was formerly equal to the lower window edge; or

        c)  an AK TPDU is received which increases  the  upper  window
            edge  but  not the lower window edge, and the lower window
            edge is lower than the highest value of the  upper  window
            edge  received  and  subsequently  reduced (i.e. following
            credit reduction).




     12.2.4  Procedures for Release

     12.2.4.1  Timers used for Release

     There are no timers used only for release.




     12.2.4.2  General Procedures for Release

     The transport entity shall use the  explicit  variant  of  normal
     release (see 6.7).

Top       Page 124 
     13  STRUCTURE AND ENCODING OF TPDUs

     13.1  Validity

     Table 8 specifies those TPDUs which are valid for each class  and
     the code for each TPDU.

        KEY:  xxxx (bits 4-1):  used to signal the CDT (set to 0000
                                in classes 0 and 1)

              zzzz (bits 4-1):  used to signal CDT in classes 2, 3,
                                4 set to 1111 in class 1

              NF:               Not available when the non explicit
                                flow control option is selected.

              NRC:              Not available when the receipt
                                confirmation option is selected.

     NOTE  - These codes are  already  in  use  in  related  protocols
     defined by standards oganizations other than CCITT/ISO.

Top       Page 125 
     +-------------------------------------------------------------+
     |                       | Validity within   |       |         |
     |                       |     classes       |  see  |  Code   |
     |                       |-------------------| Clause|         |
     |                       | 0 | 1 | 2 | 3 | 4 |       |         |
     |-----------------------|-------------------|-------|---------|
     |CR Connection Request  | x | x | x | x | x | 13.3  |1110 xxxx|
     |-----------------------|---|---|---|---|---|-------|---------|
     |CC Connection Confirm  | x | x | x | x | x | 13.4  |1101 xxxx|
     |-----------------------|---|---|---|---|---|-------|---------|
     |DR Disconnect Request  | x | x | x | x | x | 13.5  |1000 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |DC Disconnect Confirm  |   | x | x | x | x | 13.6  |1100 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |DT Data                | x | x | x | x | x | 13.7  |1111 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |ED Expedited Data      |   | x | NF| x | x | 13.8  |0001 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |AK Data Acknowledgement|   |NRC| NF| x | x | 13.9  |0110 zzzz|
     |-----------------------|---|---|---|---|---|-------|---------|
     |EA Expedited Data      |   | x | NF| x | x | 13.10 |0010 0000|
     |Acknowledgement        |   |   |   |   |   |       |         |
     |-----------------------|---|---|---|---|---|-------|---------|
     |RJ Reject              |   | x |   | x |   | 13.11 |0101 zzzz|
     |-----------------------|---|---|---|---|---|-------|---------|
     |ER TPDU Error          | x | x | x | x | x | 13.12 |0111 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |                       |   |   |   |   |   |   -   |0000 0000|
     |                       |---|---|---|---|---|-------|---------|
     |not available          |   |   |   |   |   |   -   |0011 0000|
     | (see note)            |---|---|---|---|---|-------|---------|
     |                       |   |   |   |   |   |   -   |1001 xxxx|
     |                       |---|---|---|---|---|-------|---------|
     |                       |   |   |   |   |   |   -   |1010 xxxx|
     +-------------------------------------------------------------+

                            Table 8. TPDU code

Top       Page 126 
     13.2  Structure

     All the transport protocol data units (TPDUs)  shall  contain  an
     integral  number  of  octets.   The octets in a TPDU are numbered
     starting from 1 and increasing in the order they are put into  an
     NSDU.  The bits in an octet are numbered from 1 to 8, where bit 1
     is the low-ordered bit.

     When consecutive octets are used to represent  a  binary  number,
     the lower octet number has the least significant value.

     NOTE -  When the encoding  of  a  TPDU  is  represented  using  a
     diagram in this clause, the following representation is used:

        a)  octets are shown with the lowest  numbered  octet  to  the
            left, higher numbered octets being further to the right;

        b)  within an octet, bits are shown with bit 8 to the left and
            bit 1 to the right.

     TPDUs shall contain, in the following order:

        a)  the header, comprising:

            1)  the length indicator (LI) field;

            2)  the fixed part;

            3)  the variable part, if present;

        b)  the data field, if present.

     This structure is illustrated below:

          octet    1   2 3 4 ... n   n+1  ...    p  p+1 ...end
                 +---+-------------+--------------+-----------+
                 | LI| fixed part  | variable part| data field|
                 +---+-------------+--------------+-----------+
                 <---------------   header ------>

Top       Page 127 
     13.2.1  Length indicator field

     This field is contained in the first octet  of  the  TPDUs.   The
     length  is  indicated by a binary number, with a maximum value of
     254 (1111 1110).  The length indicated shall be the header length
     in   octets   including  parameters,  but  excluding  the  length
     indicator field and user data, if any.  The value 255 (1111 1111)
     is  reserved  for  possible  extensions.  If the length indicated
     exceeds the size of the NS-user data which is present, this is  a
     protocol error.




     13.2.2  Fixed part

     13.2.2.1  General

     The fixed part contains frequently occurring parameters including
     the  code of the TPDU.  The length and the structure of the fixed
     part are defined by the TPDU code and in  certain  cases  by  the
     protocol  class  and the formats in use (normal or extended).  If
     any of the parameters of the fixed part have an invalid value, or
     if the fixed part cannot be contained with the header (as defined
     by LI) this is a protocol error.

     NOTE - In  general,  the  TPDU  code  defines  the   fixed   part
     unambiguously.   However,  different  variants  may exist for the
     same TPDU code (see normal and extended formats).




     13.2.2.2  TPDU code

     This field contains the TPDU code and is contained in octet 2  of
     the  header.  It is used to define the structure of the remaining
     header.  This field is a  full  octet  except  in  the  following
     cases:

Top       Page 128 
           1110 xxxx     Connection Request
           1101 xxxx     Connection Confirm
           0101 xxxx     Reject
           0110 xxxx     Data Acknowledgement

     where xxxx (bits 4-1) is used to signal the CDT.

     Only those codes defined in 13.1 are valid.




     13.2.3  Variable part

     The  variable  part  is  used  to  define  less  frequently  used
     parameters.   If  the  variable part is present, it shall contain
     one or more parameters.

     NOTE - The number of parameters that  may  be  contained  in  the
     variable  part  is  indicated  by the length of the variable part
     which is LI minus the length of the fixed part.

     Each parameter contained within the variable part  is  structured
     as follows:

                    Bits   8    7    6    5    4    3    2    1
          Octets          +------------------------------------+
           n+1            |          Parameter Code            |
                          |------------------------------------|
           n+2            |          Parameter Length          |
                          |          Indication (e.g. m)       |
                          |------------------------------------|
           n+3            |                                    |
                          |          Parameter Value           |
           n+2+m          |                                    |
                          +------------------------------------|

Top       Page 129 
     - The parameter code field is coded in binary;

       NOTE - Without extensions, it provides a maximum number of  255
       different  parameters.   However,  as noted below, bits 8 and 7
       cannot take every possible  value,  so  the  practical  maximum
       number  of  different  parameters is less.  Parameter code 1111
       1111 is reserved for possible extensions of the parameter code.

     - The  parameter  length  indication  indicates  the  length,  in
       octets, of the parameter value field.

       NOTE - The length is indicated by a binary number,  m,  with  a
       theoretical  maximum value of 255.  The practical maximum value
       of m is lower.  For example, in the case of a single  parameter
       contained within the variable part, two octets are required for
       the parameter code and the parameter length indication  itself.
       Thus, the value of m is limited to 248.  For larger fixed parts
       of the header and for each succeeding  parameter,  the  maximum
       value of m decreases.

     - The parameter value field contains the value of  the  parameter
       identified in the parameter code field.

     - No parameter codes use bits 8 and 7 with the value 00.

     - The parameters defined in the  variable  part  may  be  in  any
       order.   If  any  parameter  is duplicated then the later value
       shall be used.  A parameter not defined in  this  International
       Standard  shall  be treated as a protocol error in any received
       TPDU except a CR TPDU; in a CR TPDU it shall  be  ignored.   If
       the  responding  transport  entity  selects a class for which a
       parameter of the CR TPDU is not defined,  it  may  ignore  this
       parameter,   except  the  class  and  option,  and  alternative
       protocol class parameters which shall always be interpreted.  A
       parameter  defined in this International Standard but having an
       invalid value shall be treated  as  a  protocol  error  in  any
       received  TPDU  except  a  CR  TPDU.   In a CR TPDU it shall be
       treated as a protocol error if  it  is  either  the  class  and
       option  parameter  or  the  alternative  class parameter or the
       additional option  parameter;  otherwise  it  shall  be  either
       ignored or treated as a protocol error.


Next RFC Part