As per Relevance of the word parameter, we have this rfc below:
Network Working Group Wayne
Request for Comments: 1007 June 1987
MILITARY
TO
ISO TRANSPORT
Status of this
This RFC is being distributed to members of the Internet
in order to solicit comments on the Draft Military Supplement
While this document may not be directly relevant to the
problems of the Internet, it may be of some interest to a
of researchers and implementors. Distribution of this memor
unlimited
1.
1.1 Purpose
This document supplements the Transport Service and Protocol of
International Standards Organization (ISO), IS 8072 and IS 8073,
respectively, and their formal descriptions by providing conventions
option selections and parameter values to be used when the
is operated within the scope of the applicability statement
Paragraph 1.3 below. Paragraph 1.4, below, describes the
standards. Full implementation detail is not provided in
document, but reference is made to a separate document,
"Implementation Guide for the ISO Transport Protocol", in
guidance for implementation is given
1.2 Organization
Five sections comprise this supplement. In Section 1, the role
purpose of the Transport Protocol are stated and the
standards upon which the protocol is based are described.
documents, as well as others supporting the international
and this supplement are listed in Section 2. Other definitions
already included in the international standards and
documents are given in Section 3. The international standards
a very wide variety of network environments and situations.
is, thus, a collection of options and parameters provided by
standards which must be determined for specific uses. Section 4
states the options and parameters relevant to those
to which this supplement applies, and defines usage conventions
McCoy [Page 1]
RFC 1007 June 1987
Conventions for addressing and Transport connection
number usage and recovery of the Transport connection from
deactivation are covered in Section 5.
1.3 Application
The use of the Transport Protocol Class 4 and the Protocol
Providing the Connectionless-Mode Network Service (IS 8473)
mandatory foruse in all DOD packet-switched data networks
there is a potential for host-to-host connectivity across
or subnetwork boundaries. The term "network" as used here
include Local Area Networks but not integrated weapons systems
The use of the Transport Protocol Class 4 and IS 8473
strongly encouraged, particularly where a need for
interchangeability or survivability is perceived. Use of
Transport Protocol Class 4 and IS 8473 in weapons systems,
such usage does not diminish required performance, is
encouraged
1.4 International Standards Organization Transport Protocol
The international standard upon which this supplement is based
described in four documents
a. IS 8072, the Transport Service Definition, which defines
service that Transport provides to a user, described
English text
b. WG4 N53, the Formal Description of the Transport Service,
which the Transport Service is described using a
description language
c. IS 8073, the Transport Protocol, in which the protocol
specified in English text;
d. N123, the formal description of the Transport Protocol,
which the specification IS 8073 is written in a
description language
The ISO protocol has five classes of service, named Class 0
Class 4. Only Classes 4 and 2 will apply to this supplement.
formal description language, Estelle, DP 9074, provides for
descriptions in terms of communicating finite state automata.
contains a subset language which corresponds to the
standard Pascal. The Class 4 protocol operation when supported by
connectionless network service is described in an addendum to
8073, N3339(rev).
McCoy [Page 2]
RFC 1007 June 1987
2. REFERENCED
2.1 Issues of Documents
The following documents of the issue in effect on date of
for bids or request for proposal form a part of this supplement
the extent specified herein
FED-STD-1037 - Federal Standard - 1037,
Glossary of Telecommunication Terms
Implementation Guide for the ISO Transport
2.2 Other Publications
The following documents form part of this standard to the
specified herin. Unless otherwise indicated, the issue in effect
the date of invitation for bids or request for proposal shall apply
IS 8072 - Information Processing Systems -
Open Systems Interconnection - Transport Service Definition
Available from: ANSI ISO TC97/SC6 Secretariat 1430
New York, NY 10018 (212) 354-3343
IS 8073 - Information Processing Systems -
Open Systems Interconnection - Transport
Specification. Available from ANSI (SC6 Secretariat).
N3339(rev) - Draft Proposed Addendum to IS 8073
to Enable Class 4 Operation Over Connectionless Mode
Service as Defined in ISO/ISO 8348/AD1. Available from
(SC6 Secretariat).
DP 9074 - Estelle - A Formal
Technique Based on an Extended State Transition Model
Available from ANSI (SC21 Secretariat), address as for SC6,
above
WG4 N53 - Information Processing Systems -
Open Systems Interconnection - Formal Description of IS 8072
in Estelle. (Working draft, ISO TC 97/SC 6/WG 4)
N123 - Information Processing Systems -
Open Systems Interconnection - Formal Description of IS 8073
in Estelle. (Working draft, ISO TC 97/SC 6)
IS 8473 - Information Processing Systems -
Data Communications - Protocol for Providing
Connectionless-mode Network Service. Available from
(SC6 Secretariat).
McCoy [Page 3]
RFC 1007 June 1987
3.
3.1 Definition of terms
The definition of terms used in this standard shall comply
FED-STD-1037, ISO IS 8072, IS 8073 and IS 8473. Other terms
definitions unique to N3756, WG4 N53 and N3339(rev) appear
those documents
3.2 Abbreviations and acronyms
The following abbreviations and acronyms are used in
supplement
a. ISO. The International Standards Organization
b. OSI. Open Systems Interconnection
c. TS. Transport service
d. TSAP. Transport service access point
e. NSAP. Network service access point
f. TPDU. Transport protocol data unit
g. CR. Connect request
h. CC. Connect confirm
i. DR. Disconnect request
j. ER. Error
k. AK. Acknowledgement
l. IP. Internetwork protocol
m. LAN. Local area network
n. CONS. Connection oriented network service
o. CLNS. Connectionless network service
(Other provisions of this Section are under consideration.)
McCoy [Page 4]
RFC 1007 June 1987
4. GENERAL
4.1 Conformance
Implementations to which this supplement applies shall satisfy
conformance requirements (Clause 14, of IS 8073 and N3339(rev),
adapted for this supplement) in the following statements
a. A system claiming to implement the procedures
in this standard shall comply with the requirements
b. - d., below
b. The system shall implement
b.1 Class 2 or Class 0 or both, if operated over a
oriented network service;
b.2 Class 4 if operated over a connectionless network service
c. If the system implements Class 4, it shall also
Class 2, if it is operated over a connection oriented
service. Class 2 shall not be implemented if operation
exclusively over a connectionless network service
d. For each class which the system claims to implement,
system shall be capable of
d.1 initiating CR TPDUs or responding to CR TPDUs with
or both
d.2 responding to any other TPDU and operating
service in accordance with procedures for the class
d.3 operating all the procedures for the class listed
mandatory in the Provisions of Options table below
d.4 operating those procedures for the class, listed as
optional in the Provisions of Options table, for
conformance is claimed;
d.5 handling all TPDUs of lengths up to the lesser value of
d.5.1 the maximum length for the class
d.5.2 the maximum for which conformance is claimed
e. Claims of conformance shall state
e.1 whether or not operation over connectionless service
implemented
e.2 which class or classes of protocol are implemented,
McCoy [Page 5]
RFC 1007 June 1987
operation over a connection oriented network
implemented
e.3 whether the system is capable of initiating or
to CR TPDUs or both
e.4 which of the procedures listed in the Provisions
Options table are implemented
e.5 the maximum size of TPDU implemented; the value shall
chosen from the following list and all values in the
which are less than this maximum shall be implemented
128, 256, 512, 1024, 2048, 4096, or 8192 octets
Provision of options (adapted from IS 8073, Table 9)
__________________________________________________________________
| PROCEDURE | CLASS 2 | CLASS 4 |
|__________________________|____________________|_________________|
| | | |
|TPDU with checksum |not applicable |mandatory |
|TPDU without checksum |mandatory |optional |
|__________________________|____________________|_________________|
| | | |
|Expedited data transfer |mandatory |mandatory |
|No expedited data transfer|mandatory |mandatory |
|__________________________|____________________|_________________|
| | | |
|Flow control in Class 2 |mandatory |not applicable |
|No flow control in Class 2|optional |not applicable |
|__________________________|____________________|_________________|
| | | |
|Normal formats |mandatory |mandatory |
|Extended formats |optional |optional |
|__________________________|____________________|_________________|
The explicit manner in which implementations, to which
supplement applies, shall satisfy these conformance statements
given in Paragraph 4.4. The options are described in more detail
Paragraph 4.3.
4.2 Transport Service access parameters
Each of the services of transport has parameters that
communicating peers, express options for operation of the
connection, or transmit data from one peer user to the other.
conventions for these parameters for usage in implementations
which this supplement applies are given below
McCoy [Page 6]
RFC 1007 June 1987
4.2.1 Connect Service
The Connect Service is summarized below (refer to IS 8072
detailed discussion):
__________________________________________________________________
| Primitives Parameters |
|________________________________________________________________|
| T-CONNECT request | Called Address, |
| indication | Calling Address, |
| | Expedited Data Option, |
| | Quality of Service, |
| | TS User-Data |
|________________________________|_______________________________|
| T-CONNECT response | Responding Address, |
| confirm | Quality of Service, |
| | Expedited Data Option, |
| | TS User-Data |
|________________________________|_______________________________|
Conventions for Called Address, Calling Address and
Address will appear in Paragraph 5.1.1. Use of the
Data Option is dependent on the nature of the transport user
this supplement does not define how transport users will
on such usage. The parameters that define Quality of Service
discussed in IS 8072. However, the manner in which
parameters are to be applied in an implementation issue , and
mechanisms to be used to maintain the requested quality of
are not defined. It is thus recommended that these
not be used in implementations until such time that
definition exists. The amount of data passed in TS User-Data
constrained to 32 octets or less. (This TS User-Data
shall not be used for any data that requires any security
whatever.) No implementation is required to be able to send
data received from its user, but each implementation shall
capable of passing data received from the remote peer user
connection establishment to its user
4.2.2 Disconnect Service
__________________________________________________________________
| Primitives Parameters |
|________________________________________________________________|
| T-DISCONNECT request | TS User-Data |
|________________________________|_______________________________|
| T-DISCONNECT indication | TS User-Data, |
| | Disconnect reason |
|________________________________|_______________________________|
The Disconnect Service is abrupt in the sense that data may be
McCoy [Page 7]
RFC 1007 June 1987
whenever the service is invoked. Transport user processes
therefore ensure that all data intended to be received has in
been received before issuing a T-DISCONNECT-request. The data
in the TS User-Data parameter is constrained to be 64 octets or
in length. (The TS User-Data parameter shall not be used for
that requires any security protection whatever.) Disconnect
are discussed in IS 8073, and reasons other than those listed in
8073 are permitted
4.2.3 Data Transfer Service
__________________________________________________________________
| Primitives Parameters |
|________________________________________________________________|
| T-DATA request | TS User-Data |
| indication | |
|________________________________|_______________________________|
The length of the data that is carried by the TS User-Data
is not constrained by the ISO Standard, but interface
may impose practical limits. This is discussed further in
Implementors guide, Part 3.1. For the purposes of this supplement
the TS User-Data parameter in this service is considered to
protected and should be used for any data requiring
protection
4.2.4 Expedited Data Service
__________________________________________________________________
| Primitives Parameters |
|________________________________________________________________|
| T-EXPEDITED-DATA request | TS User-Data |
| indication | |
|________________________________|_______________________________|
The TS User-Data parameter is constrained to be no longer
16 octets and shall not be used for data requiring any
protection whatever. The T-EXPEDITED-DATA-request cannot be
whenever non-use of expedited data was called for in either
T-CONNECT-request or T-CONNECT-response primitive
4.3 Options
The protocol described in IS 8073 and N3756 permits certain
which qualify or enhance the service to be provided.
options are those which both communicating peer transport
agree upon during connection establishment. Local options are
which apply to a particular implementation of transport that
be used to enhance performance, optimize resource utilization
improve resilience to network failures. The election of a
option is invisible to the remote peer entity
McCoy [Page 8]
RFC 1007 June 1987
4.3.1 Negotiated options
The options in IS 8073 that shall be negotiated between
transport entities are given in the following list. The
of these options to be taken in an implementation to which
supplement applies are defined in Paragraph 4.4.
a. a. Class of service--agreement as to one of five classes
transport service, depending on which classes are supported
the entities, the quality of the network service available
the degree of resilience to network errors and
required by the peer transport users
b. b. Use of extended formats--agreement to use or not
extended formats for sequence numbering and flow
credit; normal formats provide sequence numbers in the range 0
- (2**7 - 1) and flow control credit in the range 0 - (2**15 -
1); extended formats provided sequence numbers in the range 0
- (2**31 - 1) and credit in the range 0 - (2**16 - 1).
c. Use of expedited data transfer--agreement to use or not to
expedited data transfer during normal data
procedures
d. Maximum size of protocol data units to be exchanged--
to limit size of exchanged protocol data units, depending
buffer resources that the entities have and network quality
service; values negotiated are in the range 2**7 - 2**13
octets (total length).
e. Use of checksum--agreement to use or not to use a 16-
checksum on each protocol data unit exchange between
entities, depending on expected residual error rate in
network service used
f. Protection parameters--agreement as to how protection will
defined and maintained on the transport connection;
parameters are defined by the communicants which elect to
them
g. Use of flow control in Class 2--agreement to use or not to
flow control in Class 2 when Class 2 operation has
negotiated. Conformance to the ISO Standard requires that
Class 4 is supported over CONS, then Class 2 shall also
supported
h. Service quality parameters--agreement as to the quality
service to be expected on the transport connection; the
Standard does not state how these parameters are to be used
the transport entities or their users
McCoy [Page 9]
RFC 1007 June 1987
4.3.2 Local options, Class 2.
The options that an implementor may decide in a particular Class 2
implementation are given in the following list.
and requirements for these options for the purposes of
this supplement are given in Paragraph 4.5.1.
a. Multiplexing on network connection--for better usage of
network resources, an implementation may elect to share
network connection among two or more transport connections
b. Acknowledgement strategy--an implementation is not required
IS 8073 to use any particular strategy for
acknowledgements for received data: each data
protocol data unit may be explicitly acknowledged (one-for
one) or may be implicitly acknowledged by a
acknowledgement (one-for-N).
c. Concatenation of protocol data units--when network
data units are large compared to the protocol data units to
sent, an implementation may elect to concatenate
protocol data units into a single network service data unit
d. Lockup prevention timer--when the wait-before-closing state
entered, there is a possibility of deadlock if the
transport entity never responds to the CR TPDU. The
provides for an optional timer to alleviate this situation
4.3.3 Local options, Class 4.
The options that an implementor may decide in a particular Class 4
implementation are given in the list below. Recommendations
requirements for use of these options in implementations to
this supplement applies are given in Paragraph 4.5.2.
a. Withdrawal of flow control credit--when supporting
connections of differing precedence or priority,
management must be practiced so as to maintain the
or priority relationships
b. Flow control confirmation--when flow control credit
reduced, extra delay may be encountered
acknowledgements carrying new flow control information
lost; this procedure aids in speeding up resynchronization
the flow control
c. Subsequenced acknowledgements--when the flow control
has been closed this procedure alleviates ambiguity due
lost or out-of-order acknowledgements
McCoy [Page 10]
RFC 1007 June 1987
d. Splitting over network connection--when operating over
connection-oriented network service, a Class 4
is permitted to use more than one network connection,
better performance and better resilience to network
failure
e. Acknowledgement strategy--an implementation is not required
the standard to use any particular strategy for
acknowledgements for received data: each data
protocol data unit may be explicitly acknowledged (one-for
one) or may be implicitly acknowledged by a
acknowledgement (one-for-N).
f. Wait-before-closing state--when a connect request has
sent to the peer and the user has requested a
before the connect confirmation has been received,
implementation may elect to wait until the confirmation
arrived before sending the disconnection request to the peer
to ensure positive identification of the connection to
released
g. Multiplexing on network connection--for better usage
network resources, an implementation may elect to share
network connection among two or more transport connections
h. Concatenation of protocol data units--when network
data units are large compared to the protocol data units to
sent, an implementation may elect to concatenate
protocol data units into a single network service data unit
i. Checksum algorithm--the Fletcher checksum algorithm
in an annex to the standard is not part of the standard and
provided for information only. The checksum algorithm
nature of network errors expected and need only satisfy
summation criterion given in the standard
j. Send network RESET when bad checksum received--it may not
possible to know with certainty which of several
connections multiplexed on a network connection is to
a protocol data unit which carries a bad checksum. A N-
or N-DISCONNECT may be sent on the network connection to
transport entities on the connection to indicate the error
k. Protocol data unit retransmission policy--protocol data
for which no acknowledgement has been received may
retransmitted in case the originals were never received
Whether to retransmit only the oldest unacknowledged
data unit or all those that are outstanding has
for buffer management in the sending entity and
utilization of the bandwidth in the network
McCoy [Page 11]
RFC 1007 June 1987
medium
4.4 Negotiations
Paragraph 4.2.1 lists those options that shall be negotiatied
communicating transport entities. Below, conventions are given
these options, in usage to which this supplement applies.
requirements reflect the conformance statement of IS 8073 and
needs of the DOD
4.4.1 Options
4.4.1.1 Class of service
a. An implementation operating on CONS shall be capable
offering Class 2 and may optionally support Class 0.
b. An implementation shall not respond by a proposal of Class 0
and shall not respond by a proposal of Class 2 if the
request was received on a CLNS
c. An implementation may offer Class 2 as an alternative class
operation in a connect request when operating over CONS.
alternative class may be offered if operation over a CLNS
d. An implementation shall respond to a connect request
proposes Class 1 or 3 as primary choice with a
request, reason code 128+2 (see p. 87 of IS 8073).
e. An implementation shall not propose Class 1 or Class 3
response to a connect request carrying Class 1 or Class 3
an alternative class of service
f. An implementation which proposes Class 4 in a connect
need not accept a proposal for Class 2 from its peer if
2 was not offered as an alternative in the connect request,
if operation is over a CLNS. Class 2 shall be accepted
proposed by the responding peer if it was offered as
alternative in the connect request
4.4.1.2 Extended formats
a. An implementation shall always propose use of extended
when either Class 4 or Class 2 is proposed in a
request
b. An implementation shall always accept the use of
formats when so proposed in a received connect request
McCoy [Page 12]
RFC 1007 June 1987
4.4.1.3 Expedited data
a. Use of expedited data is subject to negotiation by users
Transport Service
b. Expedited data shall be supported in Class 2.
4.4.1.4 Maximum protocol data unit size
(The provisions of this paragraph are under consideration.)
4.4.1.5 Use of checksum
An implementation shall propose use of checksums consistent with
expected quality of service and security requirements
a. Checksums should be used when operating with the IP
catenated networks
b. Checksums should not be used if high performance is required
except when required by high error rates in the
service
c. Checksums should always be used when any encryption is
used
4.4.1.6 Protection parameters
Use of the security parameters is not defined in this supplement
4.4.1.7 Use of flow control in Class 2.
a. An implementation shall always propose the use of flow
in Class 2 whenever Class 2 is proposed as either primary
alternative choice of service
b. An implementation shall accept use of flow control in Class 2
whenever negotiation to Class 2 occurs
4.4.1.8 Service quality parameters
a. Use of the service quality parameters in the CR and
protocol data units is not defined except for the
error rate parameter and the priority parameter
b. Residual error rate (the use of this parameter is
consideration).
McCoy [Page 13]
RFC 1007 June 1987
c. Priority (the use of this parameter is under consideration).
4.4.2 Parameters
This paragraph defines the values to be used in the CR and
TPDUs
4.4.2.1 Class 2 parameters
4.4.2.1.1 Connect request (CR) protocol data unit
4.4.2.1.1.1 Fixed part of header
a. Connect request code: as in IS 8073.
b. Initial credit allocation: this field defines the number
TPDUs offered as initial credit by the connection initiator
Since the field is of length 4, the maximum credit that
be initially offered is limited to 15. These TPDUs
constrained in length to the maximum size defined in the
size field, listed below in Paragraph 4.4.2.1.1.2.
c. Destination reference: as in IS 8073.
d. Source reference: this reference shall be selected pursuant
the provisions of Paragraph 5.2.1.
e. Class and option: the class field shall take binary
0010; the option field shall take binary value 0010. (
values select Class 2, and the options of extended formats
flow control in Class 2.)
4.4.2.1.1.2 Variable part of header
a. TSAP identifiers: the parameter values shall follow
conventions given in Paragraphs 5.1.1 and 5.1.2.
b. TPDU size: (The values to be used are under consideration.)
c. Version number: as in IS 8073.
d. Protection parameters: should not be used
e. Checksum: shall not be used
f. Additional options: this field shall take binary value 0001
the initiating user has proposed the use of expedited data
and shall take value 0000 otherwise
McCoy [Page 14]
RFC 1007 June 1987
g. Alternative protocol classes: this field shall not be
unless Class 0 is to be proposed as an alternate class
operation
h. Throughput: should not be used
i. Residual error rate: should not be used
j. Priority: (Use of this parameter is under consideration.)
k. Transit delay: should not be used
4.4.2.1.1.3 User data
The CR TPDU shall not carry user data which has any
whatever for security protection
4.4.2.1.2 Connect Confirm (CC) TPDU
4.4.2.1.2.1 Fixed part of header
a. Connect confirm code: as in IS 8073.
b. Initial credit allocation: same as Paragraph 4.4.2.1.1.1.
c. Destination reference: this reference shall be the "
reference" number from the received CR TPDU
d. Source reference: this reference shall be selected pursuant
the provisions of Paragraph 5.2.1.
e. Class and option: the class field shall take binary value 0010
and the option field shall take binary value 0010 (
Class 2 and options of extended formats and flow control
Class 2).
4.4.2.1.2.2 Variable part of header
a. TSAP identifier(s): the parameter values shall follow
conventions given in Paragraphs 5.1.1 and 5.1.2.
b. b. TPDU size: (The values for this parameter are
consideration.)
c. Version number: as in IS 8073.
d. Protection parameters: should not be used
McCoy [Page 15]
RFC 1007 June 1987
e. Checksum : shall not be used
f. Additional options: This field shall take binary value 0001
the responding transport entity has proposed the use
expedited data, and shall take binary value 0000 otherwise
g. Alternative protocol classes: shall not be used
h. Throughput: should not be used
i. Residual error rate: should not be used
j. Priority: (The use of this parameter is under consideration.)
k. Transit delay: should not be used
4.4.2.1.2.3 User data
The CC TPDU shall not carry any data which has any
whatever for security protection
4.4.2.2 Class 4 parameters
4.4.2.2.1 Connect request (CR) TPDU
4.4.2.2.1.1 Fixed part of header
a. Connect request code: as in IS 8073.
b. Initial credit allocation: this field defines the number
TPDUs offered as initial credit by the connection initiator
Since the field is of length 4, the maximum credit that can
initially offered is limited to 15. These TPDUs
constrained in length to the maximum size defined in the
size field, listed below in Paragraph 4.4.2.2.1.2.
c. Destination reference: as in IS 8073.
d. Source reference: this reference shall be selected pursuant
the provisions of Paragaph 5.2.1.
e. Class and option: the class field shall take binary
0100; the option field shall take binary value 0010. (
values select Class 4, and the options of extended
and flow control in Class 2. This latter option is ignored
the class negotiated is Class 2.)
McCoy [Page 16]
RFC 1007 June 1987
4.4.2.2.1.2 Variable part of header
a. TSAP identifiers: the parameter values shall follow
conventions given in Paragraphs 5.1.1 and 5.1.2.
b. PDU size: (The values for this parameter are
consideration.)
c. Version number: as in IS 8073.
d. Protection parameters: should not be used
e. Checksum: if Class 4 has been selected, this parameter may
used. If Class 2 (or Class) has been selected, this
shall not be used
f. Additional options: this field shall take binary value 0001
the initiating user has proposed the use of expedited data
and shall take binary value 0000 otherwise
g. Alternative protocol classes: this field shall be used only
Class 2 (or Class 0) is to be proposed as an alternate
of operation, conformant to the conditions of
4.4.1.1. If Class 2 is proposed, the field shall take
value 00000010 (1 octet).
h. Acknowledge time: should not be used
i. Throughput: should not be used
j. Residual error rate: (The use of this parameter is
consideration.)
k. Priority: (The use of this parameter is under consideration.)
l. Transit delay: should not be used
4.4.2.2.1.3 User data
The CR TPDU shall not carry user data which has any
whatever for security protection
4.4.2.2.2 Connect confirm (CC) TPDU
4.4.2.2.2.1 Fixed part of header
a. Connect confirm code: as in IS 8073.
b. Initial credit allocation: same as Paragraph 4.4.2.2.1.1.b
McCoy [Page 17]
RFC 1007 June 1987
c. Destination reference: this reference shall be the number
"Source reference" from the received CR TPDU
d. Source reference: this reference shall be selected pursuant
the provisions of Paragraph 5.2.1.
e. Class and option: if Class 2 has been selected, then the
field shall take binary value 0010 and the option field
take binary value 0010. If Class 4 has been selected,
the class field shall take binary value 0100 and the
field shall take binary value 0010.
4.4.2.2.1.2 Variable part of header
a. TSAP identifier(s): the parameters values shall follow
conventions given in Paragraphs 5.1.1 and 5.1.2.
b. TPDU size: (The values for this parameter are
consideration.)
c. Version number: as in IS 8073.
d. Protection parameters: should not be used
e. Checksum: if Class 4 has been selected, this parameter may
used. If Class 2 (or Class 0) has been selected,
parameter shall not be used
f. Additional options: if Class 4 or Class 2 has been selected
this field shall take binary value 0001 if the responding
has proposed use of expedited data and shall take binary
0000 otherwise
g. Alternate protocol classes: shall not be used
h. Acknowledgement time: should not be used
i. Throughput: should not be used
j. Residual error rate: (The use of this parameter is
consideration.)
k. Priority: (The use of this parameter is under consideration.)
l. Transit delay: should not be used
4.4.2.2.1.3 User data
The CC TPDU shall not carry user data which has any
whatever for security protection
McCoy [Page 18]
RFC 1007 June 1987
4.5 Use of local options
The paragraphs that follow give policy and guidance in the
of local options
4.5.1 Local options, Class 2.
4.5.1.1 Multiplexing
Any Class 2 connections may be multiplexed on the same
connection to the limits provided by the network service
Multiplexing Class 2 and Class 4 connections together on the
network connection is not recommended
4.5.1.2 Acknowledgement strategy
(The provisions of this paragraph are under consideration.)
4.5.1.3 Concatenation
This permits placing certain TPDUs into a single network
data unit with a data-bearing TPDU. It is useful for
the overhead of separate transmission of the individual TPDUs
4.5.1.4 Lockup prevention timer
It is strongly recommended that this timer be used for all Class 2
connections. A description of the timer has been included in
transport formal description. (This timer corresponds to
optional TS1 timer that IS 8073 recommends.)
4.5.1.5 Treatment of protocol errors
Protocol errors detected by a Class 2 transport connection
result in that connection being terminated, without sending an
TPDU
4.5.1.6 Action on receipt of Error transport protocol data unit
The receipt of an ER TPDU for a Class 2 transport connection
cause immediate termination of that transport connection
4.5.2 Local options, Class 4.
4.5.2.1 Withdrawal of flow control credit
Because of the need to serve transport connections of
levels of operating priority, an implementation shall
the withdrawal of flow control credit from any Class 4
connection as a means of managing resource allocation
Class 4 connections
McCoy [Page 19]
RFC 1007 June 1987
4.5.2.2 Flow control confirmation
The requirement to support withdrawal of flow control
strongly indicates the need to use flow control confirmation
An implementation should support and use the flow
confirmation procedures of IS 8073, consistent with quality
service and other requirements
4.5.2.3 Subsequenced acknowledgements
The possibility of credit withdrawal strongly indicates
requirement for subsequence numbers on acknowledgements.
implementation shall support and use subsequence numbers
defined in IS 8073.
4.5.2.4 Splitting over network connection
Implementations may use splitting as necessary or useful in
operating environment. (Splitting is defined only for
over a CONS
4.5.2.5 Acknowledgement strategy
(The provisions of this paragraph are under consideration.)
4.5.2.6 Wait-before-closing state
It is recommended that this state be used. A lockup
timer, such as used in Class 2, is not necessary, since the
TPDU retransmission timer serves this purpose
4.5.2.7 Multiplexing on network connection
Multiplexing of Class 4 connections on a single
connection may be used as necessary or useful, within the
permitted by the network service. Class 4 connections should
be multiplexed onto network connections serving Class 2
connections
4.5.2.8 Concatenation of protocol data units
Concatenation may be useful when operating over a CLNS that
large capacity service data units. Concatenation on
that areconnection-oriented may be useful if
connections are being multiplexed. A careful analysis of
treatment of the network service data unit in
environments should be done to determine whether
of TPDUs provides sufficient benefit to justify its usage
those circumstances
McCoy [Page 20]
RFC 1007 June 1987
4.5.2.9 Checksum algorithm
It is strongly recommended that the algorithm described in
Implementors Guide Part 7, be used rather than the
given in the Annex to IS 8073. The algorithm in Part 7
computes the same checksum as the one in IS 8073 but has
optimized. Guidance on the use and non-use of checksum
given in the Implementors Guide, Part 7.
4.5.2.10 Send network RESET when bad checksum received
It is recommended that only an N-RESET be sent when
a TPDU with a bad checksum on a CONS. An implementation
not send an N-DISCONNECT-request in such situations, since
TPDU with the bad checksum may have come from some
intending to interfere with communications. When
Class 4 over a CLNS, no action shall be taken on the receipt
a TPDU with a bad checksum, i.e., the TPDU shall be discarded
4.5.2.11 Protocol data unit retransmission policy
(The provisions of this paragraph are under consideration.)
4.5.2.12 Treatment of protocol errors
In Class 4, a protocol error arising from a TPDU
unrecognized parameters shall cause a DR TPDU to be sent to
sender, if the TPDU is otherwise valid. All other erroneous
shall be discarded
4.5.2.13 Action on receipt of Error transport protocol data unit
If an ER TPDU is received from a remote transport entity,
implementation to which this supplement applies shall release
transport connection with which the ER TPDU is associated, if
association can be made. When association cannot be made, the
TPDU shall be discarded
5. SPECIAL
5.1 Addressing conventions
(The provisions of Paragraph 5.1 and its subparagraphs are
consideration.)
5.1.1 Transport Service Access Point
5.1.2 Connect-request/confirm protocol data units
5.1.3 Network Service Access Point
McCoy [Page 21]
RFC 1007 June 1987
5.2 Convention for use of transport connection reference numbers
The ISO Transport Protocol provides for freezing reference
by means of a timer, so that re-use of a reference number does
cause ambiguity in communications. However, certain
are imposed on DOD implementations, so that this means of
number control is inadequate alone. The ISO standard defines
those actions to be followed if a timer is used. Other means
reference number control are not prohibited, providing that
minimum freeze time, as defined in IS 8073, is exceeded for
reference number used
5.2.1 Specification of convention
An implementation adhering to the applications definitions
this supplement, Paragraph 1.3, shall not re-use a
connection reference number until the set of available
numbers has recycled to that point. Expressed more formally
if all reference numbers are defined to be within the
[1,N] and a reference number R in this interval is used,
R shall be prohibited from being selected again until all
numbers R+1,...,N,1,2,...,R-1 shall have been used. The
of N should be sufficiently large that the expected recycle
exceeds the minimum freeze time as specified in IS 8073.
requirement is in addition to and does not supersede the
requirement of IS 8073. A simple means of implementing
convention is given in Part 9.3 of the Implementors Guide
5.3 Operation over connectionless network service
Implementations to which this supplement applies are required
operate over connectionless network services in addition to
able to operate over connection-oriented network services. The
standard specifies transport only for operation over
connection-oriented network. However, the specification for
4 has been written in such a way that use with
network service is not precluded. The formal description
even more flexibility in this regard. Consequently, operation
connectionless network services, whether a LAN or IP, is
an implementation issue for Class 4. Operation of Class 2
transportover a connectionless network service is not
to be a reasonable option because of the lack of sufficent
recovery in Class 2. For the purposes of this supplement
operation of Class 2 on a connectionless network service
not recommended. Operation of Class 4 over a
network service is discussed further in parts 1.2.2.2, 3.4,
and 6 of the accompanying Implementors Guide
McCoy [Page 22]
RFC 1007 June 1987
5.4 Recovery from peer deactivation
The ISO Standard does not provide for re-establishment of
transport connection when one of the communicating peers
deactivated ("crashes"). However, the state tables for
4 transport in Annex A to IS 8073 are flexible enough
simple adaptations in an implementation can yield some
of crash recovery without change to the protocol.
adaptations are discussed in Part 9.2 of the Implementors Guide
McCoy [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
