INDRA
                                                       Working
                                                       Paper





     INDRA Note 959
     TSIG 4.0
     IEN 153
     29th July 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).

















     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 959

             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 TCP letter 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

       There are several ways a TCP connection  providing  a
     Yellow  Book  service  could  be  distinguished  from a
     normal TCP connection.  These are as follows:

      (i)    A single TCP port could be reserved for  Yellow
             Book  service.   Additional  multiplexing could
             then be provided using the  lines  proposed  in
             Annex III of the Yellow Book.

      (ii)   A number of TCP ports could be reserved for the
             different  higher level services required, each
             one of which would be defined as including  the
             enhancement defined within this document.



Bennett                         2                       INDRA 959

                      Yellow Book above TCP



      (iii)  A  TCP  option  could  be  defined  which  when
             associated   with   a   SYN  would  denote  the
             'enhanced TCP service' option - i.e.  the  data
             stream would be governed by this document.

     The first of these possibilities leads  to  unnecessary
     duplication  of  multiplexing  facilities  -  perfectly
     adequate multiplexing is already done within  the  TCP.
     The second is potentially restrictive in that it limits
     the growth  of  future  services,  and  would  probably
     eventually  lead  to the informal adoption of the first
     solution. This notes supports the third course, subject
     to  approval by the DARPA Internet Group. Proposed text
     defining the TCP option, using the format  of  the  TCP
     specification, is as follows:

        Enhanced TCP Service

          +--------+
          |00000010|
          +--------+
           Kind = 2

          This option specifies that the TCP connection
          is  providing  the  data  formats and command
          messages necessary to  support  the  enhanced
          services  offered  by the UK standard Network
          Independent Transport  Service.  This  option
          may  only  be  specified  in  the header of a
          packet which has the SYN bit set  to  1.   If
          the  receiving  process  is unable to support
          this option, the connection should be aborted
          via a RESET.

       The adoption of this option does not imply that a TCP
     itself is required to understand the structures of this
     document. It does allow such TCPs to be built. For TCPs
     which  do  not  support  these structures directly, the
     option is effectively a  null  option,  whose  presence
     should be indicated to the receiving process.

       Failing the adoption  of  this  facility,  the  first
     choice (of a single reserved port) is supported here.


     4.2 Identification of TCP Command Messages

       Once the connection  is  identified  as  providing  a
     Yellow  Book  TCP  service,  the next problem is how to
     identify TCP Command Messages within the  data  stream.
     The  X25 enhancement made use of the X25 Q-bit for this


Bennett                         3                       INDRA 959

                      Yellow Book above TCP



     purpose, but there is no corresponding function  within
     TCP. The choices are as follows:

      (i)    Provision of a  TCP  Q-bit  facility.  This  is
             unlikely   to  occur,  not  least  because  the
             example of XXX  shows  that  it  is  liable  to
             misuse.

      (ii)   Further definition of  the  'Enhanced  Service'
             option,  so  that the occurrence of this option
             with a letter specifies that the  letter  is  a
             Command Message.

      (iii)  Structuring the data stream itself.

     Despite the marginally greater data efficiency  of  the
     second choice, the last choice is supported here, as it
     requires no modification of the TCP user interface.  It
     does, however, require the transmission of a data octet
     which will require a fairly clever  user  interface  if
     extensive buffer copying is to be avoided.

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



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

          Figure 1: Letter Structure in Yellow Book TCP



     4.3 Structure of TCP Command Messages

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





Bennett                         4                       INDRA 959

                      Yellow Book above TCP



       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; thus no intermediate parameter may be omitted,
     though it may have a null value.  Parameters,  however,
     may  be  omitted  if they and all succeeding parameters
     have null values.

       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.





























Bennett                         5                       INDRA 959

                      Yellow Book above TCP



       This structure is summarised in Figure 2.

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

       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.

       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


Bennett                         6                       INDRA 959

                      Yellow Book above TCP



     unfortunate in the DARPA context through  its  specific
     association with the Internet Datagram Protocol.


     4.4 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,  except  where  otherwise noted.  Thus,
             the NIFTP port (octal 10651) at ISIE  (net  12,
             host 1, logical host 0, IMP 64) will be denoted
             by the string:

                     /12+200064+10651/



     4.4.1 CONNECT

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

          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.4.2 ACCEPT

       The  ACCEPT  command  message  is  defined   by   the


Bennett                         7                       INDRA 959

                      Yellow Book above TCP



     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).  If
     the  recall  address  and the quality of service do not
     differ from those specified in the CONNECT, the  ACCEPT
     will normally consist of the code octet only.


     4.4.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).

       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.



Bennett                         8                       INDRA 959

                      Yellow Book above TCP



      (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.4.4 DATA

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


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


     4.4.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 letter.

       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.  As
     noted above, TCP has no direct equivalent of a priority
     data channel, but the mechanism  described  allows  the
     preservation of EXPEDITED data so that it may be passed
     as such in subsequent networks.





Bennett                         9                       INDRA 959

                      Yellow Book above TCP



     4.4.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
     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.4.8 ADDRESS

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

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





Bennett                        10                       INDRA 959

                      Yellow Book above TCP



       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.


     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


Bennett                        11                       INDRA 959

                      Yellow Book above TCP



     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.

       The US Internetwork Group is likewise unfamiliar with
     the  concepts  and details of the Yellow Book Transport
     Service.  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  network,  as
     delimited by the TCP and its address space.

       Beyond this the document proposes a new  TCP  option.
     For  most existing TCPs this option will effectively be
     a null option which must be signalled to  the  user  at
     call setup time.  However, there is no reason why a TCP
     could not be built which contained the features of this
     note  as  optional  enhancements selectable by choosing
     the option.


     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 112. August 1979.













Bennett                        12                       INDRA 959

mirror server hosted at Truenetwork, Russian Federation.