home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD1.mdf
/
nist
/
oiw
/
agreemnt
/
1993
/
04w_9312.txt
< prev
next >
Wrap
Text File
|
1994-02-09
|
15KB
|
660 lines
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
