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

  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

   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.

               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.

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

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.

  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.

  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.

 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.

 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

  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

  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

  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

  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

  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

 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.

 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

  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.

  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,

  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

  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.

                              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:

  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

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

  The Department of Defense Intelligence Information System currently
  uses a home-grown protocol.  Sometime after 1984 its plans are to
  upgrade it to TCP.  It will be a 3-node, 3-host net with plans to
  upgrade it to 20 to 30 nodes and about 50 hosts.  The net is run at a
  high-security level (SCI) for communicating compartmented data.  The
  SCI network consists of those users of SCI who are outside of DODIIS.

  SACDIN is an upgrade of the digital communications system of the
  Strategic Air Command.  The IOC is planned for about 1985.  At
  present, TCP is not planned initially as a protocol.  SACDIN will
  operate with multilevel security up to Top Secret sensitive
  information.

  WIN is the WWMCCS Information Network.  It is currently operational
  and uses NCP as a transport protocol. There is a major effort underway
  to modernize the WWMCCS, including upgrading or replacing current
  computers, providing Local Area Networks at major centers throughout
  the world, and providing common software packages for utilities and
  some applications. The upgrading of the transport protocols is part of
  this effort.  Schedules are still uncertain but there is a target of
  1986 for the protocol upgrading.

  TOP SECRET is a network that will support top secret users other than
  WIN and SACDIN.

  SECRET net is a network that will operate at the Secret level.  It
  should be very useful for a large community that does not routinely
  need top secret or compartmented information.  This is a community
  primarily outside the command and intelligence communities and
  includes missions such as logistics, procurement, and research and
  development.  DOD will start the system as soon as there is sufficient
  cryptographic equipment; by 1986 they hope to have a 90-node network
  with several hundred subscribers.

  The Army plans to establish a Headquarters Net tying together major
  headquarters with an IOC of 1986.  It will use TCP.

  The Air Force has established a Program Office to help in the
  development of Local Area Networks at major Air Force installations.
  These could be internetted using the DDN and thereby also gain access
  to other nodes. TCP has been mandated.  Initial procurements are
  underway.

  Mail Bridge will provide gateways between ARPA Research Net and other
  elements of the DDN.  These would use TCP and are scheduled for IOC in
  1987.

  During 1984 the DDN is procuring two capabilities that will facilitate
  use of the network and higher-level protocols.

  The first capability will be provided shortly by Network Access
  Controllers (NAC).  The NACs provide three elements all based on TCP:

   1.   Terminal Access Controllers (TACs) allow a cluster of terminals
        to access hosts on the DDN.  Many are in operation today as a
        legacy of the ARPANET developments.  New ones will be
        competitively procured.

   2.   Terminal Emulation Processes (TEP) allow the connection of a
        high-capacity host to the DDN through a number of terminal-like
        lines.

   3.   Host Front-End Processors (HFP) allow high-capacity host
        connection to the DDN through use of a Network Front End that
        off loads much processing capacity from the host.

  The second capability will be provided by software the DDN is
  currently procuring for up to seventeen families of specific
  combinations of hosts and their commercially available operating
  systems.  The software packages will include 1822 or X.25, TCP, and
  utility protocols for terminal access, mail, and file transfer.
  Initial operational capability is planned for late 1985.

 Integration

  MINET will be connected to MILNET in 1984.  This will be an
  unclassified network.

  WIN, DODIIS, SECRET, and SACDIN will be integrated as a classified
  network in 1987 at the earliest.  Since they all operate at different
  security levels, they will be able to use the same DDN backbone but
  will be cryptologically isolated.

  Integration and interoperability of all the networks will not be
  possible until the late 1980s at the earliest, since this will require
  successful implementation of an advanced technology for end-to-end
  cryptological networking and the development of techniques for
  multilevel security in individual and netted computer systems.

  The use of gateways as elements to integrate networks is under
  consideration.  Gateways are currently operational to interconnect
  MILNET with (l) ARPANET (six gateways primarily used to exchange mail
  between authorized users), (2) MINET (one gateway for use prior to
  integration of the two networks into one), and (3) eight
  developmentally oriented networks. There are many more gateways
  internetting ARPANET with other research nets.  Most of these gateways
  use the ARPA-developed Gateway-to-Gateway Protocol.  It is now
  realized that this protocol is deficient for widespread use and ARPA
  has been investigating alternatives.

  The earliest requirement for additional gateways in the operational
  elements of the DDN will be to internet Local Area Networks into
  global networks of the DDN.  A new "stub" protocol has been developed
  that might meet this need.  The DDN is reviewing its requirements for
  available gateways and approaches.

INTERNATIONAL AND NATIONAL STANDARD MARKET DEMAND FOR TP-4

 In the United States and most countries of the world, national
 standards organizations adopt international data communication
 standards.

 In the United States the standards for the transport protocols are
 established by the American National Standards Institute (ANSI).  The
 same standards for the federal sector are established by the NBS with
 an exception for DOD's military needs which may be established by MIL
 standards. Market demand for the latter was previously discussed.

 Outside the DOD there are numerous government agencies and
 organizations such as the Federal Aviation Agency, Internal Revenue
 Service, the Federal Bureau of Investigation, and the Federal Reserve
 Banks which have, or will have, networks that fall under the guidance
 of the NBS and will probably use the NBS-specified standard protocols
 when the NBS standard is issued.  Already the Federal Reserve is
 procuring its computer networking products using the X.25 protocol.

 National Support of International Standards

  The earliest evidence of demand for TP-4 products is in countries that
  give strong support for ISO standards.  Most countries outside of the
  United States give the international standards much stronger
  governmental support than the United States does for a variety of
  reasons. First, in most cases these governments own the postal and
  telecommunication monopolies.  Frequently, the responsibility for
  these organizations is at a ministerial level in the government.
  Furthermore, many of the modern countries have concluded that the
  information industry is a national resource and one of the growth
  industries of the future.  International standards that are neutral,
  in the sense that no manufacturer has a head start, give the companies
  in these countries the additional margin they feel is necessary to
  compete in the worldwide market.  It is also recognized by many that a
  worldwide market is much better than a market demand fragmented by
  national geographic and political considerations. Finally, the PTTs
  have traditionally provided information services equivalent to those
  for which some of the ISO computer communication protocols are
  designed.  The best example is Teletext, which is an upgraded version
  of the Telex system used widely outside the United States.

  Consequently, government networks in many countries use the
  international ISO standards or the national standards derived from the
  international standards.  Bid requests for government networks in
  France and Germany, for example, have required support for ISO
  protocols for over a year even though the standards are not yet fully
  approved.  These bids ask the respondent only to state support for the
  protocols.  No doubt, as the ISO protocols become stable, these
  countries will require the protocols for their networks.  These
  government networks will further influence the implementation of
  networks not actually required to use the international and national
  standards.

