INDRA
                                                       Working
                                                       Paper





     INDRA Note 965
     TSIG 4.1
     IEN 154
     7th August 1980










     Realization of the Yellow Book Transport Service Above TCP

                          C. J. Bennett





               ABSTRACT:  This  note  defines   an
               enhancement of the service provided
               by the US DoD Standard Transmission
               Control  Protocol  (TCP) sufficient
               to meet the requirements of the  UK
               Network    Independent    Transport
               Service  (the  Yellow  Book).  This
               note  supersedes an earlier version
               (INDRA Note 959, TSIG 4.0  and  IEN
               153).





                 Department of Computer Science

                    University College London







     1. Introduction

       This document defines a means of providing the Yellow
     Book  Transport  Service  [1]  above the DARPA Internet
     facilities, in particular TCP [2],  so  that  this  can
     then be used to support other services such as endpoint
     file transfer without requiring UK hosts  to  implement
     the   Internet   family   of   protocols.   It  assumes
     familiarity with both TCP and the Yellow Book.

       The basic  approach  taken  is  to  enhance  the  TCP
     service  along the lines suggested for enhancing X25 in
     Annex I of the Yellow Book,  taking  into  account  the
     different  services  provided  by TCP. In addition, the
     note discusses how to integrate Yellow Book TCP so that
     it can run alongside ordinary TCP - an issue the Yellow
     Book ignores for Yellow Book X25.


     2. Deficiencies of TCP

       A comparison of the  services  provided  by  TCP  and
     those  provided  by the Yellow Book reveals that TCP is
     unable to support directly, either in whole or in part,
     the following Yellow Book features:

      (i)    The RESET and ADDRESS primitives.

      (ii)   The  Yellow  Book  multiple-domain   addressing
             structure.  The TCP address space constitutes a
             single naming  domain  in  Yellow  Book  terms.
             Consequently,  features  involving addressing -
             notably ACCEPT - are inadequately supported  by
             TCP.

      (iii)  Much of  the  subsidiary  information  provided
             with  Yellow Book primitives. The fact that the
             source address provided  with  certain  actions
             such  as  DISCONNECT is not provided is again a
             limitation of the global TCP naming domain. The
             Yellow  Book 'Explanatory Text' parameters have
             no corresponding feature in TCP.

      (iv)   The closest equivalent to Yellow Book EXPEDITED
             data  - theoretically requiring a priority data
             channel - is  TCP  URGENT  data.  However,  TCP
             URGENT data remains in sequence, and the URGENT
             pointer only marks the end  of  the  data.  Its
             beginning is not delimited.

      (v)    The Yellow Book  DISCONNECT  is  a  full-duplex
             close,  whereas  the  TCP  CLOSE  is only half-
             duplex. The TCP RESET is  a  unilateral  close,
             used  in  error  conditions. Connection closure


Bennett                         1                       INDRA 965

                      Yellow Book above TCP



             provides particularly subtle problems.

     Hence in order to provide a Yellow Book  service  above
     TCP  an  enhancement of TCP is necessary. The remainder
     of this document discusses such an enhancement.


     3. Principles of the Enhancement

       The  basic  principles  of  the  enhancement  are  as
     follows:

      (i)    Where a TCP function corresponds directly to  a
             Yellow  Book function that TCP function is used
             directly.

      (ii)   Where the Yellow Book  function  requires  more
             information  or  action,  the  TCP  function is
             associated with a  TCP  Control  Message  in  a
             defined  way.  This  message  is  a  record  of
             defined  format  containing   the   information
             required.

      (iii)  Where there is no TCP  function  even  remotely
             corresponding   to  the  required  Yellow  Book
             function, a control message  is  defined  which
             may  be  used  by  the  source  and destination
             processes if possible,  and  may  be  forwarded
             into  other  transport  domains more capable of
             taking the appropriate action.



     4. The Yellow Book TCP Enhancement

     4.1 Distinguishing the Yellow Book TCP

       The services using the Yellow Book enhancement to the
     TCP  will be identifiable through the TCP socket number
     used. These will be allocated for standard services  as
     required.


     4.2 Identification of Yellow Book TCP Messages

       The data stream is structured into records, which  in
     turn  are  substructured  depending on the record type.
     These records are independent of TCP letter indications
     as the latter are purely push delimiters.




