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 _/ +---------+ +-----------+|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 | +---------+ +-----------+|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 | +---------+ +-----------+|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]