INTERNET-DRAFT D. Y. KIM draft-kim-jtc1-sc6-ects-01.txt Chungnam Univ. 30 Nov. 1996 Expires: 4/30/1997 Enhanced Communications Transport Service Definition Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo is the 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 trasnport services over the current OSI transport service; major enhancements include multicast services and enhanced QoS. This memo is distributed to possibly interested groups 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 needs of the both current and future multimedia multicast applications of widely varing ranges service requirements. It is to be noted that a protocol named 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 varyin degress of reliability and multicast QoS. Dae Young Kim Expires 4/30/97 [page 1]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Table of Contents Page Introduction ..................................................... 1 1. Scope ............................................................ 4 2. Normative References ............................................. 5 3. Definitions ...................................................... 5 4. Abbreviations .................................................... 7 5. Conventions .................................................... 7 6. Overview and General Characteristics ............................. 8 7. Features of the Enhanced Communication Transport Service ......... 9 8. Model of the Enhanced Communications Transport Service ........... 9 9. Characteristics of Transport Connection ..........................12 10 Quality-of-Service (QoS) for Transport Connections ...............13 11. Enhanced Communications Transport Service Primitives ............ 24 and Parameters 12. Transport Connection Creation Phase ............................. 29 13. Data Transfer Phase ........................................... 32 14. Transport Connection Join Phase ................................. 38 15. Transport Connection Leave Phase ................................ 41 16. Transport Connection Termination Phase .......................... 46 Annex A ............................................................. 54 Annex B ............................................................. 57 Annex C ............................................................. 72 Dae Young Kim Expires 4/30/97 [page 2]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Introduction This Recommendation | International Standard is one of a set of Reco- mmendations | International Standards produced to facilitate the i- nterconnection of computer systems. It is related to other Recomme- ndations in the set as defined by the Reference Model of Open Systems Interconnections (OSI). The OSI Reference Model (ITU-T Rec. X.200 | ISO/IEC 7498-1) subdivides the area of standardization for interco- nnection into a series of layers of specification, each of manageable size. This Recommendation | International Standard defines the service pro- vided by the Transport Layer to the Session Layer at the boundary be- tween the Transport and Session Layers of the Reference Model. It provides for the designers of Session Protocols a definition of the Transport Service existing to support the Session Protocol and for designers of Transport Protocols a definition of the services to be made available through the action of the Transport Protocol over the underlying service. This relationship is illustrated in Figure 1. +-----------+ | | Session Protocol | Session | uses service --------+ | layer | : | | v +-----------+ Transport Service | | ^ | Transport | : Transport Portocol | layer | provides service ----+ | | +-----------+ Figure 1 - Relationship of the Transport Service to the Transport Protocol and the Session Protocol Throughout the set of OSI Recommendations | International Standards, the term "service" refers to the abstract capability provided by one layer of the OSI Reference Model to the layer above it. Thus, the Transport Service defined in this Recommendation | International Sta- ndard is a conceptual architectural service, independent of admini- strative divisions. Note - It is important to distinguish the specialized use of the term "service" within the set of OSI Recommendations | Inte- rnational Standards from its use elsewhere to describe the provision of a service by an organization (such as the pro- vision of a service, as defined in other Recommendations, by an administration). Dae Young Kim Expires 4/30/97 [page 3]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 1. Scope This Recommendation | International Standard defines in an abstract way the externally visible service provided by the OSI 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 all OSI Enhanced Communications Transpo- rt Protocols (in conjunction with the Network Service) and which may be used by any OSI Session Protocol. This Recommendation | International Standard does not specify indivi- dual implementations or products, nor does it constrain the impleme- ntation of entities and interfaces within a system. Conformance of equipment to this Recommendation | International Standard is achieved by conformance to the protocols specified to fulfill the Transport Service defined in this Recommendation | International Standard. The primitives specified in this Recommendation | International Sta- ndard support a service that may be traditionally viewed as a conne- ction-mode service with three distinct phase (establishment, data transfer, and release). In some cases of connectionless-mode service supporting enhanced communications, certain operations may also be necessary prior to the commencement of data transfer, e.g., agreement on quality of service. While these operations may be viewed as a co- nnection establishment phase, reference is made to ITU-T Rec. X.214 | ISO/IEC 8072:1996 for the specification of the connectionless-mode multicast transport service. For the data transfer phase of either connection-mode or connectionle- ss-mode services, there may be a range of data-ordering characteristi- cs. These include, but not limited to: - in-sequence, time-constrained data transfer; - data transfer where sequencing may not be maintained; and - data transfer where duplicates may not be detected. No implications is made in this Recommendation | International Standa- rd regarding the inclusion or exclusion of any of the above characte- ristics given the three-phase operation of the service primitives spe- cified herein Dae Young Kim Expires 4/30/97 [page 4]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 2. Normative References The following Recommendations and International Standards contain pro- visions which, through reference in this text, constitute provisions of this Recommendation | International Standard. At the time of publi- cation, 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 inve- stigate 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 Sta- ndards. The Telecommunication Standardization Bureau of the ITU mai- ntains 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 techno- logy - Open Systems Interconnection - Basic Reference Model - the Basic Model. - ITU-T Rec. X.214 (1995) | ISO/IEC 8072:1996, Information technology - Open Systems Interconnection - Transport service definition. - 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.qsf | ISO/IEC 13236: Information technology - Quality of Service - Framework. - ITU-T Rec. X.802(1995) | ISO/IEC TR 13594:1995. Information techno- logy - Open Systems Interconnection - Lower layers security model. 3. Definitions For the purposes of this Recommendation | International Standard, the following definitions apply. 3.1. Reference Model definitions This service definition is based on the concepts developed in the OSI Basic Reference Model (ITU-T Rec. X.200 | ISO/IEC 7498-1), and makes use of the following terms defined in it: a) Transport Layer; b) Transport Service; c) Transport-Service-Access-Point; d) Transport-Service-Access-Point Address; e) Transport-Service-Data-Unit; f) Network Layer; g) Network Service. 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: Dae Young Kim Expires 4/30/97 [page 5]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 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.qsf | ISO/IEC 13236) in that it describes facilities which pertain to the Transport Layer as specified in the relevant clause of the QoS Framework. a) QoS characteristic; b) QoS mechanism; c) QoS parameter. 3.4. Enhanced Communications Transport Service definitions For the purpose of this Recommendation | International Standard, the following definitions also apply: 3.4.1. Transport Connection: A connection established among Transport Service 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. 3.4.2. Enrolled group: A group of Transport Service users who can parti- cipate in a transport connection, which is identified with a group transport-service-access-point address. 3.4.3. Group transport-service-access-point address: A transport-service- access-point address which maps to a set of individual transport-serv ice-access-point addresses of enrolled group members. 3.4.4. Active group: A group of Transport Service users which maintain the shared state information required to support the mechanisms of the data transfer phase. 3.4.5. 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. 3.4.6. Quality of Service level of agreement: The level of agreement reached during the Quality of Service negotiation mechanisms involving users and the provider. It may be: best-effort, compulsory, or guara- nteed. Dae Young Kim Expires 4/30/97 [page 6]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 3.4.7. Ordering: Ordering is concerned with the following two aspects: a) 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; b) In the case of multiple senders, ordering determines the relative sequencing of data received from multiple senders. The ordering relationship defines the arrangement or interleaving of data from the multiple senders. The ordering relationship can be: no, local, partial, causal, or total. Note - When there are only two participants in the active group, local ordering, causal ordering, and total ordering are the same. 3.4.8. TC-participant: A Transport Service user that is a member of the active group participating in a transport connection. 3.4.9. TC-owner: A Transport Service user that owns the right to create, monitor, and terminate a transport connection. 3.4.10. Sending TS user: A Transport Service 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. 3.4.11. Receiving TS user: A Transport Service 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. 4. Abbreviations AGI Active group integrity CHQ Controlled Highest Quality ECTS Enhanced Communications Transport Service LQA Lowest Quality Acceptable NSAP Network-service-access-point OSIE Open Systems Interconnection Environment QoS Quality of Service TC Transport Connection TCEP Transport Connection endpoint TS Transport Service TSAP Transport-service-access-point TSDU Transport-service-data-unit TPDU Transport-protocol-data-unit 5. Conventions 5.1. General conventions This service definition uses the descriptive conventions given in ITU-T Rec. X.210 | ISO/IEC 10731. Dae Young Kim Expires 4/30/97 [page 7]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 5.2. Parameters The available parameters for each group of primitives are set out in tables in Clauses 11 to 12. Each 'X' in the tables indicates that the primitive labeling the column in which it falls may carry the parame- ter 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 primi- tive is always identical to that supplied in the previous request primitive issued at the peer service access point. 6. Overview and General Characteristics The Transport Service provides for the transparent transfer of data among TS users. It relieves the TS users from any concern about the detailed way in which supporting communications media are utilized to achieve this transfer. The Transport Service provides for the following: a) Quality of Service selection: The Transport Layer is required to optimize the use of available communications resources to provide the Quality of Service required by communicating TS users at the minimum cost. Quality of Service requirements are specified through the selection of values for Quality of Service parameters. b) Independence of underlying communications resources: The Transport Service hides from TS users the difference in the Quality of Service provided by the Network Service. This difference in Quality of Service arises from the use of a variety of communica- tions 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 nei- ther 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 map -ped 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 Dae Young Kim Expires 4/30/97 [page 8]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 through the selection of values for AGI parameters. 7. Features of the Enhanced Communication Transport Service ECTS provides the following features to the TS user: a) The means for a TC-owner to create a TC with other TS users of the same enrolled group for the purpose of exchanging TSDUs. Only one TC may exist among the TS users of a given enrolled group. Some QoS agreements may have been determined during enrollment. Refinement of some of these QoS agreements may occur during the create opera- tion 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 impo- sed by QoS. The transfer of TSDUs is transparent, in that the bou- ndaries 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 for a TS user to leave a TC unconditionally and/or under the constraints of AGI and QoS. e) The means for a TC-owner unconditionally and therefore destructive ly to terminate a TC. 8. Model of the Enhanced Communications Transport Service 8.1. Types of Transport Connection Figure 2 gives the three types of TC considered in ECTS. They are: a) simplex TC, wherein one TC-participant, called TC-owner, is send only and all others are receive only; b) duplex TC, wherein one TC-participant, called TC-owner, can both send to and receive from all others whereas all other TC-partici- pants 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 some- one 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 duplex 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. Dae Young Kim Expires 4/30/97 [page 9]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 through the selection of values for AGI parameters. 7. Features of the Enhanced Communication Transport Service ECTS provides the following features to the TS user: a) The means for a TC-owner to create a TC with other TS users of the same enrolled group for the purpose of exchanging TSDUs. Only one TC may exist among the TS users of a given enrolled group. Some QoS agreements may have been determined during enrollment. Refinement of some of these QoS agreements may occur during the create opera- tion 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 impo- sed by QoS. The transfer of TSDUs is transparent, in that the bou- ndaries 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 for a TS user to leave a TC unconditionally and/or under the constraints of AGI and QoS. e) The means for a TC-owner unconditionally and therefore destructively to terminate a TC. 8. Model of the Enhanced Communications Transport Service 8.1. Types of Transport Connection Figure 2 gives the three types of TC considered in ECTS. They are: a) simplex TC, wherein one TC-participant, called TC-owner, is send only and all others are receive only; b) duplex TC, wherein one TC-participant, called TC-owner, can both send to and receive from all others whereas all other TC-partici- pants 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 some- one 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 duplex 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. Dae Young Kim Expires 4/30/97 [page 10]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 o o o ^ ^ ^ / / / / / / o--------->o o<<--------->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 Note: In the definition of Duplex TC, (N-1) unicast communications back to the TC-owner are supported. An important issue is whe- ther unicast communications should also be supported by, or as a variant of, the N-plex TC. NBLOs are requested to express their position on whether unicast communications of these kinds should be supported. 8.2. Model of Transport Connection An enrolled group member may be involved in only one TC. Figure 3 gives an example of a TC for an enrolled group. In this example, the enrolled group consists of six TS-users A to F. The group is identified by a group TSAP address pointing to the TSAPs of the group members A to F. In the example, TS users A, B, C, and E are involved in a simplex TC, wherein A is the owner; they are said to form the active group for TC. TS users D and F are not involved in any TC. The TC is identified by the group TSAP address which is unique within the scope of OSIE. Each terminal of a TC is called the Transport Co- nnection endpoint and is identified by the TSAP address of the TS user participating in the active group. In a TC, no specific ordering of transmitted TSDU is pre-assumed. The ordering requirement for a TC is determined by QoS agreements associa- ted with the TC which are made during the enrollment phase only. Dae Young Kim Expires 4/30/97 [page 11]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 User User C +-------+ +-------+ | o | | o | +----^--+ +--^----+ \ / \ / User A \ / User D +---+ \ / +---+ | | \ / | | | o-+----------------< | | | | TC \ | | +---+ \ +---+ \ \ +-------+ +--v----+ | | | o | +-------+ +-------+ User F User E Figure 3 - An example of a TC for an enrolled group 9. Characteristics of Transport Connection 9.1. Transport Connection Type The term Transport Connection Type(TC-type) refers to the types of transport connection. The types will be one of the followings: a) Simplex TC; b) Duplex TC; c) N-plex TC. 9.2. Quality of Enhanced Communications Transport Service The term Quality of Service (QoS) refers to certain characteristics of a TC that are managed by the TS-users and the TS-provider. They are - throughput, transit delay and transit delay jitter, which are classed as TC performance characteristics - corrupted TSDU error rate and lost TSDU error rate, which are classed as TC reliability characteristics - TC ordering - TC protection - TC precedence. Definitions of these characteristics are given in 10.1. Values for some or all of these characteristics may be agreed before the TC is operated. The nature of QoS agreements and the means by Dae Young Kim Expires 4/30/97 [page 12]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 which they can be reached are specified in 10.2. The phases of esta- blishment 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. 9.3. Active Group Integrity The Active Group Integrity specifies conditions on the active group membership of a TC. The followings are the AGI conditions identified and defined in this standard. Inclusion of other AGI conditions is for further study. 9.3.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.3.2. AGI population a) Mandatory: condition that specifies the selected enrolled group me- mbers 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 the maximum number of members that can be allowed in the active group; f) Atomic: condition wherein all of enrolled group members are required to be present in the active group. 10. Quality-of-Service (QoS) for Transport Connections 10.1. QoS classification The QoS classes and the possible values that may be imposed or agreed upon are shown in Table 1. Dae Young Kim Expires 4/30/97 [page 13]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Table 1 - Classification of the QoS characteristics +-----------------+----------------+------------------------------------+ | Charateristics | Characteristic | QoS values agreed or imposed | | Group | | | +-----------------+----------------+------------------------------------+ | TC performance | Throughput | - CHQ throughput value | | | | - operating target throughput value| | | | - threshold throughput value | | | | - LQA throughput value | | +----------------+------------------------------------+ | | Transit delay | - operating target transit delay | | | | value | | | | - LQA transit delay value | | +----------------+------------------------------------+ | | Transit delay | - operating target transit delay | | | jitter | jitter value | | | | - LQA transit delay jitter value | +-----------------+----------------+------------------------------------+ | TC reliability | Corrupted TSDU | - LQA corrupted TSDU error rate | | | error rate | value | | +----------------+------------------------------------+ | | Lost TSDU error| - LQA lost TSDU error rate value | | | rate | | +-----------------+----------------+------------------------------------+ | TC ordering | TC ordering | - No ordering | | | | - Local ordering | | | | - Causal ordering | | | | - Partial ordering | | | | - Total ordering | +-----------------+----------------+------------------------------------+ | Miscellaneous | TC protection | Local matter according to 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. Dae Young Kim Expires 4/30/97 [page 14]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 X.qsf | 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. In order to deal with cases in which data loss can be tolerated in a TC, both the transmit data rate and the receive data rate must be re- cognized in the definition of the QoS negotiation procedures. There- fore, for ECTS, throughput is defined as the receive rate (since that relates to successful transfers) and a separate definition of transmit rate is provided. Note: The current definitions of the QoS negotiation procedures do not cover the case of throughput negotiation in channels that tolerate user data loss. NBLOs are asked to comment on whether they see a requirement for ECTS to cover this case, and on QoS negotiation mechanisms that could be employed. Throughput, or equivalently receive rate, is defined between a pair of TS-users, and for each direction of transmission, in terms of a seque- nce of at least two successfully transferred TSDUs. Given such a seque- nce of n TSDUs, where n is greater than or equal to 2, the throughput 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 indications in the sequence. Successful transfer of the octets in a transmitted TSDU is defined to occur when the octets are delivered to the intended receiving TS-user without error, in the proper sequence, prior to release of the TC by the receiving TS-user. The requirement for throughput in one direction of transmission may be different from the requirement for throughput in the reverse direction. 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 Dae Young Kim Expires 4/30/97 [page 15]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 a sequence of n TSDUs, where n is greater than or equal to 2, the tra- nsmit 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 TCEP within a TSAP and the occu- rrences of the corresponding T-DATA indication primitives at the re- ceiving TCEP. 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 reliabi- lity policies as follows: a) lossless and error-free; b) lossless and corrupted; c) lossy and error-free; d) lossy and corrupted. Table 2 shows the four TC reliability policies and the associated meaningful error rates. Dae Young Kim Expires 4/30/97 [page 16]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 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 | | | indicated | ( Corrupted TSDU | error rate ) | | | | error rate ) | ( Lost TSDU error | | | | | rate ) | +------------+-------------+------------------+---------------------+ The TC reliability policies are negotiated among the TS users only. If neither losses nor corruption of contents are accepted on a TC, the TS provider has to preserve unchanged the boundaries and the contents of all submitted TSDUs. That is, any TSDU delivered to the receiving TS user via a T-DATA indication primitive shall have the same number of octets and the same value for each octet as the TSDU received from the sending TS user in the corresponding T-DATA request primitive. If corruption of contents are accepted, then any TSDU delivered to the receiving TS users via a T-DATA indication primitive shall still have the same number of octets as the TSDU submitted by the sending TS user in the corresponding T-DATA request primitive, but the values of some octets may have been altered by the TS provider. If required, 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 TSDU submitted by the sending TS user, a zero-length TSDU is delivered to the receiving TS user. The TC reliability policies are implemented by managing the QoS chara- cteristics: corrupted TSDU error rate and lost TSDU error rate. Dae Young Kim Expires 4/30/97 [page 17]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 10.1.2.1. Corrupted TSDU error rate The corrupted TSDU error rate is defined as the ratio of total number of TSDUs delivered to the receiving TS user with their contents corru- pted, to the total number of TSDUs submitted by the sending TS user to the TS provider during a defined period. The corrupted TSDU error rate is negotiated among the TS users only. 10.1.2.3. Lost TSDU error rate The lost TSDU error rate is defined as the ratio of the total number of TSDUs delivered to the receiving TS user with (parts of) their contents lost, 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 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 orde- ring 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. 10.1.3.2. Local ordering The TSDUs, generated by a particular sending TS user, are delivered to all of the receiving TS users in the same order in which they were generated. Local ordering does not establish any ordering relationship among TSDUs generated by different sending TS users. Dae Young Kim Expires 4/30/97 [page 18]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 10.1.3.3. Partial ordering The TSDUs, generated by all sending TS users are delivered to each re- ceiving TS user according to an arbitrary ordering rule. If the TSDUs are ordered according to a rule applicable to all recei- ving TS users, then each receiving TS user receives the TSDUs genera- ted 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 as established that A happens before B and that B happens before C, then it can be established A happens before C. A causal dependence relationship cannot be established between the two sending events A and C if there is no possibility to establish that A happens before B and that B happens before C. 10.1.3.5. Total ordering The TSDUs, generated by all sending TS users, are delivered to each receiving TS user in the same order. Every receiving TS user sees all TSDUs from all sending TS users in exactly the same order. 10.1.4. Miscellaneous 10.1.4.1. TC protection Protection QoS is the degree to which the TS provider attempts to counter security threats to the Transport Service using Security Services applied to the Transport, Network, Data Link or Physical Layers. The handling of Protection QoS parameters is a local matter controlled according to the security policy in force. Note: For further information on the provision of security in the lower layers and the handling of Protection QoS see ITU-T Rec. X.802 | ISO/IEC TR 13594. Dae Young Kim Expires 4/30/97 [page 19]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 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. Reaching QoS agreements Agreements are reached on how particular QoS characteristics of a TC shall be managed through negotiation between parties, imposition by one party or means beyond the scope of this standard. Different chara- cteristics are in general treated differently. Such agreement may include, for each characteristic (and direction of transmission, where applicable), one or more QoS values, which may be (a) an operating target (b) a lowest quality acceptable (LQA) limit to the value attained (c) a controlled highest quality (CHQ) limit to the value attained (for throughput only); and the level of agreement reached on that value, which will be one of best efforts, compulsory and guaranteed. A threshold may also be established, for the purpose of exception reporting (via T-REPORT indication primitives). This is to enable a TS-user to adapt its behavior to reduced QoS if possible (for example by transmitting with a different frame-rate, or in black-and-white instead of color). If an operating target and a threshold are agreed, the threshold value must correspond to lower QoS than the operating target. If an LQA limit and a threshold are agreed, the threshold value must correspond to higher QoS than the LQA limit. Note that when a threshold is negotiated, the agreement is made between one TS-user and the provider: it is not necessary for other TS-users to agree to the value, though they may need to know what it is in order to take appropriate action upon receiving a T-REPORT indication. 10.2.1. Levels of agreement Dae Young Kim Expires 4/30/97 [page 20]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 10.2.1.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 life- time of the TC. 10.2.1.2. Compulsory level Compulsory levels of agreement apply to QoS limits. For each QoS limit value negotiated at the compulsory level of agreement, the TS provider monitors the achieved QoS. If it determines that it cannot maintain the QoS within the agreed limit, it will either (a) pause the service (by issuing a T-PAUSE indication primitive), if the condition is judged to be transient, or (b) remove a TS-user (by issuing a T-LEAVE indication primitive), or (c) terminate the TC (by issuing a T-TERMINATE indication primitive). However, in reaching the compulsory level of agreement, the parties do not guarantee that the agreed QoS can be provided, and indeed may deliberately degrade QoS (and consequently pause or abort the service) in order to satisfy a request for service that has higher precedence. 10.2.1.3. Guaranteed level Guaranteed levels of agreement apply to QoS limits. The TS provider monitors the achieved QoS. If it determines that it cannot maintain the QoS within the agreed limit, it will either (a) pause the service (by issuing a T-PAUSE indication primitive), if the condition is judged to be transient, or (b) remove a TS-user (by issuing a T-LEAVE indication primitive), or (c) terminate the TC (by issuing a T-TERMINATE indication primitive). However, in reaching the guaranteed level of agreement, the parties undertake to provide the agreed QoS, for example by dedicating resou- rces to the TC, barring the occurrence of rare events such as equi- pment failure. 10.2.1.4. Agreements on thresholds When a threshold has been agreed for a particular QoS characteristic, the TS provider monitors the achieved QoS. Whenever the achieved QoS crosses the threshold in the direction of worsening QoS, the TS provider reports this to the TS users as soon as possible by issuing a T-REPORT indication primitive, while keeping the TC open. 10.2.2. Negotiation mechanisms For the negotiation of the ECTS QoS characteristics, two procedures are under consideration, namely the owner-arbitration (OA) and step- wise arbitration (SWA) procedures. The QoS negotiation capabilities and mechanisms supported by these procedures are different. Dae Young Kim Expires 4/30/97 [page 21]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 In the OA procedure, all QoS negotiation is performed solely by the TC-owner's protocol entity. During the negotiation, all the TS-users state their QoS requirements and capabilities for the data they will transmit and the aggregate of the data they will receive. The TC-owner initiates this procedure, stating its requirements and capabilities, and the other TS-users state their requirements and capabilities in response. All these values are then taken into account by the TC-owner's protocol entity, which performs an arbitration and broadcasts the final values to all TS-users. As seen from each TC-participant's point of view, the OA procedure may result in the common QoS transmit value or in distinct QoS transmit values. The SWA procedure is more complex, in order to provide negotiation of the QoS of the data transmitted by each TS-user separately. Each multicasting TS-user initiates a separate "1xN" QoS negotiation related to the data which that TS-user will transmit, in which - the initiating user makes QoS proposals - the provider may modify them in the course of transmission to the other TS-users - all the other TS-users respond - for QoS levels that need to be agreed connection-wide, the provider arbitrates and issues final values. The TC-owner is the first to initiate its 1xN procedure, and on receipt of the proposals from the TC-owner, the other multicasting TS-users initiate their 1xN procedures. Finally, the TC-owner's proto- col entity performs AGI arbitration, and may exclude some TS-users if there are incompatible QoS requirements. Note 1: Annex B contains (incomplete) descriptions on the OA and SWA negotiation procedures. Note 2: Whether ECTS and ECTP should support the OA procedure, the SWA procedure, or both, is a major outstanding issue on which comments are solicited from NBLOs. The two procedures may or may not differ in their support for QoS negotiation (as explained in the Annex B), and in the types of TC they can be used to establish (See Note in Clause 8.1). In considering this issue, which has protocol as well as service implica- tions, NBLOs are referred to the discussions in SC6 10129 attachment TD 5465 and to the report of the SC6/WG4 meeting in Guernsdy, Sept. 1996. 10.3. Phases of QoS Agreement There are several partly overlapping phases related to the operation of a Transport Connection. Some of them apply to the TC as a whole, Dae Young Kim Expires 4/30/97 [page 22]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 others (namely join and leave) apply to individual TS-users. The phases are - the enrollment phase, during which the enrollment group is establi- shed and conditions for TCs are prepared - the creation phase, during which the TC is explicitly created - the data transmission phase, during which data are exchanged - the join phase, during which new TS-users join the TC - the leave phase, during which some TS-users leave the TC - the termination phase, at which the TC is terminated. Rules may exist as to which parties may create and/or terminate such connections and therefore distinguish them from those parties which may only join and leave Transport Connections created by others. These rules thus determine the phases at which various QoS agreements may be reached. For some characteristics, such as ordering, only those parties capable of providing the necessary function can be enrolled into any given group. The ordering characteristic is therefore determined by the end of the enrollment phase. For other characteristics, the phase at which they may be agreed depends on whether negotiation is to take place and on the type of negotiation, e.g. connection-wide or receiver-selected, that is requi- red. If connection-wide negotiation is required for a value (operating target, LQA or threshold) associated with a given QoS characteristic, then that negotiation must take place during the enrollment phase or the creation phase, and the agreed value will then be imposed upon any TS-user that attempts to join the TC later. On the other hand, if the value is to be imposed or negotiated on a receiver-selected basis, then the agreement may be reached during the enrollment phase, the creation phase or the join phase. Agreements reached during the enrollment phase may be on a specific value, or on a range of acceptable values. In the latter case, the agreement may be refined by selection of a specific value within the range during the creation phase or the join phase. Note: The means by which agreements may be reached during the enro- llment 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 abse- Dae Young Kim Expires 4/30/97 [page 23]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 nce of any specification in a T-primitive. This service definition does not specify any particular default values, nor the means by which they may be established. Other specifications may specify particular defaults to be used in particular environments. Table 3 lists QoS characteristics and indicates in which phases of a TC their values may be negotiated. Table 3 - Classification of the QoS characteristics by phase usage +----------------------------+------------+------------+------------+ | Characteristic | Enroll Use | Create Use | Join Use | +----------------------------+------------+------------+------------+ | Throughput | R, V | V | SV | +----------------------------+------------+------------+------------+ | Transit delay | R, V | V | SV | +----------------------------+------------+------------+------------+ | Transit delay jitter | R, V | V | SV | +----------------------------+------------+------------+------------+ | Corrupted TSDU error rate | R, V | V | SV | +----------------------------+------------+------------+------------+ | Lost TSDU error rate | R, V | V | SV | +----------------------------+------------+------------+------------+ | TC Ordering | V | N | N | +----------------------------+------------+------------+------------+ | TC Protection | SP | SP | SP | +----------------------------+------------+------------+------------+ | TC Precedence | I | I | I | +----------------------------+------------+------------+------------+ Legend: R A range of values may be agreed V A specific value may be negotiated SV A specific value may be receiver selected only, or imposed SP Determined by the security policy in force I imposed N Not subject to further agreement, already known. 11. Enhanced Communications Transport Service Primitives and Parameters 11.1. Definitions This clause defines the service primitives and the associated parame- ters which are used in ECTS. Detailed descriptions of these primitives are given in Clauses 12 to 16. Dae Young Kim Expires 4/30/97 [page 24]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Table 4 - Enhanced Communications Transport Service primitives +----------+----------+---------------+----------------------------+ | Phase | Service | Primitive | Parameters | +----------+----------+---------------+----------------------------+ | TC | TC | T-CREATE | ( Called address, | | creation | creation | request | Calling address, | | | | | TC-characteristics, | | | | | TS user data ) | | | +---------------+----------------------------+ | | | T-CREATE | ( Called address, | | | | indication | Calling address, | | | | | TC-characteristics, | | | | | TS user data ) | | | +---------------+----------------------------+ | | | T-CREATE | ( Called address, | | | | response | Responding address, | | | | | TC-charateristics, | | | | | TS user data ) | | | +---------------+----------------------------+ | | | T-CREATE | ( Called address, | | | | confirm | Responding address, | | | | | TC-charateristics, | | | | | TS user data ) | +----------+----------+---------------+----------------------------+ | Data | Data | T-DATA request| ( TS user data ) | | transfer | transfer | | | | | +---------------+----------------------------+ | | | T-DATA | ( Status, TS user data ) | | | | indication | | | +----------+---------------+----------------------------+ | | Pause | T-PAUSE | ( Reason ) | | | | indication | | | +----------+---------------+----------------------------+ | | Resume | T-RESUME | 0 | | | | indication | | | +----------+---------------+----------------------------+ | | Report | T-REPORT | ( Calling address, Reason, | | | | indication | TS user data ) | +----------+----------+---------------+----------------------------+ | TC join | TC join | T-JOIN request| ( Called address, | | | | | Calling address, | | | | | TC-characteristics, | | | | | TS user data ) | | | +---------------+----------------------------+ | | | T-JOIN confirm| ( Called address, | | | | | TC-characteristics ) | +----------+----------+---------------+----------------------------+ Dae Young Kim Expires 4/30/97 [page 25]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 +----------+----------+---------------+----------------------------+ | TC leave | TC leave | T-LEAVE | ( Called address, | | | | request | Calling address, | | | | | Reason, TS user data ) | | | +---------------+----------------------------+ | | | T-LEAVE | ( Called address, Reason ) | | | | indication | | +----------+----------+---------------+----------------------------+ | TC | TC | T-TERMINATE | ( Reason, TS user data ) | | termina- | termina- | request | | | tion | tion +---------------+----------------------------+ | | | T-TERMINATE | ( Reason, TS user data ) | | | | indication | | +----------+----------+---------------+----------------------------+ 11.2. Sequence of primitives at one TC endpoint This clause defines the constraints on the sequences in which the primitives defined in Clauses 12-16 may occur. The constraints determine the order in which primitives may occur, but do not fully specify when they may occur. Other constraints, such as flow control of data, will affect the ability of a TS user or a TS provider to issue a primitive at any particular time. A primitive issued at one TCEP will, in general, have consequences at the other TCEPs. The relations of primitives of each type to primi- tives at the other TC endpoints are defined in the appropriate Clauses 12-16. The possible overall sequences of primitives at a TC endpoint are defined in the state transition diagram Figure 4 . In the diagram: a) a primitive which is not shown as resulting in a transition (from one state to the same state, or from one state to a different state) is not permitted in that state; b) the Idle state reflects the absence of a relationship between the TS-user and the TC. It is the initial and final state of any seque- nce, and upon returning to this state, the TS-user may not partici- pate 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. Table 5 presents the allowed sequence of primitives by showing which TS primitives may follow other primitives. Dae Young Kim Expires 4/30/97 [page 26]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 +--------+<-----------------------------+ T-TERMINATE -------------->| Idle |<--------------- T-TERMINATE | request +--------------| |--------------+ indication | T-TERMINATE | +--------+ <---------+ | T-LEAVE | indication | | ^ | | request | T-LEAVE T-CREATE T-CREATE | | T-TERMINATE | | T-LEAVE | request request indication | indication | | indication | T-LEAVE | | | T-LEAVE | | | | indication | | | request | T-JOIN | | | | | | T-LEAVE | request | | | | | | request | | | | | v v | | v | | +----------+ T-CREATE +------------+ | +---------+ | | Outgoing | reponse | Incoming | | | Join | | | create |<-----------| create | | | pending | | | pending | | pending | | +---------+ | +----------+ +------------+ | | | | | | | | +-----------+ | +-----+ T-CREATE.confirm | | | | T-TERMINATE.request(Note) | | | T-TERMINATE.indication | | | T-LEAVE.request | | | T-LEAVE.indication | | | | | | | | T-JOIN.confirm | +----------------->+----------------+ | | +-------------| Data Tranfer |<-----------+ | | +----------------+ | | ^ | ^ T-TERMINATE.request(Note) T-DATA.request | | | T-TERMINATE.indication T-DATA.indication | T-PAUSE | T-LEAVE.request T-REPORT.indication ---+ indication | T-LEAVE.indication | | | | T-RESUME | | indication | | | | v | | +---------------+ | | Data Transfer |---------------+ | Suspended | +---------------+ Note - This transition is allowed only to the TC-owner. Figure 4 - State Transition Diagram for possible allowed sequence of TS primitives at a TC endpoint Dae Young Kim Expires 4/30/97 [page 27]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Table 5 - Sequence of Primitives at one TC endpoint T-TERMINATE.indication ----------------------------------------+ T-TERMINATE.request -----------------------------------------+ | T-LEAVE.indication ----------------------------------------+ | | T-LEAVE.request -----------------------------------------+ | | | T-JOIN.confirm ----------------------------------------+ | | | | T-JOIN.request --------------------------------------+ | | | | | T-REPORT.indication -------------------------------+ | | | | | | T-RESUME.indication -----------------------------+ | | | | | | | T-PAUSE.indication ----------------------------+ | | | | | | | | T-DATA.indication ---------------------------+ | | | | | | | | | T-DATA.request ----------------------------+ | | | | | | | | | | T-CREATE.confirm ------------------------+ | | | | | | | | | | | T-CREATE.response ---------------------+ | | | | | | | | | | | | T-CREATE.indication -----------------+ | | | | | | | | | | | | | T-CREATE.request -----------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The TS primitive X | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | may be followed | | | | | | | | | | | | | | | | | by the TS primitive Y | | | | | | | | | | | | | | | | +---------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T-CREATE.request | | | | | | | | | | | | | | | | +---------------------------------+-----------------------------+ | T-CREATE.indication | | | | | | | | | | | | | | | | +---------------------------------+-----------------------------+ | T-CREATE.reponse | |+| | | | | | | | | | | | | | +---------------------------------+-----------------------------+ | T-CREATE.confirm |+| |+| | | | | | | | | | | | | +---------------------------------+-----------------------------+ | T-DATA.request | | | |+|+|+| |+|+| |+| | | | | +---------------------------------+-----------------------------+ | T-DATA.indication | | | |+|+|+| |+|+| |+| | | | | +---------------------------------+-----------------------------+ | T-PAUSE.indication | | | |+|+|+| |+|+| |+| | | | | +---------------------------------+-----------------------------+ | T-RESUME.indication | | | | | | |+| | | | | | | | | +---------------------------------+-----------------------------+ | T-REPORT.indication | | | |+|+|+| |+|+| |+| | | | | +---------------------------------+-----------------------------+ | T-JOIN.request | | | | | | | | | | | | | | | | +---------------------------------+-----------------------------+ | T-JOIN.confirm | | | | | | | | | |+| | | | | | +---------------------------------+-----------------------------+ Dae Young Kim Expires 4/30/97 [page 28]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 T-TERMINATE.indication ----------------------------------------+ T-TERMINATE.request -----------------------------------------+ | T-LEAVE.indication ----------------------------------------+ | | T-LEAVE.request -----------------------------------------+ | | | T-JOIN.confirm ----------------------------------------+ | | | | T-JOIN.request --------------------------------------+ | | | | | T-REPORT.indication -------------------------------+ | | | | | | T-RESUME.indication -----------------------------+ | | | | | | | T-PAUSE.indication ----------------------------+ | | | | | | | | T-DATA.indication ---------------------------+ | | | | | | | | | T-DATA.request ----------------------------+ | | | | | | | | | | T-CREATE.confirm ------------------------+ | | | | | | | | | | | T-CREATE.response ---------------------+ | | | | | | | | | | | | T-CREATE.indication -----------------+ | | | | | | | | | | | | | T-CREATE.request -----------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---------------------------------+-----------------------------+ | T-LEAVE.request |+|+|+|+|+|+|+|+|+|+|+| | | | | +---------------------------------+-----------------------------+ | T-LEAVE.indication |+|+|+|+|+|+|+|+|+|+|+| | | | | +---------------------------------+-----------------------------+ | T-TERMINATE.request |+| |+|+|+|+|+|+|+| |+| | | | | +---------------------------------+-----------------------------+ | T-TERMINATE.indication |+|+|+|+|+|+|+|+|+|+|+| | | | | +---------------------------------+-----------------------------+ Note - This transition is allowed only to the TC-owner. 12. Transport Connection Creation Phase 12.1. Function The TC creation TS primitives can be used by the TC-owner to create a TC, provided the enrolled TS users exist and are known to the TS provider. TC-characteristics such as TC-type, QoS, and AGI are assumed to have been defined beforehand and known both to the TS users and the TS provider at the Idle state. The TC creation service will further refine the QoS, if necessary, and check the identities of the TC-participants to validate the AGI condi- tion. It is assumed that, at the Idle state, there exists one and only one TC-owner who possesses the right to create and terminate the TC of a given TC. Dae Young Kim Expires 4/30/97 [page 29]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 12.2 Types of primitives and parameters The following Table 6 indicates the types of TS primitives and parameters associated with the TC creation Table 6 - TC creation primitives and parameters +-----------------+-----------+------------+-----------+-----------+ | | T-CREATE | T-CREATE | T-CREATE | T-CREATE | | | request | indication | response | confirm | +-----------------+-----------+------------+-----------+-----------+ | Called address | X | X(=) | X(Note 1) | X(=) | |-----------------+-----------+------------+-----------+-----------+ | Calling address | X(Note 2) | X(=) | | | |-----------------+-----------+------------+-----------+-----------+ | Responding | | | | | | address | | | X(Note 2) | X(=) | |-----------------+-----------+------------+-----------+-----------+ | TC | | | | | | Characteristics | X | X(=) | X(=) | X(=) | |-----------------+-----------+------------+-----------+-----------+ | TC user data | X(U) | X(=) | X(U) | X(=) | +-----------------+-----------+------------+-----------+-----------+ Note 1 - This is the unicast calling address of the TC-owner. Note 2 - This parameter may be implicitly associated with the TSAP at which the primitive is issued. 12.2.1 Addresses An address parameter refers to either a unicast TSAP address or a group TSAP address. The address parameter will accommodate a variable length TSAP address The value of an address supplied by the TS user is not necessarily checked or authenticated by the TS provider. 12.2.2 Called Address The called address parameter conveys a TSAP address that identifies the TS user(s) expected to participate in the TC being created . 12.2.3 Calling Address The calling address parameter conveys the address of the TSAP of the TC-owner by whom the TC has been requested. Dae Young Kim Expires 4/30/97 [page 30]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 12.2.4 Responding Address The responding address parameter conveys the address of the TSAP of the TS user to participate in the TC and to which TS user data should be delivered when the TC is in the Data Transfer state. 12.2.5 TC-characteristics The TC-characteristics parameter convey the constraints under which a group connection exists, such as TC-types, QoS, and AGI. According to the TS requirements from the TS user, the TC-characteristics parameters may have null values. 12.2.5.1 TC-type The TC-type parameter conveys the connection type of the TC to be created. 12.2.5.2 QoS A list of QoS parameters is provided as specified in 10.1. For each parameter, the values permitted in the TS request,indication, response, and confirm primitives are determined by the selected QoS negotiation mechanism. Note: See Annex B for the possible descriptions of the detailed QoS negotiation mechanism. 12.2.5.3 AGI The AGI is a list of parameters (see Clause 9.3). For each parameter, the values are not negotiated for the TC to be created. 12.2.6 TS user data This parameter allows the transfer of TS user data between TS users without modification by the TS provider. The TS user data parameter shall be an integral number of octets in length between 1 and 32 inclusive. Note 1 - The called TS user may use the information conveyed to determine whether or not the TC should be accepted. Note 2 - The QoS associated with TS user data on the T-CREATE primitive may be lower than that for TS user data in the T-DATA primitive once the TC is established. Dae Young Kim Expires 4/30/97 [page 31]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 12.3 Sequence of TS primitives The sequence of TS primitives in a successful TC creation is defined by the following time sequence diagram(Figure 5). \ | | | | T-CREATE \ | | | | request \ | | | | v | | | | |\ | | | | \ |T-CREATE | T-CREATE | | \ |indication | indication | T-CREATE | \|_ _ _ _ _ _|_ _ _ _ _ _ _| indication | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | | | | | | | T-CREATE | T-CREATE | T-CREATE | | response | response | response | | / | / | / | | / | / | / | |v_ _ _ _ __|v_ _ _ _ _ _ |v | / | | | | @ | | | | / \ | | | |/ \|_ _ _ _ _ _|_ _ _ _ _ _ _| T-CREATE /| |\ |\ |\ confirm / | | \ | \ | \ / | | v | v | v v | | T-CREATE | T-CREATE |T-CREATE | | confirm | confirm |confirm | | | | Figure 5 - Sequence of primitives in a successful TC creation The TC creation procedure may fail either due to the inability of the TS provider to create a TC, due to the unsuccessful negotiation of the QoS, or due to the failure of the AGI condition. These cases are described in Clause 15. 13 Data Transfer Phase 13.1 Data Transfer Service 13.1.1 Function The Data Transfer service provides for an exchange of TSDU, in either direction or in both directions simultaneously on a TC. Dae Young Kim Expires 4/30/97 [page 32]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 The reliability of the transfer is determined by the selected value of the reliability QoS parameters. The notification of detected but not corrected errors is signaled through the status parameter to the TS user. 13.1.2 Types of Primitives and Parameters Table 7 - Data transfer primitives and parameters +-----------------+-------------------+---------------------+ | | T-DATA | T-DATA | | | request | indication | +-----------------+-------------------+---------------------+ | Status | | X | |-----------------+-------------------+---------------------+ | TS user data | X | X(=) | +-----------------+-------------------+---------------------+ 13.1.2.1 Status The status parameter conveys a notification to the TS user that: a) either errors have been detected and not corrected; b) or errors have been detected and that TS user data length is zero. 13.1.2.2 TS user data The TS user data parameter consists of an integral number of octets greater than zero and allows the transfer of data from a sending TS user to the TS user(s) participating in the TC, without modification by the TS provider. 13.1.3 Sequence of TS primitives The sequence of primitives in a successful data transfer is defined in the following time sequence diagram(Figure 6). Dae Young Kim Expires 4/30/97 [page 33]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 \ | | | | \ | | | | v | | | | T-DATA |\ | | | request | \ | T-DATA | T-DATA | T-DATA | \ | indication| indication| indication | \|_ _ _ _ _ _|_ _ _ _ _ _| | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | | | | | Figure 6 - Sequence of primitives in data transfer 13.2 Pause service 13.2.1 Function The Pause service provides for the TS provider to indicate with the T-PAUSE indication primitive to the active group TS user(s) that the TC has entered to the state where the data transfer is not allowed. The reason parameter within the T-PAUSE indication primitive showed deliver the reason, e.g., violation of the compulsory QoS or the AGI. Until the TS users are notified that TC-characteristics are met again, no T-DATA.request primitives may be issued. See the RESUME service in Clause 13.3. Data that was submitted for transfer before the PAUSE primitive is received may be delivered to active member(s) of the TC. 13.2.2 Types of primitive and parameters Table 8 - Pause TS primitives and parameters +-------------------------+------------------------+ | | T-PAUSE | | | indication | +-------------------------+------------------------+ | Reason | X | +-------------------------+------------------------+ 13.2.2.1 Reason The reason parameter gives information indicating the cause of the data Dae Young Kim Expires 4/30/97 [page 34]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 transfer suspension. The reason is one of the followings: a) temporary lack of local or remote resources of the TS provider; b) a QoS parameter temporarily below an agreed LQA level; c) AGI temporarily below the minimum level. 13.2.3 Sequence of TS primitives suspending Data Transfer | | | | | | | | | | | | T-PAUSE | | | | indication | | T-PAUSE | T-PAUSE | T-PAUSE | | indication | indication | indication /| UO |_ _ _ _ _ _ _ |_ _ _ _ _ _ _| / | |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | | | | | Figure 7 - Sequence of primitives in TS provider invoked suspension of the Data Transfer 13.3 Resume service 13.3.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 begin issuing T-DATA.request primitives, or receiving T-DATA indic -ation primitives. 13.3.2 Types of TS primitive and parameters There is no parameter for the T-RESUME primitive. 13.3.3 Sequence of TS primitives The sequence of primitives in the resumption of a previously suspended data transfer is defined in the following time sequence diagram (Figure 8). Dae Young Kim Expires 4/30/97 [page 35]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 | | | | | | | | | | | | T-RESUME | | | | indication | | T-RESUME | T-RESUME | T-RESUME | | indication | indication | indication /| UO |_ _ _ _ _ _ _ |_ _ _ _ _ _ _| / | |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | | | | | Figure 8 - Sequence of primitives in TS provider resuming Data Transfer 13.4 Report service 13.4.1 Function The report TS primitives are used to notify the change of TC-characteristics to the active TS users in the data transfer phase. If some TC-characteristics is changed but not below the minimum level, the TS provider gives the warning to the TS user(s) by issuing a T-REPORT indication. Note - If TC-characteristics is below minimum level and not recoverable in the data transfer phase, the TS provider issues a T-TERMINATE indication or a T-LEAVE indication to the TS user. 13.4.2 Types of primitive and parameters Table 9 indicates the types of primitives and the parameters for the report service. Table 9 - Report TS primitives and parameters +-------------------------+------------------------+ | | T-REPORT | | | indication | +-------------------------+------------------------+ | Calling address | X | +-------------------------+------------------------+ | Reason | X | |-------------------------+------------------------+ | TS user data | X | +-------------------------+------------------------+ Dae Young Kim Expires 4/30/97 [page 36]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 13.4.2.1 Addresses An address parameter refers to a TSAP address or a group TSAP address. The address parameter will accommodate a variable length TSAP address The value of an address supplied by the TS user is not necessarily checked or authenticated by the TS provider. 13.4.2.2 Calling Address The calling address parameter conveys the TSAP address of the TS user from which the TS user data originated. If the report has been initiated by a pure TS provider action, this parameter carries a null value. 13.4.2.3 Reason The reason parameter gives information indicating the cause of the report. The reason is one of the following: a) minor lack of local or remote resources of the TS provider; b) detected but not fatal QoS change, e.g., degradation of QoS below a 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 indication(see 15.2.4). 13.4.2.4 TS user data The TS user data parameter is only present in the T-REPORT indication primitive: a) when the associated remote TS user provided some TS user data; b) when the TS provider provides additional information for the reason. Note - The TS provider may provide additional information (e.g., accounting) for management purposes. 13.4.3 Sequence of TS primitives Dae Young Kim Expires 4/30/97 [page 37]
INTERNET-DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 | | | | | | | | | | | | T-REPORT | | | | indication | | T-REPORT | T-REPORT | T-REPORT | | indication | indication | indication /| UO |_ _ _ _ _ _ _ |_ _ _ _ _ _ _| / | |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | | | | | Figure 9 - Sequence of primitives in Data Transfer when TS provider invoked warning or notification 14 Transport Connection Join Phase 14.1 Function The TC join TS primitives are used to establish the active membership of a TS user into an existing TC. 14.2 Types of Primitives and Parameters The following Table 10 indicates the types of TS primitives and param- eters associated with the TC join service. Table 10 - TC Join primitives and parameters +-----------------+-------------------+---------------------+ | | T-JOIN | T-JOIN | | | request | confirm | +-----------------+-------------------+---------------------+ | Called address | X | X(=) | |-----------------+-------------------+---------------------+ | Calling address | X | | +-----------------+-------------------+---------------------+ | TC- | | | | characteristics | X | X | +-----------------+-----------------------------------------+ 14.2.1 Addresses Dae Young Kim Expires 4/30/97 [page 38]
Draft Enhanced draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 An address parameter refers to a unicast TSAP address or a group TSAP address. The address parameter will accommodate a variable length TSAP address. The value of an address supplied by the TS user is not necessarily checked or authenticated by the TS provider. 14.2.2 Called Address The called address parameter conveys a TSAP address identifying the active group to which the TC join is requested. 14.2.3 Calling Address The calling address parameter conveys the address of the TSAP from which the TC join has been requested. 14.2.4 TC-characteristics The TC-characteristics in the T-JOIN request conveys the constraints under which the TS user expects to join the TC. The TC-characteristics in the T-JOIN confirm provides the constraints under which the current TC exists and falls within the scope of the constraints proposed in the previous T-JOIN request primitive. 14.2.4.1 TC-type The TC-type parameter conveys the connection type of a TC to be joined. If the parameter value in TC-JOIN request primitive is null, the retur -ned value in TC-JOIN indication primitive shall be valid. 14.2.4.2 QoS A list of QoS parameters is provided as specified in 10.1. For each parameter, the values permitted in the TS request, indication, response,and confirm primitives are determined by the selected QoS nego -tiation mechanism. Note: See Annex B for the possible descriptions of the detailed QoS negotiation mechanism. 14.2.4.3 AGI The AGI is a list of parameters (see Clause 9.3). For each parameter, the values are not negotiable for joining. 14.3 Sequence of TS primitives Dae Young Kim Expires 4/30/97 [page 39]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 \ | | | | \ | | | | T-Join \ | | | | request v | | | | |\ | | | | \ | | | | \ | | | | \ | | | | @ | | | | / \ | | | | / \ | | | | / \|_ _ _ _ _ _|_ _ _ _ _ _| | |\ |\ |\ T-JOIN / | | \ | \ | \ confirm/ | | v | v | v / | |T-REPORT | T-REPORT | T-REPORT v | |indication | indication| indication | | | | Figure 10 - Sequence of primitives in a successful TC Join procedure The sequence of TS primitives in a TC join procedure is defined by the following time sequence diagram (Figure 10). The join procedure may fail either due to the inability of the TS Dae Young Kim Expires 4/30/97 [page 40]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Provider to create a TC, due to an inability to provide the requested conditions of the TC-characteristics. These cases are described in Clause 15. 15 Transport Connection Leave Phase 15.1 Function The TC Leave TS 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 creation; d) by a TS provider to reject TC join. TC leave is permitted at any time regardless of the current TC phase. A request for Leave cannot be rejected. 15.2 Types of primitives and parameters The following Table 11 indicates the types of TS primitives and parameters associated with the leave service. Dae Young Kim Expires 4/30/97 [page 41]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Table 11 - TC Leave primitives and parameters ___________________________________________________________________ | | T-LEAVE | T-LEAVE | | | request | indication | |____________________+_________________________+____________________| | Called address | X | X | |____________________+_________________________+____________________| | Calling address | X | | +--------------------+-------------------------+--------------------+ | Reason | X | X | +--------------------+-------------------------+--------------------+ | TS user data | X(U) | | +--------------------+-------------------------+--------------------+ 15.2.1 Addresses An address parameter refers to a TSAP address or a group TSAP address. The address parameter will accommodate a variable length TSAP address The value of an address supplied by the TS user is not necessarily checked or authenticated by the TS provider. 15.2.2 Called Address The called address parameter conveys: a) in the T-LEAVE indication primitive, the TSAP address of the TS user to be excluded from the TC; b) in the T-LEAVE request primitive, a group TSAP address that identifies the active group of the TC. 15.2.3 Calling Address The calling address parameter conveys the TSAP address of the TS user wishing to leave the of TC 15.2.4 Reason The reason parameter gives information on the cause of the leave. The reason is one of the followings: a) TS user invoked to leave the TC; Note - Additional information may be given in the TS-user-data parameter. b) TS provider invoked. This reason may be of transient or permanent nature. Note that The following examples are given: a) a QoS parameter below an agreed LQA level; b) lack of local or remote resources of the TS provider; c) called address unknown; d) AGI condition violated. Dae Young Kim Expires 4/30/97 [page 42]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 15.2.5 TS user data The TS user data parameter is only present in the T-LEAVE request primitive, only when a TS user issues a leave request resulting in the exclusion of itself from the TC, leading to T-REPORT indication to all TS users. The TS user data parameter allows the transfer of TS user data between TS users, without modification by the TS provider. The TS user data may be lost in particular if the TS provider initiates a termination before the T-REPORT indication parameter is delivered. The TS user data parameter, if present, shall be an integral number of octets with length between 1 and 64 inclusive. Note 1 - The TS provider may provide additional information (e.g., accounting) for management purposes. Note 2 - The QoS associated with the TS user data on the T-REPORT indication may be lower than the QoS for TS user data transferred by the T-DATA primitive. TS user data may be lost without any notice to the TS user receiving the T-REPORT indication, even when originated by the remote TS user. 15.3 Sequence of TS primitives in TS user rejection of a TC creation A TS user may reject an invitation to participate in a TC by a T-LEAVE request. The sequence of primitives is defined in the following time sequence diagram (see Figure 11). Dae Young Kim Expires 4/30/97 [page 43]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 \ | | | | T-CREATE \ | | | | request \ | | | | v | | | | |\ | | | | \ |T-CREATE | T-CREATE | | \ |indication | indication | T-CREATE | \|_ _ _ _ _ _|_ _ _ _ _ _ _| indication | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | | | | | | | T-CREATE | T-CREATE | T-CREATE | | indication| response | response | | / | / | / | | / | / | / | |v_ _ _ _ __|v_ _ _ _ _ _ |v | / | | | | @ | | | | / \ | | | |/ \|_ _ _ _ _ _|_ _ _ _ _ _ _| /| | |\ |\ / | | | \ | \ / | | | v | v v | | | T-CREATE |T-CREATE | | | confirm |confirm | | | | Figure 11 - Sequence of Primitives in a Successful TC Creation Procedure with some TS user rejection(s) 15.4 Sequence of TS primitives in a TS provider rejection of a TC join attempt If the TS provider is unable to Create a TC, it indicates this to the TS user by T-LEAVE indication primitive with the reason parameter. Dae Young Kim Expires 4/30/97 [page 44]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 | | | | | | | | / | | | | / | | | | / | | | |v T-JOIN | | | | request | | | | | | | | | | | | | | | | | | | | T-LEAVE | | | |\ indication | | | | \ | | | | \ | | | | \ | | | | v Figure 12 - Sequence of Primitives in TS provider rejection of a TC Join attempt 15.5 Sequence of TS primitives in TS user invoked Leave The sequence may be invoked by one TS user to remove itself, with T-LEAVE request from that TS user leading to T-REPORT indication to other TS users (Figure 13). Note - The T-LEAVE requests invoked by two or more TS users shall be handled independently by the TS provider. \ | | | | \ | | | | v | | | | T-LEAVE |\ | | | request | \ | T-REPORT | T-REPORT | T-REPORT | \ | indication| indication| indication | \|_ _ _ _ _ _|_ _ _ _ _ _| | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | | | | | Figure 13 - Sequence of Primitives in a TS user leaving the active TC Dae Young Kim Expires 4/30/97 [page 45]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 15.6 Sequence of TS primitives in TS provider invoked Leave The sequence may be invoked by the TS provider to exclude a target TS user (Figure 14). | | | | | | | | | | | | T-LEAVE | | | | indication | | T-REPORT | T-REPORT | T-REPORT | | indication| indication| indication | |_ _ _ _ _ _|_ _ _ _ _ _| /| UO |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | | | | | Figure 14 - Sequence of Primitives in the TS provider Invoked a target TS user exclusion from an active TC 16 Transport Connection Termination Phase 16.1 Function The TC termination TS primitives are used to terminate a TC. The termination procedure may be performed: a) by a special TS user, named TC-owner; b) by the TS provider due to the fatal failure of some TC-characte -ristics. TC termination is permitted at any time regardless of the current TC phase. A request for termination cannot be rejected. The Transport Service does not guarantee delivery of any TS user data once the ter -mination phase is entered. 16.2 Types of Primitives and Parameters The following Table 12 indicates the types of TS primitives and parameters associated with the termination service. Dae Young Kim Expires 4/30/97 [page 46]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Table 12 - Termination TS primitives and parameters __________________________________________________________ | | | | | | T-TERMINATE | T-TERMINATE | | | request | indication | |-----------------+---------------------+------------------+ | Reason | X | X | |-----------------+---------------------+------------------+ | TS user data | X(U) | X(=) | |-----------------+---------------------+------------------| 16.2.1 Reason The reason parameter gives information indicating the cause of the termination. The reason is one of the following: a) The TC-owner has invoked the termination; b) lack of local or remote resources of the TS provider, c) QoS below an agreed LQA level, d) called address unknown, e) AGI below minimum level. 16.2.2 TS user data The TS user data parameter is only present in the T-TERMINATE indication primitive: a) when a termination request was originated by a TC owner; b) when the TS provider provides additional information for the reason. 16.3 Sequence of TS primitives when terminating an active transport connection The sequence of TS primitives depends on the origin or origins of the termination action. The sequence may be: a) invoked by a TC-owner, with T-TERMINATE request from that TS user leading to T-TERMINATE indication to all TS users; b) invoked by the TS provider, with a T-TERMINATE indication to each of the TS users; c) invoked independently by the TC-owner and the TS provider, with a T-TERMINATE request from the TC-owner leading to a T-TERMINATE indication to other TS user(s). Dae Young Kim Expires 4/30/97 [page 47]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 \ | | | | \ | | | | v | | | | T-TERMINATE |\ | | | request | \ | T-TERMINATE | T-TERMINATE | T-TERMINATE | \ | indication | indication | indication | \|_ _ _ _ _ _ _ |_ _ _ _ _ _ _| | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | | | | | Figure 15 - Sequence of primitives in a TC-owner invoked TC termination | | | | | | | | | | | | T-TERMINATE | | | | indication | | T-TERMINATE | T-TERMINATE | T-TERMINATE | | indication | indication | indication /| UO |_ _ _ _ _ _ _ |_ _ _ _ _ _ _| / | |\ |\ |\ / | | \ | \ | \ v | | v | v | v | | | | | | | | Figure 16 - Sequence of Primitives in TS provider invoked TC termination \ | | | | \ | | | | v | | | | T-TERMINATE | | | | request | | T-TERMINATE | T-TERMINATE | T-TERMINATE | | indication | indication | indication | UO |_ _ _ _ _ _ _ |_ _ _ _ _ _ _| | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | | | | | Dae Young Kim Expires 4/30/97 [page 48]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Figure 17 - Sequence of Primitives in Simultaneous TC-owner and TS provider invoked TC termination 16.4 Sequence of TS primitives in TS user rejection of a TC creation When one or more TS users reject participating into a TC by a T-LEAVE request, the sequence of TS primitives depends on the TC creation conditions described in the TC-characteristics parameter in the T-CREATE request. The following may be performed: a) if the values of the TC-characteristics parameters in the T-CREATE responses from other TS users satisfy the TC creation, the T-CREATE confirm primitives shall be delivered to the TS users who responded with T-CREATE response primitive; b) if the values of the TC-characteristics parameters in the T-CREATE responses from otherTS users do not satisfy the TC creation, the T-TERMINATE indication primitives shall be delivered to the TS users who responded with T-CREATE response primitive and to the TC-owner; c) if all TS users responded with T-TERMINATE request primitive, the T-TERMINATE indication primitives shall be delivered to the TC- owner with the reason parameter. Dae Young Kim Expires 4/30/97 [page 49]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 \ | | | | T-CREATE \ | | | | request \ | | | | v | | | | |\ | | | | \ |T-CREATE | T-CREATE | | \ |indication | indication | T-CREATE | \|_ _ _ _ _ _|_ _ _ _ _ _ _| indication | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | | | | | | | T-CREATE | T-CREATE | T-CREATE | | request | request | request | | / | / | / | | / | / | / | |v_ _ _ _ __|v_ _ _ _ _ _ |v | / | | | | @ | | | | / \ | | | T-TERMINATE |/ \|_ _ _ _ _ _|_ _ _ _ _ _ _| indication /| | |\ | / | | | \ | / | | | v | v | | | T-TERMINATE | | | | indication | | | | | Figure 18 - Sequence of Primitives in a Unsuccessful TC Creation Procedure with some TS user rejection(s) Dae Young Kim Expires 4/30/97 [page 50]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 \ | | | | T-CREATE \ | | | | request \ | | | | v | | | | |\ | | | | \ |T-CREATE | T-CREATE | | \ |indication | indication | T-CREATE | \|_ _ _ _ _ _|_ _ _ _ _ _ _| indication | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | | | | | | | T-LEAVE | T-LEAVE | T-LEAVE | | request | request | request | | / | / | / | | / | / | / | |v_ _ _ _ __|v_ _ _ _ _ _ |v | / | | | | / | | | T-TERMINATE | / | | | indication /| | | | / | | | | / | | | | v | | | | Figure 19 - Sequence of Primitives in all TS user rejections of TC creation attempt 16.5 Sequence of TS primitives in a TS provider rejection of a TC creation attempt If the TS provider is unable to Create a TC, it indicates this: a) to the TC-owner by T-TERMINATE indication primitive with the reason parameter; b) to the TS users who responded with T-CREATE response and to the TC-owner. Dae Young Kim Expires 4/30/97 [page 51]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 | | | | \ | | | | \ | | | | \ | | | | T-CREATE \ | | | | request v| | | | | | | | | | | | | | | | T-TERMINATE | | | | indication | | | | /| | | | / | | | | / | | | | v | | | | | | | | Figure 20 - Sequence of Primitives in TS provider rejection of TC creation attempt Dae Young Kim Expires 4/30/97 [page 52]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 \ | | | | T-CREATE \ | | | | request \ | | | | v | | | | |\ | | | | \ |T-CREATE | T-CREATE | | \ |indication | indication | T-CREATE | \|_ _ _ _ _ _|_ _ _ _ _ _ _| indication | |\ |\ |\ | | \ | \ | \ | | v | v | v | | | | | | | | | | T-CREATE | T-CREATE | T-CREATE | | response | response | response | | / | / | / | | / | / | / | |v_ _ _ _ __|v_ _ _ _ _ _ |v | / | | | | @ | | | | / \ | | | |/ \|_ _ _ _ _ _|_ _ _ _ _ _ _| T-CREATE /| |\ |\ |\ indication / | | \ | \ | \ / | | v | v | v v | |T-TERMINATE|T-TERMINATE |T-TERMINATE | |indication |indication |indication | | | | Figure 21 - Sequence of primitives in TS provider rejection of TC creation attempt due to unsatisfied TC-characteristics Dae Young Kim Expires 4/30/97 [page 53]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Annex A TC Ordering Relationships (This annex forms a normative part of this Recommendation | International Standard) A.1 Properties of Ordering It applies at the service level and at the protocol level. At the service level, the service provider may be required to provide guarantees regarding the order in which TSDUs are delivered to the receiving TS users. At the protocol level, TPDUs are ordered, or reordered to achieve the ordering property required by the service. The following notation is used to describe the ordering relationships: - S_i(m): Local event of sending a TSDU m at site i, - A_j(m): Local event of accepting a TSDU m at site j, - P -->Q: "An event P happens before an event Q," - P ==>Q: "If P is TRUE, then Q is to be TRUE," - P=/=>Q: "If P is TRUE, then Q does not need to be TRUE." A.1.1 No ordering TS provider does not guarantee any relationship between TSDUs sent from a single sending TS user or from multiple sending TS users. Notation: S_p(m) -->S_q(m') =/=> A_i(m) --> A_i(m') for all p,q,i; for all (m,m') pairs. A.1.2 Local ordering The TSDUs, generated by a particular sending TS user, are delivered to all of the receiving TS users in the same order in which they were generated. Local ordering does not establish any ordering relationship among TSDUs generated by different sending TS users. Notation: S_p(m) -->S_p(m') =/=> A_i(m) --> A_i(m') for all p,i; for all (m,m') pairs. But, the following constraint also applies: Notation: S_p(m) -->S_p(m') ==> A_i(m) --> A_i(m') for any given p,i pair, for all (m,m') pairs. Dae Young Kim Expires 4/30/97 [page 54]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 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 aplies: 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 as established that A happens before B and that B happens before C, then it can be established 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 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') Dae Young Kim Expires 4/30/97 [page 55]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 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 4/30/97 [page 56]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Annex B QoS Negotiation in TC Establishment (This annex forms a normative part of this Recommendation | International Standard) C.1 QoS negotiation in OA TC-establishment The OA procedure has the following steps (in cases of successful creation). 1. The TC-owner issues a T-CREATE request containing its QoS parameters, which are chosen from the complete set of possible QoS parameters defined below. 2. Every other TS-user responds with a T-CREATE response containing its QoS parameters. 3. The provider arbitrates the QoS parameters and issues arbitrated QoS values in TC-CREATE confirm primitives to all TS-users. The QoS parameters that can be used in OA QoS negotiation are, for each TS-user, Dae Young Kim Expires 4/30/97 [page 57]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 - its requirements and capability for throughput in terms of maximum possible and minimum acceptable transmit rates on the multicast, and maximum possible and minimum acceptable receive rates for data from all other TS-users aggregated together - its maximum acceptable transit delay for all the data it transmits, and its maximum acceptable delay on all the data it receives from all other TS-users aggregated together - its maximum acceptable jitter for all the data it transmits, and its maximum acceptable jitter on all the data it receives from all other TS-users aggregated together. Note: The current draft does not define how thresholds are agreed. The arbitration of QoS values is as follows. [To be supplied.] C.2 QoS negotiation in SWA TC-establishment C.2.1 QoS negotiation in SWA TC-establishment To define the SWA procedure it is useful to define a focal TS-user to be a TS-user that intends to transmit on the multi-cast TC. During the procedure, each focal TS-user initiates a 1xN QoS negotiation relating to the data it transmits and the reception of that data by other TS-users. ISSUE: Is it appropriate to define a subset of the non-owner TS-users to be focal stations in this way, or should all other TS-users be treated alike? The SWA procedure has the following steps (in cases of successful creation). 1. The TC-owner issues a T-CREATE request, multicast, containing a QoS proposal for its 1xN. 2. Every other focal TS-user issues a T-CREATE request, multicast, containing a QoS proposal for its 1xN. 3. Every TS-user responds to each T-CREATE indication it receives with a T-CREATE response, which contains a set of responses to the QoS proposals made by the focal TS-user that issued the corresponding T-CREATE request. 4. The provider performs an arbitration of the QoS for each 1xN. NOTE: This arbitration is expected to be performed in a distributed way, with each 1xN arbitration performed locally to its focal TS-user. This step applies only to "connection-wide" QoS negotiations: "receiver-selected" negotiations if any terminate after step 3 (see 10.2.2.3). Dae Young Kim Expires 4/30/97 [page 58]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 5. The provider issues TC-CREATE confirm primitives containing the results of all arbitration, with AGI for the whole connection, to all TS-users. From the point of view of QoS, the SWA procedure allows the individual 1xN QoS negotiations to be initiated and arbitrated independently, following the sequence - proposal - provider modification - response - arbitration (local to focal TS-user). C.2.2 Definition of individual 1xN procedures for QoS negotiation in SWA TC-establishment This subclause defines the individual 1xN procedures initiated by the focal TS-users in SWA TC-establishment. Each QoS negotiation may be performed on either a connection-wide or a receiver-selected basis. In connection-wide negotiation, each value is agreed between the focal TS-user, the TS-provider and all responding TS-users. In receiver-selected negotiation, a number of different values are agreed, one for each responding TS-user individually. In principle, either style of negotiation may be applied to any QoS characteristic, depending on the users' requirements. The choice is made by the focal TS-user when initiating the negotiation. Where negotiation of a threshold is performed simultaneously with that of an operating target or an LQA limit, the range applicable to the threshold must at all times lie within the range applicable to the operating target or LQA limit. NOTE: The current draft does not define how thresholds are agreed. In the following definitions, the terms increase, high value, better value and upper bound are all to be understood as in the direction of higher quality, and the terms decrease, low value, worse value and lower bound are to be understood as in the direction of lower quality. High quality values may be low numerically and vice versa, as in the case of transit delay. C.2.2.1 Connection-wide 1xN negotiation The negotiation mechanisms for connection-wide 1xN negotiation involve a focal TS-user, all responding TS-users and the TS-provider. Dae Young Kim Expires 4/30/97 [page 59]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Five mechanisms are defined, as follows: - "single-parameter" negotiation, which is negotiation down from upper bounds provided by the parties in succession, with no lower bounds imposed; - bounded negotiation of a lower limit (LQA); - bounded negotiation of an upper limit (CHQ); - bounded negotiation of an operating target; - combined negotiation of upper and lower limits (CHQ and LQA). The term "bounded" is used to characterize negotiation mechanisms in which bounds are placed on how far values may be changed from those proposed. The four bounded negotiation mechanisms are very similar, nd can be regarded as variants of a single underlying negotiation method. However, they are defined individually for maximum clarity. ISSUE: It is still to be determined exactly which of these mechanisms should be applied to the various QoS parameters negotiated, and whether they are all in fact necessary for ECTS. Specifically, should CHQ limits be negotiated by single-parameter or bounded negotiation? Are operating targets to be negotiated at all? The definitions that follow are taken from the QoS Guide to Methods and Mechanisms, TR 13243. They are to be understood in the context of ECTS as follows: user means TS-user, provider means TS-provider and initiating user means focal TS-user. 1 Single-parameter negotiation - connection-wide This mechanism can be used to negotiate operating targets or upper limits (CHQ). 1 The initiating user supplies a proposed value P. 2 The provider may refuse the request. If the provider does not refuse the request, for each responding user it may select a new proposed value Pi' which is not better than the initiator-proposed value. (These new values may differ between responder , since the capacity of the provider may vary from responder to responder.) Thus for all responders Ri, Pi' < P. The provider supplies the proposed values to the responding users. 3 Each responding user may refuse the request. If a responder does not refuse the request, it may select a new proposed value Vi which is not better than the value proposed by the provider. Thus for all responders Ri, Vi < Pi' < P. 4 The provider shall select the lowest of the values returned by the responding users, V = min Vi. 5 The selected value V is returned to the initiating user and to all Dae Young Kim Expires 4/30/97 [page 60]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 the responding users. It is the "agreed" value, and is such that V = min Vi < Vi < Pi' < P. The mechanism is illustrated in Figure a.1 Initiator | Provider | Responders | Provider | All paires -----------+-----------+---------------+-----------+------------------ | | _ _ _ _ _ | | | | | | | | ---------------+ | | | | | | |---------+---+ | | | | | | | | | | | | | | | v - - |- |- - -+ | | | \ | | | | | | | | \ | +---------+ | +--v--+ | v \| +---------+ | | | | | |\ | | |/^| min |- + ------------ | | \ |/ | | | | | | | \ /| | +-----+ | | | | v_ / | | | | | | | | | | | +---------+ | | | | | | | | | | | | | | Figure a.1 - Single-parameter negotiation (CW) 2 Bounded negotiation of a lower limit (LQA) - connection-wide 1 The initiating user specifies a desired operating range by supplying a lower bound L and an upper bound U, where L < U. L is its proposed low limit value. 2 The provider may refuse the request if it knows it cannot be met, i.e. if it cannot support at least the lower bound value L. If the provider does not refuse the request, but cannot operate over the full range proposed by the initiating user,ng user, y determine a new reduced value Ui' for the upper bound for each responding user Ri individually: this reduced value may not be worse than the lower bound. Thus L < Ui' < U for all i. (It is also possible that the provider may choose to operate internally at a higher quality, but it does not signal this fact to the responding user.) NOTE: It may be appropriate for the provider to propose different upper bounds to different responders because of different provider capabilities in different regions. The provider is not required to perform an initial arbitration to determine one u per bound common to Dae Young Kim Expires 4/30/97 [page 61]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 all responders, because at this stage it is not known which responders will wish to participate in the connection, or the values they would wish to propose in response. The provider may not alter the lower bound L. The new upper bound Ui' and the lower bound L are supplied to each responding user Ri. 3 Each responding user may refuse the request. If it accepts, it may increase the lower bound to a new value Li' within the range up to the upper bound Ui'supplied by the provider. Thus for each responder Ri, L < Li' < Ui'< U. The new lower and upper bound values Li' and Ui' are returned to the provider. 4 The provider examines the values returned from each responding user. Its behavior will depend upon the level of agreement that is being negotiated. Compulsory or guaranteed level of agreement The provider must select a final connection-wide QoS value not worse than the highest lower bound of the responders (L'max = max Li'), yet it must be capable of operating at that value to all responders. The possibility exists that highest lower bound L'max will be greater than its operating capability, as expressed by the upper bound Ui',to one or more responders; in such a case, some responders must be excluded so as to leave a feasible operating region between the highest lower bound of the remaining responders and the lowest of its remaining upper bounds. Thus, it is a requirement for a feasible region that L'max < U'min, and responders may need to be removed from the connection until this constraint is satisfied. Then the provider selects the connection-wide value V within the range, i.e. such that L'max < V < U'min. Typically V will be close to L'max. Best-efforts level of agreement The provider attempts to satisfy the same constraints as in the cases of compulsory or guaranteed levels of agreement, but does not exclude responders if the constraints cannot all be satisfied. If there is a feasible region, i.e. L'max < U'min, connection-wide value V selected by the provider will satisfy L'max < V < U'min and typically be close to L'max. Dae Young Kim Expires 4/30/97 [page 62]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 5 The selected value V is returned to the initiating user and to all (remaining) responding users. It is the "agreed" LQA value. Except in the case of best-efforts level of agreement, this meets the requirements of all (remaining) parties since for all remaining responders Ri, L < Li' < L'max < V < U'min < Ui' < U. The mechanism is illustrated in Figure a.2 Initiator | Provider | Responders | Provider | All paires -----------+-----------+---------------+-----------+------------------ | | _ _ _ _ _ | | | | | | | | ---------------+ | | | | | | |----------+---+-----|-|-----+ | | | | | | | | | | | | | /-> | | + | | | \ | |/ \ | | | | | | \ | /+--------\+ | +--v--+ | v \|/ +---------+ \|__+ | | | |\ | | | | Arb |--+------------- | / | \ |/-|--| | | | / | | \ /| | +-^---+ | -----------------/--+ | | v_ / | | | | | | | | | | | | | |--|--|---->----|--|----- | | | | | | | | | +---------+ | | | | | | Figure a.2 - Bounded negotiation of a low value (CW) 3 Bounded negotiation of an upper limit (CHQ) - connection-wide 1 The initiating user specifies a desired operating range by supplying a lower bound L and an upper bound U, where L < U. U is its proposed high limit or high threshold value. 2 The provider may refuse the request if it knows it cannot be met, i.e. if it cannot support at least the lower bound value L. If the provider does not refuse the request, but cannot operate over the full range proposed by the initiating user,it may determine a new reduced value Ui' for the upper bound for each responding user Ri individually: this reduced value may not be worse than the lower bound. Thus L < Ui' < U for all i. (It is also possible that the Dae Young Kim Expires 4/30/97 [page 63]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 provider may choose to operate inte e te inte e e nally at a higher quality, but it does not signal this fact to the responding user.) NOTE: It may be appropriate for the provider to propose different upper bounds to different responders because of different provider capabilities in different regions. The provider is not required to perform an initial arbitration to determine one u per bound common to all responders, because at this stage it is not known which responders will wish to participate in the connection, or the values they would wish to propose in response. The provider may not alter the lower bound L. The new upper bound Ui' and the lower bound L are supplied to each responding user Ri. 3 Each responding user may refuse the request. If it accepts, it may decrease the upper bound to a new value Ui", within the bounds L and Ui' supplied by the provider. Thus for each responder Ri, L < Ui" < Ui' < U. The lower and new upper bound values L and Ui" are returned to the provider. 4 The provider selects the final connection-wide QoS value V = min Ui". 5 The selected value V is returned to the initiating user and to all responding users. It is the "agreed" CHQ value. This meets the requirements of all parties since for all responders Ri, L < V = U"min < Ui" < Ui' < U. The mechanism is illustrated in Figure a.3 Dae Young Kim Expires 4/30/97 [page 64]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Initiator | Provider | Responders | Provider | All paires -----------+-----------+---------------+-----------+---------------- | | _ _ _ _ _ | | | | | | | | ---------------+ | | | | | | |----------+---+ | | | | | | | |-----|-|-----+ | | | | | /-> | | + | | | \ | |/ \ | | | | | | \ | /+--------\+ | +--v--+ | v \|/ +---------+ \|__+ | | | |\ | | | | min |--+------------- | / | \ |/-|--| | | | / | | \ /| | +-^---+ | -----------------/--+ | | v_ / | | | | | | | | | | | | |--|--|----+ | | | | | | | | | | | +---------+ | | | | | | Figure a.3 - Bounded negotiation of a high value (CW) 4 Bounded negotiation of an operating target-connection-wide 1 The initiating user specifies a desired operating range by supplying a lower bound L and an upper bound U, where L < U. 2 The provider may refuse the request if it knows it cannot be met, i.e. if it cannot support at least the lower bound value L. If the provider does not refuse the request, but cannot operate over the full range proposed by the initiating user,it may determine a new reduced value Ui' for the upper bound for each responding user Ri individually: this reduced value may not be worse than the lower bound. Thus L < Ui' < U for all i. (It is also possible that the provider may choose to operate internally at a higher quality, but it does not signal this fact to the responding user.) NOTE: It may be appropriate for the provider to propose different upper bounds to different responders because of different provider capabilities in different regions. The provider is not required to perform an initial arbitration to determine one upper bound common to all responders, because at this stage it is not known which responders will wish to participate in the connection, or the values they would wish to propose in response. Dae Young Kim Expires 4/30/97 [page 65]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 The provider may not alter the lower bound L. The new upper bound Ui' and the lower bound L are supplied to each responding user Ri. 3 Each responding user may refuse the request. If it accepts, it may increase the lower bound to a new value Li' and it may decrease the upper bound to a new value Ui", within the bounds L and Ui' supplied by the provider. Thus for each responder Ri, L < Li' < Ui" < Ui' < U. The new lower and new upper bound values Li' and Ui" are returned to the provider. 4 The provider examines the values returned from each responding user. The level of agreement that is being negotiated is best-efforts (since the others do not apply to operating targets). The provider selects a final connection-wide QoS value V. If there is a feasible operating region within the ranges returned by all responders, i.e. if the highest lower bound L'max is less than or equal to the lowest upper bound U"min = min en V is selected in the feasible region, so that L'max < V < U"min. However, this may not be possible. 5 The selected value V is returned to the initiating user and to all responding users. It is the "agreed" value. The mechanism is illustrated in Figure a.4. Initiator | Provider | Responders | Provider | All paires -----------+-----------+---------------+-----------+------------------ | | _ _ _ _ _ | | | | | | | | ---------------+ | | | | | | |----------+--->- - -|-|- - -+ | | | | | | | | | | | | | /-> | | | | | | \ | |/ \ | | | | | | \ | /+--------\+ | +--v--+ | v \|/ +---------+ \|__+ | | | |\ | | | | Arb |--+------------- | / | \ |/-|--| | | | / | | \ /| | +-----+ | -----------------/--+ | | v_ / | | | | | | | | _ _ _ _|_ _ _| | | |--|--|----^ | | | | | | | | | | | +---------+ | | | | | | Figure a.4 - Bounded negotiation of an operating target (CW) 5 Combined negotiation of lower and upper limits - connection-wide This mechanism differs from the preceding ones in that it is used to Dae Young Kim Expires 4/30/97 [page 66]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 negotiate two values - a lower limit and an upper limit - whereas the others are used to negotiate single values. 1 The initiating user proposes a lower limit L and an upper limit U, where L < U. 2 The provider may refuse the request if it knows it cannot be met, i.e. if it cannot support at least the lower bound value L. If the provider does not refuse the request, but cannot operate over the full range proposed by the initiating user,ng user, y determine a new reduced value Ui' for the upper bound for each responding user Ri individually: this reduced value may not be worse than the lower bound. Thus L < Ui' < U for all i. (It is also possible that the provider may choose to operate inte e te inte e e nally at a higher quality, but it does not signal this fact to the responding user.) NOTE: It may be appropriate for the provider to propose different upper bounds to different responders because of different provider capabilities in different regions. The provider is not required to perform an initial arbitration to determine one u per bound common to all responders, because at this stage it is not known which responders will wish to participate in the connection, or the values they would wish to propose in response. The provider may not alter the lower bound L. The new upper bound Ui' and the lower bound L are supplied to each responding user Ri. 3 Each responding user may refuse the request. If it accepts, it may increase the lower bound to a new value Li' and it may decrease the upper bound to a new value Ui", within the bounds L and Ui' supplied by the provider. Thus for each responder Ri, L < Li' < Ui" < Ui' < U. The new lower and new upper bound values Li' and Ui" are returned to the provider. Dae Young Kim Expires 4/30/97 [page 67]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 4 The provider examines the values returned from each responding user. Its behavior will depend upon the level of agreement that is being negotiated. Compulsory or guaranteed level of agreement The provider must select a final connection-wide QoS lower limit LF and a final connection-wide QoS lower limit UF such that LF is not worse than the highest lower bound L'max = max Li' and UF is not better than the lowest upper bound U"min=min Ui". Thus, it is a requirement for a feasible region that L'max < U"min, and responders may need to be removed from the connection until this constraint is satisfied. Then the provider selects the connection -wide values LF and UF such that L'max < LF < UF < U"min. Typically LF will be close to L'max and UF will be close to U"min. Best-efforts level of agreement The provider attempts to satisfy the same constraints as in the cases of compulsory or guaranteed levels of agreement, but does not exclude responders if the constraints cannot all be satisfied. If there is a feasible region, i.e. if L'max < x < ax < x < the connection-wide values LF and UF selected by the provider will satisfy L'max < LF < UF < U"min and typically LF will be close to L'max and UF will be close to U"min. 5 The selected values LF and UF are returned to the initiating user and to all (remaining) responding users. They are the "agreed" values. Except in the case of best-efforts level or agreement, this meets the requirements of all (remaining) parties since for all remaining responders Ri, L < Li' < L'max < LF < UF < U"min < Ui" < Ui' < U. The mechanism is illustrated in Figure a.5 Dae Young Kim Expires 4/30/97 [page 68]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Initiator | Provider | Responders | Provider | All paires -----------+-----------+---------------+-----------+----------------- | | _ _ _ _ _ | | | | | | | | ---------------+ | | | | | | |----------+--->- - -|-|- - -+ | | | | | | | | | | | | | /-> | | | | | | \ | |/ \ | | | | | | \ | /+--------\+ | +--v--+ | v \|/ +---------+ \|__+ | | | |\ | | | | Arb |--+------------- | / | \ |/-|--| |--|------------- | / | | \ /| | +-----+ | -----------------/--+ | | v_ / | | | | | | | | _ _ _ _|_ _ _| | | |--|--|----^ | | | | | | | | | | | +---------+ | | | | | | FIgure a.5 - Combined negotiation of lower and upper limits (CW) C.2.2.2 Receiver-selected 1xN negotiation Receiver-selected negotiation is expected to be used only for the negotiation of LQA limits and operating targets. The negotiation mechanism involves a focal TS-user (the initiating user), a responding TS-user and the TS-provider. It is operated pairwise (per value negotiated) with each responding TS-user as follows. 1 The initiating user specifies a desired operating range by supplying a lower bound L and an upper bound U, where L < U. (Where an LQA limit is being negotiated, L is the proposed LQA value. Where an operating target is being negotiated,U is the proposed target value.) 2 The provider may refuse the request if it knows it cannot be met, i.e. if it cannot support at least the lower bound value L. If the provider does not refuse the request, but cannot operate over the full range proposed by the initiating user,it may determine a new reduced value U' for the upper bound: this reduced value may not be worse than the lower bound. Thus L < U' < U. (It is possible that the provider may choose to operate internally at a higher quality, but it does not signal this fa a t to the responding user.) The provider may not alter the lower bound L. The new upper bound U' Dae Young Kim Expires 4/30/97 [page 69]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 and the lower bound L are supplied to the responding user. 3 The responding user may refuse the request. If it accepts, it may select any value V in the range between the lower and upper bounds supplied. Thus L < V < U'. The selected value is returned to the provider. 4 The provider must leave the selected value V unchanged. 5 The selected value V is returned to the initiating user. It is the "agreed" value. The mechanism is illustrated in Figure a.6. Initiator | Provider | Responders | Provider | All paires -----------+-----------+---------------+-----------+------------- | | | | | | | | ---------------+ | | | | | | | | | V______|_______ | | | | |-------+-----------+------------- ----------|-----------|-------+ | | | | | | NOTE: The provider and responder may refuse to accept the proposed value(s) and thus abort the negotiation. Figure a.6 - Receiver-selected negotiation C.2.3 Constraints applicable to specific QoS characteristics This standard places the following constraints on how QoS agreements are reached. C1. Corrupted TSDU error rate and lost TSDU error rate are negotiated between TS-users only, i.e. using a restricted form of the mechanisms defined above in which the TS-provider plays no part. C2. TC ordering is not subject to imposition or negotiation during CREATE or JOIN operations. See 10.3 for further information. C3. TC protection is determined by security policy, and is not covered by this clause. C4. TC precedence is determined by a management policy. It may be imposed, but not negotiated. NOTE 1: Should we say that it is inappropriate to negotiate any characteristic at a guaranteed level for a TC that does not have maximum precedence. If not, what happens when there is a conflict? Which wins, the guarantee or the precedence? Dae Young Kim Expires 4/30/97 [page 70]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 C.2.4 QoS parameters of ECTS Service Primitives This clause identifies the general set of QoS parameters used in ECTS Service Primitives in order to impose or 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 in 10.2.2, including the negotiation rules. For each QoS characteristic, other than TC-protection, the following parameters may be present in T-CREATE and T-JOIN service primitives: - imposition or negotiation - type of value negotiated,i.e. operating target, LQA limit, CHQ limit, threshold - type of agreement required, i.e. best efforts, compulsory or guaranteed - negotiation type, i.e. connection-wide/receiver-selected - values as defined in the negotiation mechanism employed (see 10.2.2). Dae Young Kim Expires 4/30/97 [page 71]
INTERNET_DRAFT draft-kim-jtc1-sc6-ects-00.txt 30 Nov. 1996 Annex C Bibliography (This annex forms an informative part of this Recommendation | International Standard) Many documents and papers have contributed to the construction of this standard. Some of which are: - ISO/IEC jtc1/sc6, Draft on Multi-peer Taxonomy, P 01.06.36 (ECFF), Oct. 14, 1994. - ISO/IEC jtc1/sc6 N8693, Draft Multicast Taxonomy of Multicast Operation, P01.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. Dae Young Kim Expires 4/30/97 [page 72]