rfc1006.txt

中、英文RFC文档大全打包下载完全版 .

          are identical to those presented in [ISO8073], with three
          exceptions.

          In order to facilitate testing, the connection request and
          connection confirmation TPDUs may exchange initial user data,
          using the user data fields of these TPDUs.

          In order to experiment with expedited data services, the
          connection request and connection confirmation TPDUs may
          negotiate the use of expedited data transfer using the
          negotiation mechanism specified in [ISO8073] is used (e.g.,
          setting the "use of transport expedited data transfer service"
          bit in the "Additional Option Selection" variable part). The
          default is not to use the transport expedited data transfer
          service.



M. Rose & D. Cass                                              [Page 12]

RFC 1006                                                        May 1987


          In order to achieve good performance, the default TPDU size is
          65531 octets, instead of 128 octets.  In order to negotiate a
          smaller (standard) TPDU size, the negotiation mechanism
          specified in [ISO8073] is used (e.g., setting the desired bit
          in the "TPDU Size" variable part).

          To perform an N-CONNECT.REQUEST action, the TS-peer performs
          an active open to the desired IP address using TCP port 102.
          When the TCP signals either success or failure, this results
          in an N-CONNECT.INDICATION action.

          To await an N-CONNECT.INDICATION event, a server listens on
          TCP port 102.  When a client successfully connects to this
          port, the event occurs, and an implicit N-CONNECT.RESPONSE
          action is performed.

              NOTE:      In most implementations, a single server will
                         perpetually LISTEN on port 102, handing off
                         connections as they are made

DATA TRANSFER

      The elements of procedure used during data transfer are identical
      to those presented in [ISO8073], with one exception: expedited
      data may be supported (if so negotiated during connection
      establishment) by sending a modified ED TPDU (described below).
      The TPDU is sent on the same TCP connection as all of the other
      TPDUs. This method, while not faithful to the spirit of [ISO8072],
      is true to the letter of the specification.

      To perform an N-DATA.REQUEST action, the TS-peer constructs the
      desired TPKT and uses the TCP send data primitive.

      To trigger an N-DATA.INDICATION action, the TCP indicates that
      data is ready and a TPKT is read using the TCP read data
      primitive.

CONNECTION RELEASE

   To perform an N-DISCONNECT.REQUEST action, the TS-peer simply closes
   the TCP connection.

   If the TCP informs the TS-peer that the connection has been closed or
   has errored, this indicates an N-DISCONNECT.INDICATION event.










M. Rose & D. Cass                                              [Page 13]

RFC 1006                                                        May 1987


6.  Packet Format


      A fundamental difference between the TCP and the network service
      expected by TP0 is that the TCP manages a continuous stream of
      octets, with no explicit boundaries.  The TP0 expects information
      to be sent and delivered in discrete objects termed network
      service data units (NSDUs).  Although other classes of transport
      may combine more than one TPDU inside a single NSDU, transport
      class 0 does not use this facility.  Hence, an NSDU is identical
      to a TPDU for the purposes of our discussion.

      The protocol described by this memo uses a simple packetization
      scheme in order to delimit TPDUs.  Each packet, termed a TPKT, is
      viewed as an object composed of an integral number of octets, of
      variable length.

          NOTE:       For the purposes of presentation, these objects are
                      shown as being 4 octets (32 bits wide).  This
                      representation is an artifact of the style of this
                      memo and should not be interpreted as requiring
                      that a TPKT be a multiple of 4 octets in length.

      A TPKT consists of two parts:  a packet-header and a TPDU.  The
      format of the header is constant regardless of the type of packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described in
      this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets,
      including packet-header.  This permits a maximum TPDU size of
      65531 octets.  Based on the size of the data transfer (DT) TPDU,
      this permits a maximum TSDU size of 65524 octets.

      The format of the TPDU is defined in [ISO8073].  Note that only
      TPDUs formatted for transport class 0 are exchanged (different
      transport classes may use slightly different formats).




