Click for next page ( 26


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 25
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 197S, 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" techni- cal 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 post recent TCP documents introduce a more formal style of presentation.~' The first experimental TCP implementations were completed in 1974 at Stanford University and Bolt Beranek and Newman, Inc., for the PDP-~/ELF and DEC-lO/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,]2 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, 1983, ARPANET cutover from NCP to TCP, these hosts were joined by additional TCP-only hosts (for a total of approxi- mately thirty). This extensive testing prior to the cutover to TCP en- abled the networks involved to maintain operational capability throughout ]iTransport Control Protocol, DOD MIL-STD-1778, August 1983. 12The 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 BO-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.

OCR for page 25
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 DON aJone) and serves thousands of users. Traffic on just the ARPANET component is now approximately 500 million packets per month. TOP 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 TOP, 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 surviv- abiiity 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 DON 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 impl ementat i ons are avai l ah l e. The committee has concluded that the DOD transport and internet pro- tocols 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 TOP now exist, although efforts in this area are being started at Defense Communications Agency (DCA). INTERNATIONAL STANDARDS ORGANI ZATI ON Standardization and development of the ISO IP and ISO TP-4 are pro- ceedinq in a relatively independent fashion. Currently, TP-4 is further along in the standardization process. The local area network communica- tions environment has created an immediate need for TP-4 functions; how- ever, 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 commit- tee 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 - 26 -

OCR for page 25
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 incorpo- rated into systems. In addition, more than twenty companies have indi- cated 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 dates 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 appli- cation and would be developed on two local area network technologies cur- rently standardized by the Institute _ ~ _ ~ neers (lEEE). These technologies are the Carrier Sense Multiple Access with Collision Detection, which is standardized by {EKE 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. of F1 ~ntrica1 and E] ectronics Enai- Vendors committed to the demonstration developed and tested TP-4 im- plementations 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 im- plementation as soon after the demonstration as prac- tical. The commit- tee 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 Protocal (IF) became a Draft International Stan- dard (DIS) in May 1984.~3 The DIS was out for ballot for the previous eight months. Attaining DIS status freezes the technical approach, permitting implementations to begin. ~3Iso Draft Proposal, Information Processing Systems ---Data Communications -- Protocol for Providing Connectionless-Network Services, DP 8473, May 1984. - 27 -

OCR for page 25
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 networkwide 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 pro- posals 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 bill be included in the 150 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 com- mercial 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 con- cerned with the internal structure of addresses. The committee considers that the IP-addressing scheme has sufficient flexibility that host imple- mentations can be constructed that will support the full range of address- ing philosophies allowed by ISO, including those needed by DOD. Routing algorithms, like addressing, are complex and often controver- sial. 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 ~X.) 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, the committee considers this approach worthwhile. - 28 -

OCR for page 25
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 capabil- ity or alternative approach is needed to interconnect systems attached to multiple LANs via Wide Area Networks (WANs). In the current ISO open sys- tems architecture, this function is to be provided by the Network layer. There are two possible Network layer services, connectionless and connec- tion 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 con- nection-oriented to a connectionless service since it can be done by ig- noring 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 propo- sals conform to the ISO Reference Mode] 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 im- mediate solution and implement the connectionless ISO IP. The committee believes that DOD can enhance the early availability of ISO IP by announ- cing its intention to use it. Commercial availability of IP is an impor- tant part of a migration strategy, as described in the section on recom- mendations. The 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. - 29 -

OCR for page 25