2   Environment of implementation.

   The following sections describe some general approaches to
   implementing the transport protocol and the advantages and
   disadvantages of each.  Certain commercial products are identified
   throughout the rest of this document.  In no case does such
   identification imply the recommendation or endorsement of these
   products by the Department of Defense, nor does it imply that the
   products identified are the best available for the purpose described.
   In all cases such identification is intended only to illustrate the
   possibility of implementation of an idea or approach.  UNIX is a
   trademark of AT&T Bell Laboratories.

   Most of the discussions in the remainder of the document deal with
   Class 4 exclusively, since there are far more implementation issues
   with Class 4 than for Class 2.  Also, since Class 2 is logically a
   special case of Class 4, it is possible to implement Class 4 alone,
   with special provisions to behave as Class 2 when necessary.

2.1   Host operating system program.

   A common method of implementing the OSI transport service is to
   integrate the required code into the specific operating system
   supporting the data communications applications.  The particular
   technique for integration usually depends upon the structure and
   facilities of the operating system to be used.  For example, the
   transport software might be implemented in the operating system
   kernel, accessible through a standard set of system calls.  This
   scheme is typically used when implementing transport for the UNIX
   operating system.  Class 4 transport has been implemented using this
   technique for System V by AT&T and for BSD 4.2 by several
   organizations.  As another example, the transport service might be
   structured as a device driver.  This approach is used by DEC for the
   VAX/VMS implementation of classes 0, 2, and 4 of the OSI transport
   protocol.  The Intel iRMX-86 implementation of Class 4 transport is
   another example.  Intel implements the transport software as a first
   level job within the operating system.  Such an approach allows the
   software to be linked to the operating system and loaded with every

   boot of the system.

   Several advantages may accrue to the communications user when
   transport is implemented as an integral part of the operating system.
   First,  the interface to data communications services is well known
   to the application programmer since the same principles are followed
   as for other operating system services.  This allows the fast
   implementation of communications applications without the need for
   retraining of programmers.  Second, the operating system can support
   several different suites of protocols without the need to change
   application programs.  This advantage can be realized only with
   careful engineering and control of the user-system call interface to
   the transport services.  Third, the transport software may take
   advantage of the normally available operating system services such as
   scheduling, flow control, memory management, and interprocess
   communication.  This saves time in the development and maintenance of
   the transport software.

   The disadvantages that exist with operating system integration of the
   TP are primarily dependent upon the specific operating system.
   However, the major disadvantage, degradation of host application
   performance, is always present.  Since the communications software
   requires the attention of the processor to handle interrupts and
   process protocol events, some degradation will occur in the
   performance of host applications.  The degree of degradation is
   largely a feature of the hardware architecture and processing
   resources required by the protocol.  Other disadvantages that may
   appear relate to limited performance on the part of the
   communications service.  This limited performance is usually a
   function of the particular operating system and is most directly
   related to the method of interprocess communication provided with the
   operating system.  In general, the more times a message must be
   copied from one area of memory to another, the poorer the
   communications software will perform.  The method of copying and the
   number  of copies is often a function of the specific operating
   system.  For example, copying could be optimized if true shared
   memory is supported in the operating system.  In this case, a
   significant amount of copying can be reduced to pointer-passing.

2.2   User program.

   The OSI transport service can be implemented as a user job within any
   operating system provided a means of multi-task communications is
   available or can be implemented.  This approach is almost always a
   bad one.  Performance problems will usually exist because the
   communication task is competing for resources like any other
   application program.  The only justification for this approach is the
   need to develop a simple implementation of the transport service
   quickly.  The NBS implemented the transport protocol using this
   approach as the basis for a transport protocol correctness testing
   system.  Since performance was not a goal of the NBS implementation,

   the ease of development and maintenance made this approach
   attractive.

2.3   Independent processing element attached to a system bus.

   Implementation of the transport service on an independent processor
   that attaches to the system bus may provide substantial performance
   improvements over other approaches.  As computing power and memory
   have become cheaper this approach has become realistic.  Examples
   include the Intel implementation of iNA-961 on a variety of multibus
   boards such as the iSBC 186/51 and the iSXM 554.  Similar products
   have been developed by Motorola and by several independent vendors of
   IBM PC add-ons.  This approach requires that the transport software
   operate on an independent hardware set running under operating system
   code developed to support the communications software environment.
   Communication with the application programs takes place across the
   system bus using some simple, proprietary vendor protocol.  Careful
   engineering can provide the application programmer with a standard
   interface to the communications processor that is similar to the
   interface to the input/output subsystem.

   The advantages of this approach are mainly concentrated upon enhanced
   performance both for the host applications and the communications
   service.  Depending on such factors as the speed of the
   communications processor and the system bus, data communications
   throughput may improve by one or two orders of magnitude over that
   available from host operating system integrated implementations.
   Throughput for host applications should also improve since the
   communications processing and interrupt handling for timers and data
   links have been removed from the host processor.  The communications
   mechanism used between the host and communication processors is
   usually sufficiently simple that no real burden is added to either
   processor.

   The disadvantages for this approach are caused by complexity in
   developing the communications software.  Software development for the
   communications board cannot be supported with the standard operating
   system tools.  A method of downloading the processor board and
   debugging the communications software may be required; a trade-off
   could be to put the code into firmware or microcode.  The
   communications software must include at least a hardware monitor and,
   more typically, a small operating system to support such functions as
   interprocess communication, buffer management, flow control, and task
   synchronization.  Debugging of the user to communication subsystem
   interface may involve several levels of system software and hardware.

   The design of the processing element can follow conventional lines,
   in which a single processor handling almost all of the operation of
   the protocol.  However, with inexpensive processor and memory chips
   now available, a multiprocessor design is economically viable.  The
   diagram below shows one such design, which almost directly

   corresponds to the structure of the formal description.  There are
   several advantages to this design:

    1) management of CPU and memory resources is at a minimum;

    2) essentially no resource contention;

    3) transport connection operation can be written in microcode,
       separate from network service handling;

    4) transport connections can run with true parallelism;

    5) throughput is not limited by contention of connections for CPU
       and network access; and

    6) lower software complexity, due to functional separation.

   Possible disadvantages are greater inflexibility and hardware
   complexity.  However, these might be offset by lower development
   costs for microcode, since the code separation should provide overall
   lower code complexity in the TPE and the TPM implementations.

   In this system, the TPE instantiates a TPM by enabling its clock.
   Incoming Outgoing are passed to the TPMs along the memory bus.  TPDUs
   TPDUs from a TPM are sent on the output data bus.  The user interface
   controller accepts connect requests from the user and directs them to
   the TPE.  The TPE assigns a connection reference and informs the
   interface controller to direct further inputs for this connection to
   the designated TPM.  The shared TPM memory is analogous to the
   exported variables of the TPM modules in the formal description, and
   is used by the TPE to input TPDUs and other information to the TPM.

   In summary, the off-loading of communications protocols onto
   independent processing systems attached to a host processor across a
   system bus is quite common.  As processing power and memory become
   cheaper, the amount of software off-loaded grows.  it is now typical
   to fine transport service available for several system buses with
   interfaces to operating systems such as UNIX, XENIX, iRMX, MS-DOS,
   and VERSADOS.

   Legend:    ****  data channel
              ....  control channel
              ====  interface i/o bus
               O    channel or bus connection point


                  user
                  input
                    *
                    *
          __________V_________
          |  user interface  |       input bus
          |    controller    |=================O==============O=======
          |__________________|                 *              *
                    *                          *              *
                    *                          *       _______*_______
                    *                          *       | data buffers|
                    *                          *    ...|     TPM1    |
                    *                          *    :  |_____________|
                    *                          *    :         *
                    *                          *    :         *
   _________   _____*__________   ________   __*____:______   *
   |  TPE  |   | TPE processor|   |shared|   |    TPM1    |   *
   |buffers|***|              |   | TPM1 |***|  processor |   *
   |_______|   |______________|   | mem. |   |____________|   *
       *         :    :    *      |______|        :           *
       *         :    :    *          *           :           *
       *         :    :    ***********O***********:********************
       *         :    :       memory bus          :           *
       *         :    :                           :           *
       *         :    :...........................O...........*........
   ____*_________:___         clock enable                    *
   |    network     |                                         *
   |   interface    |=========================================O========
   |   controller   |         output data bus
   |________________|
           *
           *
           V
      to network
       interface


