Working Implementation Agreements for Open Systems Interconnection Protocols: Part 4 - Transport Layer Output from the December 1993 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: Fred Burg, AT&T SIG Editor: Brenda Gray, NIST PART 4: Transport Layer December 1993 (Working) Foreword This part of the Working Implementation Agreements was prepared by the Lower Layers Special Interest Group (LLSIG) of the Open Systems Environment Implementors' Workshop (OIW). See Part 1 - Workshop Policies and Procedures in the "Draft Working Implementation Agreements Document" for the workshop charter. Text in this part has been approved by the Plenary of the Workshop. This part replaces the previously existing part on this subject. Future changes and additions to this version of these Implementor Agreements will be published as a new part. Deleted and replaced text will be shown as struck. New and replacement text will be shown as shaded. ii PART 4: Transport Layer December 1993 (Working) Table of Contents Part 4 - Transport Layer . . . . . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Normative References . . . . . . . . . . . . . . . . . . 1 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 1 5 Provision of Connection Mode Transport Services . . . . . 1 5.1 Transport Class 4 . . . . . . . . . . . . . . . . . 1 5.1.1 Transport Class 4 Overview . . . . . . . . 1 5.1.2 Protocol Agreements . . . . . . . . . . . . 2 5.1.2.1 General Rules . . . . . . . . . . . . . . . 2 5.1.2.2 Transport Class 4 Service Access Points or Selectors . . . . . . . . . . . . . . . . . 2 5.1.2.3 Retransmission Timer . . . . . . . . . . . 2 5.1.2.4 Keep-Alive Function . . . . . . . . . . . . 2 5.1.2.5 Congestion Avoidance Policies . . . . . . . 2 5.1.2.6 Use of Priority when operating over CLNS . 2 5.2 Transport Class 0 . . . . . . . . . . . . . . . . . 5 5.2.1 Transport Class 0 Overview . . . . . . . . 5 5.2.2 Protocol Agreements . . . . . . . . . . . . 5 5.2.2.1 General Rules . . . . . . . . . . . . . . . 5 5.2.2.2 Transport Class 0 Service Access Points . . 6 5.2.3 Rules for Negotiation . . . . . . . . . . . 6 5.3 Transport Class 2 . . . . . . . . . . . . . . . . . 6 5.3.1 Transport Class 2 Overview . . . . . . . . 6 5.3.2 Protocol Agreements . . . . . . . . . . . . 6 6 Provision of Connectionless Transport Service . . . . . . 6 7 Transport Protocol Identification . . . . . . . . . . . . 6 8 Security . . . . . . . . . . . . . . . . . . . . . . . . 7 iii Part 4 - Transport Layer Editor's Note - All references to Stable Agreements in this Section are to Version 7. 0 Introduction (Refer to Stable Implementation Agreements Document) 1 Scope (Refer to the Stable Implementation Agreements Document). 2 Normative References This material is current as of December 10, 1993. 3 Status This material is current as of December 10, 1993. 4 Errata Errata are reflected in pages of Version 7, Stable Document. This clause lists the defect reports from ISO which are currently recognized to be valid for the purpose of OIW conformance. 5 Provision of Connection Mode Transport Services (Refer to the Stable Implementation Agreements Document). 5.1 Transport Class 4 (Refer to the Stable Implementation Agreements Document). 5.1.1 Transport Class 4 Overview (Refer to the Stable Implementation Agreements Document). 1 PART 4: Transport Layer December 1993 (Working) 5.1.2 Protocol Agreements (Refer to the Stable Implementation Agreements Document). 5.1.2.1 General Rules (Refer to the Stable Implementation Agreements Document.) 5.1.2.2 Transport Class 4 Service Access Points or Selectors (Refer to the Stable Implementation Agreements Document.) 5.1.2.3 Retransmission Timer (Refer to Stable Implementation Agreements Document) 5.1.2.4 Keep-Alive Function (Refer to the Stable Implementation Agreements Document.) 5.1.2.5 Congestion Avoidance Policies (Refer to the Stable Implementation Agreements Document). 5.1.2.6 Use of Priority when operating over CLNS1 End system procurers shall have the option of mandating implementation of the priority parameter. If the parameter is mandated, end systems shall send an explicit priority parameter. Additional requirements are defined as follows: a) A local mechanism shall be provided to convey priority information in the Transport service. If appropriate, simultaneous Transport service requests can be managed on a priority basis within the Transport Layer; b) Mapping to and from the Transport Service priority value is done by encoding/decoding an integer in the range 0..14. 1 Refer to part 3 clause 11 for an overview on the use of priority. 2 PART 4: Transport Layer December 1993 (Working) Other values, when received, are invalid and should be considered equal to the value 14, the lowest priority. When the priority parameter is not present in a CR TPDU, the priority value is considered to have the value 14, the lowest priority; c) The priority value is negotiable with an implicit minimum acceptable value of 14, the lowest priority. The priority parameter can only be transmitted in a CC TPDU if the corresponding received CR TPDU contained the priority parameter; d) Each N-UNITDATA request shall be assigned a priority level derived from the Transport Connection (TC) priority level; e) As an option, the mapping of TC priority values, as detemined at connection setup, to N-UNITDATA request priority values, used during data transfer, is as follows: TC Priority N-UNITDATA Request Priority 0 high 14 1 13 2 3 12 . 3 . . 3 . . 3 . 13 1 14 low 0 NOTE - This encoding is consistent with ISO 8073 and reflects the reverse encoding of ISO 8473. The use of the above mapping is for further study. f) The exchange of priority parameters by Transport entities is performed as described below: 1) The priority value indicated in the T-Connect Request primitive shall be encoded and sent in the CR TPDU as the priority level "desired" for the Transport connection; 2) A receiving Transport entity supporting priority management shall either accept the priority level proposed in the CR TPDU or select a lower level. The 3 PART 4: Transport Layer December 1993 (Working) CR shall not be rejected solely because of the "desired" priority level. The selected priority level shall be encoded and returned to the calling Transport entity in the CC TPDU. The TC priority is also passed to the local session entity with the T-Connect indication primitive and is eventually conveyed to the TS user, which can reject the association if the priority is unacceptable. If a transport entity which supports priority management receives a CR TPDU without the priority parameter, the entity shall proceed as follows: - it shall associate the lowest priority level with any resulting Transport connection for the purpose of local Transport connection management; - it shall omit the priority parameter from any resulting CC TPDU; - it shall not associate any priority information with NSDUs passed to the Network entity supporting any resulting Transport connection; 3) A receiving Transport entity not supporting priority management shall ignore the parameter in the CR TPDU; 4) If the priority parameter does not appear in the CC TPDU, the initiating Transport entity shall assume the remote Transport entity does not support priority and will therefore maintain the priority sent in the CR TPDU for its local operation; g) A disconnect request shall be issued in response to a connect request when the maximum number of Transport connections would be exceeded. However, the Transport service provider shall not refuse a new Transport connection that is higher in priority than the lowest priority Transport connection that currently exists. This may require either the termination of lower priority Transport connections or the maintenance of sufficient resources by the Transport service provider; h) The extent to which throughput can be degraded on a Transport connection is determined by the priority of that connection. Lower priority connections will have their throughput degraded first. Throughput can be degraded down to the minimum acceptable level. Connections, the 4 PART 4: Transport Layer December 1993 (Working) throughput of which falls below the minimum acceptable level must be released. NOTE - The method for specifying the minimum acceptable throughput level is for further study. i) The following, non-standard, DR TPDU reason values are defined for use at Transport connection refusal or release (Classes 1 to 4): 1) value 128 + 20: connection request refused due to insufficient priority; 2) value 128 + 21: connection released due to insufficient priority; 3) value 128 + 22: connection released due to insufficient throughput. Use of these values is optional. These values should not be generated when the CR TPDU that created the connection did not contain the priority parameter. NOTE - ISO 8073 does not define nor support a sound negotiation mechanism at this time; this process will serve to allow a priority level to be established for a TC. 5.2 Transport Class 0 (Refer to Stable Implementation Agreements Document) 5.2.1 Transport Class 0 Overview (Refer to Stable Implementation Agreements Document) 5.2.2 Protocol Agreements (Refer to the Stable Implementation Agreements Document). 5.2.2.1 General Rules (Refer to Stable Implementation Agreements Document) 5 PART 4: Transport Layer December 1993 (Working) 5.2.2.2 Transport Class 0 Service Access Points (Refer to Stable Implementation Agreements Document) 5.2.3 Rules for Negotiation (Refer to Stable Implementation Agreements Document.) 5.3 Transport Class 2 (Refer to Stable Implementation Agreements Document.) 5.3.1 Transport Class 2 Overview (Refer to Stable Implementation Agreements Document.) 5.3.2 Protocol Agreements (Refer to Stable Implementation Agreements Document) 6 Provision of Connectionless Transport Service (Refer to Stable Implementation Agreements Document.) 7 Transport Protocol Identification (Refer to the Stable Implementation Agreements Document.) 6 PART 4: Transport Layer December 1993 (Working) 8 Security (Refer to the Stable Implementation Agreements Document.) 7