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 2 of 5, p. 35 to 69
Prev RFC Part       Next RFC Part

 


prevText      Top       Page 35 
     5.4.8  Characteristics of Class 4

     Class 4  provides  the  characteristics  of  Class  3,  plus  the
     capability  to  detect  and  recover from errors which occur as a
     result of the  low  grade  of  service  available  from  the  NS-
     provider.   The  kinds  of  errors  to be detected include:  TPDU
     loss, TPDU delivery out of sequence, TPDU  duplication  and  TPDU
     corruption.   These  errors  may  affect control TPDUs as well as
     data TPDUs.

     This class also provides for increased throughput capability  and
     additional  resilience  against network failure. Class 4 has been
     designed to be used with type C network connections.




     5.5  Model of the transport layer

     A transport entity communicates with its TS-users through one  or
     more  TSAPs  by means of the service primitives as defined by the
     transport service definition DP 8072.   Service  primitives  will
     cause  or be the result of transport protocol data unit exchanges
     between  the  peer  transport  entities  supporting  a  transport
     connection.   These  protocol  exchanges  are  effected using the
     services of the Network Layer as defined by the  Network  Service
     Definition DP 8348 through one or more NSAPs.

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

Top       Page 36 
               +------+                        +------+
     ----------| TSAP |------------------------| TSAP |----------
               +------+                        +------+
                   |                               |
            +---------------+               +---------------+
            | Transport     |               | Transport     |
            |       entity  |               |       entity  |
            +---------------+               +---------------+
                   |                               |
                   |                               |
               +------+                        +------+
     ----------| NSAP |------------------------| NSAP |----------
               +------+                        +------+
                   |                               |
                   +-------------------------------+

                  Figure 2 . Model of the transport layer



     NOTE - For purpose of illustration, this figure  shows  only  one
     TSAP  and  one  NSAP  for  each  transport  entity.   In  certain
     instances, more than one TSAP and/or more than one  NSAP  may  be
     associated with a particular transport entity.

Top       Page 37 
     SECTION TWO.  TRANSPORT PROTOCOL SPECIFICATION




     6  ELEMENTS OF PROCEDURE

     This clause contains elements of procedure which are used in  the
     specification  of  protocol  classes  in  clauses 7 to 12.  These
     elements are not meaningful on their own.

     The procedures define the transfer of TPDUs whose  structure  and
     coding  is  specified  in  clause  13.   Transport entities shall
     accept and respond to any TPDU received in a valid NSDU  and  may
     issue  TPDUs  initiating specific elements of procedure specified
     in this clause.

     NOTE - Where network service primitives and TPDUs and  parameters
     used  are  not significant for a particular element of procedure,
     they have not been included in the specification.




     6.1  Assignment to network connection

     6.1.1  Purpose

     The  procedure  is  used  in  all  classes  to  assign  transport
     connections to network connections.




     6.1.2  Network service primitives

     The  procedure  makes  use  of  the  following  network   service
     primitives:

        a)  N-CONNECT;

        b)  N-DISCONNECT.

Top       Page 38 
     6.1.3  Procedure

     Each  transport  connection  shall  be  assigned  to  a   network
     connection.  The initiator may assign the transport connection to
     an existing network connection of which it is the owner or  to  a
     new  network  connection  (see  Note 1) which it creates for this
     purpose.

     The  initiator  shall  not  assign  or  reassign  the   transport
     connection  to  an  existing  network  connection if the protocol
     class(es)  proposed  or  the  class  in  use  for  the  transport
     connection are incompatible with the current usage of the network
     connection with respect to multiplexing (see Note 2).

     During the resynchronization (see 6.14)  and  reassignment  after
     failure  (see 6.12) procedures, a transport entity may reassign a
     transport connection to another network  connection  joining  the
     same  NSAPs,  provided  that  it  is  the  owner  of  the network
     connection and that the transport connection is assigned to  only
     one network connection at any given time.

     During the splitting procedure (see 6.23), a transport entity may
     assign   a   transport   connection  to  any  additional  network
     connection joining the same NSAPs, provided that it is the  owner
     of  the  network  connection and that multiplexing is possible on
     the network connection.

     The responder becomes aware of the assignment when it receives

        a)  a CR TPDU during the  connection  establishment  procedure
            (see 6.5); or

        b)  an RJ TPDU or a retransmitted CR or  DR  TPDU  during  the
            resynchronization   (see   6.14)  and  reassignment  after
            failure (see 6.12) procedures; or

        c)  any TPDU when splitting (see 6.23) is used.

