INTERNET-DRAFT D. Y. KIM
draft-kim-jtc1-sc6-ects-04.txt Chungnam Univ.
30 Jun. 1998
Expires: 12/31/1998
Enhanced Communications Transport Service Definition
Status of this Memo
document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo is the final Committee Draft of the Enhanced Transport
Service Definition under development within ISO/IEC JTC1/SC6/WG7 since
last several years in order to provide to the upper-layer applications
enhanced transport services over the current OSI transport service;
major enhancements include multicast services and enhanced QoS.
This memo is distributed to possibly interested grops within IETF,
especially to experts in Transport Area, to make noticed the efforts
being made within SC6 to come up with a new transport service
definition meeting the wide range of requirements of the both current
and future multimedia multicast applications. It is to be noted that a
protocol maned ECTP(Enhanced Communications Transport Protocol)
supporting this ECTS is also under development within SC6 and will be
made public in the near future.
Experts interested in this topic might compare the services defined by
ECTS with those provided by more known protocols including RTP, MTP,
RMP, and RAMP. The ultimate apparent objective of ECTS is the
multimedia multicast transport service with varying degrees of
Dae Young Kim Expires 12/31/98 [Page 1]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
CONTENTS
Introduction...........................................................3
1 Scope..........................................................3
2 Normative references...........................................5
3 Definitions....................................................5
4 Abbreviations..................................................9
5 Conventions....................................................9
6 Overview and general characteristics..........................10
7 Features of the Enhanced Communication Transport Service......11
8 Model of the Enhanced Communications Transport Service........12
9 Transport Connection characteristics..........................15
10 Quality-of-Service (QoS) for Transport Connections............17
11 Enhanced Communications Transport Service Primitives and
Parameters....................................................32
12 TC Creation service...........................................36
13 TC Invitation service.........................................45
14 TC Join service...............................................48
15 Data Transfer service.........................................52
16 Pause service.................................................54
17 Resume service................................................56
18 Report service................................................57
19 TC Leave service..............................................58
20 TC Termination service........................................63
21 TC-ownership service..........................................69
22 Token service.................................................72
Annex A...............................................................78
Annex B...............................................................81
Dae Young Kim Expires 12/31/98 [Page 2]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
Introduction
This Recommendation | International Standard defines a transport
service, named ECTS (Enhanced Communications Transport Service), which
provides for a multicast capability and enhanced quality of service
(QoS). ECTS defines a wide range of services ranging from unreliable
unicast with best-effort QoS to reliable multicast with guaranteed
QoS. In this way, ECTS is meant to provide for a uniform and universal
service interface between transport protocols and applications of the
present and the future information age, especially for those
applications requiring versatile and powerful multimedia group
communication capabilities underneath..
Apps = Applications
+----------+ +---------------+ +---+ +------------+ +--------+
|T.120 Apps| |Other Group | |VOD| |Conventional| |New Apps|
| | |Multimedia Apps| | | | Apps | .... | |
+----------+ +---------------+ +---+ +------------+ +--------+
^ ^ ^ ^ ^
| | | | |
| | | | |
V V V V V
+-------------------------------------------------------------------+
| ECTS |
+-------------------------------------------------------------------+
^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | |
| | | | | | | | |
V V V V V V V V V
+----+ +---+ +---+ +---+ +---+ +---+ +----+ +----+ +------+
|ECTP| |TCP| |UDP| |MTP| |SRM| |RTP| |COTP| |CLTP| .... |Others|
+----+ +---+ +---+ +---+ +---+ +---+ +----+ +----+ +------+
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | | |
| | | | | | | | | | |
| V V V V V V V V V |
| +-------------------------------------------------------------+ |
| | IPv4/IPv6 + RSVP, CLNP | |
| +-------------------------------------------------------------+ |
| ^ |
| | |
| | |
V V V
+-------------------------------------------------------------------+
| PSDN, PSTN, ISDN, FR, ATM, LAN, ......... Other Networks |
+-------------------------------------------------------------------+
Figure 1 - Architectural block diagram for ECTS
Dae Young Kim Expires 12/31/98 [Page 3]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
Figure 1 depicts the general architectural block diagram showing how
ECTS relates to other protocols in the transport, application as well
as network layers.
ECTP in Figure 1 is a protocol which is supposed to support all the
services defined by ECTS. ECTP is (to be) defined in a separate
Recommendation | International Standard. Note that not all the
transport protocols shown in Figure 1 support all the services defined
by ECTS. For example, TCP provides a best-effort reliable unicast
service; UDP supports a best-effort unreliable multicast service. MTP,
RMP, and SRM support reliable multicast but with null QoS. RTP
provides means for exchanging synchronization information but does not
define mechanisms to provide the synchronization itself.
ECTP, a companion protocol to ECTS, further will utilize, wherever
possible, the multicast capabilities of the underlying network
infrastructures. For example, in operation in Internet, ECTP will make
extensive use of the multicast capabilities of IPv4 and IPv6 and rely
on RSVP for QoS provisioning by network resource reservation. As
another example, in operation over intrinsic ATM networks, ECTP will
rely on the ATM capabilities for both multicast and QoS.
1 Scope
This Recommendation | International Standard defines in an abstract
way the externally visible service provided by the Transport Layer in
terms of:
a) the primitive actions and events of the service;
b) the parameter data associated with each primitive action and
event;
c) the relationship between, and the valid sequences of, these
actions and events.
The service defined in this Recommendation | International Standard is
that which is provided by the Enhanced Communications Transport
Protocol (in conjunction with the Network Service) and which may be
used by any application protocol.. The service can also be provided by
other protocols possibly each supporting a subset of the services
defined herein.
The primitives specified in this Recommendation | International
Standard support a connection-mode service and a connectionless
service. In some cases of connectionless-mode service supporting
Dae Young Kim Expires 12/31/98 [Page 4]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
enhanced communications, certain operations may also be necessary
prior to the commencement of data transfer, e.g., agreement on
quality of service.
For the data transfer phase of either connection-mode or
connectionless-mode services, there may be a range of data-ordering
characteristics.
No implication is made in this Recommendation | International Standard
regarding the inclusion or exclusion of any of the above
characteristics given the service primitives specified herein.
2 Normative references
The following Recommendations and International Standards contain
provisions which, through reference in this text, constitute
provisions of this Recommendation | International Standard. At the
time of publication, the editions indicated were valid. All
Recommendations and Standards are subject to revision, and parties to
agreements based on this Recommendation | International Standard are
encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and International Standards listed
below. Members of IEC and ISO maintain registers of currently valid
International Standards. The Telecommunication Standardization Bureau
of the ITU maintains a list of currently valid ITU-T Recommendations.
2.1 Identical Recommendations | International Standards
- ITU-T Rec. X.200 (1994) | ISO/IEC 7498-1: 1994, Information
technology - Open Systems
Interconnection - Basic Reference Model - the Basic Model.
- ITU-T Rec. X.210 (1993) | ISO/IEC 10731: 1994, Information
technology - Open Systems Interconnection - Basic Reference Model
- Conventions for the definition of OSI services.
- ITU-T Rec. X.214 (1995) | ISO/IEC 8072: 1996, Information
technology - Open Systems Interconnection
- Transport service definition.
- ITU-T Rec. X.641 | ISO/IEC 13236: Information technology - Quality
of Service - Framework
3 Definitions
For the purposes of this Recommendation | International Standard, the
following definitions apply.
Dae Young Kim Expires 12/31/98 [Page 5]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
3.1 Reference Model definitions
This service definition is based on the concepts developed in the OSI
Basic Reference Model (ITU-T Rec. X.200 | ISO/IEC 7498-1), and makes
use of the following terms defined in it:
a) Transport Layer;
b) Transport Service;
c) transport-service-access-point;
d) transport-service-access-point address;
e) transport-service-data-unit;
f) Network Layer;
g) Network Service.
3.2 Service definition conventions
This service definition also make use of the following terms defined
in ITU-T Rec. X.210 | ISO/IEC 10731, as they apply to the Transport
Layer:
a) service-user;
b) service-provider;
c) primitive;
d) request;
e) indication;
f) response;
g) confirm.
3.3 Quality-of-Service Framework definitions
This service definition is compliant with the QoS Framework (ITU-T
Recommendation X.641 | ISO/IEC 13236) in that it describes facilities
which pertain to the Transport Layer as specified in the relevant
clause of the QoS Framework.
a) QoS characteristic;
Dae Young Kim Expires 12/31/98 [Page 6]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
b) QoS mechanism;
c) QoS parameter.
3.4 Enhanced Communications Transport Service definitions
For the purpose of this Recommendation | International Standard, the
following definitions also apply:
a) Transport Connection: A multicast connection established among
TS-users for the purpose of transferring data. In the case where
there are only two participants involved, it reduces to a
peer-to-peer connection.
b) Enrolled group: A group of TS-users who can participate in a
transport connection, which is identified with a group TSAP
address.
c) Group TSAP address: A TSAP address which maps to a set of
individual TSAP addresses of the enrolled group members.
Note that, in general, a TSAP address may be a unicast- or group-
address.
d) Active group: A group of Transport Service users which maintain
the shared state information required to support the mechanisms
of the data transfer phase.
e) Active group integrity: A set of conditions concerning the active
group which must be true in order for a transport connection to
enter or remain in the transfer state of the data transfer phase.
f) QoS level of agreement: The level of agreement reached during the
QoS negotiation between users and the provider. It may be
best-effort or guaranteed.
g) Ordering: Ordering is concerned with the following two aspects:
i) In the case of a single sender, ordering if needed ensures
that the data units generated by the sender are delivered
to each receiver in the active group in the same order as
they were sent;
ii) In the case of multiple senders, ordering determines the
relative sequencing of data received from multiple senders.
The ordering relationship defines the arrangement or
interleaving of data from the multiple senders.
Dae Young Kim Expires 12/31/98 [Page 7]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The ordering relationship can be: no, local, partial, causal
,or total.
NOTE - When there are only two participants in the active
group, local ordering, causal ordering, and total
ordering are the same.
h) TC-participant: A TS-user that is a member of the active group
participating in a transport connection.
i) TC-owner: A TS-user that owns the right to invite, monitor, and
terminate a transport connection.
j) Focal TS-user: A TS-user that intends to transmit on a TC and
initiates the QoS negotiation of the 1xN transport channel
relating to the data it transmits and the reception of that data
by other TS-users.
k) Sending TS-user: A TS-user that is a member of the active group
participating in a transport connection and submits data to the
Transport Service provider during the data transfer phase.
l) Receiving TS-user: A TS-user that is a member of the active group
participating in a transport connection and receives data from
the Transport Service provider during the data transfer phase.
m) Transmit diversity
i) Homogeneous: condition wherein all TS-users have agreed to a
common set of transmit QoS values and so all sending
TS-users transmit data at the same rate.
ii) Heterogeneous: condition wherein different sending TS-users
may transmit data at different rates.
n) Receive diversity
i) Receivers-wide: condition wherein all receiving TS-users
receive the data of a given sending TS-user at the same QoS
value.
ii) Receiver-selected: condition wherein different receivers may
receive the data of the same sending TS-user at different
QoS values not better than the transmit QoS. It is out of
the scope of this document how it can be made possible,
through some facilities and mechanisms within the
TS-provider, that data of a given QoS may be delivered at
different QoS values.
Dae Young Kim Expires 12/31/98 [Page 8]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
o) Transmit concurrency
i) Controlled: condition wherein only senders with a token may
transmit data. The maximum number of such senders is
specified by Ntok.
ii) Uncontrolled: condition wherein all senders may transmit
data concurrently.
p) Channel: A 1xN simplex data flow within a transport connection.
4 Abbreviations
AGI Active group integrity
CHQ Controlled highest quality
ECTS Enhanced Communications Transport Service
ECTP Enhanced Communications Transport Protocol
LQA Lowest quality acceptable
NSAP Network-service-access-point
OA Owner arbitration
OSIE Open Systems Interconnection Environment
OT Operating target
QoS Quality of service
SWA Step-wise arbitration
TC Transport Connection
TS Transport Service
TSAP Transport-service-access-point
TSDU Transport-service-data-unit
TPDU Transport-protocol-data-unit
5 Conventions
5.1 General conventions
Dae Young Kim Expires 12/31/98 [Page 9]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
This service definition uses the descriptive conventions given in ITU-
T Rec. X.210 | ISO/IEC 10731.
5.2 Parameters
The available parameters for each group of primitives are set out in
tables in clauses 12 to 22. Each 'X' in the tables indicates that the
primitive labeling the column in which it falls may carry the
parameter labeling the row in which it falls.
Some entries are further qualified by items in brackets. These may be:
a) indications that the parameter is optional in some way:
(U) indicating that the inclusion of the parameter is a choice
made by the user;
b) parameter specific constraints:
(=) indicating that the value supplied in an indication or
confirmation primitive is always identical to that
supplied in the respective previous request or response
primitive issued at the peer service access point.
5.3 Notations
The following notations are used in this document to denote some
numerical quantities:
a) Nmax: the maximum number of members that can be allowed in the
active group.
b) Nact: the actual number of members in the active group.
c) Ntok: the maximum number of members that can transmit data
concurrently.
6 Overview and general characteristics
The Transport Service provides for the transparent transfer of data
among TS-users. It relieves the TS-users from any concern about the
detailed way in which supporting communications media are utilized to
achieve this transfer.
The Transport Service provides for the following:
a) QoS selection:
Dae Young Kim Expires 12/31/98 [Page 10]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The Transport Layer is required to optimize the use of
available communications resources to provide the QoS required
by communicating TS-users at the minimum cost. QoS requirements
are specified through the selection of values for QoS
parameters.
b) Independence of underlying communications resources:
The Transport Service hides from TS-users the difference in the
QoS provided by the Network Service. This difference in QoS
arises from the use of a variety of communications media by the
Network Layer to provide the Network Service.
c) End-to-end significance:
The Transport Service provides for the transfer of data among
TS-users in end systems.
d) Transparency of transferred information:
The Transport Service provides for the transparent transfer of
octet-aligned TS-user data and/or control information. It does
neither restrict the content, format, or coding of the
information, nor does it ever need to interpret its structure
or meaning.
e) TS-user addressing:
The Transport Service utilizes a system of addressing which is
mapped into the addressing scheme of the supporting Network
Service. Transport addresses can be used by TS-users to refer
unambiguously to TSAPs.
f) AGI monitor:
The Transport Layer may be required to monitor the AGI of
TS-users participating in the active transport connection. AGI
is specified through the selection of values for AGI
parameters.
7 Features of the Enhanced Communications Transport Service
ECTS provides the following features to the TS-user:
a) The means for a TC-owner to create a TC with other TS-users of
the same enrolled group for the purpose of exchanging TSDUs.
Only one TC may exist among the TS-users of a given enrolled
group. Some QoS agreements may have been determined during
Dae Young Kim Expires 12/31/98 [Page 11]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
enrollment. Refinement of some of these QoS agreements may
occur during the create operation and others may be initially
determined at that time.
b) The means for a TS-user to join an existing TC under the
constraints of QoS, AGI, and other control conditions. Further
QoS refinements may be made as part of the join operation.
c) The means of transferring TSDUs on a TC under the constraints
imposed by QoS. The transfer of TSDUs is transparent, in that
the boundaries of TSDUs and the contents of TSDUs are preserved
unchanged by the Transport Service and that there are no
constraints on the TSDU content imposed by the Transport
Service. It may or may not be known whether any or all of the
potential receivers receive the TSDUs.
d) The means of transferring TSDUs with no QoS imposed except,
optionally, transit delay. The transfer of TSDUs is
transparent, in that no constraints on the TSDU content are
imposed by ECTS and the contents of TSDUs are preserved
unchanged by ECTS. It may not be known whether any or all of
the potential receivers receive the TSDUs.
e) The means for a TS-user to leave a TC unconditionally and/or
under the constraints of AGI and QoS.
f) The means for a TC-owner unconditionally and therefore
destructively to terminate a TC.
8 Model of the Enhanced Communications Transport Service
8.1 Types of Transport Connection
Figure 2 gives the three types of TC considered in ECTS. They are:
Dae Young Kim Expires 12/31/98 [Page 12]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
O O O
^ ^ ^
/ / / /
/ / / /
/ V / /
/ <---------- / V
O-----------> O------------> O<---------->
\ <---------- \ ^
\ ^ \ \
\ \ \ \
\ \ \ \
V V V
O O O
(a) Simplex TC (b) Duplex TC (c) N-plex TC
Figure 2 - Types of Transport Connections
a) simplex TC, wherein one TC-participant, called TC-owner, is send
only and all others are receive only;
b) duplex TC, wherein one TC-participant, called TC-owner, can both
send to and receive from all others whereas all other
TC-participants can receive only from and send only to the
TC-owner. Hence, send/receive among the TC-participants other
than the TC-owner is not possible;
c) N-plex TC, wherein any TC-participant is a sender as well as a
receiver. At any moment, anyone can send something, and, if
someone does so, all others may receive it.
The three basic types of TC defined here are thought to cover all the
other types as degenerate cases. For example, a unicast simplex TC is
a degenerate case of the simplex TC. A unicast duplex (peer-to-peer)
TC is a degenerate case of the N-plex TC. An MxN TC wherein M of the
total N members are send-and-receive participants while the rest are
receive-only can be modeled as a degenerate of the N-plex TC; some
members may announce their intention not to send any data as part of
QoS negotiation.
8.2 Model of Transport Connection
An enrolled group may be involved in only one TC. Figure 3 gives an
example of a TC for an enrolled group.
In this example, the enrolled group consists of six TS-users A to F.
The group is identified by a group TSAP address pointing to the TSAPs
Dae Young Kim Expires 12/31/98 [Page 13]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
of the group members A to F.
TS-user B TS-user C
+---------+ +---------+
| | | |
+---------+ +---------+
^ ^ TS-user D
TS-user A \ / +--+
+--+ \ / | |
| | \ / | |
| | \ / | |
| | \ / | |
| | \ / | |
| | \ / | |
| | \ / +--+
| | \ /
| | \ /
| | \ /
| |<---------------------------
| | \
| | TC \
+--+ \
\
\
\
V
+-----------+ +------------+
| | | |
+-----------+ +------------+
TS-user F TS-user E
+-----+
| | TSAP(Transport Service Access Point)
+-----+
TC Transport Connection (TC)
Figure 3 - An example of a TC for an enrolled group
In the example, TS-users A, B, C, and E are involved in a simplex TC,
wherein A is the owner; they are said to form the active group for TC.
TS-users D and F are not involved in any TC.
The TC is identified by the group TSAP address which is unique within
the scope of OSIE. Each terminal of a TC is identified by the TSAP
address of the TS-user participating in the active group.
Dae Young Kim Expires 12/31/98 [Page 14]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
9 Transport Connection characteristics
The TC characteristics consist of AGI and QoS. While QoS may be
changed through negotiation in TC establishments, AGI is a predefined
requisite for a TC and is not for negotiation. Therefore, AGI may be
irrelevant for some primitives, i.e., response and confirm, where the
AGI might be of a null value or even absent.
9.1 Active group integrity
The active group integrity specifies conditions on the active group
membership of a TC. The following is the AGI conditions identified and
defined in this standard. Inclusion of other AGI conditions is for
further study.
9.1.1 AGI policy
a) Soft: policy for which the TC is to be suspended when the AGI is
violated. The TC is to be restored when the AGI is recovered.
b) Hard: policy for which the TC is to be terminated when the AGI is
violated.
9.1.2 Population
The AGI population characteristic for a TC can be one or more of the
following.
a) Mandatory: condition that specifies the selected enrolled group
members required to be present in the active group;
b) Minimum: condition that specifies the minimum number of enrolled
group members required to be present in the active group;
c) Quorum: condition wherein the majority of enrolled group members
are required to be present in the active group;
d) Maximum: condition that specifies, Nmax, the maximum number of
members that can be allowed in the active group;
e) Atomic: condition wherein all of enrolled group members are
required to be present in the active group.
9.1.3 TC type
The type eligible for a group will be one of the followings:
a) Simplex TC;
Dae Young Kim Expires 12/31/98 [Page 15]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
b) Duplex TC;
c) N-plex TC.
9.1.4 Transmit diversity
The transmit diversity eligible for a group will be one of the
followings:
a) Homogeneous
b) Heterogeneous
9.1.5 Receive diversity
The receive diversity eligible for a group will be one of the
followings:
a) Receivers-wide
b) Receiver-selected
9.1.6 Transmit concurrency
The transmit concurrency eligible for a group will be one of the
followings:
a) Controlled
b) Uncontrolled
NOTE - In the controlled mode of transmit concurrency, Ntok is less
than Nmax; Ntok < Nmax. When Ntok equals Nmax, the case reduces
to the uncontrolled mode.
9.2 Quality of service
The term quality of service (QoS) refers to certain characteristics of
a TC that are managed by the TS-users and the TS-provider. They are
- throughput, transit delay and transit delay jitter, which are
classed as TC performance characteristics
- corrupted TSDU error rate and lost TSDU error rate, which are
classed as TC reliability characteristics
- TC ordering
Dae Young Kim Expires 12/31/98 [Page 16]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
- TC protection
- TC precedence.
Definitions of these characteristics are given in 10.1.
Values for some or all of these characteristics may be agreed before
the TC is operated. The nature of QoS agreements and the means by
which they can be reached are specified in 10.2. The phases of
establishment of a TC during which values for the various
characteristics may be agreed and possibly subsequently refined are
specified in 10.3.
Once agreed, QoS values apply for the duration of a TC. In some cases,
different TS-users may operate with different values of QoS.
10 Quality of service for Transport Connections
10.1 QoS classification
The QoS classes and the possible values that may be imposed or agreed
upon are shown in Table 1.
Table 1 - Classification of the QoS characteristics
+-----------------+----------------+---------------------------------+
| Characteristic | Characteristic | QoS value agreed or imposed |
| group | | |
+-----------------+----------------+---------------------------------+
| TC performance | Throughput | - ChQ throughput value |
| | | - operating target throuput |
| | | value |
| | | - LQA throughput value |
| +----------------+---------------------------------+
| | Transit delay | - operating target transit delay|
| | | value |
| | | - LQA transit delay value |
| +----------------+---------------------------------+
| | Transit delay | - operating target transit delay|
| | jitter | jitter value |
| | | - LQA transit delay jitter value|
+-----------------+----------------+---------------------------------+
| TC reliability | Corrupted TSDU | - LQA corrupted TSDU error rate |
| | error rate | value |
| +----------------+---------------------------------+
| | Lost TSDU error| - LQA lost TSDU error rate value|
| | rate | |
+-----------------+----------------+---------------------------------+
Dae Young Kim Expires 12/31/98 [Page 17]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
| TC ordering | TC ordering | - No ordering |
| | | - Local ordering |
| | | - Causal ordering |
| | | - Partial ordering |
| | | - Total ordering |
+-----------------+----------------+---------------------------------+
| Miscellaneous | TC protection | Local matter according to the |
| | | security policy in force |
| | | See 10.1.4.1 |
| +----------------+---------------------------------+
| | TC precedence | Imposition of : |
| | | - the order in which TCs are to|
| | | have their QoS degraded, or |
| | | - the order in which TCs are to|
| | | be broken to recover |
| | | resources |
+-----------------+----------------+---------------------------------+
10.1.1 TC performance
10.1.1.1 Throughput
Throughput in general is a property of a channel between a pair of
users which quantifies the rate of successful transfer of user data
through the channel. It is defined in the QoS Framework (ITU-T Rec.
X.641 | ISO/IEC 13236) as the rate of user data output from a channel
averaged over a time interval t.
If the channel is loss-free, the rate of data output will be the same
as the rate of data input, when averaged over appropriate periods. If
the channel can lose data - for example if it includes a data-
discarding filter - the rate of data output may be significantly less
than the rate of data input.
In ECTS, throughput may need to be negotiated for a number of reasons:
for example,
- to determine the maximum rate at which a transmitter should
operate
- to ensure that enough capacity is made available in the provider
and in receiving TS-users
- to set up an appropriate flow control regime.
Throughput, or equivalently transmit rate is defined for a TS-user and
a given TC in terms of a sequence of at least two TSDUs in T-DATA
request primitives. Given such a sequence of n TSDUs, where n is
Dae Young Kim Expires 12/31/98 [Page 18]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
greater than or equal to 2, the transmit rate is defined to be the
number of TS-user data octets contained in the last n-1 TSDUs divided
by the time between the first and last T-DATA requests in the
sequence.
10.1.1.2 Transit delay
Transit delay is defined as the time elapsed between the occurrence of
a T-DATA request primitive at a TSAP and the occurrences of the
corresponding T-DATA indication primitives at the receiving TSAP. The
requirement for transit delay in one direction of transmission may be
different from the requirement for transit delay in the reverse
direction.
10.1.1.3 Transit delay jitter
Transit delay jitter is defined between a pair of users, and for each
direction of transmission, as the difference between the longest and
the shortest transit delays in the lifetime of the TC.
10.1.2 TC reliability
For each TC, the TC reliability is defined as the combination of a
TSDU corruption policy and a TSDU loss policy.
The TSDU loss policy is specified qualitatively by selecting one of
two options:
a) losses of TSDUs are not accepted;
b) losses of TSDUs are accepted but indicated.
The TSDU corruption policy is specified qualitatively by selecting one
of two options:
a) corruption of contents in TSDUs are not accepted;
b) corruption of contents in TSDUs are accepted but indicated.
The four possible combinations result in four different TC reliability
policies as follows:
a) lossless and error-free;
b) lossless and corrupted;
c) lossy and error-free;
Dae Young Kim Expires 12/31/98 [Page 19]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
d) lossy and corrupted.
Table 2 shows the four TC reliability policies and the associated
meaningful error rates.
The TC reliability policies are negotiated among the TS-users only.
If neither losses nor corruption of contents are accepted on a TC, the
TS-provider has to preserve unchanged the boundaries and the contents
of all submitted TSDUs. That is, any TSDU delivered to the receiving
TS-user via a T-DATA indication primitive shall have the same number
of octets and the same value for each octet as the TSDU received from
the sending TS-user in the corresponding T-DATA request primitive.
Table 2 - The four TC reliability policies and the corresponding
meaningful error rates
+---------------------------+---------------------------------------+
| TC reliability | Loss Policy |
| policy +--------------+------------------------+
| | Losses not | Losses accepted but |
| | accepted | indicated |
+------------+--------------+--------------+------------------------+
| Corruption | Corruption | lossless and | lossy and error-free |
| policy | not accepted | error-free | (Lost TSDU error rate) |
| +--------------+--------------+------------------------+
| | Corruption | lossless and | lossy and corrupted |
| | accepted but | corrupted | (Corrupted TSDU error |
| | indicated | (Corrupted | rate) |
| | | TSDU error | (Lost TSDU error rate) |
| | | rate) | |
+------------+--------------+--------------+------------------------+
If corruption of contents are accepted, then any TSDU delivered to the
receiving TS-users via a T-DATA indication primitive shall still have
the same number of octets as the TSDU submitted by the sending TS-user
in the corresponding T-DATA request primitive, but the values of some
octets may have been altered by the TS-provider. The corruption of
contents is to be indicated by the status parameter value in the T-
DATA indication primitive. If losses are accepted, then, for any lost
or corrupted TSDU submitted by the sending TS-user, a zero-length TSDU
is delivered to the receiving TS-user with indication by the status
parameter in the T-DATA indication primitive. The TC reliability
policies are implemented by managing the QoS characteristics,
corrupted TSDU error rate and lost TSDU error rate.
10.1.2.1 Corrupted TSDU error rate
Dae Young Kim Expires 12/31/98 [Page 20]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The corrupted TSDU error rate is defined as the ratio of total number
of TSDUs delivered to the receiving TS-user, with their contents
corrupted, to the total number of TSDUs submitted by the sending TS-
user to the TS-provider during a defined period. The corrupted TSDU
error rate is negotiated among the TS-users only.
10.1.2.2 Lost TSDU error rate
The lost TSDU error rate is defined as the ratio of the total number
of zero length TSDUs delivered to the receiving TS-user to the total
number of TSDUs submitted by the sending TS-user to the TS-provider
during a defined period. The lost TSDU error rate is negotiated among
the TS-users only.
10.1.3 TC ordering
TC ordering is concerned with the following two aspects:
a) how TSDUs of a sending TS-user are presented to the receiving
TS-users;
b) how a receiving TS-user gets TSDUs from the sender(s).
In the case of a single sending TS-user, ordering if needed ensures
that the TSDUs generated by the sending TS-user are delivered to each
receiving TS-user in the active group in the same order as they were
sent. In the case of multiple sending TS-users, ordering determines
the relative sequencing of TSDU received from multiple sending TS-
users. The ordering relationship defines the arrangement or
interleaving of TSDU from the multiple sending TS-users. The ordering
relationship can be: no, local, causal, partial, or total. Note that
when there are only two participants in the active group, local
ordering, causal ordering, and total ordering are the same.
NOTE - In Annex A, the ordering relationship is described in detail.
10.1.3.1 No ordering
TS-provider does not guarantee any relationship between TSDUs sent
from a single sending TS-user or from multiple sending TS-users.
NOTE 1 - Even though the ordering of TSDUs are not guaranteed, the
ordering of TPDUs belong to the same TSDU are to be
guaranteed. NOTE 2 - Selection of no ordering can be used to
absorb the ALF
(application level framing) feature of the Internet.
10.1.3.2 Local ordering
Dae Young Kim Expires 12/31/98 [Page 21]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The TSDUs, generated by a particular sending TS-user, are delivered to
all of the receiving TS-users in the same order in which they were
generated. Local ordering does not establish any ordering relationship
among TSDUs generated by different sending TS-users.
10.1.3.3 Partial ordering
The TSDUs, generated by all sending TS-users are delivered to each
receiving TS-user according to an arbitrary ordering rule.
If the TSDUs are ordered according to a rule applicable to all
receiving TS-users, then each receiving TS-user receives the TSDUs
generated by all the sending TS-users in the same order.
If the TSDUs are ordered according to a rule determined by each
receiving TS-user, then each receiving TS-user may receive the TSDUs
in different orders.
10.1.3.4 Causal ordering
The causal ordering orders the TSDUs generated by all sending TS-users
according to the causal dependence relationship among the sending
events. A causal dependence relationship is established between two
sending events, A and B, if the following applies:
a) A happens before B if A and B are sending events generated by
the same sending TS-user and A is sent before B;
b) A happens before B if A and B are sending events generated by
two different sending TS-users and the TSDUs generated by the
event A by one sending TS-user is received by the other sending
TS-user before it generates the event B.
A causal dependence relationship is established among more than two
sending events if it can be established that A happens before B and
that B happens before C, and it therefore follows that A happens
before C. A causal dependence relationship cannot be established
between the two sending events A and C if there is no possibility to
establish that A happens before B and that B happens before C.
10.1.3.5 Total ordering
The TSDUs, generated by all sending TS-users, are delivered to each
receiving TS-user in the same order. Every receiving TS-user sees all
TSDUs from all sending TS-users in exactly the same order.
10.1.4 Miscellaneous
Dae Young Kim Expires 12/31/98 [Page 22]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
10.1.4.1 TC protection
Protection QoS is the degree to which the TS-provider attempts to
counter security threats to the Transport Service using Security
Services applied to the Transport, Network, Data Link or Physical
Layers. The handling of protection QoS parameters is a local matter
controlled according to the security policy in force.
NOTE - For further information on the provision of security in the
lower layers and the handling of protection QoS see ITU-T
Rec. X.802 | ISO/IEC TR 13594.
10.1.4.2 TC precedence
The TC precedence characteristic specifies the relationship between
TCs. This characteristic specifies the relative importance of a TC
with respect to:
a) the order in which TCs are to have their QoS degraded, if
necessary, and
b) the order in which TCs are to be broken to recover resources, if
necessary.
This characteristic only has meaning in the context of some management
entity or structure able to judge relative importance. The number of
precedence levels is limited.
10.2 Levels of QoS agreement
10.2.1 Best effort level
For each QoS value negotiated at the best effort level of agreement,
there is no guarantee that it will be maintained throughout the
lifetime of the TC.
10.2.2 Guaranteed level
Guaranteed levels of agreement apply to QoS limits. The TS-provider
monitors the achieved QoS. If it determines that it cannot maintain
the QoS within the agreed limit, it will either
a) pause the service (by issuing a T-PAUSE indication primitive), if
the condition is judged to be transient, or
b) remove a TS-user (by issuing a T-LEAVE indication primitive), or
c) terminate the TC (by issuing a T-TERMINATE indication primitive).
Dae Young Kim Expires 12/31/98 [Page 23]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
However, in reaching the guaranteed level of agreement, the parties
undertake to provide the agreed QoS, for example by dedicating
resources to the TC, barring the occurrence of rare events such as
equipment failure.
10.3 QoS negotiation mechanisms
For the negotiation of the ECTS QoS characteristics, two procedures
are defined, namely the owner-arbitration (OA) and step-wise
arbitration (SWA) procedures. The QoS negotiation capabilities and
mechanisms supported by these procedures are different.
10.3.1 Generic QoS negotiation
1. The focal TS-user proposes a LQA value LQAo, a CHQ value CHQo,
and an OT value OTo, where LQAo < OTo < CHQo.
2. The TS-provider may refuse the request if it knows it cannot be
met, i.e., if it cannot support at least LQAo.
If the TS-provider does not refuse the request, but cannot
operate over the full range proposed by the focal TS-user, it
may determine a new reduced CHQ value CHQi' for each responding
TS-user Ri individually. (It is also possible that the
TS-provider may choose to operate internally at a higher
quality, but it does not signal this fact to the responding
TS-user.) CHQi' shall not be worse than the
focal-TS-user-proposed OTo; otherwise, the TS-user should leave
the TC. The TS-provider may not alter the LQA and OT values.
Thus LQAo < OTo < CHQi' < CHQo for all i.
LQAo, OTo, and the new CHQi' are supplied to each responding
TS-user Ri.
3. Each responding TS-user may refuse the request. If it accepts,
it may increase the LQA to a new value LQAi', decrease the CHQ
to a new value CHQi", and change the OT to a new value OTi'.
OTi' may be lower or higher than the TC-owner proposed OTo.
Thus, LQAo < LQAi' < OTi' < CHQi" < CHQi' < CHQo for all i.
The new values LQAi', CHQi", and OTi' are returned to the
TS-provider.
4. The TS-provider examines the values returned from each
responding TS-user and determines LQA'max=max LQAi',
CHQ"min = min CHQi", and OT'max = max OTi'. It is a requirement
for a feasible region that LQA'max < CHQ"min. In the case of
the guaranteed level of agreement, responding TS-users may need
to be removed until this constraint is satisfied.
If a feasible region exists, the TS-provider selects the values
LQA, CHQ, and OT such that LQA'max < LQA < OT < CHQ < CHQ"min.
Dae Young Kim Expires 12/31/98 [Page 24]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
Typically, LQA will be close to LQA'max, CHQ to CHQ"min, and OT
to OT'max .
If a feasible region does not exist, selection of LQA, CHQ, and
OT are abandoned. In the case of the guaranteed level of
agreement, this results in failure of the connection
establishment.
5. The selected values LQA, CHQ, and OT are returned to the focal
TS-user and to all responding TS-users. They are the "agreed"
values. Except in the case of the best-effort level of
agreement, this meets the requirements of all TS-users since
LQAo < LQAi' < LQA'max < LQA < OT < CHQ < CHQ"min < CHQi" <
CHQi' < CHQo for all i.
If the receive mode is "receivers-wide", the "agreed" values
are also the receive QoS values of all the receiving TS-users.
If the receive mode is "receiver-selected", although the focal
TS-user transmits data according to the agreed QoS values, each
TS-user may receive the data according to the QoS values it has
returned to the TS-provider in its previous response.
The mechanism is illustrated in Figure 4.
Dae Young Kim Expires 12/31/98 [Page 25]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
focal TS-user | TS-provider | responding |TS-provider | all TS-users
| | TS-users | |
--------------+-------------+--------------+------------+-------------
| | | |
| | +--------+ | |
| | l __/1 l | |
| | __/ V l | |
| __/ l \__l | |
CHQo --------------+ __/ | l A \__| +-----+ |
| 1_/ | l _/-1_ l \-->| min |--------- CHQ
| 1 | _/ 1 \ l | +-----+ |
| 1\ |_/l V \l | A |
| V \ _/ l \ | / |
| \_/ | l A_ l\ | / |
| _/\ | l 1 \ l \| / +-----+ |
| / \ | l_/--+ \l \/->| Arb |--------- OT
OTo ---------------+ \| / \ / +-----+ |
| \ \_/+--------+\/| A |
| \ / \ /\| _/ |
| \_ /| \ / \ / |
| X | \---+ / |X |
| / \| 1 / _/ \ |
| / \ +----1/--_/ | \ |
| / |\ l V _/l | \ |
| / | \l / l | \ |
LQAo --------------+ | \ A l | V |
| \__ | l\ 1 l | +-----+ |
| \__| l \--+ l |/->| max |--------- LQA
| \__l 1 l / +-----+ |
| | \ V l_/| |
| | l\ __/ | |
| | l \ / l | |
| | l \ A l | |
| | l \1 l | |
| | +--------+ | Arb=arbitration
| | | |
| | | |
Figure 4 - Generic QoS negotiation
10.3.2 OA QoS negotiation
The OA QoS negotiation applies to all three types of TC, i.e.,
simplex, duplex, and N-plex and the procedure is the same as described
in 10.3.1 with the TC-owner as the focal TS-user:
1. The TC-owner issues a T-CREATE request, multicast, containing a
Dae Young Kim Expires 12/31/98 [Page 26]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
QoS proposal, thus initiating the generic QoS negotiation
procedure of 10.3.1 for the whole TC.
2. Every TS-user responds to the T-CREATE indication it receives
with a T-CREATE response, which contains a set of responses to
the QoS proposals made by the TC-owner.
3. The provider performs an arbitration of the QoS.
4. The provider issues T-CREATE confirm primitives containing the
results of the arbitration, with AGI for the whole connection,
to all TS-users.
From the point of view of QoS, the QA procedure allows the whole 1xN
QoS negotiations to be initiated and arbitrated altogether, following
the sequence
- proposal
- provider modification
- response
- arbitration (local to the TC-owner).
A TC by an OA establishment is said to be homogenous, implying that
all TS-users have agreed to a common set of transmit QoS values and so
all sending TS-users transmit data at the same rate. It holds for all
sending TS-users in the active group that
ThroughputMin = LQA ; minimum transmit rate
ThroughputMax = CHQ ; maximum transmit rate
ThroughputOperating = OT ; operating target transmit rate.
The non-TC-owners of a simplex or a duplex TC receive data from only
one TS-user, i.e., the TC-owner. It holds for them that
ReceiveRateMin = LQA ; minimum receive rate
ReceiveRateMax = CHQ ; maximum receive rate
ReceiveRateExpected = OT ; expected receive rate.
The TC-owner of a duplex TC and all the TS-users of a N-plex TC
receive data from multiple sending TS-users, of which the maximum
number is, by definition, Ntok. Then, selection of the transmit rate
Dae Young Kim Expires 12/31/98 [Page 27]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
as above has the consequence of implicitly announcing their receive
capability such that
ReceiveRateMin = Ntok x LQA ; minimum aggregate receive rate
ReceiveRateMax = Ntok x CHQ ; maximum aggregate receive rate
ReceiveRateExpected = Ntok x OT ; expected aggregate receive rate.
Note, in the case Nact, the number of members present in the active
group, is less than Ntok, i.e., Nact < Ntok, a resource of at least
(Ntok - Nact) x CHQ per host or provider is left unused. This is a
slack reserve for late joining TS-users.
In the case of a receiver-selected receive mode, ReceiveRateMin,
ReceiveRateMax, and ReceiveRateExpected may be less than the ones
given here.
10.3.3 SWA QoS negotiation
The SWA QoS negotiation applies only to two of the TC types, duplex
and N-plex and the procedure is the same as described in 10.3.1 with a
prior invitation by the TC-owner:
1. The TC-owner issues a T-INVITE request, multicast, containing
the TC-characteristics.
2. Every prospective focal TS-user responds to the T-INVITE
indication by issuing a T-JOIN request, thus individually
initiating the generic QoS negotiation procedure of 10.3.1 for
its 1xN simplex channel of the TC.
3. Every TS-user responds to each T-JOIN indication it receives
with a T-JOIN response, which contains a set of responses to
the QoS proposals made by the focal TS-user that issued the
corresponding T-JOIN request.
4. The TS-provider performs an arbitration of the QoS for each 1xN.
5. The TS-provider issues T-JOIN confirm primitives containing the
results of the arbitration for the relevant 1xN, with AGI for
the whole connection , to all TS-users.
From the point of view of QoS, the SWA procedure allows the individual
1xN QoS negotiations to be initiated and arbitrated independently,
following the sequence
- proposal
Dae Young Kim Expires 12/31/98 [Page 28]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
- provider modification
- response
- arbitration (local to focal TS-user).
A TC by an SWA establishment is said to be heterogeneous, implying
that different sending TS-users may transmit data at different rates.
It holds for each TS-user in the active group that
ThroughputMin = LQAi ; minimum transmit rate
ThroughputMax = CHQi ; maximum transmit rate
ThroughputOperating = OTi ; operating target transmit rate.
The non-TC-owners of a duplex TC receive data from only one TS-user,
i.e., the TC-owner. It holds for them that
ReceiveRateMin = LQAo ; minimum rate of the TC-owner
ReceiveRateMax = CHQo ; maximum rate of the TC-owner
ReceiveRateExpected = OTo ; expected rate of the TC-owner
The TC-owner of a duplex TC and all the TS-users of a N-plex TC
receive data from multiple sending TS-users, of which the maximum
number is, by definition, Ntok. Then, it holds for them that
ReceiveRateMin = Sum {LQAj; j=1,Ntok} ; minimum receive rate
ReceiveRateMax = Sum {CHQj; j=1,Ntok} ; maximum receive rate
ReceiveRateExpected = Sum {OTj; j=1,Ntok} ; expected receive rate
In the case of a receiver-selected receive mode, ReceiveRateMin,
ReceiveRateMax, and ReceiveRateExpected may be less than the ones
given here.
10.3.4 Considerations
A zero throughput value in a response primitive is used to announce
that the TS-user may want to participate the TC simply as a receive-
only user. Note that an intention of no participation at all is
signaled by a T-LEAVE request primitive.
Constraints applicable to specific QoS characteristics.
Dae Young Kim Expires 12/31/98 [Page 29]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
This standard places the following constraints on how QoS agreements
are reached.
C1. Corrupted TSDU error rate and lost TSDU error rate are
negotiated between TS-users only, i.e. using a restricted form
of the mechanisms defined above in which the TS-provider plays
no part.
C2. TC ordering is not subject to imposition or negotiation during
CREATE or JOIN operations. See 10.1.3 for further information.
C3. TC protection is determined by security policy, and is not
covered by this clause.
C4. TC precedence is determined by a management policy. It may be
imposed, but not negotiated.
QoS parameters of ECTS service primitives
This subclause identifies the general set of QoS parameters used in
ECTS service primitives in order to impose or negotiate QoS
agreements. Not all need be present in all cases: the exact set
required is determined by the types of agreement on QoS it is desired
to reach and the specifications of the foregoing negotiation rules.
For each QoS characteristic, other than TC-protection, the following
parameters may be present in T-CREATE and T-JOIN service primitives:
- imposition or negotiation
- type of value negotiated, i.e. operating target, LQA limit, CHQ
limit
- type of agreement required, i.e. best efforts or guaranteed
- negotiation type, i.e. receivers-wide/receiver-selected
- values as defined in the negotiation mechanism employed
10.4 Phases of QoS agreement
There are several partly overlapping phases related to the operation
of a TC. Some of them apply to the TC as a whole, others (namely join
and leave) apply to individual TS-users. The phases are
- the enrollment phase, during which the enrollment group is
established and conditions for TCs are prepared
Dae Young Kim Expires 12/31/98 [Page 30]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
- the creation phase, during which the TC is explicitly created
- the data transmission phase, during which data are exchanged
- the join phase, during which new TS-users join the TC
- the leave phase, during which some TS-users leave the TC
- the termination phase, at which the TC is terminated.
Rules may exist as to which parties may create and/or terminate such
connections and therefore distinguish them from those parties which
may only join and leave Transport Connections created by others.
These rules thus determine the phases at which various QoS agreements
may be reached.
For some characteristics, such as ordering, only those parties capable
of providing the necessary function can be enrolled into any given
group. The ordering characteristic is therefore determined by the end
of the enrollment phase.
For other characteristics, the phase at which they may be agreed
depends on whether negotiation is to take place and on the type of
negotiation, e.g. receivers-wide or receiver-selected, that is
required. If receivers-wide negotiation is required for a value
(operating target, LQA or CHQ) associated with a given QoS
characteristic, then that negotiation must take place during the
enrollment phase or the creation phase, and the agreed value will then
be imposed upon any TS-user that attempts to join the TC later. On
the other hand, if the value is to be imposed or negotiated on a
receiver-selected basis, then the agreement may be reached during the
enrollment phase, the creation phase or the join phase.
Agreements reached during the enrollment phase may be on a specific
value, or on a range of acceptable values. In the latter case, the
agreement may be refined by selection of a specific value within the
range during the creation phase or the join phase.
NOTE - The means by which agreements may be reached during the
enrollment phase are beyond the scope of this standard.
Security or management policies may place further constraints on the
phases at which QoS agreements may be reached.
In addition to specifying particular values or range constraints that
apply to particular QoS characteristics at various phases, it is also
possible to define those default values which will apply in the
absence of any specification in a T-primitive. This service definition
Dae Young Kim Expires 12/31/98 [Page 31]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
does not specify any particular default values, nor the means by which
they may be established. Other specifications may specify particular
defaults to be used in particular environments.
Table 3 lists QoS characteristics and indicates in which phases of a
TC their values may be negotiated.
Table 3 - Classification of the QoS characteristics by phase usage
+--------------------------+------------+------------+----------+
| Characteristic | Enroll use | Create use | Join use |
+--------------------------+------------+------------+----------+
| Throughput | R, V | V | SV |
+--------------------------+------------+------------+----------+
| Transit delay | R, V | V | SV |
+--------------------------+------------+------------+----------+
| Transit delay jitter | R, V | V | SV |
+--------------------------+------------+------------+----------+
| Corrupted TSDU error rate| R, V | V | SV |
+--------------------------+------------+------------+----------+
| Lost TSDU error rate | R, V | V | SV |
+--------------------------+------------+------------+----------+
| TC Ordering | V | N | N |
+--------------------------+------------+------------+----------+
| TC Protection | SP | SP | SP |
+--------------------------+------------+------------+----------+
| TC precedence | I | I | I |
+--------------------------+------------+------------+----------+
11 Enhanced Communications Transport Service primitives and
parameters
11.1 Definitions
Table 4 defines the service primitives and the associated parameters
which are used in ECTS. Detailed descriptions of these primitives are
given in clauses 12 to 22.
NOTE - Although the TC characteristics normally consist of AGI and
QoS, the AGI might be of a null value or even absent in
TC characteristics parameters of response and confirm primitives.
Dae Young Kim Expires 12/31/98 [Page 32]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
Table 4 - Enhanced Communications Transport Service primitives
+------------+--------------+-----------------------------------------+
| Service | Primitive | Parameters |
+------------+--------------+-----------------------------------------+
| TC | T-CREATE | (Called address, Calling address, |
| creation | request | TC-characteristics, TS-user data) |
| | T-CREATE | (Called address, Calling address, |
| | indication | TC-characteristics, TS-user data) |
| | T-CREATE | (Responding address, TC-characteristics,|
| | response | TS-user data) |
| | T-CREATE | (Responding address, TC-characteristics,|
| | confirm | TS-user data) |
+------------+--------------+-----------------------------------------+
| TC | T-INVITE | (Called address, Calling address, |
| invitation | request | TC-characteristics, TS-user data) |
| | T-INVITE | (Called address, Calling address, |
| | indication | TC-characteristics, TS-user data) |
+------------+--------------+-----------------------------------------+
| TC join | T-JOIN | (Called address, Calling address, |
| | request | TC-characteristics, TS-user data) |
| | T-JOIN | (Called address, Calling address, |
| | indication | TC-characteristics, TS-user data) |
| | T-JOIN | (Responding address, TC-characteristics,|
| | response | TS-user data) |
| | T-JOIN | (Responding address, TC-characteristics,|
| | confirm | TS-user data) |
+------------+--------------+-----------------------------------------+
| Data | T-DATA | (TS-user data) |
| transfer | request | |
| | T-DATA | (Calling address, Status, TS-user data) |
| | indication | |
| Service | Primitive | Parameters |
+------------+--------------+-----------------------------------------+
| TC | T-CREATE | (Called address, Calling address, |
| TC | T-CREATE | (Called address, Calling address, |
| creation | request | TC-characteristics, TS-user data) |
| | T-CREATE | (Called address, Calling address, |
| | indication | TC-characteristics, TS-user data) |
| | T-CREATE | (Responding address, TC-characteristics,|
| | response | TS-user data) |
| | T-CREATE | (Responding address, TC-characteristics,|
| | confirm | TS-user data) |
+------------+--------------+-----------------------------------------+
| TC | T-INVITE | (Called address, Calling address, |
| invitation | request | TC-characteristics, TS-user data) |
| | T-INVITE | (Called address, Calling address, |
| | indication | TC-characteristics, TS-user data) |
Dae Young Kim Expires 12/31/98 [Page 33]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
+------------+--------------+-----------------------------------------+
| TC join | T-JOIN | (Called address, Calling address, |
| | request | TC-characteristics, TS-user data) |
| | T-JOIN | (Called address, Calling address, |
| | indication | TC-characteristics, TS-user data) |
| | T-JOIN | (Responding address, TC-characteristics,|
| | response | TS-user data) |
| | T-JOIN | (Responding address, TC-characteristics,|
| | confirm | TS-user data) |
+------------+--------------+-----------------------------------------+
| Data | T-DATA | (TS-user data) |
| transfer | request | |
| | T-DATA | (Calling address, Status, TS-user data) |
| | indication | |
| | T-UNITDATA | (Called address, Calling address, |
| | request | TC-characteristics, TS-user data) |
| | T-UNITDATA | (Called address, Calling address, |
| | indication |TC-characteristics, Status,TS-user data) |
| Pause | T-PAUSE | (Reason) |
| | indication | |
| Resume | T-RESUME | (Reason) |
| | indication | |
| Report | T-REPORT | (Reason) |
| | indication | |
+------------+--------------+-----------------------------------------+
| TC leave | T-LEAVE | (Called address, Calling address, |
| | request | TS-user data) |
| | T-LEAVE | (Called address,Reason) |
| | indication | |
+------------+--------------+-----------------------------------------+
| TC | T-TERMINATE | (TS-user data) |
| termination| request | |
| | T-TERMINATE | (Reason, TS-user data) |
| | indication | |
+------------+--------------+-----------------------------------------+
| TC- | T-OWNER | (Called address, Calling address, |
| ownership | request | TS-user data) |
| | T-OWNER | (Called address, Calling address, |
| | indication | TS-user data) |
| | T-OWNER | (Responding address, TS-user data) |
| | response | |
| | T-OWNER | (Responding address, TS-user data) |
| | confirm | |
+------------+--------------+-----------------------------------------+
| Token give | T-GIVE | (Called address, Calling address, |
| | request | TS-user data) |
| | T-GIVE | (Called address, Calling address, |
| | indication | TS-user data) |
Dae Young Kim Expires 12/31/98 [Page 34]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
| | T-GIVE | (Responding address, TS-user data) |
| | response | |
| | T-GIVE | (Responding address, TS-user data) |
| | confirm | |
+------------+--------------+-----------------------------------------+
| Token get | T-GET | (Called address, Calling address, |
| | request | TS-user data) |
| | T-GET | (Called address, Calling address, |
| | indication | TS-user data) |
| | T-GET | (Responding address, TS-user data) |
| | response | |
| | T-GET | (Responding address, TS-user data) |
| | confirm | |
+------------+--------------+-----------------------------------------+
Table 4 - Enhanced Communications Transport Service primitives
11.2 Sequence of primitives at a TSAP
This subclause defines the constraints on the sequences in which the
primitives defined in clauses 12-22 may occur. The constraints
determine the order in which primitives may occur, but do not fully
specify when they may occur. Other constraints, such as flow control
of data, will affect the ability of a TS-user or a TS-provider to
issue a primitive at any particular time.
A primitive issued at one TSAP will, in general, have consequences at
the other TSAPs. The relations of primitives of each type to
primitives at the other TC endpoints are defined in the appropriate
clauses 12-22.
The possible overall sequences of primitives at a TSAP are defined in
the state transition diagrams, Figures 5 to 7. In the diagrams:
a) a primitive which is not shown as resulting in a transition
(from one state to the same state, or from one state to a
different state) is not permitted in that state;
b) the Idle state reflects the absence of a relationship between
the TS-user and the TC. It is the initial and final state of
any sequence, and upon returning to this state, the TS-user may
not participate in the TC;
c) the use of a state transition diagram to describe the allowable
sequences of service primitives does not impose any requirements
or constraints on the internal organization of any
implementations of the Transport Service.
Dae Young Kim Expires 12/31/98 [Page 35]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
12 TC Creation service
12.1 Function
The TC Creation primitives can be used by the TC-owner to establish a
homogeneous TC, provided the enrolled TS-users exist and are known to
the TS-provider.
TC-characteristics, i.e., AGI and QoS are assumed to have been defined
and known both to the TS-users and the TS-provider beforehand.
The TC Creation service will further refine the QoS, if necessary, and
check the identities of the TC-participants to validate the AGI
condition.
It is assumed that there exists one and only one TC-owner who
possesses the right to create and terminate a TC of a given enrolled
group.
Dae Young Kim Expires 12/31/98 [Page 36]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
+--------+ +--------+ T-JOIN.ind +--------+
| | T-INVITE.req | Invite |===========>|Incoming|
| Idle |==============>| Pending| |Join |
| | (with group | |<===========|Pending |
+--------+ address) +--------+T-LEAVE.req +--------+
| 1 A <\_ 1
T-REPORT | T-JOIN.req 1 1 \_ T-LEAVE.req 1
indication | 1 1 \_ T-LEAVE.ind 1
+====+ | 1 1 \_ 1
1 1 | 1 1 \_ 1
V 1 | 1 1 \_ T-JOIN.1
+-----------+ | T-CREATE 1 1 \_ res 1
|Incoming | | request 1 1 \ V
|Join | | 1 1T-LEAVE.req +--------+
|Processing1| V V 1T-LEAVE.ind |Outgoing|
+-----------+ +--------+ +--------+ |Join |
1 A |Outgoing| |Outgoing| |Response|
1 1T-JOIN. |Create | |Join | |Pending |
T-JOIN. 1ind |Pending | |Pending | +--------+
res 1 1 +--------+ +--------+ ___/
T-LEAVE. 1 \ / ___/
req 1 1 \ T-CREATE. /T-JOIN. ___/ T-REPORT.ind
1 1 \_ con __/ con ___/
1 1 | | ___/
V 1 v v _/
+---------+ +-----------+</ +------------+
| Data |<================| Data |=============>|Incoming |
| Transfer| T-PAUSE.ind | Transfer | T-JOIN.ind | Join |
|suspended|================>| Ready |<=============|processing 2|
+---------+ T-RESUME.ind +-----------+ T-JOIN.res +------------+
1 A 1 A T-LEAVE.req 1 A
1 1 1 1 1 1
+=====+ +===+ +=====+
T- REPORT.ind [1] [2]
[1] T-DATA.req [2] T-DATA.req
T-REPORT.ind T-REPORT.ind
T-INVITE.req
Figure 5(a) - State transition diagram of a TC-owner
Dae Young Kim Expires 12/31/98 [Page 37]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
+---------+ +-----------+ +------------+
| Data |<================| Data |=============>|Incoming |
| Transfer| T-PAUSE.ind | Transfer | T-JOIN.ind | Join |
|suspended|================>| Ready |<=============|processing 2|
+---------+ T-RESUME.ind __+-----------__ T-JOIN.res +------------+
1 A __/ A A | A | A \_T-LEAVE.req 1 A
1 1 __/ ___| | | | | |__ \_ 1 1
+=====+ / _/ | +=+ | \__ \_ +===+
T-REPORT.ind _/ _/ T-GET.| [1] |T-GET. \+ \+ [2]
____+/ / res | | ind |\ |\________
T-GIVE.| | _+/ | | | \| | T-GET.
req V |_/ | | V | \ V req
+----------+ / | +----------+ | |\ +----------+
|Token |__/| | |Token | | | \____|Token |
|Allocation|T-GIVE.| |Request | | |T-GET.|Withdrawal|
|Pending |con| | |Acceptance| | | con |Pending |
+----------+ | | |pending | | | +----------+
1 A | | T-OWNER. +----------+ | | 1 A
1 1 T-OWNER.| | con 1 A T-GIVE.| | T-GIVE. 1 1
+===+ req V | 1 1 res | V ind +==+
[2] +---------+ +==+ +---------+ [2]
|Ownership| [2] |Token |
|Transfer | |Returned |
|Pending | |Pending |
+---------+ +---------+
1 A 1 A
1 1 1 1
+===+ +===+
[2] [2]
[1] T-DATA.req [2] T-DATA.req
T-DATA.ind T-DATA.ind
T-REPORT.ind T-REPORT.ind
T-INVITE.req
Figure 5(b) - State transition diagram of a TC-owner
NOTE - T-TERMINATE request and/or indication may occur at any
states, except the idle states, which then will lead to the
idle state. All states except the Data Transfer Suspended
include a self-loop branch due to T-UNITDATA request and
T-UNITDATA indication; these primitives may occur at such
states without causing transition to other states.
Dae Young Kim Expires 12/31/98 [Page 38]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
+--------+ +--------+ T-JOIN.ind +--------+
| | T-INVITE.req | Invite |===========>|Incoming|
| Idle |==============>| Pending| |Join |
| | (with group | |<===========|Pending |
+--------+ address) +--------+T-LEAVE.req +--------+
A / A A _/
| T-JOIN.req / / 1 _/
| / / 1T-LEAVE.req _/
T-LEAVE.req | __/ / 1T-LEAVE.ind _/
T-LEAVE.ind | / / 1 _/ T-JOIN.res
| __/ / 1 _/ +=====+
| / __/ 1 ____/ | [1] |
| ______/ / 1 | | V
| | _____/T-LEAVE.req 1 V +---------+
| V | T-LEAVE.ind +--------+ |Outgoing |
| +---------+ |Outgoing| |Ownership|
| |Outgoing | |Join | |Transfer |
| |Join | |Response| |Pending |
| |Pending | |Pending | +---------+
| +---------+ +--------+ ___/ A
| \ / ___/ |
| \_T-JOIN.con /T-REPORT. ___/ T-OWNER.
+____________ \__ __/ ind ___/ res
| | | ___/ T-REPORT. |
| V V _/ ind |
+---------+ +-----------+</ +------------+
| Data |<================| Data | |Incoming |
| Transfer| T-PAUSE.ind | Transfer |=============>|Join |
|suspended|================>| Ready | T-OWNER.ind |processing 2|
+---------+ T-RESUME.ind +-----------+ +------------+
1 A 1 A 1 A
1 1 1 1 1 1
+====+ +===+ +===+
T- REPORT.ind [1] [1]
[1] T-DATA.req [2] T-DATA.ind
T-DATA.ind T-REPORT.ind
T-REPORT.ind
Figure 6(a)- State transition diagram of a focal
in a heterogeneous TC
Dae Young Kim Expires 12/31/98 [Page 39]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
+---------+ +-----------+ +------------+
| Data |<================| Data | |Incoming |
| Transfer| T-PAUSE.ind | Transfer |=============>|Join |
|suspended|================>| Ready | T-OWNER.ind |processing 2|
+---------+ T-RESUME.ind __+-----------+_ +------------+
1 A +_/ A A | A | A \_ 1 A
1 1 __/| ___| | | | | |__ \_ 1 1
+=====+ / |_/ | +=+ | \__ \_ +===+
T-REPORT.ind _/ _/ | [1] | \+ \_ [1]
_____/ +/ | | T-GET.req |\ \________
T-GIVE.| _/| | T-GET.con | | \ | T-GET.req
req V _/ | | | V | \ V
+----------+ / | | +--------+ | \ +----------+
|Token |__/ | | |Token | | \____|Token |
|Allocation|T-GIVE. | | |Request | | T-GET.|Withdrawan|
|Pending |con | | |Pending | | con |Pending |
+----------+ | | +--------+ | +----------+
1 A | | | 1 A | 1 A |
1 1 | | | 1 A | 1 1 |
+=+ | | | +===+ | +===+ |
[2] | +--------+ +-----+ [2] | [2] |
| | | +----+ T-GET.res
T-GIVE.res | T-GIVE.req / |_______________ |
| |T-REPORT.ind | T-GIVE.con | |
V | V / T-REPORT.ind | V
+-----------+ +----------+ +---------+
|Token | | Token | |Token |
|Allocated | | Returned | |Withdrawn|
|Response | | Pending | |Response |
|Pending | +----------+ |Pending |
+-----------+ 1 A +---------+
1 A 1 1 1 A
1 1 +===+ 1 1
+===+ [2] +===+
[2] [2]
[1] T-DATA.req [2] T-DATA.ind
T-DATA.ind T-REPORT.ind
T-REPORT.ind
Figure 6(b) - State transition diagram of a focal TS-user
in a heterogeneous TC
NOTE - T-TERMINATE request and/or indication may occur at any
states, except the idle states, which then will lead to the
idle state. All states except the Data Transfer Suspended
include a self-loop branch due to T-UNITDATA request and
T-UNITDATA indication; these primitives may occur at such
states without causing transition to other states.
Dae Young Kim Expires 12/31/98 [Page 40]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
T-LEAVE.req
T-LEAVE.ind
+------------> +--------+ +--------+ T-JOIN.ind +--------+
| +---------> | |T-INVITE.req | Invite |===========>|Incoming|
| T-CREATE.req | Idle |============>| Pending| |Join |
| |+--------- | | (with group | |<===========|Pending |
| || T-CRATE. +--------+ address) +--------+T-LEAVE.req +--------+
| |V ind A | A | A--------------+ A _/
| +--------+ | | | +---------+ | 1 _/
| |Incoming| | | | T-INVITE.ind| 1T-LEAVE.req _/
| |Create | | |T-LEAVE.req | | 1T-LEAVE.ind _/
| |Pending | | |T-LEAVE.ind V | 1 _/ T-JOIN.res
| +--------+ | | | +-------+ | 1 _/
| | | | | |Invited| | 1 ____/
| T-CRATE.res | | | +-------+ | 1 |
| | +--------+ \ +---+ | +-+ 1 | [1]
| | | T-JOIN.req| | | 1 | +====+
| |T-LEAVE.req \_ | T-JOIN.req | 1 | | |
| |T-LEAVE.ind | | | | 1 | | V
| V | V | V | 1 V +---------+
| +--------+ +----------+ | +--------+ |Outgoing |
| |Outgoing| |Outgoing | | |Outgoing| |Ownership|
| |Create | |Join | | |Join | |Transfer |
| |Response| |Processing| | |Response| |Pending |
| |Pending | +----------+ | |Pending | +---------+
| +--------+ | | +--------+ ___/ A
| | | T-INVITE.ind / ___/ |
| T-REPORT.ind T-JOIN.con | T-REPORT. ___/ T-OWNER.
| | +---+ | __/ ind ___/ res
| +-----------------------+ | || __/ T-REPORT. |
| V V |V __/ ind |
+---------+ +-----------+</ +------------+
| Data |<================| Data | |Incoming |
| Transfer| T-PAUSE.ind | Transfer |=============>|Join |
|suspended|================>| Ready | T-OWNER.ind |processing 2|
+---------+ T-RESUME.ind +-----------+ +------------+
1 A 1 A 1 A
1 1 1 1 1 1
+===+ +====+ +===+
T- REPORT.ind [1] [1]
[1] T-DATA.req [2] T-DATA.ind
T-DATA.ind T-REPORT.ind
T-REPORT.ind
Figure 7(a)- State transition diagram of a non-focal TS-user
Dae Young Kim Expires 12/31/98 [Page 41]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
+---------+ +-----------+ +------------+
| Data |<================| Data | |Incoming |
| Transfer| T-PAUSE.ind | Transfer |=============>|Join |
|suspended|================>| Ready | T-OWNER.ind |processing 2|
+---------+ T-RESUME.ind __+-----------+_ +------------+
1 A +_/ A A | A | A \_ 1 A
1 1 __/| ___| | | | | |__ \_ 1 1
+=====+ / |_/ | +=+ | \__ \_ +===+
T-REPORT.ind _/ _/ | [1] | \+ \_ [1]
_____/ +/ | | T-GET.req |\ \________
T-GIVE.| _/| | T-GET.con | | \ | T-GET.req
req V _/ | | | V | \ V
+----------+ / | | +--------+ | \ +----------+
|Token |__/ | | |Token | | \____|Token |
|Allocation|T-GIVE. | | |Request | | T-GET.|Withdrawan|
|Pending |con | | |Pending | | con |Pending |
+----------+ | | +--------+ | +----------+
1 A | | | 1 A | 1 A |
1 1 | | | 1 A | 1 1 |
+=+ | | | +===+ | +===+ |
[2] | +--------+ +-----+ [2] | [2] |
| | | +----+ T-GET.res
T-GIVE.res | T-GIVE.req / |_______________ |
| |T-REPORT.ind | T-GIVE.con | |
V | V / T-REPORT.ind | V
+-----------+ +----------+ +---------+
|Token | | Token | |Token |
|Allocated | | Returned | |Withdrawn|
|Response | | Pending | |Response |
|Pending | +----------+ |Pending |
+-----------+ 1 A +---------+
1 A 1 1 1 A
1 1 +===+ 1 1
+===+ [2] +===+
[2] [2]
[1] T-DATA.req [2] T-DATA.ind
T-DATA.ind T-REPORT.ind
T-REPORT.ind
Figure 7(b) - State transition diagram of a non-focal TS-user
NOTE - T-TERMINATE request and/or indication may occur at any
states, except the idle states, which then will lead to the
idle state. All states except the Data Transfer Suspended
Dae Young Kim Expires 12/31/98 [Page 42]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
include a self-loop branch due to T-UNITDATA request and
T-UNITDATA indication; these primitives may occur at such
states without causing transition to other states.
12.2 Types of primitives and parameters
Table 5 lists the types of primitives and parameters associated with a
TC creation
Table 5 - TC creation primitives and parameters
+----------------+---------+----------+---------+---------+----------+
| |T-CREATE | T-CREATE |T-CREATE |T-CREATE | T-REPORT |
| | request |indication| reponse | confirm |indication|
+----------------+---------+----------+---------+---------+----------+
| Called address | X | X(=) | | | |
+----------------+---------+----------+---------+---------+----------+
| Calling address|X(Note 1)| X(=) | | | |
+----------------+---------+----------+---------+---------+----------+
| Responding | | | | | |
| address | | |X(Note 1)|X(Note 2)| |
+----------------+---------+----------+---------+---------+----------+
| TC | | | | | |
| characteristics| X | X | X |X(Note 3)| |
+----------------+---------+----------+---------+---------+----------+
| TS-user data | X(U) | X(=) | X(U) | X(=) | |
+----------------+---------+----------+---------+---------+----------+
| Reason | | | | |X(Note 3) |
+----------------+---------+----------+---------+---------+----------+
NOTE 1 - This parameter may be implicitly associated with the TSAP at
which the primitive is issued.
NOTE 2 - This is a list of addresses of the responding TS-users.
NOTE 3 - This includes the OA QoS values.
12.2.1 Called address
The called address parameter conveys a TSAP address that identifies
the TS-user(s) expected to participate in the TC being established.
12.2.2 Calling address
The calling address parameter conveys the TSAP address of the TC-owner
by whom the TC creation has been requested.
12.2.3 Responding address
Dae Young Kim Expires 12/31/98 [Page 43]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The responding address parameter conveys the address of the TSAP of
the TS-user to participate in the TC and to which TS-user data should
be delivered when the TC is in the Data Transfer state.
12.2.4 TC-characteristics
The TC-characteristics parameter conveys the AGI and QoS for the TC.
Whereas the AGI parameters are not for negotiation, the QoS values may
be changed in the sequel of primitives. The QoS in the request
primitive is what proposed by the TC-owner; that in the indication
primitive is what modified by the TS-provider; that in the response
primitive is what counter-proposed by the responding TS-users; that in
the confirm primitive is what arbitrated by the TS-provider.
12.2.5 TS-user data
The TS-user data parameter allows the transfer of TS-user data among
TS-users without modification by the TS-provider.
12.2.6 Reason
The reason parameter of the REPORT indication primitive conveys the
TC-characteristics including the OA QoS values.
12.3 Sequence of primitives
The sequence of primitives in a successful TC creation is defined by
Figure 8. Note that a confirm primitive is delivered only to the TC-
owner who has previously issue the request primitive and other TS-
users are supplied with a T-REPORT indication.
Dae Young Kim Expires 12/31/98 [Page 44]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
\ | | | |
\ | | | |
T-CREATE v | | | |
request |\ | | |
| \ |T-CREATE | T-CREATE | T-CREATE
| \ |indication | indication | indication
| \|- - - - - -|- - - - - - -|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
| | | |
| | T-CREATE | T-CREATE | T-CREATE
| | response | response | response
| | / | / | /
| | / | / | /
| |v_ _ _ _ _ |v_ _ _ _ _ _ |v
| / | | |
| @ | | |
| / \ | | |
|/ \|_ _ _ _ _ _|_ _ _ _ _ _ _|
T-CREATE /| |\ |\ |\
confirm / | | \ | \ | \
/ | | \ | \ | \
v | | v | v | v
| | T-REPORT | T-REPORT | T-REPORT
| | indication| indication | indication
Figure 8 - Sequence of primitives in a successful TC creation
The TC Creation procedure may fail either due to the inability of the
TS-provider to establish a TC, due to the unsuccessful negotiation of
the QoS, or due to the failure of the AGI condition.
13 TC Invitation service
13.1 Function
The TC Invitation primitives can be used by the TC-owner to invite the
TS-users to collectively establishing a heterogeneous TC, provided the
enrolled TS-users exist and are known to the TS-provider. A
heterogeneous TC is established by individual establishment of
multiple 1xN simplex channels, each by every focal TS-user through
Join primitives. The TC Invitation primitive can also be used by the
TC-owner to invite a TS-user to join an already existing TC.
In both cases, the TC Invitation service is normally followed by the
Dae Young Kim Expires 12/31/98 [Page 45]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
TC Join service.
TC-characteristics, i.e., AGI and QoS are assumed to have been defined
and known both to the TS-users and the TS-provider beforehand.
The TC Invitation service does not change the TC-characteristics it
conveys.
It is assumed that there exists one and only one TC-owner who
possesses the right to invoke the Invitation service.
13.2 Types of primitives and parameters
Table 6 lists the types of primitives and parameters associated with a
TC invitation.
Table 6 - TC invitation primitives and parameters
+--------------------+-------------------+---------------------+
| | T-INVITE | T-INVITE |
| | request | indication |
+--------------------+-------------------+---------------------+
| Called address | X | X(=) |
|--------------------+-------------------+---------------------+
| Calling address | X | X(=) |
+--------------------+-------------------+---------------------+
| TC characteristics | X | X(=) |
+--------------------+-------------------+---------------------+
| TS-user data | X(U) | X(=) |
+--------------------+-------------------+---------------------+
13.2.1 Called address
In the invitation to establishing a heterogeneous TC, the called
address parameter conveys a TSAP address that identifies the TS-
user(s) expected to participate in the heterogeneous TC being
established. In the invitation to an existing TC, the called address
parameter conveys a TSAP address that identifies the TS-user being
invited.
13.2.2 Calling address
The calling address parameter conveys the TSAP address of the TC-owner
by whom the TC invitation has been requested.
13.2.3 TC-characteristics
The TC-characteristics parameter conveys the AGI and QoS for the TC.
Dae Young Kim Expires 12/31/98 [Page 46]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
Both the AGI and the QoS parameters are not changed in the sequel of
primitives.
13.2.4 TS-user data
The TS-user data parameter allows the transfer of the TC-owner data to
other TS-users.
13.3 Sequence of primitives
13.3.1 Invitation for a heterogeneous TC
The TC Invitation primitives can be used by the TC-owner to invite the
TS-users to collectively establishing a heterogeneous TC. The sequence
of primitives in a TC Invitation is defined by Figure 9. Note that
the TC invitation primitives are normally followed each by a JOIN
request primitive defined below, thus initiating the Join service
depicted in the time-sequence diagram of Figure 11.
\ | | | |
\ | | | |
v | | | |
|\ | | |
T-INVITE | \ | T-INVITE | T-INVITE | T-INVITE
request | \ | indication| indication| indication
| \|- - - - - -|- - - - - -|
| |\ |\ |\
| | \ | \ | \
| | v | v | v
| | | |
| | | |
T-JOIN | | T-JOIN | | T-JOIN
request | | request | | request
\ | | / | | /
\ | | / | | /
v | |v | |v
| | | |
Figure 9 - Sequence of primitives in a TC invitation
The TC invitation procedure may fail either due to the inability of
the TS-provider or due to the failure of the AGI condition.
13.3.2 Invitation for a late join
The TC Invitation primitives can be used by the TC-owner to invite a
specified TS-user to joining an already existing TC. The sequence of
primitives in such a TC Invitation is defined by Figure 10.
Dae Young Kim Expires 12/31/98 [Page 47]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
\ | | | |
\ | | | |
v | | | |
|\ | | |
T-INVITE | \ | T-INVITE | |
request | \ | indication| |
| \|- - - - - -|- - - - - -|
| |\ | |
| | \ | |
| | v | |
| | | |
| | | |
| | T-JOIN | |
| | request | |
| | / | |
| | / | |
| |v | |
| | | |
Figure 10 - Sequence of primitives in a TC invitation for a
specified TS-user to join an already existing TC
14 TC Join service
14.1 Function
The TC Join primitives can be used by the focal TS-user to establish a
heterogeneous TC, provided the enrolled TS-users exist and are known
to the TS-provider.
The primitive can also be used by a TS-user to join an already
existing homogenous TC as a send and/or receive TS- user or a
heterogeneous TC as a receive-only user.
TC-characteristics, i.e., AGI and QoS are assumed to have been defined
and known both to the TS-users and the TS-provider beforehand.
The TC Join service will further refine the QoS, if necessary, and
check the identities of the TC-participants to validate the AGI
condition.
14.2 Types of primitives and parameters
Table 7 lists the types of primitives and parameters associated with a
TC Join.
Dae Young Kim Expires 12/31/98 [Page 48]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
Table 7 - TC Join primitives and parameters
+----------------+---------+----------+---------+---------+----------+
| | T-JOIN | T-JOIN | T-JOIN | T-JOIN | T-REPORT |
| | Request |Indication|Response | Confirm |Indication|
+----------------+---------+----------+---------+---------+----------+
| Called address | X | X(=) | | | |
+----------------+---------+----------+---------+---------+----------+
| Calling address|X(Note 1)| X(=) | | | |
+----------------+---------+----------+---------+---------+----------+
| Responding | | | | | |
| address | | |X(Note 1)|X(Note 2)| |
+----------------+---------+----------+---------+---------+----------+
| TC | | | | | |
| characteristics| X | X | X |X(Note 3)| |
+----------------+---------+----------+---------+---------+----------+
| TS-user data | X(U) | X(=) | X(U) | X(=) | |
+----------------+---------+----------+---------+---------+----------+
| Reason | | | | |X(Note 3) |
+----------------+---------+----------+---------+---------+----------+
NOTE 1 - This parameter may be implicitly associated with the TSAP
at which the primitive is issued.
NOTE 2 - This is a list of addresses of the responding TS-users or
the address of the TC-owner.
NOTE 3 - This includes the arbitrated QoS values.
14.2.1 Called address
In the case of a heterogeneous TC establishment, the called address
parameter conveys a (group) TSAP address that identifies the TS-
user(s) expected to participate in the TC being established. In the
case of a late join wherein a TS-user attempts to join an existing TC,
the called address conveys the group address of the TC to join.
14.2.2 Calling address
In the case of a heterogeneous TC establishment, the calling address
parameter conveys the TSAP address of the focal TS-user by whom the TC
join has been requested. In the case of a late join, the calling
address conveys the address of the TS-user attempting to join the
existing TC.
14.2.3 Responding address
In the case of a heterogeneous TC establishment, the responding
Dae Young Kim Expires 12/31/98 [Page 49]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
address parameter conveys the address of the TSAP of the TS-user to
participate in the TC and to which TS-user data should be delivered
when the TC is in the Data Transfer state. In the case of a late
join, the responding address conveys the address of the TC-owner.
14.2.4 TC-characteristics
The TC-characteristics parameter conveys the AGI and QoS for the TC.
Whereas the AGI parameters are not for negotiation, the QoS values may
be changed in the sequel of primitives for the establishment of each
1xN simplex channel. The QoS in the request primitive is what proposed
by the focal TS-user; that in the indication primitive is what
modified by the TS-provider; that in the response primitive is what
counter-proposed by the responding TS-users; that in the confirm
primitive is what arbitrated by the TS-provider.
In the case of a late join, the QoS may not be changed. The late
coming TS-user either obeys the QoS of the homogeneous TC or he joins
a heterogeneous TC as a receive-only member.
14.2.5 TS-user data
The TS-user data parameter allows the transfer of TS-user data among
TS-users without modification by the TS-provider.
14.2.6 Reason
The reason parameter of the REPORT indication primitive conveys the
TC-characteristics including the arbitrated QoS values.
14.3 Sequence of primitives
The sequence of primitives in a successful TC join in the case of a
heterogeneous TC establishment is defined by Figure 11. Note that a
confirm primitive is delivered only to the TS-user who has previously
issued the request primitive and other TS-users are supplied with a T-
REPORT indication.
The sequence of primitives in a successful TC late join is defined by
Figure 12. Note that both a confirm and a report primitive are
delivered to the late joining TS-user while other TS-users are
supplied only with a report primitive.
The TC Join procedure may fail either due to the inability of the TS-
provider to establish a TC, due to the unsuccessful negotiation of
the QoS, or due to the failure of the AGI condition.
Dae Young Kim Expires 12/31/98 [Page 50]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
\ | | | |
\ | | | |
v| | | |
T-JOIN |\ | | |
request | \ |T-JOIN | T-JOIN | T-JOIN
| \ |indication | indication | indication
| \|-----------|-------------|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
| | | |
| | T-JOIN | T-JOIN | T-JOIN
| | response | response | response
| | / | / | /
| | / | / | /
| |v__________|v___________ |v
| / | | |
| @ | | |
| / \ | | |
|/ \|___________|_____________|
T-JOIN /| |\ |\ |\
confirm / | | \ | \ | \
/ | | \ | \ | \
v | | v | v | v
| | T-REPORT | T-REPORT |T-REPORT
| | indication| indication |indication
Figure 11 - Sequence of primitives in a successful TC Join by a focal
TS-user
Dae Young Kim Expires 12/31/98 [Page 51]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
| | / | |
| | / | |
| |v | |
| \| T-JOIN | |
| \ | request | |
T-JOIN | \ | | |
indication \| | | |
/ | | | |
/ | | | |
v | | | |
| | | |
| | | |
\ | | | |
\ | | | |
T-JOIN \ | | | |
response v| | | |
|\ | T-JOIN | |
| \@\ | confirm | |
| \ \| | |
| \ |\ | |
| \ | v | |
| \|_ _ _ _ _ _|_ _ _ _ _ _|
| |\ |\ |\
| | \ | \ | \
| | v | v | v
| |T-REPORT |T-REPPRT |T-REPORT
| |indication |indication |indication
Figure 12 - Sequence of primitives in a successful TC join by a
TS-user in a homogeneous TC or by a receive-only TS user
in a heterogeneous TC
15 Data Transfer service
15.1 Function
The Data Transfer service provides for two types of transfer of TSDUs
from a sending TS-user to the other receiving TS-user(s). In one type,
data transfer takes place over a successfully established TC using T-
DATA primitives. In the other type, data transfer takes place at any
phase of a TC using T-UNITDATA primitives; it may take place even when
no TC is available between the sending and the receiving TS-users.
15.2 Types of primitives and parameters
Table 8 indicates the types of primitives and the parameters for the
Data Transfer service.
Dae Young Kim Expires 12/31/98 [Page 52]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
Table 8 - Data transfer primitives and parameters
+-----------------+-----------+------------+-----------+------------+
| | T-DATA | T-DATA |T-UNITDATA |T-UNITDATA |
| | request | indication | request | indication |
+-----------------+-----------+------------+-----------+------------+
| Called address | | | X | X(=) |
|-----------------+-----------+------------+-----------+------------+
| Calling address | | X | X | X(=) |
|-----------------+-----------+------------+-----------+------------+
| TC | | | X | X(=) |
| characteristics | | | | |
|-----------------+-----------+------------+-----------+------------+
| Status | | X | | X |
|-----------------+-----------+------------+-----------+------------+
| TC user data | X | X(=) | X | X(=) |
+-----------------+-----------+------------+-----------+------------+
15.2.1 Called address
The called address parameter may be present only in T-UNITDATA
primitives and conveys a TSAP address that identifies the TS-user(s)
expected to received the data sent.
15.2.2 Calling address
The calling address parameter conveys a TSAP address that identifies
the TS-user who has sent the data.
15.2.3 TC-characteristics
The TC-characteristics parameter may be present only in T-UNITDATA
primitives. All parameters of the TC-characteristics except the
transit delay shall be of null value.
15.2.4 Status
The notification of detected but not corrected errors is signaled
through the status parameter to the TS-user.
The status parameter conveys a notification to the TS-user that
a) the TS-user data is corrupted (errors detected but not corrected)
or
b) the TS-user data is substituted (errors detected and substituted)
or
Dae Young Kim Expires 12/31/98 [Page 53]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
c) the TS-user data is of zero length (TSDU lost or corrupted).
15.2.5 TS-user data
The TS-user data parameter consists of an integral number of octets
greater than or equal to zero and allows the transfer of data from a
sending TS-user to the receiving TS-user(s), without modification by
the TS-provider.
15.3 Sequence of TS primitives
The sequence of primitives in a successful data transfer is defined by
Figures 13 and 14.
\ | | | |
\ | | | |
v | | | |
T-DATA |\ | | |
request | \ | T-DATA | T-DATA | T-DATA
| \ | indication| indication| indication
| \|_ _ _ _ _ _|_ _ _ _ _ _|
| |\ |\ |\
| | \ | \ | \
| | v | v | v
| | | |
Figure 13 - Sequence of primitives in data transfer using T-DATA
primitives
\ | | | |
\ | | | |
v | | | |
|\ | | |
T-UNITDATA | \ |T-UNITDATA |T-UNITDATA |T-UNITDATA
request | \ | indication| indication| indication
| \|_ _ _ _ _ _|_ _ _ _ _ _|
| |\ |\ |\
| | \ | \ | \
| | v | v | v
| | | |
Figure 14 - Sequence of primitives in data transfer using T-UNITDATA
primitives
16 Pause service
16.1 Function
Dae Young Kim Expires 12/31/98 [Page 54]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The Pause service provides for the TS-provider to indicate with the T-
PAUSE indication primitive to the active group TS-user(s) that the TC
has entered the state where the data transfer is not allowed. The
reason parameter within the T-PAUSE indication primitive should
deliver the reason, e.g., violation of the QoS or the AGI. Until the
TS-users are notified that TC-characteristics are met again, no T-DATA
request primitives may be issued. Data transfer resumes by the RESUME
service.
16.2 Types of primitive and parameters
Table 9 indicates the types of primitives and the parameters for the
Pause service.
Table 9 - Pause primitives and parameters
+----------------------+------------------------+
| | T-PAUSE |
| | indication |
+----------------------+------------------------+
| Reason | X |
+----------------------+------------------------+
16.2.1 Reason
The reason parameter gives information indicating the cause of the
data transfer suspension. The reason is one of the following:
a) temporary lack of local or remote resources at the TS-provider;
b) a QoS parameter temporarily below an agreed LQA level;
c) AGI temporarily below the minimum level.
16.3 Sequence of TS primitives suspending data transfer
The sequence of primitives in the Pause service is defined by Figure
15.
| | | |
T-PAUSE | | T-PAUSE | T-PAUSE | T-PAUSE
indication | | indication | indication | indication
/| U 0 |- - - - - - -|- - - - - - -|
/ | |\ |\ |\
/ | | \ | \ | \
v | | v | v | v
| | | |
Figure 15 - Sequence of primitives in TS-provider invoked suspension
of data transfer
Dae Young Kim Expires 12/31/98 [Page 55]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
17 Resume service
17.1 Function
The Resume TS primitives are used to resume the data transfer
recovering from the temporarily violated TC-characteristics. After the
receipt of the T-RESUME indication primitive, the active group TS-user
may restart issuing T-DATA request primitives, or receiving T-DATA
indication primitives.
17.2 Types of primitive and parameters
Table 10 indicates the types of primitives and the parameters for the
Resume service.
Table 10 - Resume primitives and parameters
+-------------------------+------------------------+
| | T-RESUME |
| | indication |
+-------------------------+------------------------+
| Reason | X |
+-------------------------+------------------------+
17.2.1 Reason
The reason parameter gives information indicating the reason for the
resumption of the data transfer. The reason may usually be the
recovery from the bottleneck that caused the previous Pause service.
17.3 Sequence of primitives
The sequence of primitives in the resumption of a previously suspended
data transfer is defined by Figure 16.
| | | |
| | | |
T-RESUME | | T-RESUME | T-RESUME | T-RESUME
indication | | indication | indication | indication
/| U 0 |- - - - - - -|- - - - - - -|
/ | |\ |\ |\
/ | | \ | \ | \
v | | v | v | v
| | | |
Figure 16 - Sequence of primitives in TS-provider resumption of data
transfer
Dae Young Kim Expires 12/31/98 [Page 56]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
18 Report service
18.1 Function
The report TS primitives are used to notify the change or selection of
TC-characteristics to the active TS-users during data transfer or in
TC establishments.
If the value of some TC-characteristic is changed, but not below the
minimum level, the TS-provider alters the TS-user(s) by issuing a T-
REPORT indication.
NOTE - If the value of some TC-characteristic is below its minimum
level and is not recoverable in data transfer, the TS-provider
issues a T-TERMINATE indication or a T-LEAVE indication to the
TS-user.
18.2 Types of primitive and parameters
Table 11 indicates the types of primitives and the parameters for the
Report service.
Table 11 - Report primitives and parameters
+-----------------------+------------------------+
| | T-REPORT |
| | indication |
+-----------------------+------------------------+
| Reason | X |
+-----------------------+------------------------+
18.2.1 Reason
The reason parameter gives information indicating the cause of the
report. The reason is one of the following:
a) minor lack of local or remote resources at the TS-provider;
b) detected but not fatal QoS change, e.g., degradation of QoS below
some threshold;
c) detected but not fatal AGI change.
A non-fatal change may be signaled by a T-REPORT indication, whereas a
fatal change will result in a T-LEAVE or T-TERMINATE indication. The
Dae Young Kim Expires 12/31/98 [Page 57]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
reason parameter may also convey
a) the arbitrated TC-characteristics in TC establishments, or
b) the result of the TC-ownership service, or
c) the result of the TC-token service, or
d) additional information provided by the TS-provider.
NOTE 1 - The TS-provider may provide additional information (e.g.,
accounting) for management purposes.
NOTE 2 - The TS-provider may replicate the TS-user data of some
related primitives.
18.3 Sequence of TS primitives
The sequence of primitives in the Report service as used by the TS-
provider is defined by Figure 17.
| | | |
T-REPORT | | T-REPORT | T-REPORT | T-REPORT
indication | | indication | indication | indication
\| U 0 |_ _ _ _ _ _ _|_ _ _ _ _ _ _|
/ | |\ |\ |\
/ | | \ | \ | \
v | | v | v | v
| | | |
Figure 17 - Sequence of primitives during data transfer when the TS-
provider is to give warning or notification
19 TC Leave service
19.1 Function
The TC Leave primitives are used to remove a TS-user from the TC. The
leave may be performed:
a) by a TS-user to leave the TC;
b) by a TS-provider to exclude a TS-user;
c) by a TS-user to reject TC Create or TC Join;
d) by a TS-provider to reject TC Join.
Dae Young Kim Expires 12/31/98 [Page 58]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
19.2 Types of primitives and parameters
Table 12 indicates the types of primitives and parameters associated
with the TC Leave service.
Table 12 - TC Leave primitives and parameters
+-----------------+-------------------+---------------------+
| | T-LEAVE | T-LEAVE |
| | request | indication |
+-----------------+-------------------+---------------------+
| Called address | X | X |
+-----------------+-------------------+---------------------+
| Calling address | X | |
+-----------------+-------------------+---------------------+
| Reason | | X |
+-----------------|-------------------|---------------------+
19.2.1 Called address
The called address parameter conveys:
a) in the T-LEAVE request primitive, a group TSAP address that
identifies the TC to leave;
b) in the T-LEAVE indication primitive, the TSAP address of the
TS-user to be excluded from the TC.
19.2.2 Calling address
The calling address parameter conveys the TSAP address of the TS-user
wishing to leave the TC.
19.2.3 Reason
The reason parameter gives information on the cause of the Leave. The
reason is one of the following:
a) QoS parameter below an agreed LQA level;
b) lack of local or remote resources at the TS-provider;
c) called address unknown.
19.3 Sequence of primitive
19.3.1 TS-user rejection of a TC Creation
Dae Young Kim Expires 12/31/98 [Page 59]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
A TS-user may reject a TC Creation request by a T-LEAVE request. The
sequence of primitives is defined by Figure 18.
\ | | | |
\ | | | |
\ | | | |
T-CREATE v | | | |
request |\ | | |
| \ |T-CREATE | T-CREATE | T-CREATE
| \ |indication | indication | indication
| \|- - - - - -|- - - - - - -|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
| | | |
| | T-LEAVE | T-LEAVE | T-LEAVE
| | request | response | response
| | / | / | /
| | / | / | /
| |v_ _ _ _ _ |v_ _ _ _ _ _ |v
| / | | |
| @ | | |
| / \ | | |
|/ \|_ _ _ _ _ _|_ _ _ _ _ _ _|
T-CREATE /| | |\ |\
confirm / | | | \ | \
/ | | | \ | \
v | | | v | v
| | | T-REPORT | T-REPORT
| | | indication | indication
Figure 18 - Sequence of primitives in a successful TC Creation with
some TS-user rejection(s)
19.3.2 TS-user rejection of a TC Join
A TS-user may reject a TC Join request by a T-LEAVE request. The
sequence of primitives is defined by Figure 19.
Dae Young Kim Expires 12/31/98 [Page 60]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
\ | | | |
\ | | | |
T-JOIN v | | | |
request |\ | | |
| \ |T-JOIN | T-JOIN | T-JOIN
| \ |indication | indication | indication
| \|- - - - - -|- - - - - - -|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
| | | |
| | T-LEAVE | T-JOIN | T-JOIN
| | request | response | response
| | / | / | /
| | / | / | /
| |v_ _ _ _ _ |v_ _ _ _ _ _ |v
| / | | |
| @ | | |
| / \ | | |
|/ \|_ _ _ _ _ _|_ _ _ _ _ _ _|
T-JOIN /| | |\ |\
confirm / | | | \ | \
/ | | | \ | \
v | | | v | v
| | | T-REPORT | T-REPORT
| | | indication | indication
Figure 19 - Sequence of primitives in a successful TC Join with some
TS-user rejection(s)
19.3.3 TS-provider rejection of a TC Join attempt
If the TS-provider is unable to establish a TC requested by a T-JOIN
request, it indicates this to the TS-user by T-LEAVE indication
primitive with a reason parameter. The sequence of primitives is
defined by Figure 20.
Dae Young Kim Expires 12/31/98 [Page 61]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
| | | | /
| | | | /
| | | |v
| | | | T-JOIN
| | | | request
| | | |
| | | |
| | | |
| | | | T-LEAVE
| | | |\ indication
| | | | \
| | | | \
| | | | v
Figure 20 - Sequence of primitives in TS-provider rejection of a TC
Join attempt
19.3.4 TS-user invoked Leave
A TS-user may remove itself from the TC by a T-LEAVE request. The
sequence of primitives is defined by Figure 21.
\ | | | |
\ | | | |
v | | | |
|\ | | |
T-LEAVE | \ | T-REPORT | T-REPORT | T-REPORT
request | \ | indication| indication| indication
| \|_ _ _ _ _ _|_ _ _ _ _ _|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
Figure 21 - Sequence of primitives in a TS-user leaving the active TC
19.3.5 TS-provider expulsion of a TS-user Leave
The TS-provider may expel a TS-user. The sequence of primitives is
defined by Figure 22.
Dae Young Kim Expires 12/31/98 [Page 62]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
| | | |
T-LEAVE | | T-REPORT | T-REPORT | T-REPORT
indication | | indication | indication | indication
/| U 0 |_ _ _ _ _ _ _ |_ _ _ _ _ _ _|
/ | |\ |\ |\
/ | | \ | \ | \
v | | v | v | v
| | | |
| | | |
Figure 22 - Sequence of primitives in TS-provider expulsion of a
TS-user
20 TC Termination service
20.1 Function
The TC termination primitives are used to terminate a TC. The
termination may be initiated by:
a) the TC-owner, or
b) the TS-provider due to fatal failure of some TC-characteristics.
TC termination is permitted at any time regardless of the state
of the TC. A request for termination cannot be rejected.
The Transport Service does not guarantee delivery of any TS-user data
once the termination procedure is entered.
20.2 Types of primitives and parameters
Table 13 indicates the types of primitives and parameters associated
with the TC Termination service.
Table 13 - TC Termination primitives and parameters
+-----------------+-------------------+---------------------+
| | T-TERMINATE | T-TERMINATE |
| | request | indication |
+-----------------+-------------------+---------------------+
| Reason | | X |
+-----------------|-------------------|---------------------+
| TS-user data | X(U) | X(=) |
+-----------------+-------------------+---------------------+
20.2.1 Reason
Dae Young Kim Expires 12/31/98 [Page 63]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The reason parameter gives information regarding the cause of the
termination. The reason is one of the following:
a) TC-owner invoked termination;
b) lack of local or remote resource at the TS-provider;
c) QoS below an agreed LQA level;
d) called address unknown;
e) AGI below the minimum level.
20.2.2 TS-user data
The TS-user data parameter is present in the T-TERMINATE request and
indication primitives when a termination request was originated by the
TC-owner.
20.3 Sequence of primitives
20.3.1 TC-owner invocation of a TC termination
A TC-owner may terminate a TC by a T-TERMINATE request. The sequence
of primitives is defined by Figure 23.
\ | | | |
\ | | | |
v | | | |
|\ | | |
T-TERMINATE | \ | T-TERMINATE | T-TERMINATE | T-TERMINATE
request | \ | indication | indication | indication
| \|_ _ _ _ _ _ _|_ _ _ _ _ __|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
Figure 23 - Sequence of primitives in a TC-owner invocation of a TC
termination
20.3.2 TS-provider invocation of a TC termination
The sequence may be invoked by the TS-provider to terminate a TC.
Dae Young Kim Expires 12/31/98 [Page 64]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
| | | |
T-TERMINATE | | T-TERMINATE | T-TERMINATE | T-TERMINATE
indication | | indication | indication | indication
/| U 0 |_ _ _ _ _ _ _ |_ _ _ _ _ _ _|
/ | |\ |\ |\
/ | | \ | \ | \
v | | v | v | v
| | | |
Figure 24 - Sequence of primitives in TS-provider invocation of a TC
termination
20.3.3 Simultaneous TC-owner and TS-provider invocation of a TC
termination
TC-owner may issue a T-TERMINATE request and at the same time TS-
provider may issue a T-TERMINATE indication to terminate a TC. The
sequence of primitives is defined by Figure 25.
\ | | | |
\ | | | |
\ | | | |
v| | | |
T-TERMINATE | | T-TERMINATE | T-TERMINATE | T-TERMINATE
request | U 0 | indication | indication | indication
| |_ _ _ _ _ _ _|_ _ _ _ _ __|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
Figure 25 - Sequence of primitives in simultaneous TC-owner and TS-
provider invocation of a TC termination
20.3.4 Unsuccessful TC Creation with multiple TS-user rejection(s)
If the values of the TC-characteristics parameters in the T-CREATE
responses from other TS-users do not satisfy the TC creation
condition, T-TERMINATE indication primitives are delivered to the TC-
owner and the TS-users who responded with T-CREATE response
primitive. The sequence of primitives is defined by Figure 26.
Dae Young Kim Expires 12/31/98 [Page 65]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
\ | | | |
\ | | | |
\ | | | |
T-CREATE v | | | |
request |\ | | |
| \ |T-CREATE | T-CREATE | T-CREATE
| \ |indication | indication | indication
| \|- - - - - -|- - - - - - -|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
| | | |
| | T-LEAVE | T-CREATE | T-LEAVE
| | request | response | request
| | / | / | /
| | / | / | /
| |v_ _ _ _ _ |v_ _ _ _ _ _ |v
| / | | |
| @ | | |
| / \ | | |
|/ \|_ _ _ _ _ _| |
T-TERMINATE /| | |\ |
indication / | | | \ |
/ | | | \ |
v | | | v |
| | | T-TERMINATE |
| | | indication |
Figure 26 - Sequence of primitives in an unsuccessful TC Creation with
multiple TS-user rejection(s)
20.3.5 Overall TS-user rejections of a TC creation attempt
If all TS-users respond with T-LEAVE request primitive, the T-
TERMINATE indication primitive is delivered to the TC-owner with the
reason parameter. The sequence of primitives is defined by Figure 27.
Dae Young Kim Expires 12/31/98 [Page 66]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
\ | | | |
\ | | | |
\ | | | |
T-CREATE v | | | |
request |\ | | |
| \ |T-CREATE | T-CREATE | T-Create
| \ |indication | indication | indication
| \|- - - - - -|- - - - - - -|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
| | | |
| | T-LEAVE | T-LEAVE | T-LEAVE
| | request | request | request
| | / | / | /
| | / | / | /
| |v_ _ _ _ _ |v_ _ _ _ _ _ |v
| /| | |
| / | | |
| @ | | |
|/ | | |
T-TERMINATE /| | | |
indication / | | | |
/ | | | |
v | | | |
Figure 27 - Sequence of primitives in overall TS-user rejections of a
TC creation attempt
20.3.6 TS-provider rejection of a TC creation attempt due to lack of
local resource
If the TS-provider is unable to create a TC due to lack of local
resource, it issues to the TC-owner a T-TERMINATE indication primitive
with the reason parameter. The sequence of primitives is defined by
Figure 28.
Dae Young Kim Expires 12/31/98 [Page 67]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
\ | | | |
T-CREATE \ | | | |
request v| | | |
| | | |
| | | |
| | | |
T-TERMINATION | | | |
indication | | | |
/| | | |
/ | | | |
/ | | | |
v | | | |
Figure 28 - Sequence of primitives in TS-provider rejection of a TC
creation attempt
20.3.7 TS-provider rejection of a TC creation attempt due to
incomplete TC-characteristics
If the TS-provider is unable to create a TC due to incomplete TC-
characteristics, it issues to all TS-users a T-TERMINATE indication
primitive with the reason parameter. The sequence of primitives is
defined by Figure 29.
Dae Young Kim Expires 12/31/98 [Page 68]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
\ | | | |
\ | | | |
\ | | | |
T-CREATE v | | | |
request |\ | | |
| \ |T-CREATE |T-CREATE |T-CREATE
| \ |indication |indication |indication
| \|- - - - - -|- - - - - - -|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
| | | |
| |T-CREATE |T-CREATE |T-CREATE
| |reponse |reponse |reponse
| | / | / | /
| | / | / | /
| |v_ _ _ _ _ |v_ _ _ _ _ _ |v
| / | | |
| @ | | |
| / \ | | |
|/ \|_ _ _ _ _ _|_ _ _ _ _ _ _|
T-TERMINATE /| |\ |\ |\
indication / | | \ | \ | \
/ | | \ | \ | \
v | | v | v | v
| |T-TERMINATE| T-TERMINATE |T-TERMINATE
| |indication | indication |indication
Figure 29 - Sequence of primitives in TS-provider rejection of a TC
creation attempt due to incomplete TC-characteristics
21 TC-ownership service
21.1 Function
The TC-ownership primitives can be used by the TC-owner and TS-users
to pass the TC-ownership.
The TC-ownership candidates are assumed to have been defined and known
to the all TS-users.
21.2 Types of primitives and parameters
Table 14 lists the types of primitives and parameters associated with
the TC-ownership service.
21.2.1 Called address
Dae Young Kim Expires 12/31/98 [Page 69]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The called address parameter may be a unicast TSAP address designating
a specific TS-user or the group TSAP address designating the whole TS-
users as candidate TC-owners.
Table 14 - TC Ownership primitives and parameters
+----------------+---------+----------+---------+---------+----------+
| | T-OWNER | T-OWNER | T-OWNER |T-OWNER | T-REPORT |
| | request |indication| repsonse|confirm |indication|
+----------------+---------+----------+---------+---------+----------+
| Called address | X | X(=) | | | |
+----------------+---------+----------+---------+---------+----------+
| Calling address|X(Note 1)| X(=) | | | |
+----------------+---------+----------+---------+---------+----------+
| Responding | | | | | |
| address | | | X |X(Note 2)| |
+----------------+---------+----------+---------+---------+----------+
| TS-user data | X(U) | X(=) | X(U) | X(=) | |
+----------------+---------+----------+---------+---------+----------+
| Reason | | | | |X(Note 3) |
+----------------+---------+----------+---------+---------+----------+
NOTE 1 - This is the address of the TC-owner.
NOTE 2 - This is the address of the new TC-owner.
NOTE 3 - This may replicate the TS-user data of the T-OWNER confirm
primitive.
21.2.2 Calling address
The calling address parameter conveys the TSAP address of the TC-
owner.
21.2.3 Responding address
The responding address parameter conveys the address of the TSAP of
the TS-user competing for the TC-ownership.
21.2.4 TS-user data
The TS-user data parameter allows the transfer of TS-user data among
old and new TC-owners.
21.2.5 Reason
The reason parameter of the REPORT indication primitive conveys the
result of the TC-Ownership service.
Dae Young Kim Expires 12/31/98 [Page 70]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
21.3 Sequence of primitives
21.3.1 Ownership transfer to a specified TS-user
The sequence of primitives in a successful ownership transfer to a
specified TS-user by a TC-owner is defined by Figure 30. Note that a
confirm primitive is delivered only to the TC-owner who has previously
issued the request primitive and other TS-users are supplied with a T-
REPORT indication.
\ | | | |
\ | | | |
\ | | | |
T-OWNER v | | | |
request |\ | | |
| \ | | |
| \ |T-OWNER | |
| \|indication | |
| |\ | |
| | \ | |
| | \ | |
| | v | |
| | | |
| |T-OWNER | |
| |reponse | |
| | / | |
| | / | |
| |v_ _ _ _ _ | |
| / | | |
| @ | | |
| / \ | | |
|/ \|_ _ _ _ _ _|_ _ _ _ _ _ _|
T-OWNER /| |\ |\ |\
confirm / | | \ | \ | \
/ | | \ | \ | \
v | | v | v | v
| |T-REPORT | T-REPORT |T-REPORT
| |indication | indication |indication
Figure 30 - Sequence of primitives in a successful TC ownership
transfer to a specified TS-user
The ownership transfer procedure may fail due to the rejection of the
specified TS-user. In this case, the T-REPORT may not be delivered to
other TS-users.
21.3.2 Ownership transfer to the whole TS-user candidates
Dae Young Kim Expires 12/31/98 [Page 71]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The sequence of primitives in a successful ownership transfer to the
whole TS-user candidates is defined by Figure 31. If only one TS-user
among the candidates responds, the TS-user will be selected. However,
if two or more TS-users among candidates respond, TS provider will
select one TS-user, based on predefined selection criteria. Note that
a confirm primitive is delivered only to the TC-owner who has
previously issued the request primitive and other TS-users are
supplied with a T-REPORT indication.
\ | | | |
\ | | | |
\ | | | |
T-OWNER v | | | |
request |\ | | |
| \ |T-OWNER |T-OWNER |T-OWNER
| \ |indication |indication |indication
| \|- - - - - -|- - - - - - -|
| |\ |\ |\
| | \ | \ | \
| | \ | \ | \
| | v | v | v
| | | |
| |T-OWNER |T-OWNER |T-OWNER
| |response |response |response
| | / | / | /
| | / | / | /
| |v_ _ _ _ _ |v_ _ _ _ _ _ |v
| / | | |
| @ | | |
| / \ | | |
|/ \|_ _ _ _ _ _|_ _ _ _ _ _ _|
T-OWNER /| |\ |\ |\
confirm / | | \ | \ | \
/ | | \ | \ | \
v | | v | v | v
| |T-REPORT | T-REPORT |T-REPORT
| |indication | indication |indication
Figure 31 - Sequence of primitives in a successful TC owner selection
among the TC-owner candidates
22 Token service
22.1 Function
The TC Token primitives can be used by the TC-owner and other sending
TS-users to pass around the token(s) for the right to transmit data.
Dae Young Kim Expires 12/31/98 [Page 72]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
22.2 Types of primitives and parameters
Table 15 lists the types of primitives and parameters associated with
the TC Token service.
Table 15 - TC Token primitives and parameters
+-------+------+------+------+------+------+------+------+------+------+
| |T-GIVE|T-GIVE|T-GIVE|T-GIVE|T-GET |T-GET |T-GET |T-GET |T-REPO|
| |reques|indica|respon|confir|reques|indica|respon|confir|RT |
| |t |tion |se |m |t |tion |se |m |indica|
| | | | | | | | | |tion |
+-------+------+------+------+------+------+------+------+------+------+
|Called | | | | | | | | | |
|address| X | X(=) | | | X | X(=) | | | |
+-------+------+------+------+------+------+------+------+------+------+
|Calling| | | | | | | | | |
|address| X | X(=) | | | X | X(=) | | | |
+-------+------+------+------+------+------+------+------+------+------+
|Respond| | | | | | | | | |
|ing | | | X | X(=) | | | X | X(=) | |
|address| | | | | | | | | |
+-------+------+------+------+------+------+------+------+------+------+
|TS-user| | | | | | | | | |
|data | X(U) | X(=) | X(U) | X(=) | X(U) | X(=) | X(U) | X(=) | |
+-------+------+------+------+------+------+------+------+------+------+
|Reason | | | | | | | | | X |
| | | | | | | | | |(Note)|
+-------+------+------+------+------+------+------+------+------+------+
NOTE - This may replicate the TS-user data of the T-GIVE or T-GET
confirm primitive.
22.2.1 Called address
The called address parameter may be the TSAP address of the TC-owner
or a unicast TSAP address designating a specific sending TS-user.
22.2.2 Calling address
The calling address parameter may be the TSAP address of the TC-owner
or a unicast TSAP address of a sending TS-user.
22.2.3 Responding address
The responding address parameter may be the TSAP address of the TC-
owner or a unicast TSAP address of a sending TS-user.
Dae Young Kim Expires 12/31/98 [Page 73]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
22.2.4 TS-user data
The TS-user data parameter allows the transfer of TS-user data between
the TC-owner and other TS-users.
22.2.5 Reason
The reason parameter of the REPORT indication primitive conveys the
result of the Token distribution service.
22.3 Sequence of primitives
22.3.1 Token distribution to a specified TS-user
The sequence of primitives in a successful token distribution to a
specified TS-user by a TC-owner is defined by Figure 32. Note that a
confirm primitive is delivered only to the TC-owner who has previously
issued the request primitive and other TS-users are supplied with a T-
REPORT indication.
\ | | | |
\ | | | |
\ | | | |
T-GIVE v | | | |
request |\ | | |
| \ |T-GIVE | |
| \ |indication | |
| \|- - - - - -| |
| |\ | |
| | \ | |
| | \ | |
| | v | |
| | | |
| |T-GIVE | |
| |response | |
| | / | |
| | / | |
| |v_ _ _ _ _ | |
| / | | |
| @ | | |
| / \ | | |
|/ \|_ _ _ _ _ _|_ _ _ _ _ _ _|
T-GIVE /| |\ |\ |\
confirm / | | \ | \ | \
/ | | \ | \ | \
v | | v | v | v
| |T-REPORT | T-REPORT |T-REPORT
| |indication | indication |indication
Figure 32 - Sequence of primitives in a token distribution to a
specified TS user by a TC-owner
Dae Young Kim Expires 12/31/98 [Page 74]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
The token distribution procedure may fail due to the rejection of the
specified TS-user. In this case, the T-REPORT may not be delivered to
other TS-users.
22.3.2 Token return from a specified TS-user
The sequence of primitives in a successful token return from a
specified TS-user to a TC-owner is defined Figure 33. Note that a
confirm primitive is delivered only to the TS-user who has previously
issued the request primitive and all TS-users except TC-owner are
supplied with a T-REPORT indication.
The token return procedure may fail due to the subnormal operation of
the TC-owner. In this case, the T-REPORT may not be delivered to other
TS-users.
| | / | |
| | / | |
| | / | |
| |v | |
| /| T-GIVE | |
| / | request | |
| / | | |
T-GIVE |/ | | |
indication /| | | |
/ | | | |
/ | | | |
v | | | |
| | | |
| | | |
\ | | | |
\ | | | |
T-GIVE \ | | | |
response v| | | |
|\ | T-GIVE | |
| \@\ | confirm | |
| \ \| | |
| \ |\ | |
| \ | v | |
| \|_ _ _ _ _ _|_ _ _ _ _ _|
| |\ |\ |\
| | \ | \ | \
| | v | v | v
| |T-REPORT |T-REPORT |T-REPORT
| |indication |indication |indication
Figure 33 - Sequence of primitives in a token return to a TC-owner
from a specified TS user
Dae Young Kim Expires 12/31/98 [Page 75]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
22.3.3 Token retrieval from a specified TS-user
The sequence of primitives in a successful token retrieval from a
specified TS-user by a TC-owner is defined Figure 34. Note that a
confirm primitive is delivered only to the TS-user who has previously
issued the request primitive and all TS-users except the TC-owner are
supplied with a T-REPORT indication.
\ | | | |
\ | | | |
\ | | | |
T-GET v | | | |
request |\ | | |
| \ |T-GET | |
| \ |indication | |
| \|- - - - - -| |
| |\ | |
| | \ | |
| | \ | |
| | v | |
| | | |
| |T-GET | |
| |response | |
| | / | |
| | / | |
| |v_ _ _ _ _ | |
| / | | |
| @ | | |
| / \ | | |
|/ \|_ _ _ _ _ _|_ _ _ _ _ _ _|
T-GET /| |\ |\ |\
confirm / | | \ | \ | \
/ | | \ | \ | \
v | | v | v | v
| |T-REPORT | T-REPORT |T-REPORT
| |indication | indication |indication
Figure 34 - Sequence of primitives in a forced token return from a
specified TS user by the TC-owner
The token retrieval procedure may fail due to the subnormal operation
of the specified TS-user. In this case, the T-REPORT may not be
delivered to other TS-users.
Dae Young Kim Expires 12/31/98 [Page 76]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
22.3.4 Token request from a TS-user
The sequence of primitives in a successful token request from a TS-
user to a TC-owner is defined by Figure 35. Note that a confirm
primitive is delivered only to the TS-user who has previously issued
the request primitive and all TS-users except TC-owner are supplied
with a T-REPORT indication.
The token request procedure may fail due to the rejection of TC-owner.
In this case, the T-REPORT may not be delivered to other TS-users.
| | / | |
| | / | |
| | / | |
| |v | |
| /| T-GET | |
| / | request | |
| / | | |
T-GET |/ | | |
indication /| | | |
/ | | | |
/ | | | |
v | | | |
| | | |
| | | |
\ | | | |
\ | | | |
T-GET \ | | | |
response v| | | |
|\ | T-GET | |
| \@\ | confirm | |
| \ \| | |
| \ |\ | |
| \ | v | |
| \|_ _ _ _ _ _|_ _ _ _ _ _|
| |\ |\ |\
| | \ | \ | \
| | v | v | v
| |T-REPORT |T-REPORT |T-REPORT
| |indication |indication |indication
Figure 35 - Sequence of primitives in a token acquisition by a
specified TS-user from the TC-owner
Dae Young Kim Expires 12/31/98 [Page 77]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
Annex A
TC Ordering Relationships
(This annex forms an integral part of this Recommendation |
International Standard.)
A.1 Properties of ordering
It applies at the service level and at the protocol level. At the
service level, the service provider may be required to provide
guarantees regarding the order in which TSDUs are delivered to the
receiving TS-users. At the protocol level, TPDUs are ordered, or
reordered to achieve the ordering property required by the service.
The following notation is used to describe the ordering relationships:
- S_i(m): Local event of sending a TSDU m at site i,
- A_j(m): Local event of accepting a TSDU m at site j,
- P -->Q: "An event P happens before an event Q,"
- P ==>Q: "If P is TRUE, then Q is to be TRUE,"
- P=/=>Q: "If P is TRUE, then Q does not need to be TRUE."
A.1.1 No ordering
TS-provider does not guarantee any relationship between TSDUs sent
from a single sending TS-user or from multiple sending TS-users.
Notation: S_p(m) -->S_q(m') =/=> A_i(m) --> A_i(m')
for all p,q,i;
for all (m,m') pairs.
A.1.2 Local ordering
The TSDUs, generated by a particular sending TS-user, are delivered to
all of the receiving TS-users in the same order in which they were
generated. Local ordering does not establish any ordering relationship
among TSDUs generated by different sending TS-users.
Notation: S_p(m) -->S_p(m') =/=> A_i(m) --> A_i(m')
for all p,i;
Dae Young Kim Expires 12/31/98 [Page 78]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
for all (m,m') pairs.
But, the following constraint also applies:
Notation: S_p(m) -->S_p(m') ==> A_i(m) --> A_i(m')
for any given p,i pair,
for all (m,m') pairs.
A.1.3 Causal ordering
The causal ordering orders the TSDUs generated by all sending TS-users
according to the causal dependence relationship among the sending
events. A causal dependence relationship is established between two
sending events, A and B, if the following applies:
a) A happens before B if A and B are sending events generated by the
same sending TS-user and A is sent before B;
b) A happens before B if A and B are sending events generated by two
different sending TS-users and the TSDUs generated by the event A
by one sending TS-user is received by the other sending TS-user
before it generates the event B.
A causal dependence relationship is established among more than two
sending events if it can be established that A happens before B, and
that B happens before C, it therefore follows that A happens before C.
A causal dependence relationship cannot be established between the two
sending events A and C if there is no possibility to establish that A
happens before B and that B happens before C.
If the arbitrary ordering rule is set by the TS-provider for all
receivers,
Notation: ( S_p(m) -->A_q(m) --> S_q(m') ) OR ( S_q(m)--> S_q(m') )
==> A_i(m) --> A_i(m')
for all p, q, i;
for all (m,m') pairs.
A.1.4 Partial ordering
The TSDUs, generated by all sending TS-users are delivered to each
receiving TS-user according to an arbitrary ordering rule.
If the TSDUs are ordered according to a rule applicable to all
Dae Young Kim Expires 12/31/98 [Page 79]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
receiving TS-users, then each receiving TS-user receives the TSDUs
generated by all the sending TS-users in the same order. If the TSDUs
are ordered according to a rule determined by each receiving TS-user,
then each receiving TS-user may receive the TSDUs in different orders.
Notation: If the arbitrary ordering rule is set by the TS-provider
for all receivers,
then S_p(m) -->S_q(m') =/=> A_i(m) --> A_i(m')
for all i;
for some p, q;
for all (m,m') pairs.
or
if the arbitrary ordering rule is set independently by each
receiving TS-user,
then S_p(m) -->S_q(m') =/=> A_i(m) --> A_i(m')
for some i, p, q;
for some (m,m') pairs.
A.1.5 Total ordering
The TSDUs, generated by all sending TS-users, are delivered to each
receiving TS-user in the same order. Every receiving TS-user sees all
TSDUs from all sending TS-users in exactly the same order.
Notation: S_p(m) -->S_q(m') ==> A_i(m) --> A_i(m')
for all p,q,i;
for all (m,m') pairs.
Dae Young Kim Expires 12/31/98 [Page 80]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-04.txt 30 Jun 1988
Annex B
Bibliography
(This annex does not form an integral part of this Recommendation |
International Standard.)
Many documents and papers have contributed to the construction of this
Recommendation | International Standard, some of which are:
- ISO/IEC JTC1/SC6, Draft on Multi-peer Taxonomy, P 01.06.36 (ECFF),
Oct. 14, 1994.
- ISO/IEC JTC1/SC6 N8693, Draft Multicast Taxonomy of Multicast
Operation, P 01.06.36 (ECFF), Jan. 17, 1994.
- Laurent Mathy, Guy Leduc, Olivier Bonaventure, and Andrea
Danthine, A Framework for Group Communication, RACE 2060, CIO,
Aug., 1994,
- Christophe Diot, Patrick Cocquet, and Didier Stunault,
Specifications of ETS, the Enhanced Transport Service, May 1992.
- Yves Baguette, ULg, Enhanced Transport Service Definition, RACE
2060, CIO, Feb. 5, 1994.
- Lutz Henckel, Multipeer Connection-mode Transport Service
Definition based on the Group Communication Framework, RACE 2060,
CIO, June, 1994.
- ITU-T X.tms (1993E), Information Technology - Open Systems
Interconnection - Multicast Transport Service Definition.
- Helene Maisonniaux and Patrick Cocquet, Multi-peer Transport
Service, 4B22, July 25, 1995.
Dae Young Kim Expires 12/31/98 [Page 81]