rfc979.txt

RFC 相关的技术文档

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


         One issue must be raised concerning interoperability between
         X.25 and packet-mode HDH hosts.  In order to efficiently
         interoperate, packet-mode HDH hosts should completely fill
         their middle packet frames with 128 octets of data.
         Packet-mode HDH hosts that send or require receiving middle
         packet frames with less than 128 octets of data can still
         interoperate with X.25 hosts, but at a greater expense of PSN
         CPU resources per message.

   3.2  Addressing

      The old EE supports, for both AHIP and X.25 hosts, two forms of
      host addressing, physical and logical.

      Physical addressing consists of identifying a host port by the
      combination of its PSN number and the port number on that PSN.
      Logical addressing allows an arbitrary 16-bit "name" to refer to a
      list of one or more host ports.  The EE tries to open a connection
      to one of the ports in the list according to the criterion chosen
      for that name: first reachable in the ordered list, closest port
      (in terms of routing delay), or round-robin load sharing.

      For the new EE, logical addressing is supported on an explicit
      per-connection basis: all logical-to-physical address translations
      take place in the source PSN when a connection is established.
      Once this translation has occurred, all data messages on the
      connection are sent to the same physical address.

      In addition, hunt groups are also now supported for both X.25 and
      AHIP hosts.  This new capability allows host ports on a
      destination PSN to be combined into a "hunt group".  The ports
      share the same group identifier, and incoming connections are
      evenly spread over the ports in the group.  This differs from
      logical addressing's load sharing, where all name translations
      take place in the source PSN, the different ports can be on any
      number of PSNs, and the load sharing is on a per-source-PSN basis.
      By contrast, all of the host ports in a hunt group are on the same
      PSN, the group-to-port resolution takes place in the destination
      PSN, and the load sharing of incoming connections can be
      guaranteed over the ports by the destination PSN.  For X.25, hunt
      groups comply with Section 6.24 of the 1984 X.25 Recommendation.
      Note that Called Line Address Modification is not supported.







Malis                                                          [Page 11]



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


   3.3  Protocol Functionality

      The EE peer protocol runs between EE modules in PSNs on either end
      of an EE connection.  This protocol and its mechanisms have to
      perform the following functions:

         o  Provide full duplex connections (the old EE provides simplex
            connections, and any two-way traffic, such as that generated
            by TCP, requires two subnet connections).

         o  Open a connection and optionally send a full message's worth
            of data as a part of the open request (the old EE requires a
            separate opening sequence in each direction before data can
            flow).

         o  Reliably send connection-oriented messages, properly
            fragmented/reassembled and sequenced.

         o  Close (clear) a connection (normally, or in a "clean-up"
            mode after a host or PSN dies).

         o  Reset a connection (like the X.25 reset procedure).

         o  Be able to send a limited amount of out-of-band traffic
            associated with a connection (like the X.25 interrupt).

         o  Use source buffering with message retransmission (after a
            timeout) to insure delivery (the old EE depends on
            destination buffer preallocation, which adds protocol
            overhead and cannot recover from lost packets in the
            subnet).

         o  Use an internal connection window of up to 127 messages.

         o  Support two types of ACKs, Internal ACKs (IACKs) and
            External ACKs (EACKs), which are further described following
            this list

         o  Have an inactivity timer for each connection.  For AHIP and
            Standard X.25, the connection is closed if the timer fires.
            For Basic X.25, the EE uses an internal Hello/I-Heard-You
            sequence with the PSN on the other end of the connection to
            check if the other end's host or PSN is still alive.  If
            not, then the connection is closed.

         o  Be able to gracefully handle resource shortages and avoid
            reassembly lockup problems.