Top       Page 39 
     NOTES

        1.  When a new network connection is created, the  quality  of
            service  requested  is  a  local  matter, although it will
            normally be  related  to  the  requirements  of  transport
            connection(s) expected to be assigned to it.

        2.  An existing network connection may also  not  be  suitable
            if,  for example, the quality of service requested for the
            transport  connection  cannot  be  attained  by  using  or
            enhancing the network connection.

        3.  A  network  connection  with  no  transport  connection(s)
            assigned   to   it,   may   be   available  after  initial
            establishment, or because all of the transport connections
            previously  assigned  to  it  have  been  released.  It is
            recommended  that  only  the  owner  of  such  a   network
            connection   should   release   it.   Furthermore,  it  is
            recommended that it not be released immediately after  the
            transmission of the final TPDU of a transport connection -
            either a DR TPDU in response to CR TPDU or a  DC  TPDU  in
            response  to DR TPDU.  An appropriate delay will allow the
            TPDU  concerned  to  reach  the  other  transport   entity
            allowing  the freeing of any resources associated with the
            transport connection concerned.

        4.  After the  failure  of  a  network  connection,  transport
            connections which were previously multiplexed together may
            be assigned to different  network  connections,  and  vice
            versa.




     6.2  Transport protocol data unit (TPDU) transfer

     6.2.1  Purpose

     The TPDU transfer procedure is used  in  all  classes  to  convey
     transport  protocol  data  units  in  user data fields of network
     service primitives.

Top       Page 40 
     6.2.2  Network Service Primitives

     The procedure uses the following network service primitives:

        a)  N-DATA;

        b)  N-EXPEDITED DATA




     6.2.3  Procedure

     The  transport  protocol  data  units  (TPDUs)  defined  for  the
     protocol are listed in 4.2.

     When the network expedited variant has been selected for class 1,
     the transport entities shall transmit and receive ED and EA TPDUs
     as NS-user data parameters of N-EXPEDITED DATA primitives.

     In all other cases, transport entities shall transmit and receive
     TPDUs as NS-user data parameters of N-DATA primitives.

     When  a  TPDU  is  put  into  an  NS-user  data  parameter,   the
     significance  of the bits within an octet and the order of octets
     within a TPDU shall be as defined in 13.2.

     NOTE - TPDUs may be concatenated (see 6.4).




     6.3  Segmenting and reassembling

     6.3.1  Purpose

     The segmenting and reassembling procedure is used in all  classes
     to map TSDUs onto TPDUs.

Top       Page 41 
     6.3.2  TPDUs and parameter used

     The procedure makes use of the following TPDU and parameter:

        DT TPDUs;

           - End of TSDU.




     6.3.3  Procedure

     A transport entity shall map a TSDU on to an ordered sequence  of
     one  or more DT TPDUs.  This sequence shall not be interrupted by
     other DT TPDUs on the same transport connection.

     All DT TPDUs except the last DT TPDU in a sequence  greater  than
     one shall have a length of data greater than zero.

     NOTES

        1.  The EOT parameter of a DT TPDU indicates  whether  or  not
            there are subsequent DT TPDUs in the sequence.

        2.  There is no requirement that the DT TPDUs shall be of  the
            maximum length selected during connection establishment.




     6.4  Concatenation and separation

     6.4.1  Purpose

     The procedure for concatenation and separation is used in classes
     1, 2, 3 and 4 to convey multiple TPDUs in one NSDU.

Top       Page 42 
     6.4.2  Procedure

     A transport  entity  may  concatenate  TPDUs  from  the  same  or
     different transport connections.

     The set of concatenated TPDUs may contain:

        a)  any number of TPDUs from the following list:  AK, EA,  RJ,
            ER,   DC  TPDUs,  provided  that  these  TPDUs  come  from
            different transport connections;

        b)  no more than one TPDU from the following  list:   CR,  DR,
            CC,  DT,  ED  TPDUs;  if this TPDU is present, it shall be
            placed last in the set of concatenated TPDUs.

     NOTES

        1.  The TPDUs within a concatenated set may  be  distinguished
            by means of the length indicator parameter.

        2.  The end of a TPDU containing  data  is  indicated  by  the
            termination of the NSDU.

        3.  The number of concatenated TPDUs referred to in 6.4.2.a is
            bounded  by  the  maximum  number of transport connections
            which are multiplexed together except during assignment or
            reassignment.




     6.5  Connection establishment

     6.5.1  Purpose

     The procedure for connection establishment is used in all classes
     to create a new transport connection.

Top       Page 43 
     6.5.2  Network service primitives

     The procedure uses the following network service primitive:

     N-DATA




     6.5.3  TPDUs and parameters used

     The procedure uses the following TPDUs and parameters:

        a)  CR TPDU;

            - CDT;
            - DST-REF (set to zero);
            - SRC-REF
            - CLASS and OPTIONS (i.e. preferred class, use of extended
              format, non-use of explicit flow control in class 2);
            - calling TSAP-ID;
            - called TSAP-ID;
            - TPDU size (proposed);
            - version number;
            - security parameter;
            - checksum;
            - additional  option  selection  (i.e.  use   of   network
              expedited  in  class  1,  use of receipt confirmation in
              class  1,  non-use  of  checksum  in  class  4,  use  of
              transport expedited data transfer service);
            - alternative protocol class(es);
            - acknowledge time;
            - throughput (proposed);
            - residual error rate (proposed);
            - priority (proposed);
            - transit delay (proposed);
            - reassignment time;
            - user data.

        b)  CC TPDU;

            - CDT;
            - DST-REF;