2.4   Front end processor.

   A more traditional approach to off-loading communications protocols
   involves the use of a free-standing front end processor, an approach
   very similar to that of placing the transport service onto a board
   attached to the system bus.  The difference is one of scale.  Typical
   front end p interface locally as desirable, as long as such additions
   are strictly local (i.e., the invoking of such services does not

   result in the exchange of TPDUs with the peer entity).

   The interface between the  user  and  transport  is  by nature
   asynchronous (although some hypothetical implementation that is
   wholly synchronous could be conjectured).  This characteristic  is
   due  to two factors: 1) the interprocess communications (IPC)
   mechanism--used  between  the  user  and transport--decouples the
   two, and to avoid blocking the user process (while waiting for a
   response) requires  an  asynchronous response  mechanism,  and  2)
   there are some asynchronously-generated transport indications that
   must  be handled (e.g.,  the  arrival of user data or the abrupt
   termination of  the  transport  connection  due  to  network errors).

   If it is assumed that the user interface to transport is
   asynchronous,  there are other aspects of the interface that are also
   predetermined.  The most important of these is that transport
   service  requests are confirmed twice.  The first confirmation occurs
   at the time  of  the  transport  service request  initiation.  Here,
   interface routines can be used to identify invalid sequences of
   requests, such as a request to  send  data  on  a  connection that is
   not yet open.  The second confirmation occurs when the service
   request crosses the interface into the transport entity.  The entity
   may accept or reject the request, depending on its resources and its
   assessment of connection (transport and network) status, priority,
   service quality.

   If the interface is to be asynchronous, then some mechanism must be
   provided to handle the asynchronous (and sometimes unexpected)
   events.  Two ways this is commonly achieved are: 1) by polling, and
   2) by a software interrupt mechanism.  The first of these can be
   wasteful of host resources in a multiprogramming environment, while
   the second may be complicated to implement.  However, if the
   interface is a combination of hardware and software, as in the cases
   discussed in Parts 2.3 and 2.4, then hardware interrupts may be
   available.

   One way of implementing the abstract services is to associate with
   each service primitive an actual function that is invoked.  Such
   functions could be held in a special interface library with other
   functions and procedures that realize the interface.  Each service
   primitive function would access the interprocess communication (IPC)
   mechanism as necessary to pass parameters to/from the transport
   entity.

   The description of the abstract service in IS 8073 and N3756 implies
   that the interface must handle TSDUs of arbitrary length.  This
   situation suggests that it may be useful to implement a TSDU as an
   object such as a file-pointer rather than as the message itself.  In
   this way, in the sending entity, TPDUs can be formed by reading
   segments of TPDU-size from the file designated, without regard for
   the actual length of the file.  In the receiving entity, each new

   TPDU could be buffered in a file designated by a file-pointer, which
   would then be passed to the user when the EOT arrives.  In the formal
   description of transport, this procedure is actually described,
   although explicit file-pointers and files are not used in the
   description.  This method of implementing the data interface is not
   essentially different from maintaining a linked list of buffers.  (A
   disk file is arranged in precisely this fashion, although the file
   user is usually not aware of the structure.)

   The abstract service definition describes  the  set  of parameters
   that must be passed in each of the service primitives so that
   transport can act properly on  behalf  of  the user.   These
   parameters are required for the transport protocol to operate
   correctly (e.g., a called address  must  be passed  with  the
   connect  request and the connect response must contain a responding
   address).   The  abstract  service defintion does not preclude,
   however, the inclusion of local parameters.  Local parameters may be
   included in the implementation  of  the  service  interface  for use
   by the local entity.  One example is a buffer management parameter
   passed from  the  user  in connect requests and confirms, providing
   the transport entity with expected buffer  usage  estimates.  The
   local  entity  could  use  this  in implementing a more efficient
   buffer management strategy than would otherwise be possible.

   One issue that is  of  importance  when  designing  and implementing
   a transport entity is the provision of a registration mechanism for
   transport users.  This facility provides a means of identifying to
   the transport entity those users who are willing to participate in
   communications with remote users.  An example of such a user is a
   data base management system, which ordinarily responds to connections
   requests rather than to initiate them.  This procedure of user
   identification is sometimes called a "passive open".  There are
   several ways in which registration can be implemented.  One is to
   install the set of users that  provide services  in  a table at
   system generation time.  This method may have the disadvantage of
   being  inflexible.   A  more flexible  approach is to implement a
   local transport service primitive, "listen", to indicate a waiting
   user.   The  user then  registers  its transport suffix with the
   transport entity via the listen primitive.  Another possibility is a
   combination of predefined table and listen primitive.  Other
   parameters may also be included,  such  as a partially or fully
   qualified transport address from which the user is willing  to
   receive  connections.  A  variant  on  this  approach  is  to
   provide  an ACTIVE/PASSIVE local parameter on the connect  request
   service primitive.  Part 5 discusses this issue in more detail.

