<pre>Network Working Group                                         Wayne McCoy
Request for Comments: 1007                                       June 1987



                         <span class="h1">MILITARY SUPPLEMENT</span>

                               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.


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. SCOPE</span>

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>   Purpose.</span>

   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.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>  Organization.</span>

   Five sections comprise this supplement.  In <a href="#section-1">Section 1</a>, 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  <a href="#section-2">Section 2</a>.  Other definitions not
   already included in the international standards and supporting
   documents are given in <a href="#section-3">Section 3</a>.  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.  <a href="#section-4">Section 4</a>
   states the options and parameters relevant to those implementations
   to which this supplement applies, and defines usage conventions.



<span class="grey">McCoy                                                           [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


   Conventions for addressing and Transport connection reference
   number usage and recovery of the Transport connection from peer
   deactivation are covered in <a href="#section-5">Section 5</a>.

<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>   Application.</span>

   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.

<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>   International Standards Organization Transport Protocol.</span>

   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).







<span class="grey">McCoy                                                           [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  REFERENCED DOCUMENTS</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>  Issues of Documents.</span>

   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

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>  Other Publications.</span>

   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).




<span class="grey">McCoy                                                           [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. DEFINITIONS</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>   Definition of terms.</span>

   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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>   Abbreviations and acronyms.</span>

   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.)









