I'm currently in the process of uplifting our DNS development / operations repository from SCCS (really!) to git. This is not entirely trivial because I want to ensure that all the archival material is retained in a sensible way.
I found an interesting document from one of the oldest parts of the archive, which provides a good snapshot of academic computer networking in the UK in 1991. It was written by Tony Stonely, aka <firstname.lastname@example.org>. AJMS is mentioned in RFC 1117 as the contact for Cambridge's IP address allocation. He was my manager when I started work at Cambridge in 2002, though he retired later that year.
The document is an email discussing IP connectivity for Cambridge's Institute of Astronomy. There are a number of abbreviations which might not be familiar...
- Coloured Book: the JANET protocol suite
- CS: the University Computing Service
- CUDN: the Cambridge University Data Network
- GBN: the Granta Backbone Network, Cambridge's duct and fibre infrastructure
- grey: short for Grey Book, the JANET email protocol
- IoA: the Institute of Astronomy
- JANET: the UK national academic network
- JIPS: the JANET IP service, which started as a pilot service early in 1991; IP traffic rapidly overtook JANET's native X.25 traffic, and JIPS became an official service in November 1991, about when this message was written
- PSH: a member of IoA staff
the Rutherford Appleton Laboratory, a national research institute in Oxfordshirethe Mullard Radio Astronomy Observatory, an outpost at Lords Bridge near Barton, where some of the dishes sit on the old Cambridge-Oxford railway line. (I originally misunderstood the reference.)
- RGO: The Royal Greenwich Observatory, which moved from Herstmonceux to the IoA site in Cambridge in 1990
- Starlink: a UK national DECnet network linking astronomical research institutions
Edited to correct the expansion of RA and to add Starlink
Connection of IoA/RGO to IP world --------------------------------- This note is a statement of where I believe we have got to and an initial review of the options now open. What we have achieved so far ---------------------------- All the Suns are properly connected at the lower levels to the Cambridge IP network, to the national IP network (JIPS) and to the international IP network (the Internet). This includes all the basic infrastructure such as routing and name service, and allows the Suns to use all the usual native Unix communications facilities (telnet, ftp, rlogin etc) except mail, which is discussed below. Possibly the most valuable end-user function thus delivered is the ability to fetch files directly from the USA. This also provides the basic infrastructure for other machines such as the VMS hosts when they need it. VMS nodes --------- Nothing has yet been done about the VMS nodes. CAMV0 needs its address changing, and both IOA0 and CAMV0 need routing set for extra-site communication. The immediate intention is to route through cast0. This will be transparent to all parties and impose negligible load on cast0, but requires the "doit" bit to be set in cast0's kernel. We understand that PSH is going to do all this [check], but we remain available to assist as required. Further action on the VMS front is stalled pending the arrival of the new release (6.6) of the CMU TCP/IP package. This is so imminent that it seems foolish not to await it, and we believe IoA/RGO agree [check]. Access from Suns to Coloured Book world --------------------------------------- There are basically two options for connecting the Suns to the JANET Coloured Book world. We can either set up one or more of the Suns as full-blown independent JANET hosts or we can set them up to use CS gateway facilities. The former provides the full range of facilities expected of any JANET host, but is cumbersome, takes significant local resources, is complicated and long-winded to arrange, incurs a small licence fee, is platform-specific, and adds significant complexity to the system managers' maintenance and planning load. The latter in contrast is light-weight, free, easy to install, and can be provided for any reasonable Unix host, but limits functionality to outbound pad and file transfer either way initiated from the local (IoA/RGO) end. The two options are not exclusive. We suspect that the latter option ("spad/cpf") will provide adequate functionality and is preferable, but would welcome IoA/RGO opinion. Direct login to the Suns from a (possibly) remote JANET/CUDN terminal would currently require the full Coloured Book package, but the CS will shortly be providing X.29-telnet gateway facilities as part of the general infrastructure, and can in any case provide this functionality indirectly through login accounts on Central Unix facilities. For that matter, AST-STAR or WEST.AST could be used in this fashion. Mail ---- Mail is a complicated and difficult subject, and I believe that a small group of experts from IoA/RGO and the CS should meet to discuss the requirements and options. The rest of this section is merely a fleeting summary of some of the issues. Firstly, a political point must be clarified. At the time of writing it is absolutely forbidden to emit smtp (ie Unix/Internet style) mail into JIPS. This prohibition is national, and none of Cambridge's doing. We expect that the embargo will shortly be lifted somewhat, but there are certain to remain very strict rules about how smtp is to be used. Within Cambridge we are making best guesses as to the likely future rules and adopting those as current working practice. It must be understood however that the situation is highly volatile and that today's decisions may turn out to be wrong. The current rulings are (inter alia) Mail to/from outside Cambridge may only be grey (Ie. JANET style). Mail within Cambridge may be grey or smtp BUT the reply address MUST be valid in BOTH the Internet AND Janet (modulo reversal). Thus a workstation emitting smtp mail must ensure that the reply address contained is that of a current JANET mail host. Except that - Consenting machines in a closed workgroup in Cambridge are permitted to use smtp between themselves, though there is no support from the CS and the practice is discouraged. They must remember not to contravene the previous two rulings, on pain of disconnection. The good news is that a central mail hub/distributer will become available as a network service for the whole University within a few months, and will provide sufficient gateway function that ordinary smtp Unix workstations, with some careful configuration, can have full mail connectivity. In essence the workstation and the distributer will form one of those "closed workgroups", the workstation will send all its outbound mail to the distributer and receive all its inbound mail from the distributer, and the distributer will handle the forwarding to and from the rest of Cambridge, UK and the world. There is no prospect of DECnet mail being supported generally either nationally or within Cambridge, but I imagine Starlink/IoA/RGO will continue to use it for the time being, and whatever gateway function there is now will need preserving. This will have to be largely IoA/RGO's own responsibility, but the planning exercise may have to take account of any further constraints thus imposed. Input from IoA/RGO as to the requirements is needed. In the longer term there will probably be a general UK and worldwide shift to X.400 mail, but that horizon is probably too hazy to rate more than a nod at present. The central mail switch should in any case hide the initial impact from most users. The times are therefore a'changing rather rapidly, and some pragmatism is needed in deciding what to do. If mail to/from the IP machines is not an urgent requirement, and since they will be able to log in to the VMS nodes it may not be, then the best thing may well be to await the mail distributer service. If more direct mail is needed more urgently then we probably need to set up a private mail distributer service within IoA/RGO. This would entail setting up (probably) a Sun as a full JANET host and using it as the one and only (mail) route in or out of IoA/RGO. Something rather similar has been done in Molecular Biology and is thus known to work, but setting it up is no mean task. A further fall-back option might be to arrange to use Central Unix facilities as a mail gateway in similar vein. The less effort spent on interim facilities the better, however. Broken mail ----------- We discovered late in the day that smtp mail was in fact being used between IoA and RA, and the name changing broke this. We regret having thus trodden on existing facilities, and are willing to help try to recover any required functionality, but we believe that IoA/RGO/RA in fact have this in hand. We consider the activity to fall under the third rule above. If help is needed, please let us know. We should also report sideline problem we encountered and which will probably be a continuing cause of grief. CAVAD, and indeed any similar VMS system, emits mail with reply addresses of the form "CAVAD::user"@.... This is quite legal, but the quotes are syntactically significant, and must be returned in any reply. Unfortunately the great majority of Unix systems strip such quotes during emission of mail, so the reply address fails. Such stripping can occur at several levels, notably the sendmail (ie system) processing and the one of the most popular user-level mailers. The CS is fixing its own systems, but the problem is replicated in something like half a million independent Internet hosts, and little can be done about it. Other requirements ------------------ There may well be other requirements that have not been noticed or, perish the thought, we have inadvertently broken. Please let us know of these. Bandwidth improvements ---------------------- At present all IP communications between IoA/RGO and the rest of the world go down a rather slow (64Kb/sec) link. This should improve substantially when it is replaced with a GBN link, and to most of Cambridge the bandwidth will probably become 1-2Mb/sec. For comparison, the basic ethernet bandwidth is 10Mb/sec. The timescale is unclear, but sometime in 1992 is expected. The bandwidth of the national backbone facilities is of the order of 1Mb/sec, but of course this is shared with many institutions in a manner hard to predict or assess. For Computing Service, Tony Stoneley, email@example.com 29/11/91