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,
fabrication, and testing into a planned software system release. The
product then is included in the test and integration plan for the
system release and integration into a systems test procedure to assure
operation with the other parts of the software system. The standard
product then becomes a part of the software system, and as new
releases of the system are made, the product is tested as a part of
the integrated system to assure that it still operates with the
revised, new system. The product may also be enhanced to satisfy new
requirements or resolve problems of the earlier version. The product
then will operate with the latest software system release.
The integration process complicates the development process. The
increased complexity may result in a longer development schedule or
may require more resources than special products require since (1) the
cycle may involve a longer product requirement definition, (2)
additional planning and integration testing may be needed to
coordinate the product design with other system activities, and (3)
there is the possibility of up to twelve months' delay in scheduling a
software system release, which for most vendors generally occurs at 6-
to 12 month intervals. The product may be maintained with a
corrective code released in intermediate system fabrication and
integrated into the following software release. Different categories
of support may be available and these categories may vary by product.
The support categories may range from no support to full unlimited
warranty.
CONCLUSION
The committee concludes that there are significant benefits for the
Department of Defense in using standard commercial products that meet
the department's operational needs:
Costs to the DOD for development, production, and maintenance are
significantly lower because (l) vendors spread the cost over a much
larger user base, (2) commercial vendors have to be efficient in their
operations in view of the competition in the market, and (3) vendors
look for ways to upgrade their product to meet competition.
The department may get additional useful products because vendors
integrate the protocol function into their corporate software and
hardware product lines. Thus the DOD may be able eventually to use
standard commercial software application products that are built on
top of, and thereby take advantage of, the transport protocols. The
DOD will thereby have a wider selection of standard commercial
application products to choose from. By depending on industry to
manage the development, maintenance, and upgrade of products, the DOD
can use its scarce management and technical resources on activities
unique to its mission.
VII. RESPONSIVENESS OF INTERNATIONAL STANDARDS PROCESS TO CHANGE
The international standards process has proven its ability to respond
quickly to new requirements and protocol problems uncovered during
standardization. The United States, through organizations such as the
NBS, the ANSI, and IEEE has a leadership role in this process. The
committee concludes that the process can be responsive to DOD's needs.
The DOD will benefit from active participation in the international
protocol standardization efforts. This will ensure that the DOD's
evolving computer communications needs will be met in future commercial
products. Also the DOD will have access to a broad spectrum of protocol
experts and have access to those developing future commercial products.
These benefits will far out weigh the costs of participation.
There will probably be very few high-priority instances where DOD will
require immediate changes to its operational commercial software. These
may relate to security or survivability. In order to accommodate these
changes in the short run, the DOD will need agreements with its
commercial suppliers for quick fixes to be made while the standard is
being changed.
VIII. OPTIONS FOR DOD AND NBS
The committee believes that the Department of Defense is committed to
adopting commercial standards when they are suitable and available and,
therefore, will adopt the ISO standards eventually as the military
standard for transport-level communication protocol. Further, the DOD
realizes the benefits in cost and reliability of obtaining its data
communications equipment from vendors who offer it as standard products.
Of the three options identified by the committee, the first two are ways
for the DOD to realize these benefits while the third option would
withhold the benefits from the DOD indefinitely.
The primary difference between Option l and Option 2 is in the timing of
the transition from TCP to TP-4. This timing difference has
implications in risk, cost, and manageability of the transition. (This
is discussed in Chapter X in greater detail.)
Option 1
The first option is for the DOD to immediately modify its current
transport policy statement to specify TP-4 as a costandard along with
TCP. In addition, the DOD would develop a military specification for
TP-4 that would also cover DOD requirements for discretionary options
allowed under the NBS protocol specifications. Requests for proposals
(RFPs) for new networks or major upgrades of existing networks would
specify TP-4 as the preferred protocol. Contracts for TP-4 systems
would be awarded only to contractors providing commercial products,
except for unique cases.
Existing networks that use TCP and new networks firmly committed to the
use of TCP-based systems could continue to acquire implementations of
TCP. The DOD should carefully review each case, however, to see
whether it would be advantageous to delay or modify some of these
acquisitions in order to use commercial TP-4 products. For each
community of users it should be decided when it is operationally or
economically most advantageous to replace its current or planned
systems in order to conform to ISO standards without excessively
compromising continued operations.
United States government test facilities would be developed to enable
validation of TP-4 products. The Department of Defense would either
require that products be validated using these test facilities or be
certified by the vendor. The test facilities could also be used to
isolate multivendor protocol compatibility problems. The existing NBS
validation tools should be used as the base for the DOD test
facilities.
Because under this option networks based on both TCP and TP-4 would
coexist for some time, several capabilities that facilitate
interoperability among networks would need to be developed. The
Department of Defense generally will not find them commercially
available. Examples are gateways among networks or specialized hosts
that provide services such as electronic mail. The department would
need to initiate or modify development programs to provide these
capabilities, and a test and demonstration network would be required.
Option 2
Under Option 2 the Department of Defense would immediately announce its
intention to adopt TP-4 as a transport protocol costandard with TCP
after a satisfactory demonstration of its suitability for use in
military networks. A final commitment would be deferred until the
demonstration has been evaluated and TP-4 is commercially available.
The demonstration should take at most eighteen months and should
involve development of TP-4 implementations and their installation.
This option differs from Option 1 primarily in postponing the adoption
of a TP-4 standard and, consequently, the issuance of RFPs based on
TP-4 until successful completion of a demonstration. The department
should, however, proceed with those provisions of Option 1 that may be
completed in parallel with the demonstration. Early issuance of a TP-4
military specification, development of validation procedures, and
implementation of means for interoperability would be particularly
important in this regard.
Option 3
Under the third option the DOD would continue using TCP as the accepted
transport standard and defer any decision on the use of TP-4
indefinitely. The department would be expected to stay well informed of
the development and use of the new protocol in the commercial and
international arena and, with the National Bureau of Standards, work on
means to transfer data between the two protocol systems. Testing and
evaluation of TP-4 standards by NBS would continue. The DOD might
eventually accommodate both protocol systems in an evolutionary
conversion to TP-4.
IX. COST COMPARISON OF OPTIONS
There are so many variables affecting cost, it is impossible to compare
precisely the cost for each option over time. The estimates in this
section are, therefore, mostly qualitative. They are based on the wide
experience of several committee members in commercial networking (14).
Cost comparisons among the three options are difficult for two reasons:
1. There are an unlimited number of scenarios that can be considered
for the growth of DOD's data communication networks in the next fifteen
to twenty years, involving questions such as (a) How many different
implementations will there be? (b) What economies of scale can be
achieved? (c) How much software will be shared between different
implementations? (d) How much will the standards change for greater
effectiveness or to accommodate higher-layer standards? and (e) What
will happen to manpower costs in this high-skill area?
2. It is difficult to isolate the costs attributable to developing,
implementing, and maintaining the protocols at issue. This is
especially true if we assume DOD continues to use its own unique
protocols. For both in-house and contractor efforts, the costs
associated with TCP are folded into many other efforts. If DOD moves to
commercial protocols, the marginal costs may be more visible.
-----
(14) The committee has had some access to a study recently conducted by
the Defense Communication Agency that compares the costs of commercially
maintained versus government-maintained operating systems for the
Honeywell computers used in WWMCCS. Although the WWMCCS example has
many fewer dimensions and systems than are covered by this analysis, the
committee urges the DOD to review this study as a good example of
potential savings from commercially vended software. (WWMCCS-ADP System
Software Economic Analysis. J. Stephens and others, Joint Data Systems
Support Center, Defense Communications Agency, Technical Report, in
draft.)
A major motivation expressed by the DOD for using commercial protocols
is that the commercial protocols are significantly cheaper. If this is
the case, then many in the DOD would like to know the savings over the
next ten to twenty years if DOD adopts TP-4. This is not a question we
will try to answer in this report, but the concept of opportunity costs
is significant. If DOD can successfully move to commercial standards,
then it will eventually be able to use DOD's scarce management and
technical resources to strengthen its efforts in other areas of
information communications and processing that are more unique to the
DOD. Given the finite pool of such resources available to the DOD, the
value of this transfer may be significantly greater than the dollars
saved by adopting the international standards.
The following assumptions have been used in trying to estimate the cost
factors if DOD moves toward adopting TP-4 using either Option 1 or 2:
No major subsystem of the DDN (which includes MILNET, DODIIS, WWMCCS,
and so forth) would use both protocols at the same time except possibly
for a brief transition period.
In only a few selected cases would a capability be required to handle
both protocols. These cases could include select hosts that use both,
special servers (most likely mail servers) that could provide functions
between several communities of interest using both protocols, or
translating gateways between networks.
Within the DDN both sets of protocols would be used for a period of
five to ten years starting eighteen months after the DOD approves the
use of TP-4 in a new system.
In virtually all cases, the phase-over from TCP to TP-4 in a subsystem
of the DDN would be performed at a time when there is a major upgrade
of subsystem elements that include TCP as a part. In other words, the
transition is not merely a substitution of transport or internet
software except in cases where the hardware currently being used is
from a vendor who has started to offer TP-4 as a commercial product.
Where this is not the case, the transition includes the substitution of
new hardware whose vendor provides TP-4 commercially.
COST FACTORS AND MODEL
Four major factors must be considered in evaluating the costs of the
three options:
1. How much lower will be the cost of commercial, standard-product
protocols compared to those developed and acquired by the DOD?
2. If DOD decides to adopt TP-4, how quickly can it start using it
in new systems, and how quickly will it phase TCP out of older
systems?
3. What will be the one-time cost of management and test before DOD
is prepared to start using TP-4?
4. What will be the marginal costs of maintaining the two standards
over the 5- to 10-year transition period?
Savings Using Commercial Software
Commercial software providing TP-4 will tend to be cheaper than DOD
provided TCP because commercial one-time and recurring costs
(especially the former) can be apportioned over a larger consumer
base, and the commercial supplier will tend to be more efficient. As
in most cases where one compares the cost of one product provided by
two vendors, there will be situations where a DOD vendor providing TCP
can do it more cheaply than a commercial vendor providing TP-4. These
occurrences will be rare but they illustrate the difficulty of
developing detailed quantitative models that compare the costs.
Factors relating to competing suppliers go far beyond the transport
protocols themselves and distort such models.
The first argument relating to the size of the consumer base has many
factors. For the time period under consideration, DOD represents
about 3 percent of the commercial U.S. computer base. It would follow
that DOD should pay much less in development and support costs for the
commercial products. But there are other factors. The number of
commercial suppliers is larger than the number of DOD suppliers by a
factor of 5-10. The DOD's need for transport and internet protocols
will be greater than the average commercial user in the time period
under consideration. If commercial vendors break out the costs of
developing these protocol features earlier than planned, DOD will pick
up a larger share of the tab. This could be by a factor of 2 or more.
A good deal of the one-time development and production costs of TCP
have already been spent by the DOD or partly written off by DOD
vendors. This factor would be extremely difficult to estimate, but we
do not think it is very significant since the major costs in
implementation relate to processes down-the-line from getting a
C-language version. These down-the-line processes must be repeated in
great part as families of hardware and software are upgraded with
system and technology improvements to meet DOD directives for standard
TCP products. There are also factors that cut in the other direction;
if the DOD is only 3 percent of the U.S. commercial user market, it is
an even smaller fraction of the international user market. This
latter market is growing; its need for ISO protocols will be
relatively higher than the U.S. market, and market share for U.S.
manufacturers, including foreign subsidiaries, is large and holding
its own.
The situation is equally complex when it comes to comparing the
efficiency of commercial vendors with DOD vendors when it relates to
developing, installing, and maintaining transport and internet
protocols. The elements that favor increased efficiency of the
commercial supplier include the following:
The commercial marketplace is much larger, less regulated, and is
forced, therefore, to seek greater efficiency and innovation.
Transport and internet protocols represent functions that interact
very closely with operating systems, the largest portion of which are
commercial. The major sources of expertise for dealing with these
operating systems are in the commercial marketplace, primarily with
the vendors who supply the hardware as well as with vendors who
specialize in related products.
The commercial sector is in the business of managing the interplay
between operating systems, protocols, related software and hardware
products, new technology and architecture, and the relationship
between all these and the market. If DOD adopts TP-4, it will be
delegating many of these management functions to a marketplace that
will generally make better and faster decisions.
For every dollar that the DOD might invest in TCP, how much would it
cost to gain comparable capability with TP-4 procured as vendor
standard products? The many factors involved make a precise estimate
impossible. We believe, however, that TP-4 can be procured at
substantial savings and with virtually no economic risk if the market
develops as we believe it will, with many vendors offering it as a
commercial product by mid-1986. On the average, we judge the savings
to be 30 to 80 percent including initial installation, field support,
and maintenance.
How Soon Will TP-4 Be Used?
The sooner that DOD decides to use TP-4, the greater will be DOD's
savings. These savings can offset the adverse cost factors discussed
in the next two sections: the cost to decide to use TP-4 and the
added cost for the period when two standards (TCP and TP-4) are in
use.
Currently, TCP is generally used in MILNET, MINET, and ARPANET. As
previously stated in the assumptions, even if DOD decides to move
aggressively toward TP-4, there are no evident, strong economic or
operational reasons for converting these users to the new standards
until a major upgrade of the users' communications and processing
subsystems is planned. Also in the next twelve to eighteen months new
uses of these nets are planned that will expand existing subnets and
these new users would use TCP in order to be interoperable with the
current users in their community of interest.
In some cases the planning for new subnets for new communities of
users is well along. DODIIS is a primary example. Some of these
subnets should very likely proceed with TCP, but others appear to be
prime targets for TP-4 if DOD is to move in the direction of adopting
TP-4. The WWMCCS and its WIN are probably good examples of the latter.
Planning and implementation for all of these subsystems must move
ahead, however, and if DOD does not make a firm commitment to TP-4 by
mid-1985, the number of systems that will move ahead with TCP will
probably constitute almost half of the growth of the DDN in the next
five years. In other words, delay of a decision to move to TP-4 until
1986 would mean that most of the DDN subnets that will exist in the
late 1980s will be based on TCP, whereas a decision for TP-4 a year
earlier could significantly reduce this number.
Cost of Decision to Use TP-4
The costs of the decision to use TP-4 include the one-time management
and test costs that DOD decides are needed before a TP-4 commitment
and policy can be approved. Under Option 1 these costs are small.
Under Option 2 they are significantly higher, although the amount will
depend on the extent and duration of the testing needed. Under Option
3 there will be no management and test costs.
Marginal Costs of Maintaining Two Standards
If DOD moves toward the gradual introduction of TP-4, both standards
will have to be maintained for five to ten years. The additional
costs of maintaining two standards include the following:
Management costs of dealing with two standards.
Costs for developing and maintaining capabilities for limited
intercommunication between systems using the different transport and
internet protocols. These include costs for gateways,
dual-capability hosts, and special servers such as mail.
Parallel validation capability. The DOD is implementing a validation
capability for DOD TCP. This is similar to the currently operational
NBS facility for TP-4 testing. If DOD selects Option 1, there is a
question whether this DOD facility should be completed for TCP
(because the number of new implementations of TCP would be small
several years from now). If DOD selects Option 2, the facility is
probably desirable.
Costs for maintaining research and development (R&D) programs to
improve the standards. A part of the DARPA and DCA research and
development programs in information technology is directed at system
issues related to TCP. This includes work on internet issues,
gateways, and higher-level protocols. The committee has not reviewed
the research program for details and cost; however, a commitment to
move toward ISO standards should affect the program. Costs would
increase to the extent that the program would be involved with
interactions with both protocols. There would be some decreased
requirements for R&D in light of potential dependence on commercial
R&D to improve the standards. In the next several years, however,
the committee concludes that dual standards would, on balance,
somewhat increase R&D costs because of the DOD's unique operational
requirements.
These costs are roughly the same for Options 1 and 2 and depend on how
DOD manages the transition. Under an austere transition, which does
not provide extensive interoperability between TP-4 and TCP-based
systems and minimizes costs in other areas, the overall costs could be
low in comparison with potential savings.
Evaluation of Options by Cost
In terms of the previously discussed factors, savings can develop in
two ways: by using TP-4 instead of TCP in new systems and by
replacement of TCP with TP-4 in existing systems when this can be done
smoothly and efficiently. The earlier that TP-4 is introduced, the
greater these savings.
In contrast costs will be incurred in two ways: in one-time planning
to use TP-4 and in continuing costs of operating two standards.
The following is a summary of the cost evaluation of the three options
in the near term:
Option 3 is least expensive. It achieves no commercial savings but
has no costs for one-time planning and maintenance of dual standards.
Option 1 is at most only slightly more expensive than Option 3 since
one-time planning costs (which are much lower than for Option 2) and
maintenance costs can be significantly offset with commercial savings
in the following several years.
Option 2 is most expensive since it does not realize significant
offsetting commercial savings.
In the longer term (beyond the next several years) commercial savings
for Options 1 and 2 should overtake costs of transition, and both
these options should cost the same.
There is a concern on the part of some members of the committee
whether the higher near-term costs of Option 2 are adequately offset
by the Option's long-term savings to warrant the transition.
X. EVALUATION OF OPTIONS
We present a summary of the strengths and weaknesses of each option,
followed by a detailed evaluation for each set of criteria.
SUMMARY
Option 1's primary benefit is that it would allow the DOD to obtain the
benefits of standard commercial products in the communication protocol
area at an early date. These benefits include smaller development,
procurement, and support costs; more timely updates; and a wider
product availability. By immediately committing to TP-4 as a
costandard for new systems, Option 1 minimizes the number of systems
that have to be converted eventually from TCP. The ability to manage
the transition is better than with Option 2 since the number of systems
changed would be smaller and the time duration of mixed TCP and TP-4,
operation would be shorter. Interoperability with external systems
(NATO, government, and commercial), which presumably will use TP-4,
would also be brought about more quickly. Option 1 involves greater
risk, however, since it commits to a new approach without a
demonstration of its viability.
As with Option 1, a primary benefit of following Option 2 would be
obtaining the use of standard commercial products. Unit procurement
costs probably would be lower than with Option 1 since the commercial
market for TP-4 will have expanded somewhat by the time DOD would begin
to buy TP-4 products. Risk is smaller compared to Option 1 since
testing and demonstration of the suitability for military use will have
preceded the commitment to the ISO protocols. Transition and support
costs would be higher than for Option 1, however, because more networks
and systems would already have been implemented with TCP. Also this is
perhaps the most difficult option to manage since the largest number of
system conversions and the longest interval of mixed TCP and TP-4
operations would occur. In addition, interoperability with external
networks through standardization would be delayed.
The principal benefit of exercising Option 3 would be the elimination
of transition cost and the risk of faulty system behavior and/or delay.
It would allow the most rapid achievement of full internal
interoperability among DOD systems. Manageability should be good,
since only one set of protocols would be in use (one with which the DOD
already has much experience) and the DOD would be in complete control
of system evolution. Procurement costs for TCP systems would remain
high compared to standard ISO protocol products, however, and
availability of implementations for new systems and releases would
remain limited. External interoperability with non-DOD systems would
be limited and inefficient.
In summary, Option 1 provides the most rapid path toward the use of
commercial products and interoperability with external systems. Option
2 reduces the risk but involves somewhat greater delay and expense.
Option 3 provides a quicker route to interoperability within the
Defense Department and at the least risk, but at a higher life-cycle
cost and incompatibility with NATO and other external systems.
DEFENSE DEPARTMENT OBJECTIVES VERSUS OPTIONS
The committee has identified a set of DOD objectives for transport
protocols, discussed in Section II of this report. In this section we
discuss the potential of each of the three options for achieving those
objectives. The objectives have been grouped into five major
categories that serve as criteria for evaluation of options.
Functional and Performance Objectives
There are certain functional and performance objectives that standard
DOD transport protocols must satisfy. Key objectives include security
capabilities, the ability to establish message precedence in crisis
situations, and survivability of continuing operations when failures
occur and portions of the network become inoperable. This implies
continuous availability of the primary data transmission network and
the ability to reconfigure the networks to operate after some of its
nodes are lost.
As previously stated, the two protocols are functionally equivalent.
TCP and TP-4 have equivalent reliability characteristics and are able
to detect and recover from failures. The committee also concludes
that robustness, availability, and performance in crises are
equivalent using either protocol. The committee concludes that all
three options equally satisfy the functional objectives that DOD
requires.
Since the performance characteristics of TCP versus TP-4 will be a
function primarily of the particular implementations, the committee
concludes that the two protocols are sufficiently alike that there are
no significant differences in performance of a TCP or a TP-4
implementation of equal quality when each is optimized for a given
environment.
If Option 1 is selected, early implementations may result in
suboptimal performance. Option 2 specifies that there be a
demonstration network established that will provide time for
adjustment, testing, and gaining experience. Option 3 would result in
no reduction in performance of current networks. The maturity of TCP
has resulted in many implementations that have demonstrated good
performance. This experience provides a knowledge base for future
implementations of either TCP or TP-4. In either case, however,
initial implementations of TCP or TP-4 may be suboptimal and require
additional development to optimize performance.
Maximizing Interoperability
A high-priority DOD objective is interoperability among its internal
networks and among internal networks and non-DOD, external networks,
including NATO. Interoperability allows users of a network to have
access to applications on the same or other networks.
Option 3 would allow the DOD to increase internal interoperability
most rapidly by continuing to mandate use of TCP for all new systems.
Interoperability with external systems, however, the vast majority of
which are expected to use ISO standard protocols, will remain limited.
The more quickly DOD moves to use TP-4, the more rapidly external
interoperability will improve. In the short run internal
interoperability will be reduced due to the existence of both TCP and
TP-4 protocols by different subnets. This problem is greater with
Option 2 then Option 1 since the number of systems and the length of
time both protocols are in use is greater. In both options the
problem can be reduced by providing special servers and translating
gateways to provide limited interoperability where needed among
subnets using different protocols.
Minimizing Procurement, Development, and Support Costs
A DOD goal is to assure availability of commercial-grade transport
systems from vendors and minimize development, procurement, and
continuing support costs. Both Option 1 and, after demonstration,
Option 2 result in DOD adopting the TP-4 standard that has the
endorsement of both national (ANSI) and international (ISO) standards
organizations. Further, this protocol has been endorsed for use by
NATO, the European Computer Manufacturer's Association, the Computer
and Business Equipment Manufacturer's Association (CBEMA), and the NBS
Institute of Computer Sciences and Technology for the information
processing community of the federal government.
The result of the endorsements will be widespread use of the standard
protocol in worldwide networks and a large number of vendors supplying
commercial grade products supporting TP-4. As previously noted, many
vendors have already stated they plan to develop TP-4-based products
and many are already doing this in-house. Thus a large market and
large vendor base will assure the availability of commercial grade
TP-4 products.
A large market and supply of commercial-grade products will give DOD a
large competitive base from which to select its data transmission
systems. The effect will be to reduce DOD acquisition cost because
large markets allow vendors to amortize development and support cost
over a large base. This favors adoption of either of the options that
results in DOD using TP-4 as its standard.
With the availability of commercial-grade products, vendors will take
the responsibility for continuing maintenance and enhancements of the
product. Transmission products are tightly coupled to the operating
systems on the host computer systems in which they operate. With
vendor support of the products, evolution of both the host computer
operating system and transmission system will occur in
synchronization. This again favors the adoption by DOD of either the
Option 1 or Option 2 that results in TP-4. In these options much of
the support cost is covered by the vendors and spread over the large
market base. This reduces the development and maintenance cost passed
on to the DOD.
The committee does not believe that a large market beyond the DOD will
develop for TCP because worldwide markets for products will be based
on the ISO standards. Consequently, if the DOD chooses Option 3, only
the DOD-dedicated vendors would supply TCP as standard products
resulting in a smaller market and supply for TCP products and limited
availability of TCP products.
If DOD remains with TCP, many commercial vendors will be forced to
develop and support both the commercial standard products (TP-4) and
DOD standard special products (TCP) to stay in both markets. In many
cases only the large market-based products such as TP-4 will be
considered standard and TCP products will be considered special
products. The effect is higher development and support cost to the
vendors which would be passed on to DOD. Thus the incentive for
continuing enhancement to the special product, TCP, would be reduced.
This responsibility would be passed to DOD, also resulting in higher
costs.
Ease of Transition
The DOD is concerned with the ease and risk associated with transition
from the current network architecture using TCP to its future network
architecture. The objectives for DOD are to reduce the interruption
of data communication services supplied by its active networks;
minimize the risk of using an immature, untried protocol; and maximize
the use of the critical skills, knowledge, and experience of the
engineers who develop the communications products.
The maturity of TCP and the momentum that exists in the DOD community
for implementing future systems using TCP would favor Option 3.
Selection of Option 3 would minimize interruption of service and
minimize risk. With this option there would be no transition; the DOD
would remain with its current policy. There would be no conversion
costs and the only risks for DOD would be associated with poor
implementations of new TCP-based products.
The committee believes that much of the technical risk is associated
with implementations. Therefore, given the relative state of their
specifications and implementations as discussed earlier, the committee
feels that the risks are comparable for implementing new products for
either TCP or TP-4. Since DOD is acquiring many new networks the
implementation risk of either TCP or TP-4 will be equal.
If DOD chooses Option 1, it will display confidence in the TP-4
specifications and in the vendor's implementations through its
immediate commitment for TP-4 use in new military networks. DOD will,
in effect, be making a commitment similar to that of vendors who are
planning this protocol for their standard products. Since most new
networks would not use a transport protocol other than TP-4, this
minimizes the number of networks and therefore the cost of converting
and maintaining TCP networks to TP-4.
Since the standard TP-4 products from vendors are not available today,
DOD endorsement of TP-4 may have the effect of accelerating vendor
development of standard products. These products are expected to be
generally available by 1986. Thus Option 1 can be consistent with the
manufacturers' expected product plans. Option 1 provides, therefore,
the least conversion cost but with higher risk for DOD conversion.
If DOD chooses Option 2, then the risk that TP-4 will not meet DOD
needs is reduced since there is no commitment to use this protocol
until a successful demonstration is completed. In the interim, many
networks will have been committed using TCP, resulting in higher
conversion costs than with Option 1. In summary, Option 2 provides a
lower risk approach for DOD to convert to TP-4, but will encounter the
higher conversion cost.
There is a great deal of experience with TCP and thus there is an
engineering community that is highly knowledgeable about it. As
previously noted, however, if DOD remains with TCP, some DOD vendors
will be forced to support multiple protocol products. The functional
equivalence and similarities between TCP and TP-4 permit an easy
transition for the experienced engineer to move from TCP to TP-4.
Option 2 allows more time for this transition to occur, and thereby
minimizes the risk associated with a complete switch to TP-4.
In addition to the transport protocols, a transition from TCP to TP-4
also involves the conversion of applications. The committee has
concluded that the services provided by TCP and TP-4 are comparable
and applications software can be moved from TCP to TP-4 without loss
of functionality. Obviously, Option 3 requires no conversion to
existing applications on current implementations. Option 2 will
result in more applications interfacing to TCP than Option 1, thus
potentially increasing conversion costs. In the future DOD could
minimize the cost of conversion by standardizing the services provided
by the transport layer to the applications.
Manageability and Responsiveness to DOD Requirements
The final set of objectives is concerned with the degree of difficulty
that DOD will experience in managing its installed networks and future
networks. As communications requirements evolve, DOD must have the
ability to alter specifications so they will satisfy new requirements.
Finally, DOD requires facilities for validation of protocol
implementations as they are added to their networks.
Since Option 3 is to maintain the status quo, no additional management
difficulty is anticipated.
Both Option 1 and Option 2 will cause some additional management
difficulties since they require that the current momentum for adopting
TCP to be redirected toward TP-4 without loss of intensity. In
addition to this change, DOD must manage both TCP and TP-4 networks.
This will add to its management difficulties.
Option 2 will result in greater management difficulties than Option l
due to the larger number of TCP systems that must eventually be
converted and the larger time period over which both protocols must be
supported.
There are benefits from each option. If Option 3 is selected, DOD and
its vendors have sole responsibility for determining what changes are
needed, implementing the change, validating the change and the ongoing
maintenance of the standard. If either Option 1 or Option 2 is
chosen, then DOD may encounter difficulty in persuading the standards
groups to adopt its proposals; however, DOD would gain the experience
and knowledge of the industry standards-making bodies. The industry
standards bodies should be receptive to good technical arguments for
correction of errors or apparent major deficiencies in the protocol.
The standards bodies that maintain the standard should become a
technical resource for DOD to develop its military specifications.
Since TP-4 will be a commercial standard, those vendors who adhere to
the standard will insure that validation facilities are in place. The
National Bureau of Standards has a test facility for TP-4. No such
facility exists for TCP. If Option 1 or Option 2 is chosen, DOD can
use this facility to validate vendor implementations. DOD should work
with NBS to develop a similar facility for TCP. This is particularly
important for new implementations of TCP. DOD should continue working
with and through NBS in getting needed protocol revisions introduced
into the appropriate standards bodies.
In summary, Option 3 results in no new management difficulties while
Option 2 causes the greatest difficulties. Option 1 allows DOD to
move toward commercialized standard products with the smallest
addition of management tasks.
EFFECT OF PROPOSED OPTIONS ON MARKET SHARE
Option 1 would quickly reduce the market held by TCP products as TP-4
products begin to take hold in the marketplace. In addition, it would
enhance the ability of U.S. manufacturers to compete in the world
networks market based on ISO standards because they would not have to
engage in parallel development nor support two sets of protocols for
very long. Option 2 could have a comparable but less pronounced effect
in the marketplace and it would be delayed. Because of the very
probable rapid deployment of TCP-based systems in DOD networks while
the TP-4 is still in the demonstration phase, however, many more
networks than in Option 1 would probably end up using TCP. This would
tend to reduce the U.S. manufacturer's competitive edge in the world
market because their need to develop and maintain both TCP products as
well as TP-4 products would dilute their skill resources. The same
thing would happen with Option 3. Although none of the options would
affect the world market for TP-4 greatly, Option 3 would result in a
residual market for TCP products in the DOD and related networks.
Products made specifically for this market would continue to exist, but
with functions limited to this specific market, the products would lack
some of the advantages of large-scale production and product
development.
XI. RECOMMENDATIONS
We first present our basic recommendation and then provide detailed
recommendations on aspects that require amplification. These are
followed by additional considerations in several important areas
relating to the transition plans. Many of our recommendations are
closely related to each other, and care should be taken not to consider
any single recommendation in isolation.
BASIC RECOMMENDATION
The committee unanimously recommends that DOD should adopt the ISO TP-4
(and IP) as DOD costandards with its TCP (and IP) and move toward
eventual exclusive use of TP-4. Transition to use of the ISO
standards, however, must be managed to maintain operational
capabilities and minimize risks. The timing of the transition to use
of these protocols is, therefore, a major concern, and the committee
was divided on the best schedule to recommend.
A majority of the committee favored immediate adoption of the ISO
protocols as costandards with TCP, giving major procurements in 1984-85
the option of using these standards (Option 1). A minority favored
deferring adoption of the ISO protocols by the DOD until after a
demonstration of commercial quality implementations supporting military
applications (Option 2). This difference is reflected in detailed
recommendations 2-4 below. The reasons for the two viewpoints are
based on differences within the committee on the extent of the risk
associated with adopting a protocol, TP-4, that has not been
implemented on operational networks.
DETAILED RECOMMENDATIONS
In the following recommendations the committee provides details about
actions that should be taken to implement the basic recommendations.
Most of the recommendations involve actions that require the DOD to
take the lead role, with occasional support from the NBS Institute for
Computer Sciences and Technology. Some recommendations are directed
more toward NBS. Other government agencies and parties interested in
using DOD protocols or in their future evolution may also find these
recommendations applicable.
(1). DOD should rapidly identify "open areas" of the ISO TP-4
specifications where various options for implementation are allowed and
define a required subset for use in DOD systems (a MIL-SPEC version of
the standards, for example). In doing this, the DOD should work with
the NBS with the goal of developing a Federal Standard, that has
relatively few options for implementation, facilitates maximum federal
interoperability, and makes it clear to vendors which functions are
required in their commercial products.
(2). DOD should aggressively develop and implement a plan for
integration of TP-4 as a costandard with TCP and for migration toward
its eventual exclusive use. The plan should include provision for
rapid completion of a MIL-SPEC (detailed recommendation 1), either
validation or demonstration facilities (detailed recommendation 3),
timing for procurement of systems with the new protocols (detailed
recommendation 4), development of equipment and procedures to support a
period of joint operation with both TCP and TP-4 protocols in use, and
guidelines for eventual conversion of TCP systems to the new protocols.
Whatever timing is chosen for the introduction of ISO protocols, an
extended period must be expected when both TCP and TP-4 are in use in
different systems. Hence equipment and procedures must be developed to
provide limited communication between systems using the two protocol
sets. This will include dual protocol operation for some gateways,
relay hosts, service hosts, and terminal concentrators. A secondary
purpose of the test system described in detailed recommendation 3
should be to aid in development of this transition support equipment.
Both a general transition strategy and specific transition plans for
each existing system should be developed. The switchover from old to
new protocols will take place at different times as appropriate for
each system during an overall transition period of many years.
(3). As soon as possible, the DOD should develop a protocol test
facility. If Option 1 is followed, this facility would serve primarily
to validate implementations of both old and new protocol sets. If
Option 2 is followed, the facility would initially focus on
demonstrating the suitability of the new protocols for use in a
military environment as rapidly as possible and then provide for
testing of commercially supplied protocol implementations.
For validation purposes, the NBS protocol-testing facility developed
for ISO protocols should serve as a good basis, but extensions to deal
with any DOD-specific option for the ISO protocols, performance, and
DOD protocols would be necessary. DOD is now beginning such a program.
For a more complete demonstration, commercial-quality implementations
of the ISO protocols must be obtained and shown to support military
applications in an operational subnetwork such as such as ARPANET or
DODIIS. In both cases the facility should also be used for development
and demonstration of the transition support equipment mentioned in
detailed recommendation 2.
(4). Procurements of new networks and major upgrades of existing
networks should favor use of ISO TP-4 as rapidly as possible. If
Option 1 is followed, RFPs may specify the new protocols immediately.
If Option 2 is followed, this must await successful completion of the
demonstration discussed in recommendation 3. Procurements for existing
networks using TCP may continue to require TCP-based equipment until an
appropriate conversion point is reached (see detailed recommendation
2).
The purpose of this recommendation is to minimize spending on new TCP
implementations and their subsequent conversion to TP-4 where possible,
while recognizing that some additions to TCP-based systems will also be
needed. If Option 2 is followed, immediate requirements for new
systems may force new implementations of TCP in these cases also
because the demonstration is not completed at the time RFPs must be
issued.
(5). As part of a transition plan, a transport service interface to
higher-level protocols more like that of TP-4 should be developed for
TCP and tested with existing higher-layer protocols.
This should serve as a rapid test of whether existing DOD protocols can
make effective use of the somewhat different style of service that TP-4
provides. It should also allow higher-level protocols to be modified
to make use of TP-4 in parallel with the implementation of TP-4 itself,
making the ultimate transition to TP-4 more rapid and certain of
success. Finally, it may allow use of a single version of the
higher-level protocols to be used on both TCP and TP-4 equipment.
(6). DOD should continue using existing DOD-specific, higher-level
protocols for operational purposes (Telnet, FTP, and Simple Mail
Transfer Protocol, for example) but minimize effort on their further
development and plan to adopt suitable ISO protocols as they are
developed. Research on protocols providing new services (multimedia
mail, compressed video, and voice store-and-forward, for example)
should continue. The committee is pleased to find that DOD is already
pursuing this course of action.
(7). The NBS Institute for Computer Sciences and Technology should
maintain close liaison with DOD to ensure that DOD needs for new
protocols and modifications to existing standards are effectively
represented to appropriate standards bodies. This should include
research areas such as multimedia mail where there is significant
commercial as well as military interest.
The committee is pleased to find that this is already being done
through contracts from DOD for ICST to represent its interests in
standardization activities. Further cooperation (in demonstrating and
testing protocols, for example) could occur.
(8). The NBS and DOD should collaborate from the outset in the
development of new protocols for use as federal standards. This will
ensure early agreement on functions, features, and services of the
protocols under development. The NBS should present the developing work
early to the ISO standardization activities to expedite convergence on
internationally acceptable standards.
Such collaboration could help ensure that future protocol standards
will be developed in a single, coordinated process that results in a
single standard accommodating both DOD, other federal agencies, and
commercial needs.
(9). DOD and NBS should develop additions to protocol specifications
to support preemption of limited resources by high-precedence users.
Such capabilities are needed during high-load situations such as might
develop during wartime or other crisis situations. They are not yet
part of either the TCP or TP-4 specifications or existing
implementations. This should be an example of the sort of
collaboration mentioned in detailed recommendations 7 and 8.
This is important to avoid possible incompatibilities between different
implementations of the same specification as discussed in Section III.
It is likely that vendors would welcome guidance on how to deal with
open areas of the specifications, and early action by DOD could result
in their mandated subset becoming the de facto standard for most
commercial implementations as well, with consequent benefits to DOD.
This is a good area for cooperation between DOD and NBS.
ADDITIONAL CONSIDERATIONS
Transition Plan
This section describes the major elements of a transition plan from
use of TCP to use of TP-4 in DOD systems. The plan will vary
depending on the option chosen. Both Option 1 and Option 2 share a
number of common elements that are discussed first, including
development of a MIL-SPEC, protocol-testing facilities, and transition
support equipment. If Option 2 is followed, a demonstration of TP-4
must also be undertaken.
MIL-SPEC. As noted in recommendation 1, several open areas and
options in the ISO TP-4 must be specified in order to have complete
and compatible protocol implementations. Completion of this
specification by the DOD should be a top priority objective.
Protocol-Testing Facilities. As noted in recommendation 3, test
facilities for protocol implementations are essential. Under Option
1, this facility should serve primarily to validate implementations of
both old and new protocol sets. If Option 2 is followed, the facility
should initially focus on demonstrating the suitability of the new
protocols for use in a military environment as rapidly as possible,
and provide for testing of commercially supplied protocol
implementations.
For validation purposes, the NBS protocol-testing facility developed
for ISO protocols should serve as a good basis, but extensions to deal
with any DOD-specific options for the ISO protocols, performance, and
DOD protocols would be necessary. The DOD has stated that such a
program has been started.
Transition Support Equipment. In any transition plan it must be
assumed that the large body of systems with existing TCP
implementations will take a substantial period of time to switch
completely to the use of the ISO protocols. Some networks will
include many different communities sharing a common communications
backbone. Members of one community communicate primarily among
themselves, but occasionally outside their community. While members
of one community are likely to change over as a group, different
communities will change to use the new protocols at different times.
Hence an interim period must be anticipated when some systems are
using the old protocols and others, the new protocols. The transition
plan must provide some means of allowing interaction between old and
new systems where required during this period. Toward this end, a
number of relay hosts may need to be developed that support both old
and new protocols. These will allow automatic-staged forwarding of
electronic mail between old and new systems and manually set up file
transfer or remote terminal access via the relays. Performance
through these relays will not be as good as with direct connections,
but the relays should provide an adequate level of service for
occasional interactions among different communities of the internet
system.
When more frequent interaction is anticipated and better service is
needed, major service hosts should support both old and new protocol
sets concurrently so they can provide service directly without
requiring the use of relays. Such service hosts include widely used
time-sharing machines, file servers, and special servers such as
Network Information Centers, Network Operations Centers, and
Administrator Machines (providing mailboxes of network administrators,
for example). Some dual protocol servers
may also act as relays where the load of both functions can be
supported.
Terminal concentrators for general use must also support both protocol
sets so that connections to both old and new hosts can be made
directly.
Gateways must support both old and new IPs so hosts using either one
may send internet traffic. This requirement could be relaxed in the
case of entire networks that will switch over simultaneously and hence
will only need one type of IP traffic. Gateways should not have to
translate between old and new IPs--it will be assumed that both source
and destination hosts are using the same protocols or going through an
explicit relay intermediate host.
This latter point requires some elaboration. If one type of IP packet
arrives at a destination host or gateway that only handles the other
type, it must be discarded. It would be good if, in addition, a
suitable ICMP error packet could be returned in the unsupported
protocol so it would be meaningful to the source. To avoid this
situation the internet-host name table maintained by the Network
Information Center should indicate which protocol(s) each host
supports. Then when a source host looks up the address of a
destination, it will also determine which type protocol to use or if a
relay is required.
Demonstration Plan
If Option 2 is followed, a major demonstration of the ISO protocols in
a military environment must be undertaken. Any such demonstration
should proceed by stages beginning with the implementation of TP-4 in
one network (15). Then the demonstration would be extended to include
internetting (still with DOD IP) to validate the suitability of TP-4
as a replacement for TCP. The demonstration would then be further
extended to employ the ISO IP in place of DOD IP.
Stand-Alone TP-4 Network Demonstration. The first stage of any
transition plan must be to establish a demonstration network or
subnetwork using TP-4 in place of TCP under existing higher-level
protocols. This step will require selection of a suitable network (or
subnetwork), procurement of TP-4 implementations for hosts and
terminal access controllers on that network, and modification of
higher-level protocols to use TP-4. The demonstration should include
sufficient use of real applications to test the protocols in an
operational environment.
To limit the amount of change attempted at one time, the DOD IP may be
retained and used under TP-4. Alternatively, if ISO IP development
status seems to warrant it, ISO IP may be installed along with TP-4.
-----
(15) For the remainder of this chapter, the use of TCP and TP-4 to
include their respective IPs will no longer hold. The four
entities--Transmission Control Protocol (TCP) and its Internet Protocol
(DOD IP) and the Transport Protocol (TP-4) and its Internetwork Protocol
(ISO IP)--will be treated individually.
In the latter case, all TP-4 hosts would be on the same network
anyway, so that IP will only be used between hosts and no gateways
will be involved and no gateway modifications will be needed.
The hosts involved could be dedicated to the demonstration and hence
only support TP-4 and only be able to interact with other
demonstration network hosts or be concurrently supporting TCP and DOD
IP for operational traffic to other "normal" hosts. In the latter
case, no forwarding or relaying of traffic by hosts between normal and
ISO logical networks would be allowed or performed (the demonstration
network would be logically closed).
Stand-Alone TP-4 Internet Demonstration. The next step would be to
expand the demonstration to include more than one network (at least
logically) and hence involve gateways. If only TP-4 is involved, this
is a simple extension to test TP-4 over longer internet paths with
more variable performance. If ISO IP is also being tested at the same
time, modification of the gateways involved will also be required as
indicated in the next section.
Stand-Alone ISO IP Demonstration. Once TP-4 has been tested,
introduction of the ISO IP to replace DOD IP may commence. In
addition to simply replacing one IP with the other in hosts and
gateways, this will require modification of the gateways to perform
ICMP and GGP on top of the ISO IP.
These gateways could either be dedicated to the demonstration and
hence have only ISO IP, or could be concurrently supporting normal
operational traffic via DOD IP. In the latter case, once again, no
forwarding of traffic between ISO demonstration internet and normal
systems would be allowed.
At the conclusion of these three steps, the ISO TP-4 and IP could be
deemed to have demonstrated their basic functional suitability in a
military environment. The transition support equipment described
above should have been developed in parallel, providing the capability
to smoothly and successfully switch operational systems using the old
protocols to use of the new protocols.
Switchover of User Systems
Once the above preparations have been made and the demonstration
completed, if Option 2 is being followed, the switchover of user
systems can commence. Each network or community within a network
should be able to switch at its convenience and maintain the ability
to interact with other systems. The user systems will not be required
to support operational use of both protocol sets simultaneously at any
time unless they wish to do so for their own reliability purposes.
Switchover of user systems also requires a personnel-training effort.
While earlier steps involved a relatively small number of specialists
and support staff at major sites, this step will affect all user
sites, and their network support staff must be trained in the new
procedures.
Once switchover of all systems to the new protocol set is complete,
support for the old protocols by TACS, service hosts, and gateways can
be removed.
Lessons Learned from the ARPANET NCP-to-TCP Transition
The following points summarize some important lessons learned during
the ARPANET transition from NCP to TCP (16).
Conversion of TACs and service hosts to support both protocols before
the transition of user hosts starts is essential.
Relay capabilities were heavily used for mail, but used little for
other purposes.
The Network Information Center was not ready to support the new
protocols and this caused problems in distributing the host name
table.
There were significant performance problems that required careful
analysis and parameter tuning after the transition. These were
unavoidable because no service host had been stressed prior to the
switchover, with a full user load over a long time period using the
new protocols.
-----
(16) For additional information, see ARPANET Request for Comments:
NCP/TCP Transition Plan, J. Postel, (Menlo Park, California: SRI
International Telecommunications Sciences Center, November 1981).