3.2   Flow control.

   Interface flow control is generally considered to be a local
   implementation issue.  However, in order to completely specify the
   behavior of the transport entity, it was necessary to include in the

   formal description a model of the control of data flow across the
   service boundaries of transport.  The international standards for
   transport and the OSI reference model state only that interface flow
   control shall be provided but give no guidance on its features.

   The actual mechanisms used to accomplish flow control, which need not
   explicitly follow the model in the formal description, are dependent
   on the way in which the interface itself is realized, i.e., what
   TSDUs and service primitives really are and how the transport entity
   actually communicates with its user, its environment, and the network
   service.  For example, if the transport entity communicates with its
   user by means of named (UNIX) pipes, then flow control can be
   realized using a special interface library routine, which the
   receiving process invokes, to control the pipe.  This approach also
   entails some consideration for the capacity of the pipe and blocking
   of the sending process when the pipe is full (discussed further in
   Part 3.3).  The close correspondence of this interpretation to the
   model is clear.  However, such an interpretation is apparently not
   workable if the user process and the transport entity are in
   physically separate processors.  In this situation, an explicit
   protocol between the receiving process and the sending process must
   be provided, which could have the complexity of the data transfer
   portion of the Class 0 transport protocol (Class 2 if flow
   controlled).  Note that the formal model, under proper
   interpretation, also describes this mechanism.

3.3   Interprocess communication.

   One of the most important elements of a data communication system is
   the approach to interprocess communication (IPC).  This is true
   because suites of protocols are often implemented as groups of
   cooperating tasks.  Even if the protocol suites are not implemented
   as task groups, the communication system is a funnel for service
   requests from multiple user processes.  The services are normally
   communicated through some interprocess pathway.  Usually, the
   implementation environment places some restrictions upon the
   interprocess communications method that can be used.  This section
   describes the desired traits of IPC for use in data communications
   protocol implementations, outlines some possible uses for IPC, and
   discusses three common and generic approaches to IPC.

   To support the implementation of data communications protocols, IPC
   should possess several desirable traits.  First,  IPC should be
   transaction based.  This permits sending a message without the
   overhead of establishing and maintaining a connection.  The
   transactions should be confirmed so that a sender can detect and
   respond to non-delivery.  Second,  IPC should support both the
   synchronous and the asynchronous modes of message exchange.  An IPC
   receiver should be able to ask for delivery of any pending messages
   and not be blocked from continuing if no messages are present.
   Optionally, the receiver should be permitted to wait if no messages

   are present, or to continue if the path to the destination is
   congested.  Third, IPC should preserve the order of messages sent to
   the same destination.  This allows the use of the IPC without
   modification to support protocols that preserve user data sequence.
   Fourth, IPC should provide a flow control mechanism to allow pacing
   of the sender's transmission speed to that of the receiver.

   The uses of IPC in implementation of data communication systems are
   many and varied.  A common and expected use for IPC is that of
   passing user messages among the protocol tasks that are cooperating
   to perform the data communication functions.  The user messages may
   contain the actual data or, more efficiently, references to the
   location of the user data.  Another common use for the IPC is
   implementation and enforcement of local interface flow control.  By
   limiting the number of IPC messages queued on a particular address,
   senders can be slowed to a rate appropriate for the IPC consumer.  A
   third typical use for IPC is the synchronization of processes.  Two
   cooperating tasks can coordinate their activities or access to shared
   resources by passing IPC messages at particular events in their
   processing.

   More creative uses of IPC include buffer, timer, and scheduling
   management.  By establishing buffers as a list of messages available
   at a known address at system initialization time, the potential
   exists to manage buffers simply and efficiently.  A process requiring
   a buffer would simply read an IPC message from the known address.  If
   no messages (i.e., buffers) are available, the process could block
   (or continue, as an option).  A process that owned a buffer and
   wished to release it would simply write a message to the known
   address, thus unblocking any processes waiting for a buffer.

   To manage timers, messages can be sent to a known address that
   represents the timer module.  The timer module can then maintain the
   list of timer messages with respect to a hardware clock.  Upon
   expiration of a timer, the associated message can be returned to the
   originator via IPC.  This provides a convenient method to process the
   set of countdown timers required by the transport protocol.

   Scheduling management can be achieved by using separate IPC addresses
   for message classes.  A receiving process can enforce a scheduling
   discipline by the order in which the message queues are read.  For
   example, a transport process might possess three queues:  1) normal
   data from the user, 2) expedited data from the user, and 3) messages
   from the network.  If the transport process then wants to give top
   priority to network messages, middle priority to expedited user
   messages, and lowest priority to normal user messages, all that is
   required is receipt of IPC messages on the highest priority queue
   until no more messages are available.  Then the receiver moves to the
   next lower in priority and so on.  More sophistication is possible by
   setting limits upon the number of consecutive messages received from
   each queue and/or varying the order in which each queue is examined.

   It is easy to see how a round-robin scheduling discipline could be
   implemented using this form of IPC.

   Approaches to IPC can be placed into one of three classes:  1) shared
   memory, 2) memory-memory copying, and 3) input/output channel
   copying. Shared memory is the most desirable of the three classes
   because the amount of data movement is kept to a minimum.  To pass
   IPC messages using shared memory, the sender builds a small message
   referencing a potentially large amount of user data.  The small
   message is then either copied from the sender's process space to the
   receiver's process space or the small message is mapped from one
   process space to another using techniques specific to the operating
   system and hardware involved.  These approaches to shared memory are
   equivalent since the amount of data movement is kept to a minimum.
   The price to be paid for using this approach is due to the
   synchronization of access to the shared memory.  This type of sharing
   is well understood, and several efficient and simple techniques exist
   to manage the sharing.

   Memory-memory copying is an approach that has been commonly used for
   IPC in UNIX operating system implementations.  To pass an IPC message
   under UNIX data is copied from the sender's buffer to a kernel buffer
   and then from a kernel buffer to the receiver's buffer.  Thus two
   copy operations are required for each IPC message. Other methods
   might only involve a single copy operation.  Also note that if one of
   the processes involved is the transport protocol implemented in the
   kernel, the IPC message must only be copied once.  The main
   disadvantage of this approach is inefficiency.  The major advantage
   is simplicity.

   When the processes that must exchange messages reside on physically
   separate computer systems (e.g., a host and front end), an
   input/output channel of some type must be used to support the IPC.
   In such a case, the problem is similar to that of the general problem
   of a transport protocol.  The sender must provide his IPC message to
   some standard operating system output mechanism from where it will be
   transmitted via some physical medium to the receiver's operating
   system.  The receiver's operating system will then pass the message
   on to the receiving process via some standard operating system input
   mechanism.  This set of procedures can vary greatly in efficiency and
   complexity depending upon the operating systems and hardware
   involved.  Usually this approach to IPC is used only when the
   circumstances require it.

3.4   Interface to real networks.

   Implementations of the class 4 transport protocol have been operated
   over a wide variety of networks including:  1) ARPANET, 2) X.25
   networks, 3) satellite channels, 4) CSMA/CD local area networks, 5)
   token bus local area networks, and  6) token ring local area
   networks.  This section briefly describes known instances of each use

   of class 4 transport and provides some quantitative evaluation of the
   performance expectations for transport over each network type.