Top       Page 44 
            - SRC-REF;
            - CLASS and OPTIONS (selected);
            - calling TSAP-ID;
            - called TSAP-ID;
            - TPDU size (selected);
            - security parameter;
            - checksum;
            - additional option selection (selected);
            - acknowledge time;
            - throughput (selected);
            - residual error rate (selected);
            - priority (selected);
            - transit delay (selected);
            - user data.

          NOTE - The  transport  service  defines  transit  delay   as
          requiring  a  previously stated average TSDU size as a basis
          for any  specification.   This  protocol,  as  specified  in
          13.3.4(n),  uses  a  value of 128 octets.  Conversion to and
          from specifications based upon some other value is  a  local
          matter.




     6.5.4  Procedure

     A transport connection is established by means of  one  transport
     entity  (the  initiator)  transmitting  a  CR  TPDU  to the other
     transport entity (the responder), which replies with a CC TPDU.

     Before sending the CR TPDU, the initiator assigns  the  transport
     connection  being  created  to  one  (or  more  if  the splitting
     procedure is being use) network connection(s).  It is this set of
     network  connections  over which the TPDUs are sent.  During this
     exchange, all information and parameters needed for the transport
     entities to operate shall be exchanged or negotiated.

          NOTE - Except  in  class  4,  it  is  recommended  that  the
          initiator  starts  an  optional timer TS1 at the time the CR
          TPDU is  sent.   This  timer  should  be  stopped  when  the
          connection   is   considered   as  accepted  or  refused  or
          unsuccessful.  If the timer expires,  the  initiator  should

Top       Page 45 
          reset or disconnect the network connection and, in classes 1
          and 3 freeze  the  reference  (see  6.18).   For  all  other
          transport  connection(s)  multiplexed  on  the  same network
          connection  the  procedures  for  reset  or  disconnect   as
          appropriate should be followed.

     After receiving the CC  TPDU  for  a  class  which  includes  the
     procedure  for  retention  until  acknowledgement  of  TPDUs  the
     initiator shall acknowledge the CC TPDU as  defined  in  table  5
     (see 6.13).

     When the network expedited variant of the expedited data transfer
     (see  6.11)  has  been  agreed  (possible  in  class 1 only), the
     responder shall not send  an  ED  TPDU  before  the  CC  TPDU  is
     acknowledged.

     The following information is exchanged:

        a)  references.  Each transport  entity  chooses  a  reference
            which is to be used by the peer entity is 16 bits long and
            which is arbitrary except for the following restrictions:

            1)  it shall not already be in use or frozen (see 6.18),

            2)  it shall not be zero.

            This mechanism is symmetrical and provides  identification
            of  the  transport  connection  independent of the network
            connection.  The range of references  used  for  transport
            connections,  in  a  given  transport  entity,  is a local
            matter.

        b)  addresses (optional).  Indicate  the  calling  and  called
            transport  service  access  points.   When  either network
            address unambiguously defines the transport  address  this
            information may be omitted.

        c)  initial credit.  Only relevant for classes  which  include
            the explicit flow control function.

        d)  user data.  Not available if  Class  0  is  the  preferred
            class (see note).  Up to 32 octets in other classes.

Top       Page 46 
            NOTE - If class 0 is a valid response according  to  table
            3,  inclusion  of  user  data in the CR TPDU may cause the
            responding entity to refuse the  connection  (e.g.  if  it
            only supports class 0).

        e)  acknowledgement time.  Only in class 4.

        f)  checksum parameter.  Only in class 4.

        g)  security parameter.  This parameter and its semantics  are
            user defined.

     The following negotiations take place:

        h)  protocol class.  The initiator shall propose  a  preferred
            class  and  may  propose  any  number of alternative class
            which permit a valid response as defined in table 3.   The
            initiator should assume when it sends the CR TPDU that its
            preferred class  will  be  agreed  to,  and  commence  the
            procedures  associated  with  that  class,  except that if
            class 0 or class 1 is an alternative  class,  multiplexing
            shall  not  commence  until a CC TPDU selecting the use of
            classes 2, 3 or 4 has been received.

            NOTE - This means, for example, that  when  the  preferred
            class    includes   resynchronization   (see   6.14)   the
            resynchronization will  occur  if  a  reset  is  signalled
            during connection establishment.

     The responder shall select one class defined  in  table  3  as  a
     valid  response  corresponding  to the preferred class and to the
     class(es), if any, contained in the alternative  class  parameter
     of  the  CR TPDU.  It shall indicate the selected class in the CC
     TPDU and shall follow the procedures for the selected class.

     If the preferred class is not selected, then on receipt of the CC
     TPDU  the  initiator  shall  adjust  its  operation according the
     procedures of the selected class.