M. Rose & D. Cass                                              [Page 14]

RFC 1006                                                        May 1987


      To support expedited data, a non-standard TPDU, for expedited data
      is permitted.  The format used for the ED TPDU is nearly identical
      to the format for the normal data, DT, TPDU.  The only difference
      is that the value used for the TPDU's code is ED, not DT:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | header length | code  |credit |TPDU-NR and EOT|   user data   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      ...      |      ...      |      ...      |      ...      |
      |      ...      |      ...      |      ...      |      ...      |
      |      ...      |      ...      |      ...      |      ...      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      After the credit field (which is always ZERO on output and ignored
      on input), there is one additional field prior to the user data.

      TPDU-NR and EOT         8 bits

      Bit 7 (the high-order bit, bit mask 1000 0000) indicates the end
      of a TSDU.  All other bits should be ZERO on output and ignored on
      input.

      Note that the TP specification limits the size of an expedited
      transport service data unit (XSDU) to 16 octets.




























M. Rose & D. Cass                                              [Page 15]

RFC 1006                                                        May 1987


7.  Comments


      Since the release of RFC983 in April of 1986, we have gained much
      experience in using ISO transport services on top of the TCP.  In
      September of 1986, we introduced the use of version 2 of the
      protocol, based mostly on comments from the community.

      In January of 1987, we observed that the differences between
      version 2 of the protocol and the actual transport class 0
      definition were actually quite small.  In retrospect, this
      realization took much longer than it should have:  TP0 is is meant
      to run over a reliable network service, e.g., X.25. The TCP can be
      used to provide a service of this type, and, if no one complains
      too loudly, one could state that this memo really just describes a
      method for encapsulating TPO inside of TCP!

      The changes in going from version 1 of the protocol to version 2
      and then to version 3 are all relatively small. Initially, in
      describing version 1, we decided to use the TPDU formats from the
      ISO transport protocol.  This naturally led to the evolution
      described above.
































M. Rose & D. Cass                                              [Page 16]

RFC 1006                                                        May 1987


8. References


   [GOSIP86]    The U.S. Government OSI User's Committee.
                "Government Open Systems Interconnection Procurement
                (GOSIP) Specification for Fiscal years 1987 and
                1988." (December, 1986) [draft status]

   [ISO8072]    ISO.
                "International Standard 8072.  Information Processing
                Systems -- Open Systems Interconnection: Transport
                Service Definition."
                (June, 1984)

   [ISO8073]    ISO.
                "International Standard 8073.  Information Processing
                Systems -- Open Systems Interconnection: Transport
                Protocol Specification."
                (June, 1984)

   [ISO8327]    ISO.
                "International Standard 8327.  Information Processing
                Systems -- Open Systems Interconnection: Session
                Protocol Specification."
                (June, 1984)

   [RFC791]     Internet Protocol.
                Request for Comments 791 (MILSTD 1777)
                (September, 1981)

   [RFC793]     Transmission Control Protocol.
                Request for Comments 793 (MILSTD 1778)
                (September, 1981)

   [RFC983]     ISO Transport Services on Top of the TCP.
                Request for Comments 983
                (April, 1986)

   [X.214]      CCITT.
                "Recommendation X.214.  Transport Service Definitions
                for Open Systems Interconnection (OSI) for CCITT
                Applications."
                (October, 1984)

   [X.224]      CCITT.
                "Recommendation X.224.  Transport Protocol
                Specification for Open Systems Interconnection (OSI)
                for CCITT Applications." (October, 1984)






M. Rose & D. Cass                                              [Page 17]

RFC 1006                                                        May 1987


   [X.225]      CCITT.
                "Recommendation X.225.  Session Protocol Specification
                for Open Systems Interconnection (OSI) for CCITT
                Applications."
                (October, 1984)

















































M. Rose & D. Cass                                              [Page 18]