3.4.1   Issues.

   The interface of the transport entity to the network service in
   general will be realized in a different way from the user interface.
   The network service processor is often separate from the host CPU,
   connected to it by a bus, direct memory access (DMA), or other link.
   A typical way to access the network service is by means of a device
   driver.  The transfer of data across the interface in this instance
   would be by buffer-copying.  The use of double-buffering reduces some
   of the complexity of flow control, which is usually accomplished by
   examining the capacity of the target buffer.  If the transport
   processor and the network processor are distinct and connected by a
   bus or external link, the network access may be more complicated
   since copying will take place across the bus or link rather than
   across the memory board.  In any case, the network service
   primitives, as they appear in the formal description and IS 8073 must
   be carefully correlated to the actual access scheme, so that the
   semantics of the primitives is preserved.  One way to do this is to
   create a library of routines, each of which corresponds to one of the
   service primitives.  Each routine is responsible for sending the
   proper signal to the network interface unit, whether this
   communication is directly, as on a bus, or indirectly via a device
   driver.  In the case of a connectionless network service, there is
   only one primitive, the N_DATA_request (or N_UNIT_DATA_request),
   which has to be realized.

   In the formal description, flow control to the NSAP is controlled by
   by a Slave module, which exerts the "backpressure" on the TPM if its
   internal queue gets too long.  Incoming flow, however, is controlled
   in much the same way as the flow to the transport user is controlled.
   The implementor is reminded that the formal description of the flow
   control is specified for completeness and not as an implementation
   guide.  Thus, an implementation should depend upon actual interfaces
   in the operating environment to realize necessary functions.

3.4.2   Instances of operation.

3.4.2.1   ARPANET

   An early implementation of the class 4 transport protocol was
   developed by the NBS as a basis for conformance tests [NBS83].  This
   implementation was used over the ARPANET to communicate between NBS,
   BBN, and DCA.  The early NBS implementation was executed on a
   PDP-11/70.  A later revision of the NBS implementation has been moved
   to a VAX-11/750 and VAX-11/7;80. The Norwegian Telecommunication
   Administration (NTA) has implemented class 4 transport for the UNIX
   BSD 4.2 operating system to run on a VAX [NTA84].  A later NTA
   implementation runs on a Sun 2-120 workstation.  The University of

   Wisconsin has also implemented the class 4 transport protocol on a
   VAX-11/750 [BRI85]. The Wisconsin implementation is embedded in the
   BSD 4.2 UNIX kernel.  For most of these implementations class 4
   transport runs above the DOD IP and below DOD application protocols.

3.4.2.2   X.25 networks

   The NBS implementations have been used over Telenet, an X.25 public
   data network (PDN).  The heaviest use has been testing of class 4
   transport between the NBS and several remotely located vendors, in
   preparation for a demonstration at the 1984 National Computing
   Conference and the 1985 Autofact demonstration.  Several approaches
   to implementation were seen in the vendors' systems, including ones
   similar to those discussed in Part 6.2.  At the Autofact
   demonstration many vendors operated class 4 transport and the ISO
   internetwork protocol across an internetwork of CSMA/CD and token bus
   local networks and Accunet, an AT&T X.25 public data network.

3.4.2.3   Satellite channels.

   The COMSAT Laboratories have implemented class 4 transport for
   operation over point-to-point satellite channels with data rates up
   to 1.544 Mbps [CHO85].  This implementation has been used for
   experiments between the NBS and COMSAT.  As a result of these
   experiments several improvements have been made to the class 4
   transport specification within the international standards arena
   (both ISO and CCITT). The COMSAT implementation runs under a
   proprietary multiprocessing operating system known as COSMOS.  The
   hardware base includes multiple Motorola 68010 CPUs with local memory
   and Multibus shared memory for data messages.

3.4.2.4   CSMA/CD networks.

   The CSMA/CD network as defined by the IEEE 802.3 standard is the most
   popular network over which the class 4 transport has been
   implemented. Implementations of transport over CSMA/CD networks have
   been demonstrated by: AT&T, Charles River Data Systems,
   Computervision, DEC, Hewlitt-Packard, ICL, Intel, Intergraph, NCR and
   SUN.  Most of these were demonstrated at the 1984 National Computer
   Conference [MIL85b] and again at the 1985 Autofact Conference.
   Several of these vendors are now delivering products based on the
   demonstration software.

3.4.2.5   Token bus networks.

   Due to the establishment of class 4 transport as a mandatory protocol
   within the General Motor's manufacturing automation protocol (MAP),
   many implementations have been demonstrated operating over a token
   bus network as defined by the IEEE 802.4 standard.  Most past
   implementations relied upon a Concord Data Systems token interface
   module (TIM) to gain access to the 5 Mbps broadband 802.4 service.

   Several vendors have recently announced boards supporting a 10 Mbps
   broadband 802.4 service.  The newer boards plug directly into
   computer system buses while the TIM's are accessed across a high
   level data link control (HDLC) serial channel.  Vendors demonstrating
   class 4 transport over IEEE 802.4 networks include Allen-Bradley,
   AT&T, DEC, Gould, Hewlett-Packard, Honeywell, IBM, Intel, Motorola,
   NCR and Siemens.

3.4.2.6   Token ring networks.

   The class 4 transport implementations by the University of Wisconsin
   and by the NTA run over a 10 Mbps token ring network in addition to
   ARPANET.  The ring used is from Proteon rather than the recently
   finished IEEE 802.5 standard.

3.4.3   Performance expectations.

   Performance research regarding the class 4 transport protocol has
   been limited.  Some work has been done at the University of
   Wisconsin, at NTA, at Intel, at COMSAT, and at the NBS.  The material
   presented below draws from this limited body of research to provide
   an implementor with some quantitative feeling for the performance
   that can be expected from class 4 transport implementations using
   different network types.  More detail is available from several
   published reports [NTA84, BRI85, INT85, MIL85b, COL85].  Some of the
   results reported derive from actual measurements while other results
   arise from simulation.  This distinction is clearly noted.

