rfc1008.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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



McCoy                                                          [Page 19]

RFC 1008                                                       June 1987


   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,



McCoy                                                          [Page 20]

RFC 1008                                                       June 1987


   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



McCoy                                                          [Page 21]

RFC 1008                                                       June 1987


   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.















McCoy                                                          [Page 22]

RFC 1008                                                       June 1987


   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



McCoy                                                          [Page 23]

RFC 1008                                                       June 1987


   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 inter