Paul Bryant's Networking Correspondence
The proposal was considered at the EARN Technical Group Meeting in Lisbon on 30 November and 1 December 1987. The proposal was approved with amendments. This is the amended version.
The EARN Executive is invited to approve the proposal.
The way in which EARN nodes are operated is to a great extent dictated by the site at which it is located. This has led to difficulties in attempting to provide some defined level of service and in furthering some projects.
It is proposed to define EARN 'mandatory directives' and EARN 'recommendations'. These mandatory directives and recommendations will apply to 'categories' of nodes. These mandatory directives and recommendations will be issued by the EARN executive or the EARN Board of Directors as required to ensure the effective and efficient operation of EARN and its development.
All nodes fall into one of the categories listed below.
International nodes are nodes connected to one or more nodes in other countries.
Transit nodes are nodes which are connected to more than one node and are not international nodes.
End nodes are connected to only one other node and are not international nodes.
Mandatory directives shall be implemented by relevant nodes.
Recommendations are expected to be implemented by relevant nodes.
Only the EARN Executive or EARN Board of Directors shall issue mandatory directives and recommendations. However they will be often suggested and prepared by the EARN technical group.
Mandatory directives and recommendations will be publicised in the Board of Directors distribution list and there will be a period of 14 days for objections to be registered. In general it is expected that all necessary agreements will have been obtained before they are issued. Objections shall nullify a mandatory directive or recommendation directive until resolved.
A few examples of typical mandatory directives and recommendations are given.
A mandatory directive to undertake certain international topology changes could be applied to international nodes. A mandatory directive to update routing tables within 10 days could be applied to international and transit nodes.
A recommendation to operate mail systems conforming to RFC822 could be applied to all nodes.
A recommendation to provide the mail id POSTMAST could be applied to all nodes.
Dear Chris,
I was very pleased to learn from the recent BT/RAL meeting that you were interested in providing the EARN X.25 infrastructure.
The development of the infrastructure project is now progressing very fast with a number of EARN meetings in early February. I therefore look forward to an early meeting with BTI to explore the possibilities.
I enclose a document which tries to define what we are looking for. originally the document only talked about a network with switches provided by the community and I have now 'hacked' it to include a provision from an outside organisation. This has made it a rather messy document. I would point out that the document is not yet approved by EARN but none the less is fairly near what we think we require. Thus, the fine detail is open to negotiation. I hope the document is helpful.
I look forward to you contacting me to arrange a date when I can visit you in London.
With best wishes
Paul Bryant.
Present: P Bryant, P Thomson, M Reid, J Gordon, R Brandwood
Any use of the EARN line which departs from policy must be agreed with P Bryant.
Any use of the HEP line which departs from policy must be agreed with P Jeffreys (HEP).
All traffic between the UK and the CERN site must use the HEP line except as detailed below.
Traffic between Ireland and the CERN site may use the HEP line.
The HEP NJE link is now operational and carries the CERNVM and GEN traffic.
J Gordon will draw up a list of NJE addresses which must use the HEP line.
M Reid will liaise with C Jones, O Martin, B Antoni, and D Foster to negotiate the required changes in the NJE tables on the various CERN machines.
For technical reasons the GEN traffic will be returned to the EARN line for an interim period. Action M Reid. The MAILER will be investigated with a view to directing GEN traffic via CEARN via the HEP line. Action P Bryant. GEN traffic will be directed via the HEP line when a technical solution to mail is determined.
The target date for achieving the objectives is the end of February.
The first stage will be to collect information. The next meeting will be on 12 February at 9am.
Information will be collected as follows:
Auscom - A Jesset will talk to N Gunadhi and investigate the use of the Dexspan board in an Auscom, the use of the Auscom as an SNA device emulating an IBM 3274 1A, and any other appropriate Auscom/KMC developments.
8232 - P Girard will look at documents to hand and if necessary approach IBM for more information.
DACU - G Robinson will investigate.
VME - C Osland, much information already to hand.
VAX with Auscom boards - M Waters.
CERN - M Waters is visiting CERN and will find out what they are doing.
IBM Series/1 - P Girard will see what is happening at Liverpool and Manchester.
Fibronics/Sparticus - A Jesset will see what Informatics and the company can deliver.
Interlink - What is it? P Bryant will try and find out.
IBM plans and 9370 - P bryant will ask IBM.
Daresbury - C Osland will investigate.
EARN - P Bryant will ask EARNTECH for information.
Remember we are interested in Pink Book, TCP/IP, and DECNET.
For each option the following information is required:
Description of hardware, support, and maintenance. Description of software, support, and maintenance Performance. Price. Developments required. Availability, when was equipment first available, how much longer is it expected to be available. Community, how many other systems are there in the field, how many are the UK, and how many in the community. Commentary. This will be a summary of the groups opinion of the system.
TMPC considered NTMPC/2/88.
TMPC has agreed the recommendations with some changes. The recommendations are now:
Unless there are objections I would like to assume that NTMPC agrees with the arrangements for the production of their report which follow the lines agreed in NTMPC/3/87. If their are any objections I will bring this paper to the next meeting of NTMPC.
K Benn and G W Robinson have been co-opted onto the group drafting the NTMPC's report.
Please see NTMPC/3/87 and TMPC/18/87 (attached) for details of layout and for last quarters paper.
The report should cover November 1987, December 1987, and January 1988. On this occasion please do not cover material before November but rather make reference to TMPC/18/87.
The sections on future requirements should be expanded to include speculative material, guesses, and ideas. These should be clearly indicated as such. Examples- it would be legitimate in section 1 to speculate that all communication on the IBM would be via VTAM from some date in the future and that developments should have this end in mind- the VAX section could contain comments on 'hacking' and that effort will have to be directed to solving this problem- the site LAN section may note that the AUSCOM is unsupported and that a full service cannot be contemplated until a well supported interface is in place.
Attached is the comments on the paper by TMPC which should be taken into consideration.
On producing your material please follow section 1 of NTMPC/7/87 as this will make editing easier.
Please send your contributions to PEB@UK.AC.RL.IB.
Pending objections may I ask for contributions by 23 February so that I produce a draft for our meeting on 1 March for submission to TMPC on 14 March.
The contributors will be the same as last time:
1 NETWORKING ON THE IBM EXCLUDING EARN (P Girard) 2 TELECOMMS OPERATIONAL SERVICES (R Brandwood) 3 TERMINALS AND DATA SUB-SECTION (P Gill) 4 INSTALLATIONS AND SPECIAL INVESTIGATIONS (B Day 5 VAX COMMUNICATIONS SUPPORT (S Weston) 6 EARN (P Bryant) 7 HYPERCHANNEL (M Waters) 8 IBM PC (G W Robinson) 9 SITE WIDE ETHERNET (G W Robinson) 10 USER SUPPORT (P Overy) 11 PIXNET (K Benn).
As agreed at the last Technical Meeting the next Technical Meeting will be on 14/15 April 1988 in Turkey.
Bookings should be made with Sitki Aytac BILSAY@TREARN by 15 March.
May I remind delegates that they should have the approval of their Board of Directors member to attend.
We have a problem as to when to start. Looking at the timetables, it looks to be impossible to travel in the morning to start the meeting at mid day. I would like to get in at least 1.5 days of meeting. I realise that as there is EARN88 and the BOD meeting it would inconvenient to extend the meeting backwards as delegates will want to be away from home for as short a period as possible. The options are:
Travel Wednesday and start Thursday morning. I would envisage ending Friday evening as most people will no doubt be staying for EARN88 (true?). This gives us two full days and a week end to enjoy.
Travel Thursday and start Friday. I do not think we can get through the meeting in one day so we could continue on Saturday and end when we end. This will minimise the time away from home.
Your opinions please.
The agenda will be approved at the Executive meeting on 8 March. Could I have agenda items as soon as possible. Items I think we should include are:
Reconsideration of domains paper as a result of the Task Group.
Reconsideration of statistics collection and the results of the Task Group. Will we be in a position to reconsider topology?
I hope that the proposal on ERFC papers will be approved and we need to decide whether existing documents should be catalogued in this series.
We should review the working of the operations group.
Migration is being dealt with by other groups but we should consider any actions we need to take.
This note is being sent to EARNTECH and EARN-BOD.
Paul Bryant.
As you requested I attach the budget and FYFL for transition.
1988 1989 1990 1991 1992
EXPENDITURE
4 switches at
22000 88000
Maintenance assume
1 year warranty 0 4400 8800 8800 8800
64K line UK/CH 53000 106000 106000 106000 106000
64K line UK/NL 45000 90000 90000 90000 90000
64K line NL/FR 45500 91000 91000 91000 91000
64K line FR/CH 52500 105000 105000 105000 105000
Manpower to set up
and run network 1M 15000 30000 30000 30000 30000
Travel & subsistence 10000 10000 5000
INCOME
Donations 309000 436400
Membership fees 435800 430800 430800
Note- The transition is estimated to start in the middle of 1988 and hence the costs will be about half the costs in 1989.
Note- Donations are expected to support the transition for 1.5 years.
Note- Transition is expected to absorb more travel and subsistence in the first years.
Note- No provision has been made for further 64K lines.
This NTMPC quarterly progress report was approved on 8 march by NTMPC.
During 1987 a number of general trends can be seen and it is appropriate to note these and develop a strategy taking them into account:
The conclusions to be drawn are that the philosophy of networking on the site is changing and the Department must adapt to it. The department is being dragged in many directions by its customers and there should be a small number of well supported access methods to reduce pressure on staff.
1.1.1 JTMP Host-end Service
Unreliability problems have continued with the existing SPCP (Release 2.1) software. An advance copy of Release 3 was received from Salford before Christmas. The work of preparing this for use in the RAL environment has been completed by Tim Kidd. Installation of the new version is imminent and, after some inevitable teething troubles, will hopefully prove to be more reliable.
1.1.2 NIFTP
Only minor changes have been made, apart from putting into service the completed version of the JTMP user interface. This has status/modify support implemented by Tim Kidd. No major problems have been reported with NIFTP, except possibly a tendency to build up large queues at week-ends. This causes overheads and takes time to clear (sometimes several hundred files are on the reader). These build-ups seem to consist largely of mail files sent from EARN, addressed to sites which are closed at week-ends.
1.1.3 SSMP
There has been no change. There is still no immediate prospect of receiving a better version from Edinburgh.
1.1.4 Pink Book
Pink book is not a service. In practice it only carries terminal traffic at present. A final version of the MAC-level software is expected from ULCC. This is a prerequisite for making some throughput and efficiency measurements.
1.1.5 CMS-PAD
No problems reported with Version 1.5.
1.1.6 VTAM
There has been an unproductive and utterly frustrating period until the last week of January. This was due to a succession of problems with the IBM supplied hardware and software:-
(1) There was the wrong type of cable between 3705 and PSE.
(2) The channel adapter was wrongly plugged (IBM believed wrongly that there was no optional plugging in the 3705).
(3) There was a crippling bug in VTAM. This was introduced on the PUT tape that came with the product.
Diagnosis of these problems involved studying VTAM and NCP traces and dumps in finer and finer detail. Without access to the source code for either product, this was a very slow process.
Progress has since been good, but obviously the original timescale has slipped.
1.1.7 Network Connections
There have been no changes. Three 38K links are still in use. The 4705 has been reliable.
1.1.8 Routine Maintenance
VMNCP, MVSNCP, NIFTP, CMS-PAD, 4705 software, and Coloured Books at CERN are currently consuming little effort.
Work is in progress to change the NRS-table generation software to use the latest Salford format (DERFIL2). The current format is obsolescent and does not support the partial domain entries needed for the EARN mail gateway.
1.2.1 JTMP Host-end A reliable host-end service should emerge based on Network/VM Version 3.
1.2.2 NIFTP
Some enhancements are likely to be undertaken. These will probably including the support of restart facilities at least for large outgoing files. Tim Kidd is looking at this.
1.2.3 SSMP
The expected new version from Edinburgh will hopefully materialise. The offer from Andrew Mitchell at Reading University to get it working in our environment still stands.
1.2.4 VTAM
It should be possible to demonstrate the Coloured Books working over VTAM/NCP/NPSI via 3705. This will be evaluated. A version for the 4705 will be generated and tested. This will need EP to be added to the NCP/NPSI software.
1.2.5 CP Mod Removal
A study will be undertaken of how to replace the CP mods for network line-mode terminal support by a method that does not require CP mods. Probable solution would involve using SNA CCS in some way.
No specific future requirements have been identified, except the need to move toward ISO protocols in due course.
This report includes activities on the JPSE as well as the local telecoms equipment.
2.1.1 Local
Again the main area of concern is the Camtec PADS, over 40 incidents were report during the period. Two units were returned to Camtec with PSU problems, twelve were resolved with a restart, ten required board or chip changes, seven were user problems, the others were a variety of individual faults. A considerable amount of time was expended trying to understand the inconsistent behaviour of Tandons over Focom muxs. Four faulty Mux channels boards were returned to Focom for repair during the period.
PACX was upgraded to a PACX 2000 at the beginning of January. Only minor problems were experienced in the first few days.
The X.25 exchanges were reliable only one hardware fault at the end of January causing 4 interruptions to service and a downtime of approximately 80 mins. However they were all over a weekend. There were no new connections made during the period. Two systems have now closed down RL.GK and RL.PD.
2.1.2 JANET
Throughout last year the JPSE was plagued with an intermittent hardware fault that caused an Auto-IPL, on average, once a week. GEC ran numerous test and changed a considerable number of boards. The problems disappeared at the end of October when a cable was changed and reappeared when the cable was reinstalled- the cable has now been removed and the problem has not reoccurred.
The JPSE has also been upgraded with a DMA controller to support MCC and KCC's boards. MCC are in use with the 256K links to UMRCC and Daresbury, the ULCC link is waiting to be made operational. KCCs X.21 links are sysgened into the system and test are being made to the Swindon Telepac.
The table below shows the statistics for the period for the CPSEs and JPSEs
CPSE CPSE2 JPSE
Nov Dec Jan Nov Dec Jan Nov Dec Jan
Downtime .06 .34 1.17 .03 0 0 .06 2.08 .46
Scheduled 0 0 0 .03 0 0 .06 1.56 .23
Unscheduled .06 .34 1.17 .00 0 0 .00 .12 .23
Interruptions 2 1 4 1 0 0 2 7 2
Scheduled 0 0 0 0 0 0 0 3 1
Unscheduled 2 1 4 0 0 0 0 4 1
MTBF Hrs 360 744 186 720 - - - 186 372
Availability 99.99 99.92 99.82 99.99 100 100 99.99 99.71 99.89
(percentage)
Ave Daily Traf 171 130 145 58 46 45 335 291 325
(Mbytes)
Trend. The number of incidents, if anything, is slightly reduced. The traffic level, on the local exchanges, seem to be fairly consistent. On the JANET side, there is a reduction on the number of department machines connected and analogue lines as rationalisation takes place. The traffic level is slowly increasing.
Further investigation into BSC/HDLC converter problems with the intention of changing Imperial College Physics Dept IBM over and hopefully moving RL.IC and RL.ID onto HDLC as well. The latter two do not depend on the BSC/HDLC converter. No progress was made on this during the last period.
Move to GEC Type 3 software on the CPSEs, this will keep CPSEs in line with the JPSEs. Installation of GEC Type 3 software on the RAL CPSEs.
Installation and testing of X.21 link between 4705 and JPSE. If satisfactory then purchase and installation of equipment to run both 4705/JPSE links on X.21 at 64K.
No other changes except those mentioned in Telecoms Installation and special investigations are envisaged.
Nothing new identified during this period.
During this quarter 166 faults were reported to the terminal sub- section. 80 were repaired by sub-section staff and the remaining 86 by contracted maintenance agencies.
The distribution of agency repairs is as follows:
DPCE 1 Contract for Tally line-printers
MSM 32 Movable terminals
KODE 40 Non-movable terminals
SIGMEX 12 Sigmex terminals only
CIFER 1 Warranty & Specialist repairs
The 166 faults have been further analysed for divisional distribution.
______________________________________________________________
| | REPAIR AGENCY | |
|Division|____________________________________________| |
|-Project| TCOM | DPCE | MSM | KODE | SIGMEX | CIFER | TOTALS |
|________|______|______|______|______|________|_______|________|
| ADM | 5 | | 2 | | | | 7 |
| AG | 4 | | | 1 | | | 5 |
| BNSC | 5 | | | 2 | | | 7 |
| CCD | 22 | 1 | 5 | 6 | 3 | | 37 |
| EBW | 3 | | | | | | 3 |
| ECF | 5 | | 3 | 12 | 3 | | 23 |
| HEP | 7 | | 5 | 1 | | | 13 |
| ID | 9 | | 4 | | | | 13 |
| INS | 4 | | 1 | | | | 5 |
| ISIS | 3 | | | 2 | | 1 | 6 |
| LASER | | | 4 | | 1 | | 5 |
| SL | 2 | | 2 | 11 | 3 | | 18 |
| TEC | 11 | | 6 | 5 | 2 | | 24 |
|________|______|______|______|______|________|_______|________|
| TOTALS | 80 | 1 | 32 | 40 | 12 | 1 | 166 |
|________|______|______|______|______|________|_______|________|
When the ECF "terminal-give-away" programme reaches its conclusion on 31st March 1988, there will be a further reduction of terminals that are maintained by SERC for the ECF project. The present level is about 300 and is expected to fall to around 100 by April.
It seems highly desirable for the whole laboratory, that the present operation for terminal maintenance be an infrastructure complemented function. In support of this, the table above showing divisional break -down is given. Currently, CCD has set up and administers maintenance contracts with the agencies shown and additionally with a "carrier", Lynx.
The steps involved with each fault are:
1. Fault reported to Service Line
2. Incident Report (IR) raised
3. Unit checked, directly if on-site, by telephone if off-site
If movable unit
4. Replaced by a spare
5. Removed and transported to Atlas
6. Repair attempted at Atlas
7. If not possible, taken to agent's workshop on Harwell site
8. Collected and reinstalled when repaired
If non-movable unit
9. Agent is called in to repair it
10. IR is updated throughout fault history
11. Cost of repair monitored; preset limits before any work is done
12. Bills processed; checked for satisfactory completion, no double
billing, overcharging etc.
13. Bill passed for authorisation by user
14. Repair details entered on database
15. Turn-round and cost statistics for each agency produced.
It is extremely inefficient if each division has to arrange contracts and carry out all the above functions themselves. It is strongly recommended that TMPC makes a case for CCD to be given complement under infrastructure to continue this operation.
More offices were cabled for Full Screen Terminals and various users had their connections changed between PACX, PADs and DECservers.
The ethernet backbone fibres were installed and terminated, and all village bridges were installed. DECservers and a DELNI were installed for BNSC in R25. A DEMPR ( thin ether repeater ) was installed for Technology in R25. A DECserver was installed in R68 for a Technology Conference and then relocated in R25. The A&G village ether was relocated in R25.
The wiring of the main Console and Service Line desks was completed.
A fibre optic link for IBM 3044 channel extenders was installed and terminated between Atlas and R1.
PACX was upgraded to a PACX 2000.
The Grapevine equipment was relocated in R1 Lab 11 communications. room.
Optical multiplexors to support V24/V28/RS232 connections have been installed in R2 and R5.5.
A coaxial link to Harwell contracts and another to MRC have been commissioned. Tests were carried out to confirm that two terminals could operate on the line to Harwell contracts.
Data links have been installed between R1 and R3 for a Linotronic typesetter.
Cables were installed in the SERC offices in Great Portland Street for Full Screen Terminals. A Kilostream line has been ordered for GPS.
As Focom multiplexors will not support all Category A devices, evaluations of other multiplexors have been carried out.
A fibre optic link will be installed between R1 Lab 8 and the HEP control room R5.1.
Thin ethernet will be installed in R20 for Technology.
A thin ether link will be installed in Atlas to allow monitoring of the site ether backbone.
Hopefully Harwell will complete the wiring to MRC to provide an X.25 link.
Multicore coaxial cable will be installed to R1, R25, R65 and R2 to aid fault diagnosis and provide connections for Full Screen multiplexors.
Some new multiplexors will be installed on site to support Full Screen devices.
None known.
5.1.1 Software being run
UK.AC.RL.VE is now running PSI V4.1 (released in November). CBS V4.2-4 is still being run to test LLC2. LLC2 will be purchased.
5.1.2 Support
With the release of PSI V4.1 advice and help has been given on the installation of the software. Once the software has been installed there appear to be very few problems with it.
The other support areas, PSI, CBS, Red Book, LAVC, PSS/IPSS, VMS-COMMS, EARN, and JANET continue to be covered. NRS updates continue to be produced.
The RAL DECnet has moved to area 19, some assistance has been given to other managers using DECNET at RAL. The original meetings which discussed the move to area 19 was supported. A manual 'RAL DECNET- A System Manager's Guide' has been produced to aid the managers. Representation on the LAN Management Committee has continued.
The Central network Support Contract has been progressed. The bill has been received for 1988 and is due to be paid soon.
5.1.3 Hacking
Considerable effort has been put into investigating hacking attempts. Serious hacking attempts have occurred highlighting a deficiency in the CBS code. A fix was produced to overcome the deficiency for CBS V4-2.4. This code was "field tested" on UK.AC.RL.VE before being released to the community. Unfortunately the release of the code came too late for some sites who have already been hacked. Effort has been spent in liaising with DEC on behalf of the SERC sites. The problem has been raised with DEC Country Support resulting in them visiting two SERC sites to examine the hacked systems. Attempts are underway to find a solution to the problems. There is now an increased awareness of security within the VAX community. The group have been contacted often to help to pin-point security loopholes and to provide programs for prevention (monitoring incoming X.29 calls and how to bar calls from certain DTEs or whole countries).
5.1.4 GIFT
Work has continued rather slowly on the CBS Blue Book slots. A new GIFT P end service has been announced at CERN. Some time has been spent producing VMS HELP and documentation for this service. A GIFT meeting in Amsterdam highlighted that there are still a number of deficiencies that need to be corrected in the current code. These corrections need to be made before the DECNET to Blue GIFT software can be considered a full service.
ISODE V3.0 has now arrived. It has been installed on UK.AC.RL.VE. Work is underway to install it on VMS but the first impression seems to be that this will not be an easy task. It is believed that a lot of work will need to be done to alter the code so that it will run.
A CBS V4.3 field test is due to start in February. DEC have confirmed that RAL will be a field test site for the software. The software is expected fairly soon. The field test would last for at least six weeks so the software should be released to the community late April/ beginning of May.
Efforts are being made to obtain Wollongong's version of TCP/IP to evaluate on a trial basis on UK.AC.RL.VO.
6.1.1 NJE
There have been serious congestion problems in Montpellier. EARN is considering a second transatlantic line terminating in CERN. There are still worries over the use of an MVS system at that site.
It is proving more difficult than expected to move the HEP traffic from the EARN to the HEP line. There is little doubt that the need to make this change is absorbing a lot of effort and is counter productive to the efficient running of the links.
6.1.2 File transfer between EARN and JANET
There have been no changes.
6.1.3 MAIL
A new version of the MAILER from Crosswell was mounted. It corrected a single bug. A table change in the domains table caused a loop. To some extent this was self inflicted as the table change was at the UK's request.
Investigations of LISTSERV have shown that it can be used for mail distribution within JANET and EARN.
NTMPC considered the future of mail and the EARN gateway and produced a set of recommendations which were accepted by TMPC these are about to be implemented as specified below.
A new version of the mailer is almost ready. This has greatly improved handling of addresses and far less mail will be rejected. Confusion over domain ordering is the most frequent reason for mail failure and the greatest reason for support requests.
It is intended to direct all incoming mail via the MAILER. This is to allow the distribution lists to be used and also the name translation facilities. It will remove the confusion between UK.AC.RL.EARN and UK.AC.RL.IB.
A few trial distribution lists will be set up.
The changes to the re-routing of traffic between the EARN and HEP line should be completed.
M Reid is now well advanced with the production of better accounting mechanisms based on the use of SAS. This will be run on the data already collected.
Further work will be desirable to improve the efficiency of the MAILER. The estimate is that its running cost could be reduced to 1/5 by combining the two mailers, using hash tables, and other less important changes.
No changes in functionality are expected.
The move to ISO is still slipping at real time but a lot of talking is in progress.
During November NSC spent a large amount of time trying to discover why the VAX saw errors on the hyperchannel with the A400 time-out switch set to 7 but not when it was set to 9. This is supposed to be a port contention switch for multiple devices on the A400. With only one device connected it is not obvious why this had such a serious effect.
After a lot of deliberation NSC diagnosed the fault as the Cray being slow in indicating it wanted to send data and subsequently sending it. Without a convenient diagnostics tool (none exists) it was difficult to understand this. At this point we left the switch set to 9 and contacted Cray at Bracknell to see if they had the same problem.
It is felt at that point that the basic hyperchannel was being reliable enough to risk the connection of the Sun.
The Informatics Sun 3/160 was subsequently connected to the A400. The IKON card required some hardware modification to fit. It appears that the mechanical specification of VME is not a standard! The Cray station software was then successfully installed and connected to the Cray.
At this point the VAX started reporting errors at about the rate of 1 per thousand I/Os as apposed to none at all. The errors would cause the occasional complete break between the VAX and the Cray. By stopping and starting the Sun station it became obvious that the SUN was having an adverse affect on the VAX.
Inconclusive tests were performed with the VM connection via hyperchannel. This appeared to cause the VAX to "log off" from the Cray under a heavy load from VM, but as this did not appear to cause the same level of errors it may well not be anything to do with the current problem.
It now again looked to be a hyperchannel error. However, during January, Cray release a new version of the VAX Cray station being, version 3.06. This had the ability to recover from the errors seen without being "logged off" the Cray. This was put up on the VAX and although errors still occurred when the Sun is connected it appears not to cause the VAX to be "logged off".
While the situation is now stable, it is not unreasonable to expect further problems when the second SUN and IRIS are connect. Some further investigations are required, with hopefully Cray and NSC in attendance.
Further investigation into problems.
Possible connection of the CCD Sun and IRIS.
None.
PC emulation of IBM 3270 communications across site has been a major drain on resources with considerable efforts being required to identify the cause of the problems. It appears that Focom took timing liberties with the IBM 3278 specification in designing their multiplexors and the IBM 3270 emulator card for the PC is just on the edge. Production variations meant that some PC cards worked reliably whilst others gave intermittent failures. Eventually IBM solved the problem by producing a card for the PS/2 model 50 which would not work across the Focoms at all thus forcing a change of multiplexer supplier. There now appears to be no problems.
Beta test versions of BICC's Pink Book software for XXX (line mode only) and FTP have been successfully tried to IBM and VAX machines. The main problems revolve around the ability of the BICC card to concurrently support many protocols. A new version to fix this is expected shortly.
Development of a new version of the MOS Network 3270 emulator continues at a very slow pace due to other demands. The asynchronous driver for this has been written to an IBM sponsored Network Services interface in order to assess its worth.
Development of a PC based Console Monitor program (S J L Addams) for X.25 Exchanges continues and testing is planned to start in February.
An investigation into the working of the IBM 3270 communications and especially file transfer has been carried out by a student. The interface has been documented and may be used as a basis for a file transfer system in the MOS Network 3270 emulator. Utilities to initiate commands on the IBM mainframe from the PC have been written for the PROFS team.
When new Pink Book code from BICC arrives a pilot service on PCs can be started. This may be run alongside an evaluation of an MS-NET shared filestore.
Until staff are released from the management of the ethernet backbone there will be minimal progress on PC networking
A F Jessett is the Backbone Lan Manager. Managers for the villages have been nominated. They, other specialists, and interested parties comprise the Lan Management Committee under the chairmanship of G W Robinson.
The original six villages have now grown to eight. Starlink is now separate from A & G and EBL will separate from PPD (nee HEP) when its bridge arrives. The backbone is now installed and a trial service has commenced.
Early problems, during the first few days of use, highlighted the need to have guidelines on the introduction of new equipment and software on a village since any malfunction can affect other villages. Guidelines are being developed and will be evaluated during the trial service. Guidelines on user support mechanisms have also been agreed.
Problems in the use of Decnet over the backbone have been partially resolved. Discussions with CERN should lead to a wider coverage of this service.
All services offered by villages across the backbone are on a trial basis and will continue to be so until the backbone is declared a production service and handed over to the Computer Services Division. This is not expected until the Autumn.
Work is in hand to set up traffic monitoring at the bridges and also the backbone. Remote bridge initialisation and control is being done from RL.VO. All bridges filter out broadcasts except where TCP/IP protocols are required to cross the backbone.
A F Jessett is now looking after the Auscoms and a spare is being assembled and tested. At the end of the year N Gunadhi fixed software problems that had been discovered since his departure. The IBM Pink Book service is now reliable.
Spider (under pressure from JNT) finally got round to updating the software in the two RAL PADs. They then stopped working, as had ULCC's the day previously. The main problem was due to the software not reinitialising the network tables because it did not recognise that an old version had previously been in use. When this was cured the PAD was able to make calls. Bugs in the new software prevented calls to entries in its tables with a Call User Data Field. This stopping full screen access to the IBM. Subsequently the company has confirmed several other bugs in the new software and an amended version is expected shortly. Since their present flurry of activity appears to be motivated by the chance of orders it seems prudent not to buy a PAD until we are satisfied that they work properly. Spider's claim to support terminals up to 38.4Kbaud has been found to be true though what this reduces to on a fully loaded PAD remains to be seen.
The next few months will be a period of experimentation on the backbone as different services are tried across it. In particular the IBM and VAX VMS systems should commence trial Pink Book services. There will no doubt be problems with the increased traffic and usage.
An evaluation of an X.25 gateway (currently at ULCC) should commence.
A replacement for N Gunadhi is required as a matter of urgency.
ISIS has expressed an interest in connecting to the backbone at some time in the future
As the backbone becomes stable the way will be open for some traffic to migrate from the X.25 service. When the backbone gains an X.25 gateway then significant reduction in the RAL site X.25 traffic should be apparent. If the backbone proves a success then no further X.25 PADs should be required since those on the ethernet give much better performance.
The operators can now prevent foreign mail from causing long mailer stops. Some mail is being passed onto JANET and upsetting systems there, since both lax and strict sites exist on JANET and the former would object to more address policing: The better ARPA-BITNET gateway reliability is a mixed blessing because of this problem. EARN has been asked to mail back object files - which then bring down the requesters' mail systems; Peter Girard and Tim Kidd's FTP monitoring allows us to stop retries even where the affected sites can't reject them properly.
A new name 'EARN-RELAY' is available as an option; since rl.earn is seen as '%uk.ac.rl@rl.earn' by faulty mail using US order, this may reduce problems on the machine 'uk.ac.rl'. The new name also resembles the JNT EAN gateway long name 'EAN-RELAY' in format, making the network appear more standardised.
Its longest range user, Ted Chance at Pennsylvania, is now using the ULCC Cray successfully via the EARN gateway. Montpellier are still backing up files and sending them out later, owing to delays; it would be advisable for list subscribers to decide to fetch one copy of large files so that it can be passed around the network from a central site such as the Kermit centre in Lancs.
Pink book and SSMP over Pink Book work well through a Spider PAD and N.Gunadhi's experimental system; Network 3270 works better to the IBM but has the drawback that other makes of computer use different protocols. The Spider PAD and Cifer T2000 terminal will work reliably at 19200 baud, giving a very good response.
JTMP was backed out during the month; no Cray users lost data, but some were confused by this.
EARN has embarked on a policy of only ISO two-letter network names; Ireland is called 'IE'. The ISO names were half-registered at first, but a correction came through the next day. VNET interruptions were fixed at CUNY or on the IBM side - apparently IBM's VNET was cut off from BITNET after the XMAS EXEC virus caused hundreds of RSCS messages to be sent to users' terminals and a copy to be forwarded to each of the victim's NAMES entries.
Two US universities have asked us for IDs on the EARN gateway and contact information so that they can maintain contact while in London; they particularly value messaging contact.
The Rutherford Cray has at least one (English) user on Bitnet, in Wisconsin.
Translation table problems can be overcome by some encoding programs for VMS; this is reassuring on two counts - firstly we can make longer-range 'binary' transfers - secondly it shows that the JANET translation tables are not the only ones to have caused this problem.
Return of dead letters is sometimes not possible, but sending back tests and digests helps the most irritated users - most of the failures are because the senders simply haven't got mail working yet!.
Mick Reid has set up NAMEFIND using the EARN user support names - this is a help if you need to find a postmaster but takes up a lot of space. EARN documentation at other sites is very out of date, but there seems to be more support than during last year.
Conforming with standards is a continuing chore. Many JANET contact problems eventually turn out to be due to implementation errors at one end or the other, and the same is true for EARN, so diagnosing FTP or addressing errors takes up perhaps half a day per month.
Some sites are on BITNET and not on ARPA, but have ARPA-style names; these can reply through us but not via ucl.cs.nss so some people have been sending through us and UCL until helped. Liaison with other gateways is vital as there is no single network with world-wide contact, however more US networks now use X25 and there is even an EAN gateway in the USA. Contact with CSNET and European networks such as SUNET is now more reliable and user support of smaller networks has improved dramatically; CSNET's relay now sends via X25 and SUNET etc have joined EAN.
An account on other networks is also useful; the EARN and EAN gateways have noticeably better documentation and access to documentation than UCL and UKC. BT's hostess service is improving and so is contact with UK.CO commercial sites.
It is hoped to route incoming mail for the Rutherford site through the mailer, making services like NETSERV and LISTSERV available from our normal address rather than the gateway name 'RL.EARN/EARN-RELAY'. NETSERV is EARN official help and LISTSERV runs distribution lists. Since the present mailer causes a tortuous route back for automatic replies, its behaviour must be modified before incoming mail can be redirected.
IBM mail management facilities are not as good as those at present in use on 'UK.AC.RL'. Improvements would be welcome and better information on contact with the USA is always appreciated. Better liaison with other gateways is also appreciated and the EAN gateway is much more informative than most.
I hope to attend a conference on X400 developments. New Zealand and Australia are at present trying to establish an X400 service over their 'SPEARNET' network and BT has introduced a commercial X400 package and service.
Both PIXnet and PIXnet XL links have been operating almost trouble-free in the period. Their user population has increased steadily and now almost all the potential users to whom the system was originally presented for evaluation, are connected: ie approximately 90 attached devices (terminals or printers).
The incidents were:
21 September: XL system inoperable. Cause: Megastream line adapter at
Swindon found to be in
'loop mode'. Reset.
14 October: Some Swindon addresses Cause: Swindon operators attached
not working. an extra 3274 controller
without updating software.
04 January: Unable to power-up Cause: Tape cassette in RAL LCU
after RAL power fail. stuck. Ok when freed.
Applications switching software for the XL system is still expected: Paradyne expect to deliver it in April 1988. Possible alternative solutions are being sought in case they default.
The service is popular and generally very well received. The user base at Swindon continues its steady growth.
Having now thought more carefully about the proposal to use NJE over ISO session a number of questions and comments come to mind.
1 Now, NJE (traditional) stages files through the network. There is no doubt that this could be preserved with NJE over ISO. In this case NJE would only have to know the SSAP (probably same as NSAP?) associated with the adjacent nodes. The NSAP addressing in this case could be a bilateral agreement with the adjacent nodes. The alternative is for NJE to know the NSAP of all nodes accessible directly. This would be much more efficient. If this is to be done then the allocation and registration of NSAPs become a problem. In principle this should be part of an overall NSAP scheme. Now NSAP registration schemes are not yet under study. From experience of the UK (Name Registration scheme) such schemes are VERY difficult. Also witness the current facilities in NETSERV for NODE control. A half way scheme would be to try to use the current NETSERV facilities with some upgrade just to deal with NJE/SESSION. This would probably be the best scheme but an interim one.
2 A minor question. I assume that on an IBM machine NJE/SESSION would be implemented by means of a new driver for NJE which would have access to a table of NODE names against NSAPs? Is this the idea.
4 Another minor question. I assume, unlike NJE/SNA SESSION, NJE/SESSION will use SVCs? If this is not the case I am very worried as a problem with SNA is the way it needs lots of PVCs. Also, is a call made only when there is traffic? If this is not the case I am also worried as large numbers of SVCs open for long periods can be a problem.
5 Could you say why NJE is being put over Session and not Network? The reason I ask is because some time ago we (JANET) had a long discussion as to whether we should put XXX over Network or Session. We concluded that Network should be used as the extra facilities of Session could not be used. What are your arguments one way or the other?
6 Considering the nature of RSCS V2 and if we want to use SVCs directly between the end points (where possible) we are likely to be having many nodes wanting to make simultaneous calls to a popular node. This would suggest that the NJE would have to 'back off' if it cannot make a call and try a call to some other site. I have the feeling that RSCS does not have this facility and do not know if a driver could do this. Have you any comments?
We have had some discussions on the DTE addresses and this subject is well understood and relatively easy. NSAP addresses are not. I think we need to put effort into two questions:
1. What NSAP scheme do we use? Perugia has some comments which need further development. NSAP addresses are VERY important and if we get it wrong we are in dead trouble.
2. We will need to have a scheme for allocating and registering NSAPs and a way of distributing this information to machines. From the UK experiance with such a scheme in JANET this is not simple.
While in my bath I suddenly realised why the PTT international packet switched services are poor in terms of throughput and reliability.
The PTTs connect their networks together by bilateral agreements between countries. Thus the interface between each pair is 'special' (BTI confirm this) thus there are 20 'fircles' in the BTI switch - one for each country.
We, on the other hand, are intending a managed international overlay. Thus each country will have a standard interface to outside and thus less to go wrong. In addition, the overlay management will be in a good position to increase capacity where it is needed.
This would seem to support my view that we must construct the network on performance and finance considerations and not national aspirations or where X.25 expertise rests. Expertise is needed at the management centre which can be anywhere.
Paul.
This paper is based on the "estimates" and "forward look" papers in TMPC/P19/87.
Page 5 amendments to Table COS 1(e).
+----------------------------------+----------------------------------+ | | | | Function | DMY | | | | +----------------------------------+----------------------------------+ | | | | ........... | | | | | | Local Area Network Development | 2.75 (Andy, Gunadhi*, | | | 0.5 Graham, 0.25 Paul) | | Personal Computers | 2.75 (David, 0.5 Graham, | | | 0.25 Paul, A N Other) | | International Network Access | 1.5 (Tony*, 0.5 Paul) | | Graphics | 2 | | Development | 9 | | | | | ............ | | | | | | VAX/VMS System Support | 4 (Mike, Sue, Peter, | | | A N Other) | | | | | | * = vacancies | +----------------------------------+----------------------------------+
Notes:
1 There is an attempt to be fairly accurate in the figures which has resulted in allocations down to 0.25.
2 There is a bid down of .25 on the "Local Area Network Development" which is caused by my time being allocated between the three lines (excluding graphics).
3 There is a bid up of .75 in "Personal Computers" which in fact is a bid up of one after taking account of .5 of Graham's time going to the "Local Area Network Development" and .25 of my time going into "Personal Computers". The PC group is now under severe pressure with 130 machines on site and a current purchase rate of two per week.
4 It is assumed that Sarah Addams will continue to be on loan from Operations. She undertakes special projects mainly on behalf of JNT and these would cease if she was withdrawn.
5 The apparent bid up of .5 on "International Network access" is my time being reallocated from the "Local Area Network" line.
6 The "Local Area Network" line does not take account of resources used in Telecoms for laying cables or of eventual operation of the network. This should be allowed for in OH 5.1(a) "Site Data Communication". I suggest Doug allows at lease .5.
7 "International Network Access" does not take account of support (Phil Overy). This should also probably be under OH but I can see no suitable line.
8 "International Network Access" does not take account of the support of RSCS (Mick Reid). I estimate it takes something under 0.5 and should reduce. This will need looking at by Doug and should probably be under the telecommunications support in COS 1(e).
9 "International Network Access" does not take account of operator and telecommunications effort. This is between 0 and 0.25 and should be taken account of by Doug, I guess under OH.
10 I am concerned that the true cost of EARN cannot be seen in any single figure thus hiding the cost.
11 "VAX/VMS System Support" is a bid up of one based on recent discussions on the support of GIFT. There is also an increasing load on the VAX support staff as a result of the larger number of machines and the introduction of new network products (Pink Book in particular).
Table COS 1(c).
I suggest we include a line for a "Second Generation Local Area Network". Estimates are that the currently developing backbone will last for 5 years. I suggest a token 50K is included in 1993/94. I suggest manpower of 1 in 1992/93 and 1993/94 to develop it. In reality this will be the job of current "Local Area Network Development" compliment and this line is to defend their continued existence.
1 Minutes of meeting held 9 September 1987
2 Funding progress
3 SERC - IBM contract
4 Gateway changes
5 Accounting progress
6 Transition, Neil Dunlop will attend for this item
The toner cartridges in desk top laser printers made by Canon and Hewlett Packard cost around 75 UKL.
A number of companies now advertise a service for refilling cartridges at 50 UKL. Refilling kits are available at 99 UKL for the first two and 18 UKL thereafter.
As an experiment six cartridges were refilled by Mega Media. A refill kit was purchased from Innovation Ltd..
This had scratches on the drum. It is unknown whether these were present before the cartridge was refilled. The company replaced it. The replacement cartridge, when expected, was filthy being covered in paper dust. It was cleaned but toner rapidly built up on the drum causing dirty copies.
These cartridges also built up toner and produced dirty copy.
The secretaries manager decided not to use the cartridge on the grounds of the reported dirty copies. He also claimed that there was a report that refilled cartridges emitted greater quantities of ozone and constituted a health hazard. This claim is unsubstantiated. It is difficult to understand why a refilled cartridge should emit any more ozone than a new one. With the high voltages used the production of ozone would not be surprising but the quantities should be minute. The cartridge is in use on another printer and is satisfactory so far.
No report of any problems.
Not tested.
One of the cartridges which produced dirty copies was disassembled and inspected. No faults could be found in the mechanism. The dust box did show a unusually large build up of toner which is a result of the dirty drum rather than the cause. The drum itself was changed but the copy was still dirty. The belief is now that the toner is at fault. There is insufficient information to assess this quality but there has been suggestions that the water content can be important.
The kit consists of a manual of 14 paged, two jars of toner, replacement pads, and a special tool for removing a screw.
After a bit of practice the disassembly job is easy. It is also messy in that the 'dust box' has to be emptied and toner gets everywhere if a good job is to be done. A small vacuum cleaner would be an advantage. Cleaning the rest of the assembly is easy. Filling is also easy and requires only the removal of a plug and pouring in the toner. Re-assembly is equally easy. The total time to do 'a good job' is 30 minutes. With practice and a production line this could easily be reduced to 15 minutes.
The refilled cartridges worked perfectly.
Cartridges can be refilled with success. The company used to refill cartridges did not do a satisfactory job.
Thus, it would appear that if we are to use refilled cartridges we would have to undertake the job ourselves or find a reliable operator.
The cost saving would be about 60 UKL a cartridge but a new supply of cartridges would be needed as old ones wore out. It is reported that a cartridge can be refilled up to 5 or 6 times. The rate of consumption is not known but in 3 months my office has accumulated 20 which indicates a saving of about 5000 UKL per year.
1. Statement of EUNET requirements
2. Statement of EARN current facilities and migration strategy.
3. Discussion of GB/NL pilot proposal for a 64K line.
Consideration of X.25 document PB33
Develop request for tender to switch suppliers. Select set of possible suppliers. Including NT and IBM.
Develop request for tender to network suppliers. Select set of possible suppliers. Including Dutch and UK PTTs
Confirm the use of NJE/SNA/X.25 as the way of supporting existing services.
Decide how to refine the proposal for the use of NJE.
Consider use of VAX computers for gateways.
A list or required gateways is required.
A list of possible products is required including GIFT and the Grey Book X.400 relay.
Decide questions for Geneva group.
The EARN Technical Group in Lisbon agreed to recommend the setting up of a series of papers to be called "EARN Request For Comment" ERFC papers. At the EARN Executive meeting on 10 February it was decided to consider the proposal by mail. The Executive is asked to comment and to use the voting procedures to approve the proposal.
It is proposed to set up a series of "EARN Request For Comment" papers. They will be developed as "Draft ERFCs" by the various committees until adopted by the EARN BOD or Executive.
ERFCs would cover a wide variety of topics including:
The EARN administration (Joe Chester) should maintain the register of ERFC documents. ERFCs would be held in NETSERV.
The Central Computing Department of the Rutherford Appleton Laboratory operates a gateway between the UK academic network JANET, and the European Academic Research Network EARN. The Department has developed IBM programs for implementing the gateway for file transfer and mail. A support service is provided for users. Support is provided for the management and development of the whole EARN network.
The gateway is providing a vital service to the UK and international academic community.
EARN currently uses IBM proprietary protocols. It is about to migrate to use the modern protocols of ISO. The Department is intending to take an active part in this migration.
Gateways to other networks are being considered, for example to the Space and Astrophysics Network SPAN.
The purpose of the post is:
The main duties are:
Applicants for this post should have a strong interest in communications. Initially the post will require a knowledge of IBM assembly code in which the gateway system is written. Skill in setting up communications systems provided by manufacturers will have to be developed but the nature of these are not yet known.
A broad knowledge of IBM and ISO communications methods is needed or will have to be developed.
Good writing and human communication abilities are needed. Foreign languages would be useful but not essential.
Doug House has passed me your memo of 16 February on the purchase of PCs.
First let me correct the statements made by users.
"they wish to choose their own PCs (e.g. Mackintoshes in HEP)"
Reply- The purpose of the rule is NOT is prevent a free choice of PCs. The purpose is to ensure that the PC group can proffer their advice which may or may not be accepted. The object of this is to ensure that the group can point out any possible foolish purchases. For example, a user may buy a PC in order to access the IBM and find that when purchase it may not be capable of supporting the software or hardware. In addition if a user purchase a machine for a purpose and this is agreed with the group then the group has a duty to sort out any problems. If he buys against or without the groups advice and it does not perform according to their wishes then they can expect NO advice or help.
"the IBM PC standard is dead"
Reply - There are 130 PCs on site and orders (known) are running at two per week. True the standard is developing and the group tracks these changes.
"a Department Head's signature....."
Reply - I am not competent to comment.
"no-one obeys these rules anyway"
Reply - The group has a stream of advice seekers beyond that which it can cope with. In general the visitors value the advice received and the group has prevented many foolish purchases. Some may not obey the rules and there is no idea how large that group is. I believe that those wishing to purchase Mackintoshes to not in general approach us and in any case the advice we would give them would be that we could not help them.
I hope this clarifies the situation from the PC groups perspective. I believe the rules work well as long as we do not operate them oppressivly.
The gateway between EARN and JANET has been updated.
NO USER ACTION IS REQUIRED.
The system now makes better efforts to deliver mail which has mistakes in the headers. The effect is that fewer mail files will be returned or lost. A Via: field is longer stamped on mail.
Please report any unexpected differences or difficulties.
In future all incoming mail from JANET will pass through the "mail service".
The purpose of the change is prepare for moving some mail services from the GEC to the IBM computer. This requires the mail service to intercept all mail in case it is for a distribution list.
NO USER ACTION IS REQUIRED.
For technical reasons NOTE will add mail to notebooks according to the content of the To: field rather than the file name. EARN mail will now be treated in the same way. It is hopped that this will not cause problems.
A visible change will be that mail will be stamped with a Received: field. A less visible change will be that mail in the reader will appear to come from the user EMAILDEV.
Please report any problems or observations to PO2@UK.AC.RL.IB
Present: P Bryant, N Dunlop, M Reid, B Robinson, I Smith
Apologies: P Overy
Approved
Brian Robinson will be replaced by Neil Dunlop (Academic Marketing IBM).
EARN has decided that the UK would not be allowed to have double representation on the EARN BOD. Currently the UK Directorship and Deputy is shared between Paul Bryant and Mike Wells.
The corporate membership of EARN by JANET is still being progressed.
The Computing Department was now allowed to recruit and there in an intention to recruit someone to undertake the technical tasks associated with the gateway.
The line costs have been met by JNT since the beginning of the calendar year.
Finance is now being raised is accordance with use. As expected, HEP have elected only to support traffic not emanating or terminating in CERN.
Funding is taking account of the loss of IBM support next year.
EARN is currently considering their finance for calendar year 1989. This is expected to be agreed at the APRIL BOD meeting.
Phil Overy is spending about 85% of his time on EARN matters. It is difficult to differentiate between JANET and EARN matters. Most problems are with remote gateways.
Paul Bryant presented some changes that were expected in the near future:
In the long term effort is needed to make the gateway more efficient as it is consuming considerable amounts of computer time.
SAS is now being used to analyse the accounting records. This development is not yet complete.
The nature of DEC support for transition is not yet determined. A series of meetings are being held to develop a project plan.