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).