Martine DECOURT 214-TE-E.DOC CCITTREC.DOT 16-Dec-91 24 Martine DECOURT 214-TE-E.DOC CCITTREC.DOT 16-Dec-91 23 24 Fascicle VIII.4 – Rec. X.214 Fascicle VIII.4 - Rec. X.214 23 Recommendation X.214 Fascicle VIII.4 – Rec. X.214 TRANSPORT SERVICE DEFINITION FOR OPEN SYSTEMS INTERCONNECTION FOR CCITT APPLICATIONS1) (Malaga-Torremolinos, 1984; amended at Melbourne, 1988) The CCITT, considering (a) that Recommendation X.200 defines the Reference Model of Open Systems Interconnection for CCITT applications; (b) that Recommendation X.224 specifies the connection- oriented Transport Protocol Specification for Open Systems Interconnection for CCITT Applications; (c) that Recommendation T.70 defines the Network-Independent Basic Transport Service for Teletex; (d) that Recommendation X.225 specifies the connection- oriented Session Protocol Specification for Open Systems Interconnection for CCITT applications; (e) that Recommendation X.210 specifies the OSI Layer Service Definition Conventions for describing the services of the layers of the OSI Reference Model, unanimously declares (1) that the scope, field of application, and related definitions and abbreviations of the Open Systems Interconnection Transport Service Definition are defined in §§ 1 to 4; (2) that the conventions for describing the Transport Service are given in § 5; (3) that the overview, general characteristics, and features of the Transport Service and the Classes of Transport Service are described in §§ 6, 7 and 8; (4) that the model of the Transport Service is described in § 9; (5) that the quality of Transport Service is defined in § 10; (6) that the Transport Service primitives and their related parameters are desired in §§ 11, 12, 13 and 14; (7) that the formal description of the Transport Service is contained in § 15. CONTENTS 10 Introduction 11 Scope and field of application 12 References 13 Definitions 14 Abbreviations 15 Conventions 16 Overview and general characteristics 17 Features of the Transport Service 18 Classes of Transport Service 19 Model of the Transport Service 10 Quality of Transport Service 11 Sequence of Transport Service primitives 12 Transport Connection establishment phase 13 Data transfer phase 14 Transport Connection release phase 15 Formal specification of the Transport Service 0 Introduction This Recommendation is one of a set of Recommendations produced to facilitate the interconnection of computer systems. It is related to other Recommendations in the set as defined by the Reference Model of Open Systems Interconnection (OSI). The OSI Reference Model (Reference 1) subdivides the area of standardization for interconnection into a series of layers of specification, each of manageable size. This Recommendation defines the Service provided by the Transport Layer to the Session Layer at the boundary between 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/X.214. Throughout the set of OSI Recommendations, 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 is a conceptual Architectural Service, independent of administrative divisions. Note – It is important to distinguish the specialized use of the term “Service” within the set of OSI Recommendations from its use elsewhere to describe the provision of a service by an organisation (such as the provision of a service as defined in other CCITT Recommendations by an Administration). Figure 1/X.214 = 5 cm 1 Scope and field of application This Recommendation 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 the actions and events. The service defined in this Recommendation is that which is provided by all OSI Transport Protocols (in conjunction with the Network Service) and which may be used by any OSI Session Protocol. This Recommendation does not specify individual implementations or products, nor does it constrain the implementation of entities and interfaces within a system. Conformance of equipment to this Recommendation is achieved by conformance to the protocols specified to fulfill the Transport Service defined in this Recommendation. 2 References [1] Recommendation X.200 – Reference Model of Open Systems Interconnection for CCITT Applications (see also ISO 7498). [2] Recommendation X.224 – Transport Protocol Specification for Open Systems Interconnection for CCITT Applications (see also ISO 8073). [3] Recommendation X.225 – Session Protocol Specification for Open Systems Interconnection for CCITT Applications (see also ISO 8327). [4] Recommendation X.210 – OSI Layer Service Definition Conventions (see also ISO TR 8509). [5] Recommendation T.70 – Network – Independent Basic Transport Service for Teletex. 3 Definitions 3.1 Reference Model definitions This Recommendation is based on the concepts developed in the OSI Reference Model (Reference 1), and makes use of the following terms defined in that Recommendation: a)expedited transport-service-data-unit; b)transport-connection; c)transport-connection endpoint; d)Transport Layer; e)Transport Service; f)transport-service-access-point; g)transport-service-access-point address; h)transport-service-data-unit; i)Network Layer; j)Network Service; k)network-connection; l)interface flow control. 3.2 Service Definition Convention This Recommendation also makes use of the following terms defined in Reference 4, OSI Layer Service Definition Conventions as they apply to the Transport Layer: a)service-user; b)service-provider; c)primitive; d)request; e)indication; f)response; g)confirm. 3.3 Transport Service definitions For the purpose of this Recommendation, the following definitions also apply: 3.3.1Calling TS user A Transport Service user that initiates a transport connection establishment request. 3.3.2Called TS user A Transport Service user with whom a calling TS user wishes to establish a transport-connection. Note – Calling TS users and called TS users are defined with respect to a single connection. A Transport Service user can be both a calling and a called TS user simultaneously. 3.3.3Sending TS user A Transport Service user that acts as a source of data during the data transfer phase of a transport-connection. 3.3.4Receiving a TS user A Transport Service user that acts as a sink of data during the data transfer phase of a transport-connection. Note – A Transport Service user can be both a sending and a receiving TS user simultaneously. 4 Abbreviations TS: Transport Service TC: Transport-connection TSAP:Transport-service-access-point TSDU:Transport-service-data-unit QOS: Quality of Service 5 Conventions 5.1 General conventions This Recommendation uses the descriptive conventions given in Reference 4, OSI Layer Service Definition Conventions. 5.2 Parameters The available parameters for each group of primitives are set out in tables in §§ 12 to 14. Each “X” in the tables indicates that the primitive labelling the column in which it falls may carry the parameter labelling 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) indicates that the inclusion of the parameter is a choice made by the user; b)a parameter specific constraints: (=) indicating that the value supplied in an indication or confirm primitive is always identical to that supplied in the previous request or response primitive issued at the peer service access point. 6 Overview and general characteristics The Transport Service provides transparent transfer of data between TS users. It relieves these 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 minimum cost. Quality of Service is specified through the selection of values for Quality of Service parameters representing characteristics such as throughput, transit delay, residual error rate and failure probability. b)Independence of underlying communications resources: The Transport Service hides from TS users the difference in the Quality of Service provided by the Network Service. This difference in Quality of Service arises from the use of a variety of communications media by the Network Layer to provide the Network Service. c)End-to-end significance: The Transport Service provides for the transfer of data between two TS users in end systems. d)Transparency of transferred information: The Transport Service provides for the transparent transfer of octet-aligned TS user-data and/or control information. It does neither restrict the content, format, or coding of the information, nor does it ever need to interpret its structure or meaning. e)TS user addressing: The Transport Service utilizes a system of addressing which is mapped into the addressing scheme of the supporting Network Service. Transport-addresses can be used by TS users to refer unambiguously to TSAPs. 7 Features of the Transport Service The Transport Service offers the following features to a TS user: a)The means to establish a TC with another TS user for the purpose of exchanging TSDUs. More than one TC may exist between the same pair of TS users. b)Associated with each TC at its time of establishment, the opportunity to request, negotiate, and have agreed by the TS provider a certain Quality of Service as specified by means of Quality of Service parameters. c)The means of transferring TSDUs on a TC. The transfer of TSDUs which consist of an integral number of octets is transparent, in that the boundaries of TSDUs and the contests of TSDUs are preserved unchanged by the TS provider and there are no constraints on the TSDU content imposed by the TS provider. d)The means by which the receiving TS user may control the rate at which the sending TS user may send octets of data. e)The means of transferring separate expedited TSDUs when agreed to by both TS users. Expedited TSDUs transfer is subject to a different flow control from normal data across the TSAP. f)The unconditional and therefore possible destructive release of a TC. 8 Classes of Transport Service No distinct classes of Transport Service are defined. 9 Model of the Transport Service 9.1 Model of the Transport Service This Recommendation uses the abstract model for a layer service defined in Reference 4 Service Conventions. The model defines the interactions between the TS users and the TS provider which take place at the two TSAPs. Information is passed between a TS user and the TS provider by service primitives, which may convey parameters. The primitives are abstract representations of TSAP interactions. They are solely descriptive and do not represent a specification for implementation. 9.2 Model of a Transport Connection The operation of a TC is modelled in an abstract way by a pair of queues linking the two TSAPs. There is one queue for each direction of information flow (see figure 2/X.214). Each TC is modelled by a separate pair of queues. Figure 2/X.214 = 6 cm The queue model is used to introduce the flow control feature. The ability of a TS user to add objects to a queue will be determined by the behaviour of the TS user removing objects from that queue and the state of the queue. Objects are entered and removed from the queue as a result of interactions at the two TSAPs. The pair of queues is considered to be available for each potential TC. The objects which may be placed in a queue by a TS user (see §§ 12, 13 and 14) are: a)connect objects (each representing all parameters contained in a T-CONNECT request or T-CONNECT response primitive); b)octets of normal data; c)indications of end-of-TSDU (completion of a T-Data primitive); d)expedited TSDUs (representing all parameters of a T- EXPEDITED primitive); e)disconnect objects (each representing all parameters contained in a T-DISCONNECT primitive). Note 1 – Normal and expedited TSDU transfer will result in different objects being entered into the queue. Note 2 – The description of flow control requires a less abstract description than that used for describing sequences of primitives in §§ 11-14. Each TSDU associated with a T-DATA primitive is here subdivided conceptually into a sequence of octets of data followed by an end-of-TSDU indication. The T-Data request primitive occurs when the end-of-TSDU indication is entered into the queue. The T-DATA indication primitive occurs when the end-of- TSDU indication is removed from the queue. This does not imply any particular subdivision in any real interface. The only objects which can be placed in a queue by the TS provider are disconnect objects (representing T-DISCONNECT primitives and their parameters). TS user A, who initiates connection establishment by entering a connect object (representing a T-CONNECT request primitive) into the queue from A to B, is not allowed to enter any other object into this queue until after the connect object representing the T- CONNECT confirm has been removed. In the queue from TS user B to TS user A, objects other than a disconnect object can be entered by TS user B only after TS user B has entered a connect object corresponding to a T-CONNECT response. The insertion of a disconnect object represents the initiation of the release procedure. The release procedure may be initiated at the times permitted in § 14 and in the manner described in § 11.2. The release procedure may be destructive with respect to other objects in the two queues. A queue relates an ordered set of distinct objects in the following ways: a)Queues are empty before a connect object has been added and can be returned to this state, with loss of their contents, by the TS provider under the circumstances as described in h) below. b)Objects are added to the queue, subject of control by the TS provider. c)Objects are normally removed from the queue, subject to control by the receiving TS user. d)Objects are normally removed in the same order that they were added [but see g) and h) below]. e)A queue has a limited capacity, but this capacity is not necessarily either fixed or determinable. f)The management of the queue capacity shall be such that normal data and end-of-TSDU indications cannot be added to the queue when its addition would prevent addition of an expedited TSDU or disconnect object. In addition the TS provider may manipulate pairs of adjacent objects in the queue to allow: g)Reordering The order of any pair of objects may be reversed if, and only if, the following object is of a type defined to take precedence over the preceding object. Expedited TSDUs take precedence over octets of normal data and end-of-TSDU indications (see table 1/X.214). TABLE 1/X.214 Precedence Table the queue object x Connect Octets End-of- Expedit Disconn object of TSDU ed TSDU ect normal indicat object has data ion object x precedence over queue object y Connect object – No – No Yes [see h)] Octets of normal data – No No Yes Yes [see [see g)] h)] End-of-TDSU – No No Yes Yes indication [see [see g)] h)] Expedited TSDU – No No No Yes [see h)] Disconnect object – – – – Yes [see h)] —: not applicable. No: no precedence exists. Yes: precedence exists. h)Deletion Disconnect objects take precedence over any other object. Any object other than a disconnect object may be deleted by the TS provider if, and only if, the following one is a disconnect object (see Table 1/X.214). If a connect object associated with a T-CONNECT request primitive is deleted in this manner, the disconnect object is also deleted. If a connect object associated with a T-CONNECT response positive is deleted, the disconnect object is not deleted. Whether the TS provider performs actions of types g) and h) or not, will depend on the behaviour of the TS users and on the agreed Quality of Service. In general, if the objects are not removed from the queue due to flow control expressed by the receiving TS user, the TS provider shall, after some unspecified period of time, perform all permitted actions of types g) and h). Note 1 – The internal mechanisms which support the operation of a queue are not visible in the Transport Service. A queue is one particular way of expressing the mutual interaction between primitives at different TSAPs. There may also be, for example: a) constraints on the local ability to invoke primitives; b) service procedures defining particular sequencing constraints on some primitives. Note 2 – A TC endpoint identification mechanism must be provided locally if the TS user and the TS provider need to distinguish between several TCs at a TSAP. All primitives must then make use of this identification mechanism to identify the TC to which they apply. This implicit identification is not shown as a parameter of the TS primitives, and must not be confused with the address parameters of the T-CONNECT primitives. 10 Quality of Transport Service The term Quality of Service (QOS) refers to certain characteristics of a TC as observed between the endpoints. QOS is described in terms of QOS parameters. These parameters give TS users a method of specifying their needs, and give the TS provider a basis for protocol selection. The QOS is normally negotiated between the TS users and the TS provider on a per TC basis, using the T-CONNECT request, indication, response, and confirm TS primitives defined in § 11. The QOS requested by the calling TS user may be made poorer either by the TS provider following the T-CONNECT request, or by the called TS user, following the T-CONNECT indication. In applying this to some QOS parameters this may mean that: a)a delay becomes longer, b)a throughput becomes lower, c)the error rate becomes higher, d)the priority becomes lower, e)the failure probability becomes higher. However the TC protection parameter remains unchanged by the TS provider. The so negotiated QOS values then to apply throughout the lifetime of the TC. Note – Users of the Transport Service should be aware that there is no guarantee that the originally negotiated QOS will be maintained throughout the Transport Connection lifetime, and that changes in QOS are not explicitly signalled by the Transport Service provider. The view of QOS at each end of an established TC is always the same. This section does not specify particular values, or classes of values, for the QOS parameters. Possible choices and default values for each parameter will normally be specified at the time of initial TS provider installation. The values for any or all parameters may be fixed for a given TS provider, in which case QOS negotiation on a per TC basis is not required. When a QOS value is specified; the TS user may also indicate whether the request is an absolute requirement or whether a degraded value is acceptable. The QOS parameters include parameters which express TS performance and parameters which express other TS characteristics. The QOS parameters specified in this clause are defined below. A classification of the performance QOS parameters is shown in Table 2/X.214. 10.1 TC establishment delay TC establishment delay is the maximum acceptable delay between a T-CONNECT request and the corresponding T-CONNECT confirm primitive. Note – This delay includes TS user dependent components. 10.2 TC establishment failure probability TC establishment failure probability is the ratio of total TC establishment failures to total TC establishment attempts in a measurement sample. A TC establishment failure is defined to occur when a requested TC is not established within the specified maximum acceptable TC establishment delay as a result of misconnection, TC refusal, or excessive delay on the part of the TS provider. TC establishment attempts which fail as a result of error, TC refusal, or excessive delay on the part of a TS user are excluded in calculating the TC establishment failure probability. TABLE 2/X.214 Classification of Performance QOS Parameters Performance criterion Phase Speed Accuracy/Reliability TC TC TC establishment failure establishment establishment probability (misconnection/TC delay refusal) Data transfer Throughput Residual error rate (corruption, duplication/loss) Transit delay Resilience of the TC Transfer failure probability TC release TC release TC release failure delay probability 10.3 Throughput Throughput is defined, for each direction of transfer, in terms of a sequence of at least two successfully transferred TSDUs. Given such a sequence of n TSDUs, where n is greater than or equal to two, the throughput is defined to be the smaller of: a)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; and b)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 indicators 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. Throughput is only meaningful for a sequence of complete TSDUs and each specification is based on a previously stated average TSDU size. Throughput is specified separately for each direction of transfer on a TC. In each direction, a specification of throughput will consist of a maximum throughput and an average throughput value. The maximum throughput value represents the maximum rate at which the TS provider can continuously accept and deliver TSDUs, in the absence of sending TS user input delays or flow control applied by the receiving TS user. Thus, the sequence of TSDUs in the calculation above are defined to be presented continuously at the maximum rate. The average throughput value represents the expected transfer rate on a TC including the effects of expected user- attributable delays (e.g. non-continuous TSDU input, receiving TS user flow control). Thus, the sequence of TSDUs in the calculation above are defined to be presented at a rate which includes components representing average user delays. It is possible for either the input or the output of a sequence of TSDUs to be excessively delayed by the TS users. Such occurrences are excluded in calculating average throughput values. For each direction of transfer, and for each of the maximum throughput and average throughput specifications, the throughput QOS for a particular TC will be negotiated among the TS users and the TS provider (see § 12.2.6). 10.4 Transit delay Transit delay is the elapsed time between a T-DATA request and the corresponding T-DATA indication. Elapsed time values are calculated only on TSDUs that are successfully transferred. Successful transfer of a TSDU is defined to occur when the TSDU is transferred from the sending TS user to the intended receiving TS user without error, in the proper sequence, prior to release of the TC by the receiving TS user. Transit delay is specified independently for each direction of transfer. In general, each transit delay specification will define both the average value and the maximum value expected for a TC. Each specification will be based on a previously stated average TSDU size. The transit delay for an individual TSDU may be greatly increased if the receiving TS user exercises interface flow control. Such occurrences are excluded in calculating both average and maximum transit delay values. 10.5 Residual error rate Residual error rate is the ratio of total incorrect, lost and duplicate TSDUs to total TSDUs transferred across the TS boundary during a measurement period. The relationship among these quantities is defined for a particular TS user pair, as shown in Figure 3/X.214. Figure 3/X.214 = 7.5 cm 10.6 Transfer failure probability Transfer failure probability is the ratio of total transfer failures to total transfer samples observed during a performance measurement. A transfer sample is a discrete observation of TS provider performance in transferring TSDUs between a specified sending and receiving TS user. A transfer sample begins on input of a selected TSDU at the sending TS user boundary, and continues until the outcome of a given number of TSDU transfer attempts has been determined. A transfer sample will normally correspond to the duration of an individual TC. A transfer failure is a transfer sample in which the observed performance is worse than a specified minimum acceptable level. Transfer failures are identified by comparing the measured values for three supported performance parameters with specified transfer failure thresholds. The three supported performance parameters are throughput, transit delay and residual error rate. In systems where Transport Service QOS is reliably monitored by the TS provider, transfer failure probability can be estimated by the probability of a TS provider initiated release during a transfer sample. 10.7 TC release delay TC release delay is the maximum acceptable delay between a TS user initiated T-DISCONNECT request and the successful release of the TC at the peer TS user. TC release delay is normally specified independently for each TS user. TC release delay does not apply in cases where release is initiated by the TS provider. Issuance of a T-DISCONNECT request by either TS user starts the counting of TC release delay for the other user. Successful release is signalled to the TS user not initiating the T-DISCONNECT request by a T-DISCONNECT indication. 10.8 TC release failure probability TC release failure probability is the ratio of total TC release requests resulting in release failure to total release requests included in a measurement sample. TC release failure probability is normally specified independently for each TS user. A release failure is defined to occur, for a particular TS user, if that user does not receive a T-DISCONNECT indication within the specified maximum TC release delay of the TS user issuing the T-DISCONNECT request (given that the former TS user had not itself issued a T-DISCONNECT request). 10.9 TC protection TC protection is the extent to which a TS provider attempts to prevent unauthorized monitoring or manipulation of TS user originated information. TC protection is specified qualitatively by selecting one of four TC protection options: a)no protection features; b)protection against passive monitoring; c)protection against modification, replay, addition or deletion; d)both b) and c). 10.10TC priority The specification of TC priority is concerned with the relationship between TCs. This parameter specified that 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 parameter only has meaning in the context of some management entity or structure able to judge relative importance. The number of priority levels is limited. 10.11Resilience of the TC Probability of a TS provider initiated TC release (i.e. issuance of a T-DISCONNECT indication with no prior T-DISCONNECT request) during a specified time interval (e.g.: 1 s). 11 Sequence of Transport Service primitives This section defines the constraints on the sequences in which the TS primitives may occur. The constraints determine the order in which TS primitives 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 TS provider to issue a TS primitive at any particular time. §§ 12-14 describe the TS primitives which are associated with one of the three phases of a TC, establishment, data transfer, or release. A complete listing of TS primitives appears in Table 3/X.214. 11.1 Relation of TS primitives at the two TC endpoints A TS primitive issued at one TC endpoint will, in general, have consequences at the other TC endpoint. The relations of TS primitives of each type to TS primitives at the other TC endpoint are defined in the appropriate subclause in §§ 12-14; all these relations are summarized in the Figure 4/X.214 below (see Reference 4, § 5 for the definition of time sequence diagrams). However, a T- DISCONNECT request or indication TS primitive may terminate any of the other sequences before completion. 11.2 Sequence of TS primitives at one TC endpoint The possible overall allowed sequences of TS primitives at a TC endpoint are defined in the following state transition diagram (see Figure 5/X.214) and in an alternative tabular representation (see Table 4/X.214). In Figure 5/X.214: a)The idle state (1) reflects the absence of a TC. It is the initial and final state of any sequence and once it has been re-entered, the TC is released. b)A TC release procedure can be initiated at any point during the TC establishment or data transfer phase. c)Procedures other than the TC release procedure cannot be initiated within the establishment phase. d)Any action to be taken on the occurrence of a non-allowed sequence of TS primitives is a local matter. e)The use of a state transition diagram to describe the allowable sequences of TS primitives does not impose any requirement or constraint on the internal organization of any implementation of the Transport Service. 12 Transport Connection establishment phase 12.1 Function The TC establishment TS primitives can be used to establish a TC, provided the TS users exist and are known to the TS provider. Simultaneous T-CONNECT requests at the two TSAPs are handled independently by the TS provider. Note – Simultaneous T-CONNECT requests typically result in a corresponding number of TCs. TABLE 3/X.214 Transport Service Primitives Phase Service Primitive Parameters TC TC T-CONNECT (Called address, calling establishm establishm request address, expedited data ent ent option, quality of service TS user-data) T-CONNECT (Called address, calling indication address, expedited data option, quality of service TS user-data) T-CONNECT (Quality of service, response responding address, expedited data option, TS user-data) T-CONNECT (Quality of service, confirm responding address, expedited data option, TS user-data) Data Normal T-DATA (TS user-data) transfer data request transfer T-DATA (TS user-data) indication Expedited T- (TS user-data) datatransf EXPEDITED- er a) DATA request T- (TS user-data) EXPEDITED- DATA indication TC release TC release T- (TS user-data) DISCONNECT request T- (Disconnect reason, TS user- DISCONNECT data) indication a) User option: Provided only upon TS user request. Figure 4/X.214 = 16 cm Figure 5/X.214 = 12,5 cm 12.2 Types of TS primitives and parameters The following Table 5/X.214 indicates the types of TS primitives and the parameters needed for TC establishment. 12.2.1 Addresses The parameters which take addresses as values (see §§ 12.2.2 to 12.2.4) all refer to TSAPs. These addresses are unique within the scope of TSAP addresses. 12.2.2 Called Address The Called Address parameter conveys the address of the TSAP to which the TC is to be established. 12.2.3 Calling Address The Calling Address parameter conveys the address of the TSAP from which the TC has been requested. 12.2.4 Responding Address The Responding Address parameter conveys the address of the TSAP to which the TC has been established and is identical to the Called Address parameter. Note – This parameter may be used in future definitions to return an address which is different from the Called Address, e.g., a specific address returned as the actual result of calling a generic address. TABLE 5/X.214 TC Establishment Primitives and Parameters TS-Primitive T-CONNECT T-CONNECT T-CONNECT T-CONNECT request indication response confirm Parameter Called address X X Calling address X X(=) Responding X X(=) address Expedited data X X(=) X X(=) option Quality of X X X X(=) service TS user-data X(U) X(=) X(U) X(=) X: mandatory parameter. (=): the value of that parameter is identical to the value of the corresponding parameter of the preceding TS primitive. (U): use of this parameter is a TS user option. 12.2.5 Expedited Data option The Expedited Data option parameter indicates whether the expedited data option is to be available on the TC. If this service is declared not available, it cannot be used on the TC. The value of the parameter is either “Expedited Data Service selected” or “Expedited Data Service not selected” (see § 12.4). The value of the various primitives are related such that: a)in the T-CONNECT request primitive, either of the defined values may occur; b)in the T-CONNECT indication primitive, the value is equal to the value in the T-CONNECT request primitive; c)in the T-CONNECT response primitive, the value is either “Expedited Data Service not selected” or is equal to the value in the T-CONNECT indication primitive; d)in the T-CONNECT confirm primitive, the value is equal to the value in the T-CONNECT response primitive. 12.2.6 Quality of Service Quality of Service is a list of parameters (see § 10). For each parameter, the values in the various TS primitives are related so that: a)in the T-CONNECT request primitive, any defined value is allowed, b)in the T-CONNECT indication primitive, the QOS parameter value is equal to or poorer than the value in the T-CONNECT request primitive, except for the TC protection, which must have the same value as specified in the T-CONNECT request primitive, c)in the T-CONNECT response primitive, the QOS parameter value indicated is equal to or poorer than the value in the T-CONNECT response primitive, d)in the T-CONNECT confirm primitive, the QOS parameter value indicated is equal to the value in the T-CONNECT response primitive. 12.2.7 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-CONNECT primitive may be lower than that for TS user-data in the T-DATA primitive once the TC is established. 12.3 Sequence of TS primitives The sequence of TS primitives in a successful TC establishment is defined by the following time sequence diagram (Figure 6/X.214): Figure 6/X.214 = 4,5 cm The TC establishment procedure may fail either due to the inability of the TS provider to establish a TC or due to the unwillingness of the called TS user to accept a T-CONNECT indication. These cases are described in §§ 14.4 and 14.5. The TC establishment procedure may also fail due to either of the TS users releasing the TC before the T-CONNECT confirm has been delivered to the calling TS user. 12.4 Negotiation of expedited data Transfer Service The expedited TSDU transfer is only made available when specifically requested and agreed to by both TS users when the TC is established. When available this service is always bidirectional. The procedure for negotiating the use of the expedited TSDU transfer is as follows: a)the calling TS user may request or not request the use of the expedited TSDU transfer feature; b)if the calling TS user does not request the use of the expedited TSDU transfer feature, the called TS user is not allowed to request its use; c)if the calling TS user does request the use of the expedited TSDU transfer feature, the called TS user may agree to the use of expedited TSDU transfer on the TC, in which case the TS provider is required to provide it. The called TS user may refuse the use of expedited TSDU transfer in which case the service will not be used on that TC. 13 Data transfer phase 13.1 Data Transfer Service 13.1.1 Function The TS provider provides for an exchange of TSDUs, in both directions simultaneously. The TS provider preserves the integrity, the sequence and boundaries of the TSDUs. Note – Designers of higher layer protocols should realize that the requested QOS applies to complete TSDUs, and that division of data into small TSDUs may have cost implications, because of the impact on cost optimization mechanisms operated by the TS provider. 13.1.2 Types of TS primitives and parameters Table 6/X.214 indicates the types of TS primitives and the parameters needed for data transfer. 13.1.2.1 TS User-Data The TS User-data parameter is a TSDU. A TSDU consists of an integral number of octets greater than zero. TABLE 6/X.214 Data Transfer Primitives and Parameters Primitive T-DATA request T-DATA indication Parameter TS user-data X X(=) X: mandatory parameter. (=): the value of that parameter is identical to the value of the corresponding parameter of the preceding TS primitive. 13.1.3 Sequence of TS primitives The operation of the TS provider in transferring TS user-data can be modelled as a queue of unknown size within the TS provider (see § 9). The ability of a TS user to issue a T-DATA request depends on the state of the queue. The ability of the TS provider to issue a T-DATA indication depends on the receiving TS user. The sequence of TS primitives in a successful data transfer is defined in the following time sequence diagram (Figure 7/X.214). 13.2 Expedited data transfer service 13.2.1 Function The expedited data transfer service provides a further means of information exchange on a TC in both directions simultaneously. The transfer of expedited TSDUs is subject to different QOS and separate flow control from that applying to TS user-data of the data transfer service. Figure 7/X.214 = 4,5 cm The TS provider guarantees that an expedited TSDU will not be delivered after any subsequently submitted normal TSDU or expedited TSDU on that TC. The relationship between normal and expedited data flow is modelled by the operation of reordering within queues as described in § 9. In particular expedited data will be delivered when the receiving TS user is not accepting normal data. However, the amount of normal data bypassed by such reordering cannot be predicted. 13.2.2 Types of TS primitives and parameters Table 7/X.214 indicates the types of TS primitives and the parameters needed for expedited data transfer. TABLE 7/X.214 Expedited TS Primitives and Parameters Primitive T-EXPEDITED DATA T-EXPEDITED DATA request indication Parameter TS user-data X X(=) X: mandatory parameter. (=): the value of the parameter is identical to the value of the corresponding parameter of the preceding TS primitive. 13.2.2.1 TS User-Data The TS User-Data parameter is an expedited TSDU. An expedited TSDU consists of an integral number of octets between 1 and 16 inclusive. 13.2.3Sequence of TS primitives The sequence of TS primitives in a successful expedited data transfer is defined in the following time sequence diagram (Figure 8/X.214). Figure 8/X.214 = 4,5 cm Note – Use of the expedited data transfer service must be requested by the calling TS user and agreed to by the called TS user when the TC is established (see § 12.2.5). 14 Transport Connection releas7e phase 14.1 Function The TC release TS primitives are used to release a TC. The release may be performed: a)by either or both of the TS users to release an established TC; b)by the TS provider to release an established TC; all failures to maintain a TC are indicated in this way; c)by either or both the TS users to abandon TC establishment; d)by the TS provider, to indicate its inability to establish a requested TC. TC release is permitted at any time regardless of the current TC phase. A request for release cannot be rejected. The Transport Service does not guarantee delivery of any TS user-data once the release phase in entered. 14.2 Types of TS primitives and parameters Table 8/X.214 indicates the types of TS primitives and the parameters needed for TC release. 14.2.1 Reason The Reason parameter gives information indicating the cause of the TC release. The reason is one of the following: a)remote TS user invoked; 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 – The following examples are given: a)lack of local or remote resources of the TS provider, b)QOS below minimum level, c)misbehaviour of TS provider, d)called TS user unknown, e)called TS user unavailable, f)unknown reason. TABLE 8/X.214 TC Release Primitives and Parameters Primitive T-DISCONNECT request T-DISCONNECT indication Parameter Reason X TS user-data X(U) X(=) X: mandatory parameter. (=): the value of that parameter is identical to the value of the corresponding parameter of the preceding TS primitive. (U): use of this parameter is a TS user option. 14.2.2 TS User-data 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 TC release before the T-DISCONNECT indication is delivered, or if both TS users initiate a T-DISCONNECT simultaneously. Therefore, the parameter is only present if the TC release was originated by a TS user. The TS user-data parameter, if present, shall be an integral number of octets in 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- DISCONNECT primitives 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-DISCONNECT indication, even when initiated by the remote TS user. 14.3 Sequence of TS primitives when releasing an established transport connection The sequence of TS primitives depends on the origin or origins of the TC release action. The sequence may be: a) invoked by one TS user, with a T-DISCONNECT request from that TS user leading to a T-DISCONNECT indication to the other; b)invoked by both TS users, with a T-DISCONNECT request from each of the TS users; c)invoked by the TS provider, with a T-DISCONNECT indication to each of the TS users; d) invoked independently by one TS user and the TS provider, with a T-DISCONNECT request from the initiating TS user and a T-DISCONNECT indication to the other. The sequence of TS primitives in these four cases are expressed in the following time sequence diagrams (Figures 9- 12/X.214). Figure 9/X.214 = 3,5 cm Figure 10/X.214 = 4cm Figure 11/X.214 = 4,5 cm Figure 12/X.214 = 4,5 cm 14.4 Sequence of TS primitives in TS user rejection of a TC establishment A TS user may reject a TC establishment attempt by a T- DISCONNECT request. In the T-DISCONNECT indication the reason parameter will indicate that the called TS user initiated the disconnection. The sequence of events is defined in the following time sequence diagram (see Figure 13/X.214). Figure 13/X.214 = 4 cm 14.5 Sequence of TS primitives in a TS provider rejection of a TC Establishment attempt If the TS provider is unable to establish a TC, it indicates this to the calling TS user by a T-DISCONNECT indication. The reason parameter indicates that the TS provider is the source of the T-DISCONNECT indication. The sequence of events is defined in the following time sequence diagram (Figure 14/X.214). Figure 14/X.214 = 5 cm 15 Formal specification of the Transport Service (For further study.) _______________________________ 1) La Recommandation X.214 et le rapport technique ISO 8072, [Systèmes de traitement de l'information – Interconnexion de systèmes ouverts – Définition du service de transport], ont été élaborés en étroite collaboration et sont techniquement alignés.