As per Relevance of the word connection, we have this rfc below:
Network Working Group Andrew G.
Request for Comments: 979 BBN Communications Corp
March 1986
PSN END-TO-END FUNCTIONAL
Status of this
This memo is an updated version of BBN Report 5775, "End-to-
Functional Specification". It has been updated to reflect
since that report was written, and is being distributed in this
to provide information to the ARPA-Internet community about
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
the PSN software (Release 7.0) in the ARPANET and the MILNET can
obtained from DCA. Distribution of this memo is unlimited
1
This memo contains the functional specification for the new BBNCC
End-to-End (EE) protocol and module (PSN stands for Packet
node, and has previously been known as the IMP). The EE module
that portion of the PSN code which is responsible for maintaining
connections that reliably deliver data across the network, and
handling the packet level (level 3) interactions with the hosts.
EE protocol is the peer protocol used between EE modules to create
maintain, and close connections. The new EE is being developed
order to correct a number of deficiencies in the old EE, to
its performance and overall throughput, and to better equip the
to support its current and anticipated host population
The initial version of the new EE is being fielded in PSN
7.0. Both the old and new EEs are resident in the PSN code, and
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
has facilities for switching individual PSNs or the entire
between the old and new EEs. When the old EE is running, PSN 7.0'
functionality is equivalent to that provided by PSN 6.0, and
differences listed in this memo do not apply. Hosts on PSNs
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
project
Section three contains the new EE's functional specification.
describes the services provided to the various types of hosts
Malis [Page 1]
RFC 979 March 1986
PSN End-to-End Functional
are supported by the PSN, the addressing capabilities that it
available, the functionality required for the peer protocol, and
performance goals for the new EE
Two notes concerning terminology are required. Throughout
document, the units of information sent from one host to another
referred to as "messages", and the units into which these
are fragmented for transmission through the subnetwork are
to as "subnet packets" or just "packets". This differs from X.25'
terminology; X.25 "packets" are actually messages. Also, in
report the term "AHIP" is used to refer to the ARPANET Host-
Protocol described in BBN Report 1822, "Specifications for
Interconnection of a Host and an IMP".
2
The old EE was developed almost a decade ago, in the early days
packet-switching technology. This part of the PSN has
stable for eight years, while the environment within which
technology operates has changed dramatically. At the time the old
was developed, it was used in only one network, the ARPANET.
are now many PSN-based networks, some of which are grouped
internets. Originally, AHIP was the only host interface protocol
with NCP above it. The use of X.25 is now rapidly increasing,
TCP/IP has replaced NCP
This section describes the needs for more flexibility and
in some of the limits of the old EE, and lists the goals which
new design should meet
2.1 Benefits of a New
Network growth and the changing network environment make
performance, in terms of increasing the PSN's throughput,
important goal for the new EE. The new EE reduces
traffic overhead, thereby making more efficient use of
line bandwidth and transit PSN processing power
The new EE provides a set of network transport services which
appropriate for both the AHIP and X.25 host interfaces, unlike
old EE, which is highly optimized for and tightly tied to the
host interface
The new EE has an adjustable window facility instead of the
EE's fixed window of eight outstanding messages between any
pair. The old EE applies this limit to all traffic between a
of hosts; it has no notion of multiple independent channels
Malis [Page 2]
RFC 979 March 1986
PSN End-to-End Functional
connections between two hosts, which the new EE allows. A
with satellite trunking, and consequently long delays, is
example of where the new window facility increases the
throughput that can be attained. TACs and gateways
another example where the old EE's fixed window limits throughput
all of the traffic between a host and a TAC or a gateway
uses the same EE connection and is subject to the limit of
outstanding messages, even if more than one user's traffic
are involved. With the new EE, this restriction no
applies
Supportability also motivates rewriting the EE software. The
EE can be written using more modern techniques of
practice, such as layering and modularity, which were not as
understood when the old EE was first designed, and which will
the EE easier to support and to enhance
Finally, the new EE includes a number of new features that
the PSN's ability to provide services which are more
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
capabilities
2.2 Goals for the New
The new EE's X.25 support is greatly improved over that
by the old EE. One element of this improvement is at
halving the amount of per-message EE protocol overhead.
element is the unification of the different storage
mechanisms used by the old EE and X.25 modules, where
transferred between the old EE and X.25 must be copied from
type of structure to the other
The new EE presents, as much as possible, a non-blocking
to the hosts. If a host overwhelms the PSN with traffic, the
ultimately has to block it, but this should happen less
than at present
In the old EE, all of the hosts contend for the same pool
resources. In the new EE, fairness is enforced in
allocation among different hosts through per-host
allocations for buffers and connection blocks as part of a
buffer management system. This insures that no host can
completely "shut out" of service by the actions of another host
its PSN
Malis [Page 3]
RFC 979 March 1986
PSN End-to-End Functional
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
any host pair, the maximum window size on an EE connection
configurable to a maximum of 127. The EE allows host pairs to
up multiple connections, each with an independent window
A result of the old EE's reliance on destination
reservation is that subnet packets can be lost if an
node goes down. The new EE uses source buffering
retransmission in order to provide more reliable service
The new EE has a duplex peer protocol, allowing acknowledgments
be piggybacked on reverse traffic to reduce protocol overhead
When reverse traffic is not available, acknowledgments
aggregated and sent together
The result of this development will be end-to-end software
greater performance, supportability, and functionality
3 End-to-End
This section contains the new EE's functional specification.
describes the services provided to the various types of hosts
are supported by the new EE, the addressing capabilities that
makes available, the functionality required for the peer protocol
the performance goals for the new EE, the EE's network
specification, and provisions for testing and debugging
3.1 Network Layer
The most important part of designing any new system is
its external functionality. In the case of the new EE, this
the network layer services and interfaces presented to the hosts
3.1.1 Common
The following three sections list details concerning the
EE's support for the X.25, AHIP and Interoperable network
services. In the interest of brevity, however,
functionality available to all three services is listed herein
o In order to check data integrity as packets cross
the network, the old EE relies on a trunk-level
Malis [Page 4]
RFC 979 March 1986
PSN End-to-End Functional
hardware/ firmware-generated, per-packet CRC code (
is either 16 or 24 bits in size, depending on the PSN-
trunk protocol in use) and a software-
per-packet 16-bit checksum. Neither of these
end-to-end checks, only PSN-to-PSN checks. For the
EE, the software checksum has been extended to be
optional 32-bit end-to-end checksum, and the per-
software checksum has been reduced to a parity bit
The network administration now has a choice as to
is most important, efficient utilization of
trunks (due to the reduced size of the per-
headers), or strong checks on data integrity
Those hosts that require strong data integrity
can request, in their configuration, that all
originating from this host include a 32-bit per-
end-to-end checksum. This checksum is computed in
source PSN, is ignored by tandem PSNs along the path,
is checked in the destination PSN. If the checksum
not check, the EE's regular source
facilities are used to have the message resent
o The old EE's access control mechanism allows 15
communities of interest to be defined, and uses
unnecessarily complicated algorithm to define
communities can intercommunicate. This mechanism
being expanded to allow 32 communities of interest
rather than the previous limit of 15. The feature
allowed hosts to communicate with a community
actually being a member of that community has
removed because it was never utilized
o The addressing capabilities of the PSN have been
by the new EE. In addition to continuing to support
old EE's logical addressing facility, hunt groups (
both AHIP and X.25 hosts) have been added. These
described further in Section 3.2.
o Connection block preemption is supported on
configurable per-network basis. If a network
configured to use connection block preemption,
lower-precedence connections can be closed by the PSN
if necessary, in order to maintain
reserves of PSN resources for higher-
connections
Malis [Page 5]
RFC 979 March 1986
PSN End-to-End Functional
o The new EE supports congestion control and
resource allocation policies which ensure fairness
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
resources. This ensures that no host can be totally
out from PSN resources by the actions of other hosts
the same PSN. In addition, each PSN is sensitive
congestion in both of the PSNs at the endpoints of
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
X.25 service available from the old EE. The
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
Interface Specification," and 5500, "C/30 PSN X.25
Interface Specification," respectively. In addition,
description of DDN Standard Service, Version 2, is
in Section 3.1.4 of this document
o All data packets and call requests are source-buffered
the source PSN to provide a better level of
for network traffic. This should keep the network
issuing a reset on an open connection as a result of
lost packet in the subnet or any other
subnetwork failure. Except in cases of extreme
or node congestion, recovery from lost subnet packets
automatic and transparent to the end user or host
o Both local and end-to-end significance for host
advancement (based upon the D bit from the host)
planned, but only end-to-end significance is included
the initial release (the old EE did not include
significance). The D bit is passed through the
transparently
3.1.3
Another service provided by the new EE is defined in BBN
1822, "Specifications for the Interconnection of a Host and
IMP", as amended by Report 5506, "The ARPANET 1822L Host
Protocol". This ARPANET Host-IMP Protocol (AHIP) service
Malis [Page 6]
RFC 979 March 1986
PSN End-to-End Functional
supported in a backwards-compatible manner by the new EE;
this is a BBNCC-private protocol, the new EE can improve
service to better match its current uses (the AHIP protocol
first designed over twelve years ago). The main changes
AHIP are to remove the absolute eight-message-in-
restriction for connection-based traffic, and to improve
PSN's "datagram" support for non-connection-based traffic
For this new support, datagram service is planned (for
Release 8.0) to include fragmentation and reassembly by
network, but without requiring the network overhead used
connections, and without the reliability, message sequencing
and duplicate detection that connections provide. However
"destination dead" indications will be provided to the
host where possible and appropriate
With the new EE, hosts are also able to create
connections between host pairs by using the 8-bit "
type" field to specify up to 256 different connections.
field is divided into high-order bits that specify
connection's precedence, and low-order bits that
between multiple connections at the same precedence level
Since the new EE is using four precedence levels, the
type field is used to specify 64 different connections at
of the four precedence levels
AHIP connections will continue to be implicitly created
automatically torn down after a configurable period (
three minutes) of inactivity, or because of connection
contention
To summarize the new end-to-end's AHIP support
o The old EE's AHIP services are supported in
backwards-compatible manner (except where listed below).
o The old EE's uncontrolled (subtype 3) message
will be replaced, in PSN Release 8.0, by the
service mentioned above. This service will
fragmentation and reassembly, so that there is no
restriction on the size of datagrams; will not
that messages are delivered in order or unduplicated,
provide a delivery confirmation; will notify the
host if the destination host or PSN is dead; will
require the connection block overhead associated
connections; and may lose messages in the subnet,
notification to the source host, in the event of
Malis [Page 7]
RFC 979 March 1986
PSN End-to-End Functional
congestion or component failures. This service could
useful for applications that do not need the
reliability or sequentiality of connections and
wish to avoid their associated overhead
Datagrams are not supported by the new EE in PSN
7.0.
o Connections no longer have the old EE's "eight
in flight" restriction, and a pair of hosts can
connected with up to 256 simultaneous
connections. In addition, multiple precedence levels
supported
o The new EE supports interoperability between AHIP
X.25 hosts (see Section 3.1.4 for further details).
o AHIP local, distant, and HDH (both message and
mode) hosts are supported. The new EE does not
VDH hosts. VHA and 32-bit leaders are supported
o Packet-mode HDH has been extended to allow longer
data frames (see BBN Report 1822, Appendix J, for
description of the HDH protocol). Middle packet
can now contain up to 128 octets of data, rather than
previous 126 (although there must still be an even
of octets per frame). Last packet frames can now
up to 127 octets of data, rather than the previous 125,
and the number of octets need not be even. However,
maximum total message size is still 1007 data octets.
PSN uses these new packet frame size limits when
packet frames to packet-mode HDH hosts unless the host
configured to allow only 126-octet frames. In addition
there are restrictions on packet-mode HDH
interoperating with DDN Standard X.25 hosts;
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
interoperability between AHIP and X.25 hosts. On the surface
this may appear difficult, since the two host access
have little in common: X.25 presents a connection-
interface with explicit windowing, while AHIP presents
reliable datagram-oriented interface with implicit
control. However, they both have the same
Malis [Page 8]
RFC 979 March 1986
PSN End-to-End Functional
functionality: they allow the hosts to submit and
messages, and they both provide a reliable and
delivery service
The key to interoperability is the fact that in the new EE
both X.25 and AHIP connections use the same
protocols and constructs. The new EE has AHIP and X.25 Level 3
modules that translate between the specific host protocols
the EE mechanisms. Since these Level 3 host modules share
common interface with the EE, the fact that the two hosts
either side of an EE connection are not using the same
protocol is largely hidden
As a result, the new EE supports basic interoperability
However, there are some special cases that need to be
from one protocol to the other, or just not supported
no mapping exists. For example, AHIP has no analogue of X.25'
Interrupt packet, while X.25 does not support an
datagram service such as AHIP's subtype 3 messages. For
of these cases, the recommendations of BBN Report 5476, "
X.25 Host Interface Specification," have been followed
The interoperable service provided by the new EE is called
Standard Service, Version 2. Standard Service, Version 1,
defined in BBN Reports 5760, "Preliminary
Software Design," and 5900 Revision 1, "Supplement to
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-
Call Precedence Negotiation are mapped directly to
precedence levels, instead of being collapsed into
subnet precedence levels as in Version 1.
o On an interoperable connection, the X.25 protocol ID
an X.25-originated message is translated to an AHIP
number (the upper eight bits of the message-ID field
using a lookup table. Version 1 supports only the
protocol ID and corresponding link number of 155
(decimal). Version 2 allows new values to be added
the lookup table. At present, IP is the only
supported. In addition, the AHIP link number is
used to distinguish one connection from another.
Malis [Page 9]
RFC 979 March 1986
PSN End-to-End Functional
guarantees that when an AHIP host is sending messages
an X.25 host, messages using different link numbers
into the X.25 host on different X.25 connections
o Since a "translation module" is no longer necessary
the PSN, interoperable connections now have end-to-
significance, with a direct correspondence between X.25
RRs and AHIP RFNMs. This preserves the meaning of
RFNM as defined in Report 1822. Although Release 7.0
only offers end-to-end significance, the D bit is
transparently on Standard Service connections between
X.25 hosts
o Up to 256 simultaneous connections are supported
host pairs that are using the same addresses
precedence levels. Version 1 only supported one
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
discussion, and three of them need to be specifically
here. First, for DDN Standard Service, Version 1,
acknowledgments have local significance only, and the D
must be set to 0 in the call request. In DDN Standard Service
Version 2, only end-to-end significance is being provided,
was mentioned above. For backwards compatibility with
1, the D bit can be set to 0 or 1 in a call, but hosts
advised that only end-to-end significance is provided
Version 2.
Second, non-standard Default Precedence is not supported
either Standard Service Version 1 or Version 2. Support
this facility in Version 1 was withdrawn at the request of DCA
Third, although DTEs are allowed to request maximum
sizes of 16, 32, and 64 octets, the DCE always negotiates up
128 octets, as per Section 6.12 ("Flow Control
Negotiation") of the CCITT 1984 X.25 Recommendation. This
true of both Version 1 and Version 2. Since IP and TCP
required when Standard Service is in use, this is a
restriction (due to the length of IP and TCP headers).
Malis [Page 10]
RFC 979 March 1986
PSN End-to-End Functional
One issue must be raised concerning interoperability
X.25 and packet-mode HDH hosts. In order to
interoperate, packet-mode HDH hosts should completely
their middle packet frames with 128 octets of data
Packet-mode HDH hosts that send or require receiving
packet frames with less than 128 octets of data can
interoperate with X.25 hosts, but at a greater expense of
CPU resources per message
3.2
The old EE supports, for both AHIP and X.25 hosts, two forms
host addressing, physical and logical
Physical addressing consists of identifying a host port by
combination of its PSN number and the port number on that PSN
Logical addressing allows an arbitrary 16-bit "name" to refer to
list of one or more host ports. The EE tries to open a
to one of the ports in the list according to the criterion
for that name: first reachable in the ordered list, closest
(in terms of routing delay), or round-robin load sharing
For the new EE, logical addressing is supported on an
per-connection basis: all logical-to-physical address
take place in the source PSN when a connection is established
Once this translation has occurred, all data messages on
connection are sent to the same physical address
In addition, hunt groups are also now supported for both X.25
AHIP hosts. This new capability allows host ports on
destination PSN to be combined into a "hunt group". The
share the same group identifier, and incoming connections
evenly spread over the ports in the group. This differs
logical addressing's load sharing, where all name
take place in the source PSN, the different ports can be on
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
PSN, the group-to-port resolution takes place in the
PSN, and the load sharing of incoming connections can
guaranteed over the ports by the destination PSN. For X.25,
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
3.3 Protocol
The EE peer protocol runs between EE modules in PSNs on either
of an EE connection. This protocol and its mechanisms have
perform the following functions
o Provide full duplex connections (the old EE provides
connections, and any two-way traffic, such as that
by TCP, requires two subnet connections).
o Open a connection and optionally send a full message's
of data as a part of the open request (the old EE requires
separate opening sequence in each direction before data
flow).
o Reliably send connection-oriented messages,
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
associated with a connection (like the X.25 interrupt).
o Use source buffering with message retransmission (after
timeout) to insure delivery (the old EE depends
destination buffer preallocation, which adds
overhead and cannot recover from lost packets in
subnet).
o Use an internal connection window of up to 127 messages
o Support two types of ACKs, Internal ACKs (IACKs)
External ACKs (EACKs), which are further described
this
o Have an inactivity timer for each connection. For AHIP
Standard X.25, the connection is closed if the timer fires
For Basic X.25, the EE uses an internal Hello/I-Heard-
sequence with the PSN on the other end of the connection
check if the other end's host or PSN is still alive.
not, then the connection is closed
o Be able to gracefully handle resource shortages and
reassembly lockup problems
Malis [Page 12]
RFC 979 March 1986
PSN End-to-End Functional
As mentioned above, the protocol supports two types
acknowledgments, IACKs and EACKs. Both types of ACKs apply
messages only; individual packets are not acknowledged.
windowing is being used, an individual ACK can be used
acknowledge more than one message
IACKs are used to cancel the retransmission timer and free
buffering, and are sent when a message has been
reassembled and delivered from the EE to either the AHIP or X.25
level 3 module. This allows the EE to avoid unnecessary
retransmissions, and speeds up the process of freeing
buffering when destination hosts are slow to accept messages or
in the case of X.25, slow to advance the PSN's window to
destination (X.25 does not specify any time limit for a host
acknowledge that it received a message).
EACKs are used to advance the end-to-end window and to cause
or more end-to-end X.25 RRs or AHIP RFNMs to be sent to the
host. An EACK is sent when an X.25 host acknowledges a message
when an AHIP host actually receives it
Both types of ACKs are piggybacked, if possible, on
traffic to the source PSN (for any connection). Whenever a
is sent to another PSN, it is filled to the maximum
subnetwork packet size with any outstanding ACKs that may
waiting to be sent to that PSN. After a configurable period,
outstanding ACKs for the same PSN are aggregated together
sent. In addition, succeeding ACKs for the same connection can
combined into one, and EACKs can be used to imply that a
is being IACKed as well (if the destination host is speedy
when receiving or acknowledging messages to allow IACKs and
to be combined).
This ACK aggregation timer interacts with the source
retransmission timer in the following manner: whenever a
is sent from a host on one PSN to a host on a second PSN, an
is sent back to the first PSN when the message has been
reassembled by the destination EE, and an EACK is sent when it
been delivered (and perhaps ACKed) by the destination host.
IACK must make it back to the source PSN within the limits of
retransmission timer, or unnecessary retransmissions could be
across the network. This limits the ACK aggregation timer
being shorter than the source buffering retransmission timer
If the destination host is quick enough when accepting
from its PSN (with respect to the ACK aggregation timer), then
EACK can be combined with the IACK, and only the EACK would
Malis [Page 13]
RFC 979 March 1986
PSN End-to-End Functional
sent. If the destination host is even quicker, multiple IACKs
EACKs could be combined into one EACK. In the best case, if
is a steady stream of traffic going between the two PSNs in
directions (but not necessarily over the same connection or
between the same pairs of hosts in each direction), then all
the IACKs and EACKs could be piggybacked on data packets and
no additional network packets other than the data packets
required to send the data messages across the network. In
worst case, however, such as when there is only a one-way
from a source PSN to a destination PSN and the destination host
very slow to accept the messages from the network, then each
message could result in separate IACKs and EACKs being sent
to the source PSN in individual packets. However, even though
IACKs may cause additional packets to cross the network, they
still less expensive than the source retransmissions that they
used to prevent, and they also serve to free up valuable
buffering space
3.4 Performance and Capacity
Performance and capacity goals for the new EE include
o Throughput: The AHIP host-host and host-trunk
throughput (in packets/second) will be at least as good
at present, and should improve for those situations
currently entail traffic limitations based upon the old EE'
underlying protocol. The current X.25 intrasite host-
and host-trunk throughput will each improve by at least 50%.
The store-and-forward throughput for the new EE's X.25-
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
at least 50% more call setups per second than at present
o Buffering: The EE will have at least 400 packet
available to source-buffer and/or reassemble messages
o Network size: The EE protocol and module will use
structure and message field sizes sufficient to support
least up to 255 hosts per PSN and 1023 PSNs per
(however, other PSN protocols and modules
constrain these figures to 63 hosts per PSN and 253 PSNs
network).
o Other: The EE will support four message precedence
Malis [Page 14]
RFC 979 March 1986
PSN End-to-End Functional
and a maximum message length of 1024 bytes. For
addressing, the EE will support at least 1024 logical
and at least 2048 address mappings per network
Malis [Page 15]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
