doc: Add RFC documents

1 files changed, 1355 insertions, 0 deletions

diff --git a/doc/rfc/rfc1007.txt b/doc/rfc/rfc1007.txt
new file mode 100644
index 0000000..918db13
--- /dev/null
+++ b/doc/rfc/rfc1007.txt
@@ -0,0 +1,1355 @@
+
+Network Working Group                                         Wayne McCoy
+Request for Comments: 1007                                       June 1987
+
+
+
+                         MILITARY SUPPLEMENT
+
+                               TO THE
+
+                       ISO TRANSPORT PROTOCOL
+
+
+Status of this Memo
+
+   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.
+
+
+1. SCOPE
+
+1.1   Purpose.
+
+   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.
+
+1.2  Organization.
+
+   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.
+
+
+
+McCoy                                                           [Page 1]
+
+RFC 1007                                                       June 1987
+
+
+   Conventions for addressing and Transport connection reference
+   number usage and recovery of the Transport connection from peer
+   deactivation are covered in Section 5.
+
+1.3   Application.
+
+   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.
+
+1.4   International Standards Organization Transport Protocol.
+
+   The international standard upon which this supplement is based is
+   described in four documents:
+
+       a. IS 8072, the Transport Service Definition, which defines the
+          service that Transport provides to a user, described in
+          English text;
+
+       b. WG4 N53, the Formal Description of the Transport Service, in
+          which the Transport Service is described using a formal
+          description language;
+
+       c. IS 8073, the Transport Protocol, in which the protocol is
+          specified in English text; and
+
+       d. N123, the formal description of the Transport Protocol, in
+          which the specification IS 8073 is written in a formal
+          description language.
+
+   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).
+
+
+
+
+
+
+
+McCoy                                                           [Page 2]
+
+RFC 1007                                                       June 1987
+
+
+2.  REFERENCED DOCUMENTS
+
+2.1  Issues of Documents.
+
+   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
+
+2.2  Other Publications.
+
+   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).
+
+
+
+
+McCoy                                                           [Page 3]
+
+RFC 1007                                                       June 1987
+
+
+3. DEFINITIONS
+
+3.1   Definition of terms.
+
+   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.
+
+3.2   Abbreviations and acronyms.
+
+   The following abbreviations and acronyms are used in this
+   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 REQUIREMENTS
+
+4.1   Conformance.
+
+   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.
+
+     a.  A system claiming to implement the procedures specified
+         in this standard shall comply with the requirements in
+         b. - d., below.
+
+     b.  The system shall implement:
+
+         b.1  Class 2 or Class 0 or both, if operated over a connection
+              oriented network service; or
+
+         b.2  Class 4 if operated over a connectionless network service.
+
+     c.  If the system implements Class 4, it shall also implement
+         Class 2, if it is operated over a connection oriented network
+         service.  Class 2 shall not be implemented if operation is
+         exclusively over a connectionless network service.
+
+     d.  For each class which the system claims to implement, the
+         system shall be capable of:
+         d.1  initiating CR TPDUs or responding to CR TPDUs with TPDUs
+              or both;
+
+         d.2  responding to any other TPDU and operating network
+              service in accordance with procedures for the class;
+
+         d.3  operating all the procedures for the class listed as
+              mandatory in the Provisions of Options table below;
+
+         d.4  operating those procedures for the class, listed as as
+              optional in the Provisions of Options table, for which
+              conformance is claimed; and
+
+         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 is
+              implemented;
+
+         e.2  which class or classes of protocol are implemented, if
+
+
+
+McCoy                                                           [Page 5]
+
+RFC 1007                                                       June 1987
+
+
+              operation over a connection oriented network is
+              implemented;
+
+         e.3  whether the system is capable of initiating or responding
+              to CR TPDUs or both;
+
+         e.4  which of the procedures listed in the Provisions of
+              Options table are implemented;
+
+         e.5  the maximum size of TPDU implemented; the value shall be
+              chosen from the following list and all values in the list
+              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 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.
+
+4.2   Transport Service access parameters.
+
+   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.
+
+
+
+
+
+McCoy                                                           [Page 6]
+
+RFC 1007                                                       June 1987
+
+
+4.2.1   Connect Service.
+
+   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.
+
+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 lost
+
+
+
+McCoy                                                           [Page 7]
+
+RFC 1007                                                       June 1987
+
+
+   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.
+
+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 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.
+
+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 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.
+
+4.3   Options.
+
+   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.
+
+
+
+
+McCoy                                                           [Page 8]
+
+RFC 1007                                                       June 1987
+
+
+4.3.1  Negotiated options.
+
+   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.
+
+
+     a.   a. Class of service--agreement as to one of five classes of
+          transport service, depending on which classes are supported by
+          the entities, the quality of the network service available and
+          the degree of resilience to network errors and failure
+          required by the peer transport users.
+
+     b.   b. Use of extended formats--agreement to use or not use
+          extended formats for sequence numbering and flow control
+          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 use
+          expedited data transfer during normal data transfer
+          procedures.
+
+     d.   Maximum size of protocol data units to be exchanged--agreement
+          to limit size of exchanged protocol data units, depending on
+          buffer resources that the entities have and network quality of
+          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-bit
+          checksum on each protocol data unit exchange between the
+          entities, depending on expected residual error rate in the
+          network service used.
+
+     f.   Protection parameters--agreement as to how protection will be
+          defined and maintained on the transport connection; these
+          parameters are defined by the communicants which elect to use
+          them.
+
+     g.   Use of flow control in Class 2--agreement to use or not to use
+          flow control in Class 2 when Class 2 operation has been
+          negotiated. Conformance to the ISO Standard requires that if
+          Class 4 is supported over CONS, then Class 2 shall also be
+          supported.
+
+     h.   Service quality parameters--agreement as to the quality of
+          service to be expected on the transport connection; the ISO
+          Standard does not state how these parameters are to be used by
+          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.  Recommendations
+   and requirements for these options for the purposes of this
+   this supplement are given in Paragraph 4.5.1.
+
+
+     a.   Multiplexing on network connection--for better usage of of
+          network resources, an implementation may elect to share a
+          network connection among two or more transport connections.
+
+     b.   Acknowledgement strategy--an implementation is not required by
+          IS 8073 to use any particular strategy for sending
+          acknowledgements for received data:  each data transfer
+          protocol data unit may be explicitly acknowledged (one-for-
+          one) or may be implicitly acknowledged by a group
+          acknowledgement (one-for-N).
+
+     c.   Concatenation of protocol data units--when network service
+          data units are large compared to the protocol data units to be
+          sent, an implementation may elect to concatenate these
+          protocol data units into a single network service data unit.
+
+     d.   Lockup prevention timer--when the wait-before-closing state is
+          entered, there is a possibility of deadlock if the peer
+          transport entity never responds to the CR TPDU.  The standard
+          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 and
+   requirements for use of these options in implementations to which
+   this supplement applies are given in Paragraph 4.5.2.
+
+
+     a.   Withdrawal of flow control credit--when supporting several
+          connections of differing precedence or priority, resource
+          management must be practiced so as to maintain the precedence
+          or priority relationships.
+
+     b.   Flow control confirmation--when flow control credit is
+          reduced, extra delay may be encountered because
+          acknowledgements carrying new flow control information are
+          lost; this procedure aids in speeding up resynchronization of
+          the flow control.
+
+     c.   Subsequenced acknowledgements--when the flow control window
+          has been closed this procedure alleviates ambiguity due to
+          lost or out-of-order acknowledgements.
+
+
+
+McCoy                                                          [Page 10]
+
+RFC 1007                                                       June 1987
+
+
+     d.   Splitting over network connection--when operating over a
+          connection-oriented network service, a Class 4 implementation
+          is permitted to use more than one network connection, for
+          better performance and better resilience to network connection
+          failure.
+
+     e.   Acknowledgement strategy--an implementation is not required by
+          the standard to use any particular strategy for sending
+          acknowledgements for received data:  each data transfer
+          protocol data unit may be explicitly acknowledged (one-for-
+          one) or may be implicitly acknowledged by a group
+          acknowledgement (one-for-N).
+
+     f.   Wait-before-closing state--when a connect request has been
+          sent to the peer and the user has requested a disconnection
+          before the connect confirmation has been received, an
+          implementation may elect to wait until the confirmation has
+          arrived before sending the disconnection request to the peer,
+          to ensure positive identification of the connection to be
+          released.
+
+     g.   Multiplexing on network connection--for better usage of
+          network resources, an implementation may elect to share a
+          network connection among two or more transport connections.
+
+
+     h.   Concatenation of protocol data units--when network service
+          data units are large compared to the protocol data units to be
+          sent, an implementation may elect to concatenate these
+          protocol data units into a single network service data unit.
+
+     i.   Checksum algorithm--the Fletcher checksum algorithm provided
+          in an annex to the standard is not part of the standard and is
+          provided for information only.  The checksum algorithm used
+          nature of network errors expected and need only satisfy the
+          summation criterion given in the standard.
+
+     j.   Send network RESET when bad checksum received--it may not be
+          possible to know with certainty which of several transport
+          connections multiplexed on a network connection is to receive
+          a protocol data unit which carries a bad checksum.  A N-RESET
+          or N-DISCONNECT may be sent on the network connection to all
+          transport entities on the connection to indicate the error.
+
+     k.   Protocol data unit retransmission policy--protocol data units
+          for which no acknowledgement has been received may be
+          retransmitted in case the originals were never received.
+          Whether to retransmit only the oldest unacknowledged protocol
+          data unit or all those that are outstanding has implications
+          for buffer management in the sending entity and for
+          utilization of the bandwidth in the network transmission
+
+
+
+McCoy                                                          [Page 11]
+
+RFC 1007                                                       June 1987
+
+
+          medium.
+
+
+4.4   Negotiations.
+
+   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.
+
+4.4.1   Options.
+
+4.4.1.1   Class of service.
+
+     a.   An implementation operating on CONS shall be capable of
+          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 connect
+          request was received on a CLNS.
+
+     c.   An implementation may offer Class 2 as an alternative class of
+          operation in a connect request when operating over CONS. No
+          alternative class may be offered if operation over a CLNS.
+
+     d.   An implementation shall respond to a connect request that
+          proposes Class 1 or 3 as primary choice with a disconnect
+          request, reason code 128+2 (see p. 87 of IS 8073).
+
+     e.   An implementation shall not propose Class 1 or Class 3 in
+          response to a connect request carrying Class 1 or Class 3 as
+          an alternative class of service.
+
+     f.   An implementation which proposes Class 4 in a connect request
+          need not accept a proposal for Class 2 from its peer if Class
+          2 was not offered as an alternative in the connect request, or
+          if operation is over a CLNS. Class 2 shall be accepted when
+          proposed by the responding peer if it  was offered as an
+          alternative in the connect request.
+
+4.4.1.2   Extended formats.
+
+     a.   An implementation shall always propose use of extended formats
+          when either Class 4 or Class 2 is proposed in a connect
+          request.
+
+     b.   An implementation shall always accept the use of extended
+          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 of
+          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 the
+   expected quality of service and security requirements.
+
+
+     a.   Checksums should be used when operating with the IP on
+          catenated networks.
+
+     b.   Checksums should not be used if high performance is required,
+          except when required by high error rates in the network
+          service.
+
+     c.   Checksums should always be used when any encryption is being
+          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 control
+          in Class 2 whenever Class 2 is proposed as either primary or
+          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 CC
+          protocol data units is not defined except for the residual
+          error rate parameter and the priority parameter.
+
+     b.   Residual error rate (the use of this parameter is under
+          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 CC
+          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 of
+          TPDUs offered as initial credit by the connection initiator.
+          Since the field is of length  4, the maximum credit that can
+          be initially offered is limited to 15.  These TPDUs are
+          constrained in length to the maximum size defined in the TPDU
+          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 to
+          the provisions of Paragraph 5.2.1.
+
+     e.   Class and option: the class field shall take binary value
+          0010; the option field shall take binary value 0010. (These
+          values select Class 2, and the options of extended formats and
+          flow control in Class 2.)
+
+
+4.4.2.1.1.2   Variable part of header.
+
+
+     a.   TSAP identifiers: the parameter values shall follow the
+          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 if
+          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 used
+          unless Class 0 is to be proposed as an alternate class of
+          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 requirement
+   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 "Source
+          reference" number from the received CR TPDU.
+
+     d.   Source reference: this reference shall be selected pursuant to
+          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 (selects
+          Class 2 and options of extended formats and flow control in
+          Class 2).
+
+
+4.4.2.1.2.2   Variable part of header.
+
+
+     a.   TSAP identifier(s): the parameter values shall follow the
+          conventions given in Paragraphs 5.1.1 and 5.1.2.
+
+     b.   b. TPDU size: (The values for this parameter are under
+          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 if
+          the responding transport entity has proposed the use of
+          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 requirement
+     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 of
+          TPDUs offered as initial credit by the connection initiator.
+          Since the field is of length 4, the maximum credit that can be
+          initially offered is limited to 15. These TPDUs are
+          constrained in length to the maximum size defined in the TPDU
+          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 to
+          the provisions of Paragaph 5.2.1.
+
+     e.   Class and option: the class field shall take binary value
+          0100; the option field shall take binary value 0010. (These
+          values select Class 4, and the options  of extended formats
+          and flow control in Class 2.  This latter option is ignored if
+          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 the
+          conventions given in Paragraphs 5.1.1 and 5.1.2.
+
+     b.   PDU size: (The values for this parameter are under
+          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 be
+          used.  If Class 2 (or Class) has been selected, this parameter
+          shall not be used.
+
+     f.   Additional options: this field shall take binary value 0001 if
+          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 if
+          Class 2 (or Class 0) is to be proposed as an alternate class
+          of operation, conformant to the conditions of Paragraph
+          4.4.1.1.  If Class 2 is proposed, the field shall take binary
+          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 under
+          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 requirement
+     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 in
+          "Source reference" from the received CR TPDU.
+
+     d.   Source reference: this reference shall be selected pursuant to
+          the provisions of Paragraph 5.2.1.
+
+     e.   Class and option: if Class 2 has been selected, then the class
+          field shall take binary value 0010 and the option field shall
+          take binary value 0010.  If Class 4 has been selected, then
+          the class field shall take binary value 0100 and the option
+          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 the
+          conventions given in Paragraphs 5.1.1 and 5.1.2.
+
+     b.   TPDU size: (The values for this parameter are under
+          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 be
+          used. If Class 2 (or Class 0) has been selected, this
+          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 user
+          has proposed use of expedited data and shall take binary value
+          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 under
+          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 requirement
+   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 election
+   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 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.
+
+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 service
+   data unit with a data-bearing TPDU.  It is useful for reducing
+   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 the
+   transport formal description.  (This timer corresponds to the
+   optional TS1 timer that IS 8073 recommends.)
+
+4.5.1.5   Treatment of protocol errors.
+
+   Protocol errors detected by a Class 2 transport connection shall
+   result in that connection being terminated, without sending an ER
+   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 shall
+   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 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.
+
+
+
+McCoy                                                          [Page 19]
+
+RFC 1007                                                       June 1987
+
+
+4.5.2.2   Flow control confirmation.
+
+   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.
+
+4.5.2.3   Subsequenced acknowledgements.
+
+   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.
+
+4.5.2.4   Splitting over network connection.
+
+   Implementations may use splitting as necessary or useful in the
+   operating environment. (Splitting is defined only for operation
+   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 prevention
+   timer, such as used in Class 2, is not necessary, since the CR
+   TPDU retransmission timer serves this purpose.
+
+4.5.2.7   Multiplexing on network connection.
+
+   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.
+
+4.5.2.8   Concatenation of protocol data units.
+
+   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.
+
+
+
+
+
+McCoy                                                          [Page 20]
+
+RFC 1007                                                       June 1987
+
+
+4.5.2.9   Checksum algorithm.
+
+   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.
+
+4.5.2.10   Send network RESET when bad checksum received.
+
+
+   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.
+
+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 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.
+
+4.5.2.13   Action on receipt of Error transport protocol data unit.
+
+   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.
+
+5. SPECIAL REQUIREMENTS
+
+5.1   Addressing conventions.
+
+   (The provisions of Paragraph 5.1 and its subparagraphs are under
+   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 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.
+
+5.2.1   Specification of convention.
+
+   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.
+
+5.3  Operation over connectionless network service.
+
+   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.
+
+
+
+
+
+
+
+McCoy                                                          [Page 22]
+
+RFC 1007                                                       June 1987
+
+
+5.4   Recovery from peer deactivation.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCoy                                                          [Page 23]
+