specification techniques and formal specification. It plans to
generate automatically an implementation of the ISO formal
specification and verify it against the NBS specification using the
NBS test tools. In the committee's opinion this makes the risk of
unintentional changes in the ISO specification quite low.
One possible risk remains. The ISO specification for TP-4 that was
approved is an informal document subject to the ambiguities of
informal protocol specifications. The formalization may remove
ambiguities that have gone undetected and that were the basis of its
approval. It is conceivable that once these ambiguities are exposed,
the current consensus for TP-4 may dissolve. The committee considers
this risk to be very low. The areas of ambiguity in protocol
specifications are typically only of concern to protocol implementors.
The current protocol implementors through much of the world are
typically using the NBS formal specifications as a basis of their
implementations of TP-4 and have access to the NBS test tools for
National Research Council [Page 22]
RFC942 February 1985
Report Transport on Protocols
certifying their implementations. In the event of a possible
conflict, the majority of implementors could be expected to support
resolution of ambiguities in favor of the current NBS formal
specification, making it unlikely that ISO would approve an alternate
resolution.
Errors in Protocol Implementation
Several factors influence the likelihood of errors in a protocol
implementation. These include the complexity of the protocol, quality
of the protocol specification, the experience of the implementors, and
the availability of test tools. Based on the availability of the NBS
test tools and formal protocol specification for TP-4, the committee
did not see any significant risk of errors in implementing TP-4.
Performance Issues
The largest risk in implementing TP-4 concerns the performance of the
implementations. This risk is not inherent in the protocol as
specified, but is present in new implementations of any transport
protocol. Experience has shown that performance can often be improved
by a factor of two or more by careful attention to implementation
details and careful performance measurement and tuning. The committee
considered it likely that some initial implementations of TP-4 will
have significantly lower performance than the current mature
implementations of TCP. Evidence to support this conclusion may be
found in data supplied by the DOD which show a wide range of
performance of TCP implementations.
Some members of the committee expressed the belief that over the long
term, TP-4 will afford better performance due to widespread commercial
support. Vendors will be highly motivated to optimize performance of
their TP-4 implementations, since a large number of users will
benchmark implementation performance. Many individuals will become
familiar with implementations of TP-4 and with configuring and
operating networks based on TP-4. Initially, this expertise will be
found in organizations developing TP-4 implementations and
installation.
The committee believes that the largest performance risks are short
term. The performance of existing DOD high-level protocols may be
affected by subtle differences between TP-4 and TCP interfaces.
Highlevel DOD implementations and protocols may require retuning to
attain some high-level efficiency using TP-4. Another short-term risk
is potential lack of experience in configuring and operating
TP-4-based networks. The committee believes that a program of testing
and development would minimize these risks, ensuring that the current
high-level DOD protocols run effectively on TP-4-based networks.
There is a possibility that the equivalent, but different, protocol
mechanisms and interfaces in TP-4 may manifest some undesirable
behavior that is not expected and which cannot easily be removed by
tuning. In this event ISO may find it necessary to make some
National Research Council [Page 23]
RFC942 February 1985
Report Transport on Protocols
modifications to TP-4. It is unlikely that such problems will be
serious enough to prevent an early transition to TP-4. If such
problems are discovered, it is expected that they can be handled
through the normal standards process of periodic enhancement. A
number of proprietary commercial networking protocols are similar in
operation to TP-4 and do not have serious performance problems. Any
enhancements that may be desirable can probably be added to TP-4 in a
compatible fashion, permitting interoperation of enhanced and
unenhanced implementations.
TABLE: Comparison of DOD and ISO IP Packet Formats
DOD ISO (not in correct order)
----------------------------------------------------------------------
Protocol version: 4 bits Version: 8 bits
Header Length (in 32-bit words): [Header] Length (in bytes): 8 bits
4 bits
Type of service: 8 bits Quality of service**: 8 bits
(includes 3-bit Precedence) Precedence**: 8 bits
Total Length: 16 bits Segment Length: 16 bits
ID: 16 bits Data Unit ID*: 16 bits
Don't Fragment flag Segmentation Permitted flag
More Fragments flag More Segments flag
Fragment offset: 13 bits Segment offset*: 16 bits
Time to live (sec): 8 bits Lifetime (.5 sec): 8 bits
Protocol number: 8 bits ---
Header checksum: 16 bits Header checksum: 16 bits
(provided by subnet layer) Network Layer Protocol ID: 8 bits
--- [Generate] Error flag
(in ICMP) Type: 5 bits
--- Total Length*: 16 bits
............. .............
Source address: 32 bits Source address length: 8 bits
Source address: var.
Dest. address: 32 bits Dest. address length: 8 bits
Dest. address: var.
............. .............
OPTIONS: NOP, Security, OPTIONS: Padding, Security
Source Route, Record Route, Source Route, Record Route,
Stream ID, Time Stamp Quality of service, Precedence,
Error reason (only for error type)
............. .............
DATA DATA
......................................................................
* only present if segmentation is in use
** in options
National Research Council [Page 24]
RFC942 February 1985
Report Transport on Protocols
IV. STATUS OF DOD AND ISO PROTOCOL IMPLEMENTATIONS AND SPECIFICATIONS
DEPARTMENT OF DEFENSE
The DOD internetting protocol was first introduced in 1974 and later
split into separate TCP and IP specifications. From 1974 until 1978,
when they were adopted as DOD standards, the protocols underwent a
number of major revisions. These revisions were largely a result of
extensive experience gained by researchers working on the DARPA
Internet project. The DARPA "Request for Comment" and "Internet
Experimental Note" technical report series document the conclusions of
numerous protocol-related studies and discussions. Successive
specifications of TCP and other internet protocols are also given by
reports in these series. Most of these specifications were informally
presented and were accompanied by discussions that affected design
choices. The most recent TCP documents introduce a more formal style
of presentation (11).
The first experimental TCP implementations were completed in 1974 at
Stanford University and Bolt Beranek and Newman, Inc., for the
PDP-11/ELF and DEC-10/TENEX systems, respectively. Today
implementation exists for numerous computer systems. While many of
these were implemented at and are supported by university and other
research groups, several are available as commercial products.
Testing of TCP was done on the ARPANET (12), other DOD networks
(Satellite net, packet radio), and a variety of local networks. For
several years a number of DARPA contractors used TCP in parallel with
the old ARPANET transport protocol (NCP). In addition, for about six
months preceding the January 1, l983, ARPANET cutover from NCP to TCP,
these hosts were joined by additional TCP-only hosts (for a total of
approximately thirty). This extensive testing prior to the cutover to
TCP enabled the networks involved to maintain operational capability
throughout
-----
(11) Transport Control Protocol, DOD MIL-STD-1778, August 1983.
(12) The ARPANET is a data communications network established in 1969
by the DOD's Advanced Research Projects Agency to interconnect the
computer resources at selected research centers at substantially lower
costs than systems then available. The ARPANET is a fully operational
80-node network that interconnects over 200 host computers in the United
States, the United Kingdom, and Norway. ARPA became the Defense
Advanced Research Projects Agency (DARPA) in 1973.
National Research Council [Page 25]
RFC942 February 1985
Report Transport on Protocols
the transition and to achieve normal service levels in a few months.
Today the TCP-based DOD networks includes hundreds of hosts (over 300
on DDN alone) and serves thousands of users. Traffic on just the
ARPANET component is now approximately 500 million packets per month.
TCP is also extensively used on local area networks including Ethernet
and Pronet, as well as on CSNET, the Computer Science Research Network
(Telenet hosts).
In addition to TCP, the DOD protocol architecture includes internet
layer protocols for communication between hosts and gateways (ICMP) and
between gateways (GGP). Experience indicates that the design of robust
and powerful gateways that internet numerous networks and provide
survivability is a complex challenge. DOD is developing new gateway
protocols that could be adapted to work with either DOD's or ISO's IP.
The higher-level protocols currently used on DDN for electronic mail
(Simple Mail Transfer Protocol), file transfer (File Transfer
Protocol), and remote log-in (Telnet) are TCP-specific. Their
specifications are stable, and numerous implementations exist. The DOD
has indicated its intent to adopt ISO higher-level protocols when they
are specified and implementations are available.
The committee has concluded that the DOD transport and internet
protocols are well tested and robust. It is unlikely that major
problems with their design or specifications will be uncovered. No
comprehensive facility or procedures for testing new implementations of
TCP now exist, although efforts in this area are being started at
Defense Communications Agency (DCA).
INTERNATIONAL STANDARDS ORGANIZATION
Standardization and development of the ISO IP and ISO TP-4 are
proceeding in a relatively independent fashion. Currently, TP-4 is
further along in the standardization process. The local area network
communications environment has created an immediate need for TP-4
functions; however, communications within a single Local Area Network
(LAN) do not need an internet capability. A "null" IP has been defined
to enable TP-4 to be used on a single LAN without the necessity of a
complete IP. It is quite likely that some early TP-4 products will
implement this null IP, leaving implementation of the complete IP for
future product development. In the following discussion, TP-4 and IP
will be treated separately due to this potential independence.
TP-4 Status and Plans
The ISO TP-4 became a Draft International Standard in September 1983.
The final stages in standardization are primarily procedural. The
committee expects products that implement TP-4 to be widely available
in the market within about two years. It normally takes twelve to
eighteen months for implementations and testing prior to product
announcement. Some vendors apparently began implementation and testing
the protocol
National Research Council [Page 26]
RFC942 February 1985
Report Transport on Protocols
soon after it became a draft proposal in June 1982, because the
protocol was essentially frozen at that time.
At present, INTEL and Able Computer have announced the availability of
products that implement TP-4 for use over LANs. The committee does
not know, however, whether these products have been delivered or
incorporated into systems. In addition, more than twenty companies
have indicated their support of TP-4 and their intention to
incorporate TP-4 into future products, without announcing specific
products or availability dates. Most companies do not make specific
product announcements until relatively late in the product development
process.
In December 1982 six vendors and network users interested in early
development of TP-4 products requested NBS to hold a series of
workshops on the operation of TP-4 in a LAN environment. To date,
four workshops have been held, with more than thirty companies in
attendance. The first workshop set a goal of demonstrating
multivendor networking at a major U.S. national computer conference.
The second workshop, held in April 1983, determined that
demonstrations would include a file transfer application and would be
developed on two local area network technologies currently
standardized by the Institute of Electrical and Electronics Engineers
(IEEE). These technologies are the Carrier Sense Multiple Access with
Collision Detection, which is standardized by IEEE committee 802.3,
and the Token Bus, which is standardized by IEEE committee 803.4. The
workshop selected the National Computer Conference in July 1984 for
the demonstrations.
Vendors committed to the demonstration developed and tested TP-4
implementations using the NBS test tools. The workshops defined a
schedule that called for individual testing through April 1984 with
multivendor testing commencing thereafter. While the vendors that
participated in the demonstration have emphasized that participation
in the demonstration is not a commitment to product development, a
number of large customers have indicated that there will be an
immediate market demand for TP-4 implementation as soon after the
demonstration as practical. The committee considers it highly likely
that many commercial vendors will announce commitments to deliver TP-4
products shortly after the demonstration.
Internetwork Protocol Status and Plans
The ISO Internetwork Protocol (IP) became a Draft International
Standard (DIS) in May 1984 (13). The DIS was out for ballot for the
previous eight months. Attaining DIS status freezes the technical
approach, permitting implementations to begin.
-----
(13) ISO Draft Proposal, Information Processing Systems -- Data
Communications -- Protocol for Providing Connectionless Network
Services, DP 8473, May 1984.
National Research Council [Page 27]
RFC942 February 1985
Report Transport on Protocols
The ISO IP specification is only one of several specifications needed
to completely specify the Network Layer. A number of other
specifications are needed, including a Gateway-to-Host error protocol,
a network wide addressing plan, and a Gateway-to-Gateway Protocol for
managing routing information. A complete specification is needed
before an internetwork, consisting of gateways and hosts, can be
deployed. Most of the complexity of the Network Layer, however, is
confined to the gateways. A complete standardization of the Network
Layer is not required to develop and deploy host systems.
The International Standards Organization is currently developing
proposals for conveying error information between hosts and gateways.
It is expected that responses to the Draft Proposal by ISO members
will include proposals to provide these functions. The committee does
not consider this a controversial area and expects that these
capabilities will be included in the ISO standard by the time it
reaches Draft International Status.
Addressing is a more complex issue. The addressing structure of a
computer internetwork depends on complex trade-offs between
implementation complexity, flexibility, network cost, and network
robustness. Addressing structure in a large network can influence the
range of possible policy decisions available for routing network
traffic. The trade-offs for a military environment may be
significantly different from those of a commercial environment. The
ISO has considered these factors in its existing IP. A flexible
addressing scheme is provided, permitting implementation of a variety
of addressing structures. Host computers need not be concerned with
the internal structure of addresses. The committee considers that the
IP-addressing scheme has sufficient flexibility that host
implementations can be constructed that will support the full range of
addressing philosophies allowed by ISO, including those needed by DOD.
Routing algorithms, like addressing, are complex and often
controversial. For this reason ISO has not yet attempted
standardization of routing algorithms. A routing algorithm is a key
part of a Gateway-to-Gateway Protocol. A single network must
implement a common routing algorithm. In the absence of an ISO
routing algorithm, a network must be based on either proprietary
routing algorithms or on other standards.
The committee has studied the current ISO IP and the current ISO
addressing structure. It believes that it will be possible to map the
current DOD IP-addressing structure and routing algorithm into the ISO
network layer. In practice this means that the Gateway-to-Host
Protocols and addressing formats will fully comply with the ISO
standards, while gateways will need to include additional DOD
capabilities. (This is addressed in recommendations, section IX.)
This approach will enable DOD to procure commercial host
implementations, while retaining the need for procuring DOD-specific
gateways. The committee believes these hybrid DOD-ISO gateways can be
readily developed by modifying existing DOD gateway implementations.
Since the majority of systems in a network are hosts and not gateways,
National Research Council [Page 28]
RFC942 February 1985
Report Transport on Protocols
the committee considers this approach worthwhile.
To the committee's knowledge no vendor has yet announced plans to
support the ISO Internetwork Protocol. This is not surprising, since
the ISO IP attained Draft Proposal status only recently. The
committee has considered the possibility that the ISO IP may not
attain the same wide level of market demand and vendor support
anticipated by TP-4. Since host support of IP is necessary for DOD to
migrate to ISO protocols, the committee has considered this question
in some depth.
While it is possible to operate TP-4 directly over a LAN or directly
over an X.25-based, wide-area network, some form of internetwork
capability or alternative approach is needed to interconnect systems
attached to multiple LANs via Wide Area Networks (WANs). In the
current ISO open systems architecture, this function is to be provided
by the Network layer. There are two possible Network layer services,
connectionless and connection oriented. The ISO architecture permits
both of these services, leaving it to the market place to determine
which approach is to be selected. The DOD believes that the
connectionless approach best suits their needs.
Developing a connection-oriented network that operates over a mixed
LAN and WAN environment is considerably more difficult than developing
a connectionless one. Existing LANs are inherently connectionless and
existing (X.25) WANs are inherently connection oriented. A protocol
to provide internetwork service between these LANs must arrive at a
common subnetwork capability. It is a relatively simple matter to
adapt a connection-oriented to a connectionless service since it can
be done by ignoring unneeded functions of the connection-oriented
service. Adapting a connectionless subnetwork to the needs of a
connection-oriented network service is much more difficult. Many of
the functions provided by TP-4 would be needed in the network layer to
build such a service.
Some work is currently going on in European Computer Manufacturer's
Association (ECMA) to interconnect WANs and LANs in a
connection-oriented fashion. There is considerable controversy
surrounding several proposals, since some participants in the
standards process do not believe the proposals conform to the ISO
Reference Model for Open Systems Interconnection. This, plus their
complexity, makes it unlikely that a connection-oriented network
standard will gain support in ISO in the immediate future.
There is an immediate need for users to build networks consisting of
interconnected LANs and WANs. Such networks are currently in place
using vendor proprietary architectures. Market pressures to build
multivendor LAN and WAN networks make it quite likely that vendors
will adopt the immediate solution and implement the connectionless ISO
IP. The committee believes that DOD can enhance the early
availability of ISO IP by announcing its intention to use it.
Commercial availability of IP is an important part of a migration
strategy, as described in the section on recommendations. The
National Research Council [Page 29]
RFC942 February 1985
Report Transport on Protocols
committee believes that vendors would be responsive to DOD requests
for IP, since IP is quite simple to implement in comparison with TP-4
and since they foresee the need to operate in mixed LAN-WAN
environments.
National Research Council [Page 30]
RFC942 February 1985
Report Transport on Protocols
V. MARKETS
The committee reviewed the market demand and its potential with respect
to both TCP and TP-4 to provide an indication of the likelihood and
rapidity with which competition and its benefits will develop. The
committee concludes that the market demand for TCP protocols will be
small outside the United States. The demand for TP-4, on the other
hand, is expected to be worldwide.
In this report we use the term market demand to indicate the potential
or actual demand for products using the protocols under discussion. A
large market is characterized by a broad demand from all sectors of the
marketplace: consumers, businesses, and governments. The broadest
demand is an international demand in all sectors. We distinguish the
demand for products from the supply that usually develops as a result of
the demand. It is assumed here that a broad market demand will result in
a broad range of products, competitive in price, quality, function, and
performance.
The demand for products implementing computer communication protocols is
discussed in relation to the requirements placed on the potential
customer. Specifically, the customer may be required to acquire products
that meet one or the other of the standards under discussion or may have
no obligation to use either of the two. That is, customers will fall
into one of the following classes with respect to these standards:
1. DOD standards required.
2. International or National standards required.
3. No requirement with respect to standards.
Although customers in the third class may be under no formal obligation
to use standards, they may still prefer a standard solution for several
possible real or perceived benefits. They may, for example, obtain a
broader selection of products using the standard solution or may obtain
a more competitive price. They may also require a specific
communication protocol in order to share information with products that
are required by fiat to implement certain standard protocols. This need
for compatible protocols to communicate is a powerful driving force
toward communication standards.
DEPARTMENT OF DEFENSE NETWORKS MARKET STATUS AND PLANS
The major networks of the Defense Data Network include the following:
National Research Council [Page 31]
RFC942 February 1985
Report Transport on Protocols
Military Network (MILNET)--operational and growing.
Advanced Research Projects Agency Network (ARPANET)--operational and
growing.
WWMCCS Intercomputer Network (WIN)--to be upgraded.
DOD Intelligence Information System (DODIIS)--to be upgraded.
Strategic Air Command Digital Information Network (SACDIN)--to be
upgraded.
Movement Information Network (MINET)--to be established in 1984.
Sensitive Compartmented Information (SCI) net--to be established in
1985.
TOP SECRET (TS) net--to be established in 1985.
SECRET net--to be established in 1986.
Initially, each of these networks has its own backbone. The networks
will be integrated into a common Defense Data Network in a series of
phases starting in 1984 with the integration of MILNET and MINET. It
is planned that by 1988 they will all be integrated but communities of
interest will operate at different security classifications
interconnected with Internet Private Line Interfaces (IPLIs). When
appropriate technology becomes available in the late 1980s, the network
will have the capability for multilevel security, including end-to-end
encryption, and will achieve interoperability between all users.
The following observations are relevant to the TCP and TP-4 issue:
The DOD currently has two major networks, MILNET and ARPANET,
currently comprising the DDN. About sixty subnets and hundreds of
hosts are internetted and most use TCP.
This year a European network, MINET, will be activated and integrated
into the DDN. It uses TCP.
In the second half of 1983, fifteen additional subscribers have been
added to MILNET and current planning estimates hundreds more
additional subscribers in 1984 and 1985.
For the many DDN users that are, or shortly will be, interconnected
over common backbones, there are groups of users that need
interoperability within the group. These groups are determined by the
military department they are part of as well as by functions such as
logistics, maintenance, training, and many others.
The Air Force and the Army are both committed to the use of TCP for
some of their networks or subnetworks (including Local Area
National Research Council [Page 32]
RFC942 February 1985
Report Transport on Protocols
Networks) and active acquisition programs are underway, or will be
initiated, during the next twelve to eighteen months.
The DDN Program Office has procured, or shortly will procure, devices
to facilitate terminal and host access to DDN hosts and terminals.
These devices employ TCP.
NATO has discussed protocol standards and has selected ISO as an
approach, subject to its being adapted to meet military requirements,
if such adaptation is necessary. There is no definitive planning
underway, however, to develop a NATO computer network.
The Mail Bridge that will allow traffic to pass between the classified
segment and the unclassified segment will use TCP and is scheduled for
a 1987 Initial Operational Capability (IOC).
In general, the backbone in the various networks provides functions at
layers below TCP and TP-4. As a result a backbone (such as MILNET)
could support users of either protocol set. The users of one set
could not, however, interoperate with the users of another unless
additional steps are taken.
In summary, there is a large TCP community operational today and the
community is growing rapidly. In addition, there are, or shortly will
be, procurements underway that plan to use TCP. The rate of growth
cannot be precisely estimated in part because of uncertainties in
demand and availability of trunks and cryptographic equipment. On the
other hand, interconnection of several major networks will not take
place until 1987 or later; and for those elements that are
interconnected, there are many groups of users that primarily require
interoperability with each other.
System Descriptions
MILNET is a network for handling the unclassified operational data of
the DOD. It was created after the decision in 1982 to cancel the
AUTODIN II system by dividing the ARPANET into two nets, MILNET and
ARPA Research Net. The majority of the capacity of ARPANET was
assigned to MILNET, and the number of subscribers is growing rapidly.
The network backbone does not require the use of TCP but its use is
generally mandated for subscribers. To achieve TCP functions, the DDN
will procure some interface devices and thereby take the burden off
some subscribers.
ARPANET supports most of the research organizations sponsored by
DARPA. It generally uses TCP but some users continue to use NCP.
MINET is a European network scheduled for Initial Operational
Capability (IOC) in 1984 to handle unclassified operational traffic,
mostly logistical, and tie into the MILNET. It will have 8 nodes, 8
TACs, and 3 hosts to process electronic mail. These hosts and others
to be added to the net will use TCP and the File Transfer Protocol
(FTP).
National Research Council [Page 33]
RFC942 February 1985
Report Transport on Protocols
The Department of Defense Intelligence Information System currently
uses a home-grown protocol. Sometime after 1984 its plans are to
upgrade it to TCP. It will be a 3-node, 3-host net with plans to
upgrade it to 20 to 30 nodes and about 50 hosts. The net is run at a
high-security level (SCI) for communicating compartmented data. The
SCI network consists of those users of SCI who are outside of DODIIS.
SACDIN is an upgrade of the digital communications system of the
Strategic Air Command. The IOC is planned for about 1985. At
present, TCP is not planned initially as a protocol. SACDIN will
operate with multilevel security up to Top Secret sensitive
information.
WIN is the WWMCCS Information Network. It is currently operational
and uses NCP as a transport protocol. There is a major effort underway
to modernize the WWMCCS, including upgrading or replacing current
computers, providing Local Area Networks at major centers throughout
the world, and providing common software packages for utilities and
some applications. The upgrading of the transport protocols is part of
this effort. Schedules are still uncertain but there is a target of
1986 for the protocol upgrading.
TOP SECRET is a network that will support top secret users other than
WIN and SACDIN.
SECRET net is a network that will operate at the Secret level. It
should be very useful for a large community that does not routinely
need top secret or compartmented information. This is a community
primarily outside the command and intelligence communities and
includes missions such as logistics, procurement, and research and
development. DOD will start the system as soon as there is sufficient
cryptographic equipment; by 1986 they hope to have a 90-node network
with several hundred subscribers.
The Army plans to establish a Headquarters Net tying together major
headquarters with an IOC of 1986. It will use TCP.
The Air Force has established a Program Office to help in the
development of Local Area Networks at major Air Force installations.
These could be internetted using the DDN and thereby also gain access
to other nodes. TCP has been mandated. Initial procurements are
underway.
Mail Bridge will provide gateways between ARPA Research Net and other
elements of the DDN. These would use TCP and are scheduled for IOC in
1987.
During 1984 the DDN is procuring two capabilities that will facilitate
use of the network and higher-level protocols.
The first capability will be provided shortly by Network Access
Controllers (NAC). The NACs provide three elements all based on TCP:
National Research Council [Page 34]
RFC942 February 1985
Report Transport on Protocols
1. Terminal Access Controllers (TACs) allow a cluster of terminals
to access hosts on the DDN. Many are in operation today as a
legacy of the ARPANET developments. New ones will be
competitively procured.
2. Terminal Emulation Processes (TEP) allow the connection of a
high-capacity host to the DDN through a number of terminal-like
lines.
3. Host Front-End Processors (HFP) allow high-capacity host
connection to the DDN through use of a Network Front End that
off loads much processing capacity from the host.
The second capability will be provided by software the DDN is
currently procuring for up to seventeen families of specific
combinations of hosts and their commercially available operating
systems. The software packages will include 1822 or X.25, TCP, and
utility protocols for terminal access, mail, and file transfer.
Initial operational capability is planned for late 1985.
Integration
MINET will be connected to MILNET in 1984. This will be an
unclassified network.
WIN, DODIIS, SECRET, and SACDIN will be integrated as a classified
network in 1987 at the earliest. Since they all operate at different
security levels, they will be able to use the same DDN backbone but
will be cryptologically isolated.
Integration and interoperability of all the networks will not be
possible until the late 1980s at the earliest, since this will require
successful implementation of an advanced technology for end-to-end
cryptological networking and the development of techniques for
multilevel security in individual and netted computer systems.
The use of gateways as elements to integrate networks is under
consideration. Gateways are currently operational to interconnect
MILNET with (l) ARPANET (six gateways primarily used to exchange mail
between authorized users), (2) MINET (one gateway for use prior to
integration of the two networks into one), and (3) eight
developmentally oriented networks. There are many more gateways
internetting ARPANET with other research nets. Most of these gateways
use the ARPA-developed Gateway-to-Gateway Protocol. It is now
realized that this protocol is deficient for widespread use and ARPA
has been investigating alternatives.
The earliest requirement for additional gateways in the operational
elements of the DDN will be to internet Local Area Networks into
global networks of the DDN. A new "stub" protocol has been developed
that might meet this need. The DDN is reviewing its requirements for
available gateways and approaches.
National Research Council [Page 35]
RFC942 February 1985
Report Transport on Protocols
INTERNATIONAL AND NATIONAL STANDARD MARKET DEMAND FOR TP-4
In the United States and most countries of the world, national
standards organizations adopt international data communication
standards.
In the United States the standards for the transport protocols are
established by the American National Standards Institute (ANSI). The
same standards for the federal sector are established by the NBS with
an exception for DOD's military needs which may be established by MIL
standards. Market demand for the latter was previously discussed.
Outside the DOD there are numerous government agencies and
organizations such as the Federal Aviation Agency, Internal Revenue
Service, the Federal Bureau of Investigation, and the Federal Reserve
Banks which have, or will have, networks that fall under the guidance
of the NBS and will probably use the NBS-specified standard protocols
when the NBS standard is issued. Already the Federal Reserve is
procuring its computer networking products using the X.25 protocol.
National Support of International Standards
The earliest evidence of demand for TP-4 products is in countries that
give strong support for ISO standards. Most countries outside of the
United States give the international standards much stronger
governmental support than the United States does for a variety of
reasons. First, in most cases these governments own the postal and
telecommunication monopolies. Frequently, the responsibility for
these organizations is at a ministerial level in the government.
Furthermore, many of the modern countries have concluded that the
information industry is a national resource and one of the growth
industries of the future. International standards that are neutral,
in the sense that no manufacturer has a head start, give the companies
in these countries the additional margin they feel is necessary to
compete in the worldwide market. It is also recognized by many that a
worldwide market is much better than a market demand fragmented by
national geographic and political considerations. Finally, the PTTs
have traditionally provided information services equivalent to those
for which some of the ISO computer communication protocols are
designed. The best example is Teletext, which is an upgraded version
of the Telex system used widely outside the United States.
Consequently, government networks in many countries use the
international ISO standards or the national standards derived from the
international standards. Bid requests for government networks in
France and Germany, for example, have required support for ISO
protocols for over a year even though the standards are not yet fully
approved. These bids ask the respondent only to state support for the
protocols. No doubt, as the ISO protocols become stable, these
countries will require the protocols for their networks. These
government networks will further influence the implementation of
networks not actually required to use the international and national
standards.
National Research Council [Page 36]
RFC942 February 1985
Report Transport on Protocols
MARKET SEGMENTS NOT REQUIRED TO USE TCP OR TP-4
Most of the demand for communication protocols comes from potential
customers who are under no government fiat to use either TCP or TP-4
protocols in their networks or network products. Many of these will
use existing supplier-specified protocols. Such protocols have been
embedded in products for over ten years and are well tested both
formally and through field experience in thousands of networks.
Continuing demand for these protocols will not contribute to the
relative demand for either TCP or TP-4.
There are widely recognized advantages in using international standard
protocols for computer communications. First, there is tremendous
value in exchanging information with other information users. As the
standard protocols become widely used, the value of the information
accessible through networks using these protocols is normally greater
than the value of information accessible through less widely used
networks protocols. This is the reason that industry groups such as
airlines, banks, and insurance companies band together to set up common
networks. Similarly, it is recognized that there are economies of
scale for widely used networking protocols both in the sense that
equipment can be obtained at lower cost and in the sense that the
manufacturer's improvements in performance, function, and cost will be
repaid by market demand. In addition, many network protocol users wish
to have the option to procure equipment from a wide variety of vendors.
Sometimes international standards encourage this environment. Finally,
international organizations would prefer to have common procurement of
equipment and software for worldwide operations. Thus international
standards are preferred for operational as well as logistic
considerations.
In the United States much of the demand for TP-4 will develop in the
industries that exchange information regularly with entities of the
federal government. If the Federal Reserve were to use the TP-4
standard for exchanging information with member banks, for example,
there would be pressure on the banks to use TP-4. Similarly, if DOD
suppliers wish to have easy access to DOD employees using a system
based on TCP, they would need to use TCP. Also many of the
university-oriented networks use the ARPANET protocols to exchange
information with other university ARPANET users.
The committee concludes that the demand for TP-4 in the United States
will significantly out weigh the demand for TCP independent of DOD's
adoption of TP-4. If DOD adopts the ISO TP-4 immediately or if DOD
adopts TP-4 after a demonstration, the U.S. market demand for TCP
protocols will disappear as the current networks are converted to TP-4.
If DOD chooses to use the DOD TCP indefinitely, clearly the DOD and
ARPANET demand for TCP will continue.
A similar set of market forces operates outside the United States
except that the foreign governments are more strongly in favor of
international and national standards and have smaller investments in
nonstandard equipment. Thus there are even more industries drawn to
National Research Council [Page 37]
RFC942 February 1985
Report Transport on Protocols
the standards in order to share information. This is illustrated by
the extremely strong support for ISO efforts. The European Computer
Manufacturers Association has been active in the TP-4 standardization
effort. NATO appears committed to TP-4 implementations, and there is
likely to be intense competition in this arena. Lacking the federal
government support of two different protocol suites, there is a
stronger force to adopt a single international standard in most
countries. There are other countries with a similar problem, however.
Germany is beginning to install systems based on its unique national
standard but has committed to convert eventually to ISO protocols.
The committee concludes that there will be little market demand for the
TCP protocols outside the United States. The strong international
demand will be for ISO protocols, including TP-4.
National Research Council [Page 38]
RFC942 February 1985
Report Transport on Protocols
VI. DEVELOPMENT OF STANDARD COMMERCIAL VERSUS SPECIAL COMMERCIAL
PRODUCTS
DOD has expressed a desire to use off-the-shelf commercial products
because they are expected to be less costly. It is expected that
performance of commercial products will be optimized to increase
competitiveness. User cost will be lower because of a large commercial
customer base over which to amortize costs for development, continuous
improvements, and maintenance. Furthermore, the DOD may benefit from
having more vendors compete for their business. This section examines
the way vendors select standard products for development and the
implications in cost, continuing supports, and improvements.
PRODUCT DEVELOPMENT VERSUS SYSTEM INTEGRATION
It is assumed in this discussion that off-the-shelf commercial products
can be used through system integration to construct system solutions.
Most vendors supply both standard products and system integration
services. Some vendors supply only the integration functions, using
other vendors' products. System integration adds value to the product
and in some cases results in modifications of the product to meet
system requirements. When standard products are used, the
responsibility for continuing maintenance and improvements almost
always can be passed to the product developer. Thus in this discussion
we assume that off-the-shelf commercial products are standard products
supplied by vendors to implement one or more transport-level protocols
for the DOD.
CRITERIA FOR SELECTION OF STANDARD PRODUCTS
The product vendor's choice to develop a standard product is governed
by market requirements, economic opportunities, and other design
considerations. In the case of data transmission products, market
requirements include competition, connection to the installed base of
products, market growth, and satisfaction of the standards requirements
of customers.
Often the vendor will develop a product that supports several protocols
as options. Usually only one or two protocols will be selected for
primary support, and all other options are considered for secondary
support. The primary protocols selected for implementation are based
upon the largest potential market for the vendor. These protocols
become the vendor's standard products. Standard products are announced
for sale and supported on a continuing basis. Implementations of
secondary protocols are often adaptations of the implementations of
standard protocols and may be suboptimal with respect to performance
and continuing vendor support. Often secondary implementations are
created when an RFP is issued and the vendor who wishes to respond to
the RFP must create a special product to do so. This committee
believes that, in general, future standard data transmission products
will be either TP-4 or vendor-unique protocols and TCP will be a
special product.
National Research Council [Page 39]
RFC942 February 1985
Report Transport on Protocols
STANDARD VERSUS SPECIAL PRODUCT
Within the OSI architectural model, seven layers are defined, each of
which will have protocols defined for interconnection of systems.
These protocols are controlled by standards. TP-4 is an example of a
protocol for the transport layer. These protocols will be implemented
on many vendor systems that have different systems architecture,
different operating system architectures, and, therefore, differences
in the specifics of the layer interface. The vendor systems will be
designed to optimize the specific environments that each vendor has
determined are most important to satisfy the major market objective for
that vendor's particular computer architectures. This determines the
vendor's standard system and architecture. Support of special
requirements will frequently be designed as modifications to a standard
system, using translators and other techniques to bridge the
differences in layer interface definitions, operating systems
structure, and protocols. Most support activity, optimization of
performance and resource usage will be directed at the standard system
architecture selected by the supplier.
Special-Product Process
Special-product development is initiated to meet customer
specifications. The specifications, schedule, and cost assume that
special products are released using an existing version of the
software system (operating system, language, communications, and data
manager). Support for the special product is conditioned on a support
contract. The special product is tested and released with that
system. This provides the fastest availability of the product, since
the schedule will only include the time to develop the product and
test it with the selected system. It is likely that by the time a
product and its software system are delivered, a newer version of the
software system containing code corrections and added functions and
other new products will have been released. Additional cost to the
customer is required if the vendor is to modify the special product to
operate on this new version of software. This occurs frequently in a
rapidly developing technology. If the special product is not
modified, operational and maintenance expenses may increase.
Standard-Product Process
A standard product is developed to meet the market requirements of a
market area. The development of a standard product generally has a
target date that is used as a basis for scheduling system development,