<span class="grey">McCoy                                                           [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. GENERAL REQUIREMENTS</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>   Conformance.</span>

   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



<span class="grey">McCoy                                                           [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


              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.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>   Transport Service access parameters.</span>

   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.





<span class="grey">McCoy                                                           [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>   Connect Service.</span>

   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.

<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>   Disconnect Service.</span>

   __________________________________________________________________
   |             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



<span class="grey">McCoy                                                           [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


   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.

<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>   Data Transfer Service.</span>
<span class="h4">   __________________________________________________________________</span>
   |             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.

<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>   Expedited Data Service.</span>

   __________________________________________________________________
   |               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.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>   Options.</span>

   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.




<span class="grey">McCoy                                                           [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>  Negotiated options.</span>

   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.



<span class="grey">McCoy                                                           [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>   Local options, Class 2.</span>

   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.

<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>   Local options, Class 4.</span>

   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.



<span class="grey">McCoy                                                          [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


     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



<span class="grey">McCoy                                                          [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


          medium.


<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>   Negotiations.</span>

   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.

<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>   Options.</span>

<span class="h5"><a class="selflink" id="section-4.4.1.1" href="#section-4.4.1.1">4.4.1.1</a>   Class of service.</span>

     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.

<span class="h5"><a class="selflink" id="section-4.4.1.2" href="#section-4.4.1.2">4.4.1.2</a>   Extended formats.</span>

     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.





<span class="grey">McCoy                                                          [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h5"><a class="selflink" id="section-4.4.1.3" href="#section-4.4.1.3">4.4.1.3</a>   Expedited data.</span>

     a.   Use of expedited data is subject to negotiation by users of
          Transport Service.

     b.   Expedited data shall be supported in Class 2.

<span class="h5"><a class="selflink" id="section-4.4.1.4" href="#section-4.4.1.4">4.4.1.4</a>   Maximum protocol data unit size.</span>

   (The provisions of this paragraph are under consideration.)

<span class="h5"><a class="selflink" id="section-4.4.1.5" href="#section-4.4.1.5">4.4.1.5</a>   Use of checksum.</span>

   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.

<span class="h5"><a class="selflink" id="section-4.4.1.6" href="#section-4.4.1.6">4.4.1.6</a>   Protection parameters.</span>

   Use of the security parameters is not defined in this supplement.

<span class="h5"><a class="selflink" id="section-4.4.1.7" href="#section-4.4.1.7">4.4.1.7</a>   Use of flow control in Class 2.</span>


     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.


<span class="h5"><a class="selflink" id="section-4.4.1.8" href="#section-4.4.1.8">4.4.1.8</a>  Service quality parameters.</span>


     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).



<span class="grey">McCoy                                                          [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


     c.   Priority (the use of this parameter is under consideration).

<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>   Parameters.</span>

          This paragraph defines the values to be used in the CR and CC
          TPDUs.

<span class="h5"><a class="selflink" id="section-4.4.2.1" href="#section-4.4.2.1">4.4.2.1</a>   Class 2 parameters.</span>

<span class="h6"><a class="selflink" id="section-4.4.2.1.1" href="#section-4.4.2.1.1">4.4.2.1.1</a>   Connect request (CR) protocol data unit.</span>

<span class="h6"><a class="selflink" id="section-4.4.2.1.1.1" href="#section-4.4.2.1.1.1">4.4.2.1.1.1</a>   Fixed part of header.</span>


     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.)


<span class="h6"><a class="selflink" id="section-4.4.2.1.1.2" href="#section-4.4.2.1.1.2">4.4.2.1.1.2</a>   Variable part of header.</span>


     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.



<span class="grey">McCoy                                                          [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


     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.

<span class="h6"><a class="selflink" id="section-4.4.2.1.1.3" href="#section-4.4.2.1.1.3">4.4.2.1.1.3</a>  User data.</span>

   The CR TPDU shall not carry user data which has any requirement
   whatever for security protection.

<span class="h6"><a class="selflink" id="section-4.4.2.1.2" href="#section-4.4.2.1.2">4.4.2.1.2</a>   Connect Confirm (CC) TPDU.</span>

<span class="h6"><a class="selflink" id="section-4.4.2.1.2.1" href="#section-4.4.2.1.2.1">4.4.2.1.2.1</a>   Fixed part of header.</span>


     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).


<span class="h6"><a class="selflink" id="section-4.4.2.1.2.2" href="#section-4.4.2.1.2.2">4.4.2.1.2.2</a>   Variable part of header.</span>


     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.




<span class="grey">McCoy                                                          [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


     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.

<span class="h6"><a class="selflink" id="section-4.4.2.1.2.3" href="#section-4.4.2.1.2.3">4.4.2.1.2.3</a>   User data.</span>

     The CC TPDU shall not carry any data which has any requirement
     whatever for security protection.

<span class="h5"><a class="selflink" id="section-4.4.2.2" href="#section-4.4.2.2">4.4.2.2</a>   Class 4 parameters.</span>

<span class="h6"><a class="selflink" id="section-4.4.2.2.1" href="#section-4.4.2.2.1">4.4.2.2.1</a>  Connect request (CR) TPDU.</span>

<span class="h6"><a class="selflink" id="section-4.4.2.2.1.1" href="#section-4.4.2.2.1.1">4.4.2.2.1.1</a>   Fixed part of header.</span>


     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.)







<span class="grey">McCoy                                                          [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h6"><a class="selflink" id="section-4.4.2.2.1.2" href="#section-4.4.2.2.1.2">4.4.2.2.1.2</a>   Variable part of header.</span>


     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.

<span class="h6"><a class="selflink" id="section-4.4.2.2.1.3" href="#section-4.4.2.2.1.3">4.4.2.2.1.3</a>   User data.</span>

     The CR TPDU shall not carry user data which has any requirement
     whatever for security protection.

<span class="h6"><a class="selflink" id="section-4.4.2.2.2" href="#section-4.4.2.2.2">4.4.2.2.2</a>   Connect confirm (CC) TPDU.</span>

<span class="h6"><a class="selflink" id="section-4.4.2.2.2.1" href="#section-4.4.2.2.2.1">4.4.2.2.2.1</a>   Fixed part of header.</span>

     a.   Connect confirm code: as in IS 8073.

     b.   Initial credit allocation: same as Paragraph 4.4.2.2.1.1.b.




<span class="grey">McCoy                                                          [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


     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.

<span class="h6"><a class="selflink" id="section-4.4.2.2.1.2" href="#section-4.4.2.2.1.2">4.4.2.2.1.2</a>  Variable part of header.</span>

     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.

<span class="h6"><a class="selflink" id="section-4.4.2.2.1.3" href="#section-4.4.2.2.1.3">4.4.2.2.1.3</a>   User data.</span>

   The CC TPDU shall not carry user data which has any requirement
   whatever for security protection.




<span class="grey">McCoy                                                          [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>   Use of local options.</span>

   The paragraphs that follow give policy and guidance in the election
   of local options.

<span class="h4"><a class="selflink" id="section-4.5.1" href="#section-4.5.1">4.5.1</a>   Local options, Class 2.</span>

<span class="h5"><a class="selflink" id="section-4.5.1.1" href="#section-4.5.1.1">4.5.1.1</a>   Multiplexing.</span>

   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.

<span class="h5"><a class="selflink" id="section-4.5.1.2" href="#section-4.5.1.2">4.5.1.2</a>   Acknowledgement strategy.</span>

   (The provisions of this paragraph are under consideration.)

<span class="h5"><a class="selflink" id="section-4.5.1.3" href="#section-4.5.1.3">4.5.1.3</a>   Concatenation.</span>

   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.

<span class="h5"><a class="selflink" id="section-4.5.1.4" href="#section-4.5.1.4">4.5.1.4</a>   Lockup prevention timer.</span>

   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.)

<span class="h5"><a class="selflink" id="section-4.5.1.5" href="#section-4.5.1.5">4.5.1.5</a>   Treatment of protocol errors.</span>

   Protocol errors detected by a Class 2 transport connection shall
   result in that connection being terminated, without sending an ER
   TPDU.

<span class="h5"><a class="selflink" id="section-4.5.1.6" href="#section-4.5.1.6">4.5.1.6</a>   Action on receipt of Error transport protocol data unit.</span>

   The receipt of an ER TPDU for a Class 2 transport connection shall
   cause immediate termination of that transport connection.

<span class="h4"><a class="selflink" id="section-4.5.2" href="#section-4.5.2">4.5.2</a>   Local options, Class 4.</span>

<span class="h5"><a class="selflink" id="section-4.5.2.1" href="#section-4.5.2.1">4.5.2.1</a>   Withdrawal of flow control credit.</span>

   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.



<span class="grey">McCoy                                                          [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h5"><a class="selflink" id="section-4.5.2.2" href="#section-4.5.2.2">4.5.2.2</a>   Flow control confirmation.</span>

   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.

<span class="h5"><a class="selflink" id="section-4.5.2.3" href="#section-4.5.2.3">4.5.2.3</a>   Subsequenced acknowledgements.</span>

   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.

<span class="h5"><a class="selflink" id="section-4.5.2.4" href="#section-4.5.2.4">4.5.2.4</a>   Splitting over network connection.</span>

   Implementations may use splitting as necessary or useful in the
   operating environment. (Splitting is defined only for operation
   over a CONS.

<span class="h5"><a class="selflink" id="section-4.5.2.5" href="#section-4.5.2.5">4.5.2.5</a>   Acknowledgement strategy.</span>

   (The provisions of this paragraph are under consideration.)

<span class="h5"><a class="selflink" id="section-4.5.2.6" href="#section-4.5.2.6">4.5.2.6</a>   Wait-before-closing state.</span>

   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.

<span class="h5"><a class="selflink" id="section-4.5.2.7" href="#section-4.5.2.7">4.5.2.7</a>   Multiplexing on network connection.</span>

   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.

<span class="h5"><a class="selflink" id="section-4.5.2.8" href="#section-4.5.2.8">4.5.2.8</a>   Concatenation of protocol data units.</span>

   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.





<span class="grey">McCoy                                                          [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h5"><a class="selflink" id="section-4.5.2.9" href="#section-4.5.2.9">4.5.2.9</a>   Checksum algorithm.</span>

   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.

<span class="h5"><a class="selflink" id="section-4.5.2.10" href="#section-4.5.2.10">4.5.2.10</a>   Send network RESET when bad checksum received.</span>


   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.

<span class="h5"><a class="selflink" id="section-4.5.2.11" href="#section-4.5.2.11">4.5.2.11</a>   Protocol data unit retransmission policy.</span>

   (The provisions of this paragraph are under consideration.)

<span class="h5"><a class="selflink" id="section-4.5.2.12" href="#section-4.5.2.12">4.5.2.12</a>   Treatment of protocol errors.</span>

   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.

<span class="h5"><a class="selflink" id="section-4.5.2.13" href="#section-4.5.2.13">4.5.2.13</a>   Action on receipt of Error transport protocol data unit.</span>

   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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. SPECIAL REQUIREMENTS</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>   Addressing conventions.</span>

   (The provisions of Paragraph 5.1 and its subparagraphs are under
   consideration.)

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>   Transport Service Access Point.</span>

<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>   Connect-request/confirm protocol data units.</span>

<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>   Network Service Access Point.</span>



<span class="grey">McCoy                                                          [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>   Convention for use of transport connection reference numbers.</span>

   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.

<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>   Specification of convention.</span>

   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.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>  Operation over connectionless network service.</span>

   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.







<span class="grey">McCoy                                                          [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc1007">RFC 1007</a>                                                       June 1987</span>


<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>   Recovery from peer deactivation.</span>

   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]
</pre>