rfc979.txt

RFC 的详细文档！

Network Working Group                                    Andrew G. Malis
Request for Comments: 979                       BBN Communications Corp.
                                                              March 1986

                PSN END-TO-END FUNCTIONAL SPECIFICATION


Status of this Memo

   This memo is an updated version of BBN Report 5775, "End-to-End
   Functional Specification".  It has been updated to reflect changes
   since that report was written, and is being distributed in this form
   to provide information to the ARPA-Internet community about this
   work.  The changes described in this memo will affect AHIP (1822
   LH/DH/HDH) and X.25 hosts directly connected to BBNCC PSNs.
   Information concerning the schedule for deployment of this version of
   the PSN software (Release 7.0) in the ARPANET and the MILNET can be
   obtained from DCA.  Distribution of this memo is unlimited.

1  Introduction

   This memo contains the functional specification for the new BBNCC PSN
   End-to-End (EE) protocol and module (PSN stands for Packet Switch
   node, and has previously been known as the IMP).  The EE module is
   that portion of the PSN code which is responsible for maintaining EE
   connections that reliably deliver data across the network, and for
   handling the packet level (level 3) interactions with the hosts.  The
   EE protocol is the peer protocol used between EE modules to create,
   maintain, and close connections. The new EE is being developed in
   order to correct a number of deficiencies in the old EE, to improve
   its performance and overall throughput, and to better equip the PSN
   to support its current and anticipated host population.

   The initial version of the new EE is being fielded in PSN Release
   7.0.  Both the old and new EEs are resident in the PSN code, and each
   PSN may run either the old or the new EE (but not both) at any time,
   under the control of the Network Operations Center (NOC).  The NOC
   has facilities for switching individual PSNs or the entire network
   between the old and new EEs.  When the old EE is running, PSN 7.0's
   functionality is equivalent to that provided by PSN 6.0, and the
   differences listed in this memo do not apply.  Hosts on PSNs running
   the old EE cannot interoperate with hosts on PSNs running the new EE.

   There are two additional sections following this introduction.
   Section two describes the motivation and goals driving the new EE
   project.

   Section three contains the new EE's functional specification.  It
   describes the services provided to the various types of hosts that




Malis                                                           [Page 1]



RFC 979                                                       March 1986
PSN End-to-End Functional Specification


   are supported by the PSN, the addressing capabilities that it makes
   available, the functionality required for the peer protocol, and the
   performance goals for the new EE.

   Two notes concerning terminology are required.  Throughout this
   document, the units of information sent from one host to another are
   referred to as "messages", and the units into which these messages
   are fragmented for transmission through the subnetwork are referred
   to as "subnet packets" or just "packets".  This differs from X.25's
   terminology; X.25 "packets" are actually messages.  Also, in this
   report the term "AHIP" is used to refer to the ARPANET Host-IMP
   Protocol described in BBN Report 1822, "Specifications for the
   Interconnection of a Host and an IMP".

2  Motivation

   The old EE was developed almost a decade ago, in the early days of
   packet-switching technology.  This part of the PSN has remained
   stable for eight years, while the environment within which the
   technology operates has changed dramatically.  At the time the old EE
   was developed, it was used in only one network, the ARPANET.  There
   are now many PSN-based networks, some of which are grouped into
   internets.  Originally, AHIP was the only host interface protocol,
   with NCP above it.  The use of X.25 is now rapidly increasing, and
   TCP/IP has replaced NCP.

   This section describes the needs for more flexibility and increases
   in some of the limits of the old EE, and lists the goals which this
   new design should meet.

   2.1  Benefits of a New EE

      Network growth and the changing network environment make improved
      performance, in terms of increasing the PSN's throughput, an
      important goal for the new EE.  The new EE reduces protocol
      traffic overhead, thereby making more efficient use of network
      line bandwidth and transit PSN processing power.

      The new EE provides a set of network transport services which are
      appropriate for both the AHIP and X.25 host interfaces, unlike the
      old EE, which is highly optimized for and tightly tied to the AHIP
      host interface.

      The new EE has an adjustable window facility instead of the old
      EE's fixed window of eight outstanding messages between any host
      pair.  The old EE applies this limit to all traffic between a pair
      of hosts; it has no notion of multiple independent channels or


Malis                                                           [Page 2]



