rfc983.txt

RFC 相关的技术文档

      |    ...        |      ...      |      ...      |      ...      |
      |    ...        |      ...      |      ...      |      ...      |
      |      ...      |   user data   |      ...      |      ...      |
      |    ...        |      ...      |      ...      |      ...      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the fields is identical to those of a CR or CC TPDU,
   with the following exceptions:

   where:

      8.  reason                        8 bits

         This replaces the class/option fields of the CR or CC TPDU. Any
         value, as specified in [ISO-8073], may be used in this field.
         This memo makes use of several:

            value       meaning
            -----       -------
              1         Congestion at TSAP
              2         Session entity not attached to TSAP
              3         Address unknown (at TCP connect time)
            128+0       Normal disconnect initiated by the session
                        entity
            128+1       Remote transport entity congestion at connect
                        request time
            128+3       Connection negotiation failed
            128+5       Protocol Error
            128+8       Connection request refused on this network
                        connection










Cass & Rose                                                    [Page 21]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


   The format of a DT or ED TPDU is:

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

   where:

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

      6.  TPDU-NR and EOT               16 bits

         This field is always ZERO on output and ignored on input.

7.  Expedited Data

   This memo utilizes a second TCP connection to handle expedited data
   and does not make use of the TCP URGENT mechanism.  The primary
   disadvantage of this decision is that single-threaded implementations
   of TCP may have some difficulty in supporting two simultaneous
   connections.  There are however several advantages to this approach:

      a.  Use of a single connection to implement the semantics of
      expedited data implies that the TSAP peer manage a set of buffers
      independent from TCP.  The peer would, upon indication of TCP
      urgent information, have to buffer all preceeding TPKTs until the
      TCP buffer was empty.  Expedited data would then be given to the
      TS-user.  When the expedited data was flushed, then the buffered
      (non-expedited) data could be passed up to the receiving user.

      b.  It assumes that implementations support TCP urgency correctly.
      This is perhaps an untrue assumption, particular in the case of
      TCP urgency occuring when the send window is zero-sized.  Further,
      it assumes that the implementations can signal this event to the
      TCP-user in a meaningful fashion.  In a single-threaded
      implementation, this is not likely.

   Given a reasonable TCP implementation, the TS-peer need listen on two




Cass & Rose                                                    [Page 22]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


   TCP sockets in either polling or interrupt mode.  When the TS-peer is
   given data, the TCP must indicate which connection should be read
   from.

   The only tricky part of the protocol is that the client must be able
   to start a passive OPEN for the expedited port, and then wait to read
   from another connection.  In between the passive OPEN and the other
   connection supplying data, the server will connect to the expedited
   port, prior to sending data on the other connection.  To summarize
   from Section 5, the sequence of events, with respect to TCP, is:

      time      client                          Server
      ----      ------                          ------
      0.                                        passive OPEN of port 102

      1.        T-CONNECT.REQUEST from user
                passive OPEN of expedited
                port (non-blocking)

      2.        active OPEN of port 102

      3.        send CC TPKT

      4.                                        port 102 connected

      5.                                        receive CC TPKT
                                                T-CONNECT.INDICATION to
                                                user
                                                T-CONNECT.RESPONSE from
                                                user

      6.                                        active OPEN to expedited
                                                port

      7.        expedited port connected

      8.                                        send CR TPKT

      9.        receive CR TPKT
                verify expedited port
                connected correctly

   Multi-threaded implementations of TCP should be able to support this
   sequence of events without any great difficulty.





Cass & Rose                                                    [Page 23]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