Top       Page 47 
     +------------------------------------------------------------+
     | Pre-  |                Alternative class                   |
     |ferred |----------------------------------------------------|
     |class  |   0    |   1    |   2    |   3    |   4    | none  |
     |-------|--------|--------|--------|--------|--------|-------|
     |   0   |not     |not     |not     |not     |not     |class  |
     |       |valid   |valid   |valid   |valid   |valid   |  0    |
     |-------|--------|--------|--------|--------|--------|-------|
     |   1   |class   |class   |not     |not     |not     |class  |
     |       |1 or 0  |1 or 0  |valid   |valid   |valid   |1 or 0 |
     |-------|--------|--------|--------|--------|--------|-------|
     |   2   |class   |not     |class   |not     |not     |class  |
     |       |2 or 0  |valid   |2       |valid   |valid   |  2    |
     |-------|--------|--------|--------|--------|--------|-------|
     |   3   |class   |class 3,|class   |class   |not     |class  |
     |       |3,2 or 0|2,1 or 0|3 or 2  |3 or 2  |valid   |3 or 2 |
     |-------|--------|--------|--------|--------|--------|-------|
     |   4   |class   |class 4,|class   |class   |class   |class  |
     |       |4,2 or 0|2,1 or 0|4 or 2  |4,3 or 2|4 or 2  |4 or 2 |
     +------------------------------------------------------------+
                                 Table 3.




     Valid responses corresponding to  the  preferred  class  and  any
     alternative class proposed in the CR TPDU


     NOTES:

        1.  The valid responses indicated in table 3 result from  both
            explicit negotiation, whereby each of the classes proposed
            is a valid response, and implicit negotiation whereby:

            a)  if class 3 or 4 is proposed then class 2  is  a  valid
                response;
            b)  if class 1  is  proposed  then  class  0  is  a  valid
                response.

Top       Page 48 
        2.  Negotiation from class 2 to class 1 and from any class  to
            an higher-numbered class is not valid.

        3.  Redundant combinations are not a protocol error.

        j)  TPDU size.  The initiator may propose a maximum  size  for
            TPDUs,  and the responder may accept this value or respond
            with any value between 128 and the proposed value  in  the
            set of values available (see 13.3.4.b).

            NOTE - The length of the  CR  TPDU  does  not  exceed  128
            octets (see 13.3).

        k)  normal or extended format.  Either normal or  extended  is
            available.   When  extended  is  used this applies to CDT,
            TPDU-NR, ED-TPDU-NR, YR-TU-NR and YR-EDTU-NR parameters.

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

        n)  quality  of  service   parameters.    This   defines   the
            throughput,  transit  delay,  priority  and residual error
            rate.

        p)  the non-use of explicit flow control in class 2.

        q)  the  use  of  network  receipt  confirmation  and  network
            expedited when class 1 is to be used.

        r)  use of expedited data transfer service.  This allows  both
            TS-users  to negotiate the use or non-use of the expedited
            data transport service as defined in the transport service
            (ISO 8072).

     The following information is sent only in the CR TPDU:

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

        t)  reassignment time parameter.  This indicates the time  for
            which   the   initiator  will  persist  in  following  the
            reassignment after failure procedure.

Top       Page 49 
     The negotiation rules for the options are such that the initiator
     may  propose  either  to  use  or  not  to  use  the option.  The
     responder may either accept the  proposed  choice  or  select  an
     alternative choice as defined in table 4.

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





     +-------------------------------------------------------------+
     |        Option         |  Proposal Made   | Valid Selection  |
     |                       | by the Initiator | by the Responder |
     |-----------------------|------------------|------------------|
     |Transport expedited    |       Yes        |    Yes or No     |
     |data transfer service  |       No         |        No        |
     |(Classes 1,2,3,4 only) |                  |                  |
     |-----------------------|------------------|------------------|
     |Use of receipt confir- |       Yes        |    Yes or No     |
     |mation (Class 1 only)  |       No         |        No        |
     |-----------------------|------------------|------------------|
     |Use of the network     |       Yes        |    Yes or No     |
     |expedited variant      |       No         |        No        |
     |(Class 1 only)         |                  |                  |
     |-----------------------|------------------|------------------|
     |Non-use of checksum    |       Yes        |    Yes or No     |
     |(Class 4 only)         |       No         |        No        |
     |-----------------------|------------------|------------------|
     |Non-use of explicit    |       Yes        |    Yes or No     |
     |flow control           |       No         |        No        |
     |(Class 2 only)         |                  |                  |
     |-----------------------|------------------|------------------|
     |Use of extended format |       Yes        |    Yes or No     |
     |(Classes 2,3,4 only)   |       No         |        No        |
     +-------------------------------------------------------------+

      Table 4. Negotiation of options during connection establishment

Top       Page 50 
     NOTE - Table 4 defines the procedures for negotiation of options.
     This  negotiation  has  been  designed such that if the initiator
     proposes the mandatory implementation option specified in  clause
     14,  the  responder  has  to  accept  use of this option over the
     transport  connection  except  for  the  use  of  the   transport
     expedited  data transfer service which may be rejected by the TS-
     user.  If the initiator proposes a  non-mandatory  implementation
     option,  the responder is entitled to select use of the mandatory
     implementation option for use over the transport connection.




     6.6  Connection refusal

     6.6.1  Purpose

     The connection refusal procedure is used in all  classes  when  a
     transport  entity refuses a transport connection in response to a
     CR TPDU.




     6.6.2  TPDUs and parameters used

     The procedure makes use of the following TPDUs and parameters:

        a)  DR TPDU;

            - SRC-REF;
            - reason;
            - user data.

        b)  ER TPDU;

            - reject code;
            - rejected TPDU parameter.