3.4.3.1   Throughput.

   Several live experiments have been conducted to determine the
   throughput possible with implementations of class 4 transport.
   Achievable throughput depends upon many factors including:  1) CPU
   capabilities, 2) use or non-use of transport checksum, 3) IPC
   mechanism, 4) buffer management technique, 5) receiver resequencing,
   6) network error properties, 7) transport flow control, 8) network
   congestion and 9) TPDU size.  Some of these are specifically
   discussed elsewhere in this document.  The reader must keep in mind
   these issues when interpreting the throughput measures presented
   here.

   The University of Wisconsin implemented class 4 transport in the UNIX
   kernel for a VAX-11/750 with the express purpose of measuring the
   achievable throughput.  Throughputs observed over the ARPANET ranged
   between 10.4 Kbps and 14.4 Kbps.  On an unloaded Proteon ring local
   network, observed throughput with checksum ranged between 280 Kbps
   and 560 Kbps.  Without checksum, throughput ranged between 384 Kbps
   and 1 Mbps.

   The COMSAT Laboratories implemented class 4 transport under a
   proprietary multiprocessor operating system for a multiprocessor

   68010 hardware architecture.  The transport implementation executed
   on one 68010 while the traffic generator and link drivers executed on
   a second 68010.  All user messages were created in a global shared
   memory and were copied only for transmission on the satellite link.
   Throughputs as high as 1.4 Mbps were observed without transport
   checksumming while up to 535 Kbps could be achieved when transport
   checksums were used.  Note that when the 1.4 Mbps was achieved the
   transport CPU was idle 20% of the time (i.e., the 1.544 Mbps
   satellite link was the bottleneck).  Thus, the transport
   implementation used here could probably achieve around 1.9 Mbps user
   throughput with the experiment parameters remaining unchanged.
   Higher throughputs are possible by increasing the TPDU size; however,
   larger messages stand an increased chance of damage during
   transmission.

   Intel has implemented a class 4 transport product for operation over
   a CSMA/CD local network (iNA-960 running on the iSBC 186/51 or iSXM
   552).  Intel has measured throughputs achieved with this combination
   and  has published the results in a technical analysis comparing
   iNA-960 performance on the 186/51 with iNA-960 on the 552.  The CPU
   used to run transport was a 6 MHz 80186.  An 82586 co-processor was
   used to handle the medium access control.  Throughputs measured
   ranged between 360 Kbps and 1.32 Mbps, depending on the parameter
   values used.

   Simulation of class 4 transport via a model developed at the NBS has
   been used to predict the performance of the COMSAT implementation and
   is now being used to predict the performance of a three processor
   architecture that includes an 8 MHz host connected to an 8 MHz front
   end over a system bus.  The third processor provides medium access
   control for the specific local networks  being modeled.  Early model
   results predict throughputs over an unloaded CSMA/CD local network of
   up to 1.8 Mbps.  The same system modeled over a token bus local
   network with the same transport parameters yields throughput
   estimates of up to 1.6 Mbps.  The token bus technology, however,
   permits larger message sizes than CSMA/CD does.  When TPDUs of 5120
   bytes are used, throughput on the token bus network is predicted to
   reach 4.3 Mbps.

3.4.3.2   Delay.

   The one-way delay between sending transport user and receiving
   transport user is determined by a complex set of factors.  Readers
   should also note that, in general, this is a difficult measure to
   make and little work has been done to date with respect to expected
   one-way delays with class 4 transport implementations.  In this
   section a tutorial is given to explain the factors that determine the
   one-way delay to be expected by a transport user.  Delay experiments
   performed by Intel are reported [INT85], as well as some simulation
   experiments conducted by the NBS [MIL85a].

   The transport user can generally expect one-way delays to be
   determined by the following equation.


     D = TS + ND + TR + [IS] + [IR]        (1)


   where:

      [.] means the enclosed quantity may be 0

      D is the one-way transport user delay,

      TS is the transport data send processing time,

      IS is the internet datagram send processing time,

      ND is the network delay,

      IR is the internet datagram receive processing
      time, and

      TR is the transport data receive processing time.


   Although no performance measurements are available for the ISO
   internetwork protocol (ISO IP), the ISO IP is so similar to the DOD
   IP that processing times associated with sending and receiving
   datagrams should be the about the same for both IPs.  Thus, the IS
   and IR terms given above are ignored from this point on in the
   discussion.  Note that many of these factors vary depending upon the
   application traffic pattern and loads seen by a transport
   implementation.  In the following discussion, the transport traffic
   is assumed to be a single message.

   The value for TS depends upon the CPU used, the IPC mechanism, the
   use or non-use of checksum, the size of the user message and the size
   of TPDUs, the buffer management scheme in use, and the method chosen
   for timer management.  Checksum processing times have been observed
   that include 3.9 us per octet for a VAX-11/750, 7.5 us per octet on a
   Motorola 68010, and 6 us per octet on an Intel 80186.  The class 4
   transport checksum algorithm has considerable effect on achievable
   performance. This is discussed further in Part 7.  Typical values for
   TS, excluding the processing due to the checksum, are about 4 ms for
   CPUs such as the Motorola 68010 and the Intel 80186.  For 1024 octet
   TPDUs, checksum calculation can increase the TS value to about 12 ms.

   The value of TR depends upon similar details as TS.  An additional
   consideration is whether or not the receiver caches (buffers) out of
   order TPDUs.  If so, the TR will be higher when no packets are lost
   (because of the overhead incurred by the resequencing logic).  Also,

   when packets are lost, TR can appear to increase due to transport
   resequencing delay.  When out of order packets are not cached, lost
   packets increase D because each unacknowledged packet must be
   retransmitted (and then only after a delay waiting for the
   retransmission timer to expire).  These details are not taken into
   account in equation 1.  Typical TR values that can be expected with
   non-caching implementations on Motorola 68010 and Intel 80186 CPUs
   are approximately 3 to 3.5 ms.  When transport checksumming is used
   on these CPUs, TR becomes about 11 ms for 1024 byte TPDUs.

   The value of ND is highly variable, depending on the specific network
   technology in use and on the conditions in that network.  In general,
   ND can be defined by the following equation.


     ND = NQ + MA + TX + PD + TQ   (2)


   where:

     NQ is network queuing delay,

     MA is medium access delay,

     TX is message transmission time,

     PD is network propagation delay, and

     TQ is transport receive queuing delay.

   Each term of the equation is discussed in the following paragraphs.

   Network queuing delay (NQ) is the time that a TPDU waits on a network
   transmit queue until that TPDU is the first in line for transmission.
   NQ depends on the size of the network transmit queue, the rate at
   which the queue is emptied, and the number of TPDUs already on the
   queue.  The size of the transmit queue is usually an implementation
   parameter and is generally at least two messages.  The rate at which
   the queue empties depends upon MA and TX (see the discussion below).
   The number of TPDUs already on the queue is determined by the traffic
   intensity (ratio of mean arrival rate to mean service rate).  As an
   example, consider an 8 Kbps point-to-point link serving an eight
   message queue that contains 4 messages with an average size of 200
   bytes per message.  The next message to be placed into the transmit
   queue would experience an NQ of 800 ms (i.e., 4 messages times 200
   ms).  In this example, MA is zero.  These basic facts permit the
   computation of NQ for particular environments.  Note that if the
   network send queue is full, back pressure flow control will force
   TPDUs to queue in transport transmit buffers and cause TS to appear
   to increase by the amount of the transport queuing delay.  This
   condition depends on application traffic patterns but is ignored for

   the purpose of this discussion.

   The value of MA depends upon the network access method and on the
   network congestion or load.  For a point-to-point link MA is zero.
   For CSMA/CD networks MA depends upon the load, the number of
   stations, the arrival pattern, and the propagation delay.  For
   CSMA/CD networks MA has values that typically range from zero (no
   load) up to about 3 ms (80% loads).  Note that the value of MA as
   seen by individual stations on a CSMA/CD network is predicted (by NBS
   simulation studies) to be as high as 27 ms under 70% loads.  Thus,
   depending upon the traffic patterns, individual stations may see an
   average MA value that is much greater than the average MA value for
   the network as a whole. On token bus networks MA is determined by the
   token rotation time (TRT) which depends upon the load, the number of
   stations, the arrival pattern, the propagation delay, and the values
   of the token holding time and target rotation times at each station.

   For small networks of 12 stations with a propagation delay of 8 ns,
   NBS simulation studies predict TRT values of about 1 ms for zero load
   and 4.5 ms for 70% loads for 200 byte messages arriving with
   exponential arrival distribution.  Traffic patterns also appear to be
   an important determinant of target rotation time.  When a pair of
   stations performs a continuous file transfer, average TRT for the
   simulated network is predicted to be 3 ms for zero background load
   and 12.5 ms for 70% background load (total network load of 85%).

   The message size and the network transmission speed directly
   determine TX.  Typical transmission speeds include 5 and 10 Mbps for
   standard local networks;  64 Kbps, 384 Kbps, or 1.544 Mbps for
   point-to-point satellite channels;  and 9.6 Kbps or 56 Kbps for
   public data network access links.

   The properties of the network in use determine the values of PD. On
   an IEEE 802.3 network, PD is limited to 25.6 us.  For IEEE 802.4
   networks, the signal is propagated up-link to a head end and then
   down-link from the head end.  Propagation delay in these networks
   depends on the distance of the source and destination stations from
   the head end and on the head end latency. Because the maximum network
   length is much greater than with IEEE 802.3 networks, the PD values
   can also be much greater.  The IEEE 802.4 standard requires that a
   network provider give a value for the maximum transmission path
   delay.  For satellite channels PD is typically between 280 and 330
   ms.  For the ARPANET, PD depends upon the number of hops that a
   message makes between source and destination nodes.  The NBS and NTIA
   measured ARPANET PD average values of about 190 ms [NTI85].  In the
   ARPA internet system the PD is quite variable, depending on the
   number of internet gateway hops and the PD values of any intervening
   networks (possibly containing satellite channels).  In experiments on
   an internetwork containing a a satellite link to Korea, it was
   determined by David Mills [RFC85] that internet PD values could range
   from 19 ms to 1500 ms.  Thus, PD values ranging from 300 to 600 ms

   can be considered as typical for ARPANET internetwork operation.

   The amount of time a TPDU waits in the network receive queue before
   being processed by the receiving transport is represented by TQ,
   similar to NQ in that the value of TQ depends upon the size of the
   queue, the number of TPDUs already in the queue, and the rate at
   which the queue is emptied by transport.

   Often the user delay D will be dominated by one of the components. On
   a satellite channel the principal component of D is PD, which implies
   that ND is a principal component by equation (2).  On an unloaded
   LAN, TS and TR might contribute most to D.  On a highly loaded LAN,
   MA may cause NQ to rise, again implying that ND is a major factor in
   determining D.

   Some one-way delay measures have been made by Intel for the iNA-960
   product running on a 6 MHz 80186.  For an unloaded 10 Mbps CSMA/CD
   network the Intel measures show delays as low as 22 ms.  The NBS has
   done some simulations of class 4 transport over 10 Mbps CSMA/CD and
   token bus networks.  These (unvalidated) predictions show one-way
   delays as low as 6 ms on unloaded LANs and as high as 372 ms on
   CSMA/CD LANs with 70% load.

