HANK@BARILVM.BITNET (Henry Nussbacher) (07/08/87)
Conversion Plans
from RSCS to Tcp/Ip
for Israel Academic Network
by
Henry Nussbacher
July 7th, 1987
Table of Contents
Acknowledgments
I. Reasons for conversion
A. Background
B. Reasons
II. Why Tcp/Ip and not something else?
A. SNA
B. DECNET
C. ISO
D. TCP/IP
E. Caveats
III. What will it cost?
A. Alternatives
1. High speed LAN (Ethernet)
2. BSC driver for leased lines
3. Tcp/Ip "black" boxes
B. VM
C. MVS
D. Unix
E. VMS
F. Primos
G. NOS
H. Intercampus
I. Total cost for all systems
IV. Timetable for conversion
A. Stage I - The test
B. Stage II - Tcp/Ip for everyone
C. Stage III - The Tcp/Ip<->RSCS gateway
D. Stage IV - Conversion to ISO
V. Appendix 1 - List of Israeli EARN nodes
Appendix 2 - Cost of connecting PC's to a Tcp/Ip Network
Appendix 3 - List of Tcp/Ip software and hardware vendors
Appendix 4 - The Tcp/Ip Reference Model
Appendix 5 - Glossary of acronyms
Appendix 6 - References
Appendix 7 - EARN Migration Plans
Appendix 8 - Israel viewpoint on EARN Migration Plans
Acknowledgements:
Many people have provided valuable input but there are a few
whom I wish to single out:
John Klensin - MIT
Mike Kramer - Nynex
Scott Brim - Cornell University
Marshall Rose - Northrop Research
Dan Lynch - ACE
---------------------------------------------------------------------
I. REASONS FOR CONVERSION
======================
I.A: Background:
This report is based on meetings held by the Israeli University
Telecommunications Subcommittee. Various pros and cons of the
following proposal were discussed and argued. All members of the
Telecommunications Subcommittee have reviewed this proposal and have
stated their views to me via electronic mail.
I.B: Reasons:
Quite often people ask, "Why do we need to change something if
it works perfectly and gets the job done correctly?" This is a
valid question and this section will answer it. Currently, there
are 43 computers connected to the Israeli section of EARN (European
Academic Research Network - sister network of Bitnet). The six
operating systems are:
VMS 14
Unix 11
VM 8
NOS 4
MVS 3
Primos 3
---
Total 43
The protocol in use today is known as RSCS, also known as NJE
(Network Job Entry). This protocol was developed within IBM and
resulted in the creation of VNET - IBM's internal use network that
currently numbers 2297 nodes (as of Nov 26th 1986). The reason for
its successful growth within IBM was for one reason: its simplicity.
One could install RSCS in one hour on a VM system and be talking to
another node within the same amount of time.
RSCS provides two protocols for communication: file transfer and
interactive messages. There is no remote login (this is supplied
within Vnet by a parallel network known as PASSTHRU), no mail
protocol, no topology management and very little network control.
In addition, when IBM released RSCS to the public in 1972 (along
with VM Release 1), it only allowed for the connection of IBM
operating systems (VM, MVS, DOS) and no other operating system. As
Bitnet started to develop, various universities developed NJE
simulators for their own operating systems. Urep (for Unix systems)
was developed at Penn State University, jnet (for VMS systems) was
also developed at Penn State University, and the author later sold
the software to Joiner Associates for a healthy profit. Some
vendors have taken it upon themselves to develop the NJE emulation -
as Prime has recently announced for their Primos operating system.
Over half the nodes in Israel only have a limited access to the
NJE protocol. These nodes cannot send any interactive messages and
some of them cannot send any files other than RFC822 (Request For
Comments #822) mail. Therefore, Israel currently has the situation
where some nodes have greater "connectivity" to the network than
others. That is one of the problems that needs to be resolved. All
nodes in the network should be able to supply the same level of
service to their users - no matter where that node happens to be in
Israel.
Even if the network topology was rearranged so that only a very
few nodes with limited software were to be assigned the status of
end-nodes, we would still have the problem of the limited
functionality that RSCS provides. Users have been asking for remote
login for a long time and this can currently only be provided to VM
sites and at a high cost to network performance.
In the area of performance, RSCS loses out. First of all it
uses a BSC protocol that requires an acknowledgement for every block
received over a link. This requires line turnaround time and a loss
of throughput. A full duplex protocol (HDLC) over our existing 9600
baud lines would effectively increase throughput by approximately
30%-40%. In addition, RSCS does not do any sort of dynamic or
adaptive routing. If a link goes down (which we are already very
familiar with), then data communication to that node is shut off
completely.
II. WHY TCP/IP AND NOT SOMETHING ELSE?
==================================
There are other networking protocols that exist and I will
review three of them: SNA, Decnet and ISO.
II.A: SNA: It is interesting to note that IBM's strategic
networking system is not used for its own internal network, but
instead RSCS is used. IBM has been trying to convince the people
within its own network that SNA will be "good" for them, but till
this date nothing has happened. In a lecture by Tom Piatkowski,
currently at SUNY Binghamtom, but more importantly one of the
original architects of SNA, he noted that SNA was designed for the
central management of a small network and not for a globe spanning
network. SNA excels in managing a campus network; a network
confined to a limited number of buildings and other small geographic
entities.
A recent internal memo within IBM detailed the performance
tradeoff between using SNA and RSCS over a 9600 baud line or CTCA.
The file transfer times were almost identical for both protocols but
the SNA system took 40%-60% more CPU time to execute the transfer.
This is understandable when one looks at the size of the RSCS
program compared to the size of the RSCS/SNA/VTAM program.
SNA's other major problem is also spelled with 3 letters: IBM.
Other operating systems may create gateways from their networks to
IBM's, but only a small number have done so to date and the only
places that have installed these gateways are those installations
that had to. No installation to my knowledge has planned a network
from the start with the assumption of using SNA gateways to four
non-IBM operating systems (three of which do not exist yet).
Europe and for that matter the rest of the world, have decided
that IBM is not to be followed with their networking protocols. For
that reason they have created the ISO, which I will get to shortly.
II.B: DECNET: Much of what has been discussed in the section on
SNA pertains also to DECNET. VMS, Ultrix and TOPS-20 are the only
operating system that can use Decnet and three months ago,
Technology Concepts Inc. announced CommUnity, which allows Unix
systems to participate in a DECNET environment. For our purposes,
DECNET only supports two of our operating systems along with a
gateway to SNA - exactly the same numbers that SNA claims.
II.C: OSI: The International Standards Organization (ISO)
created the Open Systems Interconnect (OSI) Reference Model because
they saw that a uniform approach needed to be created for the entire
world. In five years time, I expect we will see 4 OSI
implementations: VM, MVS, VMS and Unix. I do not see that a NOS or
Primos implementation will be available within that time frame but I
am always ready to be pleasantly surprised. As of the end of 1986,
there were only three X.400 implementations available (the mail
protocol of OSI) - all of them on an unofficial basis. It is
important to remember that X.400 is not an OSI protocol but rather a
CCITT protocol that the ISO is considering to be part of its OSI
protocol suite. No FTAM (file transfer) or Rlogin (remote login)
implementations have been heard of. Clearly, people are working on
developing the OSI protocols but we are currently looking for a
networking standard that will last us through 1992.
It is interesting to note that OSI is not a protocol but rather
a reference model that provides for several families of standards.
All that one has to do to become an "OSI product" is to document
what your software does in terms of the reference model. DECNET
claims that DNA is an OSI product as IBM claims that SNA is an OSI
product. Different vendors will interpret the OSI reference model
differently and in that case we will have many OSI products, unable
to talk to each other. That is why the NBS (National Bureau of
Standards) in the United States has created OSINET - a test bed
where vendors can try out their software to see if their OSI will
talk to someone else's OSI.
II.D: TCP/IP: So what is so great about Tcp/Ip? For one, it is
the oldest networking protocol around, predating DNA and SNA. There
are 124 different Tcp/Ip implementations that run on 28 different
brands of hardware (see Appendix 3). In addition there are 23
companies that make hardware (boxes or cards) that connect various
computers to a Tcp/Ip network. If we ever need to add other
operating systems to our network (example: MS/DOS), Tcp/Ip can
handle it. Tcp/Ip works in full duplex so a leased line is fully
utilized. Arpanet and Csnet in the United States use it, as well as
numerous individual installations in Europe. It provides three
standard applications protocols: SMTP (Simple Mail Transfer
Protocol), FTP (File Transfer Protocol) and TELNET (Remote Login).
All operating systems in Israel have Tcp/Ip implementations (NOS
Tcp/Ip to be available from CDC - April 1987).
Tcp/Ip can run on leased lines (9600 baud up to T1 speed),
Ethernet, X.25 circuits, Pronet, etc. It is more in the spirit of
the OSI reference model than SNA or DECNET since the physical and at
least part of the link layer can be swapped out and substituted for
with no change in the transport or session layers.
Some Israeli universities have already made a heavy commitment
to Tcp/Ip. Hebrew University, Ben Gurion University, Weizmann
Institute of Science and Tel Aviv University have most of their own
computers interconnected via Tcp/Ip. By installing a Tcp/Ip network
we will be gaining access to the many Sun workstations, Lisp
machines and other unique hardware that exists at each campus.
Currently, these machines are available locally at individual
campuses via local Tcp/Ip networks. Since Machba (Israeli
InterUniversity Organization) has been considering the purchase or
sharing of a Cray, it should be noted that Cray has developed a
Tcp/Ip implementation for their Unicos operating system.
Most importantly, the DOD (Department of Defense) has stated
that it intends to convert to ISO standards when such standards are
made available. To this end, the Northrop Research and Technology
Center has recently introduced RFC983 - which defines a strategy for
conversion in an evolutionary manner as opposed to a revolutionary
manner. They offer a free ISO Development Environment that they
have developed (written in C) that currently runs on Unix, VMS and
PC/DOS.
It is clear that the conversion route from Tcp/Ip to ISO (since
they are so similar and parts of ISO are drawn directly from Tcp/Ip)
will be the smoothest. The alternatives before us are few: either
to sit still and continue to use the RSCS protocol for many years to
come or to convert now to Tcp/Ip, under the assumption that it will
be replaced by the ISO suite of protocols when they become
available. It is my personal feeling that the upper layers of the
ISO protocol (levels 5-7) are at least 5-8 years away from
implementation.
II.E: Caveats: There is also a negative side to Tcp/Ip. Certain
implementations are buggy and will require a large amount of systems
programming intervention. We will try to avoid those
implementations but it should be known from the start that Tcp/Ip is
not bug free (neither is any other networking or operating system)
and we may run into a glitch along the way with certain
implementations.
The implementations that do work properly may be lacking some
feature that we will realize later on that we need. It is
impossible to know at this stage of the game what all the features
that are in Tcp/Ip (i.e. dynamic routing, adaptive routing, ICMP,
UDP) that will be needed.
Tcp/Ip lacks certain features that we may need to develop in the
future (but do not exist today). These include: accounting - there
is no facility to gather statistics on path usage, data transfer
rates, etc.; authentication and access control - suppose we wish to
limit data transfer limits for students - currently there is no
mechanism to accomplish this with Tcp/Ip. The Arpanet realizes
these requirements and has informed vendors to be prepared in the
future to include access-control and accounting machanisms in their
gateways.
Most of the assumptions for a smooth conversion depend that the
Tcp/Ip network and RSCS network work in parallel for a period of two
years. This involves an added cost that needs to be considered.
Lastly, a network of this nature needs staffing. It doesn't run
by itself and it doesn't fix itself. In general, you need more
staff to run a network than not to run a network. Of the 6
operating systems in Israel, four have sufficient systems expertise
scattered through the various universities. The two systems that
lack "networking & system hackers" are Primos and VMS. All computer
centers should be prepared to have one full-time person whose major
responsibility is the running of their LAN.
III. WHAT WILL IT COST?
==================
... this section removed for EARN and Bitnet distribution ...
IV. TIMETABLE FOR CONVERSION
========================
IV.A: Stage I:
This stage involves the interconnection of 2 or more separate
Tcp/Ip LANs. Currently, there are Tcp/Ip networks at Hebrew
University (CS Department only), Tel Aviv University (CS Department
only), Bar Ilan University (CS Department only) and Weizmann
Institute of Science (CS Department and Computer Center). There are
two alternatives to accomplish this:
A) VM to VM: The Wiscnet package comes with a BSC driver that
can run a point to point leased line. All 4 Universities mentioned
above have VM systems but currently only one of them runs Wiscnet.
B) Tcp/Ip boxes (Bridge GS/3M): This would allow any of the
current LANs mentioned above to interconnect.
... two paragraphs removed for EARN and Bitnet distribution ...
Synopsis: identify potential and willing sites with the
necessary software, then order necessary hardware. This stage
should be completed no later than September 1987.
IV.B: Stage II:
This stage is just an extension of Stage I. All 43 Israeli EARN
sites should be running Tcp/Ip on their system and a parallel Tcp/Ip
network should exist alongside the current RSCS network. This stage
will be the one to work out all the bugs between the various systems
(inter-machine translation problems, performance and optimization,
etc.)
While this work is going on, the sites from Stage I should start
experimenting with using their local Tcp/Ip services to send and
receive data from the RSCS EARN network. Makeshift solutions will
be made and the specific problems and necessary global solutions for
Israel will be identified in this stage.
This stage depends on the fact that alternate lines will exist
for each of the 43 computers currently connected. These alternate
lines can be either 9.6Kb or 64Kb Sifranet lines. The important
point in this matter is that alternate lines have to exist for this
to work.
Synopsis: Order equipment for all 43 Israeli nodes, install
software and hardware. This stage should be completed no later than
June 1988.
IV.C: Stage III:
This is the final stage. It involves the disconnection of the
9600 baud leased lines and the end to the RSCS network that is
currently in place in Israel. But before this can be done, a
gateway needs to exist at Tel Aviv University (our EARN gateway for
the country) that will send and receive Tcp/Ip datagrams from one
side and send and receive RSCS files and interactive messages from
the other. It will be up to each site to decide whether they wish
to use the new Tcp/Ip functions (i.e. SMTP or FTP) or whether they
wish to take their old RSCS user interfaces and make the necessary
modifications (on a local basis) so that they can communicate via
the Tcp/Ip network. It will not be Tel Aviv University's
responsibility to modify every user program on all 43 systems that
currently communicate with EARN.
It will be Tel Aviv University's responsibility to design a
gateway with the following capabilities:
FTP: If a file arrives via EARN, destined for an Israeli user,
then an FTP transaction should be created for delivering the file to
the user. In certain cases, FTP to a system may not be possible.
In that case, TAU must provide the necessary modifications for that
system so that they can receive FTP transactions. An example would
be a file destined to a VM site. Since FTP requires a write
password to the person's disk - a vanilla FTP would not work.
Possible alternatives might be: a) sending the file to an FTP sink
user at the intended node, along with a mail file to the intended
user informing him that a file has arrived and can be received from
his local FTP sink user; b) modifications to Wiscnet FTP that would
allow FTP to the user's VM spool (preferred solution).
The reverse also needs to be handled. If a user in Israel
wishes to send a file to a user in Germany via EARN, then the
gateway at TAU must accept the FTP request and receive all the
intended packets on behalf of the user in EARN. It will then issue
a sendfile on the user's behalf, counterfeiting the original user's
id and nodename instead of its own. There are many details that
need to be worked out for this gateway (such as what format to send
data in: netdata, disk dump, punch, print, specifying RSCS dependent
options on the FTP request - like priority, class, forms, etc.)
SMTP: Israel will register itself as being a domain of AC.IL and
that all mail destined for this domain should be sent to
MAILER@TAUNIVM. This mailer will then deliver the mail via SMTP
methods rather than RSCS methods. The reverse must also be taken
care of. This area is considered to be the easiest since other
installations throughout the world have already tackled this problem
and have come up with software solutions that we can use. It should
be noted that Arpanet has already assigned an upper level domain to
Israel (.IL) and that there is already a node at Hebrew University
listed as a host in Arpanet (HUJI.AC.IL). It would then be a
trivial matter to define all other hosts in Israel in the Arpanet
hosts table, thereby giving us equal access to Bitnet (via the
planned gateway at TAU), and via the X.25 link to Arpanet from
Hebrew University.
TELNET: This will not be supported in the direction of EARN
since it is not supported today. Users will only be allowed to
TELNET within Israel.
RSCS Interactive messages: This is one area that we may not be
able to implement. The ISO protocols do not support this kind of
facility and neither does the Tcp/Ip protocol. We will only be able
to determine whether we can implement this near the end of stage
III. A while back, Arpanet implemented a SEND protocol that was
fairly similar to RSCS interactive messages. It required a SEND
server at the origin and destination sites. This service did not
catch on with Arpanet users since they found it a bother to know
whether a user was logged on at the time. Several people within
Arpanet have indicated that the SEND protocol is very easy to
implement since it never waits for an acknowledgement but rather
just sends a datagram and exits. We may be able to use some of the
early Arpanet work but it will have to remain as a low priority work
item during the general timetable.
It should be noted that some of this development work could be
done in the framework of a graduate student project. Ariel Frank
(Bar Ilan University) has indicated that he has graduate students
that he could assign with subsets of the above stated work. Various
other universities may also have graduate students that could be
utilized to develop certain components that have been delineated
above.
Synopsis: A lot of software development should have already been
started by the end of Stage I. This stage should be completed no
later than January 1989.
IV.D: Stage IV:
This stage involves the conversion to ISO. As solutions become
available on Arpanet (i.e. RFC983; see Appendix 6), we will adopt
them. I foresee this stage lasting over a period of 2-3 years after
January 1989. It is quite possible, that development projects will
be assigned to Israel (i.e. from IBM, CDC, DEC, etc.) in this area
over the next five years.
V. APPENDIX 1: List of nodes in Israel
===================================
... this section removed for EARN and Bitnet distribution ...
APPENDIX 2: Connecting PC's to the Tcp/Ip network
=================================================
... this section removed for EARN and Bitnet distribution ...
APPENDIX 3: List of Tcp/Ip Hardware and Software Vendors
========================================================
... this section removed for EARN and Bitnet distribution ...
APPENDIX 4: The Tcp/Ip Reference Model
======================================
Applications Layer (7)
Presentation Layer (6)
Session Layer (5)
Transport Layer (4)
Network Layer (3)
Data Link Layer (2)
Physical Layer (1)
APPENDIX 5: Glossary of acronyms
================================
Application Level:
FTP - File Transfer Protocol - transfer of files and directories
between computers
TELNET - Virtual Terminal Protocol - interactive remote logon
SMTP - Simple Mail Transfer Protocol - RFC822 mail
BSMTP - Batch Simple Mail Transfer Protocol
NFS - Network File System - SUN protocol for accessing remote
files
Transport Level:
TCP - Transmission Control Protocol - sliding window protocol,
connection oriented, flow control, multiplexing
Network Level:
IP - Internet Protocol - packet addressing and fragmentation
UDP - User Datagram Protocol - connectionless service for host to
host comunications
ICMP - Internet Control Message Protocol - reports on transmission
errors, flow control, first-hop gateway redirection and
routing information
ARP - Address Resolution Protocol - converts 32-bit Internet
addresses to 48-bit Ethernet addresses.
EGP - Exterior Gateway Protocol - used to exchange information
between gateways
Data Link Level:
DLP - Data Link Protocol (also known as DLAP - Data Link Access
Protocol) - provides connectionless service for sending and
receiving datagrams
APPENDIX 6: References
======================
1) RFC942 - Transport Protocols for the Department of Defense Data
Networks; Feb 1985
2) RFC983 - ISO Transport Services on Top of the TCP; Northrop
Research; April 1986
3) RFC985 - Requirements for Internet Gateways; NSF; May 1986
4) Tcp/Ip Vendor's Guide; SRI; Feb 1987
5) DDN Protocol Handbook; SRI; Dec 1985
6) Ethernet: Distributed Packet Switching for Local Computer
Networks; Metcalfe and Boggs; ACM Communications, July 1976
7) Introduction to Local Area Networks; DEC; 1982, EB-22714-18
8) Proceedings of Campus Network Plans and Pc/Ip Workshop;
University of Maryland; Dec 1985
9) Computer Networks for Scientists; Jennings, Landweber, Fuchs,
Farber, Adrion; Science; Feb 28, 1986
10) Notable Computer Networks; Quarterman and Hoskins; ACM
Communications, Oct 1986
APPENDIX 7: EARN Migration Plans
================================
EUROPEAN ACADEMIC RESEARCH NETWORK
The migration of EARN to use ISO protocols,
summary of the proposed strategy and tactics.
Subject to ratification by the EARN Board of Directors and further study
issued by
P Bryant
20 April 1987
_______________________________________________________________________
1 Summary
EARN is determined to migrate to use ISO protocols as soon as possible.
It is vital that during this migration there is no significant loss of
service to the users.
Until recently there have not been the products available to start a
migration. There are now a number of developments which suggest that the
first stages of a migration could now be undertaken. The completion of
the process will take several years.
The EARN Board of Directors set up a working party to define the
migration path which is just concluding its work. This paper is a
summary of their report. The full report is now under discussion.
2 Why migrate?
There are three reasons for EARN wishing to use ISO protocols:
- EARN had to obtain permission from the various national regulatory
authorities in order to operate. This was because it infringed the PTT
monopolies in some countries. CEPT, the European advisory body for such
matters, agreed to recommend EARN should be permitted as long as they
migrated to ISO protocols by the end of 1987.
- EARN uses the fairly primitive IBM NJE protocols which provide a store
and forward network for file transfer and mail. The use of ISO protocols
would provide a broader range of services. ISO protocols are expected to
be available under most systems whereas NJE is restricted to the more
popular ones.
- All the west European countries (and many others) are expected to base
their academic networking on ISO protocols. EARN must cooperate and
interwork with these networks.
3 The state of protocols
The CCITT X.25 protocol is widely available but only in its 1980
version. The 1984 version is required for the support of ISO protocols.
The PTT's planed dates for the 1984 version are not yet clear. Various
private switch suppliers now provide it.
The X.400 mail protocol is available in a number of experimental or
pilot versions. The use of this protocol is likely to expand rapidly as
the PTTs provide services based on it in the near future.
FTAM (the ISO file transfer protocol) is only now becoming stable and
implementations are not expected for some time.
VTP (virtual terminal protocol) and JTP (job transfer protocol) are both
unstable and implementations are not expected for a long time.
4 The parts of EARN
EARN can be regarded as two parts - the national parts and the
international ones.
The migration of EARN within a country must be undertaken in close
cooperation with other national activities and will therefore not be
directed centrally.
The migration of the international parts will be directed by the EARN
Board. All the international EARN nodes are IBM ones. This is the
principle subject of this paper.
It is essential that the international and national migrations are
carefully coordinated.
5 The first stage, strategy
The only ISO protocol that can currently be adopted is X.25.
The strategy is to operate the IBM NJE protocol over X.25. This can be
achieved using IBM products. The users will not need to be aware of the
change since the strategy will not alter the services provides or the
interface to the user.
The use of NJE over X.25 demands the use of X.25 permanent virtual
circuits. These cannot be provided internationally by the PTTs and
therefore EARN will have to provide an interim private X.25 network.
This has the secondary advantage that X.25 (1984) can be used which is
not currently available from the PTTs and this needed to support the
higher level ISO protocols.
6 The first stage, tactics
A survey has shown that private switches which provide permanent virtual
circuits and X.25 1984 are available.
The number of switches and their location depend on the cost of switches
and the cost of lines. An incomplete study suggests that initially there
should be two switches- one serving the north of Europe and one the
south. There will need to be some relocation of lines but this is
expected to be done over a fairly long period of a year.
It is intended to use the X.121 address scheme. This defines the first
four digits of an address. Eight digits will remain for use within a
country which will be allocated according to national needs although it
is suggested that four digits define a site and four for use within a
site. A two digit subaddress will not be policed by the network.
Initially only a few sites with good networking expertise will be
connected. The rest of the international sites will be migrated at a
later date and in some cases when lines are relocated.
A few sites will need additional software which may also cause a slight
delay.
The EARN services will be enhanced by the addition of the X.3, X.28, and
X.29 services on some sites. This will not be very useful until the
national parts of EARN have migrated to X.25 or gateways are provided to
other X.25 networks.
The tactics within a country will be the responsibility of the country.
Some countries will want to migrate in step with the international parts
of EARN. Others will want to wait. Others may want to provide gateways
and relays to existing or proposed national networks.
The use of Coloured Book protocols and DECNET will be allowed for an
interim period to meet the needs of some specific groups of users. This
will allow good connectivity between Ireland, the UK, and some other
sites who use Coloured Books. DECNET is popular with the astronomy,
space physics and high energy physics communities.
7 The second stage, strategy
The first higher level ISO protocol to be promoted will be X.400 mail
protocol.
Some countries are expected to migrate with the international part of
EARN. They will be installing switches for this purpose. These switches
may be used to enhance the international parts of EARN and require some
change to the EARN topology.
8 The second stage, tactics
There are a number of X.400 systems now available.
In particular the IBM Heidelberg system will operate on IBM VM systems
and so it will be mounted on many of the international nodes. This
system has the property that parts of the system can be located remotely
over the NJE network thus allowing greater penetration of EARN by X.400
than the extent of the X.25 network would suggest.
Other X.400 systems, such as EAN, are expected to interwork with the
Heidelberg one and recent tests are encouraging. These will be of
greatest interest within a country.
Some countries are expected to be part of the EARN address space as they
migrate. Other will have different schemes and gateways and relays will
be provided to maintain a service. Various promising products are in
existence or being produced.
The most important relay will be between X.400 and RSCS mail systems. A
suitable product is being produced in Germany.
9 The fourth stage, strategy
The use of NJE, DECNET, and Coloured Book protocols will be phased out
leaving a pure ISO network. At this stage it will be possible to use the
public networks.
The removal of these protocols depends on the provision of FTAM (the ISO
file transfer protocols) which should be available in a year or two.
10 The fourth stage, tactics
Currently there are no suitable versions of FTAM available and no firm
indication of dates. EARN will wait for suitable products and promote
them as soon as possible.
The fourth stage will require further study. It is unlikely to be
concluded before 1989.
11 Time scales
The international switches plus a few connections could be provided by
the end of 1987. The complete migration of the international part of
EARN to X.25 will take to the middle or end of 1988. NJE services must
be provided immediately.
X.400 can be provided on some nodes by early in 1988 with all
international nodes operating it at the end of 1988.
The use of Coloured Book and DECNET protocols will only be provided
where needed. Planning will be on a bilateral basis.
The migration of countries has not yet been studied in detail. There
will be gateways and relays to some existing X.25 national networks at
the end of 1987. a small number of national networks within the EARN
address scheme are expected towards the end of 1988.
Implementations of FTAM are expected in 1988 or 1989.
NJE will be phased out as soon as FTAM is proved to be able to offer a
comparable service. Manufacturers plans and timescales are not
available.
12 Standards
EARN will follow the emerging functional standards being elaborated by
CEN/CENELEC. EARN is also following the activities of RARE. This is
important to ensure that EARN can interwork with other academic networks
which are all expected to follow the same standards and functional
standards.
It must be noted that EARN is a service provider and does not intend to
take part in standards activities as a primary activity. In addition,
EARN does not intend to develop products but to use those provided by
others.
13 Conclusions
EARN is moving towards the use of ISO protocols as fast as possible. The
main delay is caused by the lack of implementations of protocols which
is not surprising considering the unstable nature of some of them.
EARN is dedicated and will remain dedicated to providing the best
possible service to the European academic and research community.
APPENDIX 8: Israel viewpoint on EARN Migration Plans
====================================================
Date: July 1, 1987
This section will address some of the points raised in the EARN
Transition paper (April 20, 1987) by Paul Bryant (Appendix #7). In
order to follow the points made, it is advised to have a copy of the
EARN Transition paper available.
1) Israel is determined to migrate to the ISO protocols.
2) Israel agrees entirely with the need to abandon the NJE
protocols and adopt the OSI international standards.
3) The 1984 X.400 standard finally has a few experimental
implementations available. IBM's announcement of X.400 support for
MVS systems fails to mention that availability is 3Q88. As yet, IBM
has not announced X.400 support for VM. We also realize that ISO
has not adopted the CCITT X.400 standard and that the newly revised
1988 X.400 standard will be (on certain levels) incompatible with
the 1984 version (i.e. mailing and distribution lists). If we take
X.400 as an example, we can assume that it takes 4 years from the
time a standard is finalized until the first half dozen supported
implementations appear in the marketplace. OSI's timetable in 1985
stated that CASE, FTAM, JTM, MOTIS and VTP (the top application
level) were all to become IS (International Standards) by 1987.
Unfortunately, all of them are still DP or DIS and some (JTM for
example) are therefore approximately 4 years behind schedule.
ISO has also published a timetable for the Management Framework
which includes standards for fault management, accounting, security,
configuration, etc. Their initial timetable states IS completion by
4Q90. If we assume that ISO will meet this deadline then we can
only hope to see the first half dozen supported implementations of
the *complete* OSI model by 1994 (if we are to use the X.400 model
as an example).
It is the period of the next 7 years that the national academic
network of Israel will follow an alternate path to the ultimate OSI
solution.
4) Israel will be a full partner in all EARN decisions on the
international segment of the network. It is Israel's intention to
implement all EARN recommendations for its international link.
5) Israel will participate in the interim private X.25 network
that EARN wishes to construct between the various country gateways.
6) It is stated in this section that each country is responsible
for what occurs within its own country. "Others may want to provide
gateways and relays to existing and proposed national networks."
Ireland and England are mentioned as two examples. Israel will fall
into this category.
7) Agreed.
8) As X.400 products become available we will implement them.
As EARN proceeds with X.400, so too shall Israel on an international
level.
9) Agreed. DECNET and Coloured Book protocols will be phased
out as ISO protocols become available. We are just not quite as
optimistic ("should be available in a year or two") as EARN is and
therefore see the conversion to Tcp/Ip as a strategy for supplying
all the services that ISO is planning, on an interim basis. If for
some reason the ISO deadlines slip, we will continue to function
with our national Tcp/Ip network until the necessary protocols are
available.
10) It is stated in the Transition paper that the conversion is
"unlikely to be concluded before 1989." The OSI FTAM standards (all
4 parts: 8571/1, 8571/2, 8571/3, and 8571/4) are still DIS (Draft
International Standard), the same status they have been since 1986.
If they do turn to IS before the year is over, I do not foresee more
than 5-6 supported implementation available before 1990. A more
realistic timeframe would be 1992.
11) Israel views these timescales to be extremely optimistic.
When dealing with existing services (file transfer, interactive
messages and mail) currently provided by EARN, it is very important
to have contigency plans in case of unforeseen delays. We view the
conversion to Tcp/Ip as an insurance policy that starts paying
dividends today.
12) Agreed.
13) "EARN is moving towards the use of ISO protocols as fast as
possible, the main delay is caused by the lack of implementations of
protocols which is not suprising considering the unstable nature of
some of them". That is EARN's conclusion. Israel is committed to
ISO conversion as the standards become available. We see Tcp/Ip as
an interim solution over the next 7 years.Ata@RADC-MULTICS.ARPA ("John G. Ata") (07/09/87)
Henry,
SMTP has, within its design, the capablility of
sending/receiving interactive messages which appear on the destination
addresses terminal. Take a look at the <SEND> command in RFC 821. I
realize that not many implementations may use this, but it is part of
the SMTP spec. You might want to check it out. It might be fairly
trivial to adapt the mailer to recognize that command, and to have a
user interface to send the message.
John G. AtaLYNCH@A.ISI.EDU (Dan Lynch) (07/11/87)
Hank, Thanks for posting your large document on Israel's plan for adopting TCP/IP while waiting for the ISO protocols to get more fully defined and supported. It certainly shows a lot of thought and effort has been made in arriving at this decision. I noticed that you left out a number of sections that deal with costing data in order to comply with Bitnet and EARN strictures. Since you sent this directly to the TCP/IP list you could put them back in and make the description and analysis much more complete. Thanks, Dan -------