[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 04                                                   
INTERNET-DRAFT                                               D. Y. KIM
draft-kim-jtc1-sc6-ects-04.txt                          Chungnam Univ.
                                                          30 Jun. 1998
                                                   Expires: 12/31/1998




          Enhanced Communications Transport Service Definition




Status of this Memo

  document is an Internet-Draft.  Internet-Drafts are working documents
  of the Internet Engineering Task Force (IETF), its areas, and its
  working groups.  Note that other groups may also distribute working
  documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  To learn the current status of any Internet-Draft, please check the
  "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  ftp.isi.edu (US West Coast).

Abstract

  This memo is the final Committee Draft of the Enhanced Transport
  Service Definition under development within ISO/IEC JTC1/SC6/WG7 since
  last several years in order to provide to the upper-layer applications
  enhanced transport services over the current OSI transport service;
  major enhancements include multicast services and enhanced QoS.

  This memo is distributed to possibly interested grops within IETF,
  especially to experts in Transport Area, to make noticed the efforts
  being made within SC6 to come up with a new transport service
  definition meeting the wide range of requirements of the both current
  and future multimedia multicast applications. It is to be noted that a
  protocol maned ECTP(Enhanced Communications Transport Protocol)
  supporting this ECTS is also under development within SC6 and will be
  made public in the near future.

  Experts interested in this topic might compare the services defined by
  ECTS with those provided by more known protocols including RTP, MTP,
  RMP, and RAMP. The ultimate apparent objective of ECTS is the
  multimedia multicast transport service with varying degrees of




Dae Young Kim               Expires 12/31/98                    [Page 1]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988

CONTENTS

Introduction...........................................................3

1       Scope..........................................................3

2       Normative references...........................................5

3       Definitions....................................................5

4       Abbreviations..................................................9

5       Conventions....................................................9

6       Overview and general characteristics..........................10

7       Features of the Enhanced Communication Transport Service......11

8       Model of the Enhanced Communications Transport Service........12

9       Transport Connection characteristics..........................15

10      Quality-of-Service (QoS) for Transport Connections............17

11      Enhanced Communications Transport Service Primitives and
        Parameters....................................................32

12      TC Creation service...........................................36

13      TC Invitation service.........................................45

14      TC Join service...............................................48

15      Data Transfer service.........................................52

16      Pause service.................................................54

17      Resume service................................................56

18      Report service................................................57

19      TC Leave service..............................................58

20      TC Termination service........................................63

21      TC-ownership service..........................................69

22      Token service.................................................72

Annex A...............................................................78

Annex B...............................................................81

Dae Young Kim               Expires 12/31/98                    [Page 2]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


Introduction

  This Recommendation | International Standard defines a transport
  service, named ECTS (Enhanced Communications Transport Service), which
  provides for a multicast capability and enhanced quality of service
  (QoS). ECTS defines a wide range of services ranging from unreliable
  unicast with best-effort QoS to reliable multicast with guaranteed
  QoS. In this way, ECTS is meant to provide for a uniform and universal
  service interface between transport protocols and applications of the
  present and the future information age, especially for those
  applications requiring versatile and powerful multimedia group
  communication capabilities underneath..

                                                    Apps = Applications

  +----------+ +---------------+ +---+  +------------+       +--------+
  |T.120 Apps| |Other Group    | |VOD|  |Conventional|       |New Apps|
  |          | |Multimedia Apps| |   |  | Apps       |  .... |        |
  +----------+ +---------------+ +---+  +------------+       +--------+
       ^               ^           ^          ^                   ^
       |               |           |          |                   |
       |               |           |          |                   |
       V               V           V          V                   V
  +-------------------------------------------------------------------+
  |                             ECTS                                  |
  +-------------------------------------------------------------------+
     ^     ^     ^      ^      ^      ^       ^       ^            ^
     |     |     |      |      |      |       |       |            |
     |     |     |      |      |      |       |       |            |
     V     V     V      V      V      V       V       V            V
  +----+ +---+ +---+  +---+  +---+  +---+  +----+  +----+      +------+
  |ECTP| |TCP| |UDP|  |MTP|  |SRM|  |RTP|  |COTP|  |CLTP| .... |Others|
  +----+ +---+ +---+  +---+  +---+  +---+  +----+  +----+      +------+
   ^  ^    ^     ^      ^      ^      ^       ^       ^           ^  ^
   |  |    |     |      |      |      |       |       |           |  |
   |  |    |     |      |      |      |       |       |           |  |
   |  V    V     V      V      V      V       V       V           V  |
   | +-------------------------------------------------------------+ |
   | |                 IPv4/IPv6 + RSVP,    CLNP                   | |
   | +-------------------------------------------------------------+ |
   |                               ^                                 |
   |                               |                                 |
   |                               |                                 |
   V                               V                                 V
  +-------------------------------------------------------------------+
  |      PSDN, PSTN, ISDN, FR, ATM, LAN, ......... Other Networks     |
  +-------------------------------------------------------------------+


              Figure 1 - Architectural block diagram for ECTS

Dae Young Kim               Expires 12/31/98                    [Page 3]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988




  Figure 1 depicts the general architectural block diagram showing how
  ECTS relates to other protocols in the transport, application as well
  as network layers.

  ECTP in Figure 1 is a protocol which is supposed to support all the
  services defined by ECTS. ECTP is (to be) defined in a separate
  Recommendation | International Standard.  Note that not all the
  transport protocols shown in Figure 1 support all the services defined
  by ECTS. For example, TCP provides a best-effort reliable unicast
  service; UDP supports a best-effort unreliable multicast service. MTP,
  RMP, and SRM support reliable multicast but with null QoS. RTP
  provides means for exchanging synchronization information but does not
  define mechanisms to provide the synchronization itself.

  ECTP, a companion protocol to ECTS, further will utilize, wherever
  possible, the multicast capabilities of the underlying  network
  infrastructures. For example, in operation in Internet, ECTP will make
  extensive use of the multicast capabilities of IPv4 and IPv6 and rely
  on RSVP for QoS provisioning by network resource reservation. As
  another example, in operation over intrinsic ATM networks, ECTP will
  rely on the ATM capabilities for both multicast and QoS.

1 Scope

  This Recommendation | International Standard defines in an abstract
  way the externally visible service provided by the  Transport Layer in
  terms of:

    a) the primitive actions and events of the service;

    b) the parameter data associated with each primitive action and
       event;

    c) the relationship between, and the valid sequences of, these
       actions and events.

  The service defined in this Recommendation | International Standard is
  that which is provided by the Enhanced   Communications Transport
  Protocol (in conjunction with the Network  Service) and which may be
  used by any application protocol.. The service can also be provided by
  other protocols possibly each supporting a subset of the services
  defined herein.

  The primitives specified in this Recommendation | International
  Standard support a connection-mode service and a connectionless
  service. In some cases of connectionless-mode service supporting



Dae Young Kim               Expires 12/31/98                    [Page 4]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  enhanced communications, certain operations may also be necessary
  prior to the commencement of data  transfer, e.g., agreement on
  quality of service.

  For the data transfer phase of either connection-mode or
  connectionless-mode services, there may be a range of data-ordering
  characteristics.

  No implication is made in this Recommendation | International Standard
  regarding the inclusion or exclusion of any of the above
  characteristics given the service primitives specified herein.

2 Normative references

  The following Recommendations and International Standards contain
  provisions which, through reference in this text,   constitute
  provisions of this Recommendation | International Standard. At the
  time of publication, the editions indicated were valid. All
  Recommendations and Standards are subject to revision, and parties to
  agreements based on this   Recommendation | International Standard are
  encouraged to investigate the possibility of applying the most recent
  edition of the Recommendations and International Standards listed
  below. Members of IEC and ISO maintain registers of currently valid
  International Standards. The Telecommunication Standardization Bureau
  of the ITU maintains a list of currently valid ITU-T Recommendations.

2.1 Identical Recommendations | International Standards

  - ITU-T Rec. X.200 (1994) | ISO/IEC 7498-1: 1994, Information
    technology - Open Systems
    Interconnection - Basic Reference Model - the Basic Model.

  - ITU-T Rec. X.210 (1993) | ISO/IEC 10731: 1994, Information
    technology - Open Systems Interconnection - Basic Reference Model
    - Conventions for the definition of OSI services.

  - ITU-T Rec. X.214 (1995) | ISO/IEC 8072: 1996, Information
    technology - Open Systems Interconnection

  - Transport service definition.

  - ITU-T Rec. X.641 | ISO/IEC 13236: Information technology - Quality
    of Service - Framework

3 Definitions

  For the purposes of this Recommendation | International Standard, the
  following definitions apply.



Dae Young Kim               Expires 12/31/98                    [Page 5]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


3.1 Reference Model definitions

  This service definition is based on the concepts developed in the OSI
  Basic Reference Model (ITU-T Rec. X.200 |   ISO/IEC 7498-1), and makes
  use of the following terms defined in it:

    a) Transport Layer;

    b) Transport Service;

    c) transport-service-access-point;

    d) transport-service-access-point address;

    e) transport-service-data-unit;

    f) Network Layer;

    g) Network Service.

3.2 Service definition conventions

  This service definition also make use of the following terms defined
  in ITU-T Rec. X.210 | ISO/IEC 10731, as they apply to the Transport
  Layer:

    a) service-user;

    b) service-provider;

    c) primitive;

    d) request;

    e) indication;

    f) response;

    g) confirm.

3.3 Quality-of-Service Framework definitions

  This service definition is compliant with the QoS Framework (ITU-T
  Recommendation X.641 | ISO/IEC 13236) in that it describes facilities
  which pertain to the Transport Layer as specified in the relevant
  clause of the QoS Framework.

    a) QoS characteristic;



Dae Young Kim               Expires 12/31/98                    [Page 6]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


    b) QoS mechanism;

    c) QoS parameter.

3.4 Enhanced Communications Transport Service definitions

  For the purpose of this Recommendation | International Standard, the
  following definitions also apply:

    a) Transport Connection: A multicast connection established among
       TS-users for the purpose of transferring data. In the case where
       there are only two participants involved, it reduces to a
       peer-to-peer connection.

    b) Enrolled group: A group of TS-users who can participate in a
       transport connection, which is identified with a group TSAP
       address.

    c) Group TSAP address: A TSAP address which maps to a set of
       individual TSAP addresses of the enrolled group members.
       Note that, in general, a TSAP address may be a unicast- or group-
       address.

    d) Active group: A group of Transport Service users which maintain
       the shared state information required to support the mechanisms
       of the data transfer phase.

    e) Active group integrity: A set of conditions concerning the active
       group which must be true in order for a transport connection to
       enter or remain in the transfer state of the data transfer phase.

    f) QoS level of agreement: The level of agreement reached during the
       QoS negotiation between users and the provider. It may be
       best-effort or guaranteed.

    g) Ordering: Ordering is concerned with the following two aspects:

        i)  In the case of a single sender, ordering if needed ensures
            that the data units generated by the sender are delivered
            to each receiver in the active group in the same order as
            they were sent;

        ii) In the case of multiple senders, ordering determines the
            relative sequencing of data received from multiple senders.
            The ordering relationship defines the arrangement or
            interleaving of data from the multiple senders.




Dae Young Kim               Expires 12/31/98                    [Page 7]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


            The ordering relationship can be: no, local, partial, causal
            ,or total.

            NOTE - When there are only two participants in the active
                   group, local ordering, causal ordering, and total
                   ordering are the same.

    h) TC-participant: A TS-user that is a member of the active group
       participating in a transport connection.

    i) TC-owner: A TS-user that owns the right to invite, monitor, and
       terminate a transport connection.

    j) Focal TS-user: A TS-user that intends to transmit on a TC and
       initiates the QoS negotiation of the 1xN transport channel
       relating to the data it transmits and the reception of that data
       by other TS-users.

    k) Sending TS-user: A TS-user that is a member of the active group
       participating in a transport connection and submits data to the
       Transport Service provider during the data transfer phase.

    l) Receiving TS-user: A TS-user that is a member of the active group
       participating in a transport connection and receives data from
       the Transport Service provider during the data transfer phase.

    m) Transmit diversity

        i)  Homogeneous: condition wherein all TS-users have agreed to a
            common set of transmit QoS values and so all sending
            TS-users transmit data at the same rate.

        ii) Heterogeneous: condition wherein different sending TS-users
            may transmit data at different rates.

    n) Receive diversity

        i)  Receivers-wide: condition wherein all receiving TS-users
            receive the data of a given sending TS-user at the same QoS
            value.

        ii) Receiver-selected: condition wherein different receivers may
            receive the data of the same sending TS-user at different
            QoS values not better than the transmit QoS. It is out of
            the scope of this document how it can be made possible,
            through some facilities and mechanisms within the
            TS-provider, that data of a given QoS may be delivered at
            different QoS values.




Dae Young Kim               Expires 12/31/98                    [Page 8]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


    o) Transmit concurrency

        i)  Controlled: condition wherein only senders with a token may
            transmit data. The maximum number of such senders is
            specified by Ntok.

        ii) Uncontrolled: condition wherein all senders may transmit
            data concurrently.

    p) Channel: A 1xN simplex data flow within a transport connection.

4 Abbreviations

  AGI      Active group integrity

  CHQ      Controlled highest quality

  ECTS     Enhanced Communications Transport Service

  ECTP     Enhanced Communications Transport Protocol

  LQA      Lowest quality acceptable

  NSAP     Network-service-access-point

  OA       Owner arbitration

  OSIE     Open Systems Interconnection Environment

  OT       Operating target

  QoS      Quality of service

  SWA      Step-wise arbitration

  TC       Transport Connection

  TS       Transport Service

  TSAP     Transport-service-access-point

  TSDU     Transport-service-data-unit

  TPDU     Transport-protocol-data-unit

5 Conventions

5.1 General conventions



Dae Young Kim               Expires 12/31/98                    [Page 9]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  This service definition uses the descriptive conventions given in ITU-
  T Rec. X.210 | ISO/IEC 10731.

5.2 Parameters

  The available parameters for each group of primitives are set out in
  tables in clauses 12 to 22. Each 'X' in the tables indicates that the
  primitive labeling the column in which it falls may carry the
  parameter labeling the row in which it falls.

  Some entries are further qualified by items in brackets. These may be:

    a) indications that the parameter is optional in some way:

        (U) indicating that the inclusion of the parameter is a choice
            made by the user;

    b) parameter specific constraints:

        (=) indicating that the value supplied in an indication or
            confirmation primitive is always identical to that
            supplied in the respective previous request or response
            primitive issued at the peer service access point.

5.3 Notations

  The following notations are used in this document to denote some
  numerical quantities:

    a) Nmax: the maximum number of members that can be allowed in the
       active group.

    b) Nact: the actual number of members in the active group.

    c) Ntok: the maximum number of members that can transmit data
       concurrently.

6 Overview and general characteristics

  The Transport Service provides for the transparent transfer of data
  among TS-users. It relieves the TS-users from any concern about the
  detailed way in which supporting communications media are utilized to
  achieve this transfer.

  The Transport Service provides for the following:

    a) QoS selection:




Dae Young Kim               Expires 12/31/98                   [Page 10]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


       The Transport Layer is required to optimize the use of
       available communications resources to provide the QoS required
       by communicating TS-users at the minimum cost. QoS requirements
       are specified through the selection of values for QoS
       parameters.

    b) Independence of underlying communications resources:

       The Transport Service hides from TS-users the difference in the
       QoS provided by the Network Service. This difference in QoS
       arises from the use of a variety of communications media by the
       Network Layer to provide the Network Service.

    c) End-to-end significance:

       The Transport Service provides for the transfer of data among
       TS-users in end systems.

    d) Transparency of transferred information:

       The Transport Service provides for the transparent transfer of
       octet-aligned TS-user data and/or control information. It does
       neither restrict the content, format, or coding of the
       information, nor does it ever need to interpret its structure
       or meaning.

    e) TS-user addressing:

       The Transport Service utilizes a system of addressing which is
       mapped into the addressing scheme of the supporting Network
       Service. Transport addresses can be used by TS-users to refer
       unambiguously to TSAPs.

    f) AGI monitor:

       The Transport Layer may be required to monitor the AGI of
       TS-users participating in the active transport connection. AGI
       is specified through the selection of values for AGI
       parameters.

7 Features of the Enhanced Communications Transport Service

  ECTS provides the following features to the TS-user:

    a) The means for a TC-owner to create a TC with other TS-users of
       the same enrolled group for the purpose of exchanging TSDUs.
       Only one TC may exist among the TS-users of a given enrolled
       group. Some QoS agreements may have been determined during