8.  Conclusions

   There are two design decisions which should be considered.  The first
   deals with particular packet format used.  It should be obvious to
   the reader that the TP packet format was adopted for use in this
   memo.  Although this results in a few fields being ignored (e.g.,
   source reference), it does not introduce an unacceptable amount of
   overhead.  For example, on a connection request packet (the worst
   case) there are 6 bytes of "zero on output, ignore on input" fields.
   Considering that the packet overhead processing is fixed, requiring
   that implementations allocate an additional 1.5 words is not
   unreasonable!  Of course, it should be noted that some of these
   fields (i.e., class) may be used in future versions of the protocol
   as experience is gained.

   The second decision deals with how the TCP and TSAP port space is
   administered.  It is probably a very bad idea to take any
   responsibility, whatsoever, for managing this addressing space, even
   after ISO has stabilized.  There are two issues involved.  First, at
   what level do the TCP and TSAP port spaces interact; second, who
   defines what this interaction looks like.  With respect to the first,
   it wholly undesirable to require that each TSAP port map to a unique
   TCP port.  The administrative problems for the TCP "numbers czar (and
   czarina)" would be non-trivial.  Therefore, it is desirable to
   allocate a single TCP port, namely port 102, as the port where the
   "ISO Transport Services" live in the TCP domain. Second, the
   interaction defined in Appendix A of this memo is embryonic at best.
   It will no doubt be replaced as soon as the ISO world reaches
   convergence on how services are addressed in ISO TP. Therefore
   readers (and implementors) are asked to keep in mind that this aspect
   of the memo is guaranteed to change.  Unfortunately, the authors are
   not permitted the luxury of waiting for a consensus in ISO.  As a
   result, the minimal effort approach outlined in the appendix below
   was adopted.

   A prototype implementation of the protocol described by this memo is
   available for 4.2BSD UNIX.  Interested parties should contact the
   authors for a copy.  To briefly mention its implementation, a given
   ISO service is implemented as a separate program.  A daemon listens
   on TCP port 102, consults a database when a connection request packet
   is received, and fires the appropriate program for the ISO service
   requested.  Of course, given the nature of the BSD implementation of
   TCP, as the child fires, responsibility of that particular connection
   is delegated to the child; the daemon returns to listening for new
   connection requests.  The prototype implementation consists of both
   the daemon program and subroutine libraries which are loaded with
   programs providing ISO services.


Cass & Rose                                                    [Page 24]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


9.  References

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

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

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

   [RFC-791]    Internet Protocol.
                Request for Comments 791
                (September, 1981)
                (See also: MIL-STD-1777)

   [RFC-793]    Transmission Control Protocol.
                Request for Comments 793
                (September, 1981)
                (See also: MIL-STD-1778)

   [RFC-960]    Assigned Numbers.
                Request for Comments 960
                (December, 1985)

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




Cass & Rose                                                    [Page 25]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


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

   [X.410]      CCITT.
                "Recommendation X.410.  Message Handling Systems: Remote
                Operations and Reliable Transfer Server."
                (October, 1984)

Appendix A:  Reserved TSAP IDs

   Version 1 of this protocol uses a relatively simple encoding scheme
   for TSAP IDs.  A TSAP ID is an attribute list containing two
   parameters, a 32-bit IP address, and a 16-bit port number.  This is
   used to identify both the client TSAP and the server TSAP.  When it
   appears in a TPKT with code CR or CC, the TSAP ID is encoded in the
   variable data part for the client TSAP as:

       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      193      |       8       |       1       |       6       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       a       |       b       |       c       |       d       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              port             |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         and for the server TSAP as:

       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      194      |       8       |       1       |       6       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       a       |       b       |       c       |       d       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              port             |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   (Neither of these examples include an attribute for a TCP connection
   for expedited data.  If one were present, the length of the TSAP ID
   attribute would be 16 instead of 8, and the 8 bytes following the
   Internet address would be "2" for the attribute code, "6" for the



Cass & Rose                                                    [Page 26]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


   attribute length, and then 6 octets for the Internet address to use
   for expedited data, 4 octets for IP address, and 2 octets for TCP
   port.)

   Where [a.b.c.d] is the IP address of the host where the respective
   TSAP peer resides, and port is a 16-bit unsigned integer describing
   where in the TSAP port space the TS-user lives.

      Port value        Designation
      ----------        -----------
          0             illegal
         1-4096         privileged
      4097-65535        user

   The following table contains the list of the "official" TSAP ID port
   numbers as of the first release of this memo.  It is expected that
   future editions of the "Assigned Numbers" document[RFC-960] will
   contain updates to this list.

      Port    name        ISO service
      ----    ----        -----------
      1       echo        unofficial echo
      2       sink        unofficial data sink
      3       FTAM        File Transfer, Access, and Management
      4       VTS         ISO-8571 Virtual Terminal Service
      5       MHS         Message Handling System [X.411]
                          CCITT X.400
      6       JTM         Job Transfer and Manipulation
                          ISO 8831/8832
      7       CASE        Common Application Service Elements
                          Kernel ISO-8650/2

   If anyone knows of a list of "official" ISO services, the authors
   would be very interested.















Cass & Rose                                                    [Page 27]