Top       Page 51 
     6.6.3  Procedure

     If a transport connection cannot be accepted, the responder shall
     respond to the CR TPDU with a DR TPDU.  The reason shall indicate
     why the connection was not accepted.  The source reference  field
     in  the  DR  TPDU  shall be set to zero to indicate an unassigned
     reference.

     If  a  DR  TPDU  is  received  the  initiator  shall  regard  the
     connection as released.

     The responder shall respond to an invalid CR TPDU by  sending  an
     ER  or  DR  TPDU.   If an ER TPDU is received in response to a CR
     TPDU, the initiator shall regard the connection as released.

     NOTES

     1.  When the invalid CR TPDU can be identified as having class  0
         as  the preferred class, it is recommended to respond with an
         ER TPDU.  For all other invalid CR TPDUs either an ER TPDU or
         DR TPDU may be sent.

     2.  If the optimal supervisory timer TS1 has been  set  for  this
         connection  then  the entity should stop the timer on receipt
         of the DR or ER TPDU.




     6.7  Normal release

     6.7.1  Purpose

     The release procedure is used by a transport entity in  order  to
     terminate  a  transport connection.  The implicit variant is used
     only in class 0.  The explicit variant is used in  classes  1,2,3
     and 4.

Top       Page 52 
     NOTES

     1.  When the implicit variant is used  (i.e.  in  class  0),  the
         lifetime  of  the transport connection is directly correlated
         with the lifetime of the network connection.

     2.  The use of the explicit  variant  of  the  release  procedure
         enables the transport connection to be released independently
         of the underlying network connection.




     6.7.2  Network service primitives

     The  procedure  makes  use  of  the  following  network   service
     primitives:

        a)  N-DISCONNECT (implicit variant only),

        b)  N-DATA




     6.7.3  TPDUs and parameters used

     The procedure makes use of the following TPDUs and parameters:

        a)  DR TPDU;

            - clearing reason;
            - user data;
            - SRC-REF;
            - DST-REF.

        b)  DC TPDU.

Top       Page 53 
     6.7.4  Procedure for implicit variant

     In the implicit variant either  transport  entity  disconnects  a
     transport  connection  by disconnecting the network connection to
     which it is assigned.  When a transport  entity  receives  an  N-
     DISCONNECT  this  should  be  considered  as  the  release of the
     transport connection.




     6.7.5  Procedure for explicit variant

     When the release of a transport connection is to be  initiated  a
     transport entity

        a)  if it has previously sent or received a CC TPDU (see  note
            1),   shall   send   a  DR  TPDU.   It  shall  ignore  all
            subsequently received TPDUs other than a DR  or  DC  TPDU.
            On  receipt  of  a  DR  or  DC  TPDU it shall consider the
            transport connection released;

        b)  in other cases it shall:

            1)  For  classes  other  than  class  4   wait   for   the
                acknowledgement  of  the  outstanding  CR  TPDU; if it
                receives a CC TPDU, it shall follow the procedures  in
                6.7.5.a.


            2)  For class 4 either send a DR TPDU with a zero value in
                the   DST-REF   field   or  follow  the  procedure  in
                6.7.5.b.1.

        A transport entity that receives a DR TPDU shall

        c)  if it has previously sent a DR TPDU for the same transport
            connection, consider the transport connection released;

        d)  if it has previously sent a CR  TPDU  that  has  not  been
            acknowledged by a CC TPDU, consider the connection refused
            (see 6.6).

Top       Page 54 
        e)  in other cases, send a DC TPDU and consider the  transport
            connection released.

        NOTES

        1)  This requirement ensures  that  the  transport  entity  is
            aware   of   the   remote   reference  for  the  transport
            connection.

        2)  When the transport connection is  considered  as  released
            the  local  reference is either available for re-use or is
            frozen (see 6.18).

        3)  After the release of a transport  connection  the  network
            connection  can  be released or retained to enable its re-
            use for the assignment of other transport connections (see
            6.1.).

        4)  Except in class 4, it is recommended that, if a  transport
            entity  does  not  receive  acknowledgement  of  a DR TPDU
            within time TS2, it should either reset or disconnect  the
            network   connection,   and   freeze  the  reference  when
            appropriate  (see  6.18).    For   all   other   transport
            connection(s)  multiplexed  on this network connection the
            procedures for reset or disconnect as  appropriate  should
            be followed.

        5)  When a transport entity is waiting for a  CC  TPDU  before
            sending  a  DR TPDU and the network connection is reset or
            released, it  should  consider  the  transport  connection
            released  and,  in  classes  other  than  classes 0 and 2,
            freeze the reference (see 6.18).




     6.8  Error Release

Top       Page 55 
     6.8.1  Purpose

     This procedure is used only in classes  0  and  2  to  release  a
     transport connection on the receipt of an N-DISCONNECT or N-RESET
     indication.




     6.8.2  Network service primitives

     The procedure makes use of the following service primitives:

        a)  N-DISCONNECT indication;

        b)  N-RESET indication.




     6.8.3  Procedure

     When, on the network connection to which a  transport  connection
     is  assigned,  an N-DISCONNECT or N-RESET indication is received,
     both  transport  entities  shall  consider  that  the   transport
     connection is released and so inform the TS-users.

     NOTE - In other  classes,  since  error  recovery  is  used,  the
     receipt  of an N-RESET indication or N-DISCONNECT indication will
     result in the invocation of the error recovery procedure.




     6.9  Association of TPDUs with transport connections

     6.9.1  Purpose

     This procedure is used in all classes  to  interpret  a  received
     NSDU  as  TPDU(s)  and,  if possible, to associate each such TPDU
     with a transport connection.