Bennett                         2                       INDRA 965

                      Yellow Book above TCP



       The record structure proposed is  as  illustrated  in
     Figure  1.  Each  record is prefaced by a single octet,
     known as the TYPE octet. This takes a value  of  0  for
     data records and a value of 1 for command messages. All
     other values are undefined.



            +------+-----  -  -  -  -  -  ------+
            | TYPE |        RECORD BODY         |
            +------+-----  -  -  -  -  -  ------+
                |
                |         /
                |        |  0 = DATA
                |-------<
                         |  1 = COMMAND
                          \

          Figure 1: Letter Structure in Yellow Book TCP



     4.3 Structure of TCP Data Messages

       A TCP Data Message is a Yellow  Book  TCP  record  of
     TYPE 0.

       Each record consists of a number of SUBRECORDS.  Each
     subrecord  consists  of  a header octet and a number of
     data octets, up to a limit of 127 octets.

       The subrecord header is a  single  octet.  The  high-
     order bit of this octet, if set to 1, declares that the
     current subrecord is the last subrecord of the  current
     record.  The  remaining seven bits define the length in
     octets of the current record.

















Bennett                         3                       INDRA 965

                      Yellow Book above TCP



       This structure is illustrated in Figure 2.

            +-------- - - - - - - - - --------+
            |           DATA MESSAGE          |
            +-------- - - - - - - - - --------+
           /                                   \
          /                                     \
         /                                       \
        /                                         \
       +-------- - - + - - - - - - - + - - --------+
       | SUBRECORD 1 |  ...........  | SUBRECORD K |      Data Record
       +-------- - - + - - - - - - - + - - --------+      Structure
       |               \
       |                   \
       |                       \
       |                            \
       +--------+------ - - - - - -------+
       | HEADER |          BODY          |    Subrecord Structure
       +--------+------ - - - - - -------+
       |          \
       |            \
       |              \
       +-+-+-+-+-+-+-+-+
       | |  C O U N T  |      Header Structure
       +-+-+-+-+-+-+-+-+
        |
        |--- EOR Bit

              Figure 2: TCP Data Message Structure


     4.4 Structure of TCP Command Messages

       A TCP Command Message is a Yellow Book TCP record  of
     TYPE 1.

       The first octet of the message  defines  the  COMMAND
     CODE  of  the  message.  These  codes  are  defined  in
     subsequent sections, and have been chosen to correspond
     to the command codes of the X25 Command Messages.

       Following the command code is a number of PARAMETERS.
     The  significance  of  these  parameters  is defined by
     their position  in  the  parameter  sequence  for  each
     command, and the command message is completed only when
     all parameters have been specified; thus  no  parameter
     may be omitted, though it may have a null value.






Bennett                         4                       INDRA 965

                      Yellow Book above TCP



       Most parameters have a free field  format.  For  this
     reason  each  parameter  is  constructed of a number of
     FRAGMENTS.  These fragments consist of  a  header  byte
     and  the body of the fragment, which may have a maximum
     length of 127 octets.

       The fragment header is a single octet. The high-order
     bit  of  this  octet,  if  set  to 1, declares that the
     current fragment is the last fragment  of  the  current
     parameter.  The  remaining seven bits define the length
     in octets of the current fragment.

       This structure is summarised in Figure 3.

            +-------- - - - - - - - - --------+
            |         COMMAND MESSAGE         |
            +-------- - - - - - - - - --------+
           /                                   \
         /                                       \
       /                                           \
      +------+-------- - - + - - - - - + - - -------+
      | CODE |   PARAM 1   |  .......  |   PARAM N  |   Command
      +------+-------- - - + - - - - - + - - -------+   Structure
            /                \
          /                       \
        /                             \
      /                                   \
     +-------- - - + - - - - - + - - --------+
     |    FRAG 1   |  .......  |   FRAG K    |      Parameter
     +-------- - - + - - - - - + - - --------+      Structure
     |               \
     |                   \
     |                       \
     |                            \
     +--------+------ - - - - - -------+
     | HEADER |          BODY          |    Fragment Structure
     +--------+------ - - - - - -------+
     |          \
     |            \
     |              \
     +-+-+-+-+-+-+-+-+
     | |  C O U N T  |      Header Structure
     +-+-+-+-+-+-+-+-+
      |
      |--- EOP Bit

             Figure 2: TCP Command Message Structure






Bennett                         5                       INDRA 965

                      Yellow Book above TCP



       A parameter with a null value  is  represented  by  a
     fragment  header  whose  EOP  bit is set to 1 and whose
     count field is set to 0. The rules governing the syntax
     of  free-field parameters are the same as those defined
     in section 2.7 of the Yellow Book, based on the use  of
     the IA5 character set, except where otherwise noted.

       The sole difference between this  structure  and  the
     X25  Command  Message structure is that the count field
     in the fragment header is extended by one  bit  -  this
     bit  is  used  for  a  specific  purpose in X25 CONNECT
     messages which  does  not  arise  with  the  TCP.  This
     doubles  the  maximum  fragment  size.  Because  of the
     similarity of structure the same terminology  has  been
     used,   though   the   term   'fragment'   is  somewhat
     unfortunate in the DARPA context through  its  specific
     association with the Internet Datagram Protocol.


     4.5 Yellow Book Commands and TCP

       The following general remarks apply to the  following
     specification:

      (i)    All codes are specified as decimal integers.

      (ii)   All address fields include the appropriate  TCP
             address      components,      specified      as
             /<NET ID>+<INTERNET HOST ID>+<PORT NO>/,  where
             the  bracketed fields are the character strings
             of  the  octal  representations  of  those  TCP
             fields.  Where  a field consists of more than 8
             bits, it is further subdivided into  eight  bit
             units  separated by commas for representational
             purposes.  Thus, the NIFTP port  (octal  10651)
             at  ISIE  (net  12, host 1, logical host 0, IMP
             64) will be denoted by the string:

                     /12+1,0,64+21,251/

      (iii)  All command messages must be accompanied  by  a
             TCP  end  of  letter  at  the  end  of the last
             fragment of the last parameter.



     4.5.1 CONNECT

       The  CONNECT  command  message  is  defined  by   the
     following code and parameters:



Bennett                         6                       INDRA 965

                      Yellow Book above TCP



          Code = 16
          Parameter 1: Called Address
          Parameter 2: Calling Address
          Parameter 3: Quality of Service
          Parameter 4: Explanatory Text

       This message  will  be  preceded  by  the  usual  TCP
     three-way handshake. Where possible or appropriate, the
     quality of service parameter will be used to select TCP
     quality  of service from the options defined in the TCP
     specification.

       The CONNECT message will be the first message sent by
     the  calling party. It will be possible for the calling
     party to initiate  the  transfer  of  data  before  the
     arrival of an ACCEPT message.


     4.5.2 ACCEPT

       The  ACCEPT  command  message  is  defined   by   the
     following code and parameters:

          Code = 17
          Parameter 1: Recall Address
          Parameter 2: Quality of Service
          Parameter 3: Explanatory Text

       This message will be the first message  sent  by  the
     called  party after the three-way handshake, unless the
     call request was rejected (see DISCONNECT, below).


     4.5.3 DISCONNECT

       The DISCONNECT command  message  is  defined  by  the
     following code and parameters:

          Code = 18
          Parameter 1: Reason
          Parameter 2: Address of DISCONNECT Initiator
          Parameter 3: Explanatory Text

       The reason parameter  is  a  single  octet  giving  a
     machine-oriented  encoding of the reason the DISCONNECT
     was  initiated.  The  defined  reasons  are  listed  in
     Appendix  B of the body of the Yellow Book. Parameter 2
     is included to cover the case where the DISCONNECT  was
     initiated by some intermediate gateway (where 'gateway'
     is used in the Yellow Book sense).



