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 26
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 27
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 28
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 29
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 30
Representative terms from entire chapter:
iso internetwork