Dae Young Kim               Expires 12/31/98                   [Page 11]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


       enrollment. Refinement of some of these QoS agreements may
       occur during the create operation and others may be initially
       determined at that time.

    b) The means for a TS-user to join an existing TC under the
       constraints of QoS, AGI, and other control conditions. Further
       QoS refinements may be made as part of the join operation.

    c) The means of transferring TSDUs on a TC under the constraints
       imposed by QoS. The transfer of TSDUs is transparent, in that
       the boundaries of TSDUs and the contents of TSDUs are preserved
       unchanged by the Transport Service and that there are no
       constraints on the TSDU content imposed by the Transport
       Service. It may or may not be known whether any or all of the
       potential receivers receive the TSDUs.

    d) The means of transferring TSDUs with no QoS imposed except,
       optionally, transit delay. The transfer of TSDUs is
       transparent, in that no constraints on the TSDU content are
       imposed by ECTS and the contents of TSDUs are preserved
       unchanged by ECTS. It may not be known whether any or all of
       the potential receivers receive the TSDUs.

    e) The means for a TS-user to leave a TC unconditionally and/or
       under the constraints of AGI and QoS.

    f) The means for a TC-owner unconditionally and therefore
       destructively to terminate a TC.

8 Model of the Enhanced Communications Transport Service

8.1 Types of Transport Connection

  Figure 2 gives the three types of TC considered in ECTS. They are:

















Dae Young Kim               Expires 12/31/98                   [Page 12]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


                      O                      O                      O
                      ^                      ^                      ^
                     /                    / /                      /
                    /                    / /                      /
                   /                    V /                      /
                  /          <---------- /                      V
     O----------->         O------------>          O<---------->
                  \          <---------- \                      ^
                   \                    ^ \                      \
                    \                    \ \                      \
                     \                    \ \                      \
                      V                      V                      V
                      O                      O                      O

       (a) Simplex TC       (b) Duplex TC            (c) N-plex TC


                  Figure 2 - Types of Transport Connections

    a) simplex TC, wherein one TC-participant, called TC-owner, is send
       only and all others are receive only;

    b) duplex TC, wherein one TC-participant, called TC-owner, can both
       send to and receive from all others whereas all other
       TC-participants can receive only from and send only to the
       TC-owner. Hence, send/receive among the TC-participants other
       than the TC-owner is   not possible;

    c) N-plex TC, wherein any TC-participant is a sender as well as a
       receiver. At any moment, anyone can send something, and, if
       someone does so, all others may receive it.

  The three basic types of TC defined here are thought to cover all the
  other types as degenerate cases. For example, a unicast simplex TC is
  a degenerate case of the simplex TC. A unicast duplex (peer-to-peer)
  TC is a degenerate case of the N-plex TC. An MxN TC wherein M of the
  total N members are send-and-receive participants while the rest are
  receive-only can be modeled as a degenerate of the N-plex TC; some
  members may announce their intention not to send any data as part of
  QoS negotiation.

8.2 Model of Transport Connection

  An enrolled group may be involved in only one TC. Figure 3 gives an
  example of a TC for an enrolled group.

  In this example, the enrolled group consists of six TS-users A to F.
  The group is identified by a group TSAP address pointing to the TSAPs



Dae Young Kim               Expires 12/31/98                   [Page 13]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  of the group members A to F.

                   TS-user B               TS-user C
                  +---------+             +---------+
                  |         |             |         |
                  +---------+             +---------+
                       ^                       ^          TS-user D
  TS-user A             \                     /             +--+
    +--+                 \                   /              |  |
    |  |                  \                 /               |  |
    |  |                   \               /                |  |
    |  |                    \             /                 |  |
    |  |                     \           /                  |  |
    |  |                      \         /                   |  |
    |  |                       \       /                    +--+
    |  |                        \     /
    |  |                         \   /
    |  |                          \ /
    |  |<---------------------------
    |  |                            \
    |  |                  TC         \
    +--+                              \
                                       \
                                        \
                                         \
                                          V
               +-----------+       +------------+
               |           |       |            |
               +-----------+       +------------+
                 TS-user F           TS-user E


                   +-----+
                   |     |  TSAP(Transport Service Access Point)
                   +-----+

                       TC   Transport Connection (TC)

             Figure 3 - An example of a TC for an enrolled group

  In the example, TS-users A, B, C, and E are involved in a simplex TC,
  wherein A is the owner; they are said to form the active group for TC.
  TS-users D and F are not involved in any TC.

  The TC is identified by the group TSAP address which is unique within
  the scope of OSIE. Each terminal of a TC is identified by the TSAP
  address of the TS-user participating in the active group.




Dae Young Kim               Expires 12/31/98                   [Page 14]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


9 Transport Connection characteristics

  The TC characteristics consist of AGI and QoS. While QoS may be
  changed through negotiation in TC establishments, AGI is a predefined
  requisite for a TC and is not for negotiation.  Therefore, AGI may be
  irrelevant for some primitives, i.e., response and confirm, where the
  AGI might be of a null value or even absent.

9.1 Active group integrity

  The active group integrity specifies conditions on the active group
  membership of a TC. The following is the AGI conditions identified and
  defined in this standard. Inclusion of other AGI conditions is for
  further study.

9.1.1 AGI policy

    a) Soft: policy for which the TC is to be suspended when the AGI is
       violated. The TC is to be restored when the AGI is recovered.

    b) Hard: policy for which the TC is to be terminated when the AGI is
       violated.

9.1.2 Population

  The AGI population characteristic for a TC can be one or more of the
  following.

    a) Mandatory: condition that specifies the selected enrolled group
       members required to be present in the active group;

    b) Minimum: condition that specifies the minimum number of enrolled
       group members required to be present in the active group;

    c) Quorum: condition wherein the majority of enrolled group members
       are required to be present in the   active group;

    d) Maximum: condition that specifies, Nmax, the maximum number of
       members that can be allowed in the active group;

    e) Atomic: condition wherein all of enrolled group members are
       required to be present in the active group.

9.1.3 TC type

  The type eligible for a group will be one of the followings:

    a) Simplex TC;



Dae Young Kim               Expires 12/31/98                   [Page 15]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


    b) Duplex TC;

    c) N-plex TC.

9.1.4 Transmit diversity

  The transmit diversity eligible for a group will be one of the
  followings:

    a) Homogeneous

    b) Heterogeneous

9.1.5 Receive diversity

  The receive diversity eligible for a group will be one of the
  followings:

    a) Receivers-wide

    b) Receiver-selected

9.1.6 Transmit concurrency

  The transmit concurrency eligible for a group will be one of the
  followings:

    a) Controlled

    b) Uncontrolled

  NOTE - In the controlled mode of transmit concurrency, Ntok is less
         than Nmax; Ntok < Nmax. When Ntok equals Nmax, the case reduces
         to the uncontrolled mode.

9.2 Quality of service

  The term quality of service (QoS) refers to certain characteristics of
  a TC that are managed by the TS-users and the TS-provider. They are

    - throughput, transit delay and transit delay jitter, which are
      classed as TC performance characteristics

    - corrupted TSDU error rate and lost TSDU error rate, which are
      classed as TC reliability characteristics

    - TC ordering




Dae Young Kim               Expires 12/31/98                   [Page 16]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


    - TC protection

    - TC precedence.

  Definitions of these characteristics are given in 10.1.

  Values for some or all of these characteristics may be agreed before
  the TC is operated. The nature of QoS agreements and the means by
  which they can be reached are specified in 10.2. The phases of
  establishment of a TC during which values for the various
  characteristics may be agreed and possibly subsequently refined are
  specified in 10.3.

  Once agreed, QoS values apply for the duration of a TC. In some cases,
  different TS-users may operate with different values of QoS.

10 Quality of service for Transport Connections

10.1 QoS classification

  The QoS classes and the possible values that may be imposed or agreed
  upon are shown in Table 1.

           Table 1 - Classification of the QoS characteristics

 +-----------------+----------------+---------------------------------+
 | Characteristic  | Characteristic |   QoS value agreed or imposed   |
 | group           |                |                                 |
 +-----------------+----------------+---------------------------------+
 | TC performance  | Throughput     | - ChQ throughput value          |
 |                 |                | - operating target throuput     |
 |                 |                |   value                         |
 |                 |                | - LQA throughput value          |
 |                 +----------------+---------------------------------+
 |                 | Transit delay  | - operating target transit delay|
 |                 |                |   value                         |
 |                 |                | - LQA transit delay value       |
 |                 +----------------+---------------------------------+
 |                 | Transit delay  | - operating target transit delay|
 |                 | jitter         |   jitter value                  |
 |                 |                | - LQA transit delay jitter value|
 +-----------------+----------------+---------------------------------+
 | TC reliability  | Corrupted TSDU | - LQA corrupted TSDU error rate |
 |                 | error rate     |   value                         |
 |                 +----------------+---------------------------------+
 |                 | Lost TSDU error| - LQA lost TSDU error rate value|
 |                 | rate           |                                 |
 +-----------------+----------------+---------------------------------+



Dae Young Kim               Expires 12/31/98                   [Page 17]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


 | TC ordering     | TC ordering    | - No ordering                   |
 |                 |                | - Local ordering                |
 |                 |                | - Causal ordering               |
 |                 |                | - Partial ordering              |
 |                 |                | - Total ordering                |
 +-----------------+----------------+---------------------------------+
 | Miscellaneous   | TC protection  | Local matter according to the   |
 |                 |                | security policy in force        |
 |                 |                | See 10.1.4.1                    |
 |                 +----------------+---------------------------------+
 |                 | TC precedence  | Imposition of :                 |
 |                 |                |  - the order in which TCs are to|
 |                 |                |    have their QoS degraded, or  |
 |                 |                |  - the order in which TCs are to|
 |                 |                |    be broken to recover         |
 |                 |                |    resources                    |
 +-----------------+----------------+---------------------------------+

10.1.1 TC performance

10.1.1.1 Throughput

  Throughput in general is a property of a channel between a pair of
  users which quantifies the rate of successful transfer of user data
  through the channel. It is defined in the QoS Framework (ITU-T Rec.
  X.641 | ISO/IEC 13236) as the rate of user data output from a channel
  averaged over a time interval t.

  If the channel is loss-free, the rate of data output will be the same
  as the rate of data input, when averaged over appropriate periods. If
  the channel can lose data - for example if it includes a data-
  discarding filter - the rate of data output may be significantly less
  than the rate of data input.

  In ECTS, throughput may need to be negotiated for a number of reasons:
  for example,

    - to determine the maximum rate at which a transmitter should
      operate

    - to ensure that enough capacity is made available in the provider
      and in receiving TS-users

    - to set up an appropriate flow control regime.

  Throughput, or equivalently transmit rate is defined for a TS-user and
  a given TC in terms of a sequence of at least two TSDUs in T-DATA
  request primitives. Given such a sequence of n TSDUs, where n is



Dae Young Kim               Expires 12/31/98                   [Page 18]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  greater than or equal to 2, the transmit rate is defined to be the
  number of TS-user data octets contained in the last n-1 TSDUs divided
  by the time between the first and last T-DATA requests in the
  sequence.

10.1.1.2 Transit delay

  Transit delay is defined as the time elapsed between the occurrence of
  a T-DATA request primitive at a TSAP and the occurrences of the
  corresponding T-DATA indication primitives at the receiving TSAP.  The
  requirement for transit delay in one direction of transmission may be
  different from the requirement for transit delay in the reverse
  direction.

10.1.1.3 Transit delay jitter

  Transit delay jitter is defined between a pair of users, and for each
  direction of transmission, as the difference between the longest and
  the shortest transit delays in the lifetime of the TC.

10.1.2 TC reliability

  For each TC, the TC reliability is defined as the combination of a
  TSDU corruption policy and a TSDU loss policy.

  The TSDU loss policy is specified qualitatively by selecting one of
  two options:

    a) losses of TSDUs are not accepted;

    b) losses of TSDUs are accepted but indicated.

  The TSDU corruption policy is specified qualitatively by selecting one
  of two options:

    a) corruption of contents in TSDUs are not accepted;

    b) corruption of contents in TSDUs are accepted but indicated.

  The four possible combinations result in four different TC reliability
  policies as follows:

    a) lossless and error-free;

    b) lossless and corrupted;

    c) lossy and error-free;




Dae Young Kim               Expires 12/31/98                   [Page 19]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


    d) lossy and corrupted.

  Table 2 shows the four TC reliability policies and the associated
  meaningful error rates.

  The TC reliability policies are negotiated among the TS-users only.

  If neither losses nor corruption of contents are accepted on a TC, the
  TS-provider has to preserve unchanged the boundaries and the contents
  of all submitted TSDUs. That is, any TSDU delivered to the receiving
  TS-user via a T-DATA indication primitive shall have the same number
  of octets and the same value for each octet as the TSDU received from
  the sending TS-user in the corresponding T-DATA request primitive.

    Table 2 - The four TC reliability policies and the corresponding
              meaningful error rates

  +---------------------------+---------------------------------------+
  | TC reliability            | Loss Policy                           |
  | policy                    +--------------+------------------------+
  |                           | Losses not   | Losses accepted but    |
  |                           | accepted     | indicated              |
  +------------+--------------+--------------+------------------------+
  | Corruption | Corruption   | lossless and | lossy and error-free   |
  | policy     | not accepted | error-free   | (Lost TSDU error rate) |
  |            +--------------+--------------+------------------------+
  |            | Corruption   | lossless and | lossy and corrupted    |
  |            | accepted but | corrupted    | (Corrupted TSDU error  |
  |            | indicated    | (Corrupted   |  rate)                 |
  |            |              |  TSDU error  | (Lost TSDU error rate) |
  |            |              |  rate)       |                        |
  +------------+--------------+--------------+------------------------+

  If corruption of contents are accepted, then any TSDU delivered to the
  receiving TS-users via a T-DATA indication  primitive shall still have
  the same number of octets as the TSDU submitted by the sending TS-user
  in the corresponding T-DATA request primitive, but the values of some
  octets may have been altered by the TS-provider. The corruption of
  contents is to be indicated by the status parameter value in the T-
  DATA indication primitive.  If losses are accepted, then, for any lost
  or corrupted TSDU submitted by the sending TS-user, a zero-length TSDU
  is delivered to the receiving TS-user with indication by the status
  parameter in the T-DATA indication primitive. The TC reliability
  policies are implemented by managing the QoS characteristics,
  corrupted TSDU error rate and lost TSDU error rate.

10.1.2.1 Corrupted TSDU error rate




Dae Young Kim               Expires 12/31/98                   [Page 20]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  The corrupted TSDU error rate is defined as the ratio of total number
  of TSDUs delivered to the receiving TS-user, with their contents
  corrupted, to the total number of TSDUs submitted by the sending TS-
  user to the TS-provider during a defined period.  The corrupted TSDU
  error rate is negotiated among the TS-users only.

10.1.2.2 Lost TSDU error rate

  The lost TSDU error rate is defined as the ratio of the total number
  of zero length TSDUs delivered to the receiving TS-user to the total
  number of TSDUs submitted by the sending TS-user to the TS-provider
  during a defined period.  The lost TSDU error rate is negotiated among
  the TS-users only.

10.1.3 TC ordering

  TC ordering is concerned with the following two aspects:

    a) how TSDUs of a sending TS-user are presented to the receiving
       TS-users;

    b) how a receiving TS-user gets TSDUs from the sender(s).

  In the case of a single sending TS-user, ordering if needed ensures
  that the TSDUs generated by the sending TS-user are delivered to each
  receiving TS-user in the active group in the same order as they were
  sent. In the case of multiple sending TS-users, ordering determines
  the relative sequencing of TSDU received from multiple sending TS-
  users. The ordering relationship defines the arrangement or
  interleaving of TSDU from the multiple sending TS-users. The ordering
  relationship can be: no, local, causal, partial, or total. Note that
  when there are only two participants in the active group, local
  ordering, causal ordering, and total ordering are the same.

  NOTE - In Annex A, the ordering relationship is described in detail.

10.1.3.1 No ordering

  TS-provider does not guarantee any relationship between TSDUs sent
  from a single sending TS-user or from multiple sending TS-users.

  NOTE 1 - Even though the ordering of TSDUs are not guaranteed, the
           ordering of TPDUs belong to the same TSDU are to be
           guaranteed.  NOTE 2 - Selection of no ordering can be used to
  absorb the ALF
           (application level framing) feature of the Internet.

10.1.3.2 Local ordering



Dae Young Kim               Expires 12/31/98                   [Page 21]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  The TSDUs, generated by a particular sending TS-user, are delivered to
  all of the receiving TS-users in the same order in which they were
  generated. Local ordering does not establish any ordering relationship
  among TSDUs generated by different sending TS-users.

10.1.3.3 Partial ordering

  The TSDUs, generated by all sending TS-users are delivered to each
  receiving TS-user according to an arbitrary ordering rule.

  If the TSDUs are ordered according to a rule applicable to all
  receiving TS-users, then each receiving TS-user receives the TSDUs
  generated by all the sending TS-users in the same order.

  If the TSDUs are ordered according to a rule determined by each
  receiving TS-user, then each receiving TS-user may receive the TSDUs
  in different orders.

10.1.3.4 Causal ordering

  The causal ordering orders the TSDUs generated by all sending TS-users
  according to the causal dependence relationship among the sending
  events. A causal dependence relationship is established between two
  sending events, A and B, if the following applies:

    a) A happens before B if A and B are sending events generated by
       the same sending TS-user and A is sent before B;

    b) A happens before B if A and B are sending events generated by
       two different sending TS-users and the TSDUs generated by the
       event A by one sending TS-user is received by the other sending
       TS-user before it generates the event B.

  A causal dependence relationship is established among more than two
  sending events if it can be established that A happens before B and
  that B happens before C, and it therefore follows that A happens
  before C. A causal dependence relationship cannot be established
  between the two sending events A and C if there is no possibility to
  establish that A happens before B and that B happens before C.