3.4.3.3   Response time.

   Determination of transport user response time (i.e., two-way delay)
   depends upon many of the same factors discussed above for one-way
   delay.  In fact, response time can be represented by equation 3 as
   shown below.

      R = 2D + AS + AR     (3)

   where:

     R is transport user response time,

     D is one-way transport user delay,

     AS is acknowledgement send processing time, and

     AR is acknowledgement receive processing time.

   D has been explained above.  AS and AR deal with the acknowledgement
   sent by transport in response to the TPDU that embodies the user
   request.

   AS is simply the amount of time that the receiving transport must
   spend to generate an AK TPDU.  Typical times for this function are
   about 2 to 3 ms on processors such as the Motorola 68010 and the
   Intel 80186.  Of course the actual time required depends upon factors
   such as those explained for TS above.

   The amount of time, AR, that the sending transport must spend to
   process a received AK TPDU.  Determination of the actual time
   required depends upon factors previously described.  Note that for AR
   and AS, processing when the checksum is included takes somewhat
   longer. However, AK TPDUs are usually between 10 and 20 octets in
   length and therefore the increased time due to checksum processing is
   much less than for DT TPDUs.

   No class 4 transport user response time measures are available;
   however, some simulations have been done at the NBS.  These
   predictions are based upon implementation strategies that have been
   used by commercial vendors in building microprocessor-based class 4
   transport products.  Average response times of about 21 ms on an
   unloaded 10 Mbps token bus network, 25 ms with 70% loading, were
   predicted by the simulations.  On a 10 Mbps CSMA/CD network, the
   simulations predict response times of about 17 ms for no load and 54
   ms for a 70% load.

3.5   Error and status reporting.

   Although the abstract service definition for the  transport protocol
   specifies  a set of services to be offered, the actual set of
   services  provided  by  an  implementation need  not  be limited to
   these.  In particular, local status and error information can be
   provided as a confirmed service (request/response) and as an
   asynchronous "interrupt" (indication).  One use for this service  is
   to  allow  users  to query the transport entity about the status of
   their connections.  An example of information  that  could  be
   returned from the entity is:

        o  connection state
        o  current send sequence number
        o  current receive and transmit credit windows
        o  transport/network interface status
        o  number of retransmissions
        o  number of DTs and AKs sent and received
        o  current timer values

   Another use for the local status and error reporting service is  for
   administration  purposes.   Using  the  service, an administrator can
   gather information such as described above for  each open connection.
   In addition, statistics concerning the transport entity as a whole
   can be obtained, such as number of transport connections open,
   average number of connections open over a  given  reporting  period,
   buffer  use statistics, and total number of retransmitted DT TPDUs.
   The administrator might also be given the  authority  to  cancel
   connections,  restart  the  entity,  or  manually  set timer values.

4   Entity resource management.