MARKET SEGMENTS NOT REQUIRED TO USE TCP OR TP-4

 Most of the demand for communication protocols comes from potential
 customers who are under no government fiat to use either TCP or TP-4
 protocols in their networks or network products.  Many of these will
 use existing supplier-specified protocols.  Such protocols have been
 embedded in products for over ten years and are well tested both
 formally and through field experience in thousands of networks.
 Continuing demand for these protocols will not contribute to the
 relative demand for either TCP or TP-4.

 There are widely recognized advantages in using international standard
 protocols for computer communications.  First, there is tremendous
 value in exchanging information with other information users.  As the
 standard protocols become widely used, the value of the information
 accessible through networks using these protocols is normally greater
 than the value of information accessible through less widely used
 networks protocols. This is the reason that industry groups such as
 airlines, banks, and insurance companies band together to set up common
 networks.  Similarly, it is recognized that there are economies of
 scale for widely used networking protocols both in the sense that
 equipment can be obtained at lower cost and in the sense that the
 manufacturer's improvements in performance, function, and cost will be
 repaid by market demand.  In addition, many network protocol users wish
 to have the option to procure equipment from a wide variety of vendors.
 Sometimes international standards encourage this environment.  Finally,
 international organizations would prefer to have common procurement of
 equipment and software for worldwide operations.  Thus international
 standards are preferred for operational as well as logistic
 considerations.

 In the United States much of the demand for TP-4 will develop in the
 industries that exchange information regularly with entities of the
 federal government.  If the Federal Reserve were to use the TP-4
 standard for exchanging information with member banks, for example,
 there would be pressure on the banks to use TP-4.  Similarly, if DOD
 suppliers wish to have easy access to DOD employees using a system
 based on TCP, they would need to use TCP.  Also many of the
 university-oriented networks use the ARPANET protocols to exchange
 information with other university ARPANET users.

 The committee concludes that the demand for TP-4 in the United States
 will significantly out weigh the demand for TCP independent of DOD's
 adoption of TP-4.  If DOD adopts the ISO TP-4 immediately or if DOD
 adopts TP-4 after a demonstration, the U.S. market demand for TCP
 protocols will disappear as the current networks are converted to TP-4.
 If DOD chooses to use the DOD TCP indefinitely, clearly the DOD and
 ARPANET demand for TCP will continue.

 A similar set of market forces operates outside the United States
 except that the foreign governments are more strongly in favor of
 international and national standards and have smaller investments in
 nonstandard equipment.  Thus there are even more industries drawn to

 the standards in order to share information.  This is illustrated by
 the extremely strong support for ISO efforts.  The European Computer
 Manufacturers Association has been active in the TP-4 standardization
 effort.  NATO appears committed to TP-4 implementations, and there is
 likely to be intense competition in this arena.  Lacking the federal
 government support of two different protocol suites, there is a
 stronger force to adopt a single international standard in most
 countries.  There are other countries with a similar problem, however.
 Germany is beginning to install systems based on its unique national
 standard but has committed to convert eventually to ISO protocols.

 The committee concludes that there will be little market demand for the
 TCP protocols outside the United States.  The strong international
 demand will be for ISO protocols, including TP-4.

   VI.  DEVELOPMENT OF STANDARD COMMERCIAL VERSUS SPECIAL COMMERCIAL
PRODUCTS

DOD has expressed a desire to use off-the-shelf commercial products
because they are expected to be less costly.  It is expected that
performance of commercial products will be optimized to increase
competitiveness. User cost will be lower because of a large commercial
customer base over which to amortize costs for development, continuous
improvements, and maintenance.  Furthermore, the DOD may benefit from
having more vendors compete for their business.  This section examines
the way vendors select standard products for development and the
implications in cost, continuing supports, and improvements.

PRODUCT DEVELOPMENT VERSUS SYSTEM INTEGRATION

 It is assumed in this discussion that off-the-shelf commercial products
 can be used through system integration to construct system solutions.
 Most vendors supply both standard products and system integration
 services.  Some vendors supply only the integration functions, using
 other vendors' products.  System integration adds value to the product
 and in some cases results in modifications of the product to meet
 system requirements. When standard products are used, the
 responsibility for continuing maintenance and improvements almost
 always can be passed to the product developer.  Thus in this discussion
 we assume that off-the-shelf commercial products are standard products
 supplied by vendors to implement one or more transport-level protocols
 for the DOD.

CRITERIA FOR SELECTION OF STANDARD PRODUCTS

 The product vendor's choice to develop a standard product is governed
 by market requirements, economic opportunities, and other design
 considerations. In the case of data transmission products, market
 requirements include competition, connection to the installed base of
 products, market growth, and satisfaction of the standards requirements
 of customers.

 Often the vendor will develop a product that supports several protocols
 as options.  Usually only one or two protocols will be selected for
 primary support, and all other options are considered for secondary
 support. The primary protocols selected for implementation are based
 upon the largest potential market for the vendor.  These protocols
 become the vendor's standard products.  Standard products are announced
 for sale and supported on a continuing basis.  Implementations of
 secondary protocols are often adaptations of the implementations of
 standard protocols and may be suboptimal with respect to performance
 and continuing vendor support. Often secondary implementations are
 created when an RFP is issued and the vendor who wishes to respond to
 the RFP must create a special product to do so.  This committee
 believes that, in general, future standard data transmission products
 will be either TP-4 or vendor-unique protocols and TCP will be a
 special product.