10.1.3.5 Total ordering

  The TSDUs, generated by all sending TS-users, are delivered to each
  receiving TS-user in the same order. Every receiving TS-user sees all
  TSDUs from all sending TS-users in exactly the same order.

10.1.4 Miscellaneous




Dae Young Kim               Expires 12/31/98                   [Page 22]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


10.1.4.1 TC protection

  Protection QoS is the degree to which the TS-provider attempts to
  counter security threats to the Transport Service using Security
  Services applied to the Transport, Network, Data Link or Physical
  Layers. The handling of protection QoS parameters is a local matter
  controlled according to the security policy in force.

    NOTE - For further information on the provision of security in the
           lower layers and the handling of protection QoS see ITU-T
           Rec. X.802 | ISO/IEC TR 13594.

10.1.4.2 TC precedence

  The TC precedence characteristic specifies the relationship between
  TCs. This characteristic specifies the relative importance of a TC
  with respect to:

    a) the order in which TCs are to have their QoS degraded, if
       necessary, and

    b) the order in which TCs are to be broken to recover resources, if
       necessary.

  This characteristic only has meaning in the context of some management
  entity or structure able to judge relative importance. The number of
  precedence levels is limited.

10.2 Levels of QoS agreement

10.2.1 Best effort level

  For each QoS value negotiated at the best effort level of agreement,
  there is no guarantee that it will be maintained throughout the
  lifetime of the TC.

10.2.2 Guaranteed level

  Guaranteed levels of agreement apply to QoS limits. The TS-provider
  monitors the achieved QoS. If it determines that it cannot maintain
  the QoS within the agreed limit, it will either

  a) pause the service (by issuing a T-PAUSE indication primitive), if
     the condition is judged to be transient, or

  b) remove a TS-user (by issuing a T-LEAVE indication primitive), or

  c) terminate the TC (by issuing a T-TERMINATE indication primitive).



Dae Young Kim               Expires 12/31/98                   [Page 23]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  However, in reaching the guaranteed level of agreement, the parties
  undertake to provide the agreed QoS, for example by dedicating
  resources to the TC, barring the occurrence of rare events such as
  equipment failure.

10.3 QoS negotiation mechanisms

  For the negotiation of the ECTS QoS characteristics, two procedures
  are defined, namely the owner-arbitration (OA) and step-wise
  arbitration (SWA) procedures. The QoS negotiation capabilities and
  mechanisms supported by these procedures are different.

10.3.1 Generic QoS negotiation

    1. The focal TS-user proposes a LQA value LQAo, a CHQ value CHQo,
       and an OT value OTo, where LQAo < OTo < CHQo.

    2. The TS-provider may refuse the request if it knows it cannot be
       met, i.e., if it cannot support at least LQAo.
       If the TS-provider does not refuse the request, but cannot
       operate over the full range proposed by the focal TS-user, it
       may determine a new reduced CHQ value CHQi' for each responding
       TS-user Ri individually.  (It is also possible that the
       TS-provider may choose to operate internally at a higher
       quality, but it does not signal this fact to the responding
       TS-user.) CHQi' shall not be worse than the
       focal-TS-user-proposed OTo; otherwise, the TS-user should leave
       the TC. The TS-provider may not alter the LQA and OT values.
       Thus LQAo < OTo < CHQi' < CHQo for all i.
       LQAo, OTo, and the new CHQi' are supplied to each responding
       TS-user Ri.

    3. Each responding TS-user may refuse the request. If it accepts,
       it may increase the LQA to a new value LQAi', decrease the CHQ
       to a new value CHQi", and change the OT to a new value OTi'.
       OTi' may be lower or higher than the TC-owner proposed OTo.
       Thus, LQAo < LQAi' < OTi' < CHQi" < CHQi' < CHQo for all i.
       The new values LQAi', CHQi", and OTi' are returned to the
       TS-provider.

    4. The TS-provider examines the values returned from each
       responding TS-user and determines LQA'max=max LQAi',
       CHQ"min = min CHQi", and OT'max = max OTi'. It is a requirement
       for a feasible region that LQA'max < CHQ"min. In the case of
       the guaranteed level of agreement, responding TS-users may need
       to be removed until this constraint is satisfied.
       If a feasible region exists, the TS-provider selects the values
       LQA, CHQ, and OT such that LQA'max < LQA < OT < CHQ < CHQ"min.



Dae Young Kim               Expires 12/31/98                   [Page 24]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


       Typically, LQA will be close to LQA'max, CHQ to CHQ"min, and OT
       to OT'max .
       If a feasible region does not exist, selection of LQA, CHQ, and
       OT are abandoned. In the case of the guaranteed level of
       agreement, this results in failure of the connection
       establishment.

    5. The selected values LQA, CHQ, and OT are returned to the focal
       TS-user and to all responding TS-users.  They are the "agreed"
       values. Except in the case of the best-effort level of
       agreement, this meets the requirements of all TS-users since
       LQAo < LQAi' < LQA'max < LQA < OT < CHQ < CHQ"min < CHQi" <
       CHQi' < CHQo for all i.
       If the receive mode is "receivers-wide", the "agreed" values
       are also the receive QoS values of all the receiving TS-users.
       If the receive mode is "receiver-selected", although the focal
       TS-user transmits data according to the agreed QoS values, each
       TS-user may receive the data according to the QoS values it has
       returned to the TS-provider in its previous response.
       The mechanism is illustrated in Figure 4.































Dae Young Kim               Expires 12/31/98                   [Page 25]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


focal TS-user | TS-provider | responding   |TS-provider | all TS-users
              |             | TS-users     |            |
--------------+-------------+--------------+------------+-------------
              |             |              |            |
              |             |  +--------+  |            |
              |             |  l __/1   l  |            |
              |             | __/   V   l  |            |
              |            __/ l     \__l  |            |
  CHQo --------------+  __/ |  l    A   \__|   +-----+  |
              |      1_/    |  l _/-1_  l  \-->| min |--------- CHQ
              |      1      |  _/   1 \ l  |   +-----+  |
              |      1\     |_/l    V  \l  |    A       |
              |      V \   _/  l        \  |   /        |
              |         \_/ |  l    A_  l\ |  /         |
              |        _/\  |  l    1 \ l \| / +-----+  |
              |       /   \ |  l_/--+  \l  \/->| Arb |--------- OT
  OTo ---------------+     \|  /        \  /   +-----+  |
              |       \     \_/+--------+\/|    A       |
              |        \    / \          /\|  _/        |
              |         \_ /|  \        /  \ /          |
              |           X |   \---+  /   |X           |
              |          / \|       1 /   _/ \          |
              |         /   \  +----1/--_/ |  \         |
              |        /    |\ l    V _/l  |   \        |
              |       /     | \l     /  l  |    \       |
  LQAo --------------+      |  \    A   l  |     V      |
              |       \__   |  l\   1   l  |   +-----+  |
              |          \__|  l \--+   l  |/->| max |--------- LQA
              |             \__l    1   l  /   +-----+  |
              |             |  \    V   l_/|            |
              |             |  l\     __/  |            |
              |             |  l \   /  l  |            |
              |             |  l  \ A   l  |            |
              |             |  l   \1   l  |            |
              |             |  +--------+  |      Arb=arbitration
              |             |              |            |
              |             |              |            |


                    Figure 4 - Generic QoS negotiation

10.3.2 OA QoS negotiation

  The OA QoS negotiation applies to all three types of TC, i.e.,
  simplex, duplex, and N-plex and the procedure is the same as described
  in 10.3.1 with the TC-owner as the focal TS-user:

    1. The TC-owner issues a T-CREATE request, multicast, containing a



Dae Young Kim               Expires 12/31/98                   [Page 26]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


       QoS proposal, thus initiating the generic QoS negotiation
       procedure of 10.3.1 for the whole TC.

    2. Every TS-user responds to the T-CREATE indication it receives
       with a T-CREATE response, which contains a set of responses to
       the QoS proposals made by the TC-owner.

    3. The provider performs an arbitration of the QoS.

    4. The provider issues T-CREATE confirm primitives containing the
       results of the arbitration, with AGI for the whole connection,
       to all TS-users.

  From the point of view of QoS, the QA procedure allows the whole 1xN
  QoS negotiations to be initiated and arbitrated altogether, following
  the sequence

    - proposal

    - provider modification

    - response

    - arbitration (local to the TC-owner).

  A TC by an OA establishment is said to be homogenous, implying that
  all TS-users have agreed to a common set of transmit QoS values and so
  all sending TS-users transmit data at the same rate. It holds for all
  sending TS-users in the active group that

      ThroughputMin = LQA ; minimum transmit rate

      ThroughputMax = CHQ ; maximum transmit rate

      ThroughputOperating = OT ; operating target transmit rate.

  The non-TC-owners of a simplex or a duplex TC receive data from only
  one TS-user, i.e., the TC-owner. It holds for them that

      ReceiveRateMin = LQA ; minimum receive rate

      ReceiveRateMax = CHQ ; maximum receive rate

      ReceiveRateExpected = OT ; expected receive rate.

  The TC-owner of a duplex TC and all the TS-users of a N-plex TC
  receive data from multiple sending TS-users, of which the maximum
  number is, by definition, Ntok. Then, selection of the transmit rate



Dae Young Kim               Expires 12/31/98                   [Page 27]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  as above has the consequence of implicitly announcing their receive
  capability such that

      ReceiveRateMin = Ntok x LQA ; minimum aggregate receive rate

      ReceiveRateMax = Ntok x CHQ ; maximum aggregate receive rate

      ReceiveRateExpected = Ntok x OT ; expected aggregate receive rate.

  Note, in the case Nact, the number of members present in the active
  group, is less than Ntok, i.e., Nact < Ntok, a resource of at least
  (Ntok - Nact) x CHQ per host or provider is left unused.  This is a
  slack reserve for late joining TS-users.

  In the case of a receiver-selected receive mode, ReceiveRateMin,
  ReceiveRateMax, and ReceiveRateExpected may be less than the ones
  given here.

10.3.3 SWA QoS negotiation

  The SWA QoS negotiation applies only to two of the TC types, duplex
  and N-plex and the procedure is the same as described in 10.3.1 with a
  prior invitation by the TC-owner:

    1. The TC-owner issues a T-INVITE request, multicast, containing
       the TC-characteristics.

    2. Every prospective focal TS-user responds to the T-INVITE
       indication by issuing a T-JOIN request, thus individually
       initiating the generic QoS negotiation procedure of 10.3.1 for
       its 1xN simplex channel of the TC.

    3. Every TS-user responds to each T-JOIN indication it receives
       with a T-JOIN response, which contains a set of responses to
       the QoS proposals made by the focal TS-user that issued the
       corresponding T-JOIN request.

    4. The TS-provider performs an arbitration of the QoS for each 1xN.

    5. The TS-provider issues T-JOIN confirm primitives containing the
       results of the arbitration for the relevant 1xN, with AGI for
       the whole connection , to all TS-users.

  From the point of view of QoS, the SWA procedure allows the individual
  1xN QoS negotiations to be initiated and arbitrated independently,
  following the sequence

    - proposal



Dae Young Kim               Expires 12/31/98                   [Page 28]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


    - provider modification

    - response

    - arbitration (local to focal TS-user).

  A TC by an SWA establishment is said to be heterogeneous, implying
  that different sending TS-users may transmit data at different rates.
  It holds for each TS-user in the active group that

      ThroughputMin = LQAi      ; minimum transmit rate

      ThroughputMax = CHQi      ; maximum transmit rate

      ThroughputOperating = OTi ; operating target transmit rate.

  The non-TC-owners of a duplex TC receive data from only one TS-user,
  i.e., the TC-owner. It holds for them that

      ReceiveRateMin = LQAo     ; minimum rate of the TC-owner

       ReceiveRateMax = CHQo     ; maximum rate of the TC-owner

       ReceiveRateExpected = OTo ; expected rate of the TC-owner

  The TC-owner of a duplex TC and all the TS-users of a N-plex TC
  receive data from multiple sending TS-users, of which the maximum
  number is, by definition, Ntok. Then, it holds for them that

      ReceiveRateMin = Sum {LQAj; j=1,Ntok}     ; minimum receive rate

      ReceiveRateMax = Sum {CHQj; j=1,Ntok}     ; maximum receive rate

      ReceiveRateExpected = Sum {OTj; j=1,Ntok} ; expected receive rate

  In the case of a receiver-selected receive mode, ReceiveRateMin,
  ReceiveRateMax, and ReceiveRateExpected may be less than the ones
  given here.

10.3.4 Considerations

  A zero throughput value in a response primitive is used to announce
  that the TS-user may want to participate the TC simply as a receive-
  only user. Note that an intention of no participation at all is
  signaled by a T-LEAVE request primitive.

  Constraints applicable to specific QoS characteristics.




Dae Young Kim               Expires 12/31/98                   [Page 29]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  This standard places the following constraints on how QoS agreements
  are reached.

    C1. Corrupted TSDU error rate and lost TSDU error rate are
        negotiated between TS-users only, i.e. using a restricted form
        of the mechanisms defined above in which the TS-provider plays
        no part.

    C2. TC ordering is not subject to imposition or negotiation during
        CREATE or JOIN operations. See 10.1.3 for further information.

    C3. TC protection is determined by security policy, and is not
        covered by this clause.

    C4. TC precedence is determined by a management policy. It may be
        imposed, but not negotiated.


  QoS parameters of ECTS service primitives

  This subclause identifies the general set of QoS parameters used in
  ECTS service primitives in order to impose or negotiate QoS
  agreements. Not all need be present in all cases: the exact set
  required is determined by the types of agreement on QoS it is desired
  to reach and the specifications of the foregoing negotiation rules.

  For each QoS characteristic, other than TC-protection, the following
  parameters may be present in T-CREATE and T-JOIN service primitives:

    - imposition or negotiation

    - type of value negotiated, i.e. operating target, LQA limit, CHQ
      limit

    - type of agreement required, i.e. best efforts or guaranteed

    - negotiation type, i.e. receivers-wide/receiver-selected

    - values as defined in the negotiation mechanism employed

10.4 Phases of QoS agreement

  There are several partly overlapping phases related to the operation
  of a TC. Some of them apply to the TC as a whole, others (namely join
  and leave) apply to individual TS-users. The phases are

    - the enrollment phase, during which the enrollment group is
      established and conditions for TCs are prepared



Dae Young Kim               Expires 12/31/98                   [Page 30]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


    - the creation phase, during which the TC is explicitly created

    - the data transmission phase, during which data are exchanged

    - the join phase, during which new TS-users join the TC

    - the leave phase, during which some TS-users leave the TC

    - the termination phase, at which the TC is terminated.

  Rules may exist as to which parties may create and/or terminate such
  connections and therefore distinguish them from those parties which
  may only join and leave Transport Connections created by others.
  These rules thus determine the phases at which various QoS agreements
  may be reached.

  For some characteristics, such as ordering, only those parties capable
  of providing the necessary function can be enrolled into any given
  group. The ordering characteristic is therefore determined by the end
  of the enrollment phase.

  For other characteristics, the phase at which they may be agreed
  depends on whether negotiation is to take place and on  the type of
  negotiation, e.g. receivers-wide or receiver-selected, that is
  required. If receivers-wide negotiation is required for a value
  (operating target, LQA or CHQ) associated with a given QoS
  characteristic, then that negotiation must take place during the
  enrollment phase or the creation phase, and the agreed value will then
  be imposed upon any TS-user that attempts to join the TC later.  On
  the other hand, if the value is to be imposed or negotiated on a
  receiver-selected basis, then the agreement may be reached during the
  enrollment phase, the creation phase or the join phase.

  Agreements reached during the enrollment phase may be on a specific
  value, or on a range of acceptable values. In the latter case, the
  agreement may be refined by selection of a specific value within the
  range during the creation phase or the join phase.

  NOTE - The means by which agreements may be reached during the
         enrollment phase are beyond the scope of this standard.

  Security or management policies may place further constraints on the
  phases at which QoS agreements may be reached.

  In addition to specifying particular values or range constraints that
  apply to particular QoS characteristics at various phases, it is also
  possible to define those default values which will apply in the
  absence of any specification in a T-primitive. This service definition



Dae Young Kim               Expires 12/31/98                   [Page 31]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  does not specify any particular default values, nor the means by which
  they may be established. Other specifications may specify particular
  defaults to be used in particular environments.

  Table 3 lists QoS characteristics and indicates in which phases of a
  TC their values may be negotiated.

  Table 3 - Classification of the QoS characteristics by phase usage

  +--------------------------+------------+------------+----------+
  | Characteristic           | Enroll use | Create use | Join use |
  +--------------------------+------------+------------+----------+
  | Throughput               | R, V       | V          | SV       |
  +--------------------------+------------+------------+----------+
  | Transit delay            | R, V       | V          | SV       |
  +--------------------------+------------+------------+----------+
  | Transit delay jitter     | R, V       | V          | SV       |
  +--------------------------+------------+------------+----------+
  | Corrupted TSDU error rate| R, V       | V          | SV       |
  +--------------------------+------------+------------+----------+
  | Lost TSDU error rate     | R, V       | V          | SV       |
  +--------------------------+------------+------------+----------+
  | TC Ordering              | V          | N          | N        |
  +--------------------------+------------+------------+----------+
  | TC Protection            | SP         | SP         | SP       |
  +--------------------------+------------+------------+----------+
  | TC precedence            | I          | I          | I        |
  +--------------------------+------------+------------+----------+

11 Enhanced Communications Transport Service primitives and
   parameters

11.1 Definitions

  Table 4 defines the service primitives and the associated parameters
  which are used in ECTS. Detailed descriptions of these primitives are
  given in clauses 12 to 22.

  NOTE - Although the TC characteristics normally consist of AGI and
         QoS, the AGI might be of a null value or even absent in

  TC characteristics parameters of response and confirm primitives.









Dae Young Kim               Expires 12/31/98                   [Page 32]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


   Table 4 - Enhanced Communications Transport Service primitives

+------------+--------------+-----------------------------------------+
| Service    | Primitive    | Parameters                              |
+------------+--------------+-----------------------------------------+
| TC         | T-CREATE     | (Called address, Calling address,       |
| creation   |   request    |  TC-characteristics, TS-user data)      |
|            | T-CREATE     | (Called address, Calling address,       |
|            |   indication |  TC-characteristics, TS-user data)      |
|            | T-CREATE     | (Responding address, TC-characteristics,|
|            |   response   |  TS-user data)                          |
|            | T-CREATE     | (Responding address, TC-characteristics,|
|            |   confirm    |  TS-user data)                          |
+------------+--------------+-----------------------------------------+
| TC         | T-INVITE     | (Called address, Calling address,       |
| invitation |   request    |  TC-characteristics, TS-user data)      |
|            | T-INVITE     | (Called address, Calling address,       |
|            |   indication |  TC-characteristics, TS-user data)      |
+------------+--------------+-----------------------------------------+
| TC join    | T-JOIN       | (Called address, Calling address,       |
|            |   request    |  TC-characteristics, TS-user data)      |
|            | T-JOIN       | (Called address, Calling address,       |
|            |   indication |  TC-characteristics, TS-user data)      |
|            | T-JOIN       | (Responding address, TC-characteristics,|
|            |   response   |  TS-user data)                          |
|            | T-JOIN       | (Responding address, TC-characteristics,|
|            |   confirm    |  TS-user data)                          |
+------------+--------------+-----------------------------------------+
| Data       | T-DATA       | (TS-user data)                          |
| transfer   |   request    |                                         |
|            | T-DATA       | (Calling address, Status, TS-user data) |
|            |   indication |                                         |
| Service    | Primitive    | Parameters                              |
+------------+--------------+-----------------------------------------+
| TC         | T-CREATE     | (Called address, Calling address,       |
| TC         | T-CREATE     | (Called address, Calling address,       |
| creation   |   request    |  TC-characteristics, TS-user data)      |
|            | T-CREATE     | (Called address, Calling address,       |
|            |   indication |  TC-characteristics, TS-user data)      |
|            | T-CREATE     | (Responding address, TC-characteristics,|
|            |   response   |  TS-user data)                          |
|            | T-CREATE     | (Responding address, TC-characteristics,|
|            |   confirm    |  TS-user data)                          |
+------------+--------------+-----------------------------------------+
| TC         | T-INVITE     | (Called address, Calling address,       |
| invitation |   request    |  TC-characteristics, TS-user data)      |
|            | T-INVITE     | (Called address, Calling address,       |
|            |   indication |  TC-characteristics, TS-user data)      |



Dae Young Kim               Expires 12/31/98                   [Page 33]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


+------------+--------------+-----------------------------------------+
| TC join    | T-JOIN       | (Called address, Calling address,       |
|            |   request    |  TC-characteristics, TS-user data)      |
|            | T-JOIN       | (Called address, Calling address,       |
|            |   indication |  TC-characteristics, TS-user data)      |
|            | T-JOIN       | (Responding address, TC-characteristics,|
|            |   response   |  TS-user data)                          |
|            | T-JOIN       | (Responding address, TC-characteristics,|
|            |   confirm    |  TS-user data)                          |
+------------+--------------+-----------------------------------------+
| Data       | T-DATA       | (TS-user data)                          |
| transfer   |   request    |                                         |
|            | T-DATA       | (Calling address, Status, TS-user data) |
|            |   indication |                                         |
|            | T-UNITDATA   | (Called address, Calling address,       |
|            |   request    |  TC-characteristics, TS-user data)      |
|            | T-UNITDATA   | (Called address, Calling address,       |
|            |   indication |TC-characteristics, Status,TS-user data) |
| Pause      | T-PAUSE      | (Reason)                                |
|            |   indication |                                         |
| Resume     | T-RESUME     | (Reason)                                |
|            |   indication |                                         |
| Report     | T-REPORT     | (Reason)                                |
|            |   indication |                                         |
+------------+--------------+-----------------------------------------+
| TC leave   | T-LEAVE      | (Called address, Calling address,       |
|            |   request    |  TS-user data)                          |
|            | T-LEAVE      | (Called address,Reason)                 |
|            |   indication |                                         |
+------------+--------------+-----------------------------------------+
| TC         | T-TERMINATE  | (TS-user data)                          |
| termination|   request    |                                         |
|            | T-TERMINATE  | (Reason, TS-user data)                  |
|            |   indication |                                         |
+------------+--------------+-----------------------------------------+
| TC-        | T-OWNER      | (Called address, Calling address,       |
| ownership  |   request    |  TS-user data)                          |
|            | T-OWNER      | (Called address, Calling address,       |
|            |   indication |  TS-user data)                          |
|            | T-OWNER      | (Responding address, TS-user data)      |
|            |   response   |                                         |
|            | T-OWNER      | (Responding address, TS-user data)      |
|            |   confirm    |                                         |
+------------+--------------+-----------------------------------------+
| Token give | T-GIVE       | (Called address, Calling address,       |
|            |   request    |  TS-user data)                          |
|            | T-GIVE       | (Called address, Calling address,       |
|            |   indication |  TS-user data)                          |



Dae Young Kim               Expires 12/31/98                   [Page 34]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


|            | T-GIVE       | (Responding address, TS-user data)      |
|            |   response   |                                         |
|            | T-GIVE       | (Responding address, TS-user data)      |
|            |   confirm    |                                         |
+------------+--------------+-----------------------------------------+
| Token get  | T-GET        | (Called address, Calling address,       |
|            |   request    |  TS-user data)                          |
|            | T-GET        | (Called address, Calling address,       |
|            |   indication |  TS-user data)                          |
|            | T-GET        | (Responding address, TS-user data)      |
|            |   response   |                                         |
|            | T-GET        | (Responding address, TS-user data)      |
|            |   confirm    |                                         |
+------------+--------------+-----------------------------------------+

    Table 4 - Enhanced Communications Transport Service primitives

11.2 Sequence of primitives at a TSAP

  This subclause defines the constraints on the sequences in which the
  primitives defined in clauses 12-22 may occur. The constraints
  determine the order in which primitives may occur, but do not fully
  specify when they may occur. Other constraints, such as flow control
  of data, will affect the ability of a TS-user or a TS-provider to
  issue a primitive at any particular time.

  A primitive issued at one TSAP will, in general, have consequences at
  the other TSAPs. The relations of primitives of each type to
  primitives at the other TC endpoints are defined in the appropriate
  clauses 12-22.

  The possible overall sequences of primitives at a TSAP are defined in
  the state transition diagrams, Figures 5 to 7. In the diagrams:

    a) a primitive which is not shown as resulting in a transition
       (from one state to the same state, or from one state to a
       different state) is not permitted in that state;

    b) the Idle state reflects the absence of a relationship between
       the TS-user and the TC. It is the initial and final state of
       any sequence, and upon returning to this state, the TS-user may
       not participate in the TC;

    c) the use of a state transition diagram to describe the allowable
       sequences of service primitives does not impose any requirements
       or constraints on the internal organization of any
       implementations of the Transport Service.




Dae Young Kim               Expires 12/31/98                   [Page 35]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


12 TC Creation service

12.1 Function

  The TC Creation primitives can be used by the TC-owner to establish a
  homogeneous TC, provided the enrolled TS-users exist and are known to
  the TS-provider.

  TC-characteristics, i.e., AGI and QoS are assumed to have been defined
  and known both to the TS-users and the TS-provider beforehand.

  The TC Creation service will further refine the QoS, if necessary, and
  check the identities of the TC-participants to validate the AGI
  condition.

  It is assumed that there exists one and only one TC-owner who
  possesses the right to create and terminate a TC of a given enrolled
  group.

































Dae Young Kim               Expires 12/31/98                   [Page 36]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


              +--------+               +--------+ T-JOIN.ind +--------+
              |        | T-INVITE.req  | Invite |===========>|Incoming|
              | Idle   |==============>| Pending|            |Join    |
              |        | (with group   |        |<===========|Pending |
              +--------+  address)     +--------+T-LEAVE.req +--------+
                  |                       1  A <\_                  1
  T-REPORT        |            T-JOIN.req 1  1    \_ T-LEAVE.req    1
  indication      |                       1  1      \_ T-LEAVE.ind  1
   +====+         |                       1  1        \_            1
   1    1         |                       1  1          \_          1
   V    1         |                       1  1            \_ T-JOIN.1
+-----------+     | T-CREATE              1  1              \_  res 1
|Incoming   |     |  request              1  1                \     V
|Join       |     |                       1  1T-LEAVE.req     +--------+
|Processing1|     V                       V  1T-LEAVE.ind     |Outgoing|
+-----------+     +--------+            +--------+            |Join    |
    1    A        |Outgoing|            |Outgoing|            |Response|
    1    1T-JOIN. |Create  |            |Join    |            |Pending |
T-JOIN.  1ind     |Pending |            |Pending |            +--------+
res 1    1        +--------+            +--------+           ___/
T-LEAVE. 1                \               /              ___/
req 1    1                 \ T-CREATE.   /T-JOIN.    ___/  T-REPORT.ind
    1    1                  \_ con    __/   con  ___/
    1    1                    |      |       ___/
    V    1                    v      v     _/
+---------+                 +-----------+</            +------------+
| Data    |<================| Data      |=============>|Incoming    |
| Transfer|  T-PAUSE.ind    | Transfer  |   T-JOIN.ind | Join       |
|suspended|================>| Ready     |<=============|processing 2|
+---------+  T-RESUME.ind   +-----------+   T-JOIN.res +------------+
  1     A                      1   A        T-LEAVE.req   1     A
  1     1                      1   1                      1     1
  +=====+                      +===+                      +=====+
T- REPORT.ind                    [1]                         [2]



[1] T-DATA.req            [2] T-DATA.req
    T-REPORT.ind              T-REPORT.ind
    T-INVITE.req

           Figure 5(a) - State transition diagram of a TC-owner









Dae Young Kim               Expires 12/31/98                   [Page 37]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  +---------+                 +-----------+              +------------+
  | Data    |<================| Data      |=============>|Incoming    |
  | Transfer|  T-PAUSE.ind    | Transfer  |   T-JOIN.ind | Join       |
  |suspended|================>| Ready     |<=============|processing 2|
  +---------+  T-RESUME.ind __+-----------__  T-JOIN.res +------------+
    1     A              __/   A A | A | A  \_T-LEAVE.req    1   A
    1     1           __/   ___| | | | | |__  \_             1   1
    +=====+          /    _/     | +=+ |    \__ \_           +===+
  T-REPORT.ind     _/   _/ T-GET.| [1] |T-GET. \+ \+          [2]
             ____+/    /     res |     |  ind   |\ |\________
     T-GIVE.|    |  _+/          |     |        | \|         | T-GET.
       req  V    |_/ |           |     V        |  \         V   req
  +----------+   /   |          +----------+    |  |\     +----------+
  |Token     |__/|   |          |Token     |    |  | \____|Token     |
  |Allocation|T-GIVE.|          |Request   |    |  |T-GET.|Withdrawal|
  |Pending   |con|   |          |Acceptance|    |  |  con |Pending   |
  +----------+   |   |          |pending   |    |  |      +----------+
   1   A         |   | T-OWNER. +----------+    |  |          1  A
   1   1 T-OWNER.|   |   con     1  A    T-GIVE.|  | T-GIVE.  1  1
   +===+   req   V   |           1  1       res |  V    ind   +==+
    [2]       +---------+        +==+      +---------+         [2]
              |Ownership|         [2]      |Token    |
              |Transfer |                  |Returned |
              |Pending  |                  |Pending  |
              +---------+                  +---------+
                 1   A                        1   A
                 1   1                        1   1
                 +===+                        +===+
                  [2]                          [2]


  [1] T-DATA.req            [2] T-DATA.req
      T-DATA.ind                T-DATA.ind
      T-REPORT.ind              T-REPORT.ind
      T-INVITE.req



           Figure 5(b) - State transition diagram of a TC-owner


  NOTE - T-TERMINATE request and/or indication may occur at any
         states, except the idle states, which then will lead to the
         idle state. All states except the Data Transfer Suspended
         include a self-loop branch due to T-UNITDATA request and
         T-UNITDATA indication; these primitives may occur at such
         states without causing transition to other states.




Dae Young Kim               Expires 12/31/98                   [Page 38]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


              +--------+               +--------+ T-JOIN.ind +--------+
              |        | T-INVITE.req  | Invite |===========>|Incoming|
              | Idle   |==============>| Pending|            |Join    |
              |        | (with group   |        |<===========|Pending |
              +--------+  address)     +--------+T-LEAVE.req +--------+
               A                        / A  A                  _/
               |            T-JOIN.req / /   1                _/
               |                      / /    1T-LEAVE.req   _/
   T-LEAVE.req |                   __/ /     1T-LEAVE.ind _/
   T-LEAVE.ind |                  /   /      1          _/ T-JOIN.res
               |               __/   /       1        _/       +=====+
               |              /   __/        1   ____/         | [1] |
               |       ______/   /           1  |              |     V
               |      |    _____/T-LEAVE.req 1  V            +---------+
               |      V   | T-LEAVE.ind +--------+           |Outgoing |
               |  +---------+           |Outgoing|           |Ownership|
               |  |Outgoing |           |Join    |           |Transfer |
               |  |Join     |           |Response|           |Pending  |
               |  |Pending  |           |Pending |           +---------+
               |  +---------+           +--------+           ___/  A
               |          \               /              ___/      |
               |           \_T-JOIN.con  /T-REPORT.  ___/      T-OWNER.
               +____________ \__     __/   ind  ___/             res
                            |   |    |       ___/ T-REPORT.        |
                            |   V    V     _/         ind          |
+---------+                 +-----------+</            +------------+
| Data    |<================| Data      |              |Incoming    |
| Transfer|  T-PAUSE.ind    | Transfer  |=============>|Join        |
|suspended|================>| Ready     | T-OWNER.ind  |processing 2|
+---------+  T-RESUME.ind   +-----------+              +------------+
  1    A                        1   A                     1   A
  1    1                        1   1                     1   1
  +====+                        +===+                     +===+
T- REPORT.ind                     [1]                       [1]



  [1] T-DATA.req             [2]  T-DATA.ind
      T-DATA.ind                  T-REPORT.ind
      T-REPORT.ind



          Figure 6(a)- State transition diagram of a focal
                       in a heterogeneous TC






Dae Young Kim               Expires 12/31/98                   [Page 39]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


 +---------+                 +-----------+              +------------+
 | Data    |<================| Data      |              |Incoming    |
 | Transfer|  T-PAUSE.ind    | Transfer  |=============>|Join        |
 |suspended|================>| Ready     | T-OWNER.ind  |processing 2|
 +---------+  T-RESUME.ind __+-----------+_             +------------+
   1     A              +_/   A A | A | A  \_               1   A
   1     1           __/|  ___| | | | | |__  \_             1   1
   +=====+          /   |_/     | +=+ |    \__ \_           +===+
 T-REPORT.ind     _/   _/       | [1] |       \+ \_          [1]
            _____/   +/ |       |  T-GET.req   |\  \________
    T-GIVE.|       _/|  |   T-GET.con |        | \          | T-GET.req
      req  V     _/  |  |       |     V        |  \         V
 +----------+   /    |  |      +--------+      |   \     +----------+
 |Token     |__/     |  |      |Token   |      |    \____|Token     |
 |Allocation|T-GIVE. |  |      |Request |      |   T-GET.|Withdrawan|
 |Pending   |con     |  |      |Pending |      |     con |Pending   |
 +----------+        |  |      +--------+      |         +----------+
 1 A  |              |  |       1   A          |            1   A |
 1 1  |              |  |       1   A          |            1   1 |
 +=+  |              |  |       +===+          |            +===+ |
 [2]  |     +--------+  +-----+  [2]           |             [2]  |
      |     |                 |           +----+              T-GET.res
 T-GIVE.res |          T-GIVE.req        /     |_______________   |
      |     |T-REPORT.ind     |     T-GIVE.con                 |  |
      V     |                 V        /          T-REPORT.ind |  V
 +-----------+               +----------+                   +---------+
 |Token      |               | Token    |                   |Token    |
 |Allocated  |               | Returned |                   |Withdrawn|
 |Response   |               | Pending  |                   |Response |
 |Pending    |               +----------+                   |Pending  |
 +-----------+                  1   A                       +---------+
    1   A                       1   1                         1   A
    1   1                       +===+                         1   1
    +===+                        [2]                          +===+
     [2]                                                       [2]

[1]  T-DATA.req            [2]  T-DATA.ind
     T-DATA.ind                 T-REPORT.ind
     T-REPORT.ind

         Figure 6(b) - State transition diagram of a focal TS-user
                       in a heterogeneous TC

  NOTE - T-TERMINATE request and/or indication may occur at any
         states, except the idle states, which then will lead to the
         idle state. All states except the Data Transfer Suspended
         include a self-loop branch due to T-UNITDATA request and
         T-UNITDATA  indication; these primitives may occur at such
         states without causing transition to other states.


Dae Young Kim               Expires 12/31/98                   [Page 40]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


T-LEAVE.req
T-LEAVE.ind
+------------>  +--------+             +--------+ T-JOIN.ind +--------+
|  +--------->  |        |T-INVITE.req | Invite |===========>|Incoming|
| T-CREATE.req  |  Idle  |============>| Pending|            |Join    |
|  |+---------  |        | (with group |        |<===========|Pending |
|  || T-CRATE.  +--------+   address)  +--------+T-LEAVE.req +--------+
|  |V  ind       A | A | A--------------+    A                  _/
|  +--------+    | | | +---------+      |    1                _/
| |Incoming|     | | |      T-INVITE.ind|    1T-LEAVE.req   _/
| |Create  |     | |T-LEAVE.req  |      |    1T-LEAVE.ind _/
| |Pending |     | |T-LEAVE.ind  V      |    1          _/ T-JOIN.res
| +--------+     | | |      +-------+   |    1        _/
|   |            | | |      |Invited|   |    1   ____/
| T-CRATE.res    | | |      +-------+   |    1  |
|   |   +--------+ \ +---+     |      +-+    1  |               [1]
|   |   |      T-JOIN.req|     |      |      1  |              +====+
|   |T-LEAVE.req      \_ | T-JOIN.req |      1  |              |    |
|   |T-LEAVE.ind       | |     |      |      1  |              |    V
|   V   |              V |     V      |      1  V            +---------+
| +--------+         +----------+     | +--------+           |Outgoing |
| |Outgoing|         |Outgoing  |     | |Outgoing|           |Ownership|
| |Create  |         |Join      |     | |Join    |           |Transfer |
| |Response|         |Processing|     | |Response|           |Pending  |
| |Pending |         +----------+     | |Pending |           +---------+
| +--------+                 |        | +--------+           ___/  A
|    |                       | T-INVITE.ind /            ___/      |
| T-REPORT.ind            T-JOIN.con  |    T-REPORT. ___/      T-OWNER.
|    |                       +---+    | __/ ind  ___/             res
|    +-----------------------+   |    ||      __/ T-REPORT.        |
|                            V   V    |V   __/         ind         |
+---------+                 +-----------+</            +------------+
| Data    |<================| Data      |              |Incoming    |
| Transfer|  T-PAUSE.ind    | Transfer  |=============>|Join        |
|suspended|================>| Ready     |  T-OWNER.ind |processing 2|
+---------+  T-RESUME.ind   +-----------+              +------------+
  1   A                        1    A                      1   A
  1   1                        1    1                      1   1
  +===+                        +====+                      +===+
T- REPORT.ind                    [1]                         [1]


  [1]  T-DATA.req            [2]  T-DATA.ind
       T-DATA.ind                 T-REPORT.ind
       T-REPORT.ind

       Figure 7(a)- State transition diagram of a non-focal TS-user




Dae Young Kim               Expires 12/31/98                   [Page 41]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


 +---------+                 +-----------+              +------------+
 | Data    |<================| Data      |              |Incoming    |
 | Transfer|  T-PAUSE.ind    | Transfer  |=============>|Join        |
 |suspended|================>| Ready     |  T-OWNER.ind |processing 2|
 +---------+  T-RESUME.ind __+-----------+_             +------------+
   1     A              +_/   A A | A | A  \_               1   A
   1     1           __/|  ___| | | | | |__  \_             1   1
   +=====+          /   |_/     | +=+ |    \__ \_           +===+
 T-REPORT.ind     _/   _/       | [1] |       \+ \_          [1]
            _____/   +/ |       |  T-GET.req   |\  \________
    T-GIVE.|       _/|  |   T-GET.con |        | \          | T-GET.req
      req  V     _/  |  |       |     V        |  \         V
 +----------+   /    |  |      +--------+      |   \     +----------+
 |Token     |__/     |  |      |Token   |      |    \____|Token     |
 |Allocation|T-GIVE. |  |      |Request |      |   T-GET.|Withdrawan|
 |Pending   |con     |  |      |Pending |      |     con |Pending   |
 +----------+        |  |      +--------+      |         +----------+
 1 A  |              |  |       1   A          |            1   A |
 1 1  |              |  |       1   A          |            1   1 |
 +=+  |              |  |       +===+          |            +===+ |
 [2]  |     +--------+  +-----+  [2]           |             [2]  |
      |     |                 |           +----+              T-GET.res
 T-GIVE.res |          T-GIVE.req        /     |_______________   |
      |     |T-REPORT.ind     |     T-GIVE.con                 |  |
      V     |                 V        /          T-REPORT.ind |  V
 +-----------+               +----------+                   +---------+
 |Token      |               | Token    |                   |Token    |
 |Allocated  |               | Returned |                   |Withdrawn|
 |Response   |               | Pending  |                   |Response |
 |Pending    |               +----------+                   |Pending  |
 +-----------+                  1   A                       +---------+
    1   A                       1   1                         1   A
    1   1                       +===+                         1   1
    +===+                        [2]                          +===+
     [2]                                                       [2]



  [1]  T-DATA.req            [2]  T-DATA.ind
       T-DATA.ind                 T-REPORT.ind
       T-REPORT.ind

       Figure 7(b) - State transition diagram of a non-focal TS-user


  NOTE - T-TERMINATE request and/or indication may occur at any
         states, except the idle states, which then will lead to the
         idle state. All states except the Data Transfer Suspended



Dae Young Kim               Expires 12/31/98                   [Page 42]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


         include a self-loop branch due to T-UNITDATA request and
         T-UNITDATA  indication; these primitives may occur at such
         states without causing transition to other states.

12.2 Types of primitives and parameters

  Table 5 lists the types of primitives and parameters associated with a
  TC creation

           Table 5 - TC creation primitives and parameters

 +----------------+---------+----------+---------+---------+----------+
 |                |T-CREATE | T-CREATE |T-CREATE |T-CREATE | T-REPORT |
 |                | request |indication| reponse | confirm |indication|
 +----------------+---------+----------+---------+---------+----------+
 | Called address |    X    |   X(=)   |         |         |          |
 +----------------+---------+----------+---------+---------+----------+
 | Calling address|X(Note 1)|   X(=)   |         |         |          |
 +----------------+---------+----------+---------+---------+----------+
 | Responding     |         |          |         |         |          |
 | address        |         |          |X(Note 1)|X(Note 2)|          |
 +----------------+---------+----------+---------+---------+----------+
 | TC             |         |          |         |         |          |
 | characteristics|   X     |     X    |    X    |X(Note 3)|          |
 +----------------+---------+----------+---------+---------+----------+
 | TS-user data   |  X(U)   |   X(=)   |   X(U)  |   X(=)  |          |
 +----------------+---------+----------+---------+---------+----------+
 | Reason         |         |          |         |         |X(Note 3) |
 +----------------+---------+----------+---------+---------+----------+

  NOTE 1 - This parameter may be implicitly associated with the TSAP at
           which the primitive is issued.

  NOTE 2 - This is a list of addresses of the responding TS-users.

  NOTE 3 - This includes the OA QoS values.

12.2.1 Called address

  The called address parameter conveys a TSAP address that identifies
  the TS-user(s) expected to participate in the TC being established.

12.2.2 Calling address

  The calling address parameter conveys the TSAP address of the TC-owner
  by whom the TC creation has been requested.

12.2.3 Responding address



Dae Young Kim               Expires 12/31/98                   [Page 43]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  The responding address parameter conveys the address of the TSAP of
  the TS-user to participate in the TC and to which  TS-user data should
  be delivered when the TC is in the Data Transfer state.

12.2.4 TC-characteristics

  The TC-characteristics parameter conveys the AGI and QoS for the TC.
  Whereas the AGI parameters are not for negotiation, the QoS values may
  be changed in the sequel of primitives. The QoS in the request
  primitive is what proposed by the TC-owner; that in the indication
  primitive is what modified by the TS-provider; that in the response
  primitive is what counter-proposed by the responding TS-users; that in
  the confirm primitive is what arbitrated by the TS-provider.

12.2.5 TS-user data

  The TS-user data parameter allows the transfer of TS-user data among
  TS-users without modification by the TS-provider.

12.2.6 Reason

  The reason parameter of the REPORT indication primitive conveys the
  TC-characteristics including the OA QoS values.

12.3 Sequence of primitives

  The sequence of primitives in a successful TC creation is defined by
  Figure 8. Note that a confirm primitive is delivered only to the TC-
  owner who has previously issue the request primitive and other TS-
  users are supplied with a T-REPORT indication.





















Dae Young Kim               Expires 12/31/98                   [Page 44]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


              \    |       |           |             |
                \  |       |           |             |
      T-CREATE   v |       |           |             |
      request      |\      |           |             |
                   |  \    |T-CREATE   | T-CREATE    | T-CREATE
                   |    \  |indication | indication  | indication
                   |      \|- - - - - -|- - - - - - -|
                   |       |\          |\            |\
                   |       |  \        |  \          |  \
                   |       |    \      |    \        |   \
                   |       |     v     |     v       |    v
                   |       |           |             |
                   |       | T-CREATE  | T-CREATE    | T-CREATE
                   |       | response  | response    | response
                   |       |    /      |    /        |    /
                   |       |  /        |  /          |  /
                   |       |v_ _ _ _ _ |v_ _ _ _ _ _ |v
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|_ _ _ _ _ _|_ _ _ _ _ _ _|
      T-CREATE    /|       |\          |\            |\
      confirm   /  |       |  \        |  \          |  \
              /    |       |    \      |    \        |    \
             v     |       |     v     |     v       |     v
                   |       | T-REPORT  | T-REPORT    | T-REPORT
                   |       | indication| indication  | indication


    Figure 8 - Sequence of primitives in a successful TC creation

  The TC Creation procedure may fail either due to the inability of the
  TS-provider to establish a TC, due to the unsuccessful negotiation of
  the QoS, or due to the failure of the AGI condition.

13 TC Invitation service

13.1 Function

  The TC Invitation primitives can be used by the TC-owner to invite the
  TS-users to collectively establishing a heterogeneous TC, provided the
  enrolled TS-users exist and are known to the TS-provider. A
  heterogeneous TC is established by individual establishment of
  multiple 1xN simplex channels, each by every focal TS-user through
  Join  primitives. The TC Invitation primitive can also be used by the
  TC-owner to invite a TS-user to join an already existing TC.

  In both cases, the TC Invitation service is normally followed by the



Dae Young Kim               Expires 12/31/98                   [Page 45]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  TC Join service.

  TC-characteristics, i.e., AGI and QoS are assumed to have been defined
  and known both to the TS-users and the TS-provider beforehand.

  The TC Invitation service does not change the TC-characteristics it
  conveys.

  It is assumed that there exists one and only one TC-owner who
  possesses the right to invoke the Invitation service.

13.2 Types of primitives and parameters

  Table 6 lists the types of primitives and parameters associated with a
  TC invitation.

           Table 6 - TC invitation primitives and parameters

  +--------------------+-------------------+---------------------+
  |                    |     T-INVITE      |     T-INVITE        |
  |                    |      request      |     indication      |
  +--------------------+-------------------+---------------------+
  | Called address     |        X          |        X(=)         |
  |--------------------+-------------------+---------------------+
  | Calling address    |        X          |        X(=)         |
  +--------------------+-------------------+---------------------+
  | TC characteristics |        X          |        X(=)         |
  +--------------------+-------------------+---------------------+
  | TS-user data       |       X(U)        |        X(=)         |
  +--------------------+-------------------+---------------------+

13.2.1 Called address

  In the invitation to establishing a heterogeneous TC, the called
  address parameter conveys a TSAP address that identifies the TS-
  user(s) expected to participate in the heterogeneous TC being
  established. In the invitation to an existing TC, the called address
  parameter conveys a TSAP address that identifies the TS-user being
  invited.

13.2.2 Calling address

  The calling address parameter conveys the TSAP address of the TC-owner
  by whom the TC invitation has been requested.

13.2.3 TC-characteristics

  The TC-characteristics parameter conveys the AGI and QoS for the TC.



Dae Young Kim               Expires 12/31/98                   [Page 46]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  Both the AGI and the QoS parameters are not changed in the sequel of
  primitives.

13.2.4 TS-user data

  The TS-user data parameter allows the transfer of the TC-owner data to
  other TS-users.

13.3 Sequence of primitives

13.3.1 Invitation for a heterogeneous TC

  The TC Invitation primitives can be used by the TC-owner to invite the
  TS-users to collectively establishing a heterogeneous TC. The sequence
  of primitives in a TC Invitation is defined by Figure 9.  Note that
  the TC invitation primitives are normally followed each by a JOIN
  request primitive defined below, thus initiating the Join service
  depicted in the time-sequence diagram of Figure 11.

          \     |       |           |           |
            \   |       |           |           |
              v |       |           |           |
                |\      |           |           |
      T-INVITE  |  \    | T-INVITE  | T-INVITE  | T-INVITE
      request   |    \  | indication| indication| indication
                |      \|- - - - - -|- - - - - -|
                |       |\          |\          |\
                |       |  \        |  \        |  \
                |       |    v      |    v      |    v
                |       |           |           |
                |       |           |           |
      T-JOIN    |       | T-JOIN    |           | T-JOIN
      request   |       | request   |           | request
          \     |       |    /      |           |    /
            \   |       |  /        |           |  /
              v |       |v          |           |v
                |       |           |           |


     Figure 9 - Sequence of primitives in a TC invitation

  The TC invitation procedure may fail either due to the inability of
  the TS-provider or due to the failure of the AGI condition.

13.3.2 Invitation for a late join

  The TC Invitation primitives can be used by the TC-owner to invite a
  specified TS-user to joining an already existing TC. The sequence of
  primitives in such a TC Invitation is defined by Figure 10.


Dae Young Kim               Expires 12/31/98                   [Page 47]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988




          \     |       |           |           |
            \   |       |           |           |
              v |       |           |           |
                |\      |           |           |
      T-INVITE  |  \    | T-INVITE  |           |
      request   |    \  | indication|           |
                |      \|- - - - - -|- - - - - -|
                |       |\          |           |
                |       |  \        |           |
                |       |    v      |           |
                |       |           |           |
                |       |           |           |
                |       | T-JOIN    |           |
                |       | request   |           |
                |       |    /      |           |
                |       |  /        |           |
                |       |v          |           |
                |       |           |           |


    Figure 10 - Sequence of primitives in a TC invitation for a
                specified TS-user to join an already existing TC

14 TC Join service

14.1 Function

  The TC Join primitives can be used by the focal TS-user to establish a
  heterogeneous TC, provided the enrolled TS-users exist and are known
  to the TS-provider.

  The primitive can also be used by a TS-user to join an already
  existing homogenous TC as a send and/or receive TS- user or a
  heterogeneous TC as a receive-only user.

  TC-characteristics, i.e., AGI and QoS are assumed to have been defined
  and known both to the TS-users and the TS-provider beforehand.

  The TC Join service will further refine the QoS, if necessary, and
  check the identities of the TC-participants to validate the AGI
  condition.

14.2 Types of primitives and parameters

  Table 7 lists the types of primitives and parameters associated with a
  TC Join.



Dae Young Kim               Expires 12/31/98                   [Page 48]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


            Table 7 - TC Join  primitives and parameters

 +----------------+---------+----------+---------+---------+----------+
 |                | T-JOIN  | T-JOIN   | T-JOIN  | T-JOIN  | T-REPORT |
 |                | Request |Indication|Response | Confirm |Indication|
 +----------------+---------+----------+---------+---------+----------+
 | Called address |    X    |   X(=)   |         |         |          |
 +----------------+---------+----------+---------+---------+----------+
 | Calling address|X(Note 1)|   X(=)   |         |         |          |
 +----------------+---------+----------+---------+---------+----------+
 | Responding     |         |          |         |         |          |
 | address        |         |          |X(Note 1)|X(Note 2)|          |
 +----------------+---------+----------+---------+---------+----------+
 | TC             |         |          |         |         |          |
 | characteristics|   X     |     X    |    X    |X(Note 3)|          |
 +----------------+---------+----------+---------+---------+----------+
 | TS-user data   |  X(U)   |   X(=)   |   X(U)  |   X(=)  |          |
 +----------------+---------+----------+---------+---------+----------+
 | Reason         |         |          |         |         |X(Note 3) |
 +----------------+---------+----------+---------+---------+----------+

  NOTE 1 - This parameter may be implicitly associated with the TSAP
           at which the primitive is issued.

  NOTE 2 - This is a list of addresses of the responding TS-users or
           the address of the TC-owner.

  NOTE 3 - This includes the arbitrated QoS values.

14.2.1 Called address

  In the case of a heterogeneous TC establishment, the called address
  parameter conveys a (group) TSAP address that identifies the TS-
  user(s) expected to participate in the TC being established. In the
  case of a late join wherein a TS-user attempts to join an existing TC,
  the called address conveys the group address of the TC to join.

14.2.2 Calling address

  In the case of a heterogeneous TC establishment, the calling address
  parameter conveys the TSAP address of the focal TS-user by whom the TC
  join has been requested. In the case of a late join, the calling
  address conveys the address of the TS-user attempting to join the
  existing TC.

14.2.3 Responding address

  In the case of a heterogeneous TC establishment, the responding



Dae Young Kim               Expires 12/31/98                   [Page 49]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  address parameter conveys the address of the TSAP of the TS-user to
  participate in the TC and to which TS-user data should be delivered
  when the TC is in the Data Transfer state.  In the case of a late
  join, the responding address conveys the address of the TC-owner.

14.2.4 TC-characteristics

  The TC-characteristics parameter conveys the AGI and QoS for the TC.
  Whereas the AGI parameters are not for negotiation, the QoS values may
  be changed in the sequel of primitives for the establishment of each
  1xN simplex channel. The QoS in the request primitive is what proposed
  by the  focal TS-user; that in the indication primitive is what
  modified by the TS-provider; that in the response primitive is what
  counter-proposed by the responding TS-users; that in the confirm
  primitive is what arbitrated by the TS-provider.

  In the case of a late join, the QoS may not be changed. The late
  coming TS-user either obeys the QoS of the homogeneous TC or he joins
  a heterogeneous TC as a receive-only member.

14.2.5 TS-user data

  The TS-user data parameter allows the transfer of TS-user data among
  TS-users without modification by the TS-provider.

14.2.6 Reason

  The reason parameter of the REPORT indication primitive conveys the
  TC-characteristics including the arbitrated QoS values.

14.3 Sequence of primitives

  The sequence of primitives in a successful TC join in the case of a
  heterogeneous TC establishment is defined by Figure 11. Note that a
  confirm primitive is delivered only to the TS-user who has previously
  issued the request primitive and other TS-users are supplied with a T-
  REPORT indication.

  The sequence of primitives in a successful TC late join is defined by
  Figure 12. Note that both a confirm and a report primitive are
  delivered to the late joining TS-user while other TS-users are
  supplied only with a report primitive.

  The TC Join procedure may fail either due to the inability of the TS-
  provider to establish a TC, due to the unsuccessful  negotiation of
  the QoS, or due to the failure of the AGI condition.





Dae Young Kim               Expires 12/31/98                   [Page 50]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


              \    |       |           |             |
                \  |       |           |             |
                  v|       |           |             |
        T-JOIN     |\      |           |             |
        request    |  \    |T-JOIN     | T-JOIN      | T-JOIN
                   |    \  |indication | indication  | indication
                   |      \|-----------|-------------|
                   |       |\          |\            |\
                   |       |  \        |  \          |  \
                   |       |    \      |    \        |   \
                   |       |     v     |     v       |    v
                   |       |           |             |
                   |       | T-JOIN    | T-JOIN      | T-JOIN
                   |       | response  | response    | response
                   |       |    /      |    /        |    /
                   |       |  /        |  /          |  /
                   |       |v__________|v___________ |v
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|___________|_____________|
        T-JOIN    /|       |\          |\            |\
        confirm /  |       |  \        |  \          |  \
              /    |       |    \      |    \        |    \
             v     |       |     v     |     v       |     v
                   |       | T-REPORT  | T-REPORT    |T-REPORT
                   |       | indication| indication  |indication

  Figure 11 - Sequence of primitives in a successful TC Join by a focal
              TS-user





















Dae Young Kim               Expires 12/31/98                   [Page 51]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


                   |       |    /      |           |
                   |       |  /        |           |
                   |       |v          |           |
                   |      \| T-JOIN    |           |
                   |    \  | request   |           |
     T-JOIN        |  \    |           |           |
     indication   \|       |           |           |
                /  |       |           |           |
              /    |       |           |           |
            v      |       |           |           |
                   |       |           |           |
                   |       |           |           |
           \       |       |           |           |
             \     |       |           |           |
     T-JOIN    \   |       |           |           |
     response     v|       |           |           |
                   |\      | T-JOIN    |           |
                   |  \@\  | confirm   |           |
                   |   \  \|           |           |
                   |    \  |\          |           |
                   |     \ |  v        |           |
                   |      \|_ _ _ _ _ _|_ _ _ _ _ _|
                   |       |\          |\          |\
                   |       |  \        |  \        |  \
                   |       |    v      |    v      |    v
                   |       |T-REPORT   |T-REPPRT   |T-REPORT
                   |       |indication |indication |indication

  Figure 12 - Sequence of primitives in a successful TC join by a
              TS-user in a homogeneous TC or by a receive-only TS user
              in a heterogeneous TC


15 Data Transfer service

15.1 Function

  The Data Transfer service provides for two types of transfer of TSDUs
  from a sending TS-user to the other receiving TS-user(s). In one type,
  data transfer takes place over a successfully established TC using T-
  DATA primitives. In the other type, data transfer takes place at any
  phase of a TC using T-UNITDATA primitives; it may take place even when
  no TC is available between the sending and the receiving TS-users.

15.2 Types of primitives and parameters

  Table 8 indicates the types of primitives and the parameters for the
  Data Transfer service.



Dae Young Kim               Expires 12/31/98                   [Page 52]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


            Table 8 - Data transfer primitives and parameters

 +-----------------+-----------+------------+-----------+------------+
 |                 |  T-DATA   |  T-DATA    |T-UNITDATA |T-UNITDATA  |
 |                 |  request  | indication |  request  | indication |
 +-----------------+-----------+------------+-----------+------------+
 | Called address  |           |            |     X     |    X(=)    |
 |-----------------+-----------+------------+-----------+------------+
 | Calling address |           |     X      |     X     |    X(=)    |
 |-----------------+-----------+------------+-----------+------------+
 | TC              |           |            |     X     |    X(=)    |
 | characteristics |           |            |           |            |
 |-----------------+-----------+------------+-----------+------------+
 | Status          |           |     X      |           |     X      |
 |-----------------+-----------+------------+-----------+------------+
 | TC user data    |     X     |    X(=)    |     X     |    X(=)    |
 +-----------------+-----------+------------+-----------+------------+

15.2.1 Called address

  The called address parameter may be present only in T-UNITDATA
  primitives and conveys a TSAP address that  identifies the TS-user(s)
  expected to received the data sent.

15.2.2 Calling address

  The calling address parameter conveys a TSAP address that identifies
  the TS-user who has sent the data.

15.2.3 TC-characteristics

  The TC-characteristics parameter may be present only in T-UNITDATA
  primitives. All parameters of the TC-characteristics except the
  transit delay shall be of null value.

15.2.4 Status

  The notification of detected but not corrected errors is signaled
  through the status parameter to the TS-user.

  The status parameter conveys a notification to the TS-user that

    a) the TS-user data is corrupted (errors detected but not corrected)
       or

    b) the TS-user data is substituted (errors detected and substituted)
       or




Dae Young Kim               Expires 12/31/98                   [Page 53]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


    c) the TS-user data is of zero length (TSDU lost or corrupted).

15.2.5 TS-user data

  The TS-user data parameter consists of an integral number of octets
  greater than or equal to zero and allows the transfer of data from a
  sending TS-user to the receiving TS-user(s), without modification by
  the TS-provider.

15.3 Sequence of TS primitives

  The sequence of primitives in a successful data transfer is defined by
  Figures 13 and 14.

          \     |       |           |           |
            \   |       |           |           |
              v |       |           |           |
      T-DATA    |\      |           |           |
      request   |  \    | T-DATA    | T-DATA    | T-DATA
                |    \  | indication| indication| indication
                |      \|_ _ _ _ _ _|_ _ _ _ _ _|
                |       |\          |\          |\
                |       |  \        |  \        |  \
                |       |    v      |    v      |    v
                |       |           |           |

   Figure 13 - Sequence of primitives in data transfer using T-DATA
               primitives

          \     |       |           |           |
            \   |       |           |           |
              v |       |           |           |
                |\      |           |           |
     T-UNITDATA |  \    |T-UNITDATA |T-UNITDATA |T-UNITDATA
      request   |    \  | indication| indication| indication
                |      \|_ _ _ _ _ _|_ _ _ _ _ _|
                |       |\          |\          |\
                |       |  \        |  \        |  \
                |       |    v      |    v      |    v
                |       |           |           |


  Figure 14 - Sequence of primitives in data transfer using T-UNITDATA
              primitives

16 Pause service

16.1 Function



Dae Young Kim               Expires 12/31/98                   [Page 54]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  The Pause service provides for the TS-provider to indicate with the T-
  PAUSE indication primitive to the active group TS-user(s) that the TC
  has entered the state where the data transfer is not allowed. The
  reason parameter within the T-PAUSE indication primitive should
  deliver the reason, e.g., violation of the QoS or the AGI.  Until the
  TS-users are notified that TC-characteristics are met again, no T-DATA
  request primitives may be issued. Data transfer resumes by the RESUME
  service.

16.2 Types of primitive and parameters

  Table 9 indicates the types of primitives and the parameters for the
  Pause service.

           Table 9 - Pause primitives and parameters

       +----------------------+------------------------+
       |                      |      T-PAUSE           |
       |                      |      indication        |
       +----------------------+------------------------+
       |  Reason              |             X          |
       +----------------------+------------------------+

16.2.1 Reason

  The reason parameter gives information indicating the cause of the
  data transfer suspension. The reason is one of the following:

    a) temporary lack of local or remote resources at the TS-provider;

    b) a QoS parameter temporarily below an agreed LQA level;

    c) AGI temporarily below the minimum level.

16.3 Sequence of TS primitives suspending data transfer

  The sequence of primitives in the Pause service is defined by Figure
  15.

                   |       |             |             |
      T-PAUSE      |       | T-PAUSE     | T-PAUSE     | T-PAUSE
      indication   |       | indication  | indication  | indication
                  /|  U 0  |- - - - - - -|- - - - - - -|
                /  |       |\            |\            |\
              /    |       |  \          |  \          |  \
            v      |       |    v        |    v        |    v
                   |       |             |             |

  Figure 15 - Sequence of primitives in TS-provider invoked suspension
              of data transfer

Dae Young Kim               Expires 12/31/98                   [Page 55]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988





17 Resume service

17.1 Function

  The Resume TS primitives are used to resume the data transfer
  recovering from the temporarily violated TC-characteristics. After the
  receipt of the T-RESUME indication primitive, the active group TS-user
  may restart issuing T-DATA request primitives, or receiving T-DATA
  indication primitives.

17.2 Types of primitive and parameters

  Table 10 indicates the types of primitives and the parameters for the
  Resume service.

              Table 10 - Resume primitives and parameters

         +-------------------------+------------------------+
         |                         |      T-RESUME          |
         |                         |      indication        |
         +-------------------------+------------------------+
         |  Reason                 |           X            |
         +-------------------------+------------------------+

17.2.1 Reason

  The reason parameter gives information indicating the reason for the
  resumption of the data transfer. The reason may usually be the
  recovery from the bottleneck that caused the previous Pause service.

17.3 Sequence of primitives

  The sequence of primitives in the resumption of a previously suspended
  data transfer is defined by Figure 16.

                   |       |             |             |
                   |       |             |             |
      T-RESUME     |       | T-RESUME    | T-RESUME    | T-RESUME
      indication   |       | indication  | indication  | indication
                  /|  U 0  |- - - - - - -|- - - - - - -|
                /  |       |\            |\            |\
              /    |       |  \          |  \          |  \
            v      |       |    v        |    v        |    v
                   |       |             |             |

  Figure 16 - Sequence of primitives in TS-provider resumption of data
              transfer

Dae Young Kim               Expires 12/31/98                   [Page 56]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988





18 Report service

18.1 Function

  The report TS primitives are used to notify the change or selection of
  TC-characteristics to the active TS-users during data transfer or in
  TC establishments.

  If the value of some TC-characteristic is changed, but not below the
  minimum level, the TS-provider alters the TS-user(s) by issuing a T-
  REPORT indication.

  NOTE - If the value of some TC-characteristic is below its minimum
         level and is not recoverable in data transfer, the TS-provider
         issues a T-TERMINATE indication or a T-LEAVE indication to the
         TS-user.

18.2 Types of primitive and parameters

  Table 11 indicates the types of primitives and the parameters for the
  Report service.

           Table 11 - Report primitives and parameters

       +-----------------------+------------------------+
       |                       |      T-REPORT          |
       |                       |      indication        |
       +-----------------------+------------------------+
       |  Reason               |          X             |
       +-----------------------+------------------------+

18.2.1 Reason

  The reason parameter gives information indicating the cause of the
  report. The reason is one of the following:

    a) minor lack of local or remote resources at the TS-provider;

    b) detected but not fatal QoS change, e.g., degradation of QoS below
       some threshold;

    c) detected but not fatal AGI change.

  A non-fatal change may be signaled by a T-REPORT indication, whereas a
  fatal change will result in a T-LEAVE or T-TERMINATE indication.  The



Dae Young Kim               Expires 12/31/98                   [Page 57]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  reason parameter may also convey

    a) the arbitrated TC-characteristics in TC establishments, or

    b) the result of the TC-ownership service, or

    c) the result of the TC-token service, or

    d) additional information provided by the TS-provider.

  NOTE 1 - The TS-provider may provide additional information (e.g.,
           accounting) for management purposes.

  NOTE 2 - The TS-provider may replicate the TS-user data of some
           related primitives.

18.3 Sequence of TS primitives

  The sequence of primitives in the Report service as used by the TS-
  provider is defined by Figure 17.

                   |       |             |             |
      T-REPORT     |       | T-REPORT    | T-REPORT    | T-REPORT
      indication   |       | indication  | indication  | indication
                  \|  U 0  |_ _ _ _ _ _ _|_ _ _ _ _ _ _|
                /  |       |\            |\            |\
              /    |       |  \          |  \          |  \
            v      |       |    v        |    v        |    v
                   |       |             |             |


  Figure 17 - Sequence of primitives during data transfer when the TS-
              provider is to give warning or notification


19 TC Leave service

19.1 Function

  The TC Leave primitives are used to remove a TS-user from the TC.  The
  leave may be performed:

    a) by a TS-user to leave the TC;

    b) by a TS-provider to exclude a TS-user;

    c) by a TS-user to reject TC Create or TC Join;

    d) by a TS-provider to reject TC Join.


Dae Young Kim               Expires 12/31/98                   [Page 58]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


19.2 Types of primitives and parameters

  Table 12 indicates the types of primitives and parameters associated
  with the TC Leave service.

            Table 12 - TC Leave primitives and parameters

     +-----------------+-------------------+---------------------+
     |                 |      T-LEAVE      |      T-LEAVE        |
     |                 |      request      |     indication      |
     +-----------------+-------------------+---------------------+
     | Called address  |         X         |         X           |
     +-----------------+-------------------+---------------------+
     | Calling address |         X         |                     |
     +-----------------+-------------------+---------------------+
     | Reason          |                   |         X           |
     +-----------------|-------------------|---------------------+

19.2.1 Called address

  The called address parameter conveys:

    a) in the T-LEAVE request primitive, a group TSAP address that
       identifies the TC to leave;

    b) in the T-LEAVE indication primitive, the TSAP address of the
       TS-user to be excluded from the TC.

19.2.2 Calling address

  The calling address parameter conveys the TSAP address of the TS-user
  wishing to leave the TC.

19.2.3 Reason

  The reason parameter gives information on the cause of the Leave.  The
  reason is one of the following:

    a) QoS parameter below an agreed LQA level;

    b) lack of local or remote resources at the TS-provider;

    c) called address unknown.

19.3 Sequence of primitive

19.3.1 TS-user rejection of a TC Creation




Dae Young Kim               Expires 12/31/98                   [Page 59]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  A TS-user may reject a TC Creation request by a T-LEAVE request. The
  sequence of primitives is defined by Figure 18.

            \      |       |           |             |
              \    |       |           |             |
                \  |       |           |             |
     T-CREATE    v |       |           |             |
     request       |\      |           |             |
                   |  \    |T-CREATE   | T-CREATE    | T-CREATE
                   |    \  |indication | indication  | indication
                   |      \|- - - - - -|- - - - - - -|
                   |       |\          |\            |\
                   |       |  \        |  \          |  \
                   |       |    \      |    \        |   \
                   |       |     v     |     v       |    v
                   |       |           |             |
                   |       | T-LEAVE   | T-LEAVE     | T-LEAVE
                   |       | request   | response    | response
                   |       |    /      |    /        |    /
                   |       |  /        |  /          |  /
                   |       |v_ _ _ _ _ |v_ _ _ _ _ _ |v
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|_ _ _ _ _ _|_ _ _ _ _ _ _|
     T-CREATE     /|       |           |\            |\
     confirm    /  |       |           |  \          |  \
              /    |       |           |    \        |    \
             v     |       |           |     v       |     v
                   |       |           | T-REPORT    | T-REPORT
                   |       |           | indication  | indication

  Figure 18 - Sequence of primitives in a successful TC Creation with
              some TS-user rejection(s)

19.3.2 TS-user rejection of a TC Join

  A TS-user may reject a TC Join request by a T-LEAVE request. The
  sequence of primitives is defined by Figure 19.












Dae Young Kim               Expires 12/31/98                   [Page 60]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


              \    |       |           |             |
                \  |       |           |             |
     T-JOIN      v |       |           |             |
     request       |\      |           |             |
                   |  \    |T-JOIN     | T-JOIN      | T-JOIN
                   |    \  |indication | indication  | indication
                   |      \|- - - - - -|- - - - - - -|
                   |       |\          |\            |\
                   |       |  \        |  \          |  \
                   |       |    \      |    \        |   \
                   |       |     v     |     v       |    v
                   |       |           |             |
                   |       | T-LEAVE   | T-JOIN      | T-JOIN
                   |       | request   | response    | response
                   |       |    /      |    /        |    /
                   |       |  /        |  /          |  /
                   |       |v_ _ _ _ _ |v_ _ _ _ _ _ |v
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|_ _ _ _ _ _|_ _ _ _ _ _ _|
     T-JOIN       /|       |           |\            |\
     confirm    /  |       |           |  \          |  \
              /    |       |           |    \        |    \
             v     |       |           |     v       |     v
                   |       |           | T-REPORT    | T-REPORT
                   |       |           | indication  | indication

  Figure 19 - Sequence of primitives in a successful TC Join with some
              TS-user rejection(s)

19.3.3 TS-provider rejection of a TC Join attempt

  If the TS-provider is unable to establish a TC requested by a T-JOIN
  request, it indicates this to the TS-user by T-LEAVE indication
  primitive with a reason parameter. The sequence of primitives is
  defined by Figure 20.














Dae Young Kim               Expires 12/31/98                   [Page 61]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


                |         |         |          |    /
                |         |         |          |  /
                |         |         |          |v
                |         |         |          |  T-JOIN
                |         |         |          |  request
                |         |         |          |
                |         |         |          |
                |         |         |          |
                |         |         |          |   T-LEAVE
                |         |         |          |\  indication
                |         |         |          |  \
                |         |         |          |    \
                |         |         |          |      v

  Figure 20 - Sequence of primitives in TS-provider rejection of a TC
              Join attempt

19.3.4 TS-user invoked Leave

  A TS-user may remove itself from the TC by a T-LEAVE request. The
  sequence of primitives is defined by Figure 21.

          \     |       |           |           |
            \   |       |           |           |
              v |       |           |           |
                |\      |           |           |
      T-LEAVE   |  \    | T-REPORT  | T-REPORT  | T-REPORT
      request   |    \  | indication| indication| indication
                |      \|_ _ _ _ _ _|_ _ _ _ _ _|
                |       |\          |\          |\
                |       |  \        |  \        |  \
                |       |    \      |    \      |    \
                |       |      v    |      v    |      v

  Figure 21 - Sequence of primitives in a TS-user leaving the active TC

19.3.5 TS-provider expulsion of a TS-user Leave

  The TS-provider may expel a TS-user. The sequence of primitives is
  defined by Figure 22.











Dae Young Kim               Expires 12/31/98                   [Page 62]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


                   |       |              |             |
      T-LEAVE      |       | T-REPORT     | T-REPORT    | T-REPORT
      indication   |       | indication   | indication  | indication
                  /|  U 0  |_ _ _ _ _ _ _ |_ _ _ _ _ _ _|
                /  |       |\             |\            |\
              /    |       |  \           |  \          |  \
            v      |       |    v         |    v        |    v
                   |       |              |             |
                   |       |              |             |

    Figure 22 - Sequence of primitives in TS-provider expulsion of a
                TS-user

20 TC Termination service

20.1 Function

  The TC termination primitives are used to terminate a TC. The
  termination may be initiated by:

    a) the TC-owner, or

    b) the TS-provider due to fatal failure of some TC-characteristics.
       TC termination is permitted at any time regardless of the state
       of the TC. A request for termination cannot be rejected.

  The Transport Service does not guarantee delivery of any TS-user data
  once the termination procedure is entered.

20.2 Types of primitives and parameters

  Table 13 indicates the types of primitives and parameters associated
  with the TC Termination service.

         Table 13 - TC Termination primitives and parameters

     +-----------------+-------------------+---------------------+
     |                 |    T-TERMINATE    |   T-TERMINATE       |
     |                 |      request      |    indication       |
     +-----------------+-------------------+---------------------+
     | Reason          |                   |         X           |
     +-----------------|-------------------|---------------------+
     | TS-user data    |       X(U)        |        X(=)         |
     +-----------------+-------------------+---------------------+


20.2.1 Reason




Dae Young Kim               Expires 12/31/98                   [Page 63]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  The reason parameter gives information regarding the cause of the
  termination. The reason is one of the following:

    a) TC-owner invoked termination;

    b) lack of local or remote resource at the TS-provider;

    c) QoS below an agreed LQA level;

    d) called address unknown;

    e) AGI below the minimum level.

20.2.2 TS-user data

  The TS-user data parameter is present in the T-TERMINATE request and
  indication primitives when a termination request was originated by the
  TC-owner.

20.3 Sequence of primitives

  20.3.1 TC-owner invocation of a TC termination

  A TC-owner may terminate a TC by a T-TERMINATE request. The sequence
  of primitives is defined by Figure 23.

          \     |       |             |             |
            \   |       |             |             |
              v |       |             |             |
                |\      |             |             |
    T-TERMINATE |  \    | T-TERMINATE | T-TERMINATE | T-TERMINATE
    request     |    \  | indication  | indication  | indication
                |      \|_ _ _ _ _ _ _|_ _ _ _ _  __|
                |       |\            |\            |\
                |       |  \          |  \          |  \
                |       |    \        |    \        |    \
                |       |      v      |      v      |      v

  Figure 23 - Sequence of primitives in a TC-owner invocation of a TC
              termination

20.3.2 TS-provider invocation of a TC termination

  The sequence may be invoked by the TS-provider to terminate a TC.







Dae Young Kim               Expires 12/31/98                   [Page 64]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


                   |       |              |             |
      T-TERMINATE  |       | T-TERMINATE  | T-TERMINATE | T-TERMINATE
      indication   |       | indication   | indication  | indication
                  /|  U 0  |_ _ _ _ _ _ _ |_ _ _ _ _ _ _|
                /  |       |\             |\            |\
              /    |       |  \           |  \          |  \
            v      |       |    v         |    v        |    v
                   |       |              |             |


  Figure 24 - Sequence of primitives in TS-provider invocation of a TC
              termination

20.3.3 Simultaneous TC-owner and TS-provider invocation of a TC
       termination

  TC-owner may issue a T-TERMINATE request and at the same time TS-
  provider may issue a T-TERMINATE indication to terminate a TC.  The
  sequence of primitives is defined by Figure 25.

         \      |       |             |             |
           \    |       |             |             |
             \  |       |             |             |
               v|       |             |             |
    T-TERMINATE |       | T-TERMINATE | T-TERMINATE | T-TERMINATE
    request     |  U 0  | indication  | indication  | indication
                |       |_ _ _ _ _ _ _|_ _ _ _ _  __|
                |       |\            |\            |\
                |       |  \          |  \          |  \
                |       |    \        |    \        |    \
                |       |      v      |      v      |      v

  Figure 25 - Sequence of primitives in simultaneous TC-owner and TS-
              provider invocation of a TC termination

20.3.4 Unsuccessful TC Creation with multiple TS-user rejection(s)

  If the values of the TC-characteristics parameters in the T-CREATE
  responses from other TS-users do not satisfy the TC creation
  condition, T-TERMINATE indication primitives are delivered to the TC-
  owner and the TS-users who responded  with T-CREATE response
  primitive. The sequence of primitives is defined by Figure 26.









Dae Young Kim               Expires 12/31/98                   [Page 65]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


            \      |       |           |             |
              \    |       |           |             |
                \  |       |           |             |
     T-CREATE    v |       |           |             |
     request       |\      |           |             |
                   |  \    |T-CREATE   | T-CREATE    | T-CREATE
                   |    \  |indication | indication  | indication
                   |      \|- - - - - -|- - - - - - -|
                   |       |\          |\            |\
                   |       |  \        |  \          |  \
                   |       |    \      |    \        |   \
                   |       |     v     |     v       |    v
                   |       |           |             |
                   |       | T-LEAVE   | T-CREATE    | T-LEAVE
                   |       | request   | response    | request
                   |       |    /      |    /        |    /
                   |       |  /        |  /          |  /
                   |       |v_ _ _ _ _ |v_ _ _ _ _ _ |v
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|_ _ _ _ _ _|             |
     T-TERMINATE  /|       |           |\            |
     indication /  |       |           |  \          |
              /    |       |           |    \        |
             v     |       |           |      v      |
                   |       |           | T-TERMINATE |
                   |       |           | indication  |


  Figure 26 - Sequence of primitives in an unsuccessful TC Creation with
              multiple TS-user rejection(s)

20.3.5 Overall TS-user rejections of a TC creation attempt

  If all TS-users respond with T-LEAVE request primitive, the T-
  TERMINATE indication primitive is delivered to the TC-owner with the
  reason parameter. The sequence of primitives is defined by Figure 27.













Dae Young Kim               Expires 12/31/98                   [Page 66]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


            \      |       |           |             |
              \    |       |           |             |
                \  |       |           |             |
     T-CREATE    v |       |           |             |
     request       |\      |           |             |
                   |  \    |T-CREATE   | T-CREATE    | T-Create
                   |    \  |indication | indication  | indication
                   |      \|- - - - - -|- - - - - - -|
                   |       |\          |\            |\
                   |       |  \        |  \          |  \
                   |       |    \      |    \        |   \
                   |       |     v     |     v       |    v
                   |       |           |             |
                   |       | T-LEAVE   | T-LEAVE     | T-LEAVE
                   |       | request   | request     | request
                   |       |    /      |    /        |    /
                   |       |  /        |  /          |  /
                   |       |v_ _ _ _ _ |v_ _ _ _ _ _ |v
                   |      /|           |             |
                   |    /  |           |             |
                   |  @    |           |             |
                   |/      |           |             |
     T-TERMINATE  /|       |           |             |
     indication /  |       |           |             |
              /    |       |           |             |
             v     |       |           |             |

  Figure 27 - Sequence of primitives in overall TS-user rejections of a
              TC creation attempt

20.3.6 TS-provider rejection of a TC creation attempt due to lack of
       local resource

  If the TS-provider is unable to create a TC due to lack of local
  resource, it issues to the TC-owner a T-TERMINATE indication primitive
  with the reason parameter. The sequence of primitives is defined by
  Figure 28.














Dae Young Kim               Expires 12/31/98                   [Page 67]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


                    \    |        |          |           |
         T-CREATE     \  |        |          |           |
         request        v|        |          |           |
                         |        |          |           |
                         |        |          |           |
                         |        |          |           |
         T-TERMINATION   |        |          |           |
         indication      |        |          |           |
                        /|        |          |           |
                      /  |        |          |           |
                    /    |        |          |           |
                  v      |        |          |           |


  Figure 28 - Sequence of primitives in TS-provider rejection of a TC
              creation attempt

20.3.7 TS-provider rejection of a TC creation attempt due to
       incomplete TC-characteristics

  If the TS-provider is unable to create a TC due to incomplete TC-
  characteristics, it issues to all TS-users a T-TERMINATE indication
  primitive with the reason parameter. The sequence of primitives is
  defined by Figure 29.



























Dae Young Kim               Expires 12/31/98                   [Page 68]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


            \      |       |           |             |
              \    |       |           |             |
                \  |       |           |             |
     T-CREATE    v |       |           |             |
     request       |\      |           |             |
                   |  \    |T-CREATE   |T-CREATE     |T-CREATE
                   |    \  |indication |indication   |indication
                   |      \|- - - - - -|- - - - - - -|
                   |       |\          |\            |\
                   |       |  \        |  \          |  \
                   |       |    \      |    \        |   \
                   |       |     v     |     v       |    v
                   |       |           |             |
                   |       |T-CREATE   |T-CREATE     |T-CREATE
                   |       |reponse    |reponse      |reponse
                   |       |    /      |    /        |    /
                   |       |  /        |  /          |  /
                   |       |v_ _ _ _ _ |v_ _ _ _ _ _ |v
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|_ _ _ _ _ _|_ _ _ _ _ _ _|
     T-TERMINATE  /|       |\          |\            |\
     indication /  |       |  \        |  \          |  \
              /    |       |    \      |    \        |    \
            v      |       |      v    |      v      |      v
                   |       |T-TERMINATE| T-TERMINATE |T-TERMINATE
                   |       |indication | indication  |indication

  Figure 29 - Sequence of primitives in TS-provider rejection of a TC
              creation attempt due to incomplete TC-characteristics

21 TC-ownership service

21.1 Function

  The TC-ownership primitives can be used by the TC-owner and TS-users
  to pass the TC-ownership.

  The TC-ownership candidates are assumed to have been defined and known
  to the all TS-users.

21.2 Types of primitives and parameters

  Table 14 lists the types of primitives and parameters associated with
  the TC-ownership service.

21.2.1 Called address



Dae Young Kim               Expires 12/31/98                   [Page 69]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  The called address parameter may be a unicast TSAP address designating
  a specific TS-user or the group TSAP address designating the whole TS-
  users as candidate TC-owners.

          Table 14 - TC Ownership primitives and parameters

  +----------------+---------+----------+---------+---------+----------+
  |                | T-OWNER | T-OWNER  | T-OWNER |T-OWNER  | T-REPORT |
  |                | request |indication| repsonse|confirm  |indication|
  +----------------+---------+----------+---------+---------+----------+
  | Called address |    X    |   X(=)   |         |         |          |
  +----------------+---------+----------+---------+---------+----------+
  | Calling address|X(Note 1)|   X(=)   |         |         |          |
  +----------------+---------+----------+---------+---------+----------+
  | Responding     |         |          |         |         |          |
  | address        |         |          |    X    |X(Note 2)|          |
  +----------------+---------+----------+---------+---------+----------+
  | TS-user data   |  X(U)   |   X(=)   |   X(U)  |   X(=)  |          |
  +----------------+---------+----------+---------+---------+----------+
  | Reason         |         |          |         |         |X(Note 3) |
  +----------------+---------+----------+---------+---------+----------+

  NOTE 1 - This is the address of the TC-owner.

  NOTE 2 - This is the address of the new TC-owner.

  NOTE 3 - This may replicate the TS-user data of the T-OWNER confirm
           primitive.

21.2.2 Calling address

  The calling address parameter conveys the TSAP address of the TC-
  owner.

21.2.3 Responding address

  The responding address parameter conveys the address of the TSAP of
  the TS-user competing for the TC-ownership.

21.2.4 TS-user data

  The TS-user data parameter allows the transfer of TS-user data among
  old and new TC-owners.

21.2.5 Reason

  The reason parameter of the REPORT indication primitive conveys the
  result of the TC-Ownership service.



Dae Young Kim               Expires 12/31/98                   [Page 70]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


21.3 Sequence of primitives

21.3.1 Ownership transfer to a specified TS-user

  The sequence of primitives in a successful ownership transfer to a
  specified TS-user by a TC-owner is defined by Figure 30. Note that a
  confirm primitive is delivered only to the TC-owner who has previously
  issued the request primitive and other TS-users are supplied with a T-
  REPORT indication.

            \      |       |           |             |
              \    |       |           |             |
                \  |       |           |             |
     T-OWNER     v |       |           |             |
     request       |\      |           |             |
                   |  \    |           |             |
                   |    \  |T-OWNER    |             |
                   |      \|indication |             |
                   |       |\          |             |
                   |       |  \        |             |
                   |       |    \      |             |
                   |       |      v    |             |
                   |       |           |             |
                   |       |T-OWNER    |             |
                   |       |reponse    |             |
                   |       |    /      |             |
                   |       |  /        |             |
                   |       |v_ _ _ _ _ |             |
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|_ _ _ _ _ _|_ _ _ _ _ _ _|
     T-OWNER      /|       |\          |\            |\
     confirm    /  |       |  \        |  \          |  \
              /    |       |    \      |    \        |    \
            v      |       |      v    |      v      |      v
                   |       |T-REPORT   | T-REPORT    |T-REPORT
                   |       |indication | indication  |indication

  Figure 30 - Sequence of primitives in a successful TC ownership
              transfer to a specified TS-user

  The ownership transfer procedure may fail due to the rejection of the
  specified TS-user. In this case, the T-REPORT may not be delivered to
  other TS-users.

21.3.2 Ownership transfer to the whole TS-user candidates




Dae Young Kim               Expires 12/31/98                   [Page 71]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  The sequence of primitives in a successful ownership transfer to the
  whole TS-user candidates is defined by Figure 31. If only one TS-user
  among the candidates responds, the TS-user will be selected. However,
  if two or more TS-users among candidates respond, TS provider will
  select one TS-user, based on  predefined selection criteria. Note that
  a confirm  primitive is delivered only to the TC-owner who has
  previously issued the request primitive and other TS-users are
  supplied with a T-REPORT indication.

            \      |       |           |             |
              \    |       |           |             |
                \  |       |           |             |
     T-OWNER     v |       |           |             |
     request       |\      |           |             |
                   |  \    |T-OWNER    |T-OWNER      |T-OWNER
                   |    \  |indication |indication   |indication
                   |      \|- - - - - -|- - - - - - -|
                   |       |\          |\            |\
                   |       |  \        |  \          |  \
                   |       |    \      |    \        |   \
                   |       |     v     |     v       |    v
                   |       |           |             |
                   |       |T-OWNER    |T-OWNER      |T-OWNER
                   |       |response   |response     |response
                   |       |    /      |    /        |    /
                   |       |  /        |  /          |  /
                   |       |v_ _ _ _ _ |v_ _ _ _ _ _ |v
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|_ _ _ _ _ _|_ _ _ _ _ _ _|
     T-OWNER      /|       |\          |\            |\
     confirm    /  |       |  \        |  \          |  \
              /    |       |    \      |    \        |    \
            v      |       |      v    |      v      |      v
                   |       |T-REPORT   | T-REPORT    |T-REPORT
                   |       |indication | indication  |indication

  Figure 31 - Sequence of primitives in a successful TC owner selection
              among the TC-owner candidates

22 Token service

22.1 Function

  The TC Token primitives can be used by the TC-owner and other sending
  TS-users to pass around the token(s) for the right to transmit data.




Dae Young Kim               Expires 12/31/98                   [Page 72]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


22.2 Types of primitives and parameters

  Table 15 lists the types of primitives and parameters associated with
  the TC Token service.

              Table 15 - TC Token primitives and parameters

+-------+------+------+------+------+------+------+------+------+------+
|       |T-GIVE|T-GIVE|T-GIVE|T-GIVE|T-GET |T-GET |T-GET |T-GET |T-REPO|
|       |reques|indica|respon|confir|reques|indica|respon|confir|RT    |
|       |t     |tion  |se    |m     |t     |tion  |se    |m     |indica|
|       |      |      |      |      |      |      |      |      |tion  |
+-------+------+------+------+------+------+------+------+------+------+
|Called |      |      |      |      |      |      |      |      |      |
|address|  X   | X(=) |      |      |  X   | X(=) |      |      |      |
+-------+------+------+------+------+------+------+------+------+------+
|Calling|      |      |      |      |      |      |      |      |      |
|address|  X   | X(=) |      |      |  X   | X(=) |      |      |      |
+-------+------+------+------+------+------+------+------+------+------+
|Respond|      |      |      |      |      |      |      |      |      |
|ing    |      |      |  X   | X(=) |      |      |  X   | X(=) |      |
|address|      |      |      |      |      |      |      |      |      |
+-------+------+------+------+------+------+------+------+------+------+
|TS-user|      |      |      |      |      |      |      |      |      |
|data   | X(U) | X(=) | X(U) | X(=) | X(U) | X(=) | X(U) | X(=) |      |
+-------+------+------+------+------+------+------+------+------+------+
|Reason |      |      |      |      |      |      |      |      |   X  |
|       |      |      |      |      |      |      |      |      |(Note)|
+-------+------+------+------+------+------+------+------+------+------+

  NOTE - This may replicate the TS-user data of the T-GIVE or T-GET
         confirm primitive.

22.2.1 Called address

  The called address parameter may be the TSAP address of the TC-owner
  or a unicast TSAP address designating a specific sending TS-user.

22.2.2 Calling address

  The calling address parameter may be the TSAP address of the TC-owner
  or a unicast TSAP address of a sending TS-user.

22.2.3 Responding address

  The responding address parameter may be the TSAP address of the TC-
  owner or a unicast TSAP address of a sending TS-user.




Dae Young Kim               Expires 12/31/98                   [Page 73]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988

22.2.4 TS-user data

  The TS-user data parameter allows the transfer of TS-user data between
  the TC-owner and other TS-users.

22.2.5 Reason

  The reason parameter of the REPORT indication primitive conveys the
  result of the Token distribution service.

22.3 Sequence of primitives

22.3.1 Token distribution to a specified TS-user

  The sequence of primitives in a successful token distribution to a
  specified TS-user by a TC-owner is defined by Figure 32. Note that a
  confirm primitive is delivered only to the TC-owner who has previously
  issued the request primitive and other TS-users are supplied with a T-
  REPORT indication.

            \      |       |           |             |
              \    |       |           |             |
                \  |       |           |             |
     T-GIVE      v |       |           |             |
     request       |\      |           |             |
                   |  \    |T-GIVE     |             |
                   |    \  |indication |             |
                   |      \|- - - - - -|             |
                   |       |\          |             |
                   |       |  \        |             |
                   |       |    \      |             |
                   |       |      v    |             |
                   |       |           |             |
                   |       |T-GIVE     |             |
                   |       |response   |             |
                   |       |    /      |             |
                   |       |  /        |             |
                   |       |v_ _ _ _ _ |             |
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|_ _ _ _ _ _|_ _ _ _ _ _ _|
     T-GIVE       /|       |\          |\            |\
     confirm    /  |       |  \        |  \          |  \
              /    |       |    \      |    \        |    \
            v      |       |      v    |      v      |      v
                   |       |T-REPORT   | T-REPORT    |T-REPORT
                   |       |indication | indication  |indication

  Figure 32 - Sequence of primitives in a token distribution to a
              specified TS user by a TC-owner

Dae Young Kim               Expires 12/31/98                   [Page 74]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988




  The token distribution procedure may fail due to the rejection of the
  specified TS-user. In this case, the T-REPORT may not be delivered to
  other TS-users.

22.3.2 Token return from a specified TS-user

  The sequence of primitives in a successful token return from a
  specified TS-user to a TC-owner is defined Figure 33. Note that a
  confirm primitive is delivered only to the TS-user who has previously
  issued the request primitive and all TS-users except TC-owner are
  supplied with a T-REPORT indication.

  The token return procedure may fail due to the subnormal operation of
  the TC-owner. In this case, the T-REPORT may not be delivered to other
  TS-users.

                   |       |      /    |           |
                   |       |    /      |           |
                   |       |  /        |           |
                   |       |v          |           |
                   |      /|  T-GIVE   |           |
                   |    /  |  request  |           |
                   |  /    |           |           |
     T-GIVE        |/      |           |           |
     indication   /|       |           |           |
                /  |       |           |           |
              /    |       |           |           |
            v      |       |           |           |
                   |       |           |           |
                   |       |           |           |
            \      |       |           |           |
              \    |       |           |           |
     T-GIVE     \  |       |           |           |
     response     v|       |           |           |
                   |\      | T-GIVE    |           |
                   |  \@\  | confirm   |           |
                   |   \  \|           |           |
                   |    \  |\          |           |
                   |     \ |  v        |           |
                   |      \|_ _ _ _ _ _|_ _ _ _ _ _|
                   |       |\          |\          |\
                   |       |  \        |  \        |  \
                   |       |    v      |    v      |    v
                   |       |T-REPORT   |T-REPORT   |T-REPORT
                   |       |indication |indication |indication

  Figure 33 - Sequence of primitives in a token return to a TC-owner
              from a specified TS user

Dae Young Kim               Expires 12/31/98                   [Page 75]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988




22.3.3 Token retrieval from a specified TS-user

  The sequence of primitives in a successful token retrieval from a
  specified TS-user by a TC-owner is defined Figure 34. Note that a
  confirm primitive is delivered only to the TS-user who has previously
  issued the request primitive and all TS-users except the TC-owner are
  supplied with a T-REPORT indication.

            \      |       |           |             |
              \    |       |           |             |
                \  |       |           |             |
     T-GET       v |       |           |             |
     request       |\      |           |             |
                   |  \    |T-GET      |             |
                   |    \  |indication |             |
                   |      \|- - - - - -|             |
                   |       |\          |             |
                   |       |  \        |             |
                   |       |    \      |             |
                   |       |      v    |             |
                   |       |           |             |
                   |       |T-GET      |             |
                   |       |response   |             |
                   |       |    /      |             |
                   |       |  /        |             |
                   |       |v_ _ _ _ _ |             |
                   |     / |           |             |
                   |   @   |           |             |
                   |  / \  |           |             |
                   |/     \|_ _ _ _ _ _|_ _ _ _ _ _ _|
     T-GET        /|       |\          |\            |\
     confirm    /  |       |  \        |  \          |  \
              /    |       |    \      |    \        |    \
            v      |       |      v    |      v      |      v
                   |       |T-REPORT   | T-REPORT    |T-REPORT
                   |       |indication | indication  |indication


  Figure 34 - Sequence of primitives in a forced token return from a
              specified TS user by the TC-owner

  The token retrieval procedure may fail due to the subnormal operation
  of the specified TS-user. In this case, the T-REPORT may not be
  delivered to other TS-users.





Dae Young Kim               Expires 12/31/98                   [Page 76]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


22.3.4 Token request from a TS-user

  The sequence of primitives in a successful token request from a TS-
  user to a TC-owner is defined by Figure 35. Note that a confirm
  primitive is delivered only to the TS-user who has previously issued
  the request primitive and all TS-users except TC-owner are supplied
  with a T-REPORT indication.

  The token request procedure may fail due to the rejection of TC-owner.
  In this case, the T-REPORT may not be delivered to other TS-users.

                   |       |      /    |           |
                   |       |    /      |           |
                   |       |  /        |           |
                   |       |v          |           |
                   |      /|  T-GET    |           |
                   |    /  |  request  |           |
                   |  /    |           |           |
     T-GET         |/      |           |           |
     indication   /|       |           |           |
                /  |       |           |           |
              /    |       |           |           |
            v      |       |           |           |
                   |       |           |           |
                   |       |           |           |
            \      |       |           |           |
              \    |       |           |           |
     T-GET      \  |       |           |           |
     response     v|       |           |           |
                   |\      | T-GET     |           |
                   |  \@\  | confirm   |           |
                   |   \  \|           |           |
                   |    \  |\          |           |
                   |     \ |  v        |           |
                   |      \|_ _ _ _ _ _|_ _ _ _ _ _|
                   |       |\          |\          |\
                   |       |  \        |  \        |  \
                   |       |    v      |    v      |    v
                   |       |T-REPORT   |T-REPORT   |T-REPORT
                   |       |indication |indication |indication


  Figure 35 - Sequence of primitives in a token acquisition by a
              specified TS-user from the TC-owner







Dae Young Kim               Expires 12/31/98                   [Page 77]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


                                Annex A

                       TC Ordering Relationships

      (This annex forms an integral part of this Recommendation |
                        International Standard.)

A.1 Properties of ordering

  It applies at the service level and at the protocol level. At the
  service level, the service provider may be required to  provide
  guarantees regarding the order in which TSDUs are delivered to the
  receiving TS-users. At the protocol level, TPDUs are ordered, or
  reordered to achieve the ordering property required by the service.

  The following notation is used to describe the ordering relationships:

    - S_i(m): Local event of sending a TSDU m at site i,

    - A_j(m): Local event of accepting a TSDU m at site j,

    - P -->Q: "An event P happens before an event Q,"

    - P ==>Q: "If P is TRUE, then Q is to be TRUE,"

    - P=/=>Q: "If P is TRUE, then Q does not need to be TRUE."

A.1.1 No ordering

  TS-provider does not guarantee any relationship between TSDUs sent
  from a single sending TS-user or from multiple sending TS-users.

  Notation: S_p(m) -->S_q(m') =/=> A_i(m) --> A_i(m')

                    for all p,q,i;

                    for all (m,m') pairs.

A.1.2 Local ordering

  The TSDUs, generated by a particular sending TS-user, are delivered to
  all of the receiving TS-users in the same order in  which they were
  generated. Local ordering does not establish any ordering relationship
  among TSDUs generated by different sending TS-users.

  Notation: S_p(m) -->S_p(m') =/=> A_i(m) --> A_i(m')

                    for all p,i;



Dae Young Kim               Expires 12/31/98                   [Page 78]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


                    for all (m,m') pairs.

  But, the following constraint also applies:

  Notation: S_p(m) -->S_p(m') ==> A_i(m) --> A_i(m')

                    for any given p,i pair,

                    for all (m,m') pairs.

A.1.3 Causal ordering

  The causal ordering orders the TSDUs generated by all sending TS-users
  according to the causal dependence relationship among the sending
  events. A causal dependence relationship is established between two
  sending events, A and B, if the following applies:

    a) A happens before B if A and B are sending events generated by the
       same sending TS-user and A is sent before B;

    b) A happens before B if A and B are sending events generated by two
       different sending TS-users and the TSDUs generated by the event A
       by one sending TS-user is received by the other sending TS-user
       before it generates the event B.

  A causal dependence relationship is established among more than two
  sending events if it can be established that A happens before B, and
  that B happens before C, it therefore follows that A happens before C.
  A causal dependence relationship cannot be established between the two
  sending events A and C if there is no possibility to establish that A
  happens before B and that B happens before C.

  If the arbitrary ordering rule is set by the TS-provider for all
  receivers,

  Notation: ( S_p(m) -->A_q(m) --> S_q(m') ) OR ( S_q(m)--> S_q(m') )
            ==> A_i(m) --> A_i(m')

                    for all p, q, i;

                    for all (m,m') pairs.

A.1.4 Partial ordering

  The TSDUs, generated by all sending TS-users are delivered to each
  receiving TS-user according to an arbitrary ordering rule.

  If the TSDUs are ordered according to a rule applicable to all



Dae Young Kim               Expires 12/31/98                   [Page 79]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


  receiving TS-users, then each receiving TS-user receives the TSDUs
  generated by all the sending TS-users in the same order. If the TSDUs
  are ordered according to a rule determined by each receiving TS-user,
  then each receiving TS-user may receive the TSDUs in different orders.

  Notation: If the arbitrary ordering rule is set by the TS-provider
               for all receivers,

            then S_p(m) -->S_q(m') =/=> A_i(m) --> A_i(m')

                    for all i;

                    for some p, q;

                    for all (m,m') pairs.

            or

            if the arbitrary ordering rule is set independently by each
               receiving TS-user,

            then S_p(m) -->S_q(m') =/=> A_i(m) --> A_i(m')

                    for some i, p, q;

                    for some (m,m') pairs.

A.1.5 Total ordering

  The TSDUs, generated by all sending TS-users, are delivered to each
  receiving TS-user in the same order. Every receiving TS-user sees all
  TSDUs from all sending TS-users in exactly the same order.

  Notation: S_p(m) -->S_q(m') ==> A_i(m) --> A_i(m')

                    for all p,q,i;

                    for all (m,m') pairs.













Dae Young Kim               Expires 12/31/98                   [Page 80]


INTERNET-DRAFT       draft-kim-jtc1-sc6-ects-04.txt          30 Jun 1988


                                 Annex B

                               Bibliography

   (This annex does not form an integral part of this Recommendation |
                         International Standard.)

  Many documents and papers have contributed to the construction of this
  Recommendation | International Standard, some  of which are:

    - ISO/IEC JTC1/SC6, Draft on Multi-peer Taxonomy, P 01.06.36 (ECFF),
      Oct. 14, 1994.

    - ISO/IEC JTC1/SC6 N8693, Draft Multicast Taxonomy of Multicast
      Operation, P 01.06.36 (ECFF), Jan. 17, 1994.

    - Laurent Mathy, Guy Leduc, Olivier Bonaventure, and Andrea
      Danthine, A Framework for Group Communication, RACE 2060, CIO,
      Aug., 1994,

    - Christophe Diot, Patrick Cocquet, and Didier Stunault,
      Specifications of ETS, the Enhanced Transport Service, May 1992.

    - Yves Baguette, ULg, Enhanced Transport Service Definition, RACE
      2060, CIO, Feb. 5, 1994.

    - Lutz Henckel, Multipeer Connection-mode Transport Service
      Definition based on the Group Communication Framework, RACE 2060,
      CIO, June, 1994.

    - ITU-T X.tms (1993E), Information Technology - Open Systems
      Interconnection - Multicast Transport Service Definition.

    - Helene Maisonniaux and Patrick Cocquet, Multi-peer Transport
      Service, 4B22, July 25, 1995.
















Dae Young Kim               Expires 12/31/98                   [Page 81]