RFC 979                                                       March 1986
PSN End-to-End Functional Specification


      connections between two hosts, which the new EE allows.  A network
      with satellite trunking, and consequently long delays, is an
      example of where the new window facility increases the EE
      throughput that can be attained.  TACs and gateways provide
      another example where the old EE's fixed window limits throughput;
      all of the traffic between a host and a TAC or a gateway currently
      uses the same EE connection and is subject to the limit of eight
      outstanding messages, even if more than one user's traffic flows
      are involved.  With the new EE, this restriction no longer
      applies.

      Supportability also motivates rewriting the EE software.  The new
      EE can be written using more modern techniques of programming
      practice, such as layering and modularity, which were not as well
      understood when the old EE was first designed, and which will make
      the EE easier to support and to enhance.

      Finally, the new EE includes a number of new features that improve
      the PSN's ability to provide services which are more closely
      optimized to what our customers need for their applications.
      These include new addressing capabilities, precedence levels,
      end-to-end data integrity checks, and monitoring and control
      capabilities.

   2.2  Goals for the New EE

      The new EE's X.25 support is greatly improved over that provided
      by the old EE.  One element of this improvement is at least
      halving the amount of per-message EE protocol overhead.  Another
      element is the unification of the different storage allocation
      mechanisms used by the old EE and X.25 modules, where data
      transferred between the old EE and X.25 must be copied from one
      type of structure to the other.

      The new EE presents, as much as possible, a non-blocking interface
      to the hosts.  If a host overwhelms the PSN with traffic, the PSN
      ultimately has to block it, but this should happen less frequently
      than at present.

      In the old EE, all of the hosts contend for the same pool of
      resources.  In the new EE, fairness is enforced in resource
      allocation among different hosts through per-host minimum
      allocations for buffers and connection blocks as part of a general
      buffer management system.  This insures that no host can be
      completely "shut out" of service by the actions of another host at
      its PSN.



Malis                                                           [Page 3]



RFC 979                                                       March 1986
PSN End-to-End Functional Specification


      The EE supports four precedence levels and optional (on a per-
      network basis) preemption features.

      Addressing capabilities have been extended to include hunt groups.

      Instead of a fixed window of eight outstanding messages between
      any host pair, the maximum window size on an EE connection is
      configurable to a maximum of 127.  The EE allows host pairs to set
      up multiple connections, each with an independent window.

      A result of the old EE's reliance on destination buffer
      reservation is that subnet packets can be lost if an intermediate
      node goes down.  The new EE uses source buffering with
      retransmission in order to provide more reliable service.

      The new EE has a duplex peer protocol, allowing acknowledgments to
      be piggybacked on reverse traffic to reduce protocol overhead.
      When reverse traffic is not available, acknowledgments are
      aggregated and sent together.

      The result of this development will be end-to-end software with
      greater performance, supportability, and functionality.

3  End-to-End Functionality

   This section contains the new EE's functional specification.  It
   describes the services provided to the various types of hosts that
   are supported by the new EE, the addressing capabilities that it
   makes available, the functionality required for the peer protocol,
   the performance goals for the new EE, the EE's network management
   specification, and provisions for testing and debugging.

   3.1  Network Layer Services

      The most important part of designing any new system is determining
      its external functionality.  In the case of the new EE, this is
      the network layer services and interfaces presented to the hosts.

      3.1.1  Common Functionality

         The following three sections list details concerning the new
         EE's support for the X.25, AHIP and Interoperable network layer
         services.  In the interest of brevity, however, additional
         functionality available to all three services is listed herein:

            o  In order to check data integrity as packets cross through
               the network, the old EE relies on a trunk-level,


Malis                                                           [Page 4]



RFC 979                                                       March 1986
PSN End-to-End Functional Specification


               hardware/ firmware-generated, per-packet CRC code (which
               is either 16 or 24 bits in size, depending on the PSN-PSN
               trunk protocol in use) and a software-generated
               per-packet 16-bit checksum.  Neither of these are
               end-to-end checks, only PSN-to-PSN checks.  For the new
               EE, the software checksum has been extended to be an
               optional 32-bit end-to-end checksum, and the per-packet
               software checksum has been reduced to a parity bit.

               The network administration now has a choice as to which
               is most important, efficient utilization of network
               trunks (due to the reduced size of the per-packet
               headers), or strong checks on data integrity.

               Those hosts that require strong data integrity checking
               can request, in their configuration, that all messages
               originating from this host include a 32-bit per-message
               end-to-end checksum.  This checksum is computed in the
               source PSN, is ignored by tandem PSNs along the path, and
               is checked in the destination PSN.  If the checksum does
               not check, the EE's regular source retransmission
               facilities are used to have the message resent.

            o  The old EE's access control mechanism allows 15 separate
               communities of interest to be defined, and uses an
               unnecessarily complicated algorithm to define which
               communities can intercommunicate.  This mechanism is
               being expanded to allow 32 communities of interest,
               rather than the previous limit of 15.  The feature that
               allowed hosts to communicate with a community without
               actually being a member of that community has been
               removed because it was never utilized.

            o  The addressing capabilities of the PSN have been improved
               by the new EE.  In addition to continuing to support the
               old EE's logical addressing facility, hunt groups (for
               both AHIP and X.25 hosts) have been added.  These are
               described further in Section 3.2.

            o  Connection  block  preemption  is  supported on a
               configurable per-network basis.  If a network is
               configured to use  connection block preemption, then
               lower-precedence connections can be closed by the  PSN,
               if  necessary,  in  order  to  maintain  configured
               reserves of PSN resources for higher-precedence
               connections.



Malis                                                           [Page 5]