4.1   CPU management.

   The formal description has implicit scheduling of TPM modules, due to
   the semantics of the Estelle structuring principles.  However, the
   implementor should not depend on this scheduling to obtain optimal
   behavior, since, as stated in Part 1, the structures in the formal
   description were imposed for purposes other than operational
   efficiency.

   Whether by design or by default,  every  implementation of the
   transport protocol embodies some decision about allocating the CPU
   resource among transport connections.   The resource may be
   monolithic, i.e. a single CPU, or it may be distributed, as in the
   example design given in Part 2.3.  In the former, there are  two
   simple techniques  for apportioning CPU processing time  among
   transport  connections.   The first of these,
   first-come/first-served, consists of the transport entity handling
   user service requests in the order in which they arrive.  No
   attempt  is  made  to  prevent one transport connection from using
   an inordinate amount of the CPU.

   The second simple technique is  round-robin  scheduling of
   connections.   Under this method, each transport connection is
   serviced in turn.  For  each  connection,  transport processes one
   user service request, if there is one present at the interface,
   before proceeding to the next connection.

   The quality of service parameters provided in the connection request
   can be used to provide a finer-grained strategy for managing the CPU.
   The CPU could be allocated to connections requiring low delay more
   often while those requiring high throughput would be served less
   often but for longer periods (i.e., several connections requiring
   high throughput might be serviced in a concurrent cluster).

   For example, in the service sequence below, let "T" represent
   m > 0 service requests, each requiring high throughput, let "D"
   represent one service request requiring low delay and let the suffix
   n = 1,2,3 represent a connection identifier, unique only within a
   particular service requirement type (T,D).  Thus T1 represents a set
   of service requests for connection 1 of the service requirement type
   T, and D1 represents a service set (with one member) for connection 1
   of service requirement type D.

   D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1...


   If m = 4 in this service sequence, then service set D1 will get
   worst-case service once every seventh service request processed.
   Service set T1 receives service on its four requests only once in

   fourteen requests processed.

   D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1...
   |              |    |              |    |              |
   |  3 requests  |  4 |       3      |  4 |       3      |

   This means that the CPU is allocated to T1 29% ( 4/14 ) of the
   available time, whereas D1 obtains service 14% ( 1/7 ) of the time,
   assuming processing requirements for all service requests to be
   equal.  Now assume that, on average, there is a service request
   arriving for one out of three of the service requirement type D
   connections.  The CPU is then allocated to the T type 40% ( 4/10 )
   while the D type is allocated 10% ( 1/10 ).

4.2   Buffer management.

   Buffers are used as temporary storage areas for data on its  way to
   or arriving from the network.  Decisions must be made about buffer
   management in two areas.  The first is the overall  strategy  for
   managing  buffers in a multi-layered protocol environment.  The
   second  is  specifically  how  to allocate buffers within the
   transport entity.

   In the formal description no details of buffer strategy are given,
   since such strategy depends so heavily on the implementation
   environment.  Only a general mechanism is discussed in the formal
   description for allocating receive credit to a transport connection,
   without any expression as to how this resource is managed.

   Good buffer management should correlate to the traffic presented by
   the applications using the transport service.  This traffic has
   implications as well for the performance of the protocol. At present,
   the relationship of buffer strategy to optimal service for a given
   traffic distribution is not well understood.  Some work has been
   done, however, and the reader is referred to the work of Jeffery
   Spirn [SPI82, SPI83] and to the experiment plan for research by the
   NBS [HEA85] on the effect of application traffic patterns on the
   performance of Class 4 transport.

4.2.1   Overall buffer strategy.

   Three schemes for management of  buffers  in  a  multilayered
   environment  are described here.  These represent a spectrum of
   possibilities available to the implementor.  The first  of these is a
   strictly layered approach in which each entity in the protocol
   hierarchy, as a process, manages its own pool of buffers
   independently  of  entities  at  other layers.  One advantage of this
   approach  is  simplicity;   it is not necessary for an entity  to
   coordinate  buffer  usage with a resource manager which is serving
   the needs of numerous  protocol entities.  Another advantage is
   modularity.  The interface presented to entities in other layers is

   well  defined; protocol  service  requests and responses are passed
   between layers by value (copying) versus by reference (pointer
   copying). In particular, this is a strict interpretation of the OSI
   reference model, IS 7498 [ISO84b], and the protocol entities hide
   message details from each other, simplifying handling at the entity
   interfaces.

   The single disadvantage to a  strictly  layered  scheme derives  from
   the  value-passing  nature  of the interface.  Each time protocol
   data and control  information  is  passed from  one layer to another
   it must be copied from one layer's buffers to those of another layer.
   Copying  between  layers in  a  multi-layered  environment is
   expensive and imposes a severe penalty on the performance of the
   communications system, as  well as the computer system on which it is
   running as a whole.

   The second scheme for managing buffers  among  multiple protocol
   layers  is  buffer  sharing.   In  this  approach, buffers are a
   shared resource among multiple protocol  entities; protocol data and
   control information contained in the buffers is exchanged by passing
   a buffer pointer, or  reference, rather  than  the  values  as in the
   strictly layered approach  described  above.   The  advantage  to
   passing buffers by reference is that only a small amount of
   information, the buffer pointer, is copied  from  layer  to  layer.
   The  resulting  performance  is much better than that of the strictly
   layered approach.

   There are several requirements  that  must  be  met  to implement
   buffer sharing.  First, the host system architecture must allow
   memory sharing among protocol entities  that are  sharing the
   buffers.  This can be achieved in a variety of ways:  multiple
   protocol entities may be  implemented  as one  process, all sharing
   the same process space (e.g., kernel space),  or  the  host  system
   architecture  may  allow processes  to  map portions of their address
   space to common buffer areas at some known location in physical
   memory.

   A buffer manager is another requirement for implementing shared
   buffers.  The buffer manager has the responsibility of providing
   buffers  to  protocol entities when needed from a list of free
   buffers and recycling used buffers  back into  the  free  list. The
   pool may consist of one or more lists, depending on the level of
   control desired.  For example, there  could be separate lists of
   buffers for outgoing and incoming messages.

   The protocol entities must be implemented in such a way as to
   cooperate with the buffer manager.  While this appears to be an
   obvious condition, it has important implications for the strategy
   used by implementors to develop the communications system.  This
   cooperation can be described as follows:  an entity at layer N
   requests and is allocated a buffer by the manager; each such buffer

   is returned to the manager by some entity at layer N - k (outgoing
   data) or N + k (incoming data).

   Protocol  entities also must be designed to cooperate with each
   other.  As buffers are allocated and sent towards the  network  from
   higher  layers, allowance must be made for protocol control
   information to be added at lower layers.  This usually means
   allocating  oversized buffers to allow space for headers to be
   prepended at lower layers.  Similarly, as buffers move upward from
   the network, each protocol entity processes its headers before
   passing the buffer on.  These  manipulations  can  be handled by
   managing pointers into the buffer header space.

   In their pure forms, both strictly layered  and  shared buffer
   schemes are not practical.  In the former, there is a performance
   penalty for copying buffers.  On the other hand, it  is not practical
   to implement buffers that are shared by entities in all layers of the
   protocol hierarchy: the  lower protocol layers (OSI layers 1 - 4)
   have essentially static buffer requirements, whereas the upper
   protocol layers (OSI layers 5 - 7) tend to be dynamic in their buffer
   requirements.  That is, several different applications may be running
   concurrently, with buffer requirements varying as the set of
   applications varies.  However, at the transport layer, this latter
   variation is not visible and variations in buffer requirements will
   depend more on service quality considerations than on the specific
   nature of the applications being served.  This suggests a hybrid
   scheme in which the entities in OSI layers 1 - 4 share buffers while
   the entities in each of the OSI layers 5 - 7 share in a buffer pool
   associated with each layer.  This approach provides most of the
   efficiency of a pure shared buffer scheme and allows for simple,
   modular interfaces where they are most appropriate.