Top       Page 56 
     6.9.2  Network service primitives

     This  procedure  makes  use  of  the  following  network  service
     primitives:

        a)  N-DATA indication;

        b)  N-EXPEDITED DATA indication.





     6.9.3  TPDUs and parameters uses

     This procedure makes use of the following TPDUs and parameters:

        a)  any TPDU except CR TPDU, DT TPDU in classes 0 or 1 and  AK
            TPDU in class 1;

            - DST-REF

        b)  CR, CC, DR and DC TPDUs;

            - SCR-REF.

        c)  DT TPDU in classes 0 or 1 and AK TPDU in class 1.




     6.9.4  Procedures

     6.9.4.1  Identification of TPDUs

     If the received NSDU or Expedited NSDU cannot  be  decoded  (i.e.
     does not contain one or more correct TPDUs) or is corrupted (i.e.
     contains a TPDU with a wrong checksum) then the transport  entity
     shall:

Top       Page 57 
        a)  if the network connection on which the error  is  detected
            has  a class 0 or class 1 transport connection assigned to
            it, then treat as a protocol error  (see  6.22)  for  that
            transport connection;

        b)  otherwise

            1)  if the NSDU can  be  decoded  but  contains  corrupted
                TPDUs,  ignore the TPDUs (class 4 only) and optionally
                apply 6.9.4.b.2.

            2)  if the NSDU cannot be decoded issue an N-RESET  or  N-
                DISCONNECT  request for the network connection and for
                all the transport connections assigned to this network
                connection  (if any), apply the procedures defined for
                handling of network signalled reset or disconnect.

            If the NSDU can be  decoded  and  is  not  corrupted,  the
            transport entity shall:

        c)  if the network connection on which the NSDU  was  received
            has  a  class  0 transport connection assigned to it, then
            consider the NSDU as forming TPDU and associate  the  TPDU
            with the transport connection (see 6.9.4.2).

        d)  otherwise, invoke the separation procedures and  for  each
            of  the individual TPDUs in the order in which they appear
            in the NSDU apply the procedure defined in 6.9.4.2.




     6.9.4.2  Association of individual TPDUs

     If the received TPDU is a CR TPDU then, if it is a duplicate,  as
     recognized  by using the NSAPs of the network connection, and the
     SRC-REF parameter, then  it  is  associated  with  the  transport
     connection  created  by  the  original  value  of  the  CR  TPDU;
     otherwise it is processed as requesting the  creation  of  a  new
     transport connection.

     If the received TPDU is a DT TPDU and the network connection  has
     a class 0 or 1 transport connection assigned to it, or an AK TPDU

Top       Page 58 
     where a class 1 transport connection is assigned, then  the  TPDU
     is associated with the transport connection.

     Otherwise, the DST-REF parameter of the TPDU is used to  identify
     the transport connection.  The following cases are distinguished:

        a)  if the DST-REF is not allocated to a transport connection,
            the  transport  entity  shall  respond on the same network
            connection with a DR TPDU if the TPDU is a CC TPDU, with a
            DC TPDU if the TPDU is a DR TPDU and shall ignore the TPDU
            if neither a DR TPDU nor CC TPDU.  No association  with  a
            transport connection is made.

        b)  if the DST-REF is allocated to a connection, but the  TPDU
            is   received   on  a  network  connection  to  which  the
            connection has not been  assigned  then  there  are  three
            cases:

            1)  if the transport connection is of class 4 and  if  the
                TPDU is received on a network connection with the same
                pair of NSAPs as that of the CR TPDU then the TPDU  is
                considered as performing assignment,

            2)  if the transport connection is  not  assigned  to  any
                network  connection  (waiting  for  reassignment after
                failure) and if the TPDU  is  received  on  a  network
                connection  with the same pair of NSAPs as that of the
                CR TPDU  then  the  association  with  that  transport
                connection is made.

            3)  Otherwise, the TPDU is considered as having a  DST-REF
                not allocated to a transport connection (case a).

        c)  If the TPDU is a DC TPDU then it is  associated  with  the
            transport  connection  to  which the DST-REF is allocated,
            unless the SRC-REF is not the expected one, in which  case
            the DC TPDU is ignored.

        d)  If the TPDU is a DR TPDU then there are three cases:

            1)  if the SRC-REF is not as expected then a DC TPDU  with
                DST-REF  equal  to the SRC-REF of the received DR TPDU
                is sent back and no association is made;

