📄 rfc979.txt
字号:
RFC 979 March 1986
PSN End-to-End Functional Specification
o The new EE supports congestion control and improved
resource allocation policies which ensure fairness and
graceful degradation of service under extreme load.
Certain resources can be prereserved to each host port,
and each port can also be limited in its use of shared
resources. This ensures that no host can be totally shut
out from PSN resources by the actions of other hosts at
the same PSN. In addition, each PSN is sensitive to
congestion in both of the PSNs at the endpoints of each
connection, and it can exert backpressure (flow control)
on hosts, as necessary, to prevent congestion.
3.1.2 X.25
The new EE's X.25 service represents an improvement over the
X.25 service available from the old EE. The following
paragraphs summarize the X.25 support in the new EE:
o The new EE provides both DDN Standard and Basic X.25
service, as described in BBN Reports 5476, "DDN X.25 Host
Interface Specification," and 5500, "C/30 PSN X.25
Interface Specification," respectively. In addition, the
description of DDN Standard Service, Version 2, is found
in Section 3.1.4 of this document.
o All data packets and call requests are source-buffered in
the source PSN to provide a better level of reliability
for network traffic. This should keep the network from
issuing a reset on an open connection as a result of a
lost packet in the subnet or any other occasional
subnetwork failure. Except in cases of extreme network
or node congestion, recovery from lost subnet packets is
automatic and transparent to the end user or host.
o Both local and end-to-end significance for host window
advancement (based upon the D bit from the host) are
planned, but only end-to-end significance is included in
the initial release (the old EE did not include local
significance). The D bit is passed through the network
transparently.
3.1.3 AHIP
Another service provided by the new EE is defined in BBN Report
1822, "Specifications for the Interconnection of a Host and an
IMP", as amended by Report 5506, "The ARPANET 1822L Host Access
Protocol". This ARPANET Host-IMP Protocol (AHIP) service is
Malis [Page 6]
RFC 979 March 1986
PSN End-to-End Functional Specification
supported in a backwards-compatible manner by the new EE; since
this is a BBNCC-private protocol, the new EE can improve the
service to better match its current uses (the AHIP protocol was
first designed over twelve years ago). The main changes to
AHIP are to remove the absolute eight-message-in-flight
restriction for connection-based traffic, and to improve the
PSN's "datagram" support for non-connection-based traffic.
For this new support, datagram service is planned (for PSN
Release 8.0) to include fragmentation and reassembly by the
network, but without requiring the network overhead used by
connections, and without the reliability, message sequencing,
and duplicate detection that connections provide. However,
"destination dead" indications will be provided to the source
host where possible and appropriate.
With the new EE, hosts are also able to create multiple
connections between host pairs by using the 8-bit "handling
type" field to specify up to 256 different connections. The
field is divided into high-order bits that specify the
connection's precedence, and low-order bits that distinguish
between multiple connections at the same precedence level.
Since the new EE is using four precedence levels, the handling
type field is used to specify 64 different connections at each
of the four precedence levels.
AHIP connections will continue to be implicitly created and
automatically torn down after a configurable period (nominally
three minutes) of inactivity, or because of connection block
contention.
To summarize the new end-to-end's AHIP support:
o The old EE's AHIP services are supported in a
backwards-compatible manner (except where listed below).
o The old EE's uncontrolled (subtype 3) message service
will be replaced, in PSN Release 8.0, by the datagram
service mentioned above. This service will provide
fragmentation and reassembly, so that there is no special
restriction on the size of datagrams; will not insure
that messages are delivered in order or unduplicated, or
provide a delivery confirmation; will notify the source
host if the destination host or PSN is dead; will not
require the connection block overhead associated with
connections; and may lose messages in the subnet, without
notification to the source host, in the event of subnet
Malis [Page 7]
RFC 979 March 1986
PSN End-to-End Functional Specification
congestion or component failures. This service could be
useful for applications that do not need the absolute
reliability or sequentiality of connections and therefore
wish to avoid their associated overhead.
Datagrams are not supported by the new EE in PSN Release
7.0.
o Connections no longer have the old EE's "eight messages
in flight" restriction, and a pair of hosts can be
connected with up to 256 simultaneous implicit
connections. In addition, multiple precedence levels are
supported.
o The new EE supports interoperability between AHIP and
X.25 hosts (see Section 3.1.4 for further details).
o AHIP local, distant, and HDH (both message and packet
mode) hosts are supported. The new EE does not support
VDH hosts. VHA and 32-bit leaders are supported.
o Packet-mode HDH has been extended to allow longer packet
data frames (see BBN Report 1822, Appendix J, for a
description of the HDH protocol). Middle packet frames
can now contain up to 128 octets of data, rather than the
previous 126 (although there must still be an even number
of octets per frame). Last packet frames can now contain
up to 127 octets of data, rather than the previous 125,
and the number of octets need not be even. However, the
maximum total message size is still 1007 data octets. The
PSN uses these new packet frame size limits when sending
packet frames to packet-mode HDH hosts unless the host is
configured to allow only 126-octet frames. In addition,
there are restrictions on packet-mode HDH when
interoperating with DDN Standard X.25 hosts; these
restrictions are discussed in Section 3.1.4.
3.1.4 Interoperability (DDN Standard X.25)
One of the main goals of the new EE is to provide
interoperability between AHIP and X.25 hosts. On the surface,
this may appear difficult, since the two host access protocols
have little in common: X.25 presents a connection-oriented
interface with explicit windowing, while AHIP presents a
reliable datagram-oriented interface with implicit flow
control. However, they both have the same underlying
Malis [Page 8]
RFC 979 March 1986
PSN End-to-End Functional Specification
functionality: they allow the hosts to submit and receive
messages, and they both provide a reliable and sequenced
delivery service.
The key to interoperability is the fact that in the new EE,
both X.25 and AHIP connections use the same underlying
protocols and constructs. The new EE has AHIP and X.25 Level 3
modules that translate between the specific host protocols and
the EE mechanisms. Since these Level 3 host modules share a
common interface with the EE, the fact that the two hosts on
either side of an EE connection are not using the same access
protocol is largely hidden.
As a result, the new EE supports basic interoperability.
However, there are some special cases that need to be mapped
from one protocol to the other, or just not supported because
no mapping exists. For example, AHIP has no analogue of X.25's
Interrupt packet, while X.25 does not support an unreliable
datagram service such as AHIP's subtype 3 messages. For each
of these cases, the recommendations of BBN Report 5476, "DDN
X.25 Host Interface Specification," have been followed.
The interoperable service provided by the new EE is called DDN
Standard Service, Version 2. Standard Service, Version 1, is
defined in BBN Reports 5760, "Preliminary Interoperable
Software Design," and 5900 Revision 1, "Supplement to BBN
Report Nos. 5476 and 5760".
The major differences between Versions 1 and 2 are:
o Version 2 offers improved performance over Version 1.
o The EE now provides four precedence levels. Therefore,
the four precedence levels allowed in the DDN-private
Call Precedence Negotiation are mapped directly to subnet
precedence levels, instead of being collapsed into two
subnet precedence levels as in Version 1.
o On an interoperable connection, the X.25 protocol ID in
an X.25-originated message is translated to an AHIP link
number (the upper eight bits of the message-ID field)
using a lookup table. Version 1 supports only the IP
protocol ID and corresponding link number of 155
(decimal). Version 2 allows new values to be added to
the lookup table. At present, IP is the only protocol
supported. In addition, the AHIP link number is also
used to distinguish one connection from another. This
Malis [Page 9]
RFC 979 March 1986
PSN End-to-End Functional Specification
guarantees that when an AHIP host is sending messages to
an X.25 host, messages using different link numbers come
into the X.25 host on different X.25 connections.
o Since a "translation module" is no longer necessary in
the PSN, interoperable connections now have end-to-end
significance, with a direct correspondence between X.25
RRs and AHIP RFNMs. This preserves the meaning of the
RFNM as defined in Report 1822. Although Release 7.0
only offers end-to-end significance, the D bit is passed
transparently on Standard Service connections between two
X.25 hosts.
o Up to 256 simultaneous connections are supported between
host pairs that are using the same addresses and
precedence levels. Version 1 only supported one such
connection.
The following Version 1 services are not offered by Version 2:
o Permanent Virtual Circuits.
o X.25 protocol bypass (a BBN-private service).
A number of items in Report 5760 were the subject of some
discussion, and three of them need to be specifically mentioned
here. First, for DDN Standard Service, Version 1,
acknowledgments have local significance only, and the D bit
must be set to 0 in the call request. In DDN Standard Service,
Version 2, only end-to-end significance is being provided, as
was mentioned above. For backwards compatibility with Version
1, the D bit can be set to 0 or 1 in a call, but hosts are
advised that only end-to-end significance is provided in
Version 2.
Second, non-standard Default Precedence is not supported by
either Standard Service Version 1 or Version 2. Support for
this facility in Version 1 was withdrawn at the request of DCA.
Third, although DTEs are allowed to request maximum packet
sizes of 16, 32, and 64 octets, the DCE always negotiates up to
128 octets, as per Section 6.12 ("Flow Control Parameter
Negotiation") of the CCITT 1984 X.25 Recommendation. This is
true of both Version 1 and Version 2. Since IP and TCP are
required when Standard Service is in use, this is a reasonable
restriction (due to the length of IP and TCP headers).
Malis [Page 10]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -