home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 900s / rfc983.txt < prev    next >
Text File  |  1986-04-20  |  58KB  |  1,540 lines
  1.  
  2.  
  3. Network Working Group                                  D. E. Cass (NRTC)
  4. Request for Comments: 983                              M. T. Rose (NRTC)
  5.                                                               April 1986
  6.  
  7.                 ISO Transport Services on Top of the TCP
  8.  
  9.  
  10. Status of This Memo
  11.  
  12.    This memo describes a proposed protocol standard for the ARPA
  13.    Internet community.  The intention is that hosts in the ARPA-Internet
  14.    that choose to implement ISO TSAP services on top of the TCP be
  15.    expected to adopt and implement this standard.  Suggestions for
  16.    improvement are encouraged.  Distribution of this memo is unlimited.
  17.  
  18. 1.  Introduction and Philosophy
  19.  
  20.    The ARPA Internet community has a well-developed, mature set of
  21.    transport and internetwork protocols (TCP/IP), which are quite
  22.    successful in offering network and transport services to end-users.
  23.    The CCITT and the ISO have defined various session, presentation, and
  24.    application recommendations which have been adopted by the
  25.    international community and numerous vendors.  To the largest extent
  26.    possible, it is desirable to offer these higher level services
  27.    directly in the ARPA Internet, without disrupting existing
  28.    facilities.  This permits users to develop expertise with ISO and
  29.    CCITT applications which previously were not available in the ARPA
  30.    Internet.  It also permits a more graceful transition strategy from
  31.    TCP/IP-based networks to ISO-based networks in the medium- and
  32.    long-term.
  33.  
  34.    There are two basic approaches which can be taken when "porting" an
  35.    ISO or CCITT application to a TCP/IP environment.  One approach is to
  36.    port each individual application separately, developing local
  37.    protocols on top of the TCP.  Although this is useful in the
  38.    short-term (since special-purpose interfaces to the TCP can be
  39.    developed quickly), it lacks generality.
  40.  
  41.    A second approach is based on the observation that both the ARPA
  42.    Internet protocol suite and the ISO protocol suite are both layered
  43.    systems (though the former uses layering from a more pragmatic
  44.    perspective).  A key aspect of the layering principle is that of
  45.    layer-independence.  Although this section is redundant for most
  46.    readers, a slight bit of background material is necessary to
  47.    introduce this concept.
  48.  
  49.    Externally, a layer is defined by two definitions:
  50.  
  51.       a service-offered definition, which describes the services
  52.       provided by the layer and the interfaces it provides to access
  53.       those services; and,
  54.  
  55.  
  56. Cass & Rose                                                     [Page 1]
  57.  
  58.  
  59.  
  60. RFC 983                                                       April 1986
  61. ISO Transport Services on Top of the TCP
  62.  
  63.  
  64.       a service-required definitions, which describes the services used
  65.       by the layer and the interfaces it uses to access those services.
  66.  
  67.    Collectively, all of the entities in the network which co-operate to
  68.    provide the service are known as the service-provider. Individually,
  69.    each of these entities is known as a service-peer.
  70.  
  71.    Internally, a layer is defined by one definition:
  72.  
  73.       a protocol definition, which describes the rules which each
  74.       service-peer uses when communicating with other service-peers.
  75.  
  76.    Putting all this together, the service-provider uses the protocol and
  77.    services from the layer below to offer the its service to the layer
  78.    above.  Protocol verification, for instance, deals with proving that
  79.    this in fact happens (and is also a fertile field for many Ph.D.
  80.    dissertations in computer science).
  81.  
  82.    The concept of layer-independence quite simply is:
  83.  
  84.       IF one preserves the services offered by the service-provider
  85.  
  86.       THEN the service-user is completely naive with respect to the
  87.       protocol which the service-peers use
  88.  
  89.    For the purposes of this memo, we will use the layer-independence to
  90.    define a Transport Service Access Point (TSAP) which appears to be
  91.    identical to the services and interfaces offered by the ISO/CCITT
  92.    TSAP (as defined in [ISO-8072]), but we will base the internals of
  93.    this TSAP on TCP/IP (as defined in [RFC-793,RFC791]), not on the
  94.    ISO/CCITT transport and network protocols.  Hence, ISO/CCITT higher
  95.    level layers (all session, presentation, and application entities)
  96.    can operate fully without knowledge of the fact that they are running
  97.    on a TCP/IP internetwork.
  98.  
  99.    The authors hope that the preceding paragraph will not come as a
  100.    shock to most readers.  However, an ALARMING number of people seem to
  101.    think that layering is just a way of cutting up a large problem into
  102.    smaller ones, *simply* for the sake of cutting it up.  Although
  103.    layering tends to introduce modularity into an architecture, and
  104.    modularity tends to introduce sanity into implementations (both
  105.    conceptual and physical implementations), modularity, per se, is not
  106.    the end goal.  Flexibility IS.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Cass & Rose                                                     [Page 2]
  114.  
  115.  
  116.  
  117. RFC 983                                                       April 1986
  118. ISO Transport Services on Top of the TCP
  119.  
  120.  
  121. 2.  Motivation
  122.  
  123.    In migrating from the use of TCP/IP to the ISO protocols, there are
  124.    several strategies that one might undertake.  This memo was written
  125.    with one particular strategy in mind.
  126.  
  127.    The particular migration strategy which this memo uses is based on
  128.    the notion of gatewaying between the TCP/IP and ISO protocol suites
  129.    at the transport layer.  There are two strong arguments for this
  130.    approach:
  131.  
  132.       a.  Experience teaches us that it takes just as long to get good
  133.       implementations of the lower level protocols as it takes to get
  134.       good implementations of the higher level ones.  In particular, it
  135.       has been observed that there is still a lot of work being done at
  136.       the ISO network and transport layers.  As a result,
  137.       implementations of protocols above these layers are not being
  138.       aggressively pursued. Thus, something must be done "now" to
  139.       provide a medium in which the higher level protocols can be
  140.       developed.  Since TCP/IP is mature, and essentially provides
  141.       identical functionality, it is an ideal medium to support this
  142.       development.
  143.  
  144.       b.  Implementation of gateways at the IP and ISO IP layers are
  145.       probably not of general use in the long term.  In effect, this
  146.       would require each Internet host to support both TP4 and TCP.  As
  147.       such, a better strategy is to implement a graceful migration path
  148.       from TCP/IP to ISO protocols for the ARPA Internet when the ISO
  149.       protocols have matured sufficiently.
  150.  
  151.    Both of these arguments indicate that gatewaying should occur at or
  152.    above the transport layer service access point.  Further, the first
  153.    argument suggests that the best approach is to perform the gatewaying
  154.    exactly AT the transport service access point to maximize the number
  155.    of ISO layers which can be developed.
  156.  
  157.       NOTE:  This memo does not intend to act as a migration or
  158.       intercept document.  It is intended ONLY to meet the needs
  159.       discussed above.  However, it would not be unexpected that the
  160.       protocol described in this memo might form part of an overall
  161.       transition plan.  The description of such a plan however is
  162.       COMPLETELY beyond the scope of this memo.
  163.  
  164.    Finally, in general, building gateways between other layers in the
  165.    TCP/IP and ISO protocol suites is problematic, at best.
  166.  
  167.    To summarize: the primary motivation for the standard described in
  168.  
  169.  
  170. Cass & Rose                                                     [Page 3]
  171.  
  172.  
  173.  
  174. RFC 983                                                       April 1986
  175. ISO Transport Services on Top of the TCP
  176.  
  177.  
  178.    this memo is to facilitate the process of gaining experience with
  179.    higher-level ISO protocols (session, presentation, and application).
  180.    The stability and maturity of TCP/IP are ideal for providing solid
  181.    transport services independent of actual implementation.
  182.  
  183. 3.  The Model
  184.  
  185.    The [ISO-8072] standard describes the ISO transport service
  186.    definition, henceforth called TP.
  187.  
  188.       ASIDE:  This memo references the ISO specifications rather than
  189.       the CCITT recommendations.  The differences between these parallel
  190.       standards are quite small, and can be ignored, with respect to
  191.       this memo, without loss of generality.  To provide the reader with
  192.       the relationships:
  193.  
  194.          Transport service      [ISO-8072]      [X.214]
  195.          Transport protocol     [ISO-8073]      [X.224]
  196.          Session protocol       [ISO-8327]      [X.225]
  197.  
  198.    The ISO transport service definition describes the services offered
  199.    by the TS-provider (transport service) and the interfaces used to
  200.    access those services.  This memo focuses on how the ARPA
  201.    Transmission Control Protocol (TCP) [RFC-793] can be used to offer
  202.    the services and provide the interfaces.
  203.  
  204.    +-------------+                                      +-------------+
  205.    |   TS-user   |                                      |   TS-user   |
  206.    +-------------+                                      +-------------+
  207.            |                                                   |
  208.            | TSAP interface                     TSAP interface |
  209.            |  [ISO-8072]                                       |
  210.            |                                                   |
  211.    +------------+   ISO Transport Services on the TCP    +------------+
  212.    |   client   |----------------------------------------|   server   |
  213.    +------------+              (this memo)               +------------+
  214.            |                                                   |
  215.            | TCP interface                       TCP interface |
  216.            |  [RFC-793]                                        |
  217.            |                                                   |
  218.  
  219.    For expository purposes, the following abbreviations are used:
  220.  
  221.       TS-peer           a process which implements the protocol
  222.                         described by this memo
  223.  
  224.  
  225.  
  226.  
  227. Cass & Rose                                                     [Page 4]
  228.  
  229.  
  230.  
  231. RFC 983                                                       April 1986
  232. ISO Transport Services on Top of the TCP
  233.  
  234.  
  235.       TS-user           a process talking using the services of a
  236.                         TS-peer
  237.  
  238.       TS-provider       the black-box entity implementing the protocol
  239.                         described by this memo
  240.  
  241.    For the purposes of this memo, which describes version 1 of the TSAP
  242.    protocol, all aspects of [ISO-8072] are supported with one exception:
  243.  
  244.       Quality of Service parameters
  245.  
  246.    In the spirit of CCITT, this is left "for further study".  Version 2
  247.    of the TSAP protocol will most likely support the QOS parameters for
  248.    TP by mapping these onto various TCP parameters.
  249.  
  250.    Since TP supports the notion of a session port (termed a TSAP ID),
  251.    but the list of reserved ISO TSAP IDs is not clearly defined at this
  252.    time, this memo takes the philosophy of isolating the TCP port space
  253.    from the TSAP ID space and uses a single TCP port.  This memo
  254.    reserves TCP port 102 for this purpose.  This protocol manages its
  255.    own TSAP ID space independent of the TCP.  Appendix A of this memo
  256.    lists reserved TSAP IDs for version 1 of this TSAP protocol.  It is
  257.    expected that future editions of the "Assigned Numbers" document
  258.    [RFC-960] will contain updates to this list.  (Interested readers are
  259.    encouraged to read [ISO-8073] and try to figure out exactly what a
  260.    TSAP ID is.)
  261.  
  262.    Finally, the ISO TSAP is fundamentally symmetric in behavior.  There
  263.    is no underlying client/server model.  Instead of a server listening
  264.    on a well-known port, when a connection is established, the
  265.    TS-provider generates an INDICATION event which, presumably the
  266.    TS-user catches and acts upon.  Although this might be implemented by
  267.    having a server "listen" by hanging on the INDICATION event, from the
  268.    perspective of the ISO TSAP, all TS-users just sit around in the IDLE
  269.    state until they either generate a REQUEST or accept an INDICATION.
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284. Cass & Rose                                                     [Page 5]
  285.  
  286.  
  287.  
  288. RFC 983                                                       April 1986
  289. ISO Transport Services on Top of the TCP
  290.  
  291.  
  292. 4.  The Primitives
  293.  
  294.    The protocol assumes that the TCP [RFC-793] offers the following
  295.    service primitives:
  296.  
  297.    Events
  298.  
  299.       connected       - open succeeded (either ACTIVE or PASSIVE)
  300.  
  301.       connect fails   - ACTIVE open failed
  302.  
  303.       data ready      - data can be read from the connection
  304.  
  305.       errored         - the connection has errored and is now closed
  306.  
  307.       closed          - an orderly disconnection has started
  308.  
  309.    Actions
  310.  
  311.       listen on port  - PASSIVE open on the given port
  312.  
  313.       open port       - ACTIVE open to the given port
  314.  
  315.       read data       - data is read from the connection
  316.  
  317.       send data       - data is sent on the connection
  318.  
  319.       close           - the connection is closed (pending data is sent)
  320.  
  321.    The protocol offers the following service primitives, as defined in
  322.    [ISO-8072], to the TS-user:
  323.  
  324.    Events
  325.  
  326.       T-CONNECT.INDICATION
  327.  
  328.          - a TS-user (server) is notified that connection establishment
  329.            is in progress
  330.  
  331.       T-DISCONNECT.INDICATION
  332.  
  333.          - a TS-user is notified that the connection is closed
  334.  
  335.       T-CONNECT.CONFIRMATION
  336.  
  337.          - a TS-user (client) is notified that the connection has been
  338.            established
  339.  
  340.  
  341. Cass & Rose                                                     [Page 6]
  342.  
  343.  
  344.  
  345. RFC 983                                                       April 1986
  346. ISO Transport Services on Top of the TCP
  347.  
  348.  
  349.       T-DATA.INDICATION
  350.  
  351.          - a TS-user is notified that data can be read from the
  352.            connection
  353.  
  354.       T-EXPEDITED DATA.INDICATION
  355.  
  356.          - a TS-user is notified that "expedited" data can be read from
  357.            the connection
  358.  
  359.    Actions
  360.  
  361.       T-CONNECT.RESPONSE
  362.  
  363.          - a TS-user (server) indicates that it will honor the request
  364.  
  365.       T-DISCONNECT.REQUEST
  366.  
  367.          - a TS-user indicates that the connection is to be closed
  368.  
  369.       T-CONNECT.REQUEST
  370.  
  371.          - a TS-user (client) indicates that it wants to establish a
  372.            connection
  373.  
  374.       T-DATA.REQUEST
  375.  
  376.          - a TS-user sends data
  377.  
  378.       T-EXPEDITED DATA.REQUEST
  379.  
  380.          - a TS-user sends "expedited" data
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398. Cass & Rose                                                     [Page 7]
  399.  
  400.  
  401.  
  402. RFC 983                                                       April 1986
  403. ISO Transport Services on Top of the TCP
  404.  
  405.  
  406. 5.  The Protocol
  407.  
  408.    It is the goal of this memo to offer a TP interface on top of the
  409.    TCP.  Fortunately, the TCP does just about everything that
  410.    TS-provider offers to the TS-user, so the hard parts of the transport
  411.    layer (e.g., three-way handshakes, choice of ISS, windowing,
  412.    multiplexing, ad infinitum) are all taken care of by the TCP.
  413.  
  414.    Despite the symmetry of TP, it is useful to consider the protocol
  415.    with the perspective of a client/server model.
  416.  
  417.    The information exchanged between TSAP-peers is in the form of
  418.    packets termed "TPKT"s.  The format of these packets is described in
  419.    the next section.  For the purposes of the description below, a TPKT
  420.    has a code which is one of:
  421.  
  422.       CR - request connection
  423.       CC - confirm connection
  424.       DR - request disconnection
  425.       DT - data
  426.       ED - expedited data
  427.  
  428.    A TSAP server begins by LISTENing on TCP port 102.  When a TSAP
  429.    client successfully connects to this port, the protocol begins.
  430.  
  431.    A client decides to connect to the port when a TS-user issues a
  432.    T-CONNECT.REQUEST action.  This action specifies the TSAP ID of the
  433.    remote TS-user, whether expedited data is to be supported, and
  434.    (optionally) some initial TS-user data.  The client consults the TSAP
  435.    ID given to ascertain the IP address of the server.  If the expedited
  436.    data option was requested, the client opens a passive TCP port, in
  437.    non-blocking mode, noting the port number.  This TCP port is termed
  438.    the "expedited port".  The client then tries to open a TCP connection
  439.    to the server on port 102.  If not successful, the client fires
  440.    T-DISCONNECT.INDICATION for the TS-user specifying the reason for
  441.    failure (and, closes the expedited port, if any).  If successful, the
  442.    client sends a TPKT with code CR containing:
  443.  
  444.       - the TSAP ID of the TS-user on the client's host (the "caller")
  445.       - the TSAP ID of the TS-user that the client wants to talk to
  446.         (the "called")
  447.       - if the expedited data option was requested, the TSAP ID of the
  448.         expedited port for the client's host
  449.       - any TS-user data from the T-CONNECT.REQUEST
  450.  
  451.    The client now awaits a response.
  452.  
  453.  
  454.  
  455. Cass & Rose                                                     [Page 8]
  456.  
  457.  
  458.  
  459. RFC 983                                                       April 1986
  460. ISO Transport Services on Top of the TCP
  461.  
  462.  
  463.    The server, upon receipt of the TPKT, validates the contents of the
  464.    TPKT (checking the version number, verifying that the code is CR, and
  465.    so forth).  If the packet is invalid, the server sends a TPKT with
  466.    code DR specifying "PROTOCOL ERROR", closes the TCP connection, and
  467.    goes back to the LISTEN state.
  468.  
  469.    If the packet is valid, the server examines the TSAP ID that the
  470.    remote TS-user wants to communicate with.  If the TS-user specified
  471.    can be located and started (e.g., the appropriate program which
  472.    implements the indicated protocol is present), then the server starts
  473.    this TS-user by firing T-CONNECT.INDICATION.  Otherwise, the server
  474.    sends a TPKT with code DR specifying "SESSION ENTITY NOT ATTACHED TO
  475.    TSAP" or "REMOTE TRANSPORT ENTITY CONGESTED AT CONNECT REQUEST TIME"
  476.    as appropriate, closes the TCP connection, and goes back to the
  477.    LISTEN state.
  478.  
  479.    The server now waits for a T-CONNECT.RESPONSE or T-DISCONNECT.REQUEST
  480.    from the TS-user it started.  if the latter is given, the server
  481.    sends a TPKT with code DR containing the reason for the disconnect as
  482.    supplied by the TS-user.
  483.  
  484.    The server then closes the TCP connection and goes back to the LISTEN
  485.    state.
  486.  
  487.    Instead, if T-CONNECT.RESPONSE is given, the server sees if an
  488.    expedited port was specified in the connection request.  If so, the
  489.    server opens a second TCP connection and connects to the specified
  490.    port.  If the connection fails, the server sends a TPKT with code DR
  491.    specifying "CONNECTION NEGOTIATION FAILED", closes the TCP
  492.    connection, and goes back to the LISTEN state.  If the connection
  493.    succeeded, the server notes the local port number used to connect to
  494.    the expedited port.
  495.  
  496.    If an expedited port was not specified in the TPKT with code CR, and
  497.    the server's TS-user indicates that it wants to use expedited data,
  498.    then the server sends a TPKT with code DR specifying "CONNECTION
  499.    NEGOTIATION FAILED", fires T-DISCONNECT.INDICATION with this error to
  500.    the TS-user, closes the TCP connection, and goes back to the LISTEN
  501.    state.
  502.  
  503.    The server now sends a TPKT with code CC containing:
  504.  
  505.       - the TSAP ID of the TS-user responding to the connection
  506.         (usually the "called")
  507.       - if an expedited port was specified in the TPKT with code CR,
  508.  
  509.  
  510.  
  511.  
  512. Cass & Rose                                                     [Page 9]
  513.  
  514.  
  515.  
  516. RFC 983                                                       April 1986
  517. ISO Transport Services on Top of the TCP
  518.  
  519.  
  520.         the TSAP ID of the port number on the server's host that was
  521.         used to connect to the expedited port
  522.       - any TS-user data from the T-CONNECT.RESPONSE
  523.  
  524.    After sending the TPKT, the server enters the SYMMETRIC PEER state.
  525.  
  526.    The client, upon receipt of the TPKT, validates the contents of the
  527.    TPKT (checking the version number, verifying that the code is CC or
  528.    DR, and so forth).  If the packet is invalid, the client sends a TPKT
  529.    with code DR specifying "PROTOCOL ERROR", fires
  530.    T-DISCONNECT.INDICATION with this error to the TS-user, and closes
  531.    the TCP connection (and the expedited port, if any).
  532.  
  533.    If the packet's code is DR, the client fires T-DISCONNECT.INDICATION
  534.    with the reason given in the TPKT to the TS-user, and closes the TCP
  535.    connection (and the expedited port, if any).
  536.  
  537.    If the packet's code is CC, the client checks if an expedited port
  538.    was specified and that a connection is waiting on the expedited port.
  539.    If not, a protocol error has occurred, a TPKT with code DR is
  540.    returned, T-DISCONNECT.INDICATION is fired, and so on.  Otherwise,
  541.    the client checks the remote address that connected to the expedited
  542.    port.  If it differs from the port listed in the TPKT with code CC, a
  543.    protocol error has occurred.  Otherwise, all is well, two TCP
  544.    connections have been established, one for all TPKTs except expedited
  545.    data, and the second for the exclusive use of expedited data.
  546.  
  547.    The client now fires T-CONNECT.CONFIRMATION, and enters the SYMMETRIC
  548.    PEER state.
  549.  
  550.    Once both sides have reached the SYMMETRIC PEER state, the protocol
  551.    is completely symmetric, the notion of client/server is lost.  Both
  552.    TS-peers act in the following fashion:
  553.  
  554.    If the TCP indicates that data can be read, the TS-peer, upon receipt
  555.    of the TPKT, validates the contents.  If the packet is invalid, the
  556.    TS-peer sends a TPKT with code DR specifying "PROTOCOL ERROR", fires
  557.    T-DISCONNECT.INDICATION with this error to the TS-user, and closes
  558.    the TCP connection (and expedited data connection, if any).  If the
  559.    TS-peer was the server, it goes back to the LISTEN state.
  560.  
  561.       NOTE:  If the expedited data option was requested, then there are
  562.       two TCP connections that can supply data for reading.  The
  563.       dialogue below assumes that only ED TPKTs are read from the
  564.       expedited data connection. For simplicity's sake, when reading
  565.       from TCP the relation between connections and TPKTs is unimportant
  566.       and this memo URGES all implementations to be very lenient in this
  567.  
  568.  
  569. Cass & Rose                                                    [Page 10]
  570.  
  571.  
  572.  
  573. RFC 983                                                       April 1986
  574. ISO Transport Services on Top of the TCP
  575.  
  576.  
  577.       regard.  When writing to TCP, implementations should use the
  578.       expedited data connection only to send TPKTs with code ED.
  579.       Section 7 of this memo discusses the handling of expedited data in
  580.       greater detail.
  581.  
  582.    If the packet's code is DR, the TS-peer fires T-DISCONNECT.INDICATION
  583.    with the reason given in the TPKT to the TS-user, and closes the TCP
  584.    connection (and expedited data connection, if any).  If the TS-peer
  585.    was the server, it goes back to the LISTEN state.
  586.  
  587.    If the packet's code is ED or DT, the TS-peer fires T-DATA.INDICATION
  588.    or T-EXPEDITED DATA.INDICATION as appropriate with the enclosed user
  589.    data for the TS-user.  It then goes back to the SYMMETRIC PEER state.
  590.  
  591.    If the packet is invalid, the TS-peer sends a TPKT with code DR
  592.    specifying "PROTOCOL ERROR", fires T-DISCONNECT.INDICATION with this
  593.    error to the TS-user, and closes the TCP connection (and expedited
  594.    data connection, if any).  If the TS-peer was the server, it goes
  595.    back to the LISTEN state.
  596.  
  597.    If the TCP indicates that an error has occurred and the connection
  598.    has closed, then the TS-peer fires T-DISCONNECT.INDICATION to the
  599.    TS-user specifying the reason for the failure.  If the expedited data
  600.    connection, if any, is still open, it is closed.  If the TS-peer was
  601.    the server, it goes back to the LISTEN state.
  602.  
  603.    If the TS-user issues a T-DATA.REQUEST or T-EXPEDITED DATA.REQUEST
  604.    action, the TS-peer sends a TPKT with code DT or ED containing the
  605.    TS-user data.  It then goes back to the SYMMETRIC PEER state.
  606.  
  607.    If the TS-user issues a T-DISCONNECT.REQUEST action, the TS-peer
  608.    sends a TPKT with code DR containing the reason for the disconnect as
  609.    supplied by the TS-user.  The TS-peer then closes the TCP connection,
  610.    (and expedited data connection, if any).  If the TS-peer was the
  611.    server, it goes back to the LISTEN state.
  612.  
  613.    In terms of (augmented) state tables, the protocol can be explained
  614.    as follows.  The server starts in state S0, the client starts in
  615.    state C0.  "TCP:"  refers to an event or action from the TCP service,
  616.    "SS:"  refers to an event or action from the TS-user (e.g., the ISO
  617.    session service [ISO-8327]).
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626. Cass & Rose                                                    [Page 11]
  627.  
  628.  
  629.  
  630. RFC 983                                                       April 1986
  631. ISO Transport Services on Top of the TCP
  632.  
  633.  
  634.                         S E R V E R   S T A T E S
  635.  
  636.    state        event                   action                      goto
  637.    -----        -----                   ------                      ----
  638.    S0                                   TCP: listen on port 102     S1
  639.  
  640.    S1           TCP: connected          TCP: read TPKT
  641.                                         parse, on error
  642.                                           TCP: send DR, close       S0
  643.                                         code is CR
  644.                                           start session server
  645.                                           SS: T-CONNECT             S2
  646.                                                 .INDICATION
  647.                                         otherwise,
  648.                                           TCP: send DR, close       S0
  649.  
  650.    S2           SS: T-CONNECT.RESPONSE  if expedited option,
  651.                                           TCP: open port EXPD
  652.                                         TCP: send CC                P0
  653.  
  654.    S2           SS: T-DISCONNECT        TCP: send DR, close         S0
  655.                         .REQUEST
  656.  
  657.    Any event occuring for a state not listed above is considered an
  658.    error, and handled thusly:
  659.  
  660.    state        event                   action                      goto
  661.    -----        -----                   ------                      ----
  662.    S*           TCP: other              if TCP is open, TCP: close  S0
  663.                                         otherwise ignore            S0
  664.    S*           SS: other               SS: T-DISCONNECT
  665.                                               .INDICATION
  666.                                         if TCP is open, close       S0
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683. Cass & Rose                                                    [Page 12]
  684.  
  685.  
  686.  
  687. RFC 983                                                       April 1986
  688. ISO Transport Services on Top of the TCP
  689.  
  690.  
  691.                         C L I E N T   S T A T E S
  692.  
  693.    state        event                   action                      goto
  694.    -----        -----                   ------                      ----
  695.    C0           SS: T-CONNECT.REQUEST   if expedited option,
  696.                                           TCP: non-blocking
  697.                                                listen on port EXPD
  698.                                         TCP: open port 102          C1
  699.  
  700.    C1           TCP: connected          TCP: send CR                C2
  701.  
  702.    C1           TCP: connect fails      TCP: close
  703.                                         SS: T-DISCONNECT            C0
  704.                                                  .INDICATION
  705.    
  706.  
  707.    C2           TCP: data ready         TCP: read TPKT
  708.                                         parse, on error
  709.                                           TCP: send DR, close
  710.                                           SS: T-DISCONNECT          C0
  711.                                                 .INDICATION
  712.                                         code is CC
  713.                                           if expedited option,
  714.                                              verify port EXPD
  715.                                              connected correctly,
  716.                                              if not, treat as error
  717.                                           SS: T-CONNECT             P0
  718.                                                 .CONFIRMATION
  719.                                         code is DR
  720.                                           TCP: close
  721.                                           SS: T-DISCONNECT          C0
  722.                                                 .INDICATION
  723.                                         otherwise
  724.                                           TCP: send DR, close
  725.                                           SS: T-DISCONNECT          C0
  726.                                                 .INDICATION
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740. Cass & Rose                                                    [Page 13]
  741.  
  742.  
  743.  
  744. RFC 983                                                       April 1986
  745. ISO Transport Services on Top of the TCP
  746.  
  747.  
  748.    Any event occuring for a state not listed above is considered an
  749.    error, and handled thusly:
  750.  
  751.    state        event                   action                      goto
  752.    -----        -----                   ------                      ----
  753.    C*           TCP: other              if TCP is open, close       C0
  754.                                         otherwise ignore            C0
  755.  
  756.    C*           SS: other               SS: T-DISCONNECT
  757.                                               .INDICATION
  758.                                         if TCP is open, close       C0
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797. Cass & Rose                                                    [Page 14]
  798.  
  799.  
  800.  
  801. RFC 983                                                       April 1986
  802. ISO Transport Services on Top of the TCP
  803.  
  804.  
  805.                           P E E R   S T A T E S
  806.  
  807.    state        event                   action                      goto
  808.    -----        -----                   ------                      ----
  809.    P0           TCP: data ready         TCP: read TPKT
  810.                                         parse, on error
  811.                                           TCP: send DR, close
  812.                                           SS: T-DISCONNECT          end
  813.                                                 .INDICATION
  814.                                         code is DT
  815.                                           SS: T-DATA.INDICATION      P0
  816.                                         code is ED
  817.                                           SS: T-EXPEDITED DATA       P0
  818.                                                 .INDICATION
  819.                                         code is DR
  820.                                           TCP: close
  821.                                           SS: T-DISCONNECT          end
  822.                                                 .INDICATION
  823.                                         otherwise
  824.                                           TCP: send DR, close
  825.                                           SS: T-DISCONNECT          end
  826.                                                 .INDICATION
  827.  
  828.    P0           TCP: other              TCP: close
  829.                                         SS: T-DISCONNECT            end
  830.                                                   .INDICATION
  831.  
  832.    P0           SS: T-DATA.REQUEST      TCP: send DT                 P0
  833.  
  834.    P0           SS: T-EXPEDITED DATA    TCP: send ED                 P0
  835.                         .REQUEST
  836.  
  837.    P0           SS: T-DISCONNECT        TCP: send DR, close         end
  838.                         .REQUEST
  839.  
  840.    P0           SS: other               TCP: send DR, close
  841.                                         SS: T-DISCONNECT            end
  842.                                                 .INDICATION
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854. Cass & Rose                                                    [Page 15]
  855.  
  856.  
  857.  
  858. RFC 983                                                       April 1986
  859. ISO Transport Services on Top of the TCP
  860.  
  861.  
  862. 6.  Packet Format
  863.  
  864.    Two TS-peers exchange information over a TCP connection by
  865.    encapsulating information in well-defined packets.  A packet, denoted
  866.    as "TPKT" in the previous sections, is viewed as an object composed
  867.    of an integral number of octets, of variable length.
  868.  
  869.       NOTE:  For the purposes of presentation, these objects are shown
  870.       as being 4 octets (32 bits wide).  This representation is an
  871.       artifact of the style of this memo and should not be interpreted
  872.       as requiring that a TPDU be a multiple of 4 octets in length.
  873.  
  874.    A packet consists of two parts: a packet-header and a pseudo-TPDU.
  875.    The format of the header is constant regardless of the type of
  876.    packet.  The format of the pseudo-TPDU follows the [ISO-8073]
  877.    recommendation very closely with the exceptions listed below.  As per
  878.    [ISO-8073], each TPDU consists of two parts: header and data.
  879.  
  880.    It is EXTREMELY important to observe that TPKTs represent
  881.    "indivisible" units of data to the TS-user.  That is, a
  882.    T-DATA.REQUEST initiated by the TS-user at the sending end of a
  883.    connection should result in exactly one T-DATA.INDICATION being
  884.    generated (with exactly that data) for the TS-user at the receiving
  885.    end.  To ensure this behavior, it is critical that any INDICATION
  886.    event resulting from a TPKT be initiated ONLY after the entire TPKT
  887.    is fully received.  Furthermore, exactly one such INDICATION event
  888.    should be generated by the TS-peer.  The packet length field, as
  889.    described below, can accommodate on the order of 65K octets of user
  890.    data.  This should be well above the requirements of the size of any
  891.    SPDU (Session Protocol Data Unit) for any real implementation.  As a
  892.    result, version 1 of this protocol has no need to either fragment or
  893.    re-assemble TS-user data.  If an application arises which requires an
  894.    SPDU of size greater than 65K octets, this memo will be revised.
  895.  
  896.    The format of the packet-header is as follows:
  897.  
  898.        0                   1                   2                   3   
  899.        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 
  900.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  901.       |      vrsn     |    reserved   |          packet length        |
  902.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  903.  
  904.    where:
  905.  
  906.       1.  vrsn                  8 bits
  907.  
  908.          This field is always 1 for this memo.
  909.  
  910.  
  911. Cass & Rose                                                    [Page 16]
  912.  
  913.  
  914.  
  915. RFC 983                                                       April 1986
  916. ISO Transport Services on Top of the TCP
  917.  
  918.  
  919.       2.  packet length         16 bits (min=8, max=65535)
  920.  
  921.          The length of entire packet in octets, including packet-header.
  922.  
  923.    The format of the TPDU (to re-phrase from [ISO-8073]) depends on the
  924.    type of a TPDU.  All TPDUs start with a fixed-part header length and
  925.    the code.  The information following after the code varies, depending
  926.    on the value of the code.  In the context of this memo, the following
  927.    codes are valid:
  928.  
  929.       CR: connect request
  930.       CC: connect confirm
  931.       DR: disconnect request
  932.       DT: data
  933.       ED: expedited data
  934.  
  935.    The format of a CR or CC TPDU is:
  936.  
  937.        0                   1                   2                   3   
  938.        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 
  939.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  940.       | header length | code  | credit|     destination reference     |
  941.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  942.       |       source reference        | class |options| variable data |
  943.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  944.       |    ...        |      ...      |      ...      |      ...      |
  945.       |    ...        |      ...      |      ...      |      ...      |
  946.       |    ...        |   user data   |      ...      |      ...      |
  947.       |    ...        |      ...      |      ...      |      ...      |
  948.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  949.  
  950.    where:
  951.  
  952.       3.  header length          8 bits (min=6, max=min(254,packet
  953.       length-6))
  954.  
  955.          The TPDU-header length in octets including parameters but
  956.          excluding the header length field and user data (if any).
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968. Cass & Rose                                                    [Page 17]
  969.  
  970.  
  971.  
  972. RFC 983                                                       April 1986
  973. ISO Transport Services on Top of the TCP
  974.  
  975.  
  976.       4.  code                   4 bits
  977.  
  978.          The type of TPDU.  Values, in the context of this memo, are:
  979.  
  980.             value       meaning
  981.             -----       -------
  982.              14         CR: connection request  (binary 1110)
  983.              13         CC: connection confirm  (binary 1101)
  984.               8         DR: disconnect request  (binary 1000)
  985.              15         DT: data                (binary 1111)
  986.               1         ED: expedited data      (binary 0001)
  987.             all other   reserved                             
  988.  
  989.       5.  credit                 4 bits
  990.  
  991.          This field is always ZERO on output and ignored on input.
  992.  
  993.       6.  destination reference 16 bits
  994.  
  995.          This field is always ZERO on output and ignored on input.
  996.  
  997.       7.  source reference      16 bits
  998.  
  999.          This field is always ZERO on output and ignored on input.
  1000.  
  1001.       8.  class                  4 bits
  1002.  
  1003.          This field is always 4 (binary 0100) on output and ignored on
  1004.          input. It is anticipated that future versions of this protocol
  1005.          will make use of this field.
  1006.  
  1007.       9.  options                4 bits
  1008.  
  1009.          This field is always ZERO on output and ignored on input.
  1010.  
  1011.       10.  variable data        (header length - 6) octets
  1012.  
  1013.          This portion of the TPDU is of variable length.  For most
  1014.          TPDUs, this portion is empty (the header length field of the
  1015.          TPDU is exactly 6).  The contents of the variable data consist
  1016.          of zero or more "parameters".  Each parameter has the following
  1017.          format:
  1018.  
  1019.             parameter code        1 octet in size
  1020.             parameter length      1 octet in size, value is the number
  1021.                                     of octets in parameter value
  1022.             parameter value       parameter data
  1023.  
  1024.  
  1025. Cass & Rose                                                    [Page 18]
  1026.  
  1027.  
  1028.  
  1029. RFC 983                                                       April 1986
  1030. ISO Transport Services on Top of the TCP
  1031.  
  1032.  
  1033.          Normally, the parameter length is 1 octet.  Any implementation
  1034.          conforming to this version of the protocol must recognize all
  1035.          parameter types listed in [ISO-8073].  With the exception of
  1036.          the parameters listed below, these parameters are simply
  1037.          ignored.
  1038.  
  1039.          o   Parameter name:       Transport service access point
  1040.                                    identifier (TSAP-ID) of the client
  1041.          TSAP
  1042.  
  1043.             Parameter code:        193 (binary 1100 0001)
  1044.             Parameter length:      variable
  1045.             Parameter value:       TSAP-ID attributes
  1046.  
  1047.             Each TSAP-ID consists of 1 or more attributes.  Each
  1048.             attribute has this format:
  1049.  
  1050.                Attribute code      1 octet in size
  1051.                Attribute length    1 octet in size, value is the number
  1052.                                      of octets in attribute value
  1053.                Attribute value     attribute data
  1054.  
  1055.             In version 1 of this protocol, only two attributes are
  1056.             defined. All others are reserved.
  1057.  
  1058.                Attribute name:     Internet Address
  1059.  
  1060.                Attribute code:     1
  1061.                Attribute length:   6
  1062.                Attribute value:    IP address (4 octets)
  1063.                                    session port (2 octets, unsigned
  1064.                                    integer)
  1065.  
  1066.                   This attribute is ALWAYS required.  Values for session
  1067.                   port can be found in Appendix A of this memo.
  1068.  
  1069.                Attribute name:     Internet Address for Expedited Data
  1070.  
  1071.                Attribute code:     2
  1072.                Attribute length:   6
  1073.                Attribute value:    IP address (4 octets)
  1074.                                    TCP port (2 octets, unsigned integer)
  1075.  
  1076.                   This attribute is required ONLY if expedited data is
  1077.                   to be exchanged.  The attribute value is an <IP
  1078.                   address, TCP port> pair designated by the TS-peer for
  1079.                   use with expedited data.
  1080.  
  1081.  
  1082. Cass & Rose                                                    [Page 19]
  1083.  
  1084.  
  1085.  
  1086. RFC 983                                                       April 1986
  1087. ISO Transport Services on Top of the TCP
  1088.  
  1089.  
  1090.          o   Parameter name:       TSAP-ID of the server TSAP
  1091.  
  1092.             Parameter code:        194 (binary 1100 0010)
  1093.             Parameter length:      variable
  1094.             Parameter value:       TSAP-ID attributes
  1095.  
  1096.          o   Parameter name:       Additional option selection
  1097.  
  1098.             Parameter code:        198 (binary 1100 0110)
  1099.             Parameter length:      1
  1100.             Parameter value:       additional flags
  1101.  
  1102.             The additional flags octet consists of 8-bits of optional
  1103.             flags.  Only one bit is of interest to this memo, the
  1104.             remaining bits should be ZERO on output and ignored on
  1105.             input.  This bit indicates if the transport expedited data
  1106.             service is to be used.  If this bit is set (bit mask 0000
  1107.             0001) or this parameter does not appear in the TPDU, then
  1108.             the expedited data service is requested.  If this parameter
  1109.             appears in the TPDU and the bit is not set then the service
  1110.             is disabled.  If the service is requested, then the TSAP-ID
  1111.             of the sender of the TPDU must include an attribute
  1112.             indicating the internet address to use for expedited data.
  1113.  
  1114.          o   Parameter name:       Alternative protocol classes
  1115.  
  1116.             Parameter code:        199 (binary 1100 0111)
  1117.  
  1118.             Parameter length:      variable
  1119.             Parameter value:       64 (binary 0100 0000) in each octet
  1120.  
  1121.                This is used as a NOOP in the variable data.  Its use is
  1122.                HIGHLY discouraged, but for those implementors who wish
  1123.                to align the user data portion of the TPDU on word (or
  1124.                page) boundaries, use of this parameter for filling is
  1125.                recommended.
  1126.  
  1127.       11.  user data            (packet length - header length - 5)
  1128.                                    octets
  1129.  
  1130.          This portion of the TPDU is actual user data, most probably one
  1131.          or more SPDUs (session protocol data units).
  1132.  
  1133.  
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139. Cass & Rose                                                    [Page 20]
  1140.  
  1141.  
  1142.  
  1143. RFC 983                                                       April 1986
  1144. ISO Transport Services on Top of the TCP
  1145.  
  1146.  
  1147.    The format of a DR TPDU is:
  1148.  
  1149.        0                   1                   2                   3   
  1150.        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
  1151.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1152.       | header length | code  | credit|     destination reference     |
  1153.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1154.       |       source reference        |     reason    | variable data |
  1155.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1156.       |    ...        |      ...      |      ...      |      ...      |
  1157.       |    ...        |      ...      |      ...      |      ...      |
  1158.       |      ...      |   user data   |      ...      |      ...      |
  1159.       |    ...        |      ...      |      ...      |      ...      |
  1160.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1161.  
  1162.    The format of the fields is identical to those of a CR or CC TPDU,
  1163.    with the following exceptions:
  1164.  
  1165.    where:
  1166.  
  1167.       8.  reason                        8 bits
  1168.  
  1169.          This replaces the class/option fields of the CR or CC TPDU. Any
  1170.          value, as specified in [ISO-8073], may be used in this field.
  1171.          This memo makes use of several:
  1172.  
  1173.             value       meaning
  1174.             -----       -------
  1175.               1         Congestion at TSAP
  1176.               2         Session entity not attached to TSAP
  1177.               3         Address unknown (at TCP connect time)
  1178.             128+0       Normal disconnect initiated by the session
  1179.                         entity
  1180.             128+1       Remote transport entity congestion at connect
  1181.                         request time
  1182.             128+3       Connection negotiation failed
  1183.             128+5       Protocol Error
  1184.             128+8       Connection request refused on this network
  1185.                         connection
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196. Cass & Rose                                                    [Page 21]
  1197.  
  1198.  
  1199.  
  1200. RFC 983                                                       April 1986
  1201. ISO Transport Services on Top of the TCP
  1202.  
  1203.  
  1204.    The format of a DT or ED TPDU is:
  1205.  
  1206.        0                   1                   2                   3   
  1207.        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 
  1208.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ 
  1209.       | header length | code  | credit|         TPDU-NR and EOT       |
  1210.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1211.       |   user data   |      ...      |      ...      |      ...      |
  1212.       |    ...        |      ...      |      ...      |      ...      |
  1213.       |    ...        |      ...      |      ...      |      ...      |
  1214.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1215.  
  1216.    where:
  1217.  
  1218.       After the credit field (which is always ZERO on output and ignored
  1219.       on input), there is one additional field prior to the user data:
  1220.  
  1221.       6.  TPDU-NR and EOT               16 bits
  1222.  
  1223.          This field is always ZERO on output and ignored on input.
  1224.  
  1225. 7.  Expedited Data
  1226.  
  1227.    This memo utilizes a second TCP connection to handle expedited data
  1228.    and does not make use of the TCP URGENT mechanism.  The primary
  1229.    disadvantage of this decision is that single-threaded implementations
  1230.    of TCP may have some difficulty in supporting two simultaneous
  1231.    connections.  There are however several advantages to this approach:
  1232.  
  1233.       a.  Use of a single connection to implement the semantics of
  1234.       expedited data implies that the TSAP peer manage a set of buffers
  1235.       independent from TCP.  The peer would, upon indication of TCP
  1236.       urgent information, have to buffer all preceeding TPKTs until the
  1237.       TCP buffer was empty.  Expedited data would then be given to the
  1238.       TS-user.  When the expedited data was flushed, then the buffered
  1239.       (non-expedited) data could be passed up to the receiving user.
  1240.  
  1241.       b.  It assumes that implementations support TCP urgency correctly.
  1242.       This is perhaps an untrue assumption, particular in the case of
  1243.       TCP urgency occuring when the send window is zero-sized.  Further,
  1244.       it assumes that the implementations can signal this event to the
  1245.       TCP-user in a meaningful fashion.  In a single-threaded
  1246.       implementation, this is not likely.
  1247.  
  1248.    Given a reasonable TCP implementation, the TS-peer need listen on two
  1249.  
  1250.  
  1251.  
  1252.  
  1253. Cass & Rose                                                    [Page 22]
  1254.  
  1255.  
  1256.  
  1257. RFC 983                                                       April 1986
  1258. ISO Transport Services on Top of the TCP
  1259.  
  1260.  
  1261.    TCP sockets in either polling or interrupt mode.  When the TS-peer is
  1262.    given data, the TCP must indicate which connection should be read
  1263.    from.
  1264.  
  1265.    The only tricky part of the protocol is that the client must be able
  1266.    to start a passive OPEN for the expedited port, and then wait to read
  1267.    from another connection.  In between the passive OPEN and the other
  1268.    connection supplying data, the server will connect to the expedited
  1269.    port, prior to sending data on the other connection.  To summarize
  1270.    from Section 5, the sequence of events, with respect to TCP, is:
  1271.  
  1272.       time      client                          Server
  1273.       ----      ------                          ------
  1274.       0.                                        passive OPEN of port 102
  1275.  
  1276.       1.        T-CONNECT.REQUEST from user
  1277.                 passive OPEN of expedited
  1278.                 port (non-blocking)
  1279.  
  1280.       2.        active OPEN of port 102
  1281.  
  1282.       3.        send CC TPKT
  1283.  
  1284.       4.                                        port 102 connected
  1285.  
  1286.       5.                                        receive CC TPKT
  1287.                                                 T-CONNECT.INDICATION to
  1288.                                                 user
  1289.                                                 T-CONNECT.RESPONSE from
  1290.                                                 user
  1291.  
  1292.       6.                                        active OPEN to expedited
  1293.                                                 port
  1294.  
  1295.       7.        expedited port connected
  1296.  
  1297.       8.                                        send CR TPKT
  1298.  
  1299.       9.        receive CR TPKT
  1300.                 verify expedited port
  1301.                 connected correctly
  1302.  
  1303.    Multi-threaded implementations of TCP should be able to support this
  1304.    sequence of events without any great difficulty.
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310. Cass & Rose                                                    [Page 23]
  1311.  
  1312.  
  1313.  
  1314. RFC 983                                                       April 1986
  1315. ISO Transport Services on Top of the TCP
  1316.  
  1317.  
  1318. 8.  Conclusions
  1319.  
  1320.    There are two design decisions which should be considered.  The first
  1321.    deals with particular packet format used.  It should be obvious to
  1322.    the reader that the TP packet format was adopted for use in this
  1323.    memo.  Although this results in a few fields being ignored (e.g.,
  1324.    source reference), it does not introduce an unacceptable amount of
  1325.    overhead.  For example, on a connection request packet (the worst
  1326.    case) there are 6 bytes of "zero on output, ignore on input" fields.
  1327.    Considering that the packet overhead processing is fixed, requiring
  1328.    that implementations allocate an additional 1.5 words is not
  1329.    unreasonable!  Of course, it should be noted that some of these
  1330.    fields (i.e., class) may be used in future versions of the protocol
  1331.    as experience is gained.
  1332.  
  1333.    The second decision deals with how the TCP and TSAP port space is
  1334.    administered.  It is probably a very bad idea to take any
  1335.    responsibility, whatsoever, for managing this addressing space, even
  1336.    after ISO has stabilized.  There are two issues involved.  First, at
  1337.    what level do the TCP and TSAP port spaces interact; second, who
  1338.    defines what this interaction looks like.  With respect to the first,
  1339.    it wholly undesirable to require that each TSAP port map to a unique
  1340.    TCP port.  The administrative problems for the TCP "numbers czar (and
  1341.    czarina)" would be non-trivial.  Therefore, it is desirable to
  1342.    allocate a single TCP port, namely port 102, as the port where the
  1343.    "ISO Transport Services" live in the TCP domain. Second, the
  1344.    interaction defined in Appendix A of this memo is embryonic at best.
  1345.    It will no doubt be replaced as soon as the ISO world reaches
  1346.    convergence on how services are addressed in ISO TP. Therefore
  1347.    readers (and implementors) are asked to keep in mind that this aspect
  1348.    of the memo is guaranteed to change.  Unfortunately, the authors are
  1349.    not permitted the luxury of waiting for a consensus in ISO.  As a
  1350.    result, the minimal effort approach outlined in the appendix below
  1351.    was adopted.
  1352.  
  1353.    A prototype implementation of the protocol described by this memo is
  1354.    available for 4.2BSD UNIX.  Interested parties should contact the
  1355.    authors for a copy.  To briefly mention its implementation, a given
  1356.    ISO service is implemented as a separate program.  A daemon listens
  1357.    on TCP port 102, consults a database when a connection request packet
  1358.    is received, and fires the appropriate program for the ISO service
  1359.    requested.  Of course, given the nature of the BSD implementation of
  1360.    TCP, as the child fires, responsibility of that particular connection
  1361.    is delegated to the child; the daemon returns to listening for new
  1362.    connection requests.  The prototype implementation consists of both
  1363.    the daemon program and subroutine libraries which are loaded with
  1364.    programs providing ISO services.
  1365.  
  1366.  
  1367. Cass & Rose                                                    [Page 24]
  1368.  
  1369.  
  1370.  
  1371. RFC 983                                                       April 1986
  1372. ISO Transport Services on Top of the TCP
  1373.  
  1374.  
  1375. 9.  References
  1376.  
  1377.    [ISO-8072]   ISO.
  1378.                 "International Standard 8072.  Information Processing
  1379.                 Systems -- Open Systems Interconnection: Transport
  1380.                 Service Definition."
  1381.                 (June, 1984)
  1382.  
  1383.    [ISO-8073]   ISO.
  1384.                 "International Standard 8073.  Information Processing
  1385.                 Systems -- Open Systems Interconnection: Transport
  1386.                 Protocol Specification."
  1387.                 (June, 1984)
  1388.  
  1389.    [ISO-8327]   ISO.
  1390.                 "International Standard 8327.  Information Processing
  1391.                 Systems -- Open Systems Interconnection: Session
  1392.                 Protocol Specification."
  1393.                 (June, 1984)
  1394.  
  1395.    [RFC-791]    Internet Protocol.
  1396.                 Request for Comments 791
  1397.                 (September, 1981)
  1398.                 (See also: MIL-STD-1777)
  1399.  
  1400.    [RFC-793]    Transmission Control Protocol.
  1401.                 Request for Comments 793
  1402.                 (September, 1981)
  1403.                 (See also: MIL-STD-1778)
  1404.  
  1405.    [RFC-960]    Assigned Numbers.
  1406.                 Request for Comments 960
  1407.                 (December, 1985)
  1408.  
  1409.    [X.214]      CCITT.
  1410.                 "Recommendation X.214.  Transport Service Definitions
  1411.                 for Open Systems Interconnection (OSI) for CCITT
  1412.                 Applications."
  1413.                 (October, 1984)
  1414.  
  1415.    [X.224]      CCITT.
  1416.                 "Recommendation X.224.  Transport Protocol Specification
  1417.                 for Open Systems Interconnection (OSI) for CCITT
  1418.                 Applications."
  1419.                 (October, 1984)
  1420.  
  1421.  
  1422.  
  1423.  
  1424. Cass & Rose                                                    [Page 25]
  1425.  
  1426.  
  1427.  
  1428. RFC 983                                                       April 1986
  1429. ISO Transport Services on Top of the TCP
  1430.  
  1431.  
  1432.    [X.225]      CCITT.
  1433.                 "Recommendation X.225.  Session Protocol Specification
  1434.                 for Open Systems Interconnection (OSI) for CCITT
  1435.                 Applications."
  1436.                 (October, 1984)
  1437.  
  1438.    [X.410]      CCITT.
  1439.                 "Recommendation X.410.  Message Handling Systems: Remote
  1440.                 Operations and Reliable Transfer Server."
  1441.                 (October, 1984)
  1442.  
  1443. Appendix A:  Reserved TSAP IDs
  1444.  
  1445.    Version 1 of this protocol uses a relatively simple encoding scheme
  1446.    for TSAP IDs.  A TSAP ID is an attribute list containing two
  1447.    parameters, a 32-bit IP address, and a 16-bit port number.  This is
  1448.    used to identify both the client TSAP and the server TSAP.  When it
  1449.    appears in a TPKT with code CR or CC, the TSAP ID is encoded in the
  1450.    variable data part for the client TSAP as:
  1451.  
  1452.        0                   1                   2                   3   
  1453.        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 
  1454.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1455.       |      193      |       8       |       1       |       6       |
  1456.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1457.       |       a       |       b       |       c       |       d       |
  1458.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1459.       |              port             |                               |
  1460.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1461.  
  1462.          and for the server TSAP as:
  1463.  
  1464.        0                   1                   2                   3   
  1465.        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 
  1466.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1467.       |      194      |       8       |       1       |       6       |
  1468.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1469.       |       a       |       b       |       c       |       d       |
  1470.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1471.       |              port             |                               |
  1472.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1473.  
  1474.    (Neither of these examples include an attribute for a TCP connection
  1475.    for expedited data.  If one were present, the length of the TSAP ID
  1476.    attribute would be 16 instead of 8, and the 8 bytes following the
  1477.    Internet address would be "2" for the attribute code, "6" for the
  1478.  
  1479.  
  1480.  
  1481. Cass & Rose                                                    [Page 26]
  1482.  
  1483.  
  1484.  
  1485. RFC 983                                                       April 1986
  1486. ISO Transport Services on Top of the TCP
  1487.  
  1488.  
  1489.    attribute length, and then 6 octets for the Internet address to use
  1490.    for expedited data, 4 octets for IP address, and 2 octets for TCP
  1491.    port.)
  1492.  
  1493.    Where [a.b.c.d] is the IP address of the host where the respective
  1494.    TSAP peer resides, and port is a 16-bit unsigned integer describing
  1495.    where in the TSAP port space the TS-user lives.
  1496.  
  1497.       Port value        Designation
  1498.       ----------        -----------
  1499.           0             illegal
  1500.          1-4096         privileged
  1501.       4097-65535        user
  1502.  
  1503.    The following table contains the list of the "official" TSAP ID port
  1504.    numbers as of the first release of this memo.  It is expected that
  1505.    future editions of the "Assigned Numbers" document[RFC-960] will
  1506.    contain updates to this list.
  1507.  
  1508.       Port    name        ISO service
  1509.       ----    ----        -----------
  1510.       1       echo        unofficial echo
  1511.       2       sink        unofficial data sink
  1512.       3       FTAM        File Transfer, Access, and Management
  1513.       4       VTS         ISO-8571 Virtual Terminal Service
  1514.       5       MHS         Message Handling System [X.411]
  1515.                           CCITT X.400
  1516.       6       JTM         Job Transfer and Manipulation
  1517.                           ISO 8831/8832
  1518.       7       CASE        Common Application Service Elements
  1519.                           Kernel ISO-8650/2
  1520.  
  1521.    If anyone knows of a list of "official" ISO services, the authors
  1522.    would be very interested.
  1523.  
  1524.  
  1525.  
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538. Cass & Rose                                                    [Page 27]
  1539.  
  1540.