Bennett                         7                       INDRA 965

                      Yellow Book above TCP



       DISCONNECT will always cause  the  TCP  to  issue  an
     URGENT  call.   On  receipt of a DISCONNECT message, no
     further data may be sent and all data currently  queued
     for  transmission  should  be  flushed if possible.  No
     data  will  be  passed  across  to  the  user  after  a
     DISCONNECT has been issued.

       Beyond  this,  the  exact  DISCONNECT  sequence  used
     varies  depending  on  the  state of the connection, as
     follows:

      (i)    If the DISCONNECT is being  used  to  reject  a
             CONNECT request, the DISCONNECT message will be
             followed by a TCP RESET. This  will  abort  the
             TCP  connection, flushing all outstanding data.
             No response is  expected.  The  URGENT  pointer
             points to the TCP RESET.

      (ii)   In  the  normal  case  of   closing   an   open
             connection,   the   DISCONNECT  issued  by  the
             initiator will be followed by a  TCP  FIN.  The
             remote  party  will  respond  with  an optional
             DISCONNECT message accompanied by a FINACK  and
             a  FIN.  The  URGENT  pointer points to the TCP
             FIN.

      (iii)  For error terminations,  a  DISCONNECT  message
             should be answered with a TCP RESET. The issuer
             of the DISCONNECT will also issue a  TCP  RESET
             after  a  timeout  period,  if  a RESET has not
             already  been  received.   The  URGENT  pointer
             points to the end of the DISCONNECT message.



     4.5.4 DATA

       DATA is sent as a sequence of Yellow  Book  TCP  data
     messages, as defined above.


     4.5.5 PUSH

       The PUSH function is conveyed by use of the  TCP  EOL
     function,  pointing to the data octet at which the PUSH
     was issued.

       Note that it is possible to collapse EOL indications,
     effectively  combining  PUSHes.  Strictly speaking, the
     Yellow Book requires that a PUSH remains  in  sequence,
     but  this  is  not  necessary  to  obtain  the required


Bennett                         8                       INDRA 965

                      Yellow Book above TCP



     effect. In order to propagate the PUSH, it is necessary
     that  the  TCP  delivers  EOL  indications  to the user
     process. The circumstances under which this occurs  are
     currently unclear. It may be necessary in the future to
     define a PUSH command message.


     4.5.6 EXPEDITED

       The EXPEDITED  command  message  is  defined  by  the
     following code and parameter:

          Code = 21
          Parameter 1: EXPEDITED data

       EXPEDITED data is accompanied by a TCP URGENT pointer
     pointing  to  the  end  of  the  message.  There are no
     restrictions on the encoding of EXPEDITED data messages
     beyond the normal fragment structuring rules.

       It should be noted that this will cause the  receiver
     of  the  URGENT  to  process  all data up to the URGENT
     pointer in 'fast' mode, whether EXPEDITED  or  not.  It
     may  or  may  not  be possible to deliver the EXPEDITED
     data to the user ahead of sequence. As noted above, TCP
     has  no  direct  equivalent of a priority data channel,
     but  the  mechanism  described  at  least  allows   the
     preservation of EXPEDITED data so that it may be passed
     as such in subsequent networks.


     4.5.7 RESET

       The RESET command message is defined by the following
     code and parameters:

          Code = 19
          Parameter 1: Reason
          Parameter 2: Address of RESET Initiator
          Parameter 3: Explanatory Text

       TCP has no equivalent of the RESET  function  (a  TCP
     RESET  is  something  else entirely). Thus the only TCP
     action taken with a RESET message is  to  accompany  it
     with an URGENT pointer pointing to the end of the RESET
     message.

       As with DISCONNECT, the  defined  RESET  reasons  are
     those  listed  in Appendix B of the main portion of the
     Yellow Book. The address parameter is again included to
     cater  for the case where a RESET was initiated in some


