sets. This will include dual protocol operation for some gateways,
relay hosts, service hosts, and terminal concentrators. A secondary
purpose of the test system described in detailed recommendation 3
should be to aid in development of this transition support equipment.
Both a general transition strategy and specific transition plans for
each existing system should be developed. The switchover from old to
new protocols will take place at different times as appropriate for
each system during an overall transition period of many years.
(3). As soon as possible, the DOD should develop a protocol test
facility. If Option 1 is followed, this facility would serve primarily
to validate implementations of both old and new protocol sets. If
Option 2 is followed, the facility would initially focus on
demonstrating the suitability of the new protocols for use in a
military environment as rapidly as possible and then provide for
testing of commercially supplied protocol implementations.
For validation purposes, the NBS protocol-testing facility developed
for ISO protocols should serve as a good basis, but extensions to deal
with any DOD-specific option for the ISO protocols, performance, and
DOD protocols would be necessary. DOD is now beginning such a program.
National Research Council [Page 62]
RFC942 February 1985
Report Transport on Protocols
For a more complete demonstration, commercial-quality implementations
of the ISO protocols must be obtained and shown to support military
applications in an operational subnetwork such as such as ARPANET or
DODIIS. In both cases the facility should also be used for development
and demonstration of the transition support equipment mentioned in
detailed recommendation 2.
(4). Procurements of new networks and major upgrades of existing
networks should favor use of ISO TP-4 as rapidly as possible. If
Option 1 is followed, RFPs may specify the new protocols immediately.
If Option 2 is followed, this must await successful completion of the
demonstration discussed in recommendation 3. Procurements for existing
networks using TCP may continue to require TCP-based equipment until an
appropriate conversion point is reached (see detailed recommendation
2).
The purpose of this recommendation is to minimize spending on new TCP
implementations and their subsequent conversion to TP-4 where possible,
while recognizing that some additions to TCP-based systems will also be
needed. If Option 2 is followed, immediate requirements for new
systems may force new implementations of TCP in these cases also
because the demonstration is not completed at the time RFPs must be
issued.
(5). As part of a transition plan, a transport service interface to
higher-level protocols more like that of TP-4 should be developed for
TCP and tested with existing higher-layer protocols.
This should serve as a rapid test of whether existing DOD protocols can
make effective use of the somewhat different style of service that TP-4
provides. It should also allow higher-level protocols to be modified
to make use of TP-4 in parallel with the implementation of TP-4 itself,
making the ultimate transition to TP-4 more rapid and certain of
success. Finally, it may allow use of a single version of the
higher-level protocols to be used on both TCP and TP-4 equipment.
(6). DOD should continue using existing DOD-specific, higher-level
protocols for operational purposes (Telnet, FTP, and Simple Mail
Transfer Protocol, for example) but minimize effort on their further
development and plan to adopt suitable ISO protocols as they are
developed. Research on protocols providing new services (multimedia
mail, compressed video, and voice store-and-forward, for example)
should continue. The committee is pleased to find that DOD is already
pursuing this course of action.
(7). The NBS Institute for Computer Sciences and Technology should
maintain close liaison with DOD to ensure that DOD needs for new
protocols and modifications to existing standards are effectively
represented to appropriate standards bodies. This should include
research areas such as multimedia mail where there is significant
commercial as well as military interest.
National Research Council [Page 63]
RFC942 February 1985
Report Transport on Protocols
The committee is pleased to find that this is already being done
through contracts from DOD for ICST to represent its interests in
standardization activities. Further cooperation (in demonstrating and
testing protocols, for example) could occur.
(8). The NBS and DOD should collaborate from the outset in the
development of new protocols for use as federal standards. This will
ensure early agreement on functions, features, and services of the
protocols under development. The NBS should present the developing work
early to the ISO standardization activities to expedite convergence on
internationally acceptable standards.
Such collaboration could help ensure that future protocol standards
will be developed in a single, coordinated process that results in a
single standard accommodating both DOD, other federal agencies, and
commercial needs.
(9). DOD and NBS should develop additions to protocol specifications
to support preemption of limited resources by high-precedence users.
Such capabilities are needed during high-load situations such as might
develop during wartime or other crisis situations. They are not yet
part of either the TCP or TP-4 specifications or existing
implementations. This should be an example of the sort of
collaboration mentioned in detailed recommendations 7 and 8.
This is important to avoid possible incompatibilities between different
implementations of the same specification as discussed in Section III.
It is likely that vendors would welcome guidance on how to deal with
open areas of the specifications, and early action by DOD could result
in their mandated subset becoming the de facto standard for most
commercial implementations as well, with consequent benefits to DOD.
This is a good area for cooperation between DOD and NBS.
ADDITIONAL CONSIDERATIONS
Transition Plan
This section describes the major elements of a transition plan from
use of TCP to use of TP-4 in DOD systems. The plan will vary
depending on the option chosen. Both Option 1 and Option 2 share a
number of common elements that are discussed first, including
development of a MIL-SPEC, protocol-testing facilities, and transition
support equipment. If Option 2 is followed, a demonstration of TP-4
must also be undertaken.
MIL-SPEC. As noted in recommendation 1, several open areas and
options in the ISO TP-4 must be specified in order to have complete
and compatible protocol implementations. Completion of this
specification by the DOD should be a top priority objective.
National Research Council [Page 64]
RFC942 February 1985
Report Transport on Protocols
Protocol-Testing Facilities. As noted in recommendation 3, test
facilities for protocol implementations are essential. Under Option
1, this facility should serve primarily to validate implementations of
both old and new protocol sets. If Option 2 is followed, the facility
should initially focus on demonstrating the suitability of the new
protocols for use in a military environment as rapidly as possible,
and provide for testing of commercially supplied protocol
implementations.
For validation purposes, the NBS protocol-testing facility developed
for ISO protocols should serve as a good basis, but extensions to deal
with any DOD-specific options for the ISO protocols, performance, and
DOD protocols would be necessary. The DOD has stated that such a
program has been started.
Transition Support Equipment. In any transition plan it must be
assumed that the large body of systems with existing TCP
implementations will take a substantial period of time to switch
completely to the use of the ISO protocols. Some networks will
include many different communities sharing a common communications
backbone. Members of one community communicate primarily among
themselves, but occasionally outside their community. While members
of one community are likely to change over as a group, different
communities will change to use the new protocols at different times.
Hence an interim period must be anticipated when some systems are
using the old protocols and others, the new protocols. The transition
plan must provide some means of allowing interaction between old and
new systems where required during this period. Toward this end, a
number of relay hosts may need to be developed that support both old
and new protocols. These will allow automatic-staged forwarding of
electronic mail between old and new systems and manually set up file
transfer or remote terminal access via the relays. Performance
through these relays will not be as good as with direct connections,
but the relays should provide an adequate level of service for
occasional interactions among different communities of the internet
system.
When more frequent interaction is anticipated and better service is
needed, major service hosts should support both old and new protocol
sets concurrently so they can provide service directly without
requiring the use of relays. Such service hosts include widely used
time-sharing machines, file servers, and special servers such as
Network Information Centers, Network Operations Centers, and
Administrator Machines (providing mailboxes of network administrators,
for example). Some dual protocol servers
may also act as relays where the load of both functions can be
supported.
Terminal concentrators for general use must also support both protocol
sets so that connections to both old and new hosts can be made
directly.
National Research Council [Page 65]
RFC942 February 1985
Report Transport on Protocols
Gateways must support both old and new IPs so hosts using either one
may send internet traffic. This requirement could be relaxed in the
case of entire networks that will switch over simultaneously and hence
will only need one type of IP traffic. Gateways should not have to
translate between old and new IPs--it will be assumed that both source
and destination hosts are using the same protocols or going through an
explicit relay intermediate host.
This latter point requires some elaboration. If one type of IP packet
arrives at a destination host or gateway that only handles the other
type, it must be discarded. It would be good if, in addition, a
suitable ICMP error packet could be returned in the unsupported
protocol so it would be meaningful to the source. To avoid this
situation the internet-host name table maintained by the Network
Information Center should indicate which protocol(s) each host
supports. Then when a source host looks up the address of a
destination, it will also determine which type protocol to use or if a
relay is required.
Demonstration Plan
If Option 2 is followed, a major demonstration of the ISO protocols in
a military environment must be undertaken. Any such demonstration
should proceed by stages beginning with the implementation of TP-4 in
one network (15). Then the demonstration would be extended to include
internetting (still with DOD IP) to validate the suitability of TP-4
as a replacement for TCP. The demonstration would then be further
extended to employ the ISO IP in place of DOD IP.
Stand-Alone TP-4 Network Demonstration. The first stage of any
transition plan must be to establish a demonstration network or
subnetwork using TP-4 in place of TCP under existing higher-level
protocols. This step will require selection of a suitable network (or
subnetwork), procurement of TP-4 implementations for hosts and
terminal access controllers on that network, and modification of
higher-level protocols to use TP-4. The demonstration should include
sufficient use of real applications to test the protocols in an
operational environment.
To limit the amount of change attempted at one time, the DOD IP may be
retained and used under TP-4. Alternatively, if ISO IP development
status seems to warrant it, ISO IP may be installed along with TP-4.
-----
(15) For the remainder of this chapter, the use of TCP and TP-4 to
include their respective IPs will no longer hold. The four
entities--Transmission Control Protocol (TCP) and its Internet Protocol
(DOD IP) and the Transport Protocol (TP-4) and its Internetwork Protocol
(ISO IP)--will be treated individually.
National Research Council [Page 66]
RFC942 February 1985
Report Transport on Protocols
In the latter case, all TP-4 hosts would be on the same network
anyway, so that IP will only be used between hosts and no gateways
will be involved and no gateway modifications will be needed.
The hosts involved could be dedicated to the demonstration and hence
only support TP-4 and only be able to interact with other
demonstration network hosts or be concurrently supporting TCP and DOD
IP for operational traffic to other "normal" hosts. In the latter
case, no forwarding or relaying of traffic by hosts between normal and
ISO logical networks would be allowed or performed (the demonstration
network would be logically closed).
Stand-Alone TP-4 Internet Demonstration. The next step would be to
expand the demonstration to include more than one network (at least
logically) and hence involve gateways. If only TP-4 is involved, this
is a simple extension to test TP-4 over longer internet paths with
more variable performance. If ISO IP is also being tested at the same
time, modification of the gateways involved will also be required as
indicated in the next section.
Stand-Alone ISO IP Demonstration. Once TP-4 has been tested,
introduction of the ISO IP to replace DOD IP may commence. In
addition to simply replacing one IP with the other in hosts and
gateways, this will require modification of the gateways to perform
ICMP and GGP on top of the ISO IP.
These gateways could either be dedicated to the demonstration and
hence have only ISO IP, or could be concurrently supporting normal
operational traffic via DOD IP. In the latter case, once again, no
forwarding of traffic between ISO demonstration internet and normal
systems would be allowed.
At the conclusion of these three steps, the ISO TP-4 and IP could be
deemed to have demonstrated their basic functional suitability in a
military environment. The transition support equipment described
above should have been developed in parallel, providing the capability
to smoothly and successfully switch operational systems using the old
protocols to use of the new protocols.
Switchover of User Systems
Once the above preparations have been made and the demonstration
completed, if Option 2 is being followed, the switchover of user
systems can commence. Each network or community within a network
should be able to switch at its convenience and maintain the ability
to interact with other systems. The user systems will not be required
to support operational use of both protocol sets simultaneously at any
time unless they wish to do so for their own reliability purposes.
National Research Council [Page 67]
RFC942 February 1985
Report Transport on Protocols
Switchover of user systems also requires a personnel-training effort.
While earlier steps involved a relatively small number of specialists
and support staff at major sites, this step will affect all user
sites, and their network support staff must be trained in the new
procedures.
Once switchover of all systems to the new protocol set is complete,
support for the old protocols by TACS, service hosts, and gateways can
be removed.
Lessons Learned from the ARPANET NCP-to-TCP Transition
The following points summarize some important lessons learned during
the ARPANET transition from NCP to TCP (16).
Conversion of TACs and service hosts to support both protocols before
the transition of user hosts starts is essential.
Relay capabilities were heavily used for mail, but used little for
other purposes.
The Network Information Center was not ready to support the new
protocols and this caused problems in distributing the host name
table.
There were significant performance problems that required careful
analysis and parameter tuning after the transition. These were
unavoidable because no service host had been stressed prior to the
switchover, with a full user load over a long time period using the
new protocols.
-----
(16) For additional information, see ARPANET Request for Comments:
NCP/TCP Transition Plan, J. Postel, (Menlo Park, California: SRI
International Telecommunications Sciences Center, November 1981).