Top       Page 59 
            2)  if a CR TPDU is unacknowledged then  the  DR  TPDU  is
                associated  with  the transport connection, regardless
                of the value of its SRC-REF parameter;

            3)  otherwise,  the  DR  TPDU  is  associated   with   the
                transport   connection   identified   by  the  DST-REF
                parameter.

        e)  if  the  TPDU  is  a  CC  TPDU  whose  DST-REF   parameter
            identifies an open connection (one for which a CC TPDU has
            been previously received), and the SRC-REF in the CC  TPDU
            does  not  match  the  remote reference, then a DR TPDU is
            sent back  with  DST-REF  equal  to  the  SRC-REF  of  the
            received CC TPDU and no association is made.

        f)  if none  of  the  above  cases  apply  then  the  TPDU  is
            associated with the transport connection identified by the
            DST-REF parameter.




     6.10  Data TPDU numbering

     6.10.1  Purpose

     Data TPDU numbering is used in classes  1,  2  (except  when  the
     non-use  of  explicit  flow control option is selected), 3 and 4.
     Its purpose is to enable the use of recovery,  flow  control  and
     re-sequencing functions.




     6.10.2  TPDUs and parameters used

     The procedure makes use of the following TPDU and parameter:

        DT TPDU;

        - TPDU-NR.

Top       Page 60 
     6.10.3  Procedure

     A Transport entity shall allocate the sequence number zero to the
     TPDU-NR  of  the first DT TPDU which it transmits for a transport
     connection.  For subsequent DT TPDUs sent on the  same  transport
     connection, the transport entity shall allocate a sequence number
     one greater than the previous one.

     When a DT TPDU is retransmitted, the TPDU-NR parameter shall have
     the same value as in the first transmission of that DT TPDU.

     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.   In  this  International
     Standard  the  relationships 'greater than' and 'less than' apply
     to a set of contiguous TPDU numbers whose range is less than  the
     modulus  and whose starting and finishing numbers are known.  The
     term 'less than' means 'occurring sooner in the window  sequence'
     and  the term 'greater than' means 'occurring later in the window
     sequence'.




     6.11  Expedited data transfer

     6.11.1  Purpose

     Expedited data transfer procedures are selected during connection
     establishment.   The  network  normal data variant may be used in
     classes 1, 2, 3 and 4.  The network  expedited  variant  is  only
     used in class 1.




     6.11.2  Network service primitives

     The  procedure  makes  use  of  the  following  network   service
     primitives:

        a)  N-DATA;

Top       Page 61 
        b)  N-EXPEDITED DATA.




     6.11.3  TPDUs and parameter used

     The procedure makes use of the following TPDUs and parameters:

        a)  ED TPDU;

            - ED TPDU-NR.

        b)  EA TPDU;

            - YR-EDTU-NR.




     6.11.4  Procedures

     The TS-user data parameter of each T-EXPEDITED DATA request shall
     be conveyed as the data field of an Expedited Data (ED) TPDU.

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

     No more than one ED TPDU shall remain unacknowledged at any  time
     for each direction of a transport connection.

     An ED TPDU with a zero length data field is a protocol error.

Top       Page 62 
     NOTES

        1.  The network normal data variant is used, except  when  the
            network expedited variant (available in Class 1 only), has
            been agreed, in which case ED and EA TPDUs are conveyed in
            the  data  fields  of  N-EXPEDITED  DATA  primitives  (see
            6.2.3).

        2.  No TPDUs can be transmitted using network expedited  until
            the  CC  TPDU becomes acknowledged, to prevent the network
            expedited from overtaking the CC TPDU.




     6.12  Reassignment after failure

     6.12.1  Purpose

     The reassignment after failure procedure is used in Classes 1 and
     3 to commence recovery from an NS-provider signalled disconnect.




     6.12.2  Network service primitives

     The procedure uses the following network service primitive:

          N-DISCONNECT indication




     6.12.3  Procedure

     When an N-DISCONNECT indication  is  received  from  the  network
     connection  to  which  a  transport  connection  is assigned, the
     initiator shall apply one of the following alternatives:

        a)  if the TTR timer has not already run out and no DR TPDU is
            retained then:

Top       Page 63 
            1)  assign the transport connection to a different network
                connection  (see  6.1)  and start its TTR timer if not
                already started.

            2)  while waiting for the completion of assignment if:

                - an N-DISCONNECT indication is received,  repeat  the
                  procedure from 6.12.3.a,

                - the TTR timer expires, begin procedure 6.12.3.b.

            3)  when     reassignment     is     completed,      begin
                resynchronization (see 6.14) and:

                - if a valid TPDU is received as  the  result  of  the
                  resynchronization, stop the TTR timer, or

                - if TTR runs out, wait for the next event, or

                - if an  N-DISCONNECT  indication  is  received,  then
                  begin   either   procedure   6.12.3.a   or  6.12.3.b
                  depending on the TTR timer.

            NOTE - After the TTR timer expires and while  waiting  for
            the  next  event,  it  is  recommended  that the initiator
            starts the TWR timer.  If the TWR timer expires before the
            next  event  the  initiator  should begin the procedure in
            6.12.3.b.

        b)  if the TTR timer  has  run  out,  consider  the  transport
            connection  as  released  and  freeze  the  reference (see
            6.18).

        c)   if a DR TPDU is retained and the TTR timer  has  not  run
            out,  then  follow  the  actions  in  either  6.12.3.a  or
            6.12.3.b.

     The responder shall start its TWR timer if not  already  started.
     The arrival of the first TPDU related to the transport connection
     (because of resynchronization by  the  initiator)  completes  the
     reassignment  after  failure procedure.  The TWR timer is stopped
     and the responder  shall  continue  with  resynchronization  (see
     6.14).  If reassignment does not take place within this time, the

