rfc1007.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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