4.2.2   Buffer management in the transport entity.

   Buffers are allocated in the transport entity  for  two purposes:
   sending and receiving data.  For sending data, the decision of how
   much buffer space to allocate is  relatively simple;  enough  space
   should be allocated for outgoing data to hold the maximum number of
   data messages that the  entity will have outstanding (i.e., sent but
   unacknowledged) at any time.  The send buffer space is determined  by
   one  of  two values,  whichever  is lower:  the send credit received
   from the receiving transport entity, or a maximum  value  imposed by
   the  local  implementation,  based  on  such  factors as overall
   buffer capacity.

   The allocation of receive buffers is a more interesting problem
   because  it is directly related to the credit value transmitted the
   peer transport entity in CR (or CC) and AK TPDUs.  If the total
   credit offered to the peer entity exceeds the total available buffer
   space and credit reduction  is  not  implemented, deadlock  may
   occur, causing termination of one or more transport connections.  For

   the purposes of  this discussion,  offered  credit  is assumed to be
   equivalent to available buffer space.

   The simplest scheme for receive buffer  allocation  is allocation of
   a fixed amount per transport connection.  This amount is allocated
   regardless of how the connection  is  to be  used.   This  scheme is
   fair in that all connections are treated equally.  The implementation
   approach in Part 2.3, in which each transport connection is handled
   by a physically separate processor, obviously could use this scheme,
   since the allocation would be in the form of memory chips assigned by
   the system designer when the system is built.

   A more flexible method  of  allocating  receive  buffer space  is
   based  on the connection quality of service (QOS) requested by the
   user.  For instance, a QOS indicating  high throughput would be given
   more send and receive buffer space than one a QOS indicating low
   delay.  Similarly, connection priority can  be  used  to  determine
   send and receive buffer allocation, with important (i.e., high
   priority) connections  allocated  more buffer space.

   A slightly more complex scheme is to apportion send and receive
   buffer  space using both QOS and priority.  For each connection, QOS
   indicates a general category of  operation  (e.g., high throughput or
   low delay).  Within the general category, priority determines the
   specific  amount  of  buffer  space allocated  from  a range of
   possible values.  The general categories may well overlap, resulting,
   for example, in a high priority connection with low throughput
   requirements being allocated more buffer space than low priority
   connection requiring a high throughput.

5   Management of Transport service endpoints.

   As mentioned in Part 1.2.1.1, a transport entity needs some way of
   referencing a transport connection endpoint within the end system: a
   TCEP_id.  There are several factors influencing the management of
   TCEP_ids:

    1)  IPC mechanism between the transport entity and the session
        entity (Part 3.3);

    2)  transport entity resources and resource management (Part 4);

    3)  number of distinct TSAPs supported by the entity (Part 1.2.2.1);
        and

    4)  user process rendezvous mechanism (the means by which session
        processes identify themselves to the transport entity, at a
        given TSAP, for association with a transport connection);

   The IPC mechanism and the user process rendezvous mechanism have more
   direct influence than the other two factors on how the TCEP_id

   management is implemented.

   The number of TCEP_ids available should reflect the resources that
   are available to the transport entity, since each TCEP_id in use
   represents a potential transport connection.  The formal description
   assumes that there is a function in the TPE which can decide, on the
   basis of current resource availability, whether or not to issue a
   TCEP_id for any connection request received.  If the TCEP_id is
   issued, then resources are allocated for the connection endpoint.
   However, there is a somewhat different problem for the users of
   transport.  Here, the transport entity must somehow inform the
   session entity as to the TCEP_ids available at a given TSAP.

   In the formal description, a T-CONNECT-request is permitted to enter
   at any TSAP/TCEP_id.  A function in the TPE considers whether or not
   resources are availble to support the requested connection.  There is
   also a function which checks to see if a TSAP/TCEP_id is busy by
   seeing if there is a TPM allocated to it.  But this function is not
   useful to the session entity which does not have access to the
   transport entity's operations.  This description of the procedure is
   clearly too loose for an implementation.

   One solution to this problem is to provide a new (abstract) service,
   T-REGISTER, locally, at the interface between transport and session.

   ___________________________________________________________________
   |           Primitives                       Parameters           |
   |_________________________________________________________________|
   |  T-REGISTER        request     |  Session process  identifier   |
   |________________________________|________________________________|
   |  T-REGISTER        indication  |  Transport endpoint identifier,|
   |                                |  Session process  identifier   |
   |________________________________|________________________________|
   |  T-REGISTER        refusal     |  Session process  identifier   |
   |________________________________|________________________________|

   This service is used as follows:


     1)   A session process is identified to the transport entity by a
          T-REGISTER-request event.  If a TCEP_id is available,  the
          transport entity selects a TCEP_id and places it into a table
          corresponding to the TSAP at which the T-REGISTER-request
          event occurred, along with the session process identifier. The
          TCEP_id and the session process identifier are then
          transmitted to the session entity by means of the T-REGISTER-
          indication event. If no TCEP_id is available, then a T-
          REGISTER-refusal event carrying the session process identifier
          is returned.  At any time that an assigned TCEP_id is not
          associated with an active transport connection process
          (allocated TPM), the transport entity can issue a T-REGISTER-

          refusal to the session entity to indicate, for example, that
          resources are no longer available to support a connection,
          since TC resources are not allocated at registration time.


     2)   If the session entity is to initiate the transport connection,
          it issues a T-CONNECT-request with the TCEP_id as a parameter.
          (Note that this procedure is at a slight variance to the
          procedure in N3756, which specifies no such parameter, due to
          the requirement of alignment of the formal description with
          the service description of transport and the definition of the
          session protocol.) If the session entity is expecting a
          connection request from a remote peer at this TSAP, then the
          transport does nothing with the TCEP_id until a CR TPDU
          addressed to the TSAP arrives.  When such a CR TPDU arrives,
          the transport entity issues a T-CONNECT-indication to the
          session entity with a TCEP_id as a parameter.  As a management
          aid, the table entry for the TCEP_id can be marked "busy" when
          the TCEP_id is associated with an allocated TPM.


     3)   If a CR TPDU is received and no TCEP_id is in the table for
          the TSAP addressed, then the transport selects a TCEP_id,
          includes it as a parameter in the T-CONNECT-indication sent to
          the session entity, and places it in the table. The T-
          CONNECT-response returned by the session entity will carry the
          TCEP_id and the session process identifier.  If the session
          process identifier is already in the table, the new one is
          discarded; otherwise it is placed into the table. This
          procedure is also followed if the table has entries but they
          are all marked busy or are empty.  If the table is full and
          all entries ar marked busy, then the transport entity
          transmits a DR TPDU to the peer transport entity to indicate
          that the connection cannot be made.  Note that the transport
          entity can disable a TSAP by marking all its table entries
          busy.


   The realization of the T-REGISTER service will depend on the IPC
   mechanisms available between the transport and session entities. The
   problem of user process rendezvous is solved in general by the T-
   REGISTER service, which is based on a solution proposed by Michael
   Chernik of the NBS [CHK85].