Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 0942

Transport protocols for Department of Defense data networks

Pages: 88
Unclassified
Part 3 of 3 – Pages 60 to 88
First   Prev   None

ToP   noToC   RFC0942 - Page 60   prevText
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
ToP   noToC   RFC0942 - Page 61
  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.
ToP   noToC   RFC0942 - Page 62
                                      

     
ToP   noToC   RFC0942 - Page 63
   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.
ToP   noToC   RFC0942 - Page 64
                                      

     
ToP   noToC   RFC0942 - Page 65
                     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
ToP   noToC   RFC0942 - Page 66
 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.
ToP   noToC   RFC0942 - Page 67
                    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.)
ToP   noToC   RFC0942 - Page 68
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?
ToP   noToC   RFC0942 - Page 69
  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:
ToP   noToC   RFC0942 - Page 70
   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
ToP   noToC   RFC0942 - Page 71
  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
ToP   noToC   RFC0942 - Page 72
  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.
ToP   noToC   RFC0942 - Page 73
                       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.
ToP   noToC   RFC0942 - Page 74
 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.
ToP   noToC   RFC0942 - Page 75
 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
ToP   noToC   RFC0942 - Page 76
  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
ToP   noToC   RFC0942 - Page 77
  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
ToP   noToC   RFC0942 - Page 78
  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
ToP   noToC   RFC0942 - Page 79
 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.
ToP   noToC   RFC0942 - Page 80
                                      

     
ToP   noToC   RFC0942 - Page 81
                          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.
ToP   noToC   RFC0942 - Page 82
 (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.
ToP   noToC   RFC0942 - Page 83
 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.
ToP   noToC   RFC0942 - Page 84
 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.
ToP   noToC   RFC0942 - Page 85
  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.
ToP   noToC   RFC0942 - Page 86
  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.
ToP   noToC   RFC0942 - Page 87
  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.
ToP   noToC   RFC0942 - Page 88
  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).