Malis                                                          [Page 12]



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


      As mentioned above, the protocol supports two types of
      acknowledgments, IACKs and EACKs.  Both types of ACKs apply to
      messages only; individual packets are not acknowledged.  Since
      windowing is being used, an individual ACK can be used to
      acknowledge more than one message.

      IACKs are used to cancel the retransmission timer and free source
      buffering, and are sent when a message has been completely
      reassembled and delivered from the EE to either the AHIP or X.25
      level 3 module.  This allows the EE to avoid unnecessary message
      retransmissions, and speeds up the process of freeing source
      buffering when destination hosts are slow to accept messages or,
      in the case of X.25, slow to advance the PSN's window to the
      destination (X.25 does not specify any time limit for a host to
      acknowledge that it received a message).

      EACKs are used to advance the end-to-end window and to cause one
      or more end-to-end X.25 RRs or AHIP RFNMs to be sent to the source
      host.  An EACK is sent when an X.25 host acknowledges a message or
      when an AHIP host actually receives it.

      Both types of ACKs are piggybacked, if possible, on reverse
      traffic to the source PSN (for any connection).  Whenever a packet
      is sent to another PSN, it is filled to the maximum allowed
      subnetwork packet size with any outstanding ACKs that may be
      waiting to be sent to that PSN.  After a configurable period, all
      outstanding ACKs for the same PSN are aggregated together and
      sent.  In addition, succeeding ACKs for the same connection can be
      combined into one, and EACKs can be used to imply that a message
      is being IACKed as well (if the destination host is speedy enough
      when receiving or acknowledging messages to allow IACKs and EACKs
      to be combined).

      This ACK aggregation timer interacts with the source buffering
      retransmission timer in the following manner:  whenever a message
      is sent from a host on one PSN to a host on a second PSN, an IACK
      is sent back to the first PSN when the message has been completely
      reassembled by the destination EE, and an EACK is sent when it has
      been delivered (and perhaps ACKed) by the destination host.  The
      IACK must make it back to the source PSN within the limits of the
      retransmission timer, or unnecessary retransmissions could be sent
      across the network.  This limits the ACK aggregation timer to
      being shorter than the source buffering retransmission timer.

      If the destination host is quick enough when accepting traffic
      from its PSN (with respect to the ACK aggregation timer), then the
      EACK can be combined with the IACK, and only the EACK would be


Malis                                                          [Page 13]



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


      sent.  If the destination host is even quicker, multiple IACKs and
      EACKs could be combined into one EACK.  In the best case, if there
      is a steady stream of traffic going between the two PSNs in both
      directions (but not necessarily over the same connection or even
      between the same pairs of hosts in each direction), then all of
      the IACKs and EACKs could be piggybacked on data packets and cause
      no additional network packets other than the data packets already
      required to send the data messages across the network. In the
      worst case, however, such as when there is only a one-way flow
      from a source PSN to a destination PSN and the destination host is
      very slow to accept the messages from the network, then each data
      message could result in separate IACKs and EACKs being sent back
      to the source PSN in individual packets.  However, even though the
      IACKs may cause additional packets to cross the network, they are
      still less expensive than the source retransmissions that they are
      used to prevent, and they also serve to free up valuable source
      buffering space.

   3.4  Performance and Capacity Goals

      Performance and capacity goals for the new EE include:

         o  Throughput:  The AHIP host-host and host-trunk maximum
            throughput (in packets/second) will be at least as good as
            at present, and should improve for those situations that
            currently entail traffic limitations based upon the old EE's
            underlying protocol.  The current X.25 intrasite host-host
            and host-trunk throughput will each improve by at least 50%.
            The store-and-forward throughput for the new EE's X.25-based
            traffic will improve by at least 100%.

         o  Connections:  The new EE will support at least 500
            simultaneous connections per PSN, and will be able to handle
            at least 50% more call setups per second than at present.

         o  Buffering:  The EE will have at least 400 packet buffers
            available to source-buffer and/or reassemble messages.

         o  Network size:  The EE protocol and module will use data
            structure and message field sizes sufficient to support at
            least up to 255 hosts per PSN and 1023 PSNs per network
            (however, other PSN protocols and modules presently
            constrain these figures to 63 hosts per PSN and 253 PSNs per
            network).

         o  Other:  The EE will support four message precedence levels



Malis                                                          [Page 14]



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


            and a maximum message length of 1024 bytes.  For logical
            addressing, the EE will support at least 1024 logical names
            and at least 2048 address mappings per network.














































Malis                                                          [Page 15]