Top       Page 64 
     transport connection is considered released and the reference  is
     frozen (see 6.18).




     6.12.4  Timers

     The reassignment after failure procedure uses two timers:

        a)  TTR, the time to try reassignment/resynchronization timer;

        b)  TWR, the time to wait  for  reassignment/resynchronization
            timer.

     The TTR timer is used by the  initiator.   Its  value  shall  not
     exceed  two  minutes  minus  the  sum  of  the maximum disconnect
     propagation  delay  and  the  transit  delay   of   the   network
     connections  (see  note  1).   The value for the TTR timer may be
     indicated in the CR TPDU.

     The TWR timer is used by the responder.  If the reassignment time
     parameter is present in the CR TPDU, the TWR timer value shall be
     greater than the sum of the TTR timer plus the maximum disconnect
     propagation   delay   plus  the  transit  delay  of  the  network
     connections.

     If the reassignment time parameter is not present in the CR TPDU,
     a default value of 2 minutes shall be used for the TWR timer.

     NOTES

     1.  Provided that the required quality of service is met, TTR may
         be  set  to zero (i.e. no assignment).  This may be done, for
         example, if the rate of NS-provider generated disconnects  is
         very low.

     2.  Inclusion of the reassignment time parameter in the  CR  TPDU
         allows  the  responder  to  use  a  TWR  value of less than 2
         minutes.

     3.  If  the  optional  TS1  and  TS2  timers  are  used,  it   is
         recommended:

Top       Page 65 
            a)  to stop TS1 or TS2 if  running  when  TTR  or  TWR  is
                started;

            b)  to  restart  TS1  or  TS2  if   necessary   when   the
                corresponding TPDU (CR TPDU or DR TPDU respectively is
                repeated);

            c)  to select for TS1 and TS2 values greater than TTR.

Top       Page 66 
     6.13  Retention until acknowledgement of TPDUs

     6.13.1  Purpose

     The retention until acknowledgement of TPDUs procedure is used in
     classes  1,  3  and 4 to enable and minimize retransmission after
     possible loss of TPDUs.

     The confirmation of receipt variant is used only in Class 1  when
     it has been agreed during connection establishment (see note).

     The AK variant is used in classes 3 and 4 and  also  in  Class  1
     when  the  confirmation  of  receipt  variant has not been agreed
     during connection establishment.

     NOTE - Use of confirmation of  receipt  variant  depends  on  the
     availability  of  the  network layer receipt confirmation service
     and the expected cost reduction.




     6.13.2  Network service primitives

     The procedure uses the following network service primitives:

        a)  N-DATA;

        b)  N-DATA ACKNOWLEDGE.




     6.13.3  TPDUs and parameters used

     The procedure uses the following TPDUs and parameters:

        a)  CR, CC, DR and DC TPDUs;

        b)  RJ and AK TPDUs;

            - YR-TU-NR.

Top       Page 67 
        c)  DT TPDU;

            - TPDU-NR.

        d)  ED TPDU;

            - ED-TPDU-NR.

        e)  EA TPDU;

            - YR-EDTU-NR.




     6.13.4  Procedures

     Copies of the following TPDUs shall be retained upon transmission
     to permit their later retransmission:

        CR, CC, DR, DT and ED TPDUs

     except that if a DR is sent in response to a CR TPDU there is  no
     need to retain a copy of the DR TPDU.

     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
     an N-DATA ACKNOWLEDGE request (see notes 1 and 2).

     After each TPDU is acknowledged, as shown in table  5,  the  copy
     need  not  be  retained.   Copies  may also be discarded when the
     transport connection is released.

Top       Page 68 
     NOTES

        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.

        2.  Use of the confirmation request parameter may  affect  the
            quality of network service.

Top       Page 69 
     +-------------------------------------------------------------+
     |RETAINED|              |                                     |
     |  TPDU  |   VARIANT    |    RETAINED UNTIL ACKNOWLEDGED BY   |
     |--------|--------------|-------------------------------------|
     |   CR   | both         |CC, DR or ER TPDU.                   |
     |        |              |                                     |
     |   DR   | both         |DC or DR (in case of collision) TPDU.|
     |        |              |                                     |
     |   CC   | confirmation |N-DATA Acknowledge indication, RJ,   |
     |        | of receipt   |DT, EA or ED TPDU.                   |
     |        | variant      |                                     |
     |        |              |                                     |
     |   CC   | AK variant   |RJ, DT, AK, ED or EA TPDU.           |
     |        |              |                                     |
     |   DT   | confirmation |N-DATA ACKNOWLEDGE indication cor-   |
     |        | of receipt   |responding to an N-DATA request which|
     |        | variant      |conveyed, or came after, the DT TPDU.|
     |        |              |                                     |
     |   DT   | AK variant   |AK or RJ TPDU for which the YR-TU-NR |
     |        |              |is greater than TPDU-NR in the DT    |
     |        |              |TPDU.                                |
     |        |              |                                     |
     |   ED   | both         |EA TPDU for which the YR-EDTU-NR is  |
     |        |              |equal to the ED-TPDU-NR in the       |
     |        |              |ED TPDU.                             |
     +-------------------------------------------------------------+

                     Table 5. Acknowledgement of TPDUs


Next RFC Part