This article also appeared in the July 1991 edition of Network News.
An operational pilot (called Shoestring) for the planned JANET IP Service (JIPS) has been underway since March 1991. The aims of the pilot include:
It is expected that the Shoestring pilot will continue until invitations to connect to JIPS are issued to institutions. At present it is still anticipated that this will be possible in October 1991. The rest of this article describes progress to date (mid July) in achieving the aims stated above.
The pilot is being carried out as a co-operative venture between approximately fifteen institutions within the community, all of whom are providing expertise, effort and in some cases loans of equipment. The JNT is very grateful for the high level of commitment and enthusiasm shown by members of the pilot, without whom such rapid progress would not have been possible.When launched, the JIPS will consist of a JANET-wide backbone of routers set up to carry IP traffic between connected sites. The technology used will be so-called "IP tunnelling" ie the use of JANET's X.25 service to encapsulate and deliver IP traffic. The backbone of routers is being established in the pilot by placing one router at each of the JANET NOCs (Network Operation Centres). These routers will constitute the management framework for the JIPS. When an institution connects to the JIPS it will be assigned a tunnel to the NOC router at the NOC that serves its normal X.25 connection to JANET.
The routers that have been chosen for this task are cisco AGS/3 devices. These have been purchased and installed for all NOCs (except Belfast where the router is now on order for installation before the start of the JIPS). The configuration and subsequent management of the backbone routers is being contracted to the London NOC (at ULCC). To date the pilot's backbone has consisted of Cisco routers placed at ULCC, RAL and EUCS (and loaned by the institutions involved in the latter two cases). Following successful configuration of the NOC routers, it is now scheduled that the permanent backbone will be established at the end of July.
The objective of the establishment of a backbone for JIPS is to allow central management of the service. This will comprise routing decisions (i.e. to make the best use of the underlying JANET X.25 service), statistics gathering, and (where necessary) the enforcement of access control policy. To achieve this the architecture being adopted for the connection of an institution to JIPS is that the institution will connect via a single router, placed at the end of the tunnel provided by the router at the NOC normally serving the institution. The institution's router will not be required to participate in the routing exchanges used by the backbone - it will be required only to pass all JIPS traffic to the nominated NOC router. (The institution will have to provide JIPS management with details of which IP networks exist on site, so that these can be made known to the backbone, but these will be loaded into static tables, not deduced dynamically.)
A schematic diagram of the pilot network to date is shown in the accompanying figure. This shows the NOC sites, with those institutions connected as part of the pilot. (Apart from Bath and Belfast, all NOC sites are also participating institutions.) New pilot sites, that will connect immediately after the NOC backbone is established, are also shown. Note that the links shown between the NOCs are the X.25 links, not necessarily IP tunnels. In fact the NOC routers will be fully interconnected (ie each will have a tunnel to all the others) in the first instance. This should provide the most efficient IP path through the backbone, albeit at the expense of some tunnels being lightly used most of the time.
Access to the Internet abroad is accomplished via the London NOC. For access to the rest of Europe the route is via the use of the IXI network to the router established at NIKHEF in Amsterdam as part of the RIPE initiative. For access to the US and the rest of the world, the "fatpipe" to NSFNET is used. In order for institutions connected to the Shoestring pilot to be able to interwork with the Internet, it is necessary that they are registered with the appropriate RIPE and Internet authorities. The somewhat labyrinthine procedures for doing this have now been understood and successfully completed for the networks attached to the pilot. In future this should be a very straightforward process, completed as part of the JIPS connection procedure.
In order to make effective use of IP connectivity, it is necessary that an institution has access to the Domain Name Service (DNS). This is the basic name-to-address translation mechanism used in the IP environment, and may be roughly compared to the use of the NRS in the Coloured Books environment. However, unlike the NRS, it is implemented as a hierarchical system of communicating nameservers, each of which is responsible for both holding name-to-address translation information for systems in the domain it serves (so that other DNS nameservers may access this information) and for providing translation facilities for users of systems in its domain. (In fact a user may query any nameserver in the Internet to resolve a translation. Normally, however, it is more efficient and reliable to use a nameserver "close to home" ie on the same local network.) Use of the DNS will have to be coordinated on a national basis, with a DNS nameserver for the entire UK.AC community (or "ac.uk" in DNS ordering!) run as a central JIPS entity. This will be supplemented by DNS nameservers at each institution connected to the JIPS, each of which will be responsible for the maintenance of name and address information for systems within the institution.
Up to now there has been a relatively small need for centralised DNS facilities in the UK, and this task has been carried out on a semi-formal basis by UCL. With the inauguration of the JIPS, responsibility for this task on behalf of "ac.uk" will be taken over by the London NOC, although they will continue to work closely with UCL at the outset. Within the pilot, a number of institutions have now successfully configured their local DNS nameservers and connected them to the global DNS, allowing access to name-to-address translation throughout the Internet. The experience gained in doing this is being collated so that subscribers to the JIPS will have the benefit of practical advice and guidelines.
Within the pilot a number of tests have already been made to assess the likely performance of IP over JANET. Not surprisingly, this has proved to be a complex area, as the number of variables is high.
So far, tests have been made across the JANET 2 Mbps infrastructure, but with the routers connected at 1 Mbps. Throughput values of up to 800 Kbps at user level have been obtained with careful tuning, although it needs to be emphasised that these are obtained under near-ideal conditions. Moving to 2 Mbps has uncovered some low-level engineering bugs in the routers which are currently under investigation by the manufacturers. (The emergence of operational problems with network equipment when line speeds of 2 Mbps are used is not confined to routers - there have been problems reported with some X.25 switches as well. It appears that once again the JANET community is at the leading edge of technology, pushing suppliers' equipment to its limits, and helping them iron out the inevitable bugs that are only found when such systems are subjected to in-service use.)
From the limited information obtained so far, it is clear that current IP technology, in the end systems and in the routers, will be capable of placing a heavy load on the facilities of JANET Mark II. It is also clear that our links to the outside world, and to the rest of Europe in particular, will for the immediate future offer considerably less throughput than will be obtainable over JANET.
Pilot experience is leading to an increasingly well-defined set of requirements that will be placed on institutions wishing to connect to the JIPS when announced. These will include the following.
Because the JIPS backbone routers will handle all IP routing decisions on behalf of the institutions connected to the Service, it will not be necessary that the latter's routers have the full functionality of a backbone router. (In fact an institution's router will be required to forward all JIPS traffic direct to a designated backbone router, and will not take part in the exchange of routing information with the backbone routers.) This means that it will be possible to utilise a less functional unit than (for example) the cisco products. However, it should be borne in mind that management of routing is not the only consideration when making the decision. For example, some institutions may have a requirement to perform some access control at the JIPS connection point - for example, either to disallow outside access to certain services, or to prevent access to JIPS by certain classes of institution user. In such cases a more functional unit will also be required.
In the category of less functional routers, participants in the pilot have successfully used Netcomm's ECB and Sun's X.25 routing product (part of their Sunlink X.25 package) to connect to the backbone. It is planned that detailed advice will be available to institutions wishing to connect to the JIPS on the relative merits of these and possibly other routing devices as a means of connecting.
When the Computer Board laid out the policy framework for the JIPS, it did so on the basis of advice provided by the JNT to the Network Advisory Committee. This advice was in turn based upon recommendations made by the JNT's Advisory Group on IP protocol issues (the DoDAG).
As was explained at the Aberdeen Networkshop, the Computer Board decided that, in the interests of protecting existing connectivity, and of ensuring that its policy of a timely transition to OSI remained effective, not all possible protocols that can run over IP should be allowed to run over the JIPS. The Computer Board laid down three categories of service.
One of the Shoestring pilot's remits was to study whether this policy framework was appropriate in practical use, and to make recommendations to the JNT accordingly. This process has started already, and interest has focused on the areas of limited use of NFS in the provision of access to read-only, public-domain software archives (where the security issues are not so relevant), and in allowing some use of SMTP (where a number of UK experts feel that there is added value to be gained in the use of SMTP). It is as yet too early to report on the results of this process, as it is necessary to gather operational experience before reaching a recommendation.
It has not been possible in this article to explain in any level of technical detail the reasoning behind the issues handled within the pilot. For those that are interested in further information there is a mailing list "janet-ip@jnt" on which are published the minutes of the regular pilot meetings. These minutes also catalogue the various papers generated by the pilot - most of these are available upon request to those interested. Approach the JIPS Service Manager (Bob Day, R.A.Day@uk.ac.jnt) in the first instance.
Equally importantly, users at sites participating in the pilot are encouraged to try out its facilities and provide feedback. If you are located at one of the sites contact your Computing Services to find out how access to the pilot is arranged at your site!
Atlas Centre users who have read Bob Day's article on the progress of "Project Shoestring" may wonder how they will benefit from an IP service over JANET. Put simply, users at remote sites will be able to utilize a range of facilities which will enable them to make better use of the Atlas Centre's facilities.
At present, users do not have direct access to the Cray; they have to use it via a "front-end". The use of IP changes all this and opens up a range of possibilities. IP is a communications protocol used extensively on local area networks and, having been around for a number of years, it has given rise to a wide variety of diverse applications which offer very good communications functionality. These include:
By the end of the year, we hope to provide a new UNIX-based Cray front end to supplement the existing CMS and VMS services. A key function of this new front end will be to provide full TCP/IP support, including X-Windows, so that users can enjoy X-Windows services without placing the heavy load, associated with interactive usage, directly upon the Cray. It is for this reason that use of X-Windows directly on the Cray is not being encouraged.
With the arrival of the new front end and the advent of UNICOS 6.0, users can look forward to a range of new performance, programming and debugging tools for X-Windows to help to increase their productivity on the Cray. (See Nigel Jagger's article "UNICOS 6.0" in the previous issue for more information.)
Remote IBM users will also benefit from the introduction of the JANET IP Service. Currently, some users only have line mode access to the IBM. Those who have experienced this will appreciate that it is far from an ideal means of interaction, as CMS was designed for full screen mode 3270 terminal access. IP access offers some relief to this situation.
Both IBM and VMSFE users will also be able to use ARPA-FTP, in addition to the existing "Blue Book" FTP services, together with a wide range of applications designed to make working over a network easier and more functional.
For users based at "Shoestring" pilot sites, some of these facilities may already be available and they are welcome to try them. The full JANET IP Service, or "JIPS" for short, is scheduled to start in October, and, with the Cray Unix front end likely to arrive at a similar time, I would encourage users to ensure that their local computing centres register for connection to the JANET IP service at the earliest opportunity. Once sites are connected, suitably equipped and connected hosts, workstations and PCs will be able to communicate directly with machines both at RAL and around the world. Larger machines and workstations are likely to have existing connections to site Ethernets. Personal computers, however, will probably require some additional hardware and supporting software; talk to your local computing centre about what is required for your machine.
A formal agreement has recently been concluded between Harwell and the Numerical Analysis Group at the Atlas Centre concerning the future development and marketing of the Harwell Subroutine Library. As you will recollect from earlier articles in Flagship, the Group moved from Harwell to Rutherford Appleton Laboratory just over a year ago, and while it was at Harwell one of its main responsibilities was for the Harwell Subroutine Library. Since then, the situation has been somewhat in limbo with Harwell continuing to market the codes and the intellectual property rights on current development work being in some doubt.
The agreement has resolved these issues and we believe also provides significant side-benefits for users of the main supercomputers at the Atlas Centre. The main points of the agreement are that the Harwell Subroutine Library will continue to be developed and supported by the Numerical Analysis Group and will be marketed by Harwell with revenues shared between SERC and Harwell. The Library will be updated on a regular basis, the current release being Release 10 as presently marketed by Harwell.
As part of the agreement, the Atlas Centre will have royalty free licences for the use of the Harwell Subroutine Library on both the IBM 3090/600 and the CRAY X-MP. Release 10, which is a significant upgrade on the version currently at the Atlas Centre, will be available shortly and details on how to access the codes will be broadcast on News on the IBM 3090. Documentation on the subroutines available and details of how to use them will be held by User Support.
In the first instance, enquiries about use should be directed to Jonathan Wheeler, Applications and User Support, Atlas Centre (US@UK.AC.RL.IB) although the Numerical Analysis Group will, of course, answer any detailed enquiries and are happy to consult on the use of HSL subroutines.
Users wishing to mount and use HSL on machines in their own University can obtain licences through Harwell (Elizabeth Thick, Bldg 424.4, Harwell) although arrangements are in place for royalty free licences for collaborative research work, for which enquiries should be addressed to the Numerical Analysis Group.
A routine for calculating the eigenvectors and eigenvalues of real unsymmetric matrices, EB12, will shortly be available. This routine is designed to be particularly useful for computing eigensystems of large sparse systems and only products of vectors by the matrix are required from the user. An appendix to a Rutherford report contains a detailed specification sheet on the use of this routine. Details of how to access this code will be given shortly in a IBM 3090 News message.
Duff, LS. and Scott, J.A. (1991). Computing selected eigenvalues of sparse unsymmetric matrices using subspace iteration. Report RAL-91-056, Rutherford Appleton Laboratory.
RAL-CGM release 2.0 is now available. The changes since the last release can be broken into two parts, first the changes to the main program (and the way it operates), and second, changes and updates to the individual output drivers. Along with the listed changes go bug fixes and performance improvements. These will be considered in the following sections.
The major improvement is the inclusion of several environment variables affecting the way in which RAL-CGM operates.
This diagram was written as a CGM, output from RAL-CGM as encapsulated PostScript and originally included in a IBM DCF document which was sent to a PostScript printer. In order to be printed in FLAGSHIP the encapsulated PostScript file was converted to an IBM 4250 page segment.
A second group of environment variables is now available to change the output defaults for individual drivers. Currently available are CGMPSOPT, CGMVGAOPT, CGMXWOPT and CGMIGLOPT.
For the setting of these variables refer to the options available for the required driver.
The only major improvement to the X11 driver is the introduction of pixmap backing store for servers which are not capable of handling backing store themselves. This means that all exposure events are handled properly, even on simple window managers: i.e. if the window is covered and then uncovered, the picture will refresh correctly.
This driver has been quite dramatically improved. There is now full support of colour PS. (It should be noted that colour PS can not be sent to B/W PS devices - this is a PS deficiency!) The driver can now produce encapsulated PS (EPSF), this means that output from RAL-CGM can now be easily included into your PS documents. For users of the IBM, who are using PostScript output devices, (which are rapidly becoming popular within RAL) this provides a simple method of importing diagrams into DCF documents. The diagram in this article was written as a CGM, and then included in a recent CCD document in this manner. Also, it is now possible to turn on and off the picture border that the PS driver used to place around the output and to specify "Landscape" or "Portrait" orientation. All of these options are independent, and can be mixed at will. Indeed for encapsulating images into documents the normal form would be EPSF without the picture border.
The driver for the Silicon Graphics IRIS has been modified to allow random frame access, and now uses pop-up menus to control the display.
This is a completely new driver. It provides an output device for IBM PC compatibles, with VGA style graphics. The driver is complete and responds to all the standard CGM elements, with the exception of user defined patterns. The driver will compile with Microsoft C only.
The only significant change to the system code is for the VAX. The input/output format for binary CGMs has been changed so that RAL-CGM will read and write files that are interchangeable with most other common packages (e.g. UNIRAS), on the VAX.
RAL-CGM has proved to be a very popular package, with over a hundred requests for it, ranging from people in Informatics Department at RAL, to someone from the University of New Orleans in America!
RAL-CGM has found many uses within the Central Computing Department, too. Large amounts of video footage have been made from CGMs, some of which have even arrived as part of an ordinary mail message! It has even been shown that in some cases it is as easy to draw a diagram by typing it in as a clear text CGM as it is to use a design package; the diagram included with this article was prepared in this way.
The source code is still available through the Kent University software distribution scheme, but now there is a second way of getting software from Kent, that is via NIFTP.
The PC version of the code will be available in an executable format from Lancaster pdsoft, however the details of this are not yet available. RAL-CGM is being distributed by the following routes:
RAL-CGM for UNIX can be obtained either on a tape or over the network. The end result of all methods is to have a tarfile, which we will discuss further on.
There are three ways to get your tarfile, two over the network, or you can get it on a tape.
send encoded.tar from ralcgmYou should receive a number of big files and a single small file which contains a script and instructions to glue the separate files back into a large file (the size of which will be around 1.7 Mb). Name this, say, tarfile, then
uudecode tarfileshould produce a file called tarfile.z. (Warning: some UNIX systems may not have the uudecode command. It is hoped, however, that every installation will have at least one machine - Sun for instance - that does. Failing this get the tarfile on a QIC tape, see below).
zcat tarfile.z > ralcgm.taror
uncompress tarfile.z mv tarfile ralcgm.tarwill generate the original tar file, of about 3.8Mb, (the the former will leave tarfile.z on your filestore, the latter will not). To deal with this tarfile, see the following section.
tar -xvof ralcgm.taror, if the tarfile is on tape:
tar -xvof /dev/rstO
NOTE: The device name (rstO in the above) is system dependent.
This will create the correct directory structure. The top directory will contain a file called README which gives instructions on how to complete the installation.
RAL-CGM for VAX/VMS can be obtained over the network with the following VAX command:
$TRANSFER/CODE=FAST - UK.AC.RL.VE::RALCGM1.BCK - RALCGM1.BCK RALCGM DISTRIBUTION
This will fetch a copy of the VAX/VMS saveset, about 4 Mbytes, called RALCGMl.BCK from a VAX at Rutherford.
To install RAL-CGM from the saveset:
$BACKUP/LOG RALCGM1.BCK/SAVE/ - SELECT=[RALCGM...]*.* [...]This will unravel the saveset into the correct directory structure. The top directory will contain a file called README which gives instructions on how to complete the installation.
RAL-CGM version 2 uses the UNIX/C language command line interface so options are preceded with a minus sign, rather than in the normal VAX /option form. See the help library for more details of the options and the format to use.
This is a two year project funded by the Computer Board and based at the University of Exeter's Computer Unit. The overall aim of the Project is to explore and encourage the use of the Standard Generalized Markup Language (SGML) within the Universities and Research Council establishments of the United Kingdom.
Anyone interested in text processing will need to know about SGML and what it can do for them - whether their background is in Computing, the Arts, Social Sciences or pure Science. As well as being an internationally recognized ISO standard, it is being laid as the foundation stone of document manipulation in a wide range of environments - from the offices of the European Community to HMSO and the American Department of Defense, from IBM to Boeing and Fujitsu. Many publishers are investing in SGML-based products to accelerate the production process, and provide them with new ways to access and present their authors' works. SGML can also be used to simplify document interchange, facilitate the multiple-authoring of papers, and form a basis for developing hypertext and hypermedia systems.
In more detail, the aims of the Project are:
The Project is committed to making all its findings widely available in the form of regular on-line and paper reports. We shall be writing to the management of the computing services at every academic and Research Council establishment in order to build up a mailing list of contact names. However, we are also interested in liaison with staff from any department who believe they may have a use for SGML.
