Paul Bryant's Networking Correspondence
The most significant activity of this quarter has been the work towards installing the bridge to Daresbury. The work has led to many discussions on the benefits of bridges versus routers and an increase in the understanding of the various protocols.
The discussions have led to thoughts on how the various sets of protocols fit together. We now support coloured books, DECNET, soon SNA, and now TCP/IP. Each one has its strengths and weaknesses each one more or less orthogonal to the others. So where do we go from here? Can we afford to support all these protocols?
Some time ago there was a measure of confidence that the emergence of ISO protocols together with the JNT transition strategy would meet our requirements. The reality is that the emergence of these protocols has been far slower than expected and apart from X.400 the others (FTAM, JTM, and VTP) do not now seem to be useful in the foreseeable future. On the other hand the popularity and utility of DECNET and TCP/IP are evident with most academic local area networks running one or both of them. There is also increasing interest in using SNA. Pink Book has had a slow start and although it has been made to work it is not yet very popular. It is unclear just how well it will be supported by manufactures. Certainly DEC is advocating an alternative strategy.
The CHEP 89 terminal provision was very successful. It illustrated the need for RAL to be in a position to provide such facilities for such events. Delegates now expect to have first class facilities for accessing their home computers.
1.1.1 JTMP Host-end Service
This is now working satisfactorily, with no serious outstanding problems. Also it is running under CMS 5.5.
1.1.2 NIFTP
The command interface to NIFTP via SMSG has been further enhanced and now provides quite powerful facilities for users to monitor the progress of their files, and for User Support to diagnose any problems.
Both the RAL and CERN NIFTP systems are running under CMS 5.5.
1.1.3 NETJOB and NETFILE
The portable user interface for JTMP called NETJOB is now installed and available on the R-disk for public use, together with associated help files, etc. For the time being the original RAL-JTMP user interface (JTMP exec) will remain available also, but it is TRIKE policy to encourage the use of NETJOB.
It is not envisaged that NETFILE will replace the FTP user interface. TRIKE has agreed that it will be sufficient to provide it at the National Centres in parallel with existing user interfaces. At present, work on NETFILE is proceeding as a background activity at relatively low priority.
1.1.4 SSMP
Version 3.0D of the SSMP/3270 package has been installed and is a noticeable improvement on previous versions. In particular there is far less unnecessary cursor movement than before.
1.1.5 Pink Book
Still not a service. Due to other commitments, very little progress has been made during this period and the facilities remain incomplete. It supports incoming line-mode and full-screen terminals, together with CMS-PAD and Q-end FTP. The main deficiency is that P-end FTP is still not included.
The MAC registration database and associated software are complete.
1.1.6 CMS-PAD
No changes.
1.1.7 VTAM
Since April 11, all network traffic has been passing via VTAM, with IBM's EP/NCP/NPSI software in the 4705 front-end. The performance appears to be satisfactory, but the CPU overheads (VTAM and VMNCP combined) are substantially higher in spite of using 1K blocks between the mainframe and front-end instead of 256 bytes.
Reliability was quite a serious problem at first, with hangs or congestion occurring several times per week in either the mainframe or 4705. A PTF for VTAM has since been applied which seems to have eliminated the main problem on the mainframe side. The remaining problems seem to be due to occasional failure to release resources in NPSI, which can cause difficulty for subsequent calls attempting to use those resources.
It may be that these problems will go away when we move to the 3745 front-end, as that uses a far more up to date version of NPSI.
1.1.8 IBM 3745
There was no progress during the period of this report, as the software for the 3745 was still awaited. It has since arrived (mid-June).
1.1.9 Line mode terminal support
The remaining problems with this have been eliminated, and it appears to have reached a reliable and satisfactory state.
Unfortunately, the design inadvertently took advantage of a RAL mod to CP (which allows multiple logon attempts), and so can only be used at other sites such as MCC if a small mod is made to CP. Fortunately a one-line mod suffices, which they say they can live with for the time being. It is not easy to change the design to avoid this.
1.1.10 VMNCP
Changes during this period were mostly to deal with problems arising from the use of NPSI in the front-end.
1.1.11 RSCS
Updates were applied to RSCS to overcome two problems: (1) where international links 'hung' and caused large file queues; (2) where some files were corrupted.
A new 'PARKING' scheme has been introduced and performs well. This scheme enables the operators to place the files for a particular failed link onto a 'holding machine' rather than remaining in the RSCS file queue and degrading performance.
A major problem still requires a solution: RSCS V2 handles the multiple dataset output from MVS differently from V1. This causes problems when sending files to X.25 sites (using the RSCS -> NIFTP driver) and to the local graphics virtual machines. This is being investigated.
1.1.12 TCP/IP and the IBM 8232
The hardware and software were installed, and testing began. The 8232 hardware itself seems to be fine. The software works on the whole, but not without some serious problems. The software has also been tested via the Hyperchannel with a reasonable degree of success. Testing continues.
1.1.13 Routine Maintenance
Nothing specific to report.
1.2.1 It may be possible to bring the 3745 into service in place of the 4705.
1.2.2 There should be further substantial progress with the TCP/IP software and the IBM 8232.
1.2.3 The Pink-Book software will continue to progress as fast as possible towards service status.
In the longer term, migration towards ISO protocols using manufacturer-provide software.
2.1.1 LOCAL
a. Five of the six CPSE incidents were caused by 'store' problems, this was eventually traced to a 'cache' board.
b. SEEL delivered a new systems to support a) 1K packet size, b) Macro file facility for address translation - neither worked.
c. The DECrouter has been connected to the Ethernet, RAL SEEL and DTI London for X.25.
d. The main problem with the power supply for the Pilkington multiplexors has been overcome by removing the supervisor board and running the links over coax instead of fibre. Pilkington intend to replace all the power supplies with a different model in the near future.
e. Camtec PADs still give a range of problems most of which are resolved locally. However a number had to be returned to Camtec for PSU changes.
f. The Line/Modem faults range from loose connectors, linedriver faults, faulty modem (IBM), problems with International connections to Dublin, DESY and CERN. New lines to Swindon (Megastream), CERN (64K digital) and analogue to New College (CHEP89) were handed over by BT with faults on.
g. The CERN 64K line was accepted during April. The multiplexer supplier will install and test muxs early in May.
h. The multiplexors for the Swindon Megastream line have been installed. Problems were experienced when the Lee Data equipment was attached but this was resolved by ensuring RTS was held high at the Swindon end. Users observed errors when the channel speed was set at 1.15Mbps, but not when it was reduced to 48Kbps or transferred to the Kilostream line.
i. The CCD VAX connections were re-organised following the VAX upgrades. The CRAY VAX front end is now connected to the JPSE at 64K X.21 and Dec Vax connected to the CPSE at 19.2K.
j. New lines have been accepted for Brussels, DTI, New College (temporary for CHEP 89) all analogue, and Sheffield, CERN and Swindon (digital).
k. A PAD was connected to the CPSE for CHEP89 conference. This seemed to be well used with an average of over 250 calls per day.
2.1.2 JANET
a. The JPSE still suffers from a high number of breaks, most caused by C.I Timeouts. GPT have reworked the timing circuitry and this mod was installed during the last week of April. (Note, there have been no further occurrences of the C.I Timeout problem since the change. 9/7/89)
b. Other problems appear to have been caused by the reliability of the Megastream/MegaMux equipment. Other NOCs have experienced similar.
c. The Kilostream Plus has now been fully installed and the transfer of individual lines has started. The first few transfers went very smoothly. However problems were experienced when attempting to move the Oxford University connection, it eventually took three visits and the fault was traced to wire wrapping in the Kilostream Plus unit shorting out. (Note all circuits have now been transferred across. 9/7/89).
d. The Manchester PSS gateway, located at RAL, was reconnected to the RAL JPSE because of load-sharing difficulties on the PSS side. PSS have been requested to ensure that both connections are on the same PSS node to allow load-sharing to function correctly.
e. RAL now reports all its JANET BT problems to the MCSC at Chester. It is hoped that this will ensure a more rapid MTTR faults.
f. The analogue lines to Durham and Brunel have now been cancelled and modems/multiplexors recovered.
g. A number of faults on the analogue lines are returned as 'No Fault Found' which suggest that as soon as they connect test equipment the fault disappears. Unfortunately this appears to be happening more frequently.
h. The faults on the 'digital' lines have varied from 'high order' which take out a number of lines at the same time, to simple wiring problems where an engineer decides that the said pair of wires are not really in use so he disconnects them.
a. Installation of CERN Multiplexors and transferral of service onto it.
b. Cancellation of analogue circuits to CERN.
c. Completion of transfer of circuits onto Kilostream Plus.
d. Installation of new PSU on Pilkington Muxs.
e. Rationalisation of BATH Elec Eng connections.
a. Automatic statistics gathering program and monitor for SEEL and Camtec equipment.
The number of faults reported to the sub-section in this quarter is approximately the same as the last.
During the period 104 faults were reported to the sub-section, of which 36 were repaired by sub-section staff, some 35%. The remaining 68 units were repaired by maintenance agencies.
The distribution of agency repairs is as follows:
MSM 37 Movable terminals
KODE 24 Non-movable terminals
SIGMEX 1 Sigmex terminals only
OTHER 6 Warranty repairs
The 104 faults have been analysed for divisional distribution. Of this total, 42 (40%) was CCD and the remaining 60% was carried out for other RAL Departments.
___________________________________________________
| | REPAIR AGENCY | |
|Depart. |_________________________________| |
|-Project| TCOM | MSM | KODE |SIGMEX|OTHER| TOTALS |
|________|______|______|______|______|_____|________|
| ADM | 2 | | 7 | | 1 | 10 |
| AG | | | 1 | | | 1 |
| ALVEY | | 1 | 1 | | | 2 |
| BNSC | 2 | | 1 | | | 3 |
| CCD | 14 | 15 | 7 | 1 | 5 | 42 |
| CO | | | | | | |
| EBW | 1 | 1 | | | | 2 |
| ECF | | 2 | | | | 2 |
| HEP | 8 | 5 | 2 | | | 15 |
| ID | 4 | 3 | 4 | | | 11 |
| INS | | | | | | |
| ISIS | 3 | 4 | | | | 7 |
| LASER | | | | | | |
| ND | | | | | | |
| SL | | | 1 | | | 1 |
| TEC | 2 | 6 | | | | 8 |
|________|______|______|______|______|_____|________|
| TOTALS | 36 | 37 | 24 | 1 | 6 | 104 |
|________|______|______|______|______|_____|________|
No significant changes are expected during the next period.
The installation of coaxial cables for 'full screen' devices has continued unabated as have the offices changes around the site.
The MNP 2400 bps dial-up service came into operation; reports from users indicate it is a very good service.
A new 100 pair cable was installed from Atlas to R65 to provide improved facilities to R12, R63, R65 & R66.
Data links have been provided for the Chessington Payroll Project.
Thin ether cables were installed in the Atlas Centre, R25 and R46.
Communications links were provided for CHEP 89. A PAD and eight terminals were provided at short notice at the instigation of Telecom Section when Lee Data would not provide their terminals on the first day of the conference. These eight terminals proved invaluable during the whole of the conference.
A link was established to UKRCEO in Brussels for the provision of a PROFS service.
More Pilkington multiplexors were installed to allow access for PS/2 devices.
Wiring was provided for the Starlink Emulex P4000 ( replaces four DECservers ).
Visits were made to HSCG to de-commission and re-commission the communications facilities when new furniture was installed.
Discussions continued with Harwell to provide access to the Harwell stores database.
Thin ether to be installed in the west wing of R20.
A second Fanout unit will be installed on the CCD production ethernet in the Telecoms room.
Another ethernet (CCD5) will be installed between Telecomms and the R26 Computer Room North to allow tests of the Vitalink bridges between RAL and DL.
The ground floor lab. in R68 is to be rewired for Space Science Department.
A very much reduced R1 terminal pool is to be rewired.
Terminal wiring should be started in the new TCH conference facility.
A temporary thin ether link will be made to the Colloquium Room.
Thin ether is to be installed around the R65 group of buildings.
Thin ether to various locations around the Colloquium Room.
The R65 complex of buildings will be connected the site ethernet backbone.
Simon Arter left in the middle of April; Peter Gill and Peter Swan-Taylor retired at the end of April.
Brian Day is the Acting Head of Telecommunications Section.
5.1.1 Network Software
CBS V5.0 has gradually been installed on most SERC VAX systems. A few more problems have been experienced with this release. The problem between CERN VAX and RAL IBM reported in the previous report was subsequently realised to be provoked by an incorrect setting on the SEEL switch at RAL. This problem was rapidly rectified. Another problem involved the PAD that hung up the session when packets with the More Bit set arrived. A problem with CBS Mail was found that caused the entire CBS to fall over.
Nevertheless, CBS V5.0 as a whole appeared to be quite reliable and functionally enhanced especially with its better support of NRS and reverse addressing. It would be one of our prime concern to obtain rapid fixes on the problems experienced. We have volunteered ourselves to field test the next release of CBS to ensure this.
Despite a few problems and poor documentations, JTMP V5.0 appeared to be able to function satisfactorily over X.25 on JANET as well as over LLC2. Document tasks do not work with this release.
LLC2 V1.1 has been gradually installed in more sites, particularly those wishing to exchange data between VAX and IBM. There appeared to be some confusion in formulating the NSAP addresses and some considerable efforts have been spent assisting the site managers installing the software.
5.1.2 Network Hardware
The Cray VMS Front-End MicroVAX was upgraded to a cluster of a VAX 8250 and a MicroVAX 3600. A 64K bps line is used between the 3600 and the JPSE. The X.25 interface (DSV-11) has a capability of supporting 2 256K bps lines. X.25 throughput has been significantly improved.
There has been no change of hardware on the development VAX.
The regular networking support of PSI, CBS and Red Book, Pink Book, DECNet, LAVC, PSS/IPSS, VMS-COMMS, EARN and Janet mailshr continues. The NRS updates were continually supplied to SERC sites.
There were some intrusive calls probing machines in early February. The source of the calls were from Hull and warnings have been sent alerting other sites.
The incident appeared to have been stopped but suggestions of allowing restrictive type of login control were made to the site managers.
As advertised previously, this service has officially been stopped at CERN in April.
As one of the sites nominated for CBS field tests, it is hoped that some fixes for V5 would be ready for testing in this quarter.
The Development VAX 11/750 will be phased out and replaced by the MicroVAX II which used to front-end the Cray. Some efforts will be required in migrating all network software to the MicroVAX II.
The EARN G-box has arrived. It will be installed with the latest network software and some initial tests will be made to connect it to the IBM and Ireland G-box.
6.1.1 NJE
No change.
6.1.2 File transfer between EARN and JANET
No change.
6.1.3 MAIL
The mailers will not operate under CMS 5.5.
A new mailer, version 2.03, has been produced by Alan Crosswell and initial tests show that this will also not work under CMS 5.5. It is hoped that this will be sorted out by Alan Crosswell in due course.
There is a worse problem with this system in that the data structures have changed and the exits needed to operate the gateway will not work with this system. Some preliminary work has been done to modify the code in the exits but it is a fairly substantial task.
The code to deal with real names is progressing but there has been some problems with the use of memory which have been difficult to solve.
6.1.4 LISTSERV
LISTSERV now operates under CMS 5.5.
It is now decided to run two LISTSERVs, one in the JANET address space and one in the EARN address space. This will reduce the amount of traffic going through the mailers and will make the operation of lists in the JANET domain far easier. It is unclear what the side effects of having two LISTSERVs are. Certainly the one in the JANET domain is not part of the global family of LISTSERVs which form a sophisticated interlinked system. For "local to the UK lists" this is not important. The largest list, VAXVMS, will probably be moved to the JANET domain shortly.
The "looping mail" problems are now solved.
The rejected mail problems are still with us in that many systems in JANET reject mail from lists when their file stores are full and this returns to "decorate" the Rutherford POSTMASTERs reader.
Eric Thomas who wrote LISTSERV wishes to withdraw his support and the future support of the system is unclear.
6.1.5 EARN management
The EARN Executive has been preoccupied with preparations for the Board of Directors meeting in Crete in May/June. It is important to resolve the funding and budget problems. The details of the EARN transition are also important.
The problems with Eric Thomas and LISTSERV are an irritation that EARN could well do without and it is likely that EARN will take over its maintenance.
The Amsterdam EARN OSI operations centre is now operational and DEC has provided a manager for the site. It will contain two VAX computers and the Northern Telecom network management equipment. EARN will provide a staff member.
6.1.6 Transition
The interconnection of the Northern Telecom switches has still not taken place. Tests between Ireland and RAL have failed and it now turns out that inter switch connections must operate at 9.6K or over. The 64K line to CERN is not yet available, it was expected in mid February.
The UK G-box is delivered and installed. The software has been mounted but no testing has taken place because of the connection problems.
The IBM ISO code has been delivered and mounted but the NJE code has not been provided by Heidelberg yet.
6.2.1 NJE
No changes expected.
6.2.2 File transfer between EARN and JANET
No changes expected.
6.2.3 MAIL
Further development towards adopting the new mailer although it is unlikely to be in use in this quarter.
6.2.4 LISTSERV
No changes expected.
6.2.5 EARN Management
Steps are being taken to deal with the late and non-payment of subscriptions. As the UK is not prepared to pay its full subscription this may effect the service.
6.2.6 Transition
The service should be moved to the 9.6K channel of the HEP line.
The 64K circuit to CERN should be provided and the switches interconnected. G-box testing should be completed.
It is unclear what will happen at the end of the financial year when HEP terminate the use of their line for EARN. It may be that the service will be provided over the EARN or some other X.25 network.
The Hyperchannel and all its connections performed without trouble during the period. On April 24 the new VAX front end to the Cray ceased using the Hyperchannel as its prime route to the Cray in favour of the new VAX Supercomputer Gateway.
An attempt will be made to get New MicroVAX 3600 to work over Hyperchannel as a secondary route to the Cray for Unicos transition. Unfortunately, the existing interface that is supported by Cray is not supported by Network Systems (NSC), and the new interface supplied by NSC that they do support on a MicroVAX 3600 is not supported by Cray.
None.
The licence agreement between CHEST and Edinburgh for the Rainbow Pink Book software was finally agreed and RAL signed their copy at the end of April. The software should be available within a few weeks. Each RAL user will have to sign a non disclosure agreement but otherwise the software is free.
The JNT's PC-COMMS special interest group held its first meeting and produced a list of enhancements it would like to see in the Rainbow software. A driver to support some 3COM ethernet boards is being developed by Daresbury.
TCP/IP and NFS software has been purchased for the PC but there is no effort available to implement it.
A trainee programmer has just started work on writing RAL versions of the IBM SEND and RECEIVE programs so that MOS can support file transfer.
It is likely to be some time before the Rainbow software can be released to users due to holidays and interviewing commitments.
The inability to recruit a networking specialist is a cause for concern.
There were six incidents (four major) reported during this quarter:
Approximately 90% of the backbone traffic is DECnet, 6% bridge communications, 2% broadcast, 0.3% Pink Book, and 0.15% IP..
There were problems with statistics collection during the period. If effort is available an attempt will be made to determine if some figures can be produced.
It would be more satisfactory if statistics could be gathered centrally and graphs, plots etc. produced automatically.
RLVMSFE, RLVE, RLVO, CCDVS1 and IRIS were moved from the CCD development to CCD production ethernet.
The Spider X200 X.25 gateway is not yet providing a service.
There were three major incidents reported during this period:
CCD machines are expected to change to IP class B addresses.
A temporary thin ether link will be installed to the Colloquium Room.
A new fibre optic link is to be established to the R65 complex and to R2 to provide backbone connections to the villages that will be set up.
Thin ether connections will be installed around the Colloquium Room.
10.1.1 Current Situation
At a conference in Oxford (CHEP89) 13 terminals were used (5 Lee Data to IBM and 8 Cifer to PAD). The conference delegates used them all heavily. Obtaining extra lines from BT takes about three months and the Lee Data terminals were installed late, so Telecom Section installed the PAD and Cifers at short notice to overcome the lack of terminals and fill a gap over the weekend: Foreign users adapted to the Cifers well and some preferred them after comparing the speed (both sets had 9600 bps of bandwidth each, but the IBMs used the half-duplex bisync protocol). Conference arrangements often now involve comms support, if only to reach the visitors and tell them about their tickets etc. Conference delegates now expect good data communications to their home machines.
The return of dead mail is still a good way to anticipate mail errors - enquiries are reduced and some system problems are overcome by the process. About 20-30 files per day are rejected to ET from mailer. The reason is that list users often break the rules in setting up their mailers, and all their mail is multiplied by the size of the list before failing. Real mail errors are much less common - only 2 or 3 per day are not sent back by auto-reply when an incorrect address is used.
The major EARN nodes have adopted mailer release 2.03 which sends strict ARPA addresses (@relay:user@site is the general form of the path) which cause us problems because our release expects the general form user%site@relay - when any main field of a mail address is built by the new mailer, that mail will be rejected to ET here. Again this causes a large part of dead mail.
In view of the size of ET's mail, I have written EXECs and XEDIT profiles which allow me to pass on mail purely by those fields which ARE valid (if the sender has chosen a non-existent site, the mail goes back to the sender, etc). Although single line commands are often enough to return dead mail, it is still hard to devise a procedure which would drive the three or four commands automatically without crashing because manual errors are also present and some of these are unpredictable in form.
The Ethernet link to the IBM over the Spider PAD has been withdrawn at the moment. SSMP has also been updated, improving its speed: It is possible to find that the VM has no ports available, however a short wait and retry is often enough to get into the system. Each month there is a Fawn Box/SSMP, net3270 or MOS enquiry - but since they involve hardware, they are often slow to solve.
There are fewer NIFTP and JTMP user problems - since user support now have some extra tools written by Tim Kidd, they can sometimes be solved without passing the problem back to him; the user is just as happy, but it makes NIFTP support by non-systems people easier and so saves their time. I have been able to help several other sites where our packet or window sizes were a problem.
IBM has begun some projects (ASTRA and Hipparcos) which use EARN as a vehicle for access to their databases. Some users have acquired an account here because the software does not permit non-RSCS access - as these systems mature, mail access will be added and the need for RAL accounts will disappears.
We are acquiring some experience in setting up and running email lists.
10.1.2 Routine tasks and Investigations
An EBCDIC table is available which compares RAL with the two candidate de facto standards - code page 37 and 500. There are differences between CP37 and CP500, and the fact that CP37 and CP500 both have characters like "i acute" rather than the Greek alphabet makes it hard to recommend these standards for use by a laboratory.
It has taken a long time to find out the full details about running mailer 2.03 under CMS 5.5 as only one VM/SP HPO site is doing it. The facts were eventually obtained from the info-nets list.
EARN statistics are now available - they allow us to check, using observations of dead mail, whether any site is out of contact.
Diagnosing implementation errors takes up less time than hitherto. Some X400 tests have begun over the network, but some of these mailers are not yet mature and the implementation errors will probably increase while this is being developed on JANET.
ARPA sites are often best reached through NSFNET-RELAY. Japan has created an EARN gateway to JUNET in which Junet is replaced by .ac.jp - this is popular because the route is faster then the ARPA equivalent. Maintaining contact with other EARN gateways is now a routine chore - establishing contact was once a one-off experiment which would usually fail so this is a big improvement.
The new mailer should solve many problems. An automatic postmaster is not yet ready, but dead mail return is now quite a quick, unskilled operation in which there is no need to read even the addresses of the failed mail too closely.
We have not yet had a meeting of all the gateways operators - I see John Seymour at SERJUG and Ian Dallas comes to EARNUS meetings, however a special meeting would probably be very useful.
EARN is certain to adopt some version of X400. I have not yet tried NOTE400, but such tests would be useful.
The functionality of the G-Box is becoming apparent. When EARN alters its infrastructure, the users should hopefully see no change. However to support the new topology and the presence of G-Boxes and E-boxes is bound to have some effect.
Not supplied.
TMPC have asked for a statistics section in the Quarterly Progress.
The table shows performance and failure figures for the various network components on the Rutherford site. Comparisons between various access methods are not easy and must be read with some background knowledge. Major incidents are ones where a substantial number of connections are lost. Minor incidents are ones where only one or a few connections are lost.
Component Major Minor Traffic passed Traffic number
incidents incidents Mbytes/quarter of calls
Local
X.25 CPSE 6 4 16422 767000
SEEL 0 2 na na
PADs 12 10
PACX 0 0
LINES/MODEMS 6 0
Multiplexors 6 1
JANET
JPSE 13 5 36290 3145000
Lines/Modems 9 0
Local area network
VMNCPE 0 0 250 3000
Auscom H/W 1 0 - -
S/W 0 0 - -
370E - - - -
Auscom H/W 0 0 - -
S/W 0 0 - -
Backbone LAN
H/W 3 0 ? np
S/W 1 2 - -
CCD LAN
H/W 1 0 na np
S/W 0 0 - -
Spider Gateway
H/W 0 0
S/W 1 0
Hyperchannel
H/W ? ? np np
PIXNET
PIXNET H/W 0 0 np np
PIXNET S/W 0 2 - -
VAX VMSFE
Ethernet H/W na na np np
Ethernet S/W na na - -
X.25 H/W na na na na
X.25 S/W na na - -
SUN ARCU
SUN H/W na na na na
SUN S/W na na - -
IBM
4705 H/W 1 1 - -
4705 S/W 4 0 na na
VTAM(since V3R2) 8 0 na na
VMNCP 8 4 15000 1000000
Network/3270 ? ? 2500 65000
SSMP ? ? 65 1500
NIFTP ? ? 11000 900000
JTMP ? ? 650 17000
Line-mode ? ? 800 50000
CMS-PAD ? ? 65 50000
3270 H/W na na np na
3270 S/W na na - -
Note:
np indicates that it is not possible to provide figures.
na indicates that figures could be made available with effort.
- indicates that the figure is not relevant.
Dear Colleagues,
Following the favourable reception for the financial model at our last meeting I have made a number of changes and additions.
Remember the model contains the raw financial figures and I believe these to be complete as far as the published figures are concerned. However there is now scope for breaking sown the figures further should you wish. I have done nothing to provide presentation programs which will be needed for presenting the figures to the Board. I have not updated the 1989 actual income and expenditure as I do not have them. I have not added a percentage column as this is probably best done with an application. I also have difficulty with including an out-turn column since this requires quite a lot of work in deciding what the pattern of expenditure is with each budget item, including a commitment column. To do this I would need access to the historic month by month expenditure figures and probably we would need some formal electronic book keeping if the figures are to be kept up to date. I also note that few of our items have much regularity about them. If this is to be useful it would need Alain to provide a set of updated figures at each meeting. I suspect that the only way of tackling this would be to have a separate spread sheet for the current year. Your views please?
I enclose a disc with the program and data. The loading is now easier:-
I have come across a number of further difficulties.
The 1985/6/7 figures are in US dollars and I have converted them to ECU at the rate of 1.123 since the RARE subscription is shown as 1123 Dollars. This gives a surplus at the end of 1987 of 249665 ECU. However the surplus shown in the 1988 accounts is 211258 ECU (see figures marked in red. What has happened to 38407 ECU? I also note that the auditor does not seem to have been paid! Did IBM pay directly? The early accounts show a negative term called "interest" - I have assumed that this is a bank charge and have put it in as a expenditure. There is a income called "financial revenue" and I have assumed that this is interest on capital.
In putting in capital assets I cannot make these agree with the income statement. I would have expected the liquid assets to be exactly equal to the surplus. Note that I have included the Ivory coast subscription as a bad debit rather than a credit as we are unlikely to ever see it. Strictly speaking this should be done in the 1989 accounts. There is a discrepancy of 1607 ECU (see figures marked in green). This may be caused by the asset "Dublin Office" 2318 ECU and "Accrued expenses ader" 2820 ECU. It could also be caused by the asset "investment" 1296 ECU which I believe is the furnishings in the Paris Office. This is shown as a null expenditure in the accounts so perhaps the expenditures in the accounts are incomplete?
It would be useful to iron out the remaining anomalies which are no doubt due to my misunderstandings.
I would welcome any further comments and corrections.
I take the opportunity to distribute some papers from the last Executive meeting for your records I believe they require no action at this time.
ALSO PLEASE NOTE THE DRAFT AGENDA FOR THE AMSTERDAM EXECUTIVE MEETING.
Yours sincerely,
Paul Bryant.
Dear Mr. Potter,
I am pleased to confirm that we will be able to sell you time on our IBM computer in order to access EARN. I enclose a form for your completion which I have partly filled in.
I have pencilled in 6 Bus (Allocation Units) for your use which cost 60 pounds each which would be the limit of your liability. There are no other charges. Units not used will not be charged. For your guidance I use mail heavily most days and get through 400 messages a week and this costs me 3 AUs per month. I would not expect you to use anything like that amount. You may change the 6 AUs I suggest to any number you like but if it is too small you will have to come back for a reallocation if you run out.
You should by now have received the 3270 code for a PC.
Yours sincerely
Paul Bryant.
I had a look at a typical day in the life of PACX on July 26, 1988. This looks at a typical day a year latter on July 24 1989. I have had a brief look at a few other days and July 24 does indeed look typical. Since this analysis I have found that PACX now automatically produces some useful figures which support the findings of this paper.
Number of connections at each speed:
+--------+--------+--------+
| Speed |88 Calls|89 Calls|
+--------+--------+--------+
| 300 | 3 | 0 |
| 1200 | 23 | 7 |
| 2400 | 12 | 3 |
| 4800 | 479 | 281 |
| 9600 | 64 | 165 |
| 19200 | 2 | 20 |
+--------+--------+--------+
| Total | 583 | 476 |
+--------+--------+--------+
Calls were made from 71 terminal ports. There are a total of 768 ports with 198 for computer ports and the rest for terminals. Unfortunately there is no way of finding out whether there actually is a terminal at the end of a line. The numbers of calls from each port were:
Number of ports number of calls 20 1 8 2 3 3 10 4 2 5 2 6 2 7 1 8 2 9 5 10 1 11 1 12 4 13 3 15 2 17 1 18 1 19 1 35 1 48
Number of connections made in each hour:
+----------+--------+--------+
|Start time|88Number|89Number|
+----------+--------+--------+
| 00.00 | 0 | 0 |
| 01.00 | 0 | 1 |
| 02.00 | 1 | 2 |
| 03.00 | 0 | 0 |
| 04.00 | 0 | 0 |
| 05.00 | 1 | 12 |
| 06.00 | 0 | 0 |
| 07.00 | 10 | 3 |
| 08.00 | 82 | 47 |
| 09.00 | 69 | 47 |
| 10.00 | 50 | 41 |
| 11.00 | 50 | 55 |
| 12.00 | 32 | 13 |
| 13.00 | 44 | 38 |
| 14.00 | 42 | 41 |
| 15.00 | 85 | 93 |
| 16.00 | 62 | 51 |
| 17.00 | 19 | 24 |
| 18.00 | 11 | 0 |
| 19.00 | 14 | 5 |
| 20.00 | 9 | 1 |
| 21.00 | 0 | 1 |
| 22.00 | 3 | 0 |
| 23.00 | 1 | 1 |
+----------+--------+--------+
Classes used on PACX 2000
PACX Numb. Port speeds x100 PORTS
CLASS CONNECTED TO calls 192 96 48 12 3 TOTAL
88 89
1 PACX Console (restricted) * * * * * 1
2 PACX RALPSS (restricted) 6 * * * * * 1
3 PACX ULCCPSS (restricted) * * * * * 1
4+ Swindon CDC AUX ?
5 RAL Prime 9955 (A) * * * * * 1
6 RAL Prime 9955 (A) * * * * * 1
7 RAL Prime 9987 (G) 5 6 1 1
8 4
10 RAL R1 I.D SUN NFS-1 1 1
13 RAL R1 I.D VAX 11/750 (C) 1 * * * 6
15 NT ops console 1
20 RAL Prime 750 (E) 44 28 * * * * 6
25 RAL R1 I.D Pyramid 64 34 12 12
30 RAL Gec B 4090 Asynch FTP * * * * 1
31 RAL R1 PPD Terminal Server 7 7 * * * * 12
33 RAL OS9 * * * 1
35 RAL EBLF Vax 11/750 * * * 1
40 DECSERVER on ETHERNET 1 1 * * * * * 3
44 RAL Prime 2655 (H) 15 5 * * * * 8
50 RAL Camtec Pad (M) & (O) 187 312 * * * * 32
55 RAL R1 I.D VAX 8750 (D) 1 * * * 10
60 RAL CCD VAX 11/750 (E) 7 1 * * * * 2
61 RAL Starlink Vax 11/780 11 3 * * * * 6
62 RAL R25 PDP 1 1 1
67 RAL GEC 4090 (B) 24 17 * * * * 4
65 IRIS 4 * * * * 1
70 RAL Prime 9955 (A) 46 26 * * * * 32
72 RAL Prime 750 (C) 1 * * * 15
73 RAL Prime 750 (C) 1 * * * 1
77 RAL Schools Prime 400 * * * * 4
101 RAL Prime 750 (F) 23 4 * * * 15
102 RAL Prime 750 (F) * * * 1
110 RAL IPMAF Vax 11/750 13 * * * * 4
120 RAL R1 I.D Vax 8750 (F) * * * 4
123 RAL AMDAHL UTS 6 6
133 RAL Spider PAD 24 * * * 2
140 RAL Informatics Ether PAD 1 * * * 2
152 RAL Amdahl (test) 2 2
160- RAL IBM Cifer full screen 57 6 6
171- RAL IBM CMS 67 10 2 2 14
Total number of ports in use in July 88 217
Total number of ports in use in July 89 198
It is not possible to measure the numbers of interactive calls through the X.25 network but the IBM statistics for a specimen week show an average of 1680 incoming and 725 outgoing calls. This is an increase from 1120 incoming and 560 outgoing which is accounted for in a small way by the loss of interactive access to the IBM 4705.
The statistics from PACX show that queues only build up where there is only one port into a service such as the IRIS. Where there are multiple ports there is an over-provision of more than 50%, for example with PRIMEs.
312 PACX calls went to a PAD an increase from 187- that is 65% of calls. This underlines the observation of last year that many terminals would be better off with a PAD port.
Most other services show a drop of about 50 %. A notable exception is the Spider PAD which has attracted a small following.
There are a large number of minor services used for testing and emergency use. For example, the connection to the CCD VAX is in case the DEC server fails in which case staff would have to visit the machine room to re-boot the system. Most such services could be replaced by a few dedicated lines.
As expected the use of PACX has decreased but unexpectedly ID have not become larger users and have in fact their use has halved.
The traffic has now reached the stage where it is difficult to justify the size of PACX we have and a single unit could deal with the traffic and number of ports especially if the terminals predominantly using PACX to access PADs are moved to PADs. From an equipment point of view this is no problem with the reducing number of Cifer terminals.
A difficulty is to know how to deal with the DEC servers. VAX access via a server is popular and a better quality than via X.25 but is costly. PACX provides an easy way of sharing these ports.
We now have a wide variety of viable options for networking on the Rutherford site. Whilst this is an unusual and comfortable position to be in it does mean that staff have to understand, operate, and maintain this equipment with reducing effort. It would seem unlikely that the manpower problem will improve. At some stage some rationalisation must take place. At this stage we need to review parts of the system.
The popular activities are 3270 and VT100 terminal access plus file transfer and mail. Task to task access is popular between VAXes. The computers of interest are the IBM, VAXes, PCs, and UNIX. The GECs and PRIMEs seem to be on the way out. XWINDOWS has yet to make its impact. The dumb "line at a time" terminal is of diminishing interest.
The four attached diagrams show the various routes that 3270, VT100, file transfer, and mail traffic can take via the ethernet. The observation is that Pink Book, DECNET, and TCP/IP can all provide many of the services each with some irritating limitations.
The problem with TCP/IP is off site access. Terminal traffic can use a VAX or the IBM as a PAD. Mail is probably possible but more evaluation work is needed. Blue Book FTP is not possible.
Pink Book relies on the Auscom and the Spider gateway. The Auscom is reliable but is not well supported. No alternatives for Pink Book into the IBM appear to be developing. The Spider Gateway depends on a site nameserver to be supplied by JNT later this year. Pink Book remains a UK academic protocol stack and we have yet to see it being taken up in other communities or by large manufacturers.
DECNET appears to have few problems. It has a specific advantage that if PSI Access is used the complete set of DECNET VAX machines can have a single X.25 connection to JANET thus avoiding the Spider gateway. PSI access allows X.25 to be carried over DECNET in a transparent fashion. This solves JANET access at a stroke.
The reliability of the methods vary although they are all high enough to be viable.
The TCP/IP products are reliable although coming from various manufacturers there are minor glitches. There have been some entertaining addressing problems which have been resolved or at least understood.
Pink Book is well understood as Rutherford has been involved in field testing implementations and has thus seen them develop in reliability. The use of the protocols has been light and its performance under heavy load is unknown.
DECNET between VAXes has perhaps the highest reliability being developed by a single manufacturer. The reliability of DECNET on a PC also seems high but the reliability of DECNET on the IBM has yet to be determined.
The quality and functionality of the methods are quite difficult to compare. With 3270 access there is no doubt that it is difficult to compete with a 3270 PC connected to the IBM via a co-axial cable with their close coupling. With Pink Book 3270, the connection can be suspended to do a Blue Book transfer. Whilst quite easy it is not as transparent or well integrated as the IBM system. 3270 via TCP/IP has similar characteristics to Pink Book. Co-axial 3270 gives almost instantaneous response while TCP/IP and Pink Book network 3270 give a noticeably slower but acceptable 1/2 second response. For comparison X.25 network 3270 gives a more variable response from 1.5 seconds. Remember that the loading on the ethernet is light and so the observed responses may be optimistic for a well loaded ethernet. TCP/IP and Pink Book 3270 from a VAX have similar performance and functionality to the PC versions. The TCP/IP versions suffers from having a poor keyboard mapping. Pink Book 3270 is a bit slower but has a better keyboard mapping. 3270 via DECNET falls between TCP/IP and Pink Book and has a poor Keyboard layout.
Real VT100 performance is limited by its 19.2K asynchronous connection and therefore connections via DEC Servers or VAXes to other VAXes via ethernet are difficult to tell apart. Not surprisingly a PC or VAX workstation emulating a VT100 connected to the ethernet using DECNET or TCP/IP has a better performance than the real VT100. VT100 emulation from a 3270 connected to the IBM via Pink Book and TCP/IP is not possible although line mode access gives a service for the occasional use. Emulation via DECNET is quite good considering the limitations of the 3270 terminal.
In all cases terminal access to JANET machines is possible by using the PAD capabilities in a VAX or the IBM.
DECNET and TCP/IP file transfers have the obvious drawback that they cannot operate freely across JANET. In DECNET case it is a political problem as well as only a subset of machines on JANET being potentially capable of DECNET. With TCP/IP further equipment, such as a CISCO router is needed but again there are political problems and only a subset of machines offer the protocols. Pink Book/Blue Book file transfer requires the Spider gateway. This is currently not a viable proposition as it cannot hold a full NRS table. This problem should be resolved with the introduction of a campus name server.
Mail has the same requirements as Blue Book and thus can use Pink Book. Mail to other sites requires the Spider PAD or alternatively could go to VAX machines via PSI access and DECNET. Some preliminary work has been done with mail over TCP/IP. This suggests that a gateway between the Grey Book world and TCP/IP mail would be possible thus allowing mail to PCs. There are some addressing issues to be resolved. Such traffic would go via the EARN gateway.
Hardware wise on the IBM there is a worry that we may end up with a different ethernet box for each protocol. Without a magic wand Pink Book will continue to use the Auscom and nothing else will (bar the 370E). The 8230 and INTERLINK both support TCP/IP and DECNET. The INTERLINK operates at a higher speed. There are a number of other products of varying prices and performances mainly aimed at the TCP/IP market.
Both PC Pink Book and TCP/IP are supported by the popular BICC board. Unfortunately DECNET requires the more expensive 3COM. The 3COM will be able to support Pink Book as a result of work at Daresbury.
The VAX has DEC ethernet interfaces which all support DECNET, PINK BOOK and TCP/IP.
Pink Book code is effectively free for the IBM, PC and UNIX. It is charged on the VAX.
DECNET and TCP/IP code is charged on all machines.
The following diagrams do not include the details of the current PACX and X.25 connections to PRIMEs, NORD etc which all require support by Telecoms.
There are also a range of other communications methods such as that used by Chessington which are not the concern of TMPC as no proposals have been brought to the meeting. None the less these also absorb effort.
3270
+---+---------+
| | | SSMP
| | | A +----------+
| | | +----+-----+ |FAWN BOX |
| |3745 +-Col. Books----X.25--------+CAMTEC PAD+- S -+almost-+PC|
| | | | +----------+ |any |
| | | +-------+------+ Y |terminal |
| | | |Spider Gateway| +----------+
| +---------+ +------+-------+ N
| | | E +--+ SSMP
| | | T-----------+PC| C +----------+
| | | H +--+-------+ -+PC |
| |AUSCOM +-Pink Book-----E-----------+Spider PAD+- H +----------+
| | | R +---+------+
| | | +-----------+VAX+-------- R Network 3270
| | | | +---+ +----------+
| +---------+ O -|CIFER |
| | | | E +----------+ |or PC |
| | | E T-+DEC Server+- N +----------+
| | | T H-+----------+
|IBM|8232 or +-TCP/IP--------H E O VT100 via VAX
| |INTERLINK| E R-+---+ +----------+
| | | R-----------+VAX+-------- U |VT100 or |
| | | | +---+-----+ -+PC or |
| | | +-----------+PC or SUN| S |CIFER |
| | | +---------+ +----------+
| | | E
| | | T +---+
| | +-DECNET--------H-----------+VAX+--------
| | | E +---+
| | | R
| +---------+
| | | +----+
| | | 3745<-+3274+----co-ax---------+----+
| | | +----+ | |
| |3274 or | +3270+
| |3174 | | |
| | +--------------------------co-ax---------+----+
| | |
+---+---------+
VT100
+---+
| |
| |
| | +----------+ +------+
| +-------------------------X.25--------+CAMTEC PAD+---------+ |
| | | +----------+ |PC or |
| | +-------+------+ |CIFER |
| | |Spider Gateway| |or |
| | +------+-------+ |VT100 |
| | E | |
| | T | |
| | H | |
| +-----------Pink Book-----E +----------+ | |
| | R-----------+Spider PAD+---------+ |
| | | +----------+ | |
| | | | |
| | | |
| | | +----------+ | |
| | E-----------+DEC Server+---------+ |
| | T +---+------+ | |
|VAX+-----------DECNET--------H |VAX+----------------+ |
| | E +--++ | |
| | R +PC+-----------------+ |
| | +-----------+--+ | |
| | +------+
| | E
| | T +------+
| | H--------------------------------+ |
| | E |SUN |
| | R |or |
| +-----------TCP/IP--------+ |PC |
| | +--------------------------------+ |
+---+ | +------+
File Transfer
+---+---------+
| | |
| | |
| | | +--------+
| |3745 +-Col. Books----X.25---------------------+JANET |
| | | | |machines|
| | | +-------+------+ +--------+
| | | |Spider Gateway|
| +---------+ +------+-------+
| | | E
| | | T +---+
| | | H |VAX|
| |AUSCOM +-Pink Book-----E-----------------------+or |
| | | R |PC |
| | | | +---+
| | | |
| +---------+
| | | |
| | | E +-----+
| | | T |VAX |
|IBM|8232 or +-TCP/IP--------H------------------------+or |
| |INTERLINK| E |PC |
| | | R |or |
| | | | |SUN |
| +---------+ +-----+
| | | E
| | | T +-----+
| | | H |VAX |
| |8232 or | E |or |
| |INTERLINK| R------------------------+PC |
| | +-DECNET--------+ +-----+
| | | |
+---+---------+
MAIL
+---+---------+--------------EARN
| | |
| | |
| | | +--------+
| |3745 +-Col. Books----X.25---------------------+JANET |
| | | | |machines|
| | | +-------+------+ +--------+
| | | |Spider Gateway|
| +---------+ +------+-------+
| | | E
| | | T
| | | H +---+
| |AUSCOM +-Pink Book-----E-----------------------+VAX|
| | | R +---+
| | | |
| | | |
| +---------+
| | | |
| | | E +-----+
| | | T |VAX |
|IBM|8232 or +-TCP/IP--------H--Needs further study---+or |
| |INTERLINK| E |PC |
| | | R |or |
| | | | |SUN |
+---+---------+ +-----+
1.1.1 JTMP Host-end Service
No significant problems.
1.1.2 NIFTP
No significant problems. No new developments.
1.1.3 NETJOB and NETFILE
The NETJOB user interface is installed, but has as yet been very little used. There has been no work on NETFILE during this period.
1.1.4 SSMP
Reliable apart from occasional call hangs. It is now believed that the hangs result from a difference between VM/XA and VM/SP. Salford are still working on a fix; the first one supplied did not cure it.
1.1.5 Pink Book
No progress in rectifying the main deficiency that P-end FTP is not supported. The rest of it seems very reliable but has not been heavily used.
1.1.6 CMS-PAD
No changes. Some problems are emerging when accessing IBM sites using Salford's Network/VM under VM/XA. Someone at Glasgow is currently studying this.
1.1.7 VTAM
Performance and throughput have been satisfactory, but reliability has continued to be patchy. A weakness in NPSI (believed to be rectified in later Releases for the 3745) sometimes results in incoming calls hanging at call set-up time in an apparently random way. Occasionally, there seems to be a major snarl-up in VTAM itself, with most of the Switched Minor Nodes going into hung states. This problem is probably really in the 4705, as it invariably seems to be incurable except by re-loading the front-end. 4705 dumps have not thrown any useful light on the cause of these problems.
1.1.8 IBM 3745
The software arrived in mid-June, and has been installed. Since the end of this 3-month period, it has been successfully run using a 64K test link to the Seel switch.
1.1.9 Line mode terminal support
No new problems have emerged. However, this service has been affected by the problem of call hangs at set-up time, mentioned in the VTAM section above.
1.1.10 VMNCP
Incoming full-screen calls were found to be occasionally hanging in mid-call, and for a long time no progress was made due to inability to reproduce the problem deliberately. It has since become clear that the problem was due to a difference between VM/XA and VM/SP and a fix has been applied.
VMNCP continues to be affected from time to time by the VMCF problem in VM/XA, for which IBM have still not supplied a viable fix.
1.1.11 RSCS
Local modifications have been applied to RSCS version 2.3 and it is now ready to provide a production service. This version of RSCS will replace both V2.2 and V1.3 (therefore reducing the number of RSCS virtual machines).
A fix for the problem affecting graphics output via RSCS has been developed and applied to version 2.3.
A fix for the problem affecting MVS user names and site names has been developed and applied to both version 2.2 and version 2.3. This problem has been reported to IBM and an official fix is believed to be available on the next update tape.
1.1.12 TCP/IP and the IBM 8232
The IBM 8232 appears to be very reliable. Initial problems with the Hyperchannel interface have been solved. Some small modifications have been made to the terminal interface code to log incoming calls and to set the QUERY WHERE text.
Line mode terminal access did not work. This was found to be a CP bug and has now been fixed.
Following the fix of a few minor problems with the X-Windows code, X-Windows applications have been run from the 3090 onto PCs and SUNs.
1.1.13 Routine Maintenance
Nothing specific to report.
1.2.1 Introduction into service of the 3745.
1.2.2 There should be further substantial progress with the TCP/IP software and the IBM 8232.
1.2.3 The Pink-Book software will continue to progress as fast as possible towards service status.
In the longer term, migration towards ISO protocols using manufacturer-provide software.
2.1.1 Local.
a. The Multiplexors on the CERN 64K line were installed and the services transferred across. Problems were experienced with poor response to/from the SERC PAD and CERN IBMs - this appears to be due to flowcontrol problems on the link between SERC PSE at CERN and the CERN Excite Network. The problem has been over come by splitting the X.25 traffic into two channels back to the UK. The line has suffered a number of Sync loses and the PTT have been monitoring to establish the cause.
b. Four of the CPSE Major faults were due to loss of power during storms and the three minor ones due to changing suspect controller boards during the Tuesday 'At Risk ' period.
c. SEEL have delivered new software to over come the 1K packet size problem and this appears to be functioning correctly. However more problems have been experienced with the 'macro facility' and address translation is not yet working in a way that we had hoped. Problems also have arisen with 'Calling Address' insertion for lines that do not enter the 'Calling Address' themselves.
d. Pilkington have supplied a number of new power supplies and these are currently being evaluated.
e. Camtec PADs still give a range of problems most of which are resolved locally.
f. The problem reported previously on the Swindon Megastream link do not appear to be caused by the Mux but are speed related, currently the channel is running at 256K with no errors. Problems did arise when Lee Data connected an additional unit to their Mux at Swindon - this eventually turned out to be a Lee Data problem. The link itself has experienced two outages due to line faults.
g. The EARN 64K line contract was re-negotiation from 1 Year to less than 1 year and then eventually cancelled due to none delivery.
h. The HEP and EARN analogue lines were both cancelled and then the EARN cancellation was withdrawn.
i. Two 64K Kilostream lines have been ordered for IBM Winchester connections.
2.1.2 JANET
a. There have been no occurrences of the 'C I Timeout' problem during this quarter. The original interface cable was reconnected at the end of July.
b. A number of IPLs have been required to overcome problems on KCC boards and a number were due to power problems during the storms. KCC board problems have also been reported by other NOCs.
c. Progress meetings have started with BTs MCSC, the first being held at RAL in June. This meeting was useful and BT have confirmed that problems do exist with 2-wire NTU if their is a long tail involved and full-duplex protocols are used. We have been advised to specify that we require 4-wire NTUs when ordering new lines.
d. The SERC PAD at Bath has now been connected to the Bath CPSE, however the PR1ME is still connected to RAL.
e. New lines have been installed to Southampton (digital 48K), UCCA (digital 9.6K), MST at Capel Dewi (Analogue).
f. All lines scheduled to be moved onto the Kilostream Plus have now been transferred across.
g. Problems were experienced with attempting to run X.25 (84) on a number of load-sharing lines for NERC. Two IPLs were required to overcome the problems that arose.
a. With the resignation of two experienced staff during the quarter the time to fix faults is likely to increase, as resources will be spread thinly.
b. Ordering of lines for ESANET connections.
c. Connections for 3745 to go into service.
a. More staff.
b. Automatic statistics gathering program and monitor for SEEL and Camtec equipment.
c. Monitoring equipment for ethernet.
There was a 15% increase in the number of faults reported to the sub-section, this quarter, all of which was repaired by the section.
During the period 119 faults were reported, 43% repaired by sub-section staff and the remaining units by maintenance agencies.
The distribution of agency repairs is as follows:
MSM 24 Movable terminals
KODE 35 Non-movable terminals
SIGMEX 4 Sigmex terminals only
OTHER 5 Warranty repairs
The 119 faults have been analysed for divisional distribution. Of this total, 44 (37%) was CCD and the remaining 63% for other RAL divisions.
____________________________________________________
| | REPAIR AGENCY | |
|Division |_________________________________| |
|-Project | TCOM | MSM | KODE |SIGMEX|OTHER| TOTALS |
|_________|______|______|______|______|_____|________|
| ADM | 9 | | 4 | | | 13 |
| ALVEY | | | | | | |
| CCD | 13 | 11 | 12 | 4 | 4 | 44 |
| CO | | | | | | |
| EBW | | | | | 1 | 1 |
| ECF | 2 | 1 | | | | 3 |
| HEP | 7 | 2 | 4 | | | 13 |
| ID | 6 | 5 | 3 | | | 14 |
| INS | | | | | | |
| RCR | | 1 | | | | 1 |
| SCI.ISI| 1 | 1 | 2 | | | 4 |
| SCI.LAS| | | | | | |
| SL | 2 | | 4 | | | 6 |
| SPA | 3 | | 2 | | | 5 |
| TEC | 8 | 3 | 4 | | | 15 |
|_________|______|______|______|______|_____|________|
| TOTALS | 51 | 24 | 35 | 4 | 5 | 119 |
|_________|______|______|______|______|_____|________|
No significant changes are expected during the next period.
The Multiplexer in TCH was upgraded to support eight terminals.
A DECserver was set up in Telecomms for a Space Science Seminar in TCH.
A mixture of Full Screen, Cifer and Sigma terminals was installed at TCH for the CCD Summer School.
A Cifer and dial-up modem were installed in Harwell contracts to give 'Full Screen' access to the IBM.
The PPD communications rack in R1 Lab 8 was relocated.
The optical fibres for the PPD backbone connection and village extension to Atlas were re-terminated.
The two offices in R1 allocated to the terminal pool were wired for data.
The R61 Library coaxial connections were re-routed via R1.
Thin ether cabling was installed in R20.
A second Fanout unit was installed in Telecomms on the CCD Production ether.
Another thick ether cable (CCD 5) was installed in Atlas between Telecomms and the R26 Computer Room North.
Terminal wiring was started in the new TCH conference centre.
A temporary thin ether link was installed to the Colloquium Room.
Due to financial constraints it is difficult to predict what will be done during this period as many jobs that were to have been done have been put on 'hold'.
Terminals will be moved into the new R1 terminal pool.
The equipment for the Chessington Payroll Project will be moved into Telecomms for tests to be carried out.
A cable will be installed in R1 to the telephone exchange to extend a Mercury data link ( from Swindon ) across to Atlas.
The R65 village ether may be installed.
The backbone link to R65 may be installed.
The ground floor R68 may be wired up for data communications.
5.1.1 Network Software
A patch to the CBS PAD (V5.1) was received that will fix the problem in which a terminal session hangs when packets of the More Bit Set arrive. This patch has been passed on to SERC VAX systems after being announced in the July VAX User Group Meeting.
The field test on CBS and JTMP has been carried out on RL.VE since Mid-July. This release provides some fixes to the major problems such as FTP Manager crashes. It also provides some enhancements, including user transparent mail relay via gateway and the support of sub-addresses for PSI Access nodes.
The FTP process looping problem on a file transfer with the RAL IBM currently remains unresolved in this release.
A few bugs in JTMP V5.0 are corrected in this release but no enhancements are provided.
The field test will continue probably till September and it is hoped that patches for both the old and new problems experienced can be provided before the product is finally released.
5.1.2 Network Hardware
The Development VAX 11/750 has been replaced by the MicroVAX II (the old Cray VAX Front-End) in May. The new configuration consists of one X.25 line to CPSE at 19.2K and one Ethernet connection to the CCD Production LAN. No problem was experienced during the change-over process.
There has been no further change in hardware on the Cray Front End since the major upgrade took place in April.
The EARN G-Box was installed in May with the PSI, VOTS, OSAK and JNET software. The installation was successful and connections was made to the RAL IBM using RSCS over a Bisync line and also to the Ireland G-Box using JNET with the Northern Telecomms switch.
The regular networking support of PSI, CBS and Red Book, Pink Book, DECNet, LAVC, PSS/IPSS, VMS-COMMS, EARN and Janet mailshr continues.
The NRS updates were continually supplied to SERC sites.
A major incident was recorded in June in which a hacker(s) managed to log on to a VAX in Imperial College and from there he fetched some sensitive files from a number of VAXes on JANET using the DECNET username and password.
Imperial has since then taken major steps to tighten up their security such as changing all their users' passwords. A warning has also been circulated to all VAX managers advising them to reset the passwords on all commonly known accounts.
The field test on CBS and JTMP will continue. It is hoped that the entire field test can be concluded in September.
An order for a DSV-11 X.25 interface device for RL.VE has been placed. This addition will help to increase the network throughput for the VAX and be particularly useful in networking field tests. The device is expected to arrive in August.
More connectivity tests will take place on the EARN G-Box with Ireland and possibly with other G-Boxes pending on successful installation and connections of the G-Box backbone and the switches.
A new member of staff will join the VAX Support Group. Heather Welch will start on 1st August and she will take part in providing VAX networking support in due course.
6.1.1 NJE
No Change.
6.1.2 File transfer between EARN and JANET
No change.
6.1.3 MAIL
An updated version of the new mailer has been produced which gets over some problems to do with the data structure. Regretfully it did not overcome the problem of loading exits dynamically under CMS 5.5. A number of solution to the problem were examined and it has now been decided to link edit the RAL exits with the mailer code. This does not require any changes to the mailer code but does involve assembling it. This has the additional benefit that the RAL code can now call mailer routines directly. This scheme has proved successful.
To date simple mail messages will go through the mailer and the remaining problems are to do with fairly well understood pieces of code.
The code to deal with a user name server is complete but it had been decided to introduce it with the new mailer rather than spend time with the old one.
6.1.4 LISTSERV
A number of lists have been moved from the EARN LISTSERV to the JANET one with no problems.
6.1.5 EARN management
There has been considerable discussion on the use of SNA with a number of countries quite keen to convert much of the network to these protocols.
A detailed proposal has been drafted for the future of EARN together with its transition. This is still under development.
EARN and RARE will run a joint conference in Ireland in 1990.
6.1.6 Transition
The 64K EARN line has been cancelled as a result the UKs unwillingness to part fund it. As a result the network will now be based on a triangle between Amsterdam, CERN, and Montpellier. The UK was asked to retain the 9.6K line for a few months for testing. By some unfortunate mistakes at CERN the line was cancelled and there have been severe difficulties in retrieving it.
The transition is now going ahead rather more rapidly with all the switches (bar the UK one) being interconnected together with a number of G-boxes. The management centre in Amsterdam is now operational with the relocation of the equipment from Ireland.
6.2.1 NJE
No changes expected.
6.2.2 File transfer between EARN and JANET
No changes expected.
6.2.3 MAIL
No changes expected.
6.2.4 LISTSERV
No changes expected.
6.2.5 EARN Management
The September Executive meeting is expected to recommend a course of action to the EARN Board of Directors meeting in October in the light of the non payment of part of the UK contribution. Options are to reduce the EARN expenditure, reduce the UK contribution for 1989, increase the UK contribution for 1990, degrade the service to the UK in some way (for example by cutting of the UK for a pro rata period), or some combination of these.
Figures on country contributions based on traffic will soon be available for comment.
The future of the UK participation is unclear with the financial problems and the development IXI and the NT networks.
The Hyperchannel had a single fault when the IBM adapter failed after a severe storm, it was repaired within 24 hours.
First attempts have been made to get the Hyperchannel connection to the new MicroVAX 3600 working. The Hyperchannel diagnostics (HIT) were run from the old VAX to ensure all was still working, this showed a few errors that are believed to be 'contention' errors. The diagnostics are not very good, and it is thought they cannot handle contention on the adapter, at other times the diagnostics have been run with only the VAX connected.
A new cable has been made to connect the MicroVAX 3600 to the Hyperchannel (not supported by anyone!). The HIT tests were then run using the MicroVAX 3600. These again showed some errors which have been put down to similar contention problems as on the old system, although the information supplied by the diagnostics are not very helpful.
Final tests of running the Cray station software over Hyperchannel from the MicroVAX 3600 will be carried out and, if successful, they will be put into the system on an almost permanent basis to ensure the connection is reliable over a longer period of time.
None.
The first release of the Rainbow Pink Book software has been obtained. Tests found one minor bug which has been fixed. Problems with addressing mean that maintaining each user's address database could be a significant problem. However the next release, scheduled for September, will allow unknown addresses to be routed via the X.25 gateway which should simplify matters. Until the NRS Campus Server arrives only a limited number of external sites can be accessed. Converting the user manual to DisplayWrite format has proved to be a difficult task.
Considerable progress has been made with TCP/IP thanks to help from Tim Kidd. The incentive was the arrival of the IBM 8232 and its TCP/IP software on the IBM. The PC can now access the IBM over the ethernet to do mail, file transfer and fullscreen terminal access. Access to devices such as a Postscript printer on other machines with TCP/IP show that the product has considerable potential. NFS allows a CMS mini disc to accessed directly from the PC which allows PC disc backup within the limits of the flat CMS filestore. Software to support X-Windows has also been tested - the only drawback with this is the memory requirements which, unless the PC is carefully configured, exceed the 640k limit. The cost of the software may be a limiting factor in its acceptance at RAL but site licences are rumoured to be under consideration at CHEST.
The latest BICC ethernet cards have been tested. These support 16 bit access for an AT type machine and the PS/2 MCA interface. In common with several other sites we have found problems and the current recommendation is to stick with the old 8 bit card which is tried and tested. The memory requirements for the latest version of the BICC Multi Protocol Support (MPS) driver is also a cause for concern.
RAL versions of IBM's SEND and RECEIVE file transfer programs are now under test along with a new version of MOS which implements enhancements such as a help system and programmable keys. Problems with code conversion are gradually being solved and binary transfers between the IBM via Kermit, PC3270 and MOS are now all the same. This will allow a software distribution system based on the IBM to be released in due course. Ascii transfers are also compatible providing a series of patches are applied to the conversion tables of SEND and RECEIVE.
A feasibility study on the possibility of adding the EEHLLAPI interface to MOS is being done by a trainee. The ultimate aim is to run PASF thus giving PROFS users the same facilities over the network as they enjoy over the coaxial links.
It is hoped to offer a pilot Rainbow service. However before this is done considerable thought is required about what to recommend to users. Rainbow is effectively free and can access the UK academic community. The TCP/IP software has much greater functionality but can only access certain machines at RAL and costs several hundred pounds unless a site licence can be obtained.
A beta test version of MOS 2.1 with file transfer should be released to selected users.
The possible need to support two ethernet protocols on the PC will further dilute the limited effort.
There were no incidents reported during this period that related to the site backbone.
There are still problems collecting statistics.
CCD machines changed to IP class B addresses.
A temporary thin ether connection was made to the Colloquium room for equipment demonstrations.
Fibre optic cable to be installed to R65 for village connection.
Thin ether around Colloquium room.
The EARN user meeting on May 17th took place at ULCC: The usual venue at UCL was booked. The meeting was attended by about 40 people, most of whom were satisfied with recent developments in the UK and in EARN (except that the UK is less dependent on EARN than other European countries whose share is similar or lower). Ian Smith's feeling that the money was at last being used to make EARN run properly was not disputed - there were no more comments and negotiations were left to the JNT. Only one item brought any disapproval: Ted Chance welcomed the change of the partial domain EARN to point at EARN-RELAY rather than NSFNET-RELAY - tests of the "ARPA" route to BITNET had proved the advantages of the RAL gateway - but regretted the delay before this was done.
Some EXECs in ET have made error forwarding a reasonably quick service. Forwarding with advice is far more popular than rejecting with criticism - and forwarding is now easy enough that there is no need to force users to immediately correct their mail. The problem is caused when system and user errors make auto-reply impossible. My forwarding tools were used in my holiday by Jonathan Wheeler - they appear to work reliably in the hands of another postmaster, so I consider them tested. The work was needed as lists generate a great deal of failed mail: If any list user sends a syntax error, the mailer will receive either all our rejections or fewer rejections, from sites where mailers are stricter; the EXECs read any convenient address -it requires added intelligence to decide which one is valid, but since the most tedious problems are then multiply copied, this allows list errors to be cleared out rapidly in the same way. The EXECs could be made much tidier, however they do not occupy much space and are driven by PF keys so this is not a priority.
We are still not receiving gateway configurations (MAILER NAMES and DOMAIN NAMES files) as fast as other EARN sites would like. The EARN management should say how the distribution is being done and how fast it is so that new members can be warned not to introduce new mailers in a sloppy fashion (mailer 2.03 is still causing us to manually forward mail and we are still being asked to manually alter the NAMES files).
Curlew, the SSMP editor, is now installed on TESTSOFT. It works well and allows users of multiple machines on JANET to use the IBM without much re-learning. It can be set up to resemble EMACS for Unix users.
It will be very useful to know the spool id of NIFTP transfers when Tim Kidd has expanded his NIFTP facilities. This would allow user support to deal with routine NIFTP upsets such as rejections owing to wrong packet sizes.
Two satellite-related databases have been set up for EARN: IBM think that ASTRA can now be accessed by email, which we will test shortly. Hipparcos' database was moved nearer to Kourou, where it was launched, but since the satellite has not reached its intended orbit, it may be little-used.
There is now a lot of interest in UUENCODE/UUDECODE on JANET. This "binary ftp" over email encounters the ASCII/EBCDIC problem. MAC users want to retrieve software and send graphics by email, but EARN has corrupted the files in the past.
Mailer 2.03 was written and is supported by PUCC - Princeton - the lack of it causes about 80 errors per week, so installation of the latest version will be very welcome, but the change of authorship has made the new version significantly different.
We have received email from X400 sites in the UK. DECNET and "X400" syntax converters will be added to the deadmail EXECs in the short term and a test of NOTE400 will be useful in the longer term.
A semi-automatic postmaster is available and will be installed on the ID deadmail. A REXX forwarding program may make this more automatic for the known bugs, but there will need to be an escape mechanism so that the unpredictable human errors are still left for the human maintainer.
We have not yet had a meeting of all the gateways - I see John Seymour at SERJUG and Ian Dallas comes to EARNUS meetings, however a special meeting would still be very useful.
EARN is certain to adopt some version of X400. I have not yet tried NOTE400, but such tests would be useful.
Tests of the G-Box are successful. This is likely to be available and usable when EARN begins to alter its infrastructure. Our experience in the remote support of JNET, which began when Paul Thompson kindly obtained a manual for me at a conference two years ago, is likely to apply to the G-Box as well - this seems to be simply a JNET EARN node with X25 access. JNET users have had great difficulty with access to other gateways - a program to build a proper mail file with BSMTP and send it to a mailer, ("gMail"), has been used but is often out of date (eg the removal of some incorrect syntax from our mailer caught out tens of sites in the USA who regarded JANET as "%ac.uk@uk" rather than "@ac.uk")
In this period there have been no faults attributable to PIXNET, but there was an intermittent line fault in Swindon Exchange which first occurred on 14 June and was finally cleared on 17 June (Sat).
Nothing scheduled.
Nothing significant identified, but capacity may have to be increased to serve the MSA and/or Chessington Payroll Project.
TMPC have asked for a statistics section in the Quarterly Progress.
The table shows performance and failure figures for the various network components on the Rutherford site. Comparisons between various access methods are not easy and must be read with some background knowledge. Major incidents are ones where a substantial number of connections are lost. Minor incidents are ones where only one or a few connections are lost.
Component Major Minor Traffic passed Traffic number
incidents incidents Mbytes/quarter of calls
Local
CPSE 7 3 14,448 848,000
SEEL 3 n/a n/a
PADs 10 5
PACX 0 1
Lines/Modems 18 7
Muxs 3 6
JPSE 16 9 39,622 3,727,300
lines/modems 11
Local area network
VMNCPE 0 0 470 4200
Auscom H/W 0 0 - -
S/W 0 0 - -
370E - - - -
Auscom H/W 0 0 - -
S/W 0 0 - -
Backbone LAN
H/W 0 0 ? np
S/W 0 0 - -
CCD LAN
H/W 0 0 na np
S/W 0 0 - -
Spider Gateway
H/W 0 0
S/W 0 0
Hyperchannel
H/W 0 0 np np
PIXNET
PIXNET H/W 0 0 np np
PIXNET S/W 0 0 - -
VAX VMSFE
Ethernet H/W na na np np
Ethernet S/W na na - -
X.25 H/W na na na na
X.25 S/W na na - -
SUN ARCU
SUN H/W na na na na
SUN S/W na na - -
IBM
4705 h/w 0 0 - -
VTAM/NCP/NPSI 10 12 n/a n/a
VMNCP total 3 6 - -
Network/3270 0 6 2,020 60,000
Line-mode 0 0 1,060 50,000
Other 3 0 (reloads: VMCF/LDSF problems in CP)
SSMP 0 Some 140 2,000
NIFTP 0 0 9,500 800,000
JTMP 0 0 450 13,000
CMS-PAD 0 Some 80 50,000
3270 H/W na na np na
3270 S/W na na - -
Note:
np indicates that it is not possible to provide figures.
na indicates that figures could be made available with effort.
- indicates that the figure is not relevant.
EARN is a rather slow moving organisation in common with many other organisations. We are often delayed by the PTTs, by manufacturers, and by the problems and expenses of running international discussions. Thus during the last six months there has been little spectacular progress but rather a series of useful steps forward.
The progress in the EARN transition to use ISO protocols is reported in another paper.
The new EARN Executive has met three times. My main objective as Secretary General has been to reorganise the EARN paper work. Originally we worked in an informal way. Two years ago we recruited permanent secretarial staff and we received mountains of paper which was usually copies of mail both electronic and paper. Our business is now so complex that we delegate Exec members to provide formal proposal papers. This has stream lined the decision taking.
A further innovation is that Executive minutes and papers are published except where they are confidential. These can be retrieved from LISTSERV@UK.AC.RL.IB . To retrieve the index of papers send a mail message to LISTSERV@UK.AC.RL.IB containing the text GET EXEC INDEX. Specific documents are retrieved in a similar way. Several documents may be retrieved with a single message. As these are committee papers they are often difficult to understand without the relevant background knowledge.
The maintenance of EARN tables is now paid for by EARN under a contract with Nijmegan University in Holland. This is proving successful but costly.
EARN is attempting to get good support for the LISTSERV file distribution service but negotiations are at an early stage.
IBM finance for the Paris office ceases in August. Fortunately EARN has a kind offer from the French universities to host an EARN office at a Paris university. This will consist of a manager, a VAX computer, an IBM computer and a number of research students. EARN had expected to have to pay for these resources but this means that the budget worries detailed below will hopefully be reduced.
EARN is now setting up an office in Amsterdam financed by DEC. This is primarily for OSI support. It is expected that an X.25 switch and management centre will be installed together with a VAX and possible an IBM machine. There will be 3 or 4 staff initially.
A number of 64K circuits have started to appear. In particular between CERN and Montpellier and Bonn and Montpellier. The former line seems to have removed the performance problem between the UK and the USA. Reports now suggest that files can be expected to take minutes to be delivered rather than hours. I would welcome comments on the UK perception of USA traffic.
The gateway has been changed to fold lines on mail coming from JANET to EARN. This appears to be a great improvement but there are still a few problems which are probably insoluble. A particular problem is transmitting binary or Tex files which invariably become corrupted due to the translation tables in various places.
All mail to the IBM machine at Rutherford now passes through the mail system and this has removed the distinctions between UK.AC.RL.IB, UK.AC.RL.MAIL, UK.AC.RL.EARN and EARN-RELAY... EARN... has now been removed as a partial domain.
Unfortunately BITNET-RELAY has not been registered.
JNT were hoping to send more traffic over the JANET NSF link to BITNET. Unfortunately this has technical problems with many systems in BITNET not having the capability to deal with the address mechanisms required.
Rutherford is now exploiting LISTSERV for distribution lists both in EARN and JANET. This is now better supported.
Traffic from the UK is still using a 9.6K circuit to CERN. It had been planned to use a channel on the HEP 64K circuit but that has been delayed but in now available. This circuit is available on a temporary basis until the end of 1989.
A 64K circuit is on order as part of the EARN transition project and should have been delivered in mid February but has yet to be delivered. This line is financed by DEC and it was expected that the UK would contributor the cost of a 9.6K line to it. Unfortunately this finance is not forthcoming and as a consequence it is likely that this line will be removed after initial ISO test are complete and it now seems unlikely that it will carry user traffic. It is unclear what will happen at the end of 1989 when HEP may withdraw the loan of their circuit. Thus users would be well advised to start to seek alternative routes for their traffic. Should the UK continue to pay its subscription to EARN then traffic will be allowed to EARN and BITNET sites. However, should the UK decide not to pay its subscription as a result of the absence of a direct connection to EARN then EARN would bar traffic to EARN and BITNET sites from the UK which arrived via other routes. It is unclear what will happen in 1989.
Yugoslavia and Egypt are now connected to the network. Cyprus is unfortunately still not connected for financial reasons.
India has been accepted as an Associate Network but is not yet connected.
Pakistan has applied to join as an Associate Network and this is currently being voted on.
There has been some progress in getting connection to Ease Europe. We have applications pending from Poland, Hungary, and Russia. Discussions are taking place with politicians in high places and it seems that the thaw in East West relations may well allow connections in the not too distant future. This is a slow moving area!
Nearer home there is now a connection to the European Centre for Medium Range Weather Forecasting at Shinfield Park. They have a direct connection to Rutherford rather than via JANET. Pergamon Press has been accepted as an Associate Member but their means of access has yet to be determined. From time to time traffic is detected from commercial organisations which are then invited to apply for Associate Membership. BT at Martelsham is expected to be an Associate member shortly.
SNA protocols can make far better use of the bandwidth available. It provides full duplex protocols and various other advanced facilities for performance improvement. It is particularly useful on 64K lines. Thus the Bonn Montpellier, CERN Montpellier, Yugoslavia Austria, Italy Montpellier the transatlantic route now use SNA. It is expected that a new Brussels Montpellier link will use SNA shortly.
EARN has now set up an SNA group to study the use and impact of SNA on EARN which is expected to produce its first report in a month or two.
There are now line sharing agreements with EUNET, NORDUNET, and HEP for a number of 64K lines. The aim is to reduce costs, to provide better services, and to speed up the EARN transition to use ISO protocols. We exact to continue to make such agreements where they are of benefit to users. Eventually we hope to have further agreements to carry each others traffic but this depends on further progress with transition.
IBM has set up a 64K super computer network which is based on a number of lines out of Montpellier. It had been hoped that this would be part of EARN but for various reasons this was not possible. However, some of the bandwidth is being used for EARN traffic. Ways of co-operating with this network are being examined.
EARN hopes to play a full part in the expected COSINE/RARE/MDNS X.25 network which is now names IXI. The exact nature of EARN's co-operation is not yet determined as IXI itself is not yet well defined in terms of dates and services. EARN is hoping to, and has offered, to undertake studies financed by COSINE and negotiations are at an early stage. Meanwhile EARN is still progressing with its own transition plans but these will be reviewed as IXI progresses.
Licensing issues are no longer are a problem. It would be fair to say that CEPT and the regulatory bodies have lost interest in EARN. The threat of EARN creaming off large amounts of PTT traffic have not materialised. In addition the liberalisation of the European PTTs has reduced their interests in EARN and similar networks.
EARN 89 is in Crete. There will also be a meeting of the EARN technical groups, the EARN Executive and the EARN Board of Directors.
Undoubtedly the main topic for the Board meeting will be the financial arrangements for 1990. As a result of the ending of IBM support, the increased DEC and other support together with the decision to fund more activities, finance has become a complex and delicate issue. If we do as suggested by earlier Board meetings and support some technical and managerial staff then the the contributions from members will double. It is therefore expected that some budget cutting will take place which will unfortunately reduce the support EARN will be able to pay for.
EARN has a project to collect and analyse the international traffic. This is achieved by each international node collecting figures and sending then to the collection centre where they are amalgamated and published.
Unfortunately not all international nodes are yet in a position to collect figures and so the analysis is not complete. None the less they give some useful information.
Attached are the figures for January 1989 (STAT8901) and February 1989 (STAT8902).
The figures are in terms of records which are traditionally taken to be 80 bytes. The figures are collected from the NJE systems and thus are the total traffic seen at the line level rather than at the mail and file transfer levels.
As far as the UK (marked GB in the tables) is concerned the transmitted and received totals balance for both months. The month to month figures show an increase from 7.3% of the total EARN traffic to 9.0% and there is no known reason for this increase.
The UK is fourth in the table for total international traffic. The leaders are:
Country January February DE 20.3% 21.1% IT 10.4% 8.3% IL 9.5% 8.9% NL 7.9% 9.4% GB 7.3% 9.0%
The figures for France are inaccurate and are probably over 10%.
The traffic to the USA is:
January February
US 9.5% 9.0%
The high figure for Germany reflects the high number of EARN nodes within the country and the importance of the network within the country. The GB is remarkably high considering the relatively poor view the community have of EARN and the difficulty UK EARN management have in communication with the users. The traffic level to the States is surprisingly low.
The GB figure excludes the HEP traffic to CERN which now travels over an alternative route.
The popular correspondents from GB are:
US 36.0% 40.1% IE 11.8% 11.8% CH 10.6% 7.1% DE 9.6% 11.1% FR 7.4% 4.6%
The traffic to the USA is very high and is in part due to the HEP traffic to places like SLAC. The High level of traffic to Ireland may be due to the presence of a popular MAC server,
As mentioned earlier these figures are incomplete but apart from France give a good indication of the traffic patterns.
The documentation for the EARN transition project is held on LISTSERV@UK.AC.RL.IB. The first document to be retrieved should be PROJECT SEC0. This can be done by sending a mail message to LISTSERV@UK.AC.RL.IB containing the line GET PROJECT SEC0.
All five Northern Telecom Switches have been installed. The delay now is the delivery of lines from the PTTs.
The first connection is between the RAL switch and the Dublin switch which is also connected to the management centre. There have been some problems which are all do do be cable lengths and which are now resolved. We are now waiting for faster 19.2K modems as inter switch links cannot operate at less than 9.6K and we have to retain at least 4.8K for the normal EARN traffic.
Lines are now on order between CWI Amsterdam to CERN, CERN to Montpellier, and Montpellier to CWI. The line between RAL and CERN will be dropped as soon as initial testing is complete. Thus contrary to expectation EARN will end up with a triangular backbone network. The reason for the reconfiguration is that EARN was expecting the UK to contribute part of the cost of the RAL to CERN link but this has not been found to be possible. It is likely that the RAL switch will be moved to another location which has yet to be identified.
EARN is expecting to be given a 64K channel on the DEC USA 2M link. This terminates in Galway and we now have a sponsor to pay for a 64K connection to Dublin. In order to utilise this link Dublin will have to be connected with a 64K line to the backbone - probably at CWI. When this happens the Dublin to RAL link will be dropped and with it the JANET connection to Ireland.
The G-boxes are VAX computers which form a gateway between traditional EARN and NJE over OSI session which EARN will operate across the X.25 infrastructure. The code has been developed by Joiners Associates and uses the DEC OSI products PSI/VOTS/OSAC. Eight of these machines have now been delivered - one to Rutherford. The software has been delivered and testing is starting. It is too early to comment on its performance.
Tests between a VAX and the Northern Telecom switches at the X.25 level show no problems.
The first tests are being conducted between Dublin and Rutherford and should be complete in a month or so. Connections to other sites will take place as soon as other lines are delivered by the PTTs.
The E-boxes are functionally similar to the G-box except that they are based on IBM computers and only the code and not the computers is being provided. The code has been developed by IBM and used the IBM OSI products NPSI/VTAM/OTSS/OSNS.
Tests between the Rutherford IBM and the Northern Telecom switch have taken place which have revealed some minor problems which seem to be due to the archaic version of the IBM X.25 code (NPSI) currently in use.
The system will be delivered to Rutherford shortly and testing will take place between the G-box and E-box systems.
Unfortunately it is non-trivial to connect two X.25 networks together. According to the standards X.75 or a network level gateway is required.
Unfortunately academic networks do not usually offer X.75 but rather they interconnect with modified X.25 connections which we term "gateway X.25". This will be available on the Northern Telecom switches late this year. Some preliminary test have been carried out between a Seel switch and the Northern Telecom which indicate that traffic from the Seel to Northern Telecom is possible as long as the calling address is suppressed. There are also some addressing problems as a network connected to must be able to understand the EARN addresses.
Network level gateways are not yet available. This is probably because the form of NSAP addresses is not yet firm from an international point of view.
At the recent EARN Executive Meeting it was decided with great reluctance that sanction must be taken against the UK for failing to pay their full contribution. Although an invoice has yet to be issued, correspondence with Bob Cooper convinces us that the UK will not pay the remaining 10% or so.
Thus, an invoice will be issued and if full payment is not made before October 1 then the Executive will recommend to the Board of Directors at their October meeting that sanctions should be imposed on the UK. They will recommend that the UK is denied use of EARN for December. Steps will be taken to ensure that alternative routes to EARN sites such at the HEP, EUNET, NSF or others are barred. In addition BITNET, as a sister network, may be asked to bar UK traffic.
As this will be discussed at the Board of Directors Meeting the UK will have an opportunity of explaining its position.
You will no doubt appreciate that this will have a devastating effect on the UK community and RAL should take steps to ensure that it is not a party to the non payment of the contribution or to the removal of the service. My suggestion is that the mailer should be modified to return mail destined for EARN with a suitable message.
It is anticipated that the Irish service will be maintained by onward linking the Irish line to the temporary 9.6 X.25 EARN line. As both these are funded from outside the UK this should not present a problem. I assume that as the UK will no longer be a member of EARN RAL will have no option but to obey the instruction of EARN with respect to the connections and lines.
I shall require guidance.
Dear Mrs. Humphreys,
Thank you for your letter (from Mr. G D Bennett reference LM/216) and paper on the allocation of DNICs.
I have discussed your paper with the management of the European Academic Research Network and they welcome the paper. Their view is that the allocation of DNICs should be based on a need basis rather than on regulatory considerations. We appreciate that DNICs are a scarce resource and that our requirements are for a relatively small address space. Thus if necessary are needs may be met by a shared DNIC.
May I therefore confirm that the European Academic Research Network would still like to acquire a UK DNIC. If we are given a shared DNIC we would request that we are allocated numbers with the fifth digit 2 as this would be least disruptive to our current address plan.
We currently operate an international X.25 network with connections to a few countries but ultimately intend to have connections in all West European countries and a few countries on the periphery of the region. The network is for the benefit of the research and academic community and EARN is a non profit making organisation.
Our network is based on switches from Northern Telecom and offer X.75 connections.
Our model of the world is that we operate an international network with X.75 connections to sub-networks. These sub-networks may or may not be operated by EARN and may be the public network within a country (regulations permitting).
As yet we have no X.75 connections for technological and regulatory reasons which we would hope to overcome within each country on a bilateral basis.
We have two problems with the allocation of DNICs.
Firstly we need a DNIC for the international part of EARN. Currently we use 2000 which is, of course, un-registered. This would lead us into problems when we apply for connections with the TPO networks. In addition DNIC 2000 is liable to be allocated at some time.
Secondly we need a DNIC for the UK part of the network. This is an interesting problem as EARN is connected to JANET (the academic network) which has allocated itself the DNIC 0000 (again un-registered). I have spoken to Ian Smith of JANET and passed him a copy of your letter and he may well approach you with an application.
Thus at this stage our exact requirement is unclear and on a pragmatic basis the requirement for a DNIC for the international part of the network is most pressing. Ideally we would like an internationally allocated DNIC but there appears to be no mechanism to make such an application or at least a mechanism with any chance of success.
Interestingly the Dutch regulatory authority has allocated a DNIC for the so called IXI academic network which is also an international one. Thus there seems to be a precedent for the allocation of national DNICs for international networks.
I look forward to your response to our application and would be happy to provide you with any further information you may need.
Yours sincerely
Paul Bryant.
Dear Johanne,
I have now studied the document 241-1001-317 that you kindly gave me.
I believe the scheme gives us most of what we want. The remaining minor problem is that there is no address manipulation to, say, hide the fact that JANET has a DNIC of 0000 whereas from within EARN we would like it to be 2340. However this is a small point.
The paper seems to reduce to the following:
Within the NT network addresses of the form pddddnnnnnnxxxx where p is the prefix digit, d is any DNIC, nnnnnn is up to 6 digits, and x is any remaining arbitrary digits can be directed to a gateway port.
The called address may be transformed to pddddnnnnnnxxxx , ddddnnnnnnxxxx, or nnnnnnxxxx. I assume that the calling address will undergo a similar transformation.
For incoming calls the called address will have similar characteristics.
The calling address verification on incoming calls may be suppressed. If not suppressed it is unclear what calling addresses would be permitted.
The document specifies that nnnnnn is up to 6 digits but does not specific whether 0 digits is acceptable. If 0 is acceptable then you have an interesting case where dddd is the local DNIC whence all local calls with the prefix and DNIC will go to the gateway.
Thus my conclusion is that I would like to get my hands on this release as soon as possible.
Yours sincerely
Paul Bryant.
The equipment involved, where -- is an X.25 connection and == is an asynchronous connection, is:
Public X.25--JANET gateway--PAD==PACX async switch==NT
|
+--------------------------------GBGBOX
For access to the NT switch the process is:
Call 23422351919169 on the public network. The resulting dialogue is as below. Your responses are enclosed in [ ]. R indicates the carriage return character. Comments are enclosed in " ". The call can be cleared from the local (your) end. The performance is poor!
Please enter your authorisation and address required in form: (user,password),address > [(,),000000005040R] "This is the X.25 JANET address of the PAD" Call connected to remote address [R] "This return wakes up the PACX port" RAL PACX 2000 -------------
Please report all faults to the Service Line on x6389
YOUR PACX 2000 TERMINAL ID IS T503
If you require information on services available please type help after
the Enter class prompt; Enter class [ntR] "This selects the NT console" class NT start You are connected via PACX 2000 port P259 [R] "you are now connected to the NT switch so return gets" > "the prompt"
For access to GBGBOX the process is:
Call 23422351919169 on the public network. The resulting dialogue is as below. Your responses are enclosed in [ ]. R indicates the carriage return character. Comments are enclosed in " ". The call can be cleared from the local (your) end. The performance is poor!
Please enter your authorisation and address required in form: (user,password),address > [(,),000000004617R] "This is the X.25 JANET address of GBGBOX" Call connected to remote address Welcome to RAL EARN VMS Gateway Machine running VAX/VMS V5.0 Username: "you may now log into the VAX"
Dial up access is provided and the equipment is:
PSTN==V22bis==Camtec PAD--X.25 JANET--PAD==PACX async switch==NT
V22 |
V21 +---------------------------------------------GBGBOX
The PSTN number for the V.24 service is +44 235446956
On the call being connected the resultant dialogue to access the switch is:
* The 2400 BPS dial-up service on * * Abingdon 446952 ceased on * * May 31st 1989 * * * * The new service on Abingdon 446956 * * supports 300, 1200/1200 or 2400 BPS * PAD> [call 000000005040R] *** Call connected [R] "This return wakes up the PACK port and the" PAL PACX 2000 "dialogue continues as above"
On the call being connected the resultant dialogue to access GBGBOX is:
* The 2400 BPS dial-up service on * * Abingdon 446952 ceased on * * May 31st 1989 * * * * The new service on Abingdon 446956 * * supports 300, 1200/1200 or 2400 BPS * PAD> [call 000000004617R] *** Call connected Welcome to RAL EARN VMS Gateway Machine running VAX/VMS V5.0 Username: "you may now log into the VAX"
Dear Simon,
I have accepted your application to join EARN and attach a completed form I have filled in on your behalf.
As you wish to use a dial up connection I enclose a disk with suitable software for making a PC operate as an IBM 3270. Documentation is on the disk. I also attach documentation for making dial up access.
I attach a form for you to apply for an account on our IBM computer. I suggest that we limit your use to 500 pounds for a year which should be more than adequate for mail. You can vary this limit if you wish. Please return the form to me when you have completed and signed it.
Yours sincerely
Paul Bryant. EARN EXECUTIVE
Dear David,
Further to our telephone call I enclose:
1 Form requesting computing services on out IBM. I have filled in a limit of 500 pounds on your use which I believe will be more than adequate. Please complete the form and return to me.
2 IBM PC disc which will turn a PC into a dial up IBM 3270. Documentation is on the disc.
3 Some information on our dial up service. Most of it is irrelevant and I have marked the important bits.
4 EARN gateway document which I may have sent you already.
5 Some information on the mail command on the IBM.
Yours sincerely
Paul Bryant.
Dear Ms. Pentol,
Rutherford Laboratory used to have two analogue leased circuits between Rutherford Laboratory and CERN in Geneva Switzerland. One was used for High Energy Physics traffic (XHAR-GNA DP1) and the other by the European Academic Research Network (DDC-GNA DP1). it was decided to replace these with a single digital circuit which was duly delivered.
XHAR was cancelled on 27/6/89 in the UK and DDC was cancelled on 30/6/89 in the UK. Subsequently we decided to retain DDC and the cancellation was rescinded on 11/7/89. Regretfully we discovered that CERN had cancelled DDC on or about 27/6/89 and had not cancelled XHAR. The service on both lines then ceased. It seems impossible to restore this service and in negotiation with BT International it was agreed to try and join the DDC UK end with the XHAR CERN end and it was thought this could be done rapidly.
Since that time we have not been able to get the service restored. The responses from BT International indicate a measure of confusion by the variety of responses we have received to our enquiries.
We have considerable concern that little progress is being made and that we are unable to find out exactly what is happening.
The lack of this line is now causing us difficulties in that we are unable to take part in vital development in the EARN network to use OSI protocols as demanded by CEPT. The UK should be playing a key role in this development which require international co-operation. Unfortunately the project is slipping badly and we have a considerable amount of expensive equipment lying idle.
As our normal contacts with BT International are not successful I am writing to you in order to escalate the problem,
I hope you will be able to find out what is happening and reinstate the line at an early date. Please do not hesitate to contact me or our technical expert Mr. R Brandwood (0635 446281) should you require further information.
Yours sincerely,
Paul Bryant. EARN UK Director.
Out among the 23 countries and 70,000 EARN researchers, there are users such as yourself, developing software tools that may very well have a large impact on the way EARN develops in the future. The EARN Executive would like to encourage the continued development of these software tools for EARN and to stimulate EARN users and user support staff to develop such tools.
To this end, EARN has set up a Scholarship programme that will in 1990 award up to three grants of 3,000ECU each to individuals or groups who, in the opinion of the Scholarship Programme Evaluation Committee, are doing work which will significantly benefit EARN and EARN's users. Grants will be paid directly to the individuals involved.
If you are interested in applying for an EARN Scholarship for software development work currently under way, please send a summary of the work to SCHOLAR@TAUNIVM before December 15, 1989.
Rules for submission of Scholarship applications are:
Since the last meeting no significant changes have been made to the gateway.
The LISTSERV service has developed with a number of further lists being supported. There are now two LISTSERVs known as LISTSERV which operates in the EARN domain and LISTRAL in the JANET domain. The aim has been to move lists to the most appropriate service. This reduces the cost of traffic traversing the mail gateway.
Whilst the service is stable and appears to attract little adverse comment there are still many areas which to my mind are unsatisfactory.
The most urgent need is to bring into use the new mail system. This has taken far longer than expected due to loss of staff, training of new staff, the use of the VM/XA operating system (RAL is one of the few users) under which the mailer was reluctant to work. Most problems are now solved and the JANET site should be brought into use by the end of the year and the EARN site shortly after.
The benefits will be that the mailer has fewer bugs, obeys RFC822 more accurately, and will thus fault less mail. Hopefully this will reduce the load on Rutherford support.
A further development will be to combine the two mailers thus halving the computer resources absorbed by the gateway.
It is clear that gateways are perceived to be a barrier in many ways.
The visibility of the remote network is poor. The UK users do not have a good grasp of the facilities of EARN or the same ease of access to them. For example, who is aware of the "list of lists" which allows you to search out and join the lists of your choice. The UK user does not have access to the TELL command to easily examine these lists.
An additional problem is to get at the users to promote the services and most information comes from personal contact particularly with the support service at Rutherford.
For your information I attach the list of lists. Unfortunately this document is just the tip of the iceberg of useful information.
Mick Reid will present the UK statistics which give a detailed break down of the UK use of the network.
EARN now collects statistics on a Europe wide basis and attached is a review of a typical period which was presented to the EARN Board of Directors. The remarkable observation is that regardless of the presence of a gateway the UK traffic is comparable with other large countries which have extensive EARN networks within their country.
More detailed figures can be obtained on a month by month basis from LISTSERV@EARN.DEARN.
The Executive now meets every 2 months and the Board twice a year.
EARN now has a policy of publishing most of its papers and these are stored in LISTSERV@UK.AC.RL.IB , be warned there are now 141 Executive papers and 59 Board papers. The most useful document is the index and you can get this by sending a mail message to LISTSERV@UK.AC.RL.IB containing the text GET EARN INDEX. I would also warn you that most document are incredibly boring and the meeting minutes arcane to a fault.
The topics of interest are:
Attached is a report presented to the EARN Board which outlines progress.
The EARN OSI Centre (EOC) now has 4 permanent staff and so progress is now very good. The X.25 switches apart from the UK one are interconnected and a number of G-boxes are being put through their paces.
Sadly the 64K line from the UK was cancelled as the UK were unwilling to contribute to it. It was planned to retain a 9.6K line for a few months of testing but it was inadvertently cancelled by CERN and we have not been able to reinstated it yet. None the less we have tested out G-box which is also connected to the IBM computer.
EARN has now moved its management centre to CIRCE in France. EARN France kindly agreed to host the centre and provide some staff free of change. Alain Auroux, who is the EARN manager, will soon return to IBM and EARN is seeking to recruit a new manager.
Experience has shown that EARN must have a full time manager if it is to operate effectively otherwise many activities just do not get done.
Dear Alain,
My expenses for the Lisbon were:
Hotel 66212 PTE = 272.14 UKL
Taxi from airport 600 PTE = 2.47 UKL
Air fare 306 UKL
==========
Total 580.61 UKL
==========
Thanks.
Yours sincerely
Paul Bryant.
Welcome to the EARN annual report. Since the last one much has happened. Since EARN was set up in 1984 a vast amount has happened.
EARN has had a year of achievements and this introduction mentions many of them which are explored in detail in other sections. Many events and developments have taken place but EARN has many problems which it is vigorously trying to solve with great success.
There are now a large number of customers who rely on the facilities provided by EARN. Without it projects would be slowed down or in many cases would not be possible. This has placed a responsibility on EARN to provide a guaranteed professionally run service. This contrasts with the volunteer effort which launched the network. It would have been impossible to launch this network without the vast amount of free effort provided by many sites and people but with the best will in the world it is wrong to rely on effort which may vanish at any time or which may decide to move the network in undesirable directions.
The response of EARN has been to hire staff or contract with sites to provide the essential tasks needed to keep EARN running. The most important person is the EARN manager responsible for the day to day operation of the network. Other staff are employed on the maintenance of the EARN tables and LISTSERV. Although this has raised the fees EARN has had to charge it has enabled EARN to provide a guarantees of service to the customers. The network still looks to the army of volunteers to provide many of the developments and services enjoyed. Without the outstanding job done by these volunteers EARN would be a far poorer network.
No network is static. As with EARN's attitude to operating the current service it also takes the greatest care to ensure that changes or developments to the network will at least maintain the quality of the service if not improve it. This has made development rather slower than many would have liked but has led to the improvement of the quality of EARN.
There have been several strands of development.
On the organisational front EARN has had to show itself to be well organised and competent. Finance has been a particular problem with the move from being financed by IBM to being financed by the members. The strategy now adopted is to provide a draft budget and country contribution statement to the Spring Board of Directors Meeting and a final one for agreement to the Autumn meeting. Whilst the mechanisms now work well EARN still has two difficult tasks. The first is to keep the budget as low as possible so that contributions are low thus restricting the work EARN would ideally like to undertake. This has to be done as countries have very restricted sources of finance and many deserving calls on that finance. The second task is to find some equitable way of apportioning the contributions. If this is done on traffic grounds then countries will minimise their traffic and if this is done by all countries nothing will be achieved beyond the counter productive reduction in the service to the user. If contributions are based on something like GNP then countries such as Switzerland and Israel get their communications as an exceptionally low cost per byte. Many hours of study by many people have failed to resolve this problem.
Technically EARN is developing along a number of fronts and an ultimate strategy is difficult to determine. The OSI program which is well supported by DEC and Northern Telecom is now centred on the Amsterdam OSI Centre. Good progress is being made with the X.25 switches in place and the testing of the G-box and E-box systems going well. This provides a mechanism for transferring NJE traffic across an X.25 network. EARN has now produces a substantial document containing details of the OSI programme.
In the Nordic countries there is an extensive network based on ethernets interconnected with bridges. This network carries many services including EARN NJE traffic.
For some time there has been pressure to allow SNA to be used freely on the international lines. This has led to an SNA working group set up decide whether this is a good idea and if so how SNA should be organised. Good progress has now been made.
The tendency now is that EARN NJE traffic will be carried over a variety of bearer networks. It should also be remembered that EARN is attempting on a longer term to exploit newer high level protocols such as X.400 which tend be be restricted in the bearer networks that can support them.
Drawing conclusions is difficult as there are many conflicting interests at work. However one interest above all others predominates and that is to meet the user requirements rather than any technological or political aspirations. EARN hopes to try and make some sense out of this complex situation over the next few months and produce a new statement on its future.
EARN is not the only international network or networking organisation. EUNET, High Energy Physics, the emerging IXI network, SPAN, and no doubt others all combine to provide a variety of services which at times compete. EARN has been working with many of these groups with a view to sharing resources and improving users services. This has led to line sharing arrangements and also agreements to carry each others traffic. It is difficult to see how these various organisations will evolve. It is difficult to see how EARN will evolve and the other networks have similar problems with their futures.
EARN has been accused of being secretive. The truth was that being an open organisation take considerable effort in ensuring that information is well produced, readable, and accessible. EARN has revolutionised its workings. All Board and Executive papers and minutes, except a few containing confidential information, are now published in LISTSERV. This has entailed producing the papers to a far higher standard. It has been of great interest to see the response from those studying the 200 or so documents on file.
EARN is caught up in the many technological and political changes in European networking. EARN has to evolve and adapt to meet the new challenges and opportunities. EARN has advice in abundance from the OSI, TCP/IP, SNA, and DECNET experts and the many organisations advocating various lines of development.
It seems that in the next few years there will be no consensus on one single network technology. Indeed, were this to take place it would be probably be rendered obsolete overnight by new technologies.
It must also be remembered that EARN is an exploiter of networking and not a developer or innovator.
Thus any EARN future is a compromise between the customer needs, the technological opportunities, political pressures, and funding. Perhaps the only firm statement is that the customer needs are the single motivation.
Dear Mrs. Humphreys,
I wrote to you on November 2, 1989 giving the European Academic Research Network's (EARN) response to your letter concerning the allocation of DNICs. In addition I confirmed our application for a DNIC.
Events have now moved on rather faster than I had anticipated which make our requirement for a DNIC a matter of some urgency.
You may be aware that the European Commission is financing an international X.25 network called IXI as part of the COSINE project. This is being undertaken by the Dutch PTT and has a Dutch DNIC. Various national and international networks will be connecting to this network one of which is EARN.
Networks are connecting to IXI in various ways. Some via X.75, some via "gateway X.25" which provides some awkward address conversions, and some via network level gateways. EARN wishes to connect to IXI via an X.75 as this provides the most effective type of connection which will allow full transparency of addresses between the networks. Unfortunately this X.75 connection will not be allowed by IXI unless EARN has a properly registered DNIC.
May I therefore confirm EARN's application for a DNIC? May I also request an early response as we are now only a matter of months from making a connection between the EARN network and IXI and wish to avoid any interim connection methods?
I look forward to your response to our application and would be happy to provide you with any further information you may need. I did include some further details in my previous letter.
Yours sincerely
Paul Bryant. EARN Secretary General.
Dear Alain,
As you know we want to use the spread sheet for the 1990 EARN finances. I have now enhanced the spread sheet to include the useful figures you provided at the last meeting on the expenditure to date and the out-turns. I have done this for both 1989 and 1990 although the 1990 figures are, of course, zero.
There are two macros alt/a and alt/b which provide a 1989 and 1990 summary of the figures the second of which could be the basis for the presentation to the next Board meeting. The 1989 figures are the ones which would have been given to the BOD has we been using the spread sheet at the last meeting. The Board meeting will need to have a written explanation of the figures such as we have provided in the past.
I attach a print out of the complete spread sheet and the summary for 1989 and 1990. For the next Executive I do not think the figures themselves need changing except to update the contributions received and the expenditures/commitments and expected out-turn. However, we shall have to revise the 1990 figures in the light of the need to finance the EARN manager.
There follows a few comments on the spread sheet which I hope are helpful.
The idea is that the original 1990 budget is never changed but that we only modify the revised budget as the year progresses. This allows a check to be kept on how the finances are changing which is normal budgeting practice. If the 1990 origin budget is changed then as the figures carry forward into subsequent years these figures will be changed and mess up 1991/2/3/4 figures. Changing the revised budget has no effect on future years. Of course, at the end of the year a change will have to be made to carry forward the actual figure which will then effect the subsequent year. Thus at the end of 1989 we will change the model to carry forward the true surplus rather than the planned one. At this time the commitment, out-turn, and the expected out-turn will be deleted and the expenditure will become the actual column.
May I remind you that the "To carry forward" and "Working Capital" (section 8) are important figures. "To carry forward" is the income less expenditure. "Working capital" is the amount of money we would like to have at the end of the year which is any surplus from previous years and any contingency build up. Thus the contributions needed are derived from the income (less contributions), expenditures, and "working capital". The "working capital" is, of course, the surplus for the next year. It could be more business like to decide on our working capital rather than letting it be the addition of the contingency and surpluses. As you know I tend to think that any surpluses should be used to reduce the contributions. If we want to build up a contingency quicker or to a larger value this should be done by adjusting the "working capital" explicitly rather than adding to surpluses by "windfall" under-spends.
Under 9.6 "International country's lines" I have put in estimates for 1990 onwards. It would be useful to get accurate figures sometime in 1990 that that year.
Under the "Country Contributions" you will see "Estimates" - this is because I have no records of the original contributions. You will also see "BAD Debits" and "currency loss+taxes" - these are needed to correct the figures to carry forward to subsequent years as revised rather than original figures were used in your computations for future years. I think that it would be easier to always the use original figures in these computations and to make an adjustment at the end of the year. This would then effect the contributions for the subsequent year and the contingency fund will cushion any differences between original and actual figures. This will allow us to deal with the budget from a stable base throughout the year.
May I also remind you that the contributions are automatically computed from the finance required, the Rare Keys, the GNP/traffic figures, and the expenditure split. This differs slightly from your calculation in that the GNP figures are used in their exact ration rather than deriving EARN Keys and using them. With a spread sheet this is an easier computation and a little more accurate which I suggest we use.
I have highlighted the columns which can be changed with safety or rather the ones I expect to be changed.
No doubt we will want to make changes to the model as time progresses.
I hope that your secretary is making progress in working with Lotus 123 and will be able to take on this enhanced one.
Yours sincerely
Paul Bryant.
Thank you for the comments on the EARN Board of Directors Meeting.
It would indeed be possible to produce minutes of Board of Directors meetings which include the comments made by members. This is up to you the Directors. It should be remembers that the Board of Directors meetings' serve two purposes - first they ask the Directors to take decisions - second they report on events. As such, the vital purpose of the minutes is to record the decisions so that the Executive know exactly what they are expected to do, what policies the Board wants. Also it is important to record what the Board has been told what has happened and what is happening to ensure that the Executive can be assured that its actions are known and that the Board has an opportunity to object or re-direct them.
This is in contrast to the minutes of a working group where comment is appropriate.
The minutes are intentionally devoid of comment apart from comments explicitly requested to be included by a member. In fact this was the policy of the BOD which can be found in Board Meeting number 3 minute 1 held September 4, 1984 and cataloged as BOD3 84 in LISTSERV@UKACRL. This was reinforced in the new method of working of the Executive to be found in EARN27 89 which was approved by the Executive. A similar method of working has been introduced into the BOD and this was discussed at the Crete BOD meeting and well received. See BOD19 89.
In short the meeting receives "proposal papers" and "information papers". All items are accompanied by papers. It is expected that a "proposal paper" is ether "approved", "approved with minuted changes", "deferred for further development", or "rejected". It is assumed that the paper contains all the major relevant information on which the Board may wish to base its decision.
It may well be that, say, the OSI paper did not explore all the relevant aspects of the subject or may have passages with which the members disagree. In this case the paper should have been rejected or returned for re-drafting or relevant comment put in the minutes. Were there to be various arbitrary comments in the minutes then what has the Board agreed to? The paper or the paper plus the arbitrary comments? It should be remembered that the minutes are not intended to be educational.
The the case of "information papers" these are only to inform members what has been happening and should contain all relevant information. If we take the case of the SNA paper, which was mentioned, any comments should go to the SNA working group as this is where they would have some effect. In the Board minutes they would have no effect.
If comment were to be included then experience suggests that members would react by claiming that their comments were not included or had been miss represented. In any case the comments would be reported as seen by the secretary who is well known to have strong views on some subjects and would no doubt "bend" the comments to support his point of view.
Members, in reporting the meeting, may well like to report it as they saw it and emphasise certain aspects and not others in which case a string of arbitrary comments would prejudice the view they may wish to present. They could also find that the reporting of their "off the cuff" comments could be embarrassing at a later date.
The Executive feel that it is important that minutes come out quickly. Even with no comment they are the best part of ten pages but come out within a week of the meeting. Should comment be included then they would take a long time to produce and be much larger. The current form is very easy to produce, comment is most difficult to edit as much of the comment is long and rambling and often fairly irrelevant or a repeat of material in papers.
Thank you for the note from the "NSAP working party".
The proposal is in line with UK, EARN, and COSINE/RARE WG4 thinking.
The general view (forgetting Victor Reije of IXI/SURFNET) is that an NSAP defines a SERVICE with a unique identifier of up to 40 semi-octets. This identifier of 40 semi-octets is carried in the X.25 extended address field and in similar fields with other sorts of network.
Received wisdom is that an NSAP SHOULD NOT contain routing information or any network specific information. Any routing information should be contained in tables held in the calling terminal and in gateways in the path to the called service. Thus regardless of haw you get to a service (ethernet, TCP/IP, DECNET, X.25,...) the NSAP is the same.
ISO defines several types of NSAP. (I have lost the relevant standard) but there is one for X.121, TELEX, telephone plus the all important DCC scheme. The first two semi-octets define the type. The X.121, TELEX etc types are (to the informed cynic) for the benefit of the PTOs who believe that all communications are run by the PTOs and thus you can name anything in the PTO address space with an NSAP. You and I know that this is not true and we have private networks (JANET, LANs etc). Hence the academics think the DCC scheme is better.
In the DCC scheme the first two digits are 38 for an NSAP made up of further semi-octets or 39 if the rest is in binary. The UK have opted for 38. There seems no clear arguments for 38 or 39. After the 38 or 39 you have a 3 digit country code. The rest of the NSAP is an organisation code allocated by the appropriate authority (DIN in Germany, BSI in the UK). After the organisation code the rest of the NSAP is allocated by the organisation in any way it thinks fit. In the UK we define a site code. After the site code the rest of the NSAP is defined by the site.
The country code part is identical to the UK. The site code is a bit different. We also have a format identifier (just in case you want to start again with another scheme) and the site code is derived from part of the JANET X.25 address of the site NOTE - THIS IS NOT TO BE USED FOR ROUTING BUT IS AN ARBITRARY WAY OF NUMBERING SITES.
We have defined a scheme at Rutherford for the private part which I publicised in the EARN X.25 list some time ago.
The EARN scheme is defined in PROJECT SEC15 in LISTSERV@UKACRL
In short - I think DFN is doing the right thing.
I hope this helps.
Paul.
Herewith my unexpurgated thoughts on the EARN mission. Paul
The long term mission and strategy for EARN is bound up with:
Regretfully both of these topics have a number of uncertainties.
In all these discussions EARN must remember that its single reason for existence is service to its community of users. The political and technical aspirations of various fractions must be recognised. Unfortunately a certain amount of compromise is needed to achieve the best for the community.
The strength of EARN has been to provide a service based on IBM methods. Without the the pressures of CEPT, RARE, COSINE, national groups, and others it is a reasonable assumptions that the network would have gradually adopted SNA or possibly have followed BITNET II. It is also likely that in various areas these protocols would have been carried over X.25 or TCP/IP to take advantage of national facilities.
What has happened is that EARN has been forced first by CEPT to migrate to OSI protocols, secondly by sponsors who have forced EARN down a particular route, and now thirdly by COSINE with particular political aims.
What does the user want? Undoubtedly the world separates into IBM, DEC, and UNIX which relate broadly to SNA, DECNET, and TCP/IP. It is abundantly clear that between homogeneous machines the relevant protocol set gives the best service - in the case of SNA and DECNET it is completely and well supported by IBM and DEC plus suppliers of emulators for non native systems - in the case of TCP/IP it is well supported by many manufacturers.
Many, including myself, believed that OSI protocols could replace all the above and solve interconnection between heterogeneous systems. Experience now suggests that this is highly unlikely except in the case of X.25, X.400, 802.3/4 which are really retro-standardisation of PTO Xerox and IBM protocols. Their popularity is because of PTO/CCITT and manufacturer activities. It is difficult to see FTAM becoming popular in the near future and even less JTP and VTP except where they are imposed in spite of the community requirements.
My view now is that OSI protocols had a window of opportunity which was only partly successful. It is interesting to note that the successful OSI protocols have been those which have been standardised pragmatic ones which have paid scant attention to the seven layer model and have been of little academic merit. The well designed ones such as FTAM have ended up being highly baroque and being "all things to all men" and have succeeded in being nothing to anyone.
It is also apparent that OSI protocols have taken a long time to produce and in the mean time SNA, DECNET, and TCP/IP protocols have advanced. It is also significant that OSI protocols are useless without functional standards. These are complex and not yet universally accepted.
It should be noted that DEC is migrating part of DECNET to use ISO protocols in DECNET phase 5 although it appears that this is mainly at the lower levels. There is no guarantee that the functional standards used by DEC will match those of others. In fact in the UK the DEC functional standard does not match the JANET one (DEC uses TP4, JANET uses TP0 and X.25 over ethernet). Thus some OSI protocols have a long way to go.
It is significant that IXI will allow any higher level protocols. Not to do this would probably result in it being only used for X.400 and X.29.
The wide imposition of OSI protocols is, in my opinion, now regarded as in-feasible. Manufacturers have been reluctant to implement protocols, the results of their efforts are poor but the development of DECNET, SNA, and TCP/IP had been good.
It is obvious that COSINE has drawn back from a rapid move to OSI high level protocols and has instead concentrated on the provision of X.25 which does have a reasonable degree of acceptance by all manufacturers. This is a good decision since SNA, DECNET, TCP/IP, and X.400 can all operate more or less effectively across such a network.
COSINE has dual loyalties. On the one hand there is a desire to bring together the academic and research community in a single network, a desire to support European PTOs and industry. They have a belief that they know what is best for the community. COSINE appears to be led from a practical point of view by the Commission and the user input seems to be absent.
EARN, more than any other organisation, has suffered under the monopoly of the PTOs. It has been apparent that they have been loathed to give up their monopolistic powers. We have seen the unwillingness to allow EARN to compete in any way with PTO services. We have seen the unreasonable attempts to impose a volume tariff. To quote the proverb - power corrupts, absolute power corrupts absolutely. Absolute corruption has only been avoided by the welcome liberalisation.
The monopolistic service provided, and being provided, by the PTOs is atrocious. Why do international leased lines take so long to obtain? Why are international services so expensive? Why is the international X.25 unbelievably bad and expensive?
I would maintain that monopoly is bad and reduces services to the lowest denominator. Competition is good and forces suppliers to provide a good service of face extinction.
Unfortunately the track record of directed development is poor, the track record of monopoly is poor, and the track record of OSI development is poor. I cannot see that any of these factors will change.
Unfortunately the strategy of COSINE is not only to provide a monopoly but also a monopoly in conjunction with the PTOs. The PTO monopolies have been a disgrace within Europe with restrictive practices and punitive tariffs. It is clear from the emerging COSINE network that it is seen as a corner of the PTOs network. It will be easy for it connect effectively with other PTO run networks such as SURFNET and DFN. It will be difficult for non PTO networks such as JANET and EARN to connect. This appears to be the PTOs re-asserting their traditional monopoly with the help of the Commission. This is surprising when you remember that the Commission is expected to foster competition and de-regulation. It would appear that the COSINE network has been little influenced by the COSINE report and more by the PTOs perception of what is required. Why should the community exchange the inappropriate monopoly of the PTOs for a seemingly inappropriate monopoly of the PTOs.
So where does this leave EARN? is is no secret that many want to see EARN disappear as it poses competition or a threat to COSINE. EARN has been popular and left to its own devised would become even more popular as it provides services now to the end user rather than some promise of services of some rather unspecified form in the future.
It has become clear that the opponents of EARN want to see EARN concentrate on high level services. It is also becoming clear that this is restricted to IBM protocols and that EARN should not take initiatives in X.400 or X.500. Thus the future of EARN in this scenario would be to migrate its mail services to X.400 under the control of the appropriate authorities and this would no doubt include migrating LISTSERV type activities in the same way. Thus EARN ends up looking after NJE.
EARN has no guarantee that COSINE/IXI will succeed any more than MDNS, there is no guarantee it will provide the quality of service EARN requires, the long term finances of IXI are unknown.
EARN's primary mission is to provide international communications services to the community.
EARN will provide services at the highest quality and at the lowest cost.
EARN will co-operate with other international and national organisations in order to provide an enhanced service.
EARN will use any appropriate communication technologies.
EARN will not use any particular bearer services but will use those which provide the service required by the users.
EARN will continue to encourage the attachment by direct or indirect means to its services from appropriate institutes and countries.
EARN expects to be one of several organisations providing communications services to the community.
Dear John,
You will recall that at our recent meeting in Amsterdam we discussed the possibility of an X.75 connection between EARN and IXI which we believed was the most effective way of connecting the two networks together. We were led to believe that this would not be possible unless we were to obtain a registered DNIC.
We have been talking to OFTEL in the UK (and other administrations) on obtaining a DNIC and we have now received the attached letter. This suggests that OFTEL would allocate a DNIC as long as there was a requirement to connect to another network offering X.75. As IXI is the only network we are currently negotiating to connect with in this way we require a letter from IXI to confirm that should EARN be allocated a DNIC then IXI would be prepared to allow such a connection.
This is clearly an exciting opportunity for us which we would like to take advantage of. Fortunately we are still in the position where we can change our number plan without any major problems. However, should this be possible then we should like to proceed as quickly as possible to minimise disruption and to be able to make a connection as early as possible to IXI.
May I therefore ask you to give this opportunity your urgent consideration and I look forward to a fruitful co-operation with IXI.
I attach the letter from OFTEL.
I have briefed Niall O'Reilly, who will hopefully be at the WG4 meeting in Portugal, and I hope you will be able to discuss the connection with him. Regretfully I will not be able to attended.
With best wishes,
Paul Bryant. EARN Secretary General.
Dear Miss Seaton,
Thank you for your second reminder that we have not paid your invoice. Regrettable I do not seem to have received the first one.
I raised the necessary paper work on receipt of your invoice on October 5. On receiving your reminder I checked and find that regrettably you are correct and that my bill paying department has not yet seen fit to send you the payment. I find this quite unacceptable and have asked them to pay as soon as possible.
I can only apologise for the inconvenience we have caused you.
Yours sincerely
Paul Bryant.
Dear John,
Many thanks for the meeting report that you intend to present to the IXI Project Team.
I also produced a report that I presented to the EARN Executive and I attach a copy. It seems to say much the same as yours. I am happy.
It is unclear from either of our reports whether direct G-box connections are wanted or allowed. In fact we have asked our members to consider whether they wish to take part in the IXI test and if so how they would envisage connecting. It may be appropriate to reconsider the exact method of connection when we have had the results of our request.
I do have a copy of the Northern Telecom document concerning their "Gateway X.25" facility which, with NT's consent, could be made available. I am not sure that this would further the project at thus stage.
I note that you consider that the routing of traffic over IXI or EARN will require further study. This make me happy as I was under the impressing that this was only an outside possibility.
Yours sincerely
Paul Bryant.
Progress on most projects has been hampered by the difficulty of replacing staff lost over a year ago. Recently VAX staff have been recruited and now a LAN and a PC specialist are expected. In the VAX subgroup little more than essential work has been possible but this will now change. The lack of a local area network expert has again reduced any forward planning activities although considerable progress has been made with TCP/IP, Pink Book, and MOS. The staff on mail faced many difficulties with VM/XA and radical changes in a new version of the MAILER but good progress is now being made. The name look up facilities will soon be available and efficiency improvements next year. The mail distribution facilities have been in use for some time with few problems. The addition of administrative support for the PC and VAX work has been of enormous help. This year has again been frustrating with the under-staffing but quite a bit of progress has been made and we enter next year in far better shape staff-wise.
Dear John,
Thank you for your letter of November 28, 1989.
I have spoken to JANET and they are not interested in obtaining a DNIC. Thus this may be discounted.
Oftel is the regulatory authority for DNICs in the UK and not the TOs. Oftel are willing to issue DNICs on the basis of need. Thus a DNIC will be issued to EARN if a connection to IXI (or other network) is allowed. The UK TOs are not in a position to object. The issuing of a DNIC does not seem to require a TO to allow a connection from EARN. However, DNICs are a scarce resource and OFTEL do not wish to issue them unless there is a demonstrable need.
I do have a licence from Oftel which allows me to operate EARN. I attach a copy for your examination.
We are very happy with an initial connection in Amsterdam as we agreed at our recent meeting. Oftel are aware of this decision and are not concerned that the DNIC is needed to connect to a foreign network
I do not expect to speak to Oftel again unless there are some specific question you wish me to raise. The next stage is to inform them that we have permission to connect to IXI with X.75 and thus to allow the allocation of the DNIC.
I will, of course, be pleased to discuss the "X.25 Optional Facilities" with yourself and WG-4.
Yours sincerely
Paul Bryant.
It is expected that the X.400 mail system will take the place of Grey Book mail. It is proposed that Rutherford should start to prepare for this change. It is proposed that at this stage preparations should be made to test various products and to gain expertise.
The transition to use X.400 is inevitable and the only question is "when?". With a universally acceptable mail standard we would expect far better quality products from manufacturers and far better support. As most organisations in this and other countries who are interested in mail will use it there will be better interconnection possibilities.
X.400 is an electronic mail system promoted by CCITT and ISO. It is expected to take the place of the JNT Grey Book mail, RFC822 mail, and others. It should lead to a single mail standard for the academic world as well as the TOs (Telecommunications Operators) and others.
JNT has been supporting various moves to introduce X.400 although progress has been rather slow. There have been various versions of the protocol usually designated by the CCITT year of publication. There have been pilot projects in particular EAN which is used at many sites within Europe and elsewhere. There is a gateway produced by UCL between Grey Book and X.400. Current wisdom suggests that the community should adopt the CCITT 1988 version.
As is usual with these matters the X.400 standard is more complex than the systems it aims to replace. It has a companion standard, X.500, which provides a directory service which is thought to be essential.
Clearly Rutherford will have to follow X.400 at some time. The problem is when. Regretfully Rutherford has few resources to allow it to be a leader. If a project is started too early then there will be a lack of suitable products and a lack of other systems and sites to communicate with. If a project is started too late then the site will be unable to take advantage of the benefits at an early date.
This paper suggests that during 1990 suitable products and a reasonable community of correspondents will exist for Rutherford to take some action. It suggests that a service could be provided in 1991.
Products will be required for:
The IBM 3090 - this should include products for use with PROFs as well as for the non-PROFs community. IBM Screen Mail will be investigated.
VAX - Clearly with VAX being a popular machine on site they are an essential component.
IBM PC - there are many who prefer to use their PCs for mail purposes although this is a new departure with a lower priority.
UNIX systems - here we need to co-operate with Informatics Department.
A project group should be set up consisting of representatives from each type of machine and a few others. A suggested list is:
Co-ordination- Roger Westlake
IBM- Peter Girard and Dave Parker (for PROFs)
VAX- Mike Waters
IBM PC- Graham Robinson
Support- Phil Overy
UNIX- Informatics
Others may be needed from time to time.
The first task is to have a close look at the products now becoming available. A detailed programme will be established which will contain, amongst other things in time order:
Considerable development in the functional standards has already taken place within the community and these should be followed.
No rigid time scale is proposed but rather that the pace should be dictated by the availability of products, their quality, and the pace of change outside Rutherford. No service dates should be quoted until there is a certainty that they can be met.
An optimistic outline time scale which is speculative is:
First half 1990 - Education
Information collection
Development of detailed testing proposals
Second Half 1990 - Possible purchase of IBM and VAX products
Testing of products.
Study of X.500 directory services and products.
Study of possible Grey Book to X.400 gateways
Study of replacing MAILER, LISTSERV and directory
services
Study of mail for workstations
Development of detailed X.400 strategy
First half 1991 - Possible purchase of systems for all possible
machines and testing
Purchase of a gateway
Purchase or development of EARN X.400 gateway
Detailed testing with many sites.
Second half 1991 - Introduction of services.
Throughout the period there will be an increasing involvement with the JNT and other X.400 activities.
There will be a review at the end of each calendar 6 months.
During the first half of 1990 most of the work will be the collection of information and various studies which by its nature will modest effort by several people. Say one man month in all.
The second half of 1990 will involve testing which will require more concentrated effort which will have to be scheduled into the various work programs. It is expected that testing will be suspended if problems requiring manufacturer involvement are encountered rather than any aggressive development plan. In addition if things look encouraging more detailed planning will take place. Say three man months.
The first half of 1991 will be the most intensive period with a lot of detailed planning and testing. Say one man year. At this stage there should be one person dedicated to the project.
The second half of 1991 will also see a high level of activity with involvement from support staff. There will be some savings from the lower level of support of current services. From the development point of view a man year is suggested but with the greater involvement of many others in the Department and the reduction in effort on current services it is difficult to give a figure.
The exact costs of the software and hardware required have not been studied. As fully supported manufacturer products are expected these are likely to be more expensive than current systems although there will no doubt be scope for discounts and deals.
Dear Alain,
Herewith my claim for expenses for the last Exec meeting.
Air travel 194.60 UKL
Train to CIRCE 35 FF
Hotel 325 FF
Total of FF 360 FF @9.29 38.75 UKL
Total 233.35 UKL
Yours sincerely
Paul Bryant.
This is an agreed reply for Central Computing Division at Rutherford Appleton Laboratory, UK.
TCP/IP is now used between the IBM3090, IBM PCs, and UNIX machines over a site wide ethernet. TCP/IP connections have been established between Daresbury Laboratory and Imperial College London via bridges. Experiments are about to take place of TCP/IP across X.25/JANET using CISCO and Spider routers. Discussion are taking place to interconnect Rutherford, University of London Computing Centre, and Manchester Regional Computing Centre principally for access to super computers. These links will probably use routers. Discussions are taking place with University College Dublin and HEP (for a CERN link).
Rutherford Laboratory believe that TCP/IP and associated protocols are essential for the development of certain types of access, in particular X-Windows. Currently there seems no immediate prospect of these services being provided by other protocol stacks. Having established a TCP/IP infrastructure it is being utilised for other purposes which can be provided by other means but are more convenient via TCP/IP because they utilise the site ethernet and have been shown to be robust and easy to mount and use.
Rutherford is concerned over the proliferation of access methods on the site and would wish to concentrate on a narrow set of protocols which fulfil all the requirements. This does not appear to be currently possible and as an interim strategy support is being given to those protocols which are finding favour with our community. TCP/IP is within this support.
Rutherford believe that co-ordination of TCP/IP across Europe is essential if the highest quality service is to be provided at the lowest cost. The address structures, topology, use of various bearer services, traffic analysis, costs, management are a subset of topics which need to be addressed. Rutherford welcomes the initiative of the RIPE group and will support its activities.