Bennett                         9                       INDRA 965

                      Yellow Book above TCP



     intermediate network.

       A RESET may only be issued if the connection is fully
     open  and  there  are no RESETs already outstanding.  A
     RESET message must always be replied  to  with  another
     RESET  message, leaving the connection open, or with an
     error DISCONNECT message followed by a TCP RESET, which
     will  abort  the  connection.   All  data  and  control
     messages, with the exception  of  DISCONNECT,  received
     after  a RESET has been issued and before a RESET reply
     has been received, will be discarded without  informing
     the  user.  In  the  case of DISCONNECT, the connection
     will be considered as  having  closed  in  an  abnormal
     state.   If  a  DISCONNECT  has been issued, a received
     RESET will be ignored.

       Where possible the issue of a RESET should cause  the
     sender to flush its transmission buffers.


     4.5.8 ADDRESS

       The  ADDRESS  command  message  is  defined  by   the
     following code and parameters:

          Code = 20
          Parameter 1: Address
          Parameter 2: Address Qualifier

       The ADDRESS qualifier is  a  single  octet  parameter
     taking one of the values defined in the Yellow Book:

          0: The message is passing  towards  the  addressed
          object.

          1: The message is passing away from the  addressed
          object.

          2: An addressing error has been detected.

       There is no  associated  TCP  action  taken  with  an
     ADDRESS message.

       The receiver of an ADDRESS message will  perform  the
     appropriate  ADDRESS  transformation  as defined in the
     Yellow Book.

       It is recommended that the  ADDRESS  function  should
     not be used.


Bennett                        10                       INDRA 965

                      Yellow Book above TCP



     5. Conclusions

       One of the difficulties of writing  a  note  such  as
     this  is that it is addressed to several audiences with
     different interests and not necessarily a great deal of
     overlap either in aim or in background.

       The immediate audience  is  the  team  at  University
     College  London  who  are  involved  in  implementing a
     'Protocol Convertor' to  make  possible  direct  access
     between  hosts  in  Britain  using  the  CCITT  and  UK
     national standards and the hosts in the US based on the
     DARPA   Internet  standards.  For  this  audience,  the
     document hopefully defines an answer to what will  soon
     be  a  practical  need,  though  it  is  a  matter  for
     continuing debate to what extent the  full  enhancement
     defined here will be implemented.

       Within  Britain,  the  wider  audience  aimed  at  is
     centred  on  the Transport Service Implementors' Group.
     For this group, the aim of the document  will  be  well
     understood  -  it  is  defining  a  service enhancement
     similar to the one that is already defined for X25  and
     the  ones  they  are  defining  for  their local campus
     networks. The aim is  to  provide  a  common  transport
     service  for all these systems. They will be unfamiliar
     with the detailed nature of the TCP itself, but this is
     not  particularly  important. The major interest of the
     document  lies  in  the  fact  that  the  system  being
     enhanced  is  not  an  ordinary  local  network, but an
     entire  family   of   networks,   and   the   resultant
     enhancement will make possible direct authorised access
     between UK and US hosts. I would also like to point out
     the  issue  of separating Yellow Book enhancements from
     ordinary uses of a network service. This issue  is  not
     addressed by the X25 enhancement specification.

       Much  of  the  US  Internetwork  Group  is   likewise
     unfamiliar  with the concepts and details of the Yellow
     Book Transport Service. A  summary  of  these  concepts
     will  be  made available in a later IEN.  For them, the
     document will be of interest in that it  shows  how  to
     coordinate    two    very   different   approaches   to
     internetworking. The Catenet,  based  on  TCP,  can  be
     described  as a strongly connected internetwork system,
     with common transport protocols and  a  common  address
     space. The UK Transport Service takes an approach based
     on providing a common service interface, which leads to
     a weakly connected system with common service protocols
     and no common address space.  Within this approach, the
     entire  Internet  system  appears as a single component


Bennett                        11                       INDRA 965

                      Yellow Book above TCP



     network, as delimited by the TCP and its address space.


     6. References

     [1] - PSS User Forum  Study  Group  Three:  "A  Network
           Independent   Transport   Service"   SG3/CP(80)2.
           February 1980.

     [2] - Information  Sciences  Institute:   "Transmission
           Control Protocol" IEN 129.January 1980.











































Bennett                        12                       INDRA 965