Network Working Group Wayne McCoy Request for Comments: 1007 June 1987
TO THE
ISO TRANSPORT PROTOCOL
This RFC is being distributed to members of the Internet community in order to solicit comments on the Draft Military Supplement. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors. Distribution of this memor is unlimited.
This document supplements the Transport Service and Protocol of the 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 protocol is operated within the scope of the applicability statement in Paragraph 1.3 below. Paragraph 1.4, below, describes the ISO standards. Full implementation detail is not provided in this document, but reference is made to a separate document, entitled "Implementation Guide for the ISO Transport Protocol", in which guidance for implementation is given.
Five sections comprise this supplement. In Section 1, the role and purpose of the Transport Protocol are stated and the international standards upon which the protocol is based are described. These documents, as well as others supporting the international standards and this supplement are listed in Section 2. Other definitions not already included in the international standards and supporting documents are given in Section 3. The international standards cover a very wide variety of network environments and situations. There is, thus, a collection of options and parameters provided by the standards which must be determined for specific uses. Section 4 states the options and parameters relevant to those implementations to which this supplement applies, and defines usage conventions.
Conventions for addressing and Transport connection reference number usage and recovery of the Transport connection from peer deactivation are covered in Section 5.
The use of the Transport Protocol Class 4 and the Protocol for
Providing the Connectionless-Mode Network Service (IS 8473) is
mandatory foruse in all DOD packet-switched data networks where
there is a potential for host-to-host connectivity across network
or subnetwork boundaries. The term "network" as used here shall
include Local Area Networks but not integrated weapons systems.
The use of the Transport Protocol Class 4 and IS 8473 is
strongly encouraged, particularly where a need for equipment
interchangeability or survivability is perceived. Use of the
Transport Protocol Class 4 and IS 8473 in weapons systems, where
such usage does not diminish required performance, is also
encouraged.
The international standard upon which this supplement is based is described in four documents:
The ISO protocol has five classes of service, named Class 0 through Class 4. Only Classes 4 and 2 will apply to this supplement. The formal description language, Estelle, DP 9074, provides for protocol descriptions in terms of communicating finite state automata. It contains a subset language which corresponds to the international standard Pascal. The Class 4 protocol operation when supported by a connectionless network service is described in an addendum to IS 8073, N3339(rev).
The following documents of the issue in effect on date of invitation for bids or request for proposal form a part of this supplement to the extent specified herein.
FED-STD-1037 - Federal Standard - 1037,
Glossary of Telecommunication Terms.
Implementation Guide for the ISO Transport Protocol
The following documents form part of this standard to the extent specified herin. Unless otherwise indicated, the issue in effect on 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 Broadway
New York, NY 10018 (212) 354-3343
IS 8073 - Information Processing Systems -
Open Systems Interconnection - Transport Protocol
Specification. Available from ANSI (SC6 Secretariat).
N3339(rev) - Draft Proposed Addendum to IS 8073
to Enable Class 4 Operation Over Connectionless Mode Network
Service as Defined in ISO/ISO 8348/AD1. Available from ANSI
(SC6 Secretariat).
DP 9074 - Estelle - A Formal Description
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 the
Connectionless-mode Network Service. Available from ANSI
(SC6 Secretariat).
The definition of terms used in this standard shall comply with FED-STD-1037, ISO IS 8072, IS 8073 and IS 8473. Other terms and definitions unique to N3756, WG4 N53 and N3339(rev) appear in those documents.
The following abbreviations and acronyms are used in this supplement:
(Other provisions of this Section are under consideration.)
Implementations to which this supplement applies shall satisfy the conformance requirements (Clause 14, of IS 8073 and N3339(rev), as adapted for this supplement) in the following statements.
operation over a connection oriented network is 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 this supplement applies, shall satisfy these conformance statements is given in Paragraph 4.4. The options are described in more detail in Paragraph 4.3.
Each of the services of transport has parameters that identify communicating peers, express options for operation of the transport connection, or transmit data from one peer user to the other. The conventions for these parameters for usage in implementations to which this supplement applies are given below.
The Connect Service is summarized below (refer to IS 8072 for 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 Responding Address will appear in Paragraph 5.1.1. Use of the Expedited Data Option is dependent on the nature of the transport user; this supplement does not define how transport users will decide on such usage. The parameters that define Quality of Service are discussed in IS 8072. However, the manner in which these parameters are to be applied in an implementation issue , and the mechanisms to be used to maintain the requested quality of sevice are not defined. It is thus recommended that these parameters not be used in implementations until such time that usage definition exists. The amount of data passed in TS User-Data is constrained to 32 octets or less. (This TS User-Data parameter shall not be used for any data that requires any security protection whatever.) No implementation is required to be able to send such data received from its user, but each implementation shall be capable of passing data received from the remote peer user during connection establishment to its user.
__________________________________________________________________
| 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 lost
whenever the service is invoked. Transport user processes should therefore ensure that all data intended to be received has in fact been received before issuing a T-DISCONNECT-request. The data used in the TS User-Data parameter is constrained to be 64 octets or less in length. (The TS User-Data parameter shall not be used for data that requires any security protection whatever.) Disconnect reasons are discussed in IS 8073, and reasons other than those listed in IS 8073 are permitted.
| Primitives Parameters | |________________________________________________________________| | T-DATA request | TS User-Data | | indication | | |________________________________|_______________________________|
The length of the data that is carried by the TS User-Data parameter is not constrained by the ISO Standard, but interface considerations may impose practical limits. This is discussed further in the Implementors guide, Part 3.1. For the purposes of this supplement, the TS User-Data parameter in this service is considered to be protected and should be used for any data requiring security protection.
__________________________________________________________________
| Primitives Parameters | |________________________________________________________________| | T-EXPEDITED-DATA request | TS User-Data | | indication | | |________________________________|_______________________________|
The TS User-Data parameter is constrained to be no longer than 16 octets and shall not be used for data requiring any security protection whatever. The T-EXPEDITED-DATA-request cannot be used whenever non-use of expedited data was called for in either the T-CONNECT-request or T-CONNECT-response primitive.
The protocol described in IS 8073 and N3756 permits certain options which qualify or enhance the service to be provided. Negotiated options are those which both communicating peer transport entities agree upon during connection establishment. Local options are those which apply to a particular implementation of transport that may be used to enhance performance, optimize resource utilization or improve resilience to network failures. The election of a local option is invisible to the remote peer entity.
The options in IS 8073 that shall be negotiated between peer transport entities are given in the following list. The elections of these options to be taken in an implementation to which this supplement applies are defined in Paragraph 4.4.
- (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).
The options that an implementor may decide in a particular Class 2 implementation are given in the following list. Recommendations and requirements for these options for the purposes of this this supplement are given in Paragraph 4.5.1.
The options that an implementor may decide in a particular Class 4 implementation are given in the list below. Recommendations and requirements for use of these options in implementations to which this supplement applies are given in Paragraph 4.5.2.
medium.
Paragraph 4.2.1 lists those options that shall be negotiatied by communicating transport entities. Below, conventions are given for these options, in usage to which this supplement applies. These requirements reflect the conformance statement of IS 8073 and the needs of the DOD.
(The provisions of this paragraph are under consideration.)
An implementation shall propose use of checksums consistent with the expected quality of service and security requirements.
Use of the security parameters is not defined in this supplement.
This paragraph defines the values to be used in the CR and CC TPDUs.
The CR TPDU shall not carry user data which has any requirement whatever for security protection.
The CC TPDU shall not carry any data which has any requirement whatever for security protection.
The CR TPDU shall not carry user data which has any requirement whatever for security protection.
The CC TPDU shall not carry user data which has any requirement whatever for security protection.
The paragraphs that follow give policy and guidance in the election of local options.
Any Class 2 connections may be multiplexed on the same network connection to the limits provided by the network service. Multiplexing Class 2 and Class 4 connections together on the same network connection is not recommended.
(The provisions of this paragraph are under consideration.)
This permits placing certain TPDUs into a single network service data unit with a data-bearing TPDU. It is useful for reducing the overhead of separate transmission of the individual TPDUs.
It is strongly recommended that this timer be used for all Class 2 connections. A description of the timer has been included in the transport formal description. (This timer corresponds to the optional TS1 timer that IS 8073 recommends.)
Protocol errors detected by a Class 2 transport connection shall result in that connection being terminated, without sending an ER TPDU.
The receipt of an ER TPDU for a Class 2 transport connection shall cause immediate termination of that transport connection.
Because of the need to serve transport connections of various levels of operating priority, an implementation shall support the withdrawal of flow control credit from any Class 4 transport connection as a means of managing resource allocation among Class 4 connections.
The requirement to support withdrawal of flow control credit strongly indicates the need to use flow control confirmation. An implementation should support and use the flow control confirmation procedures of IS 8073, consistent with quality of service and other requirements.
The possibility of credit withdrawal strongly indicates the requirement for subsequence numbers on acknowledgements. An implementation shall support and use subsequence numbers as defined in IS 8073.
Implementations may use splitting as necessary or useful in the operating environment. (Splitting is defined only for operation over a CONS.
(The provisions of this paragraph are under consideration.)
It is recommended that this state be used. A lockup prevention timer, such as used in Class 2, is not necessary, since the CR TPDU retransmission timer serves this purpose.
Multiplexing of Class 4 connections on a single network
connection may be used as necessary or useful, within the limits
permitted by the network service. Class 4 connections should not
be multiplexed onto network connections serving Class 2 transport
connections.
Concatenation may be useful when operating over a CLNS that has
large capacity service data units. Concatenation on networks
that areconnection-oriented may be useful if transport
connections are being multiplexed. A careful analysis of the
treatment of the network service data unit in internetwork
environments should be done to determine whether concatenation
of TPDUs provides sufficient benefit to justify its usage in
those circumstances.
It is strongly recommended that the algorithm described in the
Implementors Guide Part 7, be used rather than the algorithm
given in the Annex to IS 8073. The algorithm in Part 7
computes the same checksum as the one in IS 8073 but has been
optimized. Guidance on the use and non-use of checksum is
given in the Implementors Guide, Part 7.
It is recommended that only an N-RESET be sent when encountering a TPDU with a bad checksum on a CONS. An implementation shall not send an N-DISCONNECT-request in such situations, since the TPDU with the bad checksum may have come from some entity intending to interfere with communications. When operating Class 4 over a CLNS, no action shall be taken on the receipt of a TPDU with a bad checksum, i.e., the TPDU shall be discarded.
(The provisions of this paragraph are under consideration.)
In Class 4, a protocol error arising from a TPDU containing unrecognized parameters shall cause a DR TPDU to be sent to the sender, if the TPDU is otherwise valid. All other erroneous TPDUs shall be discarded.
If an ER TPDU is received from a remote transport entity, an implementation to which this supplement applies shall release the transport connection with which the ER TPDU is associated, if such association can be made. When association cannot be made, the ER TPDU shall be discarded.
(The provisions of Paragraph 5.1 and its subparagraphs are under consideration.)
The ISO Transport Protocol provides for freezing reference numbers by means of a timer, so that re-use of a reference number does not cause ambiguity in communications. However, certain requirements are imposed on DOD implementations, so that this means of reference number control is inadequate alone. The ISO standard defines only those actions to be followed if a timer is used. Other means of reference number control are not prohibited, providing that the minimum freeze time, as defined in IS 8073, is exceeded for each reference number used.
An implementation adhering to the applications definitions in this supplement, Paragraph 1.3, shall not re-use a transport connection reference number until the set of available reference numbers has recycled to that point. Expressed more formally, if all reference numbers are defined to be within the interval [1,N] and a reference number R in this interval is used, then R shall be prohibited from being selected again until all the numbers R+1,...,N,1,2,...,R-1 shall have been used. The choice of N should be sufficiently large that the expected recycle period exceeds the minimum freeze time as specified in IS 8073. This requirement is in addition to and does not supersede the freeze requirement of IS 8073. A simple means of implementing this convention is given in Part 9.3 of the Implementors Guide.
Implementations to which this supplement applies are required to
operate over connectionless network services in addition to being
able to operate over connection-oriented network services. The ISO
standard specifies transport only for operation over a
connection-oriented network. However, the specification for Class
4 has been written in such a way that use with connectionless
network service is not precluded. The formal description offers
even more flexibility in this regard. Consequently, operation over
connectionless network services, whether a LAN or IP, is primarily
an implementation issue for Class 4. Operation of Class 2
transportover a connectionless network service is not considered
to be a reasonable option because of the lack of sufficent error
recovery in Class 2. For the purposes of this supplement,
operation of Class 2 on a connectionless network service is
not recommended. Operation of Class 4 over a connectionless
network service is discussed further in parts 1.2.2.2, 3.4,
and 6 of the accompanying Implementors Guide.
The ISO Standard does not provide for re-establishment of the
transport connection when one of the communicating peers is
deactivated ("crashes"). However, the state tables for Class
4 transport in Annex A to IS 8073 are flexible enough that
simple adaptations in an implementation can yield some degree
of crash recovery without change to the protocol. These
adaptations are discussed in Part 9.2 of the Implementors Guide.