INDRA Note 674
PSPWN **
IEN 35
SATNET and the Provision of Transnet Service
P. T. Kirstein and C. J. Bennett
ABSTRACT: This note discusses the problem
of providing service to ARPANET from the
UK via SATNET after the existing direct
ARPANET link disappears. A general
approach is outlined. The solution
offered attempts to make as much use of
current hardware and software as possible.
Areas where problems are anticipated, or
where insufficient information is
available, are indicated.
INDRA Research Group
Department of Statistics and Computer Science
University College London
SATNET and the Provision of Transnet Service Page 1
CONTENTS
1. Introduction
2. Overview
2.1 Configuration
2.2 Service Support
2.3 Stages of Development
3. Detailed Requirements
3.1 UCL TIP
3.2 UCL PDP9: Access to EPSS
3.3 UCL PDP-11
3.4 UCL PDP9: Access to X25
3.5 UCL LSI-11
3.6 Gateway LSI-11s
3.7 TCP Service Gateway in the ARPANET
4. Conclusions
SATNET and the Provision of Transnet Service Page 2
1. Introduction
With the transition of SATNET to a service role and the impending
demise of our direct connection to the ARPANET, University College is
faced with the problem of how to provide access to the ARPANET for the
many UK users who have come to rely on it. There are two aspects to
this problem. Users who connect through our site in London must be
given terminal access to both ARPANET and EPSS (and possibly the future
public PSS, currently due in mid 1979). Other UK users accessing
ARPANET through EPSS and ARPANET users accessing EPSS hosts (including
the UCL service to Culham, RSRE etc) must be given adequate support at
the transport and terminal level to make this possible.
Our solution to this must be based on our assessment of the current
state of techniques for implementing transnet services. The most
significant development in this area has been the development of a
number of network-independent protocols. Providing network-independent
process-to-process transport service has had the most attention
initially. The TCP is the result which is most familiar to members of
the ARPANET community. Another network-independent transport protocol
is the INWG 96 proposal. There has been a lot of discussion in Europe
on protocols for higher level services which are network-independent
(beyond the description of basic transport facilities required) and
there are several proposals around for virtual terminal protocols, none
of which has yet met with general acceptance. Recently the UK Higher
Level Protocol Group has published a proposal for a network-independent
file transfer protocol, available as INWG Protocol Note 86, which has
gained fairly wide approval in the UK and is now being publicised in
various international groups. This protocol is a development of the
file transfer protocol used on EPSS, and is being implemented on many
sites on that network, hence in this document it will be referred to as
the EPSS FTP.
Ideally, then, we would like to implement our future
ARPANET/SATNET/EPSS connection within this context, and assume that
connecting lines and machines and providing software to support these
network independent protocols is a sufficient solution to the problem.
In practise, of course, such an attitude is utopian. It assumes that
everyone who wants internet services will adopt network-independent
protocols to do it, and they will be perfectly happy to do this
themselves. There are some very good practical reasons why this will
not happen. Firstly, it means putting a great deal of effort into
developing a new solution to a problem which has already been solved.
ARPANET users have for many years been using the ARPANET file transfer
protocol quite happily, and they are not going to implement a completely
different and incompatible one just to enable European users to access
their files. Secondly, in order to achieve network-independence, the
protocols make the minimal assumptions possible about the nature of the
underlying network services, which means that they end up duplicating
many aspects of those services. For this reason it is unlikely, for
instance, that TCP or INWG 96 will be seen initially as an attractive
solution for providing transport services in an X25 environment - much
SATNET and the Provision of Transnet Service Page 3
of the emphasis of TCP is on providing end-to-end liaisons in a datagram
environment, which many people argue will involve a near duplication of
features of the X25 virtual call, to take just one example.
Therefore, we foresee the development of transnet services as
taking place at a limited number of network sites within the
concatenated networks, and it is unlikely that these services will be
integrated at any one particular site. A generalised view of the
transnet world under this scheme is given in Figure 1. The sites at
which the network-independent protocols are implemented have been
christened 'service gateways' as they are providing transnet access for
particular services. Note that this concept is quite distinct from the
gateways which physically connect two networks, providing packet
encapsulation, fragmentation, internet routing etc. The service
gateways need not stand in any particular physical relationship to each
other or to the physical gateways. Clearly there will be strong
functional relations between the physical and service gateways, and
there is a hierarchy of service gateways. One major research interest
of the concept is in establishing just what these functional relations
are and how best they should be implemented.
While the immediate aim of our network interconnection project is
simply to provide communication between the UK and ARPANET through
SATNET, the design chosen is one which will facilitate the provision of
future services across many networks using the service gateway concept.
Section 2 gives an overview of the proposed connection. Section 3 gives
a more detailed survey of the software needed in each crucial machine to
support the service, relates this survey to our understanding of the
existing state of the hardware and software for these machines, and
summarises the modifications to existing developments needed to realise
the system. Section 4 summarises our main conclusions.
SATNET and the Provision of Transnet Service Page 4
Figure 1 - The service gateway concept.
SATNET and the Provision of Transnet Service Page 5
2. Overview.
2.1 Configuration
The proposed future UCL configuration is given in Figure 2. The
principal points to note about this diagram are summarised below.
i) The PDP-11, currently the gateway machine, will become a
transnet access host on the TIP, connected via the VDH
interface currently connected to a PDP9, and probably running
under a standard operating system such as UNIX. It will
support terminal and file transfer access to and from ARPANET
via SATNET through TCP.
ii) An alternate route for EPSS-ARPANET traffic will pass
through the other PDP9 and the LSI-11 via the X25 connection.
The PDP9 will lose its current VDH connection to the TIP. The
X25 connection has been so constructed that the LSI will be
seen by users as an X25 host; EPSS sees the X25 interface as a
process on the PDP9. This LSI will also support TCP to
provide access to the ARPANET.
iii) The (physical) gateways to SATNET will be replaced by
LSI-11s. As indicated, the UCL gateway will have two 1822
interfaces and a VDH interface whereas the gateway on the
ARPANET side (presumably the BBN gateway) may only have one
1822 interface. Special hardware for the LSI-11 may be
required to handle 50kb on the VDH line across a DMA
interface; this will (presumably!) be done by BBN.
iv) A transport-level service gateway supporting TCP will
terminate the connection on the ARPANET side. This may be a
TENEX (or TOPS), or another PDP-11. Further terminal access
will be developed via ARPANET Telnet; support for other
services, such as transnet file transfer will also be provided
at this point.
SATNET and the Provision of Transnet Service Page 6
Figure 2 - Proposed UCL Configuration
SATNET and the Provision of Transnet Service Page 7
2.2 Service Support
The two major service requirements are the provision of terminal
access and of file transfer capability. Terminal access requires the
mapping of various terminal protocols at the appropriate points, rather
like the current SWITCH approach. Mappings between the ARPANET standard
Telnet and the TCP-based Telnet will be required in the transport
gateway in ARPANET and in the PDP-11 at UCL. The TCP-based Telnet will
map into the X25 VPT in the UCL LSI-11, and the ARPA Telnet will map
into the EPSS VPT in the PDP9 connected to the TIP. Much of the
complexity of this problem comes from linking up two connections when
one is being set up by the rather complex procedures of ICP. It is not
clear whether TCP-Telnet goes through a similar port-allocation
procedure.
The situation with regard to FTP is not so clear. The TCP group is
intending to implement a TCP-based FTP, but this is still in the
planning stages. If this becomes available at the right time, then for
service purposes we would perform analogous FTP mappings at the same
places. This mapping can be done either on a real-time basis, as we
have attempted to do for the EPSS and ARPANET FTPs on our PDP9, or on a
staged basis, with the file being stored on some mass-storage device and
forwarded to the next stage only when it has all arrived. Based on our
past experience, the staged solution is probably preferable when it is
possible. The status of the TCP FTP is one of the major question which
needs to be followed up. It may not actually be necessary to do a
detailed mapping of FTPs in the TCP transport gateways, as both the
source and destination of the transfer will be using the standard ARPA
FTP. It may only be necessary to map certain low-level features of the
FTPs, such as control and data sockets being mapped into TCP ports.
This is an option which we should also investigate.
If mappings of file transfers have to be done, it is desirable that
we keep these to a minimum, and it would be preferable to do them on a
large system, such as TENEX. If TCP-based FTPs are to be used, several
mappings are involved, none of them on systems of this type. Since in
any case it seems that a TCP FTP may not be available in time, an
alternative strategy of implementing the EPSS File Transfer Protocol on
ARPANET could be adopted. This protocol is specifically designed to be
network and transport protocol independent, and so this is an attractive
proposition. If transnet file transfer were done this way, this
protocol would be implemented in the PDP-11 at UCL, interfacing to both
TCP and NCP, and at the transport gateway, interfacing to TCP (or,
indeed, at some other site in ARPANET, in which case it would interface
to NCP). In this case, the only FTP mapping required is at the site in
ARPANET which has the EPSS FTP installed. The transport gateways (i.e.
the TCP site in ARPANET, the PDP-11 at UCL, the LSI-11 at UCL, and the
PDP9s at UCL) will then be supporting an end-to-end protocol between the
FTP service gateway in ARPANET and the destination site in EPSS (or at
UCL), and they will perform the classic gateway services of
address-mapping, connection-establishment, flow-control, etc.
SATNET and the Provision of Transnet Service Page 8
2.3 Stages of Development
The work needed for this development will obviously not be done
overnight. We see the project taking place in three main stages.
i) As much work as possible will be done in the current
configuration. Development of software for the PDP-11 at UCL
will probably be carried out on a PDP-11 in the ARPANET
(exactly which one is to be decided; see sections 3.3 and
3.7). The TCP/X25 LSI-11 will be developed as a terminal host
on a local host port on the TIP (see section 3.5). This
situation will continue until either the Norway line to
ARPANET disappears or LSI-11 gateways are ready. We expect
that the direct connection to ARPANET will not disappear
before the LSI gateways are ready, and this document is based
on that assumption; should events happen otherwise,
alternative means of continuing development will have to be
found.
ii) Once the LSI-gateways are ready and installed, the
configuration of Figure 2 can be set up. It is not necessary
that both paths become operational at once, but we expect that
the TIP-based path will be ready for use at that point, i.e.
there will be an operational TCP-based terminal system on the
UCL PDP-11. The TCP/X25 LSI-11-based path will be strictly
for experimental development at this point, investigating the
nature of the connections needed to support the appropriate
services. It is not clear whether XNET can be used
satisfactorily across SATNET, and any development strategy
based on XNET may have to be reconsidered at this point.
iii) When the X25/TCP path is ready for service use it will
become the main service route between EPSS and ARPA. Either
now, or at some other time, the PDP-11 could be directly
connected to the LSI-11 gateway, and at some time it will
probably support multiple terminals directly. When all these
conditions are fulfilled, the TIP could be removed completely.
No doubt this possibility will be looked at more closely when
the time comes.
SATNET and the Provision of Transnet Service Page 9
3. Detailed Requirements
This section describes the software needed in the various machines
to support the service outlined above. This is done machine by machine.
The proposals try to make the minimum changes needed to existing systems
or to current plans. Attention is drawn to points on which we need more
information, or which we know or believe to be incompletely developed,
and also to areas in which problems are expected.
3.1 UCL TIP
No functional changes are envisaged for this machine, which will
continue to support terminal access as at present. The major change
will be updating the routing tables to reflect the absolute isolation
the TIP will experience. The major problem which BBN will encounter
will be in providing the same remote maintenance and monitoring
facilities it has at present. One possibility is to retain the direct
lines that ARPA currently maintains to the SIMPs (e.g. the 9.6 kb line
between London and Goonhilly), as this is the simplest way to provide
direct access to our isolated TIP. However, this is a problem for
forces beyond our control.
3.2 UCL PDP9 Access to EPSS
No major functional modifications to the existing SWITCH system are
expected here for providing terminal-level access. Other services can
be set up as concatenated terminal streams. If the EPSS File Transfer
Protocol is adopted for transnet service, this will be sufficient to
provide an adequate. If not, then the current EPSS FTP/ARPA FTP mapping
will be used. The resulting configuration is shown in Figure 3.
There is some question as to how much work the full PDP9 system can
support simultaneously. If serious overloading occurs, some of the
special systems supported (e.g. the Culham link) may be removed from
the standard system; if even this is inadequate, then the position of
the FTP facilities may be reconsidered.
SATNET and the Provision of Transnet Service Page 10
Figure 3 - Terminal Access to EPSS via the PDP9
3.3 UCL PDP-11
The PDP-11 is the first machine considered which will require
significant effort to bring up. Much of the new software required has
either already been developed or is currently under development by BBN,
notably TCP, TCP-Telnet, and these can be run under ELF, which we at UCL
have some experience with. ELF has some disadvantages as an operating
system to support user services, however. The principal one is that, to
the best of our knowledge, it does not support either the NCP or the
standard ARPA FTP. This point should be checked. The lack of an FTP
would be unimportant if the EPSS File Transfer Protocol is adopted;
however the lack of adequate NCP facilities is critical. Also, we would
prefer to use an operating system with terminal drivers capable of
handling multiple users, as we ultimately expect to be using this
machine as a terminal concentrator to replace the TIP. The main new
item which has to be tackled in this system is providing a connection
between NCP-based Telnet sockets and TCP-Telnet ports. As a gateway
between two transport protocols (TCP and NCP) this machine will also
have to handle the usual readdressing, flow control and reassembly
problems handled by gateways.
The configuration under consideration is illustrated in Figure 4.
The existing local host interface will not be used, and connection to
the TIP will be via the VDH, as the two local host ports on the TIP are
taken up by the PDP9 gateway to EPSS and the LSI-11 gateway to SATNET.
The looped nature of the traffic may create some unusual flow control
problems when there are heavy traffic rates. For this reason, when the
file transfer facilities are developed for this machine, onward transfer
to EPSS will be done in a staged fashion, with the file being
temporarily stored on the RK05 disc.
SATNET and the Provision of Transnet Service Page 11
Since we have not been directly involved with the work, one major
question on which we lack hard facts is the question of choosing an
appropriate operating system. As we have indicated, ELF does not seem
to be suitable for a major service role of the kind implied here. The
major PDP-11 operating systems that seem to be suitable, both because
the expertise is available in the department and because TCP
developments are taking place on them are UNIX and RSX-11M. TCP version
2.5s have been developed by BBN under UNIX and ELF; version 3 of TCP is
currently being developed by DTI under UNIX and by CCA under RSX-11M.
The only system under which a TCP-Telnet seems to be developing is ELF.
Further information must be obtained about these points.
Two other points are relevant here. The first is that it would be
highly desirableable to be able to use the same operating system here as
we do on the remote transport gateway (see section 3.7) if this is to be
a PDP-11; this would considerably speed up the development of the whole
system. Secondly, we have to investigate the cross-net loading
facilities. The great advantage of ELF is the fact that it is
specifically tailored to run with XNET. With other operating systems we
will almost certainly require a special bootstrap to be able to use XNET
at all, and it is unlikely that we will be able to use its full
facilities even then. For debugging purposes this is not so serious,
but for cross-net loading it is vital.
Figure 4 - PDP-11 Configuration
3.4 UCL PDP9 - Access to X25
Here, the anticipated course is that the current system will
develop along its existing lines, with the complete excision of the
current ARPANET software. For transnet communication an EPSS user will
access the X25 port, which will also support incoming connections from
ARPANET. The present SWITCH system running on this machine, supporting
SATNET and the Provision of Transnet Service Page 12
the EPSS VPT and FTP, will be the standard system on the PDP9 which is
connected to the TIP. Both Level 2 and Level 3 of X25 are currently
available, and although it is designed basically as a DCE we anticipate
no great difficulty in turning it into a DTE if required. This point,
however, requires more detailed study. Calls coming in from EPSS will
automatically be forwarded to the LSI-11 if no EPSS address is included
in the data field. In the reverse direction, calls being forwarded to
EPSS will require an EPSS address in the data field, but these must be
provided by the LSI-11. This scheme fits into the current context very
well, and we see no reason not to retain it.
Figure 5 - UCL PDP9 - X25 Access
3.5 UCL LSI-11
Essentially, this machine will consist of an X25 terminal and a TCP
terminal connecting an HDLC interface on the one side to a BBN 1822
interface on the other through a number of mapping modules. The basic
structure is shown in Figure 6. The X25 hardware for this configuration
has recently been completed, and the 1822 interface is nearly ready.
The software, however, is in a rather more uncertain state, and it is
expected that this terminal will remain an experimental link for some
time.
As with the PDP-11, it is not clear what operating system this
machine will use, although the alternatives are fewer: either the
current TCP terminal, available under MOS, is altered to run under
RSX-11, or the current X25 terminal, available under RSX-11, is altered
to run under MOS. RSX-11 will support development in a high-level
language (RTL2), but it is doubtful whether this is advantageous, as the
generated code is large. Also, whichever system used will initially
have to support crossnet loading (and possibly development) of the
TCP-terminal software. This question is an unknown for both systems,
and urgently needs resolution.
SATNET and the Provision of Transnet Service Page 13
The TCP side of the terminal is based on the packet-radio TCP
terminal developed at SRI. The major difference is the replacement of
the DSP, which is packet-radio dependent, by an XNCP-like module for
communication with the gateway. This raises two problems. The first is
the unorthodox nature of the 1822 connection, in that neither side of
the HOST/IMP interface supports what would normally be understood as an
IMP. There is, however, a precedent for this situation, as COMSAT has
built a similarly non-standard connection between its 360 and its PDP-11
gateway, so we should be able to consult them for guidance for potential
problems. Moreover, 1822 is a highly symmetric interface, so major
problems are not anticipated. The second problem is that this module
will initially only support a single TCP port, whereas there is a strong
requirement for supporting several ports for different services.
However, creating a multiplexing 'XNCP' is not the whole solution to the
problem, as we will then be able to support several TCP connections only
if they go to different hosts. Unfortunately, we need to support
several connections to one particular host (i.e. the remote transport
gateway in ARPANET - see section 3.7). This will require modifications
to the TCP itself.
Our current X25 is written in RTL2 or in assembler versions derived
from it, and is rather large in its RTL2 version. The VPT is a larger
RTL2 program. While the generated assembly code is believed not to be
highly system dependent, this aspect has not been analysed in detail -
the driver for the HDLC chip is a particularly important question here.
On the face of it, therefore, it would seem to be easier to put X25
under MOS than to put TCP (written in MACRO) under RSX-11 from the point
of view of aiding development. The RTL2 code has been written so that
it can be run as both as X25 DTE and a DCE, and one problem under
investigation concerns deciding when it should be one or the other. A
study of the incorporation of the X25 software into MOS should be
undertaken very soon.
Finally, there is the connection between the X25 side and the TCP
side. At this stage, it is not possible to say much more about this
than to state the functional requirements. Terminal access will require
a mapping between the X25-VPT and the TCP-Telnet; this will undoubtedly
be based on our experience with similar problems in the PDP9 SWITCH
systems. File transfer may also need to be mapped, and will certainly
require support of high-throughput connections on both sides; the
evolution of suitable strategies to match the flow will have to be
evolved. These modules will also have to solve the questions of forward
addressing and routing. In the service gateway context, these functions
become more important than the mappings.
The question of how this code is to be developed has still not been
satisfactorily resolved. There are two main options. The first is to
develop it in our PDP-11, using XNET to load in the system. This
requires a MOS-based VDH driver for a DMA interface, which is currently
being written. The second option is to load the LSI-11 directly, using
one of our local host ports on the TIP. This requires the completion of
the 1822 interface, which is proceeding rapidly. Other options, such as
storing the software on floppy discs, are basically variants of these.
SATNET and the Provision of Transnet Service Page 14
Figure 6. UCL LSI-11: TCP Access Configuration
3.6 Gateway LSI-11s
No special role is envisaged for these gateways, as end-to-end
transport is being provided entirely by TCP at this point. It is not
clear how far development on LSI-11 gateways has progressed, as opposed
to PDP-11 gateways; this is a question which must raised with BBN. One
problem that may well affect the schedule is that our preliminary
calculations suggest that access to the VDH line will have to be via a
DMA interface if high throughput is desired and the machine is not to
spend up to 50% of its time servicing interrupts from the interface.
Critical questions for this machine, then, are the development of
MOS-drivers for DMA VDH interfaces, and the ability of the gateway to
handle more than two nets - the 'nets' here being SATNET, the TCP/NCP
PDP-11, and the TCP/X25 LSI-11.
It is conceivable, if TCP develops concepts of selecting grades of
service from local nets, that we may become interested in developing our
ideas in these gateways as well as the ones already discussed, but this
does not seem to be on the current schedule of TCP development and in
any case would have to be coordinated very closely with BBN.
SATNET and the Provision of Transnet Service Page 15
Figure 7 - UCL SATNET Gateway Configuration
3.7 TCP Service Gateway in the ARPANET
Finally, a site in the ARPANET must be selected to provide the far
end of the TCP pipeline. The development needed here is very similar to
that discussed in section 3.3, and developing both ends simultaneously
on PDP-11s under the same operating system, as we did for GNOME, could
speed up the process considerably. However, the system support and
system resources we could draw on are likely to be limited unless
coupled with a TENEX. Differences between the two sites will emerge at
later stages in the development. These will be mainly connected with
addressing and routing problems: this machine will act as a service site
for the whole US ARPANET, whereas the UCL PDP-11 will only service EPSS
traffic through the PDP9.
The other alternative is to use a TENEX or TOPS-20 system for this
end of the connection, as TCP and TCP-Telnet are both available, and
they have proved and extensive resources for such work. However, this
will mean developing two versions of the new software, and will also
involve experimenting with special versions of standard software (such
as ARPA-Telnet, FTP, NCP) which may lead to organisational problems, as
these are machines supporting large user populations. This question
will again have to be gone into more deeply.
SATNET and the Provision of Transnet Service Page 16
Figure 8 - TCP Service Gateway Configuration
SATNET and the Provision of Transnet Service Page 17
4. Conclusions
In this note future ARPANET service is considered from several
points of view. Firstly, there is the problem of providing UCL users
with terminal access to ARPANET via SATNET. Secondly, access has to be
provided between EPSS and ARPANET for a variety of services. Initially,
this will be of the terminal mapping type already in use, but the design
proposed has hooks for extension towards a more sophisticated concept of
supporting service gateways. Where possible, the scheme uses existing
systems, or systems already under development. Obviously, there will be
problems in modifying these to meet the new requirements, but the scheme
outlined has attempted to minimise these, and at the very least to
identify them.
Integration of the various components into a unified system
requires most software work at the points where various layers of
trsnsport protocol terminate and have to be connected to the next level.
The two most critical points for providing a general transnet transport
service are in the TCP service gateway in ARPANET and the TCP/X25 LSI-11
at UCL. A similar critical point occurs in the PDP-11 at UCL. The PDP9
giving terminal access to EPSS from UCL is not critical as this problem
has already been solved. Again, a solution for the transport connection
between the EPSS Bridge and X25 is already in existence to the point
where the LSI-11 will be seen as a host on EPSS when it is connected to
the PDP9.
Specific areas where we anticipate difficulties with existing
software are: the remote loading (and debugging) of non-ELF operating
systems for the PDP-11; the choice of an operating system for the
LSI-11; the nonstandard nature of the 1822 interface connecting this
machine to the gateway LSI-11; the use of XNET across SATNET; and the
provision of a DMA VDH interface on the gateway LSI-11s, to connect them
to SATNET. Areas on which we need further information include: the
status of TCP and TCP-Telnet under various standard PDP-11 operating
systems; the current status (or even the existence!) of the TCP-FTP; the
current status of LSI-11 gateways; and information that we can get about
activities such as the non-standard 1822 connections which have been
undertaken by other groups.
In short, the components required to connect UCL and EPSS to
ARPANET via SATNET are on the whole either already in existence or
already under development. The new work is in sticking them together in
such a way as to provide adequate transnet service.