INTERNET-DRAFT D. Y. KIM draft-kim-jtc1-sc6-ects-02.txt Chungnam Univ. 31 JUL. 1997 Expires: 31/1/1998 Enhanced Communications Transport Service Definition Status of this Memo This 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 reliability and multicast QoS. Dae Young Kim Expires 1/31/98 [page 1]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 CONTENTS Page Introduction..........................................................3 1 Scope.........................................................5 2 Normative references..........................................5 3 Definitions...................................................6 4 Abbreviations................................................10 5 Conventions..................................................11 6 Overview and general characteristics.........................11 7 Features of the Enhanced Communication Transport Service.....12 8 Model of the Enhanced Communications Transport Service.......13 9 Transport Connection characteristics.........................16 10 Quality-of-Service (QoS) for Transport Connections...........18 11 Enhanced Communications Transport Service Primitives and Parameters...................................................33 12 TC Creation service..........................................40 13 TC Invitation service........................................42 14 TC Join service..............................................44 15 Data Transfer service........................................48 16 Pause service................................................51 17 Resume service...............................................52 18 Report service...............................................53 19 TC Leave service.............................................55 20 TC Termination service.......................................59 21 TC-ownership service.........................................65 22 Token service................................................69 Annex A..............................................................75 Annex B..............................................................78 Dae Young Kim Expires 1/31/98 [page 2]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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.. 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. T. 120 applications rely on MCS (Multicast Connection Service, T.122) and MCSP (MCS Protocol , T.125) for support of the multicast capability. An architectural consequence is that an additional layer called MCS Layer exists between the Application and the Transport Layer. Use of MCS is mandatory for T.120 applications. One immediate contrast with ECTS is that MCS does not support QoS negotiation. In this sense, MCS lacks in a very important feature of ECTS, i.e., enhanced QoS. And no less importantly, MCS is based on the assumption that the underlying transport protocol supports only unicast service. This is too pessimistic an assumption in network environments of the present and especially of the future. Internet provides the multicast communication capability by IP multicast; X.25 is also geared to provide multicast by use of X.6; ATM is being engineered to provide the multicast capability. It is presumed that the multicast capability will be the prime requisite of any significant future network infrastructures. Also, transport protocols are not any more unicast only; a lot of reliable multicast transport protocols are being introduced, e.g., MTP, RMP, and SRM as shown in Figure 1. Because MCS did not expect these multicast protocols underneath, yet another additional convergence protocol called MAP (Multicast Adaptation Protocol) is needed to fully utilize their capabilities and so is defined in the revision of T.125. This added redundancy is a significant mismatch with competitive network environments where the multicast capability will prevail. Dae Young Kim Expires 1/31/98 [page 3]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 For those networks which cannot be amended with added multicast capability, use of MCS will continue to be justified. But for multicast networks and any point-to-point networks to which the multicast capability can be easily added, use of ECTS will provide far more simple and efficient access to the underlying network communication resource. 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. +----------+ +---------------+ +---+ +------------+ +--------+ |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| |RMP| |SRM| |RTP| |X.224| .... |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 1/31/98 [page 4]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 Enhanced Communications Transport Protocols (in conjunction with the Network Service) and which may be used by any application protocol, including the OSI Session Protocol. 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 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 implications 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. Dae Young Kim Expires 1/31/98 [page 5]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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. 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. Dae Young Kim Expires 1/31/98 [page 6]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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; b) QoS mechanism; c) QoS parameter. Dae Young Kim Expires 1/31/98 [page 7]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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. 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) Quality of Service level of agreement: The level of agreement reached during the Quality of Service negotiation between users and the provider. It may be best-effort, compulsory, 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. 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. Dae Young Kim Expires 1/31/98 [page 8]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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. 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. Dae Young Kim Expires 1/31/98 [page 9]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 4 Abbreviations AGI Active group integrity CHQ Controlled highest quality ECTS Enhanced Communications Transport Service 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 Dae Young Kim Expires 1/31/98 [page 10]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 5 Conventions 5.1 General conventions 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 23. 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 primitive is always identical to that supplied in the previous request primitive issued at the peer service access point. 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) Quality of Service selection: The Transport Layer is required to optimize the use of available communications resources to provide the Quality of Service required by communicating TS-users at the minimum cost. Quality of Service requirements are specified through the selection of values for Quality of Service parameters. Dae Young Kim Expires 1/31/98 [page 11]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 b) Independence of underlying communications resources: The Transport Service hides from TS-users the difference in the Quality of Service provided by the Network Service. This difference in Quality of Service 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 Communication 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 enrollment. Refinement of some of these QoS agreements may occur during the create operation and others may be initially determined at that time. Dae Young Kim Expires 1/31/98 [page 12]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 but 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: 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. Dae Young Kim Expires 1/31/98 [page 13]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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 member 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 of the group members A to F. 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. Dae Young Kim Expires 1/31/98 [page 14]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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 1/31/98 [page 15]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 9 Transport Connection characteristics 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; f) Atomic: condition wherein all of enrolled group members are required to be present in the active group. 9.1.3 TC type The types eligible for a group will be one or more of the followings: a) Simplex TC; b) Duplex TC; c) N-plex TC. Dae Young Kim Expires 1/31/98 [page 16]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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 - 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. Dae Young Kim Expires 1/31/98 [page 17]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 (QoS) 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 | | +-----------------+----------------+---------------------------------+ | 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 | +-----------------+----------------+---------------------------------+ Dae Young Kim Expires 1/31/98 [page 18]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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. Dae Young Kim Expires 1/31/98 [page 19]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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; d) lossy and corrupted. Table 2 shows the four TC reliability policies and the associated meaningful error rates. 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) | | +------------+--------------+--------------+------------------------+ Dae Young Kim Expires 1/31/98 [page 20]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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. 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 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.3 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. Dae Young Kim Expires 1/31/98 [page 21]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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. Theordering 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 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. Dae Young Kim Expires 1/31/98 [page 22]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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. Dae Young Kim Expires 1/31/98 [page 23]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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). 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. Dae Young Kim Expires 1/31/98 [page 24]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 TC-owner-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 L'max < LQA < OT < CHQ < U"min. Typically, LQA will be close to L'max, CHQ to U"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 then requirements of all TS-users since Dae Young Kim Expires 1/31/98 [page 25]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 LQAo < LQAi' < L'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 the following figure. 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 Dae Young Kim Expires 1/31/98 [page 26]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 clause 10.3.1 with the TC-owner as the focal TS-user: 1. The TC-owner issues a T-CREATE request, multicast, containing a 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 TC-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 TS-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. Dae Young Kim Expires 1/31/98 [page 27]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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 < 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 clause 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 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. Dae Young Kim Expires 1/31/98 [page 28]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 - 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. Dae Young Kim Expires 1/31/98 [page 29]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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.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. NOTE 1: Should we say that it is inappropriate to negotiate any characteristic at a guaranteed level for a TC that does not have maximum precedence. If not, what happens when there is a conflict? Which wins, the guarantee or the precedence? QoS parameters of ECTS Service Primitives This clause identifies the general set of QoS parameters used in ECTS Service Primitives in order to impose or negotiatem 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 in 10.2.2, including the 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, threshold - type of agreement required, i.e. best efforts, compulsory or guaranteed - negotiation type, i.e. connection-wide/receiver-selected - values as defined in the negotiation mechanism employed Dae Young Kim Expires 1/31/98 [page 30]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 - 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. connection-wide or receiver-selected, that is required. If connection-wide negotiation is required for a value (operating target, LQA or threshold) 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. Dae Young Kim Expires 1/31/98 [page 31]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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 | R, V | V | SV | +--------------------------+------------+------------+----------+ | TC Protection | R, V | V | SV | +--------------------------+------------+------------+----------+ | TC precedence | R, V | V | SV | +--------------------------+------------+------------+----------+ Legend: R A range of values may be agreed V A specific value may be negotiated SV A specific value may be negotiated or imposed SP Determined by the security policy in force I Imposed N Not subject to further agreement, already known. Dae Young Kim Expires 1/31/98 [page 32]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 11 Enhanced Communications Transport Service primitives and parameters 11.1 Definitions This clause defines the service primitives and the associated parameters which are used in ECTS. Detailed descriptions of these primitives are given in Clauses 12 to 16. 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 | (Called address, Responding address, | | | response | TC-characteristics, TS-user data) | | | T-CREATE | (Called address, Responding address, | | | confirm | TC-characteristics, 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 | (Called address, Responding address, | | | response | TC-characteristics, TS-user data) | | | T-JOIN | (Called address, Responding address, | | | confirm | TC-characteristics, 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 | | +------------+--------------+----------------------------------------+ Dae Young Kim Expires 1/31/98 [page 33]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 +------------+--------------+----------------------------------------+ | TC leave | T-LEAVE | (Called address, Calling address, | | | request | Reason, TS-user data) | | | T-LEAVE | (Called address,Reason) | | | request | | +------------+--------------+----------------------------------------+ | TC | T-TERMINATE | (Reason, TS-user data) | | termination| request | | | | T-TERMINATE | (Reason, TS-user data) | | | request | | +------------+--------------+----------------------------------------+ | TC- | T-OWNER | (Called address, Calling address, | | ownership | request | TS-user data) | | | T-OWNER | (Called address, Calling address, | | | indication | TS-user data) | | | T-OWNER | (Called address, Responding address, | | | response | TS-user data) | | | T-OWNER | (Called address, Responding address, | | | confirm | TS-user data) | +------------+--------------+----------------------------------------+ | Token give | T-GIVE | (Called address, Calling address, | | | request | TS-user data) | | | T-GIVE | (Called address, Calling address, | | | indication | TS-user data) | | | T-GIVE | (Called address, Responding address, | | | response | TS-user data) | | | T-GIVE | (Called address, Responding address, | | | confirm | TS-user data) | | Token get | T-GET | (Called address, Calling address, | | | request | TS-user data) | | | T-GET | (Called address, Calling address, | | | indication | TS-user data) | | | T-GET | (Called address, Responding address, | | | response | TS-user data) | | | T-GET | (Called address, Responding address, | | | confirm | TS-user data) | +------------+--------------+----------------------------------------+ 11.2 Sequence of primitives at a TSAP This clause defines the constraints on the sequences in which the primitives defined in Clauses 12-16 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-16. Dae Young Kim Expires 1/31/98 [page 34]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 The possible overall sequences of primitives at a TSAP are defined in the state transition diagram Figures 5 and 6. In the diagram: 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 1/31/98 [page 35]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 +--------+ +--------+ | | T-INVITE request | | | Idle |====================>| Invite | | | T-INVITE indication | | +--------+ +--------+ A 1 A 1 A T-TERMINATE 1 1 \ T-JOIN 1 1 T-TERMINATE request(Note) 1 1 \_ request 1 1 request(Note) T-TERMINATE 1 1 \ 1 1 T-TERMINATE indication 1 1 \ 1 1 indication T-LEAVE 1 1 \ 1 1 T-LEAVE request 1 1 T-CREATE \ 1 1 request T-LEAVE 1 1 request \ T-TERMINATE 1 1 T-LEAVE indication 1 1 \ request(Note) 1 1 indication 1 V \ T-TERMINATE V 1 +--------+ 1 indication+--------+ |Outgoing| 1 T-LEAVE |Outgoing|<======+ |Create | 1 request |Join | 1 |Pending | 1 T-LEAVE |Pending |=======+ +--------+ 1 indication+--------+ T-INVITE.req \ 1 / uest(Note1) \ 1 / T-CREATE.confirm \ 1 / T-JOIN.confirm \ 1 / T-PAUSE. \_ V _/ T-JOIN. +---------+ indication \>+--------+</ indication+----------+ | Data |<=============| Data |=============>|Incoming | | Transfer| |Transfer| | Join | |suspended|=============>| |<=============|processing| +---------+ T-RESUME. +--------+ T-JOIN. +----------+ 1 A indication 1 A response 1 A 1 1 1 1 1 1 +=====+ +====+ +======+ T-INVITE.request T-INVITE.request T-INVITE.request T-INVITE.indication T-INVITE.indication T-INVITE.indication T-DATA.request T-DATA.indication T-REPORT.indication NOTE 1 - This transition applies only to the TC-owner. NOTE 2 - All states except the Data Transfer suspended includes a self -loop branch due to UNITDATA request and UNITDATA indication; UNITDATA request and indication primitives may occur at such states without causing transition to other states. Figure 5 - State transition diagram of a TC-owner or a focal TS-user Dae Young Kim Expires 1/31/98 [page 36]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 +--------+ +--------+ +=========>| | T-INVITE indication | | 1 T-JOIN | Idle |====================>| Invite | 1 request | | | | T-TERMINATE1 +========| |<===========\ | | indication 1 1 +--------+ \ +--------+ T-LEAVE 1 1 / A A A A \ 1 request 1 1 T-CREATE 1 1 1 1_ \ 1 T-JOIN T-LEAVE 1 1 indicatio 1 1 \_ \ 1 indication indication 1 1 / / 1 1 \_ \ 1 1 1 V / 1 1 \_ \ V 1 1 +--------+ 1 \ \_ \ +--------+ 1 1 |Incoming| 1 1 \_ >|Incoming| / 1 | Create | 1 1 T-LEAVE \_ | Join | / / | pending| 1 1 request \ | pending| / / +--------+ 1 1 T-LEAVE \ +--------+ 1 1 1 1 \ indication \ 1 1 1 T-CREATE 1 1 1 T-TERMINATE \ 1 T-JOIN V V response 1 1 1 indication \ 1 response +----------+ 1 1 1 \ 1 | Join | 1 1 1 \---+ 1 |processing| V V 1 V V +----------+ +----------+ 1 +----------+ 1 | Outgoing | 1 | Outgoing | 1 | Create | 1 | Join | 1 | pending | 1 +==================| pending | 1 +----------+ 1 1 T-JOIN.confirm +----------+ 1 1 1 1 T-JOIN 1 T-CREATE 1 1 1 confirm1 confirm 1 1 1 1 1 1 1 1 V V V 1 +---------+ T-PAUSE.indication+------------+ 1 | Data |==================>| Data | +===============>| Transfer|<==================| Transfer | | | T-RESUME | suspended | +---------+ indication +------------+ 1 A 1 A 1 1 1 1 +=====+ +========+ T-INVITE.indication T-INVITE.indication T-DATA.request T-DATA.indication T-REPORT.indication NOTE - All states except the Data Transfer suspended includes a self- loop branch due to UNITDATA request and UNITDATA indication; UNITDATA request and indication primitives may occur at such states without causing transition to other states. Figure 6 - State transition diagram of a non-focal TS-user Dae Young Kim Expires 1/31/98 [page 37]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 The following table presents the allowed sequence of primitives by showing which TS primitives may follow other primitives. Table 5 - Sequence of primitives at a TSAP T-TERMINATE.indication ----------------------------------------------+ T-TERMINATE.request -----------------------------------------------+ | T-LEAVE.indication ----------------------------------------------+ | | T-LEAVE.request -----------------------------------------------+ | | | T-REPORT.indication -----------------------------------------+ | | | | T-RESUME.indication ---------------------------------------+ | | | | | T-PAUSE.indication --------------------------------------+ | | | | | | T-DATA.indication -------------------------------------+ | | | | | | | T-DATA.request --------------------------------------+ | | | | | | | | T-JOIN.confirm ------------------------------------+ | | | | | | | | | T-JOIN.response ---------------------------------+ | | | | | | | | | | T-JOIN.indication -----------------------------+ | | | | | | | | | | | T-JOIN.request ------------------------------+ | | | | | | | | | | | | T-INVITE.indication -----------------------+ | | | | | | | | | | | | | T-INVITE.request ------------------------+ | | | | | | | | | | | | | | T-CREATE.confirm ----------------------+ | | | | | | | | | | | | | | | T-CREATE.response -------------------+ | | | | | | | | | | | | | | | | T-CREATE.indication ---------------+ | | | | | | | | | | | | | | | | | T-CREATE.request ---------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | he TS primitive X | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | may be followed | | | | | | | | | | | | | | | | | | | | | by the TS primitive Y | | | | | | | | | | | | | | | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-CREATE.request | | | | | | | | | | | | | | | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-CREATE.indication | | | | | | | | | | | | | | | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-CREATE.reponse | |*| | | | | | | | | | | | | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-CREATE.confirm |*| | | | | | | | | | | | | | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-INVITE.request | | | | | | |*|*|*|*|*|*|*|*|*| |*| | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-INVITE.indication | | | | | | | |*|*|*|*|*|*|*|*|*|*| | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-JOIN.request | | | | |*|*| | | | | |*| |*| | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-JOIN.indication | | | | |*|*| | | | |*|*| |*| | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-JOIN.response | | | | | | | |*| | | | | | | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-JOIN.confirm | | | | | | |*| | | | | | | | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dae Young Kim Expires 1/31/98 [page 38]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 T-TERMINATE.indication ----------------------------------------------+ T-TERMINATE.request -----------------------------------------------+ | T-LEAVE.indication ----------------------------------------------+ | | T-LEAVE.request -----------------------------------------------+ | | | T-REPORT.indication -----------------------------------------+ | | | | T-RESUME.indication ---------------------------------------+ | | | | | T-PAUSE.indication --------------------------------------+ | | | | | | T-DATA.indication -------------------------------------+ | | | | | | | T-DATA.request --------------------------------------+ | | | | | | | | T-JOIN.confirm ------------------------------------+ | | | | | | | | | T-JOIN.response ---------------------------------+ | | | | | | | | | | T-JOIN.indication -----------------------------+ | | | | | | | | | | | T-JOIN.request ------------------------------+ | | | | | | | | | | | | T-INVITE.indication -----------------------+ | | | | | | | | | | | | | T-INVITE.request ------------------------+ | | | | | | | | | | | | | | T-CREATE.confirm ----------------------+ | | | | | | | | | | | | | | | T-CREATE.response -------------------+ | | | | | | | | | | | | | | | | T-CREATE.indication ---------------+ | | | | | | | | | | | | | | | | | T-CREATE.request ---------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-DATA.request | | | |*| | | | | |*|*|*| |*|*| | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-DATA.indication | | | |*| | | | | |*|*|*| |*|*| | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-PAUSE.indication | | | |*| | | | | |*|*|*| |*|*| | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-RESUME.indication | | | | | | | | | | | | |*| | | | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-REPORT.indication | | |*|*| | | | |*|*|*|*| |*|*| | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-LEAVE.request |*|*|*|*| | |*|*|*|*|*|*|*|*|*| | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-LEAVE.indication |*|*|*|*| | |*|*|*|*|*|*|*|*|*| | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-TERMINATE.request |*| | |*| | |*|*|*|*|*|*|*|*|*| | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-TERMINATE.indication |*|*|*| | | |*|*|*|*|*|*|*|*|*| | | | | +-------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NOTE - T-TERMINATE request primitive applies only to the TC-owner. NOTE - T-UNITDATA request and indication primitives are omitted in this table. They can follow and be followed by any primitives but two; they cannot follow a PAUSE indication primitive and cannot be followed by a RESUME indication primitive. Dae Young Kim Expires 1/31/98 [page 39]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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. 12.2 Types of primitives and parameters The following table lists the types of primitives and parameters associated with a TC creation Table 6 - TC creation primitives and parameters +----------------+---------+----------+---------+---------+----------+ | |T-CREATE | T-CREATE |T-CREATE |T-CREATE | T-REPORT | | | request |indication| reponse | confirm |indication| +----------------+---------+----------+---------+---------+----------+ | Called address | X | X(=) |X(Note 1)| X(=) |X(Note 4) | +----------------+---------+----------+---------+---------+----------+ | Calling address|X(Note 2)| X(=) | | |X(Note 1) | +----------------+---------+----------+---------+---------+----------+ | Responding | | | | | | | address | | |X(Note 2)|X(Note 3)| | +----------------+---------+----------+---------+---------+----------+ | TC | | | | | | | characteristics| X | X | X |X(Note 5)| | +----------------+---------+----------+---------+---------+----------+ | TS-user data | X(U) | X(=) | X(U) | X(=) | | +----------------+---------+----------+---------+---------+----------+ | Reason | | | | |X(Note 5) | +----------------+---------+----------+---------+---------+----------+ NOTE 1 - This is the unicast address of the TC-owner. NOTE 2 - This parameter may be implicitly associated with the TSAP at which the primitive is issued. NOTE 3 - This is a list of addresses of the responding TS-users. NOTE 4 - This is the address of the group. NOTE 5 - This includes the OA QoS values. Dae Young Kim Expires 1/31/98 [page 40]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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 the following time sequence diagram. 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 1/31/98 [page 41]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | 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 7 - 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 simplex TCs, each by every focal TS-user through Join primitives. Thus, the TC Invitation service is normally followed by the TC Join service. Dae Young Kim Expires 1/31/98 [page 42]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 The following table lists the types of primitives and parameters associated with a TC invitation. Table 7 - 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 The called address parameter conveys a TSAP address that identifies the TS-user(s) expected to participate in the heterogeneous TC being established. 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. 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. Dae Young Kim Expires 1/31/98 [page 43]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 13.3 Sequence of primitives The sequence of primitives in a TC Invitation is defined by the following time sequence diagram. Note that the TC invitation primitives are normally followed each by a JOIN request primitive defined below, thus initiating the Join service. \ | | | | \ | | | | 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 8 - 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. 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. 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. Dae Young Kim Expires 1/31/98 [page 44]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 14.2 Types of primitives and parameters The following table lists the types of primitives and parameters associated with a TC Join. Table 8 - TC creation primitives and parameters +----------------+---------+----------+---------+---------+----------+ | | T-JOIN | T-JOIN | T-JOIN | T-JOIN | T-REPORT | | | request |indication| reponse | confirm |indication| +----------------+---------+----------+---------+---------+----------+ | Called address | X | X(=) |X(Note 1)| X(=) |X(Note 4) | +----------------+---------+----------+---------+---------+----------+ | Calling address|X(Note 2)| X(=) | | |X(Note 1) | +----------------+---------+----------+---------+---------+----------+ | Responding | | | | | | | address | | |X(Note 2)|X(Note 3)| | +----------------+---------+----------+---------+---------+----------+ | TC | | | | | | | characteristics| X | X | X |X(Note 5)| | +----------------+---------+----------+---------+---------+----------+ | TS-user data | X(U) | X(=) | X(U) | X(=) | | +----------------+---------+----------+---------+---------+----------+ | Reason | | | | |X(Note 5) | +----------------+---------+----------+---------+---------+----------+ NOTE 1 - This is the unicast address of the focal TS-user. NOTE 2 - This parameter may be implicitly associated with the TSAP at which the primitive is issued. NOTE 3 - This is a list of addresses of the responding TS-users. NOTE 4 - This is the address of the group. NOTE 5 - This includes the OA QoS values. 14.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 created . 14.2.2 Calling address The calling address parameter conveys the TSAP address of the TC-owner by whom the TC creation has been requested. 14.2.3 Responding address 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. Dae Young Kim Expires 1/31/98 [page 45]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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. 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. 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 OA arbitrated QoS values. 14.3 Sequence of primitives The sequence of primitives in a successful TC creation is defined by the following time sequence diagrams. Note that a confirm primitive is delivered only to the TS-user who has previously issue the request primitive and other TS-users are supplied with a T-REPORT indication. Dae Young Kim Expires 1/31/98 [page 46]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | 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 9 - Sequence of primitives in a successful TC Join by a focal TS-user Dae Young Kim Expires 1/31/98 [page 47]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 | | / | | | | / | | | |v | | | \| T-JOIN | | | \ | request | | T-JOIN | \ | | | \| | | | / | | | | / | | | | v | | | | | | | | | | | | \ | | | | \ | | | | T-JOIN \ | | | | response v| | | | |\ | T-JOIN | | | \@\ | confirm | | | \ \| | | | \ |\ | | | \ | v | | | \|_ _ _ _ _ _|_ _ _ _ _ _| | |\ |\ |\ | | \ | \ | \ | | v | v | v | |T-REPORT |T-REPPRT |T-REPORT | |indication |indication |indication Figure 10 - 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 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. 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) of the TC. 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. Dae Young Kim Expires 1/31/98 [page 48]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 15.2 Types of primitives and parameters Table 9 - 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 | | | 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. Dae Young Kim Expires 1/31/98 [page 49]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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) participating in the TC, without modification by the TS-provider. 15.3 Sequence of TS primitives The sequence of primitives in a successful data transfer is defined in the following time sequence diagram. \ | | | | \ | | | | v | | | | T-DATA |\ | | | request | \ | T-DATA | T-DATA | T-DATA | \ | indication| indication| indication | \|_ _ _ _ _ _|_ _ _ _ _ _| | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | Figure 11 - Sequence of primitives in data transfer using DATA primitives Dae Young Kim Expires 1/31/98 [page 50]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | v | | | | |\ | | | T-UNITDATA | \ |T-UNITDATA |T-UNITDATA |T-UNITDATA request | \ | indication| indication| indication | \|_ _ _ _ _ _|_ _ _ _ _ _| | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | Figure 12 - Sequence of primitives in data transfer using UNITDATA primitives 16 Pause service 16.1 Function 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 The following table indicates the types of primitives and the parameters for the Pause service. Table 10 - Pause primitives and parameters +----------------------+------------------------+ | | T-PAUSE | | | indication | +----------------------+------------------------+ | Reason | X | +----------------------+------------------------+ Dae Young Kim Expires 1/31/98 [page 51]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 | | | | T-PAUSE | | T-PAUSE | T-PAUSE | T-PAUSE indication | | indication | indication | indication /| U 0 |- - - - - - -|- - - - - - -| / | |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | Figure 13 - Sequence of primitives in TS-provider invoked suspension of data transfer 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 The following table indicates the types of primitives and the parameters for the Resume service. Table 11 - Resume primitives and parameters +-------------------------+------------------------+ | | T-RESUME | | | indication | +-------------------------+------------------------+ | Reason | X | +-------------------------+------------------------+ Dae Young Kim Expires 1/31/98 [page 52]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 17.3 Sequence of primitives The sequence of primitives in the resumption of a previously suspended data transfer is defined in the following time sequence diagram. | | | | | | | | T-RESUME | | T-RESUME | T-RESUME | T-RESUME indication | | indication | indication | indication /| U 0 |- - - - - - -|- - - - - - -| / | |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | Figure 14 - Sequence of primitives in TS-provider resumption of data transfer 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-characteristics 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 The following table indicates the types of primitives and the parameters for the Report service. Dae Young Kim Expires 1/31/98 [page 53]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 Table 12 - Report primitives and parameters +-----------------------+------------------------+ | | T-REPORT | | | indication | +-----------------------+------------------------+ | Calling address | X | +-----------------------+------------------------+ | Reason | X | +-----------------------+------------------------+ | TS-user data | X | +-----------------------+------------------------+ 18.2.2 Calling Address The calling address parameter conveys the TSAP address of the TS-user from which the TS-user data originated. If the report has been initiated by a pure TS-provider action, this parameter conveys the address of the TS-user associated with the originating protocol entity. Otherwise, this parameter carries a null value. 18.2.3 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. 18.2.4 TS-user data The TS-user data parameter conveys a) the data of the remote TS-user, or b) the arbitrated TC-characteristics in TC establishments, or c) additional information provided by the TS-provider NOTE - The TS-provider may provide additional information (e.g., accounting) for management purposes. Dae Young Kim Expires 1/31/98 [page 54]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 18.3 Sequence of TS primitives | | | | T-REPORT | | T-REPORT | T-REPORT | T-REPORT indication | | indication | indication | indication \| U 0 |_ _ _ _ _ _ _|_ _ _ _ _ _ _| / | |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | Figure 15 - 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. 19.2 Types of primitives and parameters The following Table indicates the types of primitives and parameters associated with the TC Leave service. Table 13 - TC Leave primitives and parameters +-----------------+-------------------+---------------------+ | | T-LEAVE | T-LEAVE | | | request | indication | +-----------------+-------------------+---------------------+ | Called address | X | X | +-----------------+-------------------+---------------------+ | Calling address | X | | +-----------------+-------------------+---------------------+ | Reason | | X | +-----------------|-------------------|---------------------+ | TS-user data | X(U) | | +-----------------+-------------------+---------------------+ Dae Young Kim Expires 1/31/98 [page 55]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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.3 Calling Address The calling address parameter conveys the TSAP address of the TS-user wishing to leave the TC. 19.2.4 Reason The reason parameter gives information on the cause of the Leave. The reason is one of the following: a) TS-user invoked, possibly with additional information in the TS- user data parameter; b) TS-provider invoked. This reason may be of a transient or a permanent nature. Examples include: c) a QoS parameter below an agreed LQA level; d) lack of local or remote resources at the TS-provider; e) called address unknown; f) AGI condition violated. 19.2.5 TS-user data The TS-user data parameter conveys additional TS-user information concerning the Leave request. 19.3 Sequence of primitive 19.3.1 TS-user rejection of a TC Creation A TS-user may reject a TC Creation request by a T-LEAVE request. The sequence of primitives is defined in the following time sequence diagram. Dae Young Kim Expires 1/31/98 [page 56]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | \ | | | | 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 16 - 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 in the following time sequence diagram. Dae Young Kim Expires 1/31/98 [page 57]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | 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 17 - 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. | | | | / | | | | / | | | |v | | | | T-JOIN | | | | request | | | | | | | | | | | | | | | | T-LEAVE | | | |\ indication | | | | \ | | | | \ | | | | v Figure 18 - Sequence of primitives in TS-provider rejection of a TC Join attempt Dae Young Kim Expires 1/31/98 [page 58]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 19.3.4 TS-user invoked Leave A TS-user may remove itself from the TC by a T-LEAVE request. \ | | | | \ | | | | v | | | | |\ | | | T-LEAVE | \ | T-REPORT | T-REPORT | T-REPORT request | \ | indication| indication| indication | \|_ _ _ _ _ _|_ _ _ _ _ _| | |\ |\ |\ | | \ | \ | \ | | \ | \ | \ | | v | v | v Figure 19 - Sequence of primitives in a TS-user leaving the active TC 19.3.5 TS-provider expulsion of a TS-user Leave The sequence may be invoked by the TS-provider to expel a TS-user. | | | | T-LEAVE | | T-REPORT | T-REPORT | T-REPORT indication | | indication | indication | indication /| U 0 |_ _ _ _ _ _ _ |_ _ _ _ _ _ _| / | |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | | | | | Figure 20 - 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. Dae Young Kim Expires 1/31/98 [page 59]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 The following Table indicates the types of primitives and parameters associated with the TC Termination service. Table 14 - TC Termination primitives and parameters +-----------------+-------------------+---------------------+ | | T-TERMINATE | T-TERMINATE | | | request | indication | +-----------------+-------------------+---------------------+ | Reason | | X | +-----------------|-------------------|---------------------+ | TS-user data | X(U) | X(=) | +-----------------+-------------------+---------------------+ 20.2.1 Reason 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 indication primitive when a termination request was originated by the TC owner. Dae Young Kim Expires 1/31/98 [page 60]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 20.3 Sequence of primitives 20.3.1 TC-owner invocation of a TC termination \ | | | | \ | | | | v | | | | |\ | | | T-TERMINATE | \ | T-TERMINATE | T-TERMINATE | T-TERMINATE request | \ | indication | indication | indication | \|_ _ _ _ _ _ _|_ _ _ _ _ __| | |\ |\ |\ | | \ | \ | \ | | \ | \ | \ | | v | v | v Figure 21 - Sequence of primitives in a TC-owner invocation of a TC termination 20.3.2 TS-provider invocation of a TC termination | | | | T-TERMINATE | | T-TERMINATE | T-TERMINATE | T-TERMINATE indication | | indication | indication | indication /| U 0 |_ _ _ _ _ _ _ |_ _ _ _ _ _ _| / | |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | Figure 22 - Sequence of primitives in TS-provider invocation of a TC termination Dae Young Kim Expires 1/31/98 [page 61]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 20.3.3 Simultaneous TC-owner and TS-provider invocation of a TC termination \ | | | | \ | | | | \ | | | | v| | | | T-TERMINATE | | T-TERMINATE | T-TERMINATE | T-TERMINATE request | U 0 | indication | indication | indication | |_ _ _ _ _ _ _|_ _ _ _ _ __| | |\ |\ |\ | | \ | \ | \ | | \ | \ | \ | | v | v | v Figure 23 - 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. Dae Young Kim Expires 1/31/98 [page 62]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | \ | | | | 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 24 - Sequence of primitives in an unsuccessful TC Creation with multiple TS-user rejection(s) 20.3.4 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. Dae Young Kim Expires 1/31/98 [page 63]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | \ | | | | 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 25 - Sequence of primitives in overall TS-user rejections of a TC creation attempt 20.3.5 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. \ | | | | T-CREATE \ | | | | request v| | | | | | | | | | | | | | | | T-TERMINATION | | | | indication | | | | /| | | | / | | | | / | | | | v | | | | Figure 26 - Sequence of primitives in TS-provider rejection of a TC creation attempt Dae Young Kim Expires 1/31/98 [page 64]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 20.3.6 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 the TC-owner a T-TERMINATE indication primitive with the reason parameter. \ | | | | \ | | | | \ | | | | 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 27 - 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 Owner primitives can be used by the TC-owner and other focal TS -users to pass the TC-ownership. 21.2 Types of primitives and parameters The following table lists the types of primitives and parameters associated with the TC Ownership service. Dae Young Kim Expires 1/31/98 [page 65]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 Table 15 - TC Ownership primitives and parameters +----------------+---------+----------+---------+---------+----------+ | | T-OWNER | T-OWNER | T-OWNER |T-OWNER | T-OWNER | | | request |indication| repsonse|confirm |indication| +----------------+---------+----------+---------+---------+----------+ | Called address | X | X(=) |X(Note 1)| X(=) |X(Note 3) | +----------------+---------+----------+---------+---------+----------+ | Calling address|X(Note 1)| X(=) | | |X(Note 2) | +----------------+---------+----------+---------+---------+----------+ | Responding | | | | | | | address | | | X |X(Note 2)| | +----------------+---------+----------+---------+---------+----------+ | TS-user data | X(U) | X(=) | X(U) | X(=) | | +----------------+---------+----------+---------+---------+----------+ | Reason | | | | |X(Note 4) | +----------------+---------+----------+---------+---------+----------+ NOTE 1 - This is the address of the TC-owner. NOTE 2 - This is the address of the new TC-owner. NOTE 3 - This is the address of the group. NOTE 4 - This may contain the TS-user data of the T-OWNER confirm primitive. 21.2.1 Called address 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. 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.6 Reason The reason parameter of the REPORT indication primitive conveys the result of the TC-Ownership service. Dae Young Kim Expires 1/31/98 [page 66]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 21.3 Sequence of primitives \ | | | | \ | | | | \ | | | | 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 28 - Sequence of primitives in a successful TC ownership transfer to a specified TS-user Dae Young Kim Expires 1/31/98 [page 67]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | \ | | | | T-OWNER v | | | | request |\ | | | | \ |T-OWNER |T-OWNER | | \ |indication |indication | | \|- - - - - -|- - - - - - -| | |\ |\ | | | \ | \ | | | \ | \ | | | v | v | | | | | | |T-OWNER | | | |response | | | | / | | | | / | | | |v_ _ _ _ _ |_ _ _ _ _ _ _| | / | | | | @ | | | | / \ | | | |/ \|_ _ _ _ _ _|_ _ _ _ _ _ _| T-OWNER /| |\ |\ |\ confirm / | | \ | \ | \ / | | \ | \ | \ v | | v | v | v | |T-REPORT | T-REPORT |T-REPORT | |indication | indication |indication Figure 29 - Sequence of primitives in a successful TC ownership transfer among the TC-owner candidates Dae Young Kim Expires 1/31/98 [page 68]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | \ | | | | 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 30 - 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. 22.2 Types of primitives and parameters The following table lists the types of primitives and parameters associated with the TC Ownership service. Dae Young Kim Expires 1/31/98 [page 69]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 Table 16 - 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 | | | | | | | | |X(Note| |address| X | X(=) | X | X(=) | X | X(=) | X | X(=) | 1) | +-------+------+------+------+------+------+------+------+------+------+ |Calling| | | | | | | | |X(Note| |address| X | X(=) | | | X | X(=) | | | 2) | +-------+------+------+------+------+------+------+------+------+------+ |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| | | | | | | | | | | 3) | +-------+------+------+------+------+------+------+------+------+------+ NOTE 1 - This is the address of the group. NOTE 2 - This is the address of the TC-owner. NOTE 3 - This may contain 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 called address parameter may be the TSAP address of the TC-owner or a unicast TSAP address of a sending TS-user. 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. Dae Young Kim Expires 1/31/98 [page 70]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 22.2.6 Reason The reason parameter of the REPORT indication primitive conveys the result of the Token distribution service. 22.3 Sequence of primitives \ | | | | \ | | | | \ | | | | 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 31 - Sequence of primitives in a token distribution to a specified TS user by a TC-owner Dae Young Kim Expires 1/31/98 [page 71]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 | | / | | | | / | | | | / | | | |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 32 - Sequence of primitives in a token return to a TC-owner from a specified TS user Dae Young Kim Expires 1/31/98 [page 72]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 \ | | | | \ | | | | \ | | | | 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 33 - Sequence of primitives in a forced token return from a specified TS user by the TC-owner Dae Young Kim Expires 1/31/98 [page 73]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 | | / | | | | / | | | | / | | | |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 34 - Sequence of primitives in a token acquisition by a specified TS-user from the TC-owner Dae Young Kim Expires 1/31/98 [page 74]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 Annex A TC Ordering Relationships (This annex forms a normative 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. Dae Young Kim Expires 1/31/98 [page 75]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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; 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. Dae Young Kim Expires 1/31/98 [page 76]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 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 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 1/31/98 [page 77]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-02.txt 31 JUL. 1997 Annex B Bibliography (This annex forms an informative part of this Recommendation | International Standard) Many documents and papers have contributed to the construction of this 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 1/31/98 [page 78]