Network Working Group National Research Council Request for Comments: 942 February 1985 TRANSPORT PROTOCOLS FOR DEPARTMENT OF DEFENSE DATA NETWORKS STATUS OF THIS MEMO This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community. Distribution of this memo is unlimited. This RFC reproduces the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). Transport Protocols for Department of Defense Data Networks Report to the Department of Defense and the National Bureau of Standards Committee on Computer-Computer Communication Protocols Board on Telecommunications and Computer Applications Commission on Engineering and Technical Systems National Research Council National Academy Press Washington, D.C. February 1985 National Research Council [Page i] RFC 942 February 1985 Report Transport on Protocols NOTICE The project that is the subject of this report was approved by the Governing Board on the National Research Council, whose members are drawn from the councils of the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine. The members of the committee responsible for the report were chosen for their special competences and with regard for appropriate balance. This report has been reviewed by a group other than the authors, according to procedures approved by a Report Review Committee consisting of members of the National Academy of Sciences, the National Academy of Engineering, and the Institute of Medicine. The National Research Council was established by the National Academy of Sciences in 1916 to associate the broad community of science and technology with the Academy's purposes of furthering knowledge and of advising the federal government. The Council operates in accordance with general policies determined by the Academy under the authority of its congressional charter of 1863, which establishes the Academy as a private, nonprofit, self-governing membership corporation. The Council has become the principal operating agency of both the National Academy of Sciences and the National Academy of Engineering in the conduct of their services to the government, the public, and the scientific and engineering communities. It is administered jointly by both Academies and the Institute of Medicine. The National Academy of Engineering and the Institute of Medicine were established in 1964 and 1970, respectively, under the charter of the National Academy of Sciences. This is a report of work supported by Contract No. DCA-83-C-0051 between the U.S. Defense Communications Agency and the National Academy of Sciences, underwritten jointly by the Department of Defense and the National Bureau of Standards. Copies of this publication are available from: Board on Telecommunications and Computer Applications Commission on Engineering and Technical Systems National Research Council 2101 Constitution Avenue, N.W. Washington, D.C. 20418 National Research Council [Page ii] RFC 942 February 1985 Report Transport on Protocols BOARD ON TELECOMMUNICATIONS -- COMPUTER APPLICATIONS COMMITTEE ON COMPUTER-COMPUTER COMMUNICATION PROTOCOLS Chairman C. CHAPIN CUTLER, Professor of Applied Physics, Stanford University, Stanford, California Members HERBERT D. BENINGTON, Technical Director, System Development Corporation, McLean, Virginia DONALD L. BOYD, Director, Honeywell Corporate Computer Sciences Center, Honeywell Corporate Technology Center, Bloomington, Minnesota DAVID J. FARBER, Professor of Electrical Engineering and Professor of Computer Science, Department of Electrical Engineering, University of Delaware, Newark, Delaware LAWRENCE H. LANDWEBER, Professor, Computer Sciences Department, University of Wisconsin, Madison, Wisconsin ANTHONY G. LAUCK, Manager, Distributed Systems Architecture and Advanced Development, Digital Equipment Corporation, Tewksbury, Massachusetts KEITH A. LUCKE, General Manager of Control Data Technical Standards, Control Data Corporation, Minneapolis, Minnesota MISCHA SCHWARTZ, Professor of Electrical Engineering and Computer Science, Columbia University, New York, New York ROBERT F. STEEN, Director of Architecture, Communication Products Division IBM Corporation, Research Triangle Park, North Carolina CARL A. SUNSHINE, Principal Engineer, Sytek, Incorporated, Los Angeles Operation, Culver City, California DANIEL J. FINK, (Ex-officio), President, D.J. Fink Associates, Inc., Arlington, Virginia JAMES L. FLANAGAN, (CETS LIAISON MEMBER), Head, Acoustics Research Department, AT&T Bell Laboratories, Murray Hill, New Jersey Staff RICHARD B. MARSTEN, Executive Director JEROME D. ROSENBERG, Senior Staff Officer and Study Director LOIS A. LEAK, Administrative Secretary National Research Council [Page iii] RFC 942 February 1985 Report Transport on Protocols National Research Council [Page iv] RFC 942 February 1985 Report Transport on Protocols COMMISSION ON ENGINEERING AND TECHNICAL SYSTEMS BOARD ON TELECOMMUNICATIONS -- COMPUTER APPLICATIONS Chairman DANIEL J. FINK, President, D.J. Fink Associates, Inc., Arlington, Virginia Past Chairman BROCKWAY MCMILLAN, Vice President (Retired), Bell Laboratories, Sedgwick, Maine Members ARTHUR G. ANDERSON, Vice President (Retired), IBM Corporation, San Jose, California DANIEL BELL, Henry Ford II Professor of Social Sciences, Department of Sociology, Harvard University, Cambridge, Massachusetts HERBERT D. BENINGTON, Technical Director, System Development Corporation, McLean, Virginia ELWYN R. BERLEKAMP, Professor of Mathematics, Department of Mathematics, University of California, Berkeley, California ANTHONY J. DEMARIA, Assistant Director of Research for Electronics and Electro-Optics Technology, United Technologies Research Center, East Hartford, Connecticut GERALD P. DINNEEN, Vice President, Science and Technology, Honeywell Incorporated, Minneapolis, Minnesota GEORGE GERBNER, Professor and Dean, The Annenberg School of Communications, University of Pennsylvania, Philadelphia, Pennsylvania ANNE P. JONES, Partner, Sutherland, Asbill and Brennan, Washington, D.C. ADRIAN M. MCDONOUGH, Professor of Management and Decision Sciences (Retired), The Wharton School, University of Pennsylvania, Havertown, Pennsylvania WILBUR L. PRITCHARD, President, Satellite Systems Engineering, Inc., Bethesda, Maryland MICHAEL B. PURSLEY, Professor of Electrical Engineering, University of Illinois, Urbana, Illinois IVAN SELIN, Chairman of the Board, American Management Systems, Inc., Arlington, Virginia National Research Council [Page v] RFC 942 February 1985 Report Transport on Protocols MISCHA SCHWARTZ, Professor of Electrical Engineering and Computer Science, Columbia University, New York, New York ERIC E. SUMNER, Vice President, Operations System and Network Planning, AT&T Bell Laboratories, Holmdel, New Jersey KEITH W. UNCAPHER, Executive Director, USC-Information Sciences Institute Associate Dean, School of Engineering, University of Southern California, Marina del Rey, California JAMES L. FLANAGAN, (CETS LIAISON MEMBER), Head, Acoustics Research Department, AT&T Bell Laboratories, Murray Hill, New Jersey Staff Richard B. Marsten, Executive Director Jerome D. Rosenberg, Senior Staff Officer Karen Laughlin, Administrative Coordinator Carmen A. Ruby, Administrative Assistant Lois A. Leak, Administrative Secretary National Research Council [Page vi] RFC 942 February 1985 Report Transport on Protocols CONTENTS PREFACE ............................................................ ix EXECUTIVE SUMMARY .................................................. xi I Introduction .................................................. 1 II Review of NBS and DOD Objectives .............................. 3 III Comparison of DOD and ISO Protocols .......................... 13 IV Status of DOD and ISO Protocol Implementations and Specifications .......................... 25 V Markets ...................................................... 31 VI Development of Standard Commercial versus Special Commercial Products .................................. 39 VII Responsiveness of International Standards Process to Change ............................................ 43 VIII Options for DOD and NBS ...................................... 45 IX Cost Comparison of Options .................................. 47 X Evaluation of Options ........................................ 53 XI Recommendations .............................................. 61 National Research Council [Page vii] RFC 942 February 1985 Report Transport on Protocols National Research Council [Page viii] RFC 942 February 1985 Report Transport on Protocols PREFACE This is the final report of the National Research Council Committee on Computer-Computer Communication Protocols. The committee was established in May l983 at the request of the Department of Defense (DOD) and the National Bureau of Standards (NBS), Department of Commerce, to develop recommendations and guidelines for resolving differences between the two agencies on a data communications transport protocol standard. Computer-based information and transaction-processing systems are basic tools in modern industry and government. Over the past several years there has been a growing demand to transfer and exchange digitized data in these systems quickly and accurately. This demand for data transfer and exchange has been both among the terminals and computers within an organization and among those in different organizations. Rapid electronic transport of digitized data requires electronic communication links that tie the elements together. These links are established, organized, and maintained by means of a layered series of procedures performing the many functions inherent in the communications process. The successful movement of digitized data depends upon the participants using identical or compatible procedures, or protocols. The DOD and NBS have each developed and promulgated a transport protocol as standard. The two protocols, however, are dissimilar and incompatible. The committee was called to resolve the differences between these protocols. The committee held its first meeting in August l983 at the National Research Council in Washington, D.C. Following this two-day meeting the committee held five more two-day meetings, a three-day meeting, and a one-week workshop. The committee was briefed by personnel from both agencies. In addition, the committee heard from Jon Postel, University of Southern California's Information Sciences Institute; Dave Oran, Digital Equipment Corporation; Vinton Cerf, MCI; David Wood, The Mitre Corporation; Clair Miller, Honeywell, and Robert Follett, IBM, representing the Computer and Business Equipment Manufacturer's Association; and John Newman, Ultimate Corporation. In most cases the briefings were followed by discussion. The committee wishes to thank Philip Selvaggi of the Department of Defense and Robert Blanc of the NBS, Institute of Computer Sciences and National Research Council [Page ix] RFC 942 February 1985 Report Transport on Protocols Technology, for their cooperation as their agency's liaison representatives to the committee. The committee appreciates the contributions and support of Richard B. Marsten, Executive Director of the Board on Telecommunications -- Computer Applications (BOTCAP), and Jerome D. Rosenberg, BOTCAP Senior Staff Officer and the committee Study Director. We also wish to thank Lois A. Leak for her expert administrative and secretarial support. National Research Council [Page x] RFC 942 February 1985 Report Transport on Protocols EXECUTIVE SUMMARY Computer communication networks have become a very important part of military and commercial operations. Indeed, the nation is becoming dependent upon their efficiency and reliability, and the recent proliferation of networks and their widespread use have emphasized the importance of developing uniform conventions, or protocols, for communication between computer systems. The Department of Defense (DOD) and the National Bureau of Standards (NBS) have been actively engaged in activities related to protocol standardization. This report is concerned primarily with recommendations on protocol standardization within the Department of Defense. Department of Defense's Transmission Protocol The DOD's Defense Advanced Research Projects Agency (DARPA) has been conducting and supporting research on computer networks for over fifteen years (1). These efforts led to the development of modern packet-switched network design concepts. Transmission between computers is generally accomplished by packet switching using strict protocols for the control and exchange of messages. The Advanced Research Projects Agency network (ARPANET), implemented in the early 1970s, provided a testing ground for research on communications protocols. In 1978, after four years of development, the DOD promulgated versions of its Transmission Control Protocol (TCP) and an Internet Protocol (IP) and mandated their use as standards within the DOD. TCP is now widely used and accepted. These protocols meet the unique operational and functional requirements of the DOD, and any changes in the protocols are viewed with some trepidation by members of the department. DOD representatives have stated that standardizing TCP greatly increased the momentum within the DOD toward establishing interoperability between networks within the DOD. International Standards Organization's Transport Protocol The NBS Institute for Computer Sciences and Technology (ICST), in cooperation with the DOD, many industrial firms, and the International Standards Organization (ISO), has developed a new international standard ----- (1) The Advanced Research Projects Agency (ARPA) was reorganized and became the Defense Advanced Research Projects Agency (DARPA) in 1973. National Research Council [Page xi] RFC 942 February 1985 Report Transport on Protocols Transport Protocol (TP-4) and a new Internetwork Protocol (2). These protocols will soon be available as commercial products. Although in part derived from TCP, the new protocols are not compatible with TCP (3). The U.S. standards organizations are supporting TP-4 in international operations, and the Department of Commerce is proposing TP-4 as a Federal Information Processing Standard (FIPS) for use by all federal agencies. DOD OPERATIONAL AND TECHNICAL NEEDS The DOD has unique needs that could be affected by the Transport and Internet Protocol layers. Although all data networks must have some of these capabilities, the DOD's needs for operational readiness, mobilization, and war-fighting capabilities are extreme. These needs include the following: Survivability--Some networks must function, albeit at reduced performance, after many nodes and links have been destroyed. Security--Traffic patterns and data must be selectively protected through encryption, access control, auditing, and routing. Precedence--Systems should adjust the quality of service on the basis of priority of use; this includes a capability to preempt services in cases of very high priority. Robustness--The system must not fail or suffer much loss of capability because of unpredicted situations, unexpected loads, or misuse. An international crisis is the strongest test of robustness, since the system must operate immediately and with virtually full performance when an international situation flares up unexpectedly. Availability--Elements of the system needed for operational readiness or fighting must be continuously available. Interoperability--Different elements of the Department must be able to "talk" to one another, often in unpredicted ways between parties that had not planned to interoperate. ----- (2) The ISO Transport Protocol and ISO Internetwork Protocol became Draft International Standards in September 1983 and April 1984, respectively. Commercial vendors normally consider Draft International Standards to be ready for implementation. (3) Except where noted, the abbreviation TCP generally refers to both the DOD's Transmission Control Protocol and its Internet Protocol. Similarly, the abbreviation TP-4 refers to both the ISO Transport Protocol class 4 and its Internetwork Protocol. (Transport Protocol classes 0 to 3 are used for special purposes not related to those of this study.) National Research Council [Page xii] RFC 942 February 1985 Report Transport on Protocols These operational needs reflect themselves into five technical or managerial needs: 1. Functional and operational specifications (that is, will the protocol designs meet the operational needs?); 2. Maximum interoperability; 3. Minimum procurement, development, and support costs; 4. Ease of transition to new protocols; and 5. Manageability and responsiveness to changing DOD requirements. These are the criteria against which DOD options for using the ISO transport and internet protocols should be evaluated. Interoperability is a very important DOD need. Ideally, DOD networks would permit operators at any terminal to access or be accessed by applications in any computer. This would provide more network power for users, integration of independently developed systems, better use of resources, and increased survivability. To increase interoperability, the Office of the Secretary of Defense has mandated the use of TCP for the Defense Communication System's Defense Data Network (DDN), unless waivers are granted. In addition, the Defense Communication Agency (DCA) is establishing standards for three higher-level "utility" protocols for file transfer, terminal access, and electronic mail. Partly as a result of these actions, it has become clear that there is growing momentum toward accepting interoperability and a recognition that it is an important operational need. It is very important, however, to recognize that functional interoperability is only achieved with full generality when two communication nodes can interoperate at all protocol levels. For the DOD the relevant levels are as follows: 1. Internet, using IP; 2. Transport, using TCP; 3. Utility, using file, terminal, or mail protocols; and 4. Specific applications that use the above protocols for their particular purpose. Accordingly, if a network is developed using one transport protocol, it would generally not be able to interoperate functionally with other networks using the same transport protocol unless both networks were also using the higher-level utility and application protocols. In evaluating whether or not to convert to TP-4 and in developing a transition plan, the following factors must be considered: The DOD contains numerous communities of interest whose principal need is to interoperate within their own members, independently. Such communities generally have a specific, well-defined mission. National Research Council [Page xiii] RFC 942 February 1985 Report Transport on Protocols The DOD Intelligence Information System (DODIIS) and the World Wide Military Command and Control System (WWMCCS) are examples. Interoperability is needed primarily between the higher layer applications programs initially unique to each community of interest. There are many different kinds of operations needed between communities of interest. Examples of such operations are headquarters' need for access to several subordinate communities and the communities' need for some minimum functional interoperability with each other (such as mail exchange). The need for functional interoperability can arise, unexpectedly and urgently, at a time of crisis or when improved management opportunities are discovered. Widespread standardization of TP-4 and higher-level protocols can readily help to achieve these needs. Often, special development of additional applications that cost time and money will be necessary. The DOD needs functional interoperability with many important external agencies that are committed to ISO standards: The North Atlantic Treaty Organization (NATO), some intelligence and security agencies, and other parts of the federal government. The same objectives that have prompted the use of standardized protocols at higher-level headquarters will lead to their use by tactical groups in the field. SOME COMPARISONS A detailed comparison of the DOD Transmission Control Protocol and the ISO Transport Protocol indicates they are functionally equivalent and provide essentially similar services. Because it is clear that a great deal of care and experience in protocol development have gone into generating the specifications for TP-4, the committee is confident that TP-4 will meet military requirements. Although there are differences between the two protocols, they do not compromise DOD requirements. And, although in several areas, including the data transfer interface, flow control, connection establishment, and out-of-band, services are provided in different ways by the two protocols, neither seems intrinsically superior. Thus, while existing applications may need to be modified somewhat if moved from TCP to TP-4, new applications can be written to use either protocol with a similar level of effort. The TCP and TP-4 protocols are sufficiently equivalent in their security-related properties in that there are no significant technical points favoring the use of one over the other. While TCP currently has the edge in maturity of implementation, TP-4 is gaining rapidly due to the worldwide support for and acceptance of the National Research Council [Page xiv] RFC 942 February 1985 Report Transport on Protocols Open System Interconnection (OSI) international standards. Experimental TCP implementations were completed in 1974 at Stanford University and BBN Communications Corporation. Between 1974 and 1982 a large number of implementations were produced. The Defense Advanced Research Projects Agency (ARPA) network switched to a complete use of TCP in January 1983. Operations have been satisfactory and its use is growing. A number of TCP implementations are also in commercial use in various private networks. In contrast, TP-4 has not yet been implemented in any large operational system. It has been tested experimentally, however, and has received endorsement by many commercial vendors worldwide. In addition, substantial portions of TP-4 have been demonstrated at the National Computer Conference in July 1984. The Internet Protocol (IP) part of the standards is not believed to be a problem. The ISO IP is not as far along as TP-4, but it is much less complex. The ISO IP, based very strongly on the DOD IP, became a draft international standard in April 1984. The rapidity of the progress in ISO and the results achieved over the past two years have surprised even the supporters of international standards. The reasons for this progress are twofold: strong market demands stemming from the growing integration of communications and data processing and the progress in networking technology over the past years as the result of ARPA and commercial developments. Although the DOD networks have been a model upon which the ISO transport standards have been built, the rest of the world is adopting TP-4. Because the DOD represents a small fraction of the market and because the United States supports the ISO standard, it is not realistic to hope that TP-4 can be altered to conform with TCP. This raises the question as to what action should be taken by the DOD with respect to the ISO standard. SOME ECONOMIC CONSIDERATIONS The DOD has a large and growing commitment in operational TCP networks, and this will increase by 50 to 100 percent in the next eighteen months. This rate of investment will probably continue for the next five years for new systems and the upgrading of current ones. The current Military Network (MILNET) and Movement Information Network (MINET) systems are expanding and will shortly be combined. The Strategic Air Command Digital Information Network (SACDIN) and DODIIS are undergoing major upgrading. When these changes are completed, there are plans to upgrade the WWMCCS Intercomputer Network (WIN) and to add separate SECRET and TOP SECRET networks. There are plans to combine these six networks in the late 1980s, and they will become interoperable and multilevel secure using an advanced technology now under development. If these plans are implemented on schedule, a delay of several years in moving to TP-4 would mean that the DOD networks in the late 1980s would be virtually all TCP-based. Subsequent conversion to international standards would be very expensive National Research Council [Page xv] RFC 942 February 1985 Report Transport on Protocols if hastily attempted in order to maintain established DOD interoperability and gain interoperability with a large body of users. As the Department of Defense policy recognizes, there are significant advantages in using commercial vendor products if they meet the department's operational needs. The major advantages are as follows: Costs to the DOD for development, production, and maintenance are significantly lower because (1) vendors spread the cost over a much larger user base, (2) commercial vendors are generally more efficient in their operations, and (3) vendors look for ways to improve their product to meet competition. The department generally gets more effective products because vendors integrate the protocol functions into their entire software and hardware product line. Thus the DOD may be able eventually to use commercial software products that are built on top of, and thereby take advantage of, the transport protocols. By depending on industry to manage the development and maintenance of products, the department can use its scarce management and technical resources on activities unique to its mission. Because the costs of transport and internet protocol development and maintenance are so intertwined with other factors, it is impossible to give a precise estimate of the savings that would be achieved by using commercial products. Savings will vary in individual cases. The marginal savings should range from 30 to 80 percent. RECOMMENDATIONS The ISO protocols are now well specified but will not generally be commercially available for many months. Nevertheless, this committee believes that the principles on which they are based are well-established, and the protocols can be made to satisfy fully DOD's needs. The committee recommends that the DOD move toward adoption of TP-4 as costandard with TCP and toward exclusive use of TP-4. Transition to the use of the ISO standards, however, must be managed in a manner that will maintain DOD's operational capabilities and minimize risks. The timing of the transition is, therefore, a major concern. Descriptions of two options that take this requirement into account follow. A majority of the committee recommends the first option, while a minority favors the second. A third option--to defer action--is also described but not recommended. 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 National Research Council [Page xvi] RFC 942 February 1985 Report Transport on Protocols 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 (4). The Department of Defense would either require that products be validated using these test facilities or that they 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, ----- (4) Validation means a systematic and thorough state-of-the-art testing of the products to assure that all technical specifications are being achieved. National Research Council [Page xvii] RFC 942 February 1985 Report Transport on Protocols however, should 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 on 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. Comparison of Options The committee believes that all three options equally satisfy the functional objectives of the DOD, including matters of security. It believes the two protocols are sufficiently similar and no significant differences in performance are to be expected if the chosen protocol implementation is of equal quality and is optimized for the given environment. The primary motivation for recommending Option 1 is to obtain the benefits of standard commercial products in the communication protocol area at an early date. 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, commercial), which presumably will also use TP-4, would be brought about more quickly. Option 1 involves greater risk, however, since it commits to a new approach without as complete 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 because 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, because 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 National Research Council [Page xviii] RFC 942 February 1985 Report Transport on Protocols 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 delay. It would allow the most rapid achievement of full internal interoperability among DOD systems. Manageability should be good because only one set of protocols would be in use (one with which the DOD already has much experience), and because the DOD would be in complete control of system evolution. Procurement costs for TCP systems would remain high compared with 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 involves the least risk and provides the quickest route to interoperability within the Defense Department at the least short-term cost. These are, however, accompanied by penalties of incompatibility with NATO and other external systems and higher life-cycle costs. National Research Council [Page xix] RFC 942 February 1985 Report Transport on Protocols National Research Council [Page xx] RFC 942 February 1985 Report Transport on Protocols I. INTRODUCTION For the past two decades industry and government have experienced an increasing need to share software programs, transfer data, and exchange information among computers. As a result, computer-to-computer data communications networks and, therefore, communication formats and procedures, or protocols, have proliferated. The need to interconnect these networks is obvious, but the problems in establishing agreements among users on the protocols have heightened. The Department of Defense (DOD) has been conducting research and development on protocols and communication standards for more than fifteen years. In December 1978 the DOD promulgated versions of the Defense Advanced Research Projects Agency's (DARPA) Transmission Control Protocol (TCP) and Internet Protocol (IP) as standards within DOD. With the participation of major manufacturers and systems houses, the DOD has implemented successfully over twenty different applications of these standards in DOD operational data communications networks. The Institute for Computer Sciences and Technology (ICST) of the National Bureau of Standards (NBS) is the government agency responsible for developing network protocols and interface standards to meet the needs of federal agencies. The Institute has been actively helping national and international voluntary standards organizations develop sets of protocol standards that can be incorporated into commercial products. Working with both industry and government agencies, the ICST has developed protocol requirements based, in terms of functions and services, on the DOD's TCP. These requirements were submitted to the International Standards Organization (ISO) and resulted in the development of a transport protocol (TP-4) that has the announced support of twenty computer manufacturers. Although the ISO's TP-4 is based on the DOD's TCP, the two protocols are not compatible. Thus manufacturers who wish to serve DOD, while remaining able to capture a significant share of the worldwide market, have to field two product lines that are incompatible but perform the same function. The Institute for Computer Sciences and Technology would like to have a single set of protocol standards that serves both the DOD, other government agencies, and commercial vendors. It would be to the advantage of the DOD to use the same standards as the rest of the world. The dilemma, however, is understandable: The DOD National Research Council [Page 1] RFC 942 February 1985 Report Transport on Protocols has well satisfied its requirements by its own tried and proven protocols, the agency has invested heavily in systems operating successfully with TCP, and the Armed Forces is increasingly adopting the protocol. Thus, although DOD's policy is to use commercial standards whenever suitable, it is hesitant about converting to the ISO TP-4 protocols. In addition, the DOD is not certain whether the ISO TP-4 completely satisfies military requirements. In 1983 both DOD and the ICST agreed that an objective study of the situation was needed. Each requested assistance from the National Research Council. The National Research Council, through its Board on Telecommunications and Computer Applications (BOTCAP), appointed a special Committee on Computer-Computer Communication Protocols to study the issues and develop recommendations and guidelines for ways to resolve the differences in a mutually beneficial manner. The six items composing the committee's scope of work are as follows: 1. Review the technical aspects of the DOD transmission control and ICST transport protocols. 2. Review the status of the implementation of these protocols. 3. Review the industrial and government markets for these protocols. 4. Analyze the technical and political implications of the DOD and ICST views on the protocols. 5. Report on time and cost implications to the DOD, other federal entities, and manufacturers of the DOD and ICST positions. 6. Recommend courses of action toward resolving the differences between the DOD and ICST on these protocol standards. The committee devoted considerable effort to reviewing the objectives and goals of the DOD and NBS that relate to data communications, the technical aspects of the two protocols, the status of their implementation in operating networks, and the market conditions pertaining to their use. This process included hearing government and industry presentations and reviewing pertinent literature. The results of this part of the study are presented in Sections II through VII. Concurrent with this research and analysis, the committee developed ten possible options that offered plausible resolutions of the problem. These ranged from maintaining the status quo to an immediate switchover from one protocol to the other. From these ten initial options three were determined to hold the greatest potential for resolving the problem. Section VIII describes the three options, Section IX provides a cost comparison, and Section X provides an overall evaluation of the three options. Section XI presents the committee's basic and detailed recommendations for how best the DOD might approach the differences between its protocol and the ISO protocol. National Research Council [Page 2] RFC 942 February 1985 Report Transport on Protocols II. REVIEW OF NBS AND DOD OBJECTIVES The National Bureau of Standards and the Department of Defense are such disparate organizations that the committee felt it needed to begin its study with a definition of the roles and expectations of each with regard to the protocol issues in question. The following provides a review of each organization's objectives (5). NBS OBJECTIVES The National Bureau of Standards has three primary goals in computer networking: 1. To develop networking and protocol standards that meet U.S. government and industry requirements and that will be implemented in off-the-shelf, commercial products. 2. To develop testing methodologies to support development and implementation of computer network protocols. 3. To assist government and industry users in the application of advanced networking technologies and computer and communications equipment manufacturers in the implementation of standard protocols. Development of Networking and Protocol Standards The Bureau accomplishes the first objective through close coordination and cooperation with U.S. computer manufacturers and communications system developers. Technical specifications are developed cooperatively with U.S. industry and other government agencies and provided as proposals to voluntary standards organizations. Because the Department of Defense is potentially the largest government client of these standards, DOD requirements are carefully factored into these proposals. In addition, protocols for computer-to-computer communications developed within the DOD research community are used as an ----- (5) The objectives were reviewed by representatives of NBS and DOD, respectively. National Research Council [Page 3] RFC 942 February 1985 Report Transport on Protocols exact statement of DOD functional needs for a particular protocol and form a basis for the functions, features, and services of NBS-proposed standards. To further the development of commercial products that implement standards, the NBS gives priority to the needs of U.S. computer manufacturers who wish to market their products nationally and internationally, not just to the U.S. government. The NBS participates, therefore, in national and international voluntary standards organizations toward the development of an international consensus based on United States needs. Specifications, formal description techniques, testing methodologies, and test results developed by the NBS are used to further the international standardization process. Development of Testing Methodologies The National Bureau of Standards has laboratory activities where prototypes of draft protocol standards are implemented and tested in a variety of communications environments supporting different applications on different kinds and sizes of computers. Communications environments include, for example, global networks, local networks, and office system networks. Applications may, for example, include file transfer or message processing. The primary purposes are to advance the state of the art in measurement methodologies for advanced computer networking technologies and determine protocol implementation correctness and performance. The NBS views testing as a cooperative research effort and works with other agencies, private-sector companies, and other countries in the development of methodologies. At this time, this cooperation involves five network laboratories in other countries and over twenty computer manufacturers. The testing methodologies developed at the NBS are well documented, and the testing tools themselves are developed with the objective of portability in mind. They are made available to many organizations engaged in protocol development and implementations. Assisting Users and Manufacturers The NBS works directly with government agencies to help them use evolving network technologies effectively and apply international and government networking standards properly. When large amounts of assistance are required, the NBS provides it under contract. Assistance to industry is provided through cooperative research efforts and by the availability of NBS testing tools, industry wide workshops, and cooperative demonstration projects. At this time, the NBS is working directly with over twenty computer manufacturers in the implementation of network protocol standards. National Research Council [Page 4] RFC 942 February 1985 Report Transport on Protocols Consistent with overall goals, NBS standards developments, research in testing methodologies, and technical assistance are characterized by direct industry and government cooperation and mutual support. DOD OBJECTIVES The DOD has unique needs that could be affected by the Transport and Internet Protocol layers. Although all data networks must have some of these capabilities, the DOD's needs for operational readiness, mobilization, and war-fighting capabilities are extreme. These needs include the following: Survivability--Some networks must function, albeit at reduced performance, after many nodes and links have been destroyed. Security--Traffic patterns and data must be selectively protected through encryption, access control, auditing, and routing. Precedence--Systems should adjust the quality ot service on the basis of priority of use; this includes a capability to preempt services in cases of very high priority. Robustness--The system must not fail or suffer much loss of capability because of unpredicted situations, unexpected loads, or misuse. An international crisis is the strongest test of robustness, since the system must operate immediately and with virtually full performance when an international situation flares up unexpectedly. Availability--Elements of the system needed for operational readiness or fighting must be continuously available. Interoperability--Different elements of the Department must be able to "talk" to one another, often in unpredicted ways between parties that had not planned to interoperate. These operational needs reflect themselves into five technical or managerial needs: 1. Functional and operational specifications (that is, will the protocol designs meet the operational needs?); 2. Maximum interoperability; 3. Minimum procurement, development, and support costs; 4. Ease of transition to new protocols; and 5. Manageability and responsiveness to changing DOD requirements. These are the criteria against which DOD options for using the ISO transport and internet protocols should be evaluated. National Research Council [Page 5] RFC 942 February 1985 Report Transport on Protocols Performance and Functionality The performance and functionality of the protocols must provide for the many unique operational needs of the DOD. The following paragraphs discuss in some detail both these needs and the ways they can impact protocol design. Survivability includes protecting assets, hiding them, and duplicating them for redundancy. It also includes endurance--the assurance that those assets that do survive can continue to perform in a battle environment for as long as needed (generally months rather than hours); restoral--the ability to restore some of the damaged assets to operating status; and reconstitution--the ability to integrate fragmented assets into a surviving and enduring network. The DOD feels that an important reason for adopting international and commercial standards is that under cases of very widespread damage to its own communications networks, it would be able to support DOD functions by using those civil communications that survive. This would require interoperability up to the network layer, but neither TCP nor TP-4 would be needed. The committee has not considered the extent to which such increased interoperability would increase survivability through better restoral and reconstitution. Availability is an indication of how reliable the system and its components are and how quickly they can be repaired after a failure. Availability is also a function of how badly the system has been damaged. The DDN objective for system availability in peacetime varies according to whether subscribers have access to l or 2 nodes of the DDN. For subscribers having access to only one node of the DDN, the objective is that the system be available 99.3 percent of the time, that is, the system will be unavailable for no more than 60 hours per year. For subscribers having access to 2 nodes, the objective is that the system be available 99.99 percent of the time, that is, the system will be unavailable for no more than one hour per year. Robustness is a measure of how well the system will operate successfully in face of the unexpected. Robustness attempts to avoid or minimize system degradation because of user errors, operator errors, unusual load patterns, inadequate interface specifications, and so forth. A well designed and tested system will limit the damage caused by incorrect or unspecified inputs to affect only the performance of the specific function that is requested. Since protocols are very complex and can be in very many "states", robustness is an important consideration in evaluating and implementing protocols. Security attempts to limit the unauthorized user from gaining both the information communicated in the system and the patterns of traffic throughout the system. Security also attempts to prevent spoofing of the system: an agent attempting to appear as a legitimate user, insert false traffic, or deny services to users by repeatedly seeking system services. National Research Council [Page 6] RFC 942 February 1985 Report Transport on Protocols Finally, Security is also concerned with making sure that electronic measures cannot seriously degrade the system, confuse its performance, or cause loss of security in other ways. Encryption of communication links is a relatively straightforward element of security. It is widely used, fairly well understood, constantly undergoing improvement, and becoming less expensive. On the other hand, computer network security is a much newer field and considerably more complex. The ability of computer network protocols to provide security is a very critical issue. In the past decade much has been learned about vulnerability of computer operating systems, development of trusted systems, different levels of protection, means of proving that security has been achieved, and ways to achieve multilevel systems or a compartmented mode. This is a dynamic field, however, and new experience and analysis will probably place new requirements on network protocols. Crisis-performance needs are a form of global robustness. The nature of a national security crisis is that it is fraught with the unexpected. Unusual patterns of communication traffic emerge. Previously unstressed capabilities become critical to national leaders. Individuals and organizations that had not been communicating must suddenly have close, secure, and reliable communications. Many users need information that they are not sure exists, and if it does, they do not know where it is or how to get it. The development of widely deployed, interoperable computer networks can provide important new capabilities for a crisis, particularly if there is some investment in preplanning, including the higher-level protocols that facilitate interoperability. Presidential directives call for this. This will become a major factor in DOD's need for interoperability with other federal computer networks. The DOD, as one of the most affected parties, has good reason to be concerned that its network protocols will stand the tests of a crisis. In addition, there are performance and functionality features that are measures of the capability of the network when it is not damaged or stressed by unexpected situations. Performance includes quantifiable measures such as time delays, transmission integrity, data rates and efficiency, throughput, numbers of users, and other features well understood in computer networks. Equally important is the extent of functionality: What jobs will the network do for the user? The DDN has established some performance objectives such as end-to-end delays for high-precedence and routine traffic, the probability of undetected errors, and the probability of misdelivered packets. Such objectives are important to engineer a system soundly. The DOD must place greater emphasis on more complex performance issues such as the efficiency with which protocols process and communicate data. The DOD has stated a need for an effective and robust system for precedence and preemption. Precedence refers to the ability of the system to adaptively allocate network resources so that the network performance is related to the importance of the function being National Research Council [Page 7] RFC 942 February 1985 Report Transport on Protocols performed. Preemption refers to the ability of the system to remove users (at least temporarily) until the needs of the high-priority user are satisfied. The ARPANET environment in which the protocols were developed did not emphasize these capabilities, and the current MILNET does not function as effectively in this regard as DOD voice networks. The DOD has also stated a need for connectionless communications and a broadcast mode. In the majority of network protocols, when two of more parties communicate, virtual circuits are established between the communicating parties. (For reliability, additional virtual circuits may be established to provide an in place backup.) DOD needs a connectionless mode where the message can be transmitted to one or more parties without the virtual circuit in order to enhance survivability; provide a broadcast capability (one sender to many receivers); and handle imagery, sensor data, and speech traffic quickly and efficiently. If intermediate nodes are destroyed or become otherwise unavailable, there is still a chance that the data can be sent via alternate paths. The broadcast capability is particularly important in tactical situations where many parties must be informed almost simultaneously and where the available assets may be disappearing and appearing dynamically. The Department of Defense requires an internetting capability whereby different autonomous networks of users can communicate with each other. Interoperability Presidential and DOD directives place a high priority on interoperability, which is related to the internetworking previously discussed. Interoperability is primarily important at two levels: network access and applications. To achieve interoperability at the level of network access,users of backbone communications nets must utilize the same lower-level protocols that are utilized by the network. Generally these protocols are layers 1, 2, and 3, up to and including part of the IP layer. In other words, interoperability for network access does not depend on either implementation of the transport layer (TP-4 or TCP) or of all of the internet (IP) layer. The primary advantages of network access interoperability are twofold: 1. Significant economies of scale are possible since the various users can share the resources of the backbone network including hardware, software, and development and support costs. 2. Network survivability for all users can be increased significantly since the network has high redundancy and, as the threat increases, the redundancy can also be increased. Interoperability at the applications layer allows compatible users at different nodes to talk to each other, that is, to share their data, National Research Council [Page 8] RFC 942 February 1985 Report Transport on Protocols support each other, and thereby coordinate and strengthen the management of forces and other assets. Interoperability at the applications layer can be achieved through the use of specialized software that performs those functions of higher-layer protocols (such as TCP or TP-4, file transfer, and virtual terminal) that are needed by the particular application. If some of the higher-layer transport and utility protocols have been developed for particular hosts or work stations, their use greatly reduces development, integration, and support costs, although with a potential sacrifice of performance. Interoperability at the applications level, that is, full functional interoperability, is important to specialized communities of users such as the logistics, command and control, or research and development communities. As these different communities utilize the DDN, they have the advantages of shared network resources. Within each community there is full functional interoperability but generally there is much less need for one community to have functional interoperability with members of another community. The implementation of TCP or TP-4 within network users, but without the implementation of higher-level protocols and application interoperability, is not generally an immediate step in increasing interoperability. It does have these immediate advantages: It represents an important step in investing in longer-term interoperability. It generally represents an economical near-term investment on which communities of interest can build their own applications. It facilitates the development of devices for general network use such as Terminal Access Controllers (TACs). Interoperability at the applications level will become increasingly important among the following communities: Worldwide Military Command and Control Systems, including systems of subordinate commands; Department of Defense Intelligence Information Systems; U.S. tactical force headquarters (fixed and mobile); NATO force headquarters; other U.S. intelligence agencies; the State Department; and the Federal Bureau of Investigation and other security agencies. Although interoperability of applications within the DOD has the highest priority, it is clear that government wide and international interoperability will be an objective with increasing priority. The NATO situation is especially important (6). ----- (6) Europe has been a major force in the development of ISO standards. Consistent with this is a NATO commitment to adopt ISO standards so long as they meet military requirements. National Research Council [Page 9] RFC 942 February 1985 Report Transport on Protocols In a somewhat longer time period, DOD will want applications interoperability with many commercial information services. As interoperable computer networks become more common, processing and data services will burgeon in the marketplace. These will include specialized data bases and analytic capabilities that all large organizations will need in order to be up-to-date and competitive. With regard to interoperability at the network level, DOD will want to be able to utilize commercially available networks for both survivability and operational effectiveness and economy. In the case of a major war in Europe, for example, the United States would want to be able to use surviving PTTs (Postal, Telegraphy, and Telephony Ministries) for restoral and reconstitution. During peacetime there will be cases where special DOD needs can be best satisfied with commercially available capabilities. As technology continues to provide less expensive, smaller, and more reliable data processing equipment, computer networks will become increasingly prevalent at lower levels of the tactical forces--land, air, and sea. It will be important that these tactical networks be capable of interoperability with each other (for example, air support of ground forces) and with headquarters. It is likely that the tactical network will need a network architecture and protocols that are different from the ARPA-\and ISO-derived protocols. If so, the developments will place requirements on the higher-level DOD protocols. If the DOD chooses to move from TCP to TP-4, this can be done in phases for different communities of interest and subnetworks. In this way if there is difficulty in converting one subnet, the rest of the network need not be degraded. Also the different subnets will be able to make the transition at the most suitable time in terms of cost, risk, and the need to interoperate with other subnets. As a result if DOD uses TP-4 for some new nets or major upgrade of existing nets, this will generally not reduce interoperability in the near term unless interoperability of applications is needed between two communities. In this case specific interoperability needs may be satisfied with specialized gateways for mail or data exchange. The DOD points out that it desires all networks to be interoperable since it is not possible to predict when one community will need to communicate with another or use the resources of the other. As previously indicated, however, unexpected needs for full functional interoperability can only be met when appropriate higher-layer software is developed. Minimize Costs The Department of Defense seeks to minimize costs of development, procurement, transition (if it decides to move to ISO protocols), and support. Generally the objective is to limit life-cycle costs, that is, the total costs over a 5-to-8-year period with future costs suitably discounted (10 to 20 percent per year). National Research Council [Page 10] RFC 942 February 1985 Report Transport on Protocols The Department of Defense has already made a heavy investment in protocols, and the investment has paid off in the success of current protocols operational in many networks. On the other hand, the DOD acknowledges the potential advantages of using the ISO protocols if made available as commercially supported products. Development costs for these protocols can be small since their development cost is amortized by the commercial vendor over a larger market. Support costs for these protocols (including minor modifications, integration into other products, documentation, and training) are also significantly reduced because of vendor-supplied services. These cost factors are further discussed in Section IX in terms of the three options presented in Section VIII. Ease of Transition and Manageability Networks must be manageable and capable of growth and improvement. The Department of Defense generally makes the fastest progress in developing complex information systems if it evolves these capabilities while working in concert with the users and the acquiring agencies. In this light, the following factors are important: Minimal interruption of current service--For most DOD networks it is essential that they operate continuously. If there is to be transition to new protocol services (whether based on current DOD versions or ISO), it is important that these transitions be planned, designed, and pretested so that the transition will be nondisruptive. Verifiability--It is essential to have a testing capability where new protocol implementations can be thoroughly tested to ensure that they will interoperate, have full functionality specified, do not contain errors, are robust, and meet quantitative performance needs. The National Bureau of Standards has established such a capability, and it is being used to verify a number of TP-4 implementations, including those demonstrated at the National Computer Conference in July 1984. An IP-testing capability is being added. The Department of Defense is planning a similar protocol test facility for TCP, but work is just getting underway. If the DOD plans to migrate promptly to TP-4, there is a question whether this investment is warranted. Compatibility with higher protocols--As the transport and lower-protocol layers evolve, it is essential that they maintain full compatibility with higher-layer protocols. This is particularly important for the DOD because it will increasingly have inter-operability at the applications level. Responsiveness to evolving DOD needs--Current DOD needs will change or new needs may arise. It is very likely, for example, that subtle performance problems may be discovered in a protocol that are unique to the strenuous DOD-operating environment and that could have serious operational consequences. If the DOD is using commercial protocols products based upon international standards, the DOD will need two commitments when critical deficiencies are discovered. It will need a commitment from the manufacturer that critical problems National Research Council [Page 11] RFC 942 February 1985 Report Transport on Protocols will be promptly fixed and a commitment from the NBS that it will move quickly to change federal standards and seek changes in international standards. Minimal risks--The DOD needs are so large and important, it cannot afford to take otherwise avoidable risks. Maintenance of manageability--The DDN is new and is using a new approach after the cancellation of AUTODIN II (7). There are pressing operational needs and many impatient users. If the DOD delays in moving to ISO protocols and later decides to do so, the costs and disruption will be large. On the other hand, moving now to ISO will be less disruptive. ----- (7) AUTODIN II was a program to develop a data communications system for the DOD. The program envisioned relatively few large packet switches. It was cancelled in 1982 in favor of ARPANET-derived designs because of considerations of security, architecture, survivability, and cost. National Research Council [Page 12] RFC 942 February 1985 Report Transport on Protocols III. COMPARISON OF DOD AND ISO PROTOCOLS This section presents a general description of the major functional differences between the ISO and DOD protocol sets at the transport and network layers and then discusses particular aspects of the protocols: performance, security, and risk. COMPARISON OF DOD AND ISO TRANSPORT LAYERS Differences between the Defense Department's TCP protocol and the International Standards Organization's TP-4 protocol are described in terms of items visible to users of the protocol. Internal differences in mechanism that have no effect on the service seen by the user are not considered. A second much simpler protocol, the User Datagram Protocol (UDP), providing datagram or connectionless service at the transport layer is also briefly considered. In summary, the services provided by TCP and TP-4 are functionally quite similar. Several functions, however, including data transfer interface, flow control, connection establishment binding, and out-of-band signals are provided in significantly different ways by the two protocols. Neither seems intrinsically superior, but some effort would be required to convert a higher-level protocol using TCP to make use of TP-4. The exact amount of work needed will vary with the nature of the higher-level protocol implementations and the operating systems in which they are embedded. A programmer experienced with the higher-level protocols would require about six months to design, implement, and test modifications of the three major DOD higher-level protocols (file transfer, mail, and Telnet) to work with TP-4. There are several areas in which the openness and lack of experience with the TP-4 specification leave questions about just what functionality is provided and whether incompatibilities are allowed. These areas include connection-establishment binding, flow control, addressing, and provision of expedited network service. The best way to resolve these questions seems to be to implement and test TP-4 in a military environment and to further specify desired procedures where there is unwanted latitude allowed by the standard (see the recommendations section XI). There is one area in which the NBS-proposed Federal Information Processing Standard (FIPS) differs from the ISO specification: The FIPS provides a graceful closing service as in TCP, while the ISO does not. National Research Council [Page 13] RFC 942 February 1985 Report Transport on Protocols Data Transfer Interface TCP is stream oriented. It does not deliver any End of Transmission (EOT), but accepts a "push" on the send side which has an effect much like an EOT causes data being buffered to be sent. TP-4 is block oriented and does deliver EOT indications. By indicating EOT, a sending user should be able to accomplish the same effect as "push" in TCP in most reasonable TP-4 implementations. The impact of this is uncertain. Neither type of interface is inherently better than the other. Some applications will find it more convenient to have a stream-type interface (for example, interactive terminal handling), while others might prefer a block mode (for example, file transfer). It should be possible for TP-4 to approximate the stream mode by forwarding data without an EOT from the sending user and delivering data to the receiving user before an EOT is received. Some work would have to be done on applications using one type of protocol to modify them to use the other. Flow Control TCP has octet units of allocation, with no EOT and hence no impact of EOT on the allocation. The segment size, Transport Protocol Data Unit (TPDU) size, used by the protocol is invisible to the user, who sees allocations in units of octets. TP-4 has segment units of allocation, with a common segment size for both directions negotiated as part of connection establishment. Although in some implementations the protocol's flow control is not directly visible to the users, in others it is. In the latter case, users of TP-4 will see allocations in units of segments and will have to be aware of the segment size for this to be meaningful (for example, to know that a window of four 100-byte segments seen will be consumed by two messages of 101 to 200 bytes each). The impact is uncertain. Both octet and segment units of flow control can be argued to have their advantages for different types of application. The former makes it easy to indicate buffering limits in terms of total bytes (appropriate for stream transfer), while the latter makes it easy to indicate buffering limits in terms of messages (appropriate for block mode). The way in which flow control is exerted over an interface is complex and one of the most performance-sensitive areas of protocols, so a significant conversion and tuning effort would be required to get an application used with one type of high-level protocol to be able to perform using another. Error Detection TCP applies ones-complement addition checksum. TP-4 uses an ISO National Research Council [Page 14] RFC 942 February 1985 Report Transport on Protocols algorithm (8). The error-detection properties of the TCP procedure have not been studied carefully, but the ISO algorithm is thought to be somewhat stronger and hence allows fewer nondetected errors in data passed to users. It should be noted that the TCP checksum is defined to include certain fields from the IP level including addresses so that double protection against misdelivery errors is provided. The practical difference in error-detection power is probably not important. Simultaneous Call Between Same Users TCP will establish one call. TP-4 will establish two calls if both sides support multiple calls, no call if they allow only one call (that is, see each other as busy), or in very unusual circumstances, one call. The impact is minor since most applications naturally have an initiator and a responder side. Multiple Calls Between Same Addresses_ TCP allows only one call between a given pair of source and destination ports. TP-4 allows more than one by using reference numbers. The impact is minor since it is easy to generate a new per-call port number on the calling side in most cases. This can be a problem in TCP, however, if both are well-known ports. Addressing TCP provides sixteen bit ports for addressing within a node identified by the internet layer. Some of these ports are assigned to well-known applications, others are free for dynamic assignment as needed. TP-4 provides a variable-length transport suffix (same as Transport Service Access Point Identifier) in the call-request packet. The use of addresses at different levels in the ISO model has not yet been solidified, but it seems likely that addressing capabilities similar to TCP's will eventually be provided by TP-4 (or possibly the session layer) along with standard addresses for common applications. The impact is likely to be minimal, but this is an open area of the ISO specifications that may need further definition for use by DOD. Binding User Entities to Connections TCP requires a prior Listen Request from a user entity for it to be able to accept an incoming connection request. Normally a user entity must exist and declare itself to TCP, giving prior approval to accept ----- (8) For additional information, see Information Processing Systems, Open Systems Interconnection, Connection-Oriented Transport Protocol Specifications, ISO DIS 8073, Section 6.17, page 45. National Research Council [Page 15] RFC 942 February 1985 Report Transport on Protocols a call from a specific or general remote entity. In some implementations it may be possible for a nonresident user entity to cause a Listen Request to be posted and an instance of the entity to be created when a matching connection request arrives. TCP does not queue an incoming connection request with no matching Listen Request but instead rejects the connection. TP-4 requires no prior request but passes a Call Indication to a user entity whenever a Call Request is received. It is, however, left open as an implementation decision as to how TP-4 finds and/or creates an appropriate user entity to give the Call Indication; that is, the service does not include or define how user applications make themselves available for calls (no Listen Service Primitive). The implementation guidelines indicate that well-known addresses, prior process existence, and Call Request queuing are all facilities that may or may not be provided at the implementor's choice (9). This would seem to allow for different choices and hence failure to establish a connection between standard implementations (for example, caller expects requests not to be queued, while callee does queuing, and hence never responds). The practical impact is uncertain due to lack of experience with how the various options allowed by the TP-4 standard will be used in practice. TCP seems more oriented to a prior authorization mode of operation, while TP-4 most easily supports an indication-with-later-acceptance scenario. It is not clear how TP-4 will support rejecting calls to nonexistent or inactive user entities and how user entities could control how many calls they would accept. This area may require DOD refinement. Out-of-Band Signals TCP allows the user to specify an urgent condition at any point in the normal data stream. Several such indications may be combined, with only the last one shown to the destination. There is no limit to the number of urgent indications that can be sent. The TCP urgent messages are sent requesting expedited service from the network layer so network bottlenecks can be bypassed as well. TP-4 allows users to send expedited data units carrying up to sixteen octets of user data. These are only half synchronized with the normal data stream since they may be delivered before previously sent normal data, but not after subsequently sent normal data. Each expedited data unit is delivered to the destination, and only one can be outstanding at a time. ISO has indicated its intention to allow transport protocols to use network-level expedited service, but this ----- (9) Specification of a Transport Protocol for Computer Communications, Vol. 5: Guidance for the Implementor, Section 2.11.2. National Bureau of Standards, Institute for Computer Sciences and Technology, (Washington, D.C.) U.S. Department of Commerce, January 1983. National Research Council [Page 16] RFC 942 February 1985 Report Transport on Protocols is not yet defined. The impact is primarily for applications like terminal traffic handlers that must deal with interrupt-type signals of various types. The need to read an arbitrary amount of normal data and recognize urgent data in the normal stream are difficulties with TCP urgent service, but it has been used successfully by the Telnet protocol. The lack of full synchronization of the signal and normal data in TP-4 may require users to insert their own synchronization marks in the normal data stream [as was the case with the old ARPA Network Control Program (NCP)], and the limitation of one outstanding signal may be restrictive. Some effort would be required to convert higher-level protocols using one transport protocol to using the other. Security The committee has determined that the TCP and TP-4 are sufficiently equivalent in their security-related properties so that no significant technical points favor the use of one over the other. The DOD protocol architecture assigns the security-marking function to the IP layer and provides an 11-byte security option with a defined coding in the IP header. TP-4 provides a variable-length security option carried in Call Request packets. A variable-length security option field is also provided in the ISO IP. Standard encoding of security markings are under consideration but not yet defined and accepted. In addition to these explicit security-marking fields, the existence, coding, and placement of other header fields have security implications. If data is encrypted, for example, a checksum is usually used to determine if the decrypted data is correct, so the strength of the checksum has security implications. Precedence TCP supports precedence by using three bits provided in IP headers of every packet. TP-4 provides a 2-byte priority option in Call Request packets. A 2-byte priority option in the ISO IP header is also under consideration. Currently, no implementations make use of precedence information (to support preemption, for example). There should be no impact, therefore, of changing from one protocol to the other. Type of Service The types of network service that can be requested via TCP and TP-4 are somewhat different. The impact seems minimal since few networks do anything with the type of service fields at present with the exception of DARPA's packet radio and satellite nets. This may become more important in the future. National Research Council [Page 17] RFC 942 February 1985 Report Transport on Protocols Datagram Service TCP provides only reliable session service. A separate User Datagram Protocol (UDP) in the DOD architecture supports transaction or connectionless-type interaction where individual messages are exchanged. UDP is merely an addition of the port-addressing layer to the basic datagram service provided by IP. No delivery confirmation or sequencing is provided (although IP provides fragmentation and reassembly). The NBS TP-4 specification originally presented to the committee provided unit-data-transfer service within the same protocol framework as sessions (10). This material has since been deleted to bring the NBS proposal into conformance with ISO work. A separate ISO datagram protocol similar to UDP has been defined and is expected to become a draft proposed standard in June 1984. Closing TCP provides a graceful closing mechanism that ensures that all data submitted by users are delivered before the connection is terminated. The NBS TP-4 provides a similar mechanism, but is not included in the ISO standard TP-4, which provides only an immediate disconnect service. Impact is significant if the ISO version is used because users would then have to add their own graceful termination handshake if desired. COMPARISON OF DOD AND ISO INTERNET LAYERS The internet protocols of DOD and ISO are much more similar to one another than the transport protocols. This is not surprising since the Defense Department's IP was used as the basis for the International Standards Organization's IP. Some reformatting, renaming, and recoding of fields has been done. Hence not only are the services to higher layers essentially equivalent, but the protocol mechanisms themselves are also nearly identical. Due to the format changes, however, the two protocols are incompatible. It should be noted that the IP itself forms only part of the internet layer. For clarity it should also be noted that the internet layer in ISO is considered to be the top sublayer within the network layer. In DOD, there is an additional Internet Control Message Protocol (ICMP) that deals with error conditions, congestion control, and simple routing updates to host computers. There is also a Gateway-to-Gateway Protocol (GGP) that deals with internet management and routing updates for gateways. In the ISO, only the IP itself has so far been ----- (10) National Bureau of Standards, Specification of a Transport Protocol for Computer Communications, Vol. 3, Class 4 Protocol, ICST/HLNP-83-3, February 1983. National Research Council [Page 18] RFC 942 February 1985 Report Transport on Protocols considered, while most error reporting, control, and routing functions are considered "management" functions that remain to be addressed in the future. The only significant differences in the IPs themselves are in the areas of addressing and error reporting. The DOD IP has a fixed-length, 32-bit source and destination addresses (identifying network and host) plus an 8-bit "protocol number" field to identify the higher-level protocol for which the IP data is intended. The ISO IP has variable-length source and destination addresses whose format and content are not yet specified, although preliminary documentation indicates that ISO intends to support a similar level of addressing (network/host) in a more global context which would allow use of current DOD addresses as a subset. There is no equivalent of the DOD protocol number field, although possibly the tail of the variable-length ISO addresses could be used for this purpose. Error reporting is provided within the ISO IP by means of a separate packet type, while the DOD provides more complete error- and status-reporting functions via the separate Internet Control Message Protocol (ICMP), including routing "redirect" messages to hosts that have sent datagrams via nonoptimal routes. In summary, from the functional point of view, DOD and ISO IP can be considered essentially equivalent with the provision that the ISO-addressing scheme is suitably resolved. The absence of routing and control procedures from the ISO internet layer means that additional procedures beyond IP would be needed to produce a complete, functioning, internet even if the ISO IP were adopted. It appears that the existing DOD ICMP and GGP or its successors could be modified to operate with the ISO IP with modest effort, but this requires further study and validation in an operational system. A table at the end of this chapter compares DOD and ISO IP packet formats. COMPARISON ON THE BASIS OF PERFORMANCE, SECURITY, AND RISK Performance The performance of a transport protocol, such as TCP or TP-4, is a function of its implementation as well as its inherent design. Experience in implementing TCP and other proprietary protocols has demonstrated that implementation considerations usually dominate. This makes it difficult to compare protocols, since a wide range in efficiency of implementations is possible. Furthermore, there are a number of dimensions along which an implementation can be optimized. Despite the difficulties, protocol designers have developed several metrics for comparing transport protocols. These view protocol performance from a variety of perspectives, including (1) user response time, (2) throughput on a single connection, (3) network and host computer resource utilization. Protocol efficiency can also be National Research Council [Page 19] RFC 942 February 1985 Report Transport on Protocols significantly affected by the communications environment. Protocol efficiency must be considered in a wide range of communication environments, including local area networks, satellite links, terrestrial links, and packet-switched networks. The critical algorithms most affecting protocol performance are those that perform end-to-end error control and end-to-end flow control. These algorithms affect the response time, throughput, and resource utilization of the protocol during the data transfer phase. The efficiency of the connection management procedures may also be important in applications involving frequent connections of brief duration. The committee compared the algorithms and message formats specified for each protocol for critical functions, including flow-and error-control and connection management. They concluded that since the two protocols were sufficiently similar there would be no significant difference in performance of TCP or TP-4 implementations of equal quality optimized for a given environment. The committee compared the error-and-flow-control algorithms of TCP/IP and TP-4. Both employ window-based techniques using large-sequence number spaces and both permit large window sizes. Their differences are minor. TCP performs its error-and-flow-control in units of octets, rather than the protocol data units employed by TP-4. This adds a small amount of overhead to TCP calculation in return for a finer control over host buffer memory. The committee did not consider the difference significant, assuming that appropriate buffer management strategies are implemented by transport and higher-level protocols. TP-4 employs more sophisticated techniques to ensure that flow-control information is reliably transmitted than does TCP. These more sophisticated techniques may reduce TP-4 protocol overhead during periods of light load in some applications, possibly adding slightly more CPU load in other cases. The committee did not consider these effects significant. Both protocols employ a three-way handshake for establishing a transport connection. The differences between the TCP and TP-4 handshake are related to the addressing conventions employed for establishing connections and do not affect protocol efficiency. In the common cases where a client process requests a connection to a server process, the TCP and TP-4 operations are equivalent. Both protocols permit a range of policy decisions in their implementation. These include (1) selection of timer values used to recover from transmission errors and lost packets, (2) selection of window sizes at the receiver and transmitter, and (3) selection of protocol data unit sizes. Both permit substantial reduction in control message overhead by expanding window sizes. Both permit credits to be granted "optimistically," permitting receiver buffers to be shared over several transport connections and permitting credit reduction in the event of buffer congestion. Both permit optimizing protocol efficiency by delaying control message traffic when it does National Research Council [Page 20] RFC 942 February 1985 Report Transport on Protocols not need to be transmitted, combining it with later data or control traffic. The most significant difference between TCP and TP-4 flow control derives from slight differences in expression of flow control at the transport layer service interface. TCP employs a stream model while TP-4 uses a message model. These two models are equivalent in function; however, some higher-level applications protocols may be more naturally expressed in one model than the other. The committee considered the possibility that current ARPA protocols might require some adaptation to operate more efficiently with TP-4. For this reason the committee recommends that the DOD study the operation of current DOD higher-level protocols on TP-4 (recommendation 5, Chapter XI). Security The committee considered the impact of security requirements on transport protocols primarily and also on overall protocol hierarchies in the DOD, The American National Standards Institute (ANSI), and ISO. Based on the information the committee received, it finds that: The current TCP-4 and TP-4 are sufficiently equivalent in their security-related properties that no significant technical points would favor the use of one over the other. There is no technical impediment to their equivalent evolution over time in the security area. Risk There are several risks in implementing a new protocol or protocol family. These include (1) fatal flaws in protocol design not easily rectified, (2) errors in protocol specification, (3) ambiguities in protocol specification, (4) errors in protocol implementation, (5) performance degradation due to inefficient implementation, (6) performance degradation due to "untuned" implementation, and (7) performance degradation due to untuned application protocols. This list of risks comes from experience in implementing computer networks based on the DOD protocols and proprietary commercial protocols. Considering that it took more than ten years for the current TCP protocols to reach their current state of maturity and that the TP-4 protocol is only about two years old, the committee devoted considerable attention to the maturity of TP-4. Fatal Flaws in Protocol Design Early ARPANET protocols had a number of "fatal" design errors that resulted in deadlocks or other serious system failures. Commercial networks had similar problems in early design phases. The committee considered the possibility that TP-4 could suffer from similar faults and concluded that this was unlikely. TP-4 employs design techniques National Research Council [Page 21] RFC 942 February 1985 Report Transport on Protocols similar to those of TCP and proprietary transport protocols. The faults encountered in the ARPANET are now well known. Indeed, the state of the art in transport protocol design is now quite mature. The developers of the TP-4 protocol were familiar with the earlier protocols and their problems. Errors and Ambiguities in Protocol Specification Early in the development of TP-4, NBS developed a formal protocol specification and a test environment based on this specification. A protocol implementation can be partially compiled automatically from the formal specification. Other implementations can be tested against this master implementation. The NBS protocol laboratory was used to debug the formal specification of TP-4 and is currently being used to certify other implementations of TP-4. The laboratory has also developed and employed tools to analyze the specification for possible problems. The existence of this laboratory and the results obtained to date led the committee to conclude that there is no substantial risk associated with the TP-4 protocol specification. In contrast TCP has only recently received a formal specification. To the committee's knowledge most existing TCP implementations predate the formal TCP specification and have not been derived from the formal specification. In the committee's opinion the formal TCP specification is likely to have more bugs or ambiguities than the TP-4 specification. At the present time NBS has developed the only formal specification for ISO TP-4. ISO is currently developing standards for formal specification techniques that are similar to those used by NBS. When these specifications are complete ISO will update the TP-4 specification to include a formal description. In translating the current informal ISO specification into the formal specification there is a risk that the ISO specification may be changed such that it is no longer consistent with the current NBS specification. The National Bureau of Standards is playing a key role in developing the ISO formal specification techniques and formal specification. It plans to generate automatically an implementation of the ISO formal specification and verify it against the NBS specification using the NBS test tools. In the committee's opinion this makes the risk of unintentional changes in the ISO specification quite low. One possible risk remains. The ISO specification for TP-4 that was approved is an informal document subject to the ambiguities of informal protocol specifications. The formalization may remove ambiguities that have gone undetected and that were the basis of its approval. It is conceivable that once these ambiguities are exposed, the current consensus for TP-4 may dissolve. The committee considers this risk to be very low. The areas of ambiguity in protocol specifications are typically only of concern to protocol implementors. The current protocol implementors through much of the world are typically using the NBS formal specifications as a basis of their implementations of TP-4 and have access to the NBS test tools for National Research Council [Page 22] RFC 942 February 1985 Report Transport on Protocols certifying their implementations. In the event of a possible conflict, the majority of implementors could be expected to support resolution of ambiguities in favor of the current NBS formal specification, making it unlikely that ISO would approve an alternate resolution. Errors in Protocol Implementation Several factors influence the likelihood of errors in a protocol implementation. These include the complexity of the protocol, quality of the protocol specification, the experience of the implementors, and the availability of test tools. Based on the availability of the NBS test tools and formal protocol specification for TP-4, the committee did not see any significant risk of errors in implementing TP-4. Performance Issues The largest risk in implementing TP-4 concerns the performance of the implementations. This risk is not inherent in the protocol as specified, but is present in new implementations of any transport protocol. Experience has shown that performance can often be improved by a factor of two or more by careful attention to implementation details and careful performance measurement and tuning. The committee considered it likely that some initial implementations of TP-4 will have significantly lower performance than the current mature implementations of TCP. Evidence to support this conclusion may be found in data supplied by the DOD which show a wide range of performance of TCP implementations. Some members of the committee expressed the belief that over the long term, TP-4 will afford better performance due to widespread commercial support. Vendors will be highly motivated to optimize performance of their TP-4 implementations, since a large number of users will benchmark implementation performance. Many individuals will become familiar with implementations of TP-4 and with configuring and operating networks based on TP-4. Initially, this expertise will be found in organizations developing TP-4 implementations and installation. The committee believes that the largest performance risks are short term. The performance of existing DOD high-level protocols may be affected by subtle differences between TP-4 and TCP interfaces. Highlevel DOD implementations and protocols may require retuning to attain some high-level efficiency using TP-4. Another short-term risk is potential lack of experience in configuring and operating TP-4-based networks. The committee believes that a program of testing and development would minimize these risks, ensuring that the current high-level DOD protocols run effectively on TP-4-based networks. There is a possibility that the equivalent, but different, protocol mechanisms and interfaces in TP-4 may manifest some undesirable behavior that is not expected and which cannot easily be removed by tuning. In this event ISO may find it necessary to make some National Research Council [Page 23] RFC 942 February 1985 Report Transport on Protocols modifications to TP-4. It is unlikely that such problems will be serious enough to prevent an early transition to TP-4. If such problems are discovered, it is expected that they can be handled through the normal standards process of periodic enhancement. A number of proprietary commercial networking protocols are similar in operation to TP-4 and do not have serious performance problems. Any enhancements that may be desirable can probably be added to TP-4 in a compatible fashion, permitting interoperation of enhanced and unenhanced implementations. TABLE: Comparison of DOD and ISO IP Packet Formats DOD ISO (not in correct order) ---------------------------------------------------------------------- Protocol version: 4 bits Version: 8 bits Header Length (in 32-bit words): [Header] Length (in bytes): 8 bits 4 bits Type of service: 8 bits Quality of service**: 8 bits (includes 3-bit Precedence) Precedence**: 8 bits Total Length: 16 bits Segment Length: 16 bits ID: 16 bits Data Unit ID*: 16 bits Don't Fragment flag Segmentation Permitted flag More Fragments flag More Segments flag Fragment offset: 13 bits Segment offset*: 16 bits Time to live (sec): 8 bits Lifetime (.5 sec): 8 bits Protocol number: 8 bits --- Header checksum: 16 bits Header checksum: 16 bits (provided by subnet layer) Network Layer Protocol ID: 8 bits --- [Generate] Error flag (in ICMP) Type: 5 bits --- Total Length*: 16 bits ............. ............. Source address: 32 bits Source address length: 8 bits Source address: var. Dest. address: 32 bits Dest. address length: 8 bits Dest. address: var. ............. ............. OPTIONS: NOP, Security, OPTIONS: Padding, Security Source Route, Record Route, Source Route, Record Route, Stream ID, Time Stamp Quality of service, Precedence, Error reason (only for error type) ............. ............. DATA DATA ...................................................................... * only present if segmentation is in use ** in options National Research Council [Page 24] RFC 942 February 1985 Report Transport on Protocols IV. STATUS OF DOD AND ISO PROTOCOL IMPLEMENTATIONS AND SPECIFICATIONS DEPARTMENT OF DEFENSE The DOD internetting protocol was first introduced in 1974 and later split into separate TCP and IP specifications. From 1974 until 1978, when they were adopted as DOD standards, the protocols underwent a number of major revisions. These revisions were largely a result of extensive experience gained by researchers working on the DARPA Internet project. The DARPA "Request for Comment" and "Internet Experimental Note" technical report series document the conclusions of numerous protocol-related studies and discussions. Successive specifications of TCP and other internet protocols are also given by reports in these series. Most of these specifications were informally presented and were accompanied by discussions that affected design choices. The most recent TCP documents introduce a more formal style of presentation (11). The first experimental TCP implementations were completed in 1974 at Stanford University and Bolt Beranek and Newman, Inc., for the PDP-11/ELF and DEC-10/TENEX systems, respectively. Today implementation exists for numerous computer systems. While many of these were implemented at and are supported by university and other research groups, several are available as commercial products. Testing of TCP was done on the ARPANET (12), other DOD networks (Satellite net, packet radio), and a variety of local networks. For several years a number of DARPA contractors used TCP in parallel with the old ARPANET transport protocol (NCP). In addition, for about six months preceding the January 1, l983, ARPANET cutover from NCP to TCP, these hosts were joined by additional TCP-only hosts (for a total of approximately thirty). This extensive testing prior to the cutover to TCP enabled the networks involved to maintain operational capability throughout ----- (11) Transport Control Protocol, DOD MIL-STD-1778, August 1983. (12) The ARPANET is a data communications network established in 1969 by the DOD's Advanced Research Projects Agency to interconnect the computer resources at selected research centers at substantially lower costs than systems then available. The ARPANET is a fully operational 80-node network that interconnects over 200 host computers in the United States, the United Kingdom, and Norway. ARPA became the Defense Advanced Research Projects Agency (DARPA) in 1973. National Research Council [Page 25] RFC 942 February 1985 Report Transport on Protocols the transition and to achieve normal service levels in a few months. Today the TCP-based DOD networks includes hundreds of hosts (over 300 on DDN alone) and serves thousands of users. Traffic on just the ARPANET component is now approximately 500 million packets per month. TCP is also extensively used on local area networks including Ethernet and Pronet, as well as on CSNET, the Computer Science Research Network (Telenet hosts). In addition to TCP, the DOD protocol architecture includes internet layer protocols for communication between hosts and gateways (ICMP) and between gateways (GGP). Experience indicates that the design of robust and powerful gateways that internet numerous networks and provide survivability is a complex challenge. DOD is developing new gateway protocols that could be adapted to work with either DOD's or ISO's IP. The higher-level protocols currently used on DDN for electronic mail (Simple Mail Transfer Protocol), file transfer (File Transfer Protocol), and remote log-in (Telnet) are TCP-specific. Their specifications are stable, and numerous implementations exist. The DOD has indicated its intent to adopt ISO higher-level protocols when they are specified and implementations are available. The committee has concluded that the DOD transport and internet protocols are well tested and robust. It is unlikely that major problems with their design or specifications will be uncovered. No comprehensive facility or procedures for testing new implementations of TCP now exist, although efforts in this area are being started at Defense Communications Agency (DCA). INTERNATIONAL STANDARDS ORGANIZATION Standardization and development of the ISO IP and ISO TP-4 are proceeding in a relatively independent fashion. Currently, TP-4 is further along in the standardization process. The local area network communications environment has created an immediate need for TP-4 functions; however, communications within a single Local Area Network (LAN) do not need an internet capability. A "null" IP has been defined to enable TP-4 to be used on a single LAN without the necessity of a complete IP. It is quite likely that some early TP-4 products will implement this null IP, leaving implementation of the complete IP for future product development. In the following discussion, TP-4 and IP will be treated separately due to this potential independence. TP-4 Status and Plans The ISO TP-4 became a Draft International Standard in September 1983. The final stages in standardization are primarily procedural. The committee expects products that implement TP-4 to be widely available in the market within about two years. It normally takes twelve to eighteen months for implementations and testing prior to product announcement. Some vendors apparently began implementation and testing the protocol National Research Council [Page 26] RFC 942 February 1985 Report Transport on Protocols soon after it became a draft proposal in June 1982, because the protocol was essentially frozen at that time. At present, INTEL and Able Computer have announced the availability of products that implement TP-4 for use over LANs. The committee does not know, however, whether these products have been delivered or incorporated into systems. In addition, more than twenty companies have indicated their support of TP-4 and their intention to incorporate TP-4 into future products, without announcing specific products or availability dates. Most companies do not make specific product announcements until relatively late in the product development process. In December 1982 six vendors and network users interested in early development of TP-4 products requested NBS to hold a series of workshops on the operation of TP-4 in a LAN environment. To date, four workshops have been held, with more than thirty companies in attendance. The first workshop set a goal of demonstrating multivendor networking at a major U.S. national computer conference. The second workshop, held in April 1983, determined that demonstrations would include a file transfer application and would be developed on two local area network technologies currently standardized by the Institute of Electrical and Electronics Engineers (IEEE). These technologies are the Carrier Sense Multiple Access with Collision Detection, which is standardized by IEEE committee 802.3, and the Token Bus, which is standardized by IEEE committee 803.4. The workshop selected the National Computer Conference in July 1984 for the demonstrations. Vendors committed to the demonstration developed and tested TP-4 implementations using the NBS test tools. The workshops defined a schedule that called for individual testing through April 1984 with multivendor testing commencing thereafter. While the vendors that participated in the demonstration have emphasized that participation in the demonstration is not a commitment to product development, a number of large customers have indicated that there will be an immediate market demand for TP-4 implementation as soon after the demonstration as practical. The committee considers it highly likely that many commercial vendors will announce commitments to deliver TP-4 products shortly after the demonstration. Internetwork Protocol Status and Plans The ISO Internetwork Protocol (IP) became a Draft International Standard (DIS) in May 1984 (13). The DIS was out for ballot for the previous eight months. Attaining DIS status freezes the technical approach, permitting implementations to begin. ----- (13) ISO Draft Proposal, Information Processing Systems -- Data Communications -- Protocol for Providing Connectionless Network Services, DP 8473, May 1984. National Research Council [Page 27] RFC 942 February 1985 Report Transport on Protocols The ISO IP specification is only one of several specifications needed to completely specify the Network Layer. A number of other specifications are needed, including a Gateway-to-Host error protocol, a network wide addressing plan, and a Gateway-to-Gateway Protocol for managing routing information. A complete specification is needed before an internetwork, consisting of gateways and hosts, can be deployed. Most of the complexity of the Network Layer, however, is confined to the gateways. A complete standardization of the Network Layer is not required to develop and deploy host systems. The International Standards Organization is currently developing proposals for conveying error information between hosts and gateways. It is expected that responses to the Draft Proposal by ISO members will include proposals to provide these functions. The committee does not consider this a controversial area and expects that these capabilities will be included in the ISO standard by the time it reaches Draft International Status. Addressing is a more complex issue. The addressing structure of a computer internetwork depends on complex trade-offs between implementation complexity, flexibility, network cost, and network robustness. Addressing structure in a large network can influence the range of possible policy decisions available for routing network traffic. The trade-offs for a military environment may be significantly different from those of a commercial environment. The ISO has considered these factors in its existing IP. A flexible addressing scheme is provided, permitting implementation of a variety of addressing structures. Host computers need not be concerned with the internal structure of addresses. The committee considers that the IP-addressing scheme has sufficient flexibility that host implementations can be constructed that will support the full range of addressing philosophies allowed by ISO, including those needed by DOD. Routing algorithms, like addressing, are complex and often controversial. For this reason ISO has not yet attempted standardization of routing algorithms. A routing algorithm is a key part of a Gateway-to-Gateway Protocol. A single network must implement a common routing algorithm. In the absence of an ISO routing algorithm, a network must be based on either proprietary routing algorithms or on other standards. The committee has studied the current ISO IP and the current ISO addressing structure. It believes that it will be possible to map the current DOD IP-addressing structure and routing algorithm into the ISO network layer. In practice this means that the Gateway-to-Host Protocols and addressing formats will fully comply with the ISO standards, while gateways will need to include additional DOD capabilities. (This is addressed in recommendations, section IX.) This approach will enable DOD to procure commercial host implementations, while retaining the need for procuring DOD-specific gateways. The committee believes these hybrid DOD-ISO gateways can be readily developed by modifying existing DOD gateway implementations. Since the majority of systems in a network are hosts and not gateways, National Research Council [Page 28] RFC 942 February 1985 Report Transport on Protocols the committee considers this approach worthwhile. To the committee's knowledge no vendor has yet announced plans to support the ISO Internetwork Protocol. This is not surprising, since the ISO IP attained Draft Proposal status only recently. The committee has considered the possibility that the ISO IP may not attain the same wide level of market demand and vendor support anticipated by TP-4. Since host support of IP is necessary for DOD to migrate to ISO protocols, the committee has considered this question in some depth. While it is possible to operate TP-4 directly over a LAN or directly over an X.25-based, wide-area network, some form of internetwork capability or alternative approach is needed to interconnect systems attached to multiple LANs via Wide Area Networks (WANs). In the current ISO open systems architecture, this function is to be provided by the Network layer. There are two possible Network layer services, connectionless and connection oriented. The ISO architecture permits both of these services, leaving it to the market place to determine which approach is to be selected. The DOD believes that the connectionless approach best suits their needs. Developing a connection-oriented network that operates over a mixed LAN and WAN environment is considerably more difficult than developing a connectionless one. Existing LANs are inherently connectionless and existing (X.25) WANs are inherently connection oriented. A protocol to provide internetwork service between these LANs must arrive at a common subnetwork capability. It is a relatively simple matter to adapt a connection-oriented to a connectionless service since it can be done by ignoring unneeded functions of the connection-oriented service. Adapting a connectionless subnetwork to the needs of a connection-oriented network service is much more difficult. Many of the functions provided by TP-4 would be needed in the network layer to build such a service. Some work is currently going on in European Computer Manufacturer's Association (ECMA) to interconnect WANs and LANs in a connection-oriented fashion. There is considerable controversy surrounding several proposals, since some participants in the standards process do not believe the proposals conform to the ISO Reference Model for Open Systems Interconnection. This, plus their complexity, makes it unlikely that a connection-oriented network standard will gain support in ISO in the immediate future. There is an immediate need for users to build networks consisting of interconnected LANs and WANs. Such networks are currently in place using vendor proprietary architectures. Market pressures to build multivendor LAN and WAN networks make it quite likely that vendors will adopt the immediate solution and implement the connectionless ISO IP. The committee believes that DOD can enhance the early availability of ISO IP by announcing its intention to use it. Commercial availability of IP is an important part of a migration strategy, as described in the section on recommendations. The National Research Council [Page 29] RFC 942 February 1985 Report Transport on Protocols committee believes that vendors would be responsive to DOD requests for IP, since IP is quite simple to implement in comparison with TP-4 and since they foresee the need to operate in mixed LAN-WAN environments. National Research Council [Page 30] RFC 942 February 1985 Report Transport on Protocols V. MARKETS The committee reviewed the market demand and its potential with respect to both TCP and TP-4 to provide an indication of the likelihood and rapidity with which competition and its benefits will develop. The committee concludes that the market demand for TCP protocols will be small outside the United States. The demand for TP-4, on the other hand, is expected to be worldwide. In this report we use the term market demand to indicate the potential or actual demand for products using the protocols under discussion. A large market is characterized by a broad demand from all sectors of the marketplace: consumers, businesses, and governments. The broadest demand is an international demand in all sectors. We distinguish the demand for products from the supply that usually develops as a result of the demand. It is assumed here that a broad market demand will result in a broad range of products, competitive in price, quality, function, and performance. The demand for products implementing computer communication protocols is discussed in relation to the requirements placed on the potential customer. Specifically, the customer may be required to acquire products that meet one or the other of the standards under discussion or may have no obligation to use either of the two. That is, customers will fall into one of the following classes with respect to these standards: 1. DOD standards required. 2. International or National standards required. 3. No requirement with respect to standards. Although customers in the third class may be under no formal obligation to use standards, they may still prefer a standard solution for several possible real or perceived benefits. They may, for example, obtain a broader selection of products using the standard solution or may obtain a more competitive price. They may also require a specific communication protocol in order to share information with products that are required by fiat to implement certain standard protocols. This need for compatible protocols to communicate is a powerful driving force toward communication standards. DEPARTMENT OF DEFENSE NETWORKS MARKET STATUS AND PLANS The major networks of the Defense Data Network include the following: National Research Council [Page 31] RFC 942 February 1985 Report Transport on Protocols Military Network (MILNET)--operational and growing. Advanced Research Projects Agency Network (ARPANET)--operational and growing. WWMCCS Intercomputer Network (WIN)--to be upgraded. DOD Intelligence Information System (DODIIS)--to be upgraded. Strategic Air Command Digital Information Network (SACDIN)--to be upgraded. Movement Information Network (MINET)--to be established in 1984. Sensitive Compartmented Information (SCI) net--to be established in 1985. TOP SECRET (TS) net--to be established in 1985. SECRET net--to be established in 1986. Initially, each of these networks has its own backbone. The networks will be integrated into a common Defense Data Network in a series of phases starting in 1984 with the integration of MILNET and MINET. It is planned that by 1988 they will all be integrated but communities of interest will operate at different security classifications interconnected with Internet Private Line Interfaces (IPLIs). When appropriate technology becomes available in the late 1980s, the network will have the capability for multilevel security, including end-to-end encryption, and will achieve interoperability between all users. The following observations are relevant to the TCP and TP-4 issue: The DOD currently has two major networks, MILNET and ARPANET, currently comprising the DDN. About sixty subnets and hundreds of hosts are internetted and most use TCP. This year a European network, MINET, will be activated and integrated into the DDN. It uses TCP. In the second half of 1983, fifteen additional subscribers have been added to MILNET and current planning estimates hundreds more additional subscribers in 1984 and 1985. For the many DDN users that are, or shortly will be, interconnected over common backbones, there are groups of users that need interoperability within the group. These groups are determined by the military department they are part of as well as by functions such as logistics, maintenance, training, and many others. The Air Force and the Army are both committed to the use of TCP for some of their networks or subnetworks (including Local Area National Research Council [Page 32] RFC 942 February 1985 Report Transport on Protocols Networks) and active acquisition programs are underway, or will be initiated, during the next twelve to eighteen months. The DDN Program Office has procured, or shortly will procure, devices to facilitate terminal and host access to DDN hosts and terminals. These devices employ TCP. NATO has discussed protocol standards and has selected ISO as an approach, subject to its being adapted to meet military requirements, if such adaptation is necessary. There is no definitive planning underway, however, to develop a NATO computer network. The Mail Bridge that will allow traffic to pass between the classified segment and the unclassified segment will use TCP and is scheduled for a 1987 Initial Operational Capability (IOC). In general, the backbone in the various networks provides functions at layers below TCP and TP-4. As a result a backbone (such as MILNET) could support users of either protocol set. The users of one set could not, however, interoperate with the users of another unless additional steps are taken. In summary, there is a large TCP community operational today and the community is growing rapidly. In addition, there are, or shortly will be, procurements underway that plan to use TCP. The rate of growth cannot be precisely estimated in part because of uncertainties in demand and availability of trunks and cryptographic equipment. On the other hand, interconnection of several major networks will not take place until 1987 or later; and for those elements that are interconnected, there are many groups of users that primarily require interoperability with each other. System Descriptions MILNET is a network for handling the unclassified operational data of the DOD. It was created after the decision in 1982 to cancel the AUTODIN II system by dividing the ARPANET into two nets, MILNET and ARPA Research Net. The majority of the capacity of ARPANET was assigned to MILNET, and the number of subscribers is growing rapidly. The network backbone does not require the use of TCP but its use is generally mandated for subscribers. To achieve TCP functions, the DDN will procure some interface devices and thereby take the burden off some subscribers. ARPANET supports most of the research organizations sponsored by DARPA. It generally uses TCP but some users continue to use NCP. MINET is a European network scheduled for Initial Operational Capability (IOC) in 1984 to handle unclassified operational traffic, mostly logistical, and tie into the MILNET. It will have 8 nodes, 8 TACs, and 3 hosts to process electronic mail. These hosts and others to be added to the net will use TCP and the File Transfer Protocol (FTP). National Research Council [Page 33] RFC 942 February 1985 Report Transport on Protocols The Department of Defense Intelligence Information System currently uses a home-grown protocol. Sometime after 1984 its plans are to upgrade it to TCP.