Paul Bryant's Networking Correspondence
Over the last year or so the MAC computer has become increasingly popular as it provides many high quality services which are not available or of a lesser quality on other equipment. The purpose of the attached questionnaire is to determine whether a MAC support service is wanted on the Rutherford site.
For several years Central Computing Department has been providing a support service for the IBM personal computer and its clones. Some 300 customers are supported. The services provided are:
This service is provided on request and Departments provide Central Computing with 1/10 of a complement place per 10 machines if support is required.
The MAC computer is significantly different from the PC as the hardware tends to be from a single manufacturer and has less variety. The software, although of a high quality, tends to be less diverse. As with the IBM PC there is a need for network connections for access to the IBM and VAX computers. This is an area where Computing Department has been very active.
It is envisaged that any service would be along the same lines as the PC support. In particular it would be optional. It may be possible to add the MAC and PC numbers for complement purposes.
To assist us in evaluating the need for a service I would be grateful if you could spare a few moments to complete the attached questionnaire.
Please contact me if you require any further information on ext. 5267.
MAC SUPPORT QUESTIONNAIRE
1. Name:
+------------------------------------------------------------------+
| |
| |
+------------------------------------------------------------------+
2. How many MAC computers of what type are there in your department?
+------------------------------------------------------------------+
| Number | Type |
+------------------------------------------------------------------|
| | |
| | |
| | |
+------------------------------------------------------------------+
3. What are your maintenance and support arrangements?
+------------------------------------------------------------------+
| |
| |
| |
+------------------------------------------------------------------+
4. What are the principle uses?
+------------------------------------------------------------------+
| |
| |
| |
+------------------------------------------------------------------+
5. If a support service similar to the PC one were offered would you be likely to subscribe?
+------------------------------------------------------------------+
| |
+------------------------------------------------------------------+
6. Have you any further comments?
+------------------------------------------------------------------+
| |
| |
| |
| |
+------------------------------------------------------------------+
Please return in the envelope provided to:
Paul Bryant, MAC Support Survey, Room 9, R30, Computing Department.
Dear John,
Please could you let me know how the application for an EARN to IXI X.75 connection is progressing. I am sure you will appreciate that once we have an agreement to proceed then we have quite a lot of work in obtaining the DNIC from OFTEL and the re-vamping of our address scheme. I would like to proceed with this as soon as possible so that we can make the connection to IXI at the earliest date.
I hope you had an enjoyable Christmas break. I had a very nice New Year present in that my line between the Rutherford and CERN NT switches became active and progress is now a lot better.
I am sorry I did not manage to get to the last WG4 meeting, I will try and do better in future.
With best wishes,
Paul Bryant.
This is the third look at PACX taken from statistics of January 17. The last look was on July 26, 1988 and the first one was on July 24 1989.
Number of connections at each speed:
+--------+--------+--------+--------+
| Speed |88 Calls|89 Calls|90 Calls|
+--------+--------+--------+--------+
| 300 | 3 | 0 | 0 |
| 1200 | 23 | 7 | 5 |
| 2400 | 12 | 3 | 0 |
| 4800 | 479 | 281 | 140 |
| 9600 | 64 | 165 | 102 |
| 19200 | 2 | 20 | 0 |
+--------+--------+--------+--------+
| Total | 583 | 476 | 247 |
+--------+--------+--------+--------+
Calls were made from 56 terminal ports as opposed to 71 in 89. There are a total of 768 ports with 198 for computer ports and the rest for terminals.
The number of calls made from terminals is categorised below. The 1989 figure is in brackets.
Number of ports number of calls 19 (20) 1 8 (8) 2 6 (3) 3 3 (10) 4 6 (2) 5 2 (2) 6 2 (2) 7 1 (1) 8 4 (2) 9 0 (5) 10 1 (1) 11 0 (1) 12 0 (4) 13 1 (3) 15 1 (2) 17 0 (1) 18 0 (1) 19 1 (0) 28 0 (1) 35 0 (1) 48
Number of connections made in each hour:
+----------+--------+--------+--------+
|Start time|88Number|89Number|90Number|
+----------+--------+--------+--------+
| 00.00 | 0 | 0 | 0 |
| 01.00 | 0 | 1 | 0 |
| 02.00 | 1 | 2 | 1 |
| 03.00 | 0 | 0 | 0 |
| 04.00 | 0 | 0 | 0 |
| 05.00 | 1 | 12 | 1 |
| 06.00 | 0 | 0 | 0 |
| 07.00 | 10 | 3 | 2 |
| 08.00 | 82 | 47 | 31 |
| 09.00 | 69 | 47 | 32 |
| 10.00 | 50 | 41 | 34 |
| 11.00 | 50 | 55 | 28 |
| 12.00 | 32 | 13 | 16 |
| 13.00 | 44 | 38 | 15 |
| 14.00 | 42 | 41 | 31 |
| 15.00 | 85 | 93 | 23 |
| 16.00 | 62 | 51 | 25 |
| 17.00 | 19 | 24 | 7 |
| 18.00 | 11 | 0 | 2 |
| 19.00 | 14 | 5 | 1 |
| 20.00 | 9 | 1 | 0 |
| 21.00 | 0 | 1 | 1 |
| 22.00 | 3 | 0 | 0 |
| 23.00 | 1 | 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/90
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/ 7 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/21 * * * * 12
33 RAL OS9 * * * 1
35 RAL EBLF Vax 11/750 * * * 1
40 DECSERVER on ETHERNET 1/ 1/ 8 * * * * * 3
44 RAL Prime 2655 (H) 15/ 5/ 1 * * * * 8
50 RAL Camtec Pad (M) & (O) 187/312/168 * * * * 32
55 RAL R1 I.D VAX 8750 (D) 1/ / * * * 10
60 RAL CCD VAX 11/750 (E) 7/ 1/ 5 * * * * 2
61 RAL Starlink Vax 11/780 11/ 3/ 5 * * * * 6
62 RAL R25 PDP / 1/ 1 1
67 RAL GEC 4090 (B) 24/17/15 * * * * 4
65 IRIS 4/ / * * * * 1
70 RAL Prime 9955 (A) 46/26/ 6 * * * * 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
Total number of ports in use in Jan. 90 158
For comparison the IBM was dealing with 350 incoming and 150 outgoing network calls a day in July 1989.
The January 1990 figures show a sharp drop of 50%. The principle reason is the loss of the PRIMEs. The Spider PAD now shows no use. Over half the calls are to a PAD. There is a 20% drop in the terminal ports being used. There is an increase in access to the DEC SERVER but this is a low level use. There is also some increase in access to the other VAXes. Curiously the ID Pyramid had no calls.
This was the third meeting of RIPE (Reseaux IP Europeens).
RIPE is an ad hoc group which aims to co-ordinate IP across Europe. RIPE has no funds and reports only to itself. The wish of the meeting was that this was the best setup. The chairman of RIPE is Bob Blokzijl who is from NIKHEF and well known in CERN networking circles. He is aided by Daniel Karrenberg who looks after EUNET. The group is open and although in general people tend to represent IP networks in countries anyone who is supportive of IP international networking would be welcome. The people attending were a mixture of IP experts and those responsible for network management. All their meetings and documents are open.
Most work is done by mail. There is a list for those with a general interest of about 100 and another list for those attending meetings and being more active of about 25.
This meetings attracted about 20 or so people.
The Nordic countries, Germany, Holland, CERN, Italy, France, and Switzerland are all participants in an existing network. See the map.
The first item was RIPE and RARE status report. As IP is not ISO there has been some friction between RIPE and RARE. Brian Carpenter was asked by RARE to advise them. He has now reported and recommended that RARE should encourage RIPE. See report. This report was broadly supported by RIPE. It will be discussed by the RARE COA (Council of Administration, one representative per country) next week. It is clear that RARE has reached a difficult point. Several members are "hard line" in supporting only ISO. Others are "liberal" - particularly the Nordic members. My view is that they will accept the recommendations. The view of RIPE is that they would welcome RARE participation in their activities but would be unwilling to report to RARE. They see this as preferable to operating as a RARE WG with the restrictions that this may impose.
The meeting reviewed the four Task Forces set up at a previous meeting (see the minutes of second meeting).
Task Force one is attempting to map the network and list contact people for each country. The results are maps and tables. There are at lease 12800 hosts in Europe on the network. There are probably at least twice this number on IP networks not connected to the network. They intend to plan future connections.
Task Force two is for network management and operations. It is looking at the use of SNMP (simple network management protocol). Various "tools" for the use of RIPE are being collected. They intend to create centres of excellence.
Task Force three is for the Domain Name Service. This group is looking at exploiting "domain name servers". This needs to be carefully structured if it is to be useful to the users and not expensive in network traffic.
Task Force four is for formal co-ordination, publicity, politics, funds, and so on. There had been a meeting of the CCIRN (organisation looking at the Europe to USA lines) at CERN on December 6 to discuss EASInet (the IBM sponsored supercomputer network) which uses (amongst other protocols) IP. RIPE was not invited but a second meeting was held where RIPE was represented.
There was a detailed presentation on running IP over X.25 which is a project of IETF (a similar group in the USA). This is an important topic for Europe.
The strong impression is that IP is a reality within Europe and it is inevitable that the bits of network will join together. This inevitably demands some co-ordination and management to make the best of the resources. IP is popular since good implementations are available for most academically interesting machines and these are well supported by a vigorous community in the USA. Whether RARE supports or opposes the use of IP the long tern result will still be an IP network. The resources needed exist and are outside the control of RARE or COSINE. IP is popular on many UK sites. The UK does have gateway access for some traffic to the IP networks although this inevitably reduces the quality of service. It is unclear what the demand for full UK IP access to the European (or USA) networks is.
Confidential.
Rutherford has a number of choices:
Do we believe IP will become internationally important for RAL and/or the UK? I would say "yes" as witnessed by the steady growth of IP in RAL and universities.
Do we believe that IP should be carried "native" between the UK and Europe/USA rather than via converting gateways? I would say "yes" as even the good gateways have been shown to reduce communications quality.
Do we believe RAL should take a lead in establishing international IP? I would say "yes". We have good international contacts both human and electronic. We have a reasonable and improving expertise in IP. Other candidates are ULCC (with the US link) and possibly Kent (with the EUNET IP link).
Do we believe that RAL should take a pro-active or a re-active attitude? I would say a pro-active attitude. Although we can only identify one firm request my belief is that there are a large number of minor users. This is a similar situation to EARN where growth followed a knowledge that a service existed. A reactive approach may result in the service being provided elsewhere or not at all.
If a proactive approach is taken then what lines could be used? There are eight possibilities which can be explored. First the new ESA link which terminates at an IP site in Holland, in addition there is a request from space research for an IP connection. Second the HEP CERN line but so far there is no demand from HEP as UK HEP tends to use VAX VMS and DECNET whereas NIKHEF (for example) use UNIX and IP. Third the HEP DESY link where again there is no HEP demand although DESY is a keen IP site represented on RIPE. Fifth is the use of IXI depending on how this develops. Sixth is the use of the EARN X.25 but this could vanish and DEC would have to remove its embargo on IP which is being pursued. Seventh is to obtain an EASInet link as IP is used on the rest of this network, IBM may need some considerable encouragement to fund this link. Eighth is a new line and here there is a funding problem and we should avoid any funding which imposes undesirable restrictions such as those we have seen with the EARN link. One of these must succeed.
What equipment is needed? Very little. Initially the already ordered CISCO router could be used as long as a suitable X.25 connection can be established. This may be a bit messy but I am confident it is possible. It would be advisable to install a "Domain Name Server" (the IP equivalent of the NRS but simpler). This could be put on the IBM initially but a stand alone system (a SUN?) may be desirable at a later date.
What are the staff implications? With the current increase in LAN staff and the high level of IP activity in CCD and ID no additional staff are currently envisaged. Any future increases will depend on the popularity of the service.
What difficulties are envisaged? It would appear that JNT are developing a softer attitude to IP (as with DECNET). Thus we may not be opposed by them. On the other hand they may wish to "take over" the service in the same way as EARN which has caused a lot of political problems.
What liaison is needed? RIPE should be supported as the right body for practical purposes. If the UK IP network grows then a UK co-ordinating group may be needed but this would be premature pending a stable RIPE connection. JNT should certainly be invited to participate and some careful thought is needed. CCD should have the closest possible contact with ID who have great expertise in IP.
The Rt. Hon. D Hurd MP Foreign Secretary The Houses of Parliament Westminster LONDON
Dear Prime Minister,
For some years EARN (the European Academic and Research Network) has had requests to improve academic cooperation by extending our computer network to Eastern Europe. So far, this has not been possible because of COCOM restrictions. In view of the recent dramatic political events in East Europe, I ask for your assistance in removing this restriction of communication.
Education and public research are today international activities. This applies both to multinational scientific projects in fields like high energy physics, space physics and molecular biology and to the day to day academic activities in most universities all over the world. Computers have long ago been incorporated as tools in most academic disciplines, and in recent years computer networks have increasingly been regarded as a prerequisite for modern research and education.
EARN is a computer network for research and Education in Europe, the Middle East and Africa. Started in 1984, EARN now connects more than 500 universities and research institutions in 25 countries, and it has a connection to BITNET which is a similar network in the USA. Every month, about 70.000 university people and researchers use EARN for electronic mail and data transfer to colleagues in EARN countries or America.
Today the applications for joining EARN from East European countries comprise:
USSR - International Centre for Scientific and Technical Information, Moscow - Joint Institute for Nuclear Research, Dubna - Kalinin State University - Program Systems Institute, Pereslavl-Zalessky Hungary - Hungarian Academy of Science, Budapest - Technical University of Budapest Bulgaria - Bulgarian Academy of Science, Sofia - Centre for Informatics and Computing Technology, Sofia Czechoslovakia - University of Brno - Czech Technical University, Praha Poland - University of Warsaw - Polish Academy of Science, Warzaw - Technical University of Lodz - Technical University of Wroclaw
Due to trade restrictions EARN has so far been unable to establish connections to East Europe. From meetings with the US Department of Commerce we have learned that the trade restrictions versus so called COCOM proscribed countries apply to computer networks for two reasons. Firstly, it might be feared that computer networks could facilitate illegal transfer of restricted software or data bases. Secondly, network connections might facilitate illegal access to supercomputers installed in EARN countries or the USA.
To evaluate the significance of these risks it must be understood that the systems connected to EARN are university and research centre computers, i.e. systems dedicated to teaching and research that is ultimately published, in contrast to computers holding classified or commercial data bases. Also, EARN services are only electronic mail and file transfer. No terminal traffic for remote log-in is operated on the international links.
The EARN belief is that protection is best done as close as possible to the resource to be protected, i.e. any supercomputer or data base, not by generally restricting network access. We believe that the extra risk by establishing EARN connections to University and research institutions in East Europe is negligible as compared to the risks existing today, such as using the public networks or removing magnetic tapes.
We therefore urge you to take any actions possible to lift this barrier to free communication within the global research and educational community.
Should you require further information, please do not hesitate to contact me. I enclose a brochure describing EARN which you may find helpful.
Yours sincerely
Frode Greisen - EARN President.
A meeting was held between P Jeffreys, R Brandwood, P Girard, and P Bryant.
Current status 64K split: 19.2K X.25 CERN EXCITE - carries traffic to VAX machines 19.2K X.25 GEC switch - carries Coloured Book traffic to IBM and PADs 9.6K HEP NJE 9.6K EARN NJE 4.8K SNA
Multiplexors are installed which allow flexible splitting of the bandwidth.
Expected status 64K split: xK X.25 xK DECNET xK SNA
The exact split will depend on requirements and will be adjusted as needed.
The removal of the GEC switch is dependent on the removal of X.25/bisynch from the CERN IBM which in turn is dependent on the satisfactory performance of the IBM 3745 at RAL.
All the services could operate over X.25 but at this stage this is thought undesirable as DECNET and SNA would each take one X.25 call and each Blue Book FTP or interactive call would take one call and thus as there is no priority mechanism on the X.25 link the performance of the DECNET and SNA would degrade disproportionally as the number of Blue Book and interactive calls increased.
Current status 14.4K split: 4.8K X.25 4.8K NJE 4.8K PVM
Expected status 19.2K split: 4.8K X.25 4.8K DECNET 9.6K SNA
The reasoning for having three separate channels is similar to that of the CERN link.
There is less flexibility in splitting the bandwidth but there may be some changes in the light of the actual traffic pattern.
Present: J Barlow, B Read, R Brandwood, J Brown, P Bryant, T Daniels, E Dunford, D Giaretta, D R Lepine, C Mutlow, D Terrett, M Waters
A 64K line is now operational from RAL to ESTEC (Noordwljk, Holland).
A 9.6K PSS line is now operational funded by ESIS (Frascati). It is understood that a number of NUIs on various PSS switches have been obtained for "dial up" use.
There is a 9.6K line to BNSC currently dedicated to PROFS and using IBM protocols.
There is a 48K line to RAE Farnborough.
A Hughes X.25 switch is expected with 8 RS232 and 2 RS449 ports there is no delivery date.
No multiplexing equipment or PADs are currently expected although it is understood that such equipment is available "off the shelf" from ESTEC.
The requirements appear to be for the Hughes switch to be connected to PSS, RAE Farnborough 9.6K, BNSC London 9.6K, Kleinwort Benson London 4.8K, BAE Stevenage, BAE Bristol, and Rutherford. The lines to BAE should be provided by BAE and the other ones for which there is authority by RAL.
Action - C Mutlow to check what the BAE sites are doing.
DECNET - this could go from a router at RAL to a router at ESTEC preferably over X.25. This had been agreed with the ESOC SPAN manager. If over X.25 then there may be problems with the switch. If using DDCMP and a portion of the line then multiplexors would be needed.
PROFS - currently PROFS connections are via EARN. This could be by dedicated bandwidth or using X.25 with SNI. With dedicated bandwidth multiplexors would be needed. There would be reluctance to use SNI until the problems with the 3745 had been solved.
Mail to JANET - this could (as now) use the JANET/SPAN gateway.
File transfer from JANET - there is a possibility that the JNT reincarnated GIFT project could be used. In some cases DECNET links are avail# able to JANET sites.
Interactive traffic - there is no need for interactive VAX traffic.
TCP/IP - there is a need for TCP/IP from Rutherford to Norway. This could use the X.25 connection using the CISCO router expected at Rutherford. TCP/IP exists at ESTEC. The need for TCP/IP from other JANET sites is not known but RAL is experimenting with TCP/IP across JANET.
PROFS to RAL- they had not contacted J Brown.
Action - J Brown to contact Colin Phillips (computer manager) to determine the requirement.
Access to other ESA machines - this could be provided by a PAD at RAE sharing the 48K line.
Action - C Mutlow to determine the interactive requirement.
E Dunford will be visiting RAE and will make some enquiries.
Dominic Foster looks after the RAE end of the 48K line.
PROFS - this service exists and is thought to be the only one required.
Other services - if occasional interactive services were needed the PAD facility in the RAL IBM could be used. Alternatively the 9.6K bandwidth could be split and a single terminal or PAD installed depending on the requirement, this would reduce the PROFS performance unless higher (14.4K or 19.2K) bandwidth modems were installed.
R Brandwood will contact Clive Glover of DTI, Jan Anthony of SERC, or K Inglis to clarify the requirement.
PROFS - Stevenage and Bristol are thought to be connected by a 2M connection which carries PROFS and therefore single PROFS connection to Bristol would be sufficient.
Other services - the need for these is unclear.
Any line will be ordered by BAE Stevenage.
Action - R Brandwood will check the PROFS statement and clarify the need for other services when he next speaks to Michael Agnew.
PROFS - there already appears to be a PROFS SNI link to ESTEC which is not via Rutherford. The intention seems to be to consolidate traffic via Rutherford.
Other services - the need for these is unclear.
Any line will be ordered by BAE Stevenage.
Action - J Brown will speak to Paul Chatfield of Bristol and Michael Agnew of Stevenage to confirm the need.
Four services are needed:-
PROFS This may use NJE or SNI/X.25 DECNET This may use DDCMP or X.25 Terminals This will use X.25 PADs TCP/IP This would use X.25
There is concern that as SNI and DECNET/X.25 use a single X.25 call and X.25 has no priority mechanism then if there are a large number of calls carrying other types of traffic the SNI and DECNET traffic will be disadvantaged. There is therefore a case for placing multiplexors on the 64K line in order to guarantee bandwidth to selected services. Multiplexors would also be required if the problems with the 3745 are not solved.
Action - R Brandwood will determine whether ESOC can supply suitable multipexors.
There could be advantages in a connection between the RAL CPSE and the Hughes X.25 switch. This requires a more detailed knowledge of the switch and the details of how ESOC intend to operate it.
Action - R Brandwood to find out details of the Hughes switch and how it will be operated.
As the line is now operational a DECNET connection could be made immediately to ESOC. This will be further investigated in the light of the delivery dates of the Hughes switch and possible multiplexors.
The ROSAT satellite will soon be launched and UK universities will requires resultant data which they would be able to get via DECNET and this encourages the earliest possible DECNET connection to ESOC.
E Dunford will provide a charge code for effort provided by CCD and possibly others.
P Bryant will set up a distribution list (ESANETWP@UK.AC.RL.IB) for use by people attending this meeting in order to report the results of actions and to co-ordinate the activity.
No further meetings have been planned at this stage.
Dear Alain,
I enclose an invoice from British Telecom for the RAL CERN line. This is shown as DP2. The refund and arrears also refer to this line. The total is thus 1990.00 + 707.56 - 136.35 + 384.18(VAT) = 2945.39 pounds.
I have now paid this invoice and request a refund.
Unfortunately the finances of Rutherford are complicated and if you were to make a credit transfer then it is likely that the money would never find its way back into my budget. We also have the problem that on April the fifth all surpluses vanish and all debits get carried forward. To complicate the matter we are to be inflicted with new charge codes which will make a difficult situation impossible. Thus I would appreciate a cheque made payable to RUTHERFORD APPLETON LABORATORY (CREDIT CC65204) and I can then shepherd it though our rabbit warren of a financial system.
I trust this will not cause any problems.
Yours sincerely
I was an ardent supporter of a transition to ISO protocols. I supported and took part in the formation of RARE and the JANET transition strategy development. I no longer believe that an ISO future is possible or desirable or in the interests of the users. Why is this?
Not all ISO protocols have been a failure. The successes have usually been where a de-facto protocol has been standardised or where there has been an organisation with enough pressure to force the use of the protocols. For example:
Note that the parts of the ISO protocols that DECNET phase V will use will become popular with the power of DEC.
On the other hand the ISO failures are:
During the long gestation of ISO the DECNET, SNA, and IP families have been maturing and gaining popularity within the academic community.
It is apparent that groups who decide to develop their own protocols or protocol variants find themselves with relatively poor products with poor support and limited capabilities. For example:
Within EARN we have decided to follow some of these prescriptions for failure:
Where EARN has made correct technical decisions are:
Experience has shown that the lead times EARN requires for forcing developments rather than letting things take their course is long. The initial plans to move to ISO were laid THREE years ago at Perugia. Such delays mean that the world changes and that what would have been a sound plan at that time may no longer be the case as new opportunities arise and old ones become less attractive.
At Perugia the consensus was to provide an SNA over X.25 network. Technically this is still an attractive option since it retains the possibility of embracing DECNET, IP, and X.400 on the same bearer network at a later date.
Politically the provision of X.25 at the Perugia time would have been a sound development. There was no other organisation undertaking such a task and EARN had the capability to start such a migration at low cost using part of the then underused EARN bandwidths and borrowed switches.
We are now three years on and the scene has changed.
The technical decision to use NJE/OSI now seems a dead end development forced on EARN by DEC. There are arguments that this stack moves EARN nearer ISO than the use of SNA over X.25. This is a difficult argument to sustain since the natural break between the low and high level protocol stacks is at about the network level where you can "mix and match" protocols. There seems no such break between an application and presentation. Where the protocol stack breaks is not easy to define but we see IP, SNA, and DECNET over X.25 which is an indication of the popular break points. The use of NJE over ISO neither encourages or discourages the use of the only other currently viable ISO protocol - X.400. It is worth noting that DECNET phase V will use TP4 which is at variance with X.400 and NJE/ISO.
In finding a viable strategy the determining factor is to see what is popular and well supported and back it rather than to predict the future or try and manufacture a future.
So what is popular?
With SNA EARN has a lead in using IBM protocols. This is an option which protects the existing investment.
With DECNET EARN has no experience. HEP and SPAN hold the experience. To attempt to enter this world would probably cause a lot of friction unless it was done in a partnership basis with others.
IP appears to have at last obtained a nucleus network in Europe encouraged by RIPE. As with DECNET, an attempt to take over this world would be met with hostility. On the other hand an exploitation of the protocol in partnership with RIPE would find favour. Leaving aside the exploitation of some of the higher level aspects of IP, EARN could exploit NJE/IP. This has the advantage that the technology is now well developed in the States and EARN would need to concentrate on its exploitation.
The conclusion I draw is that EARNs future is bound up with the triple exploitation of NJE/bisynch, NJE/IP, and SNA together with the interactive possibilities offered by SNA and TN3270. My view is that X.400 is still in the early stages of development which would cause EARN to undertake development before exploitation. EARN has shown itself poorly placed to undertake development.
The carrier systems are a problem. The NT X.25 network would be useful in exploiting both IP and SNA were it not for the DEC embargo. The use of IXI still has a number of uncertainties. The current address structure, management, and willingness to negotiate with EARN give me cause for concern. In addition the long term future both technically, managerially, and financially is another cause for concern.
There are several options open to EARN. My principle concern is that the current option is showing signs of not being a success and if EARN is to survive it must ether find a new strategy or find ways of making the current one work.
In the light of the use of G-BOXes for other EARN related gateway projects Rutherford suggests how the use of the G-BOX may be used in the UK. Commented is invited as to whether such uses would find favour.
The current connection to the Rutherford G-BOX are:
This is used for EARN NJE test traffic.
This was expected to be used for testing to the Irish G-BOX as it is difficult to release dedicated bandwidth on the existing line for a dedicated connection to the NT switch. This connection has temporarily been removed because of lack of ports on the SEEL switch.
This provides DECNET connections to allow local staff to use existing terminals to access the G-BOX for maintenance and for using the NAS account.
This is for NJE traffic between the two machines.
This connection may be re-made ether for traffic to the Irish G-BOX or for IXI testing although this latter use depends on the development of a definitive proposal by EARN for IXI testing. The connection may be re-made to a JANET switch in order to provide better bandwidth for IXI testing.
The SPAN (Space and astrophysics network) community are interested in a SPAN/EARN gateway which could be provided at Rutherford. SPAN use DECNET. This possibility is being investigated technically and no definitive proposal is yet to hand. It is envisaged that PMDF would be the best vehicle for providing such a service. DECNET connections to SPAN would be via the site ethernet which already has SPAN connections. This project should be considered in conjunction with other possible gateways between the two networks in order to maximise the benefits and minimise the effort involved.
Rutherford has a policy of putting as much local traffic as possible on the local ethernet. Thus it would be useful to use NJE/IP between GBGBOX and UKACRL. This required no further hardware but does require the appropriate JNET system in GBGBOX and VMNET in UKACRL. Such a connection would remove any possible bottleneck caused by the 9.6K bi-synch connection.
This would be removed if NJE/IP were to be used.
Dear Mrs. C J Richardson,
Thank you for your letter. It is indeed true that I have not replied to the letter from Mr. Bennett but this is in no way due to a lack of interest on our part but to the negotiations we are engaged in having proved more difficult and slow than anticipated.
As a result of Mr. Bennett's letter I approached the management of the IXI network to which we wish to connect with a request for a confirmation that EARN would be allocated an X.75 port. At that time EARN understood that as a result of previous negotiation a suitable connection would be forthcoming. I still await a response.
We have learned in the last few days that IXI has not allocated EARN a port for reasons of political manoeuvring which I will not bore you with. None the less negotiations continue with high expectations of success.
I can reply to some of the points in Mr. Bennett's letter.
If a DNIC is allocated to us then we have no preference for the first four digits. The letter mentions the fifth digit presumably on the assumption that we share a DNIC. If this is the case I would prefer this digit to be 2 as this fits in with our current number plan and would cause minimum disruption. I can confirm that we have no objection to sharing a DNIC with any other organisation related or otherwise.
I have now concluded discussion with JANET on a joint DNIC and they prefer not to be allocated a DNIC at this stage. Thus sharing a DNIC with them is currently not an option.
The licence I currently operate under was issued by the Department of Trade and Industry and I attach a copy for your records.
We have entered negotiations with SURFNET 2 (the Dutch academic network) and ESA (the European Space Agency network) for X.75 connections. We believe both these networks have DNICS but negotiations are still at an early stage.
Lastly I apologise that this matter is taking for ever to resolve and appreciate your help and interest.
Yours sincerely
Paul Bryant. EARN Secretary General and UK Director.
****************************** * LISTEARN Registration Form * ****************************** ********************************* 1. Information About Your Site: *********************************
Sites which do not currently run LISTEARN or LISTSERV are required to complete this section.
The nodeid of your site:
UKACRL
Is the userid of LISTSERV acceptable for your site (Y/N):
Y
If NO, please enter a userid for the LISTEARN product: ________
Enter the name and the short address of your institution (less than 70 chars):
Computing Division, Rutherford Lab., Chilton, Didcot, OX11 0QZ, UK.
What is the two-letter country code for your country:
GB
What is the name of your system software (VM/SP 5, etc):
VM/XA CP SP release 2 CMS release 5.5
What is the name of your computer system (IBM 4381-21, etc):
IBM 3090-600E
Who shall be the main 'postmaster' or the caretaker of LISTEARN?
(full name) userid@nodeid (phone)
Penny Windebank PAW@UK.AC.RL.IB +44 235446553
If the above person is not available, who can be contacted for emergencies: (full name) userid@nodeid (phone)
Paul Bryant, PEB@UK.AC.RL.IB +44 235445267
Do you wish to become a backbone server, if this is granted to your site. (Becoming a backbone server increases the load on the server considerably, but allows your server to provide more services to the end user) (Y/N):
Y
***********************************
2. Completing the registration form
***********************************
I have read and understood the LISTEARN LICENSE and LISTEARN REGISTER
documents, and declare that I accept the terms stated.
**********************************************************************
Memorandum of understanding between EARN and Rutherford Appleton Laboratory.
It is understood and agreed that this registration refers to a single instance
of LISTSERV also known as LISTEARN which is part of the LISTSERV backbone
and which is maintained by EARN. It does not refer to other instances of
LISTSERV which may co-exist on the same computing system and it does not
alter any existing agreements legal or otherwise under which such systems operate.
**********************************************************************
(Date, Signature)
February 26, 1990 Dr. P Bryant
Head of Communications and Small Systems Group
Central Computing Department
Rutherford Appleton Laboratory
Chilton
Didcot
OX11 0QX
UK
To:
EARN Office
Ege Universitesi Bilgisayar Merkezi
Bornova 35100, Izmir
Turkey
To: Paul Jeffreys R1 2.50 Date: March 6, 1990 From: Paul Bryant Subject: Proposal From CERN
Further to our telephone call I attach a copy of the paper by Olivier Martin on EARN and HEP NJE addresses that was recently considered by the EARN Executive. I believe that this paper has the support of CERN. I also append a copy of the Executive minute on the subject. I would value your comments.
31.8 Proposal to include HEPNet lines in EARN routing tables - EXEC8 90
Resolved - The principle that EARN should manage the HEP NJE tables as part of the EARN NJE tables is acceptable. The Executive welcomes co-operating with organisations wishing to share resources for the common good. However a full consistent international backbone must be maintained and also the principle was proposed that a dedicated EARN connection should be kept by all countries. A proposal is needed to define exactly the details of the suggestions in EXEC8 90. The Executive is concerned at the resultant shared use of lines and the accounting implications. It highlighted the lack of routing facilities in NJE. The details will be examined by staff (Ulrich Giese) and policy proposal will be prepared by ST to the next Executive meeting. Action Stephano Trumpy
Dear Colleague,
I attach the minutes of the recent UK EARN user meeting and an update of recent EARN progress.
I also enclose a copy of the EARN Annual Report for 1988-1989 which I hope you will find interesting.
This year EARN and RARE have combined to hold a joint networking conference in Killarney - Ireland. I have Pleasure in enclosing full details. An updated programme is attached. The agenda covers a wide variety of topics of international interest and there will be something for everyone. I have no doubt that it will be an important event where you will be able to meet your colleagues from other European countries. In addition, Killarney is in a beautiful part of Ireland worthy of a visit quite irrespective of the conference.
I look forward to meeting many of you at the event.
With best wishes,
Paul Bryant - UK EARN Director and EARN Secretary General.
SCIENCE AND ENGINEERING RESEARCH COUNCIL
RUTHERFORD APPLETON LABORATORY
COMPUTING DEPARTMENT
Minutes of the EARN meeting at Imperial College Huxley Building
on Wednesday 15th Nov 1989
issued by
P Overy
March 8, 1990
_______________________________________________________________________
Apologies from:
Sally Justice, South Bank Poly
Ian Dallas, UKC
Those attending:
AA Young Durham Univ
Bob Cooper JNT
Bob Procter Southampton Univ
C.F.Perkins UCL
Chris Roberts RAL
Francois Leveque Imperial College DOC
George Petmezas Daresbury
Gurdev Bal Liverpool
Harry Gluck Imperial College CC
John Gordon Rutherford-Appleton
Mick Kahn London Network Team
Mick Reid RAL
Paul Bryant RAL
Phil Overy RAL
Roger Stratford Cambridge Univ
Roger Westlake RAL
Ros Hallowell RAL
William Craven Sussex Univ
W.A.Ciesla Surrey Univ
The 64k line to CEARN has now been cancelled which was to have been used as part of the EARN X.25 network has been cancelled.
The meeting was asked whether IBM sites would be interested in a conversion of the full-screen ASTRA interface to run over JANET as well as from UKACRL. There appears to be no demand but details of ASTRA can be obtained from P Bryant and an interface can be re-considered if a demand arises.
Paul Bryant presented this paper. The gateway has remained stable and no changes have been made since the last meeting in May. Two LISTSERVs are now running - a JANET side server called LISTRAL saves computer time by not sending files through the gateway unnecessarily. The mail service in general is being redesigned to save resources. A new mailer from PUCC should be working in a month or two, despite needing much alteration to allow interworking with non-BITNET networks.
Since there were few complaints at present, Paul Bryant wondered whether this reflected satisfaction or lack of interest in the service. It was stated that users are in fact satisfied.
The UK payments for EARN are based on GNP rather than use of the network - all UK traffic represents about 6 per cent while Germany exchanges about 18 per cent. None of these statistics include internal traffic (Germany uses EARN as its internal university network). EARN statistics are available (in an untidy form) from LISTSERV@EARN.DEARN.
The Cote D'Ivoire link has been down for much of the year and will there not be paying their full contribution. The UK and West Germany abstained from approving the funding as they needed approval from their funding bodies.
It is still not clear what part EARN will play in the emerging IXI X.25 network. A testing project is being prepared. Nordic countries are using a system of bridged Ethernets for their national network. This runs TCPIP and connect to EARN by G-Boxes (NJE over X25 on a VAX) Germany is now running some E-boxes (NJE over X.25 on an IBM machine) The OSI CWI-Montpellier-CERN main triangle is now linked by X25 and Northern Telecom switches.
There are problems with the coordination of LISTSERVs because of the size of the network and some political problems. These should not cause problems in the UK. Montpellier has improved and there are more links to the USA. EASYNET has offered some links and several countries (Germany, Italy, France, Belgium, Austria and Yugoslavia) would like to use SNA as it provides full-duplex links.
The 9.6k line to CERN was cancelled and has been difficult to get re-opened. Bob Cooper was asked about the line: He stated that we should retain 9.6k access to EARN as cheaply as possible until a new IXI/OSI backbone matures and then move onto the new service.
At the moment no new SNA links are being added as the network then becomes too complex to run (names have to be considered and the SNA system has to be managed)
G-BOX to E-BOX tests have been run for longish periods over public X.25 circuits. The tests are limited by cost. PEB was asked whether the new EARN switches were X25-84. They are, and so can use NSAPs, however G-boxes don't exploit the NSAP facility and X25-84 is in any case backward-compatible with X25-80 so there was no problem in linking such switches to older installations.
The EARN Office has moved to CIRCE in Paris which is a strong EARN site and provides significant support. This is likely to be strengthened with EARN paid staff. The EARN manager, Alain Auroux, is expected to return to IBM and a new one will be recruited. There is one staff member paid by EARN in Turkey who is responsible for LISTSERV. There is one staff member in Neijmegan (Holland) paid by EARN who is responsible for the EARN routing tables.
EARN will continue to run IBM protocols for the forseeable future as there is no X400 off-the-shelf implementation; EARN is a technology follower rather than a pioneer.
Bob Cooper stated that EARN funding requests will go to the computer board the week after the meeting. Computer Board users account for 61 per cent of the 131,000 pounds being requested for 1990. The funding model based on GNP at present used is a great disadvantage to the UK; CERN (one of the heaviest EARN users, based in Switzerland) benefits from its country's low GNP. He predicted that funding will need to change for the year after next.
Mick Reid presented this paper.
Recently the UK EARN link was saturated at about 600,000 records per day. Only full duplex (SNA) would allow more traffic. RAL itself is only 7th heaviest EARN gateway user. At least 250 nodes use the gateway and 24 per cent of traffic goes to users not in the top 100. It is difficult to find a heavy user who could reduce the traffic and LISTSERV makes lists reasonably efficient (although more could be PEERed). The present line is near saturation.
Phil Overy described the strategies used to improve reliability by passing on dead mail, providing fuller help and liaising with other gateway staff.
The use of the uk-mail-managers list and some other bureaucratic devices allowed the various gateways to decide what was needed to fix problems. Improvements in EARN, such as employees able to update the tables from Holland, were making the network much more reliable. Some countries are now using bridged Internet links rather than EARN or X25; this makes access difficult as the EARN mailer is not yet up to full RFC822 specification and NSF is heavily used. Some recurring problems will disappear when the new PUCC mailer replaces the Columbia code used at present.
Roger Stratford asked about X400.
Bob Cooper said that X400 gateways are being provided for JANET and should be used in preference to private links.
John Gordon asked him when X400 would be introduced on JANET:
At present there are no stable X400/88 implementations, so there should be no X400/88 gateways before Sept 1990, when gateways and interfaces should be available. EARN's X400 migration policy is not clear as they do not intend to do their own development.
John Gordon also pointed out, regarding the present mailer, that if mail had a valid JNT or BSMTP header (neither of which carry over between JANET and EARN) mail containing junk could be sent to sites on either side of the gateway. It was suggested that perhaps a warning Comments: field could be added to ensure that such mail did not upset mailers on the receiving end which expected only MAIL files and did not themselves see the JNT header created from BSMTP.
In answer to Gurdev Bal, Paul Bryant said that EARN sites tend to sort problems out informally rather than through a bureaucratic system.
Roger Stratford wanted to know the definition of "large" for EARN files - the figures for EARN (10,000 records) and for Cambridge (100,000 bytes) were similar. At RAL large files go into a slower stream.
By mid 1990 more should be know more about IXI, migration to X400, what kind of line will replace our sub-channel of the HEP link and how much EARN will cost.
5th June 1990 was the proposed date, however the meeting need not occur if participants feel there is no need. Any next meeting will be organised by Ros Hallowell and any views will be welcome meetings.
SCIENCE AND ENGINEERING RESEARCH COUNCIL
RUTHERFORD APPLETON LABORATORY
COMPUTING DEPARTMENT
EARN progress
issued by
P Bryant
March 8, 1990
May I first remind you that most EARN documents are available in electronic form including the minutes and papers of the EARN Executive and the EARN Board of Directors. You can obtain an index to these papers by sending a mail message to LISTSERV@UK.AC.RL.IB containing the text
GET EARN INDEX
In the index you will see that all documents have a two part code such as EXEC12 89. You can obtain any documents by again sending a mail message to LISTSERV@UK.AC.RL.IB containing the text:
GET EXEC12 89 GET EXEC3 90 etc.
The 9.6K sub-channel of the HEP link will disappear on April 1 and be replaced by a dedicated 9.6K line to CERN. This line has been installed for about three months and has been used for X.25 testing. Thus the service is assured for the immediate future.
The line to CERN is now saturated and any small problems which occur have the effect of causing queues to build up very quickly. There are a number of solution possible which are being looked at.
Since the last meeting there have been no changes in the gateway at Rutherford. The new gateway code is now in a late stage of testing and will be brought into use in the next few weeks.
All five Northern Telecom switches have been interconnected since the New Year and have performed well. They have proved highly reliable in every way.
Six GBOXes (which use NJE over X.25 on a VAX) have been connected and testing has been encouraging although little live traffic has been passed but a lot of experimental traffic has ironed out a few problems. There are no EBOXes (NJE over X.25 on an IBM) connected. Rutherford were expecting to test the EBOX code but regretfully the relevant OSI code does not operate under the latest version of the IBM operating system (VM/XA). For the interested this is all to do with IBM rewriting the OSI code in SNA and not wanting to convert the old code for XA). There are now four members of staff working at the EARN OSI Centre in Amsterdam, one of which is funded by EARN and the others by DEC.
EARN has now produced details of how it will allow SNA to operate over EARN lines (see EXEC162 89 and EXEC19 90). As a result many lines are now migrating to SNA which will make a much more efficient network although it will be much more complex. As the developments are fairly recent there are no reports on the effect of the move.
There have been requests to operate NJE over IP in Europe. This is the protocol stack favoured by BITNET which allows them to take advantage of the NSF network. As with SNA we have commissioned a report which is not yet complete or agreed (see EXEC14 90). We are seeking the advise of RIPE (Reseau IP Europeen). RIPE has recently been set up to co-ordinate the use of IP internationally within Europe .
There are now no problems for 1990. The Executive were asked to provide a funding structure based on traffic figures. Whilst good traffic figures are now available there are significant problems. For example - who pays for traffic from servers which are located in a country and used internationally and how do you measure the traffic? How do you avoid each country minimising its traffic to reduce its contribution with the net effect that contributions will remain the same but traffic will be low and users restricted? These problems have yet to have a successful resolution.
A recent study has shown that if the cost of EARN (including the lines) were spread over all users they would each pay 3 ECUs per month. I will leave you to decide whether this is good value.
EARN now has the "green light" to permit the East European countries to connect (see EXEC22 90). We expect to vote on this immediately. The problem has been the COCOM regulations and the connection of super computers. As far as the UK is concerned I am assured that there is no problem.
I get few complaints or suggestions from users. I assume that "no news is good news" and that there are no problems. If this is not true please send me a message (PEB@UK.AC.RL.IB).
EARN/RARE
JOINT NETWORKING CONFERENCE 1990
PRELIMINARY PROGRAMME
_____________________
GREAT SOUTHERN HOTEL
KILLARNEY - IRELAND
MAY 15TH/17TH 1990
---------------------------------------------------------------------
EARN/RARE
JOINT NETWORKING CONFERENCE, 1990
To be held on 15-17 May, 1990 in Killarney, Ireland.
The JOINT NETWORKING CONFERENCE, 1990, is being held at a critical time in the development of research networking in Europe with important developments in COSINE (Cooperation for Open Systems Interconnection Network for Europe); IXI (International X.25 Interconnection 64KB X.25 Network); TCP/IP networking and IP coordination in Europe; IBM's EASINET Network; and the EARN OSI Transition Programme.
The Conference will provide the forum where policies underlying these developments can be discussed and reviewed, where networking specialists will be brought up to date on technical developments, where network service providers can outline their future plans, and, most importantly, where those who support academics and researchers using the networks can contribute to the development of networking policy and the introduction of new network services.
The JOINT NETWORKING CONFERENCE, 1990, is organised by:
The EARN (European Academic and Research Network) Association -
providers of the EARN Network, the general purpose computer network supporting academic research in Europe, the Middle East and Africa,
and
The RARE (Reseaux Associes pour la Recherche Europeenne) Association -
the Association representing all European, national and international research networks, and coordinating the development of research networking in Europe
REGISTRATION
NOTE: The closing date for Early Registration has been put back to 31, March, 1990. Please register early.
---------------------------------------------------------------------
The Preliminary Programme for the
JOINT NETWORKING CONFERENCE, 1990, is
MONDAY, May 14, 1990
____________________
12.30 Registration
19.00 Welcome Reception
TUESDAY, May 15, 1990
_____________________
MORNING: PLENARY SESSION:
09.00 Opening & Welcome
09.15 Invited Keynote Speaker
David Hartley, Cambridge University, UK
"Policy Issues for Academic and Research Networking:
Achievements, Failures and Future Prospects"11.00
Policy Panel: Invited panelists from Academia, Research, Industry and
Government will discuss the Policy Issues for research networking.
Research networking in Europe is influenced by many competing interests
including - the needs of researchers; the use of standards; industrial develop
ment; CEC policies national policy interests; and the PTT regulatory environ
ment. The Panel will discuss these issues.
AFTERNOON: PARALLEL SESSIONS:
14.00 Supporting Users
This session will explore the issues involved in supporting local and remote
network users. Requirements for international User Group support will be
presented.
Topics:
International User Group Support
Managing your Mail
The Travelling User
Help Desk and User Support
16.00 User Support Discussion
A presentation of approaches to coordinating the support of users will be
followed by an open discussions on the user support issues for research net
working.
Topics:
EARNINFO Presentation
Discussion on User Support
14.00 High Performance Networking
Plans for Gigabit networking in the United States and for 2Mbit/sec X.25 and
satellite based networking in Europe will be presented.
Topics:
US Gigabit Plans
2MBbps X.25
Ebit Satellite Networking
16.00 Lower Layer Protocols
Connection Oriented vs Connectionless for lower layer protocols. The merits
and demerits of the approaches and the effect on end-user services will be
explored.
Topics:
CO / CL Interworking
Interconnecting Local Area Networks
EVENING: Conference Dinner
WEDNESDAY, May 16, 1990
_______________________
MORNING: PLENARY SESSION
09.00 World-wide Networking
This session will look at networking in Africa, the USSR, the United States,
and Ireland.
Topics:
US National Research and Education Network
USSR report
Academic Networking in Ireland
UNESCO North African Project
MORNING: PARALLEL SESSIONS
11.00 Library Network Services
There is growing interest in the provision of Library Services across the
European research networks. The networking requirements of Libraries will
be explored and some existing services presented.
Topics:
Library Requirements on Communication Systems Connectivity for Libraries
The Network as an Information Resource
11.00 Technical Coordination
Coordination of technical developments in OSI and TCP/IP networking is
increasingly important. This session will look at RFC 987 Gateway coordin-
ation, and the RIPE TCP/IP coordination.
Topics:
TCP / IP Coordination
RFC 987 Coordination
Academic Network Coordination: An outsiders View.
AFTERNOON: PARALLEL SESSIONS
14.00 OSI Transition
Nearly all the existing national and international research networks are pla-
nning or are implementing some level of transition to the use of ISO/OSI pro-
tocols. Current activities will be reviewed.
Topics:
HEP / SPAN Migration
EARN OSI Transition
NJE/IP - A different Model for Communication in EARN
Coloured Book OSI Transition
16.00 Distributed Communication
The requirements for distributed group communication and the human factors
affecting group communication will be discussed. The LISTSERV experience
will be presented.
Topics:
Computer Supported Cooperative Work
Future Opportunities in Group Communication
The ASTRA Databases Project
The LISTSERV Experience
14.00 FDDI Tutorial
A detailed tutorial session on FDDI networking technologies and benefits, and
a look at PPT plans for FDDI Networking.
Topics:
FDDI Tutorial
PTT FDDI PLans
16.00 Technical Topics
This session will report on the progress of the X.500 Pilot Directory Services
Project, on experiences with FDDI networking, and on character set require-
ments and national language support.
Topics:
X.500 Pilot Progress
FDDI Ethernet Interworking
CERN FDDI Pilot Project Report
International Character Sets
17.30 Informal Discussions, BOFs, and Technical Meetings
Informal discussions and participant organised Birds of a Feather (BOF)
sessions. EARNTECH and RARE Working Group meetings, as desired.
THURSDAY, May 17, 1990
______________________
MORNING: PARALLEL SESSIONS
09.00 Information Access
This session will cover the provision of mail gateways and of database services
on public and research networks. A survey of Information Services will be
presented.
Topics:
Mail Gateways US-Europe
Survey of Information Services
Euronet DIANE report
09.00 Security
Networking security is an increasingly important topic. This session will look at
the Kerberos security architecture in detail, and discuss the provision of secure
mail.
Topics:
The Kerberos Security Architecture
Secure Mail
DFN Mail Security Project Report
MORNING: PLENARY SESSION
11.00 Invited Keynote Speaker
E. de Robien, Bull, France
"Research Networking: An Industry View"
11.45 Closing Session
EARN Report
RARE Report
Conference ends at 12.30
Conference Exhibition
User Support and Documentation. The Conference will include a major exhibition of existing end-user documentation to support network users. All participants are invited to contribute to this exhibition.
Posters
Facilities will be provided for poster presentations.
The Northern Telecom X.25 Switch is connected to a similar switch at CERN via a 9.6K connection. It is connected to VAX computer GBGBOX. There is an operator console placed near the switch. All other connections are currently for experimental use.
The switch forms a network with similar switches at CERN, Montpellier, and CWI Amsterdam. The network is operated from the EARN EOC in Amsterdam.
The rear of the switch faces the wall. There are 15 board positions to the front and rear. All cables are connected to the boards at the rear. Signal cable connections are referred to by board number and line number on the board counting from the top down and starting with 1.
The relevant connections are:
Northern Telecom CERN
|
IBM Modem
|
PTT circuit
| cable 1984
IBM Modem (Rack F labelled DIDCOT GENEVA DP1)
| cable "NT to EARN"
V24-V35 converter (Trend model 2-3 above Northern Telecom)
| cable local
Northern Telecom Peripheral interface 13 interface 1
Northern Telecom Peripheral interface 1--------------Console
Northern Telecom Peripheral interface 3 interface 1
| cable 2200
Monitor rack 1 top row labelled GBOX NT
| cable 2968
Line driver (Rack K labelled GBOX NT)
| cable 6050
Line driver (Gandalf LDS329 under floor at rear of GBOX)
| cable local
GBGBOX
There are no operator tasks required when the switch is operating correctly.
Press "return" on the operators console which should result in a prompt ">".
Check power to console and that console is in "line" mode.
Check cable between switch and console. This connects to the board in slot 1 at the rear.
Check the two power supplies to the switch in the adjoining rack by observing the voltmeters which should read 45 and the currentmeters which should read about 6 amps.
Check power to switch by opening door furthest from wall. Check that all three switches below the three "power converters" are UP. Check that the six boards with character displays have these illuminated.
Look at the boards. Some of these have two character displays which should show "D4" or "D1". There should be no error lights. If this is not the case the switch is not operating and the only procedure is to power it off and on.
Type the command:
13 1 D
The response will be:
+---------------------------------------------------------------------+ |> 13 1 D | | 90-03-15 11:09:07 Transaction ID = 37 | |> utp service status | | | | utp link state = operational | | link mode = trunk link | | | | local identification: | | mnemonic RAL_CERN; pi 13; port 1; rid 5; | | remote identification: | | mnemonic CERN_RAL; pi 9; port 1; rid 3; | | | | statspool flag = ON link carrier = up | | facility type = terrestrial round trip delay = 60 msec | | measured link speed = 10 kbps reported link speed = 10 kbps | | port switches dte | | | | modem leads : rts dtr dsrs lb llb - rfs dsr rlsd ci ti | | /bo - | | expect : - on on on X X | | input : - on on on X X | | output : on off off off off - | | | | 1990-03-15 11:09:08 command executed | | | |> | +---------------------------------------------------------------------+
The "utp link status" should be "operational" and if this is not the case then the CERN Northern Telecom switch is down or there is a modem fault or a cable fault or a PTT fault.
If the "expect" "modem leads" are different to those shown above then it is probably a line or modem fault.
Type the command:
3 1 D
The response should be:
+----------------------------------------------------------------------+ |> 3 1 D | | 90-03-15 11:08:54 Transaction ID = 36 | |> x25 service status | | | | ready ; refuse: off | | interrupt handler type = dma | | port switches = dte; v54 mode | | line speed = 9600 bps | | | | link status: | | protocol = information transfer | | modem = normal | | | | interface leads : rts dtr dsrs lb llb - rfs dsr rlsd ci ti | | expect (07 07): - on on on X X | | input (1F 07): - on on on off off| | output (1F 03): on on off off off - | | | | | | 1990-03-15 11:08:54 command executed | | | |> | +----------------------------------------------------------------------+
If "link status:" "protocol" is not "information transfer" then either the GBOX is not operational or there is a cable fault or a line driver fault.
If "interface leads" "expect" are not as above then do not suspect the GBOX.
Check GBOX.
Check V24 signals on monitor rack 1.
Check signals on LEDs on the Trend model 2-3 V24-V35 converter. Light DTR - blank, DCD, DSR, CTS - red, TD, RC, TC, RD - red/green.
Check line drivers in rack K and under floor near GBGOX.
Type the command:
13 1 D STAT
The response will be:
+------------------------------------------------------------------+ |>13 1 D STAT | | 90-03-15 13:33:48 Transaction ID = 39 | |> link statistics | | | | interval since last reset: 4 min | | receive: transmit: | | bytes 8859 bytes 10908 | | frames 2945 high-priority frames 0 | | local packets 164 low-priority frames 125 | | tandem packets 0 | | bifurcated packets 0 | | | | link quality: | | retransmit frames 0 lrc errors 0 | | discarded packets 0 crc errors 0 | | window closures 0 underruns 0 | | ayt entries 0 overruns 0 | | modem changes 0 | | | | 1990-03-15 13:33:48 command executed | | | |> | +------------------------------------------------------------------+
The values under "link quality" should all be zero or less than 10. If this is not the case the line is giving a large number of errors and the line or modem should be checked.
The "received: bytes" and "transmitted: bytes" should be large indicating that traffic is flowing. If this is not the case then the status of the GBOX and remote GBOXes should be checked.
Type the command:
3 1 D STAT
The response will be:
+---------------------------------------------------+ |>3 1 D STAT | | 90-03-15 11:08:39 Transaction ID = 35 | |> x25 line statistics | | | | interval since last reset: 9 | | statistics count type degrade overload oos | | frmqd 0 abs 10 20 50 | | bsize 0 rel 9 8 | | under 0 rel 9 8 | | cder 0 rel 9 8 | | modem 0 abs 10 20 30 | | proto 0 rel 9 8 | | abort 0 rel 9 8 | | nbuf 0 rel 9 8 | | rexmt 0 rel 9 8 | | crcer 0 rel 9 8 | | lrcer 0 abs 1 5 | | overw 0 rel 9 8 | | ofrm 64 | | ifrm 64 | | orr 192 | | irr 231 | | ornr 0 | | irnr 0 | | orej 0 | | irej 0 | | ofrej 0 | | ifrej 0 | | obyte 605 | | ibyte 667 | | ossq 9035 | | issq 23271 | | fsent 256 | | frecv 295 | | locfc 0 | | forfc 0 | | secur 0 abs 4 | | | | 1990-03-15 11:08:40 command executed | |> | +---------------------------------------------------+
Examine the column headed "count" with entries under "degarade" and "overload". These entries should all be zero. They count failures and when the failures reach levels defined in the "overload" column then the switch will close the line down for a short period. In this case there is a line or line driver fault.
The switch operates from two 45 volt power supplies in the adjoining rack. The switch will operate from a single power supply although the switch on power surge may trip the supply. The current drawn from each supply as shown on the meters should be roughly 6 amps.
Place the double pole switch on each power supply in the DOWN position. This removes the AC power. (The single pole switch controls the low voltage output).
Check that the single pole switches on the power supplies are UP. Place the double pole switches on each power supply in the UP position. They should be moved simultaneously to avoid power surge trips.
Ensure that the console and line drivers are switched on.
The switch requires no further intervention and will be operational within 5 minutes when all the indicators on the boards show "D4" or "D1".
Paul Bryant x4267 RAL Niall O'Reilly EOC, The Einstein Building, Kabelveg 21, Sloterdijh 1014, Amsterdam.
Recently we circulated a questionnaire to find out if there was a case for providing support for the Apple Macintosh computer. We were very pleased with the response from 82 of you.
There are 35 MACs on the site.
27 machines have no maintenance and 8 have contracts. Comments suggest that machines are reliable enough not to require maintenance.
The principle uses are word processing and desk top publishing with 11 machines. 3 are used for graphics. Comments suggest that most machines are used for a variety of tasks.
30 would subscribe to a support service and 8 would not.
The principle requirement was for communications support. This included access to the IBM as well as other machines.
There were fewer machines than expected. The replies suggested that the number of machines was unlikely to rise significantly. Many commented that their principle desk top machine was the IBM PC. Several of the Macintoshes seem to have been acquired for evaluation or for a special purpose such as desk top publishing.
If 30 machines were to be supported then this (on the PC support basis) would attract 0.3 man years of effort. The support of the Macintosh by part time labour would be unlikely to provide a satisfactory service and one full time support position would be a minimum requirement. On this basis support cost would be difficult to justify with the tight compliment and financial constraints.
There is a measure of support for the communications into the IBM from the Information Management Group of Central Computing which meets the major requirement.
The conclusion is not to provide any comprehensive support. We will review this should the number of Macintoshes increase significantly.
Dear Sir,
I have a Space Scientist, Dr. Chris Mutlow, who requires an IP link to NORSUN ERSI for the Near Real Time Demonstration Project. He is currently using the public packet switched service for this connection. It would be preferable to use the recently installed 64K X.25 connection to Amsterdam for this purpose. I believe that an IP link is being installed at ESA which would allow a connection to NORSUN.
Should this connection be established then there may well be further space scientists on this site who would make use of it.
To establish this connection we would need an IP router which would be connected between your X.25 switch on this site and the local site ethernet.
I am writing to establish whether this connection would be acceptable to you and whether it is possible for you to supply the required equipment.
I attach an "ESApac User Application Request".
My task at the Rutherford Laboratory is the development of the site ethernet including the use of IP which is why the request is coming through me.
Please contact me should you require further information.
Yours sincerely
Paul Bryant - Head of small systems and communications group.
This was the fourth meeting attended by 27 people. It was again held at NIKEF in Amsterdam.
The recent RARE decision recognised IP as an interim set of protocols which need co-ordination. Kees Neggers (who unfortunately could not attend the meeting) has been tasked to take an interest in the RIPE activity.
The creation of the users and address database is going well and has some 800K of information.
The maps of the IP network have been further developed.
There are now thought to be between 40 and 50 links between the US and Europe which is a surprising large number. Many of these appear to be restricted in their use such as SPAN connections.
Statistics are now being collected from the CISCO routers. Some diagrams seem to suggest that lines had average loadings of 10% but remember they include nights and week ends. The figures are available in Sweden but unfortunately they are difficult to access with the lack of an IP connection.
It now appears that the EASInet network (financed by IBM) will predominantly carry NJE/IP. This has a 1.5M line from Cornell to CERN. There are 13 64K lines radiating from CERN and Montpellier. This network is managed by GMD Bonn.
There was a long discussion on the structure of the backbone. Whether it should be regarded as an IP "cloud" or a backbone based on selected site. In fact a backbone centred on CERN and Amsterdam gained favour.
The relation between RIPE, IXI, EASInet came to no conclusion apart from some worry over what happens after July 1991 when the current IXI phase ends. There are no definitive plans to exploit IXI.
EARN is contemplating the use of NJE/IP and a paper has been produced by Hank Nusbacher (Israel) and this paper was considered with no adverse comment.
The next meeting will be 11/12 June in Amsterdam.
A communications strategy will:
The user requirement implies the use of high speed networking technology which is now available together with the relevant interfaces to computers and the relevant supporting software.
The need to operate economically, particularly with respect to staff costs, leads to a tactic of simplifying the network infrastructure whilst at the same time maintaining or improving services without heavy expenditure. This implies encouraging the use of technologies which have a long life expectance and high performance and discouraging the use of older methods with the expectation that they can be removed. A minimum number of technologies carrying a variety of traffic will be used in the quest for simplicity of equipment. The newer technologies are the more complex where many connections may depend on a few pieces of equipment. This requires that careful thought has to be given to the maintainability of key items and possibly the provision of spares. Thus more sophisticated monitoring equipment and suitably trained staff (but fewer of them) are required.
Central Computing Department is no longer in a position to develop communications systems from scratch and there is now no need with the large number of products now available from suppliers. It is important to ensure that the products adopted are in common use and are of a high standard. Thus a variety of products must be tested and evaluated prior to offering services.
There is a great temptation to use proprietary communications systems and this must be resisted (with the exception of DEC and IBM strategic products). Such products often lead to dead end developments while delivering only short term advantages. Thus standards with a large following in the academic community which are well tried and trusted and have good support must be followed. The adoption of these standards also aids interworking between local and remote systems.
The strategy will:
A revised strategy is needed to:
For many years the communications requirements of Rutherford have been largely met by the X.25 network with Coloured Book protocols, the coaxial 3270 connections, and PACX. While these provide a good service newer technologies can provide significant advantages particularly on site.
The aspirations of users have increased and the technical opportunities to meet these aspirations have emerged to the point where a revised strategy is appropriate.
The customers of CCD should be aware of the network strategy and the services that can be provided and the charging mechanisms involved. Such an awareness will guide customers to take advantage of the preferred communications methods provided.
The customer services required are:-
A increasing variety of terminal equipment is emerging comprising mainly of PCs, VAXstations, SUNs, and 3270s. The use of glass teletypes will diminish together with some other obsolete terminals.
The limitations of current services are:
Apart from the archival requirements all of the requirements can be met but at a relatively slow speed - typically sub 19.2K for terminals and 64K for computer connections.
The X.25 network, PADs, and the PACX system have a large and complex system of equipment and of cables crossing the site. Although remarkably reliable its maintenance requires a high level of knowledge of many pieces of equipment and this has manpower implications. Any failures tend to effect a small number of users.
The networks allow a variety of methods of providing similar services which has support implications.
The use of "glass teletype" terminals is reducing in favour of 3270, PC, and workstation equipment which can take advantage of higher bandwidths and higher speed connections than PACX or PADs can provide. None the less the Cifer network 3270 terminal is still very popular as an adequate 3270 for some customers which would be costly to replace particularly for HEP who have a large number. The popularity of PC and workstation equipment is in part due to the desire to have a measure of local processing as well as access to other machines for mail and shared or large scale facilities.
The exception to this trend is the use of VTxxx terminals which are limited to 19.2K and an asynchronous interface. These terminals do not work well over the X.25 network due to the character at a time method of use. This encourages connections directly to VAXs or DECSERVERs and the use of DECNET. Note that VTxxx emulation via ethernet connections is not constrained to 19.2K.
A transition to newer methods has problems:
To move all traffic to modern methods immediately would be an expensive and disruptive exercise.
The ethernet has the characteristic that a failure is capable to bringing down the complete network or a large part of it. This has already been seen with the incidents of "broadcast storms". Thus, good monitoring equipment and diagnostic tool are needed to quickly isolate faults and if necessary replace equipment.
The traffic on the current backbone and CCD ethernets is low. This situation could change as the use of protocols such as X-WINDOWS becomes popular. Unfortunately the overload characteristics of ethernets causes performance to degrade catastrophically. This again requires careful monitoring of the traffic and the development of contingency plans for increasing the network capacity. This may be the installation of further ethernet connection or by the installation of a 100M/bit FDDI network in selected areas. These development should be transparent to the customer.
The conclusion is that whilst a migration to more modern and performant methods is desirable this will take a long time to accomplish if it is to take place by a process of equipment becoming obsolete rather than by heavy investment in new equipment.
All new communications connections will be encouraged to be via newer technologies and connections via the older ones will be discouraged. Assistance will be provided for migration to these newer technologies. The older technologies will be phased out as they become redundant.
The co-axial (including fibre optic multiplexors and PIXNET) 3270 connections give a high quality access to the IBM for "real" 3270 terminals and PCs and as this is well supported by IBM and unlikely to be superseded in the near future this is a sound if not unavoidable access method.
The recently installed ethernet has proved that this system can provide a variety of high speed access methods including most if not all the ones currently enjoyed by other link level services. It has proved reliable. It must be noted that as yet traffic on the CCD and backbone networks is light other Departmental ethernets show quite heavy traffic.
The ethernet can carry most of the services now carried by the X.25 network although the shift to use the ethernet has been inhibited by inertia and the need for equipment (DECrouters, DECservers, ethernet PADs, and a name server for the Pink book gateway).
PACX, although not strictly a link level, provides terminal connections. The principle use of the equipment is for access to PADs which is to be expected with the removal of the PRIME and IBM asynchronous terminal facilities. Thus the equipment is a contention unit for the 32 PAD ports plus a few specialist services. It should be relatively easy to move these connections to PADs.
Off site traffic is dependent on the services provided by other parties. Thus there are X.25 services to JANET, bi-synch to EARN and HEP, and DDCMP to SPAN. BSC will be replaced by SDLC for HEP. BSC for EARN will be replaced by X.25 or SDLC. The DDCMP and SDLC services may be replaced by X.25 but there is some concern that this may reduce performance and not mix well with the other X.25 traffic.
There is a small demand for IP although this may increase with its increasing adoption within Europe. As with DDCMP and SDLC this traffic may use X.25 with similar concerns with those protocols.
Communications on site will be based on the IBM 3270 network and the evolving ethernet. New connections will be encouraged to take advantage of these services and assistance will be provided for migration to them. Other types of connection will be discouraged.
Off site services will continue to exploit X.25, DDCMP, BSC, SDLC, and IP. The use of BSC will vanish.
In general the greater part of traffic is between homogeneous machines under the same management. Thus the majority of traffic is between machines in the same Rutherford Department. Traffic between heterogeneous and inter Department traffic comes next. Off site traffic comes third.
The VAX computers are connected to the ethernet and use DECNET between themselves. DECNET is also used off site for STARLINK, HEP, and SPAN traffic. This provides the best quality of service possible between such machines and has the advantage of being well supported by DEC. The introduction of DECNET on the IBM, principally for archival reasons, provides an additional opportunity yet to be exploited. The use of DECNET will continue. DEC is committed to migrate to use some ISO protocols within DECNET phase V. The site will migrate with DEC's policy in order to take advantage of DEC developments.
FTP, TELNET and NFS operate between UNIX systems and implementations are available on the IBM and PCs which are good (apart from NFS on the IBM). These protocols are also available on the VAX systems but have not been little exploited at Rutherford as they provide modest benefit and there seems to be only a small demand for UNIX to VMS traffic. This may change as Telnet VT100 is a viable access method for VAXes. Informatics Department exploit the protocols as do other Departments with UNIX equipment. Although the protocols on the IBM whereas principally purchased to allow the archiving of UNIX file stores it has proved effective for 3270 and file transfer and access and this use is likely to increase because of the maturity, robustness, and modest cost of such connections.
Pink Book protocols are available on IBM, VAX, PC and UNIX systems. The service has not been as popular as expected. This is because users would rather use the more mature DECNET and TCP/IP protocols between homogeneous systems and the recently provided 3270 and VT100 over TCP/IP . It is unlikely that the dumping and archival to the IBM traffic could use Pink book as this will rely on pieces of mature UNIX and DEC software which utilises TCP/IP and DECNET and would require significant development to move to alternative protocols (Blue Book or FTAM) and seem to have no significant advantage.
As yet no ISO higher level protocols are in use at Rutherford. The JNT have a transition programme which Rutherford must follow in order to maintain and enhance communications with other JANET sites. Whilst a number of small development projects are taking place there is no firm indications of dates when services could be launched.
The first protocol of interest is likely to be X.400 mail service and there are many activities in the community towards this end. Rutherford requires X.400 services for the IBM and VAX computers. Whilst it is understood that VAX products are well advanced there is less optimism over an IBM product. UNIX products using the IOSDE development tools are well advanced but it is unclear whether these will lead to products. X.400 may require the installation of a Grey Book to X.400 converter as well as an X.500 name server. These are areas where further study is needed.
FTAM is less well developed. It is as yet very unclear exactly how such a service will develop. There are pilot products and a Blue Book to FTAM is being developed in the community. Rutherford can but await developments.
JTM and VTP are further away.
On the face of it it would appear that Pink Book would be ideal for the traffic to the wide area network via the Spider gateway together with the NRS name server. This route has only recently been available and has had only modest use. There are also alternative routes.
The IBM computer has a direct X.25 connection to JANET and this will continue.
Many VAX computers have connections to the campus X.25 network although these may be removed in time. If the on-site communications are to be concentrated on the ethernet then the VAXes have two options. The first is to use Pink Book and the second is to use PSI access which would allow the complete VAX DECNET on-site network to have a single or small number of X.25 connections and coloured book traffic can be carried over DECNET connections to these connections. The DECNET solution is more attractive since it can be implemented immediately, involves fewer suppliers, and involves fewer pieces of equipment.
It is as yet unclear whether the growing number of IBM PCs with network connections require direct JANET connections or more likely whether the use of the IBM or VAX computers as servers is more appropriate.
As there is only a single IBM computer the use of SNA access methods is only of interest for off site communications to CERN, DESY, EARN, Swindon and possibly other UK machines. The current NJE/bisych connections will probably migrate to use SNA in some cases over X.25.
Seen from the high level protocol perspective the DECNET, TCP/IP, Coloured Book, and SNA form four virtually isolated networks. This is more of a nuisance in that machines often require more than one communications system. This is against the JNT philosophy of one universal set of protocols. Although such a philosophy seemed attractive in the past the adoption of a universal set by manufacturers is poor and the DECNET, TCP/IP, and SNA access methods provide the more attractive services. The Coloured Book protocols are essential for communication with the rest of the UK community particularly for mail. The ISO protocols have yet to make their mark and it may be that apart from X.400 the other high level protocols may only have modest impact.
Computing Department will actively support DECNET, TCP/IP, and IBM SNA and 3270 co-axial methods. Computing Department will support Coloured Book protocols principally for off site access and access between heterogeneous machines.
In the past the Computing Department Division was responsible for the vast majority of computing on the site. Since then Departments have set up their own substantial computing organisation mainly to operate VAX machines. This trend had been augmented by the introduction of PCs and workstations which are also under Department's control.
There is a similar trend in networking in that the ethernet is based on a set of interconnected Departmental networks which are largely managed by the Departments with an inter Departmental co-operative arrangement.
It seems unlikely that the strategy of a single computing and networking management and operation will return, on the contrary, these trends are set to continue.
The provision of communications within a Department will gradually become the responsibility of the Department. Computing Department will provide networking services in the form of consultation, installations and maintenance under a suitable contractual arrangement with each Department.
The implementation of the above strategies will take some time as there is no point in accelerating it unless there are good economic, staff, or service gains.
Whilst these strategies are currently optimal it ignores possible developments such any demand for ISO services, the transition of DEC to use ISO protocols or high speed FDDI 100Mb services. There are, no doubt, developments as yet unidentified which may demand a revision.
The network strategy for the site should be reviewed at least once per year.
NTMPC is invited to approve the quarterly progress report.
The papers are awash with adverts and comments on the 100Mbits FDDI (Fibre Distributed Data Interface) networks. The initial idea at Rutherford was that we would replace our backbone with this technology when it became overloaded. The truth seems to be that the village networks will overload before the backbone. Wisely we have so arranged things that most traffic is between machines within the same village.
We have had a number of presentations which have been useful in exploring the options open. It is clear that there are a number of decisions on the sort of topology that would suit the backbone and the villages depending on the physical characteristics of the site and the amount of resilience required. From a protocol point of view we have to ensure that any move to FDDI is invisible to the users. There are still a number of standards issues in the protocol area which need to be resolved before any firm plans can be laid.
It is hoped that the first project would be to have a small experimental network and a possible vehicle would be for the transfer of graphics data to the Topaz system. Even before this is undertaken it is important to make sure that any equipment is "standard".
The cost of FDDI is high and hopefully this will reduce before we buy anything.
1.1.1 JTMP Host-end Service
The JTMP server now supports the KILL and STATUS requests for jobs submitted to the COS jobmill. Work on the latest version of the JTMP server (Network/VM 3.1B, based on SPCP 4.1) is progressing and should be ready for installation in February. This new version will support the UNICOS jobmill.
1.1.2 NIFTP
No major changes have occurred, but there were a number of minor enhancements and fixes. The FTP exec has been converted from EXEC2 to REXX, and can now be used from both 370-mode and XA-mode virtual machines.
1.1.3 NETFILE
Still no progress on this due to the backlog of more urgent commitments.
1.1.4 SSMP
Version 3.0D3 was recently received from Reading and installed. It has also been sent to ULCC and MCC.
1.1.5 Pink Book
Plans for merging VMNCP with VMNCPE were well advanced, but have had to be shelved for some weeks due to preoccupation with the 3745 and problems with operational software.
The possible use of Fast Connect support for NPSI also has implications for merging the two machines, and some re-thinking needs to be done.
1.1.6 CMS-PAD
The only significant change is that the PAD command can now be used from both 370-mode and XA-mode virtual machines.
1.1.7 VTAM/NCP/NPSI
The situation is essentially unchanged since the last report: the service has been tolerable most of the time, but with too many breaks and other problems, and occasionally a very bad spate of difficulties.
1.1.8 IBM 3745
A new attempt was made to introduce the 3745 on 5 December, but this merely revealed another bug: that the NPSI control sessions tended to get into hung states which prevented the setting up of new calls. It was therefore backed out. In spite of persistent efforts to galvanise IBM into action, there was still no fix in sight at the end of January (and indeed none was received until 5th March).
The delay was partly due to our inability to supply IBM with VTAM buffer traces when requested in mid-January. The trace facility seems not to work in our version, and this too has become a long-standing problem (still unresolved in early-April).
Because of the apparently indefinite delay, a decision was made to redesign VMNCP to use the Fast Connect feature in NPSI, thus by-passing the hang problem and possibly providing a more efficient and reliable interface. This required 3 weeks of solid work, but is now complete. Unfortunately a serious bug has since emerged with Fast Connect also, and it is not possible to introduce it into service.
Although individual IBM people are helpful, the procedures for supporting these object-code-only products are exasperatingly inadequate. This is costing us a huge amount of wasted effort and loss of credibility with the users.
1.1.9 VMNCP
No significant changes. An occasional 'program interrupt loop' is under investigation.
1.1.10 RSCS
RSCS V2.2 (RSCSKING VM) has a local modification applied to catch the well known 'virus' files DIR EXEC and CHRISTMAS EXEC. This code stops transfer of files with this name both into and out of the IBM 3090 and warns a selected list of users.
RSCS V2.2 continues to run as our main RSCS node and appears to have no problems. We are waiting for a CP modification to spool file handling before RSCS V2.3 can be installed.
1.1.11 TCP/IP and the IBM 8232
The IBM 8232 continues to be very reliable.
A line printer server from Columbia has been installed and modified and now provides a printer facility for UNICOS. This is due to become a production service in the next few months.
A line printer spooler (lpr) and query command (lpq) have been tested and will be released to users once local modifications have been applied.
1.2.1 Introduction into service of the 3745, either with or without the Fast Connect feature in NPSI.
1.2.2 Introduction into service of VMJTMP Version 3.1B and RSCS Version 2.3.
1.2.3 A renewed attempt to merge the Pink Book software (VMNCPE) with the main X25-based software (VMNCP). This would rectify the problem that at present there is no FTP P-end capability via Pink Book.
1.2.4 SNA links to CERN, DESY and Swindon will probably be set up.
1.2.5 A separate VTAM virtual machine for Swindon users will be set up to insulate them from problems affecting the main VTAM service.
IBM are due to produce some OSI products during 1990: OSI/CS in July and FTAM in September. However, it is now found that the initial products will be for VM/SP only, not for VM/XA.
2.1.1 Local
The Telecoms section is still short of manpower but the adverts have now been placed and 20 applications have been received. It is hoped to shortlist within the first week of February and board as soon as possible.
The number of problems has increased this quarter, this is due to two factors. The thunder storm just before Christmas which struck R2 and damaged a number of Multiplexor, PAD and Terminal boards. The second being the gales at the end of January.
* The CPSE had one hardware fault - this being a faulty fan in a Power Supply. It was replaced as soon as the problem was discovered to save any unexpected break in the service.
* The CPSE traffic is down by approx 8% on the previous quarter. This maybe due to the season and more traffic going out via the DECNET and SEEL.
* The SEEL failed to restart after the November Air-Conditioning shutdown. The error message indicated a Hardware fault. The engineer was called on the Monday and discovered that it was in fact a software configuration problem. This can be put down to poor SEEL documentation and our general inexperience on the SEEL due to staff shortage.
* Both PACX and the Ethernet have been trouble free during the period.
* The Ethernet FF problem reported in the last report is still with us. The program to change all the PROMs has slowed due to staff shortages.
* The number of PAD faults is lower than the previous month just, but this quarter a number were due to board damage following the thunder storm just before Christmas.
* A number of multiplexor boards were also damaged during the storm.
* The ESA line to ESTEC has been installed and tested satisfactorily. The same applies to the ESA PSS line. The equipment is due to be installed on this line during February.
* The EARN analogue line to CERN has been installed and is now being used to connected the Northern Telecom switches together.
* The schools PR1ME connections have been cancelled and the equipment recovered.
* An order has been with BT to rationalise the termination equipment at RAL. This will mean replacing the existing 3 racks containing the 29A termination units with 1 rack with modern termination equipment. The cost will be recovered within 18 months and we will also recover floor space.
* Currently a rationalisation of equipment held by Telecoms is in progress. It is intended to dispose of all old or redundant modems, multiplexors and terminals in the authorised way.
2.1.2 JANET
The reliability of the JPSE improves. The main problem area being with software crashes caused by individual line processes failures. The traffic level has increased by some 11% over the last period and the highest daily total has been 977M bytes switched. The Mercury Multiplexor has now been installed in Telecoms.
* Mercury lines to Oxford (256K) and Keyworth (64K) have been installed.
* The Swindon Mercury connection has not yet been brought into service due to a number of wiring problems at RAL and Swindon. It is now intended to move the terminal point at RAL from the PABX to the Mux in Telecoms.
* The number of problems on the analogue lines is still high and BT have been given a list of lines which we are concerned about.
* The Megastream line to Daresbury had to be reported faulty on 3 occasions to BT.
* The installation of ESA equipment.
* Introduction of the Netcomm Switch for high speed JANET lines.
* More Staff.
* Statistics gathering program for SEEL.
* Ethernet Monitoring equipment.
* Better Ethernet Stats program.
The expected increase in the number of repairs by Kode occurred, with a rise of 60%, nearly all accounted for by PC's. But the MSM total was markedly down.
The overall figure of 145 faults, was slightly below that of the last quarter. 38% of which were repaired by the sub-section staff and the remainder by contracted agencies. The high figure of 16 repairs by telecoms for the Science department was due to a lightening strike on Isis division's building R2.
The distribution of agency repairs is as follows:
Last qtr. This qtr.
MSM 44 13 Movable terminals
KODE 38 62 Non-movable terminals
SIGMEX 2 1 Sigmex terminals only
OTHER 15 14 Warranty repairs
The 145 faults have been analysed for divisional distribution. Of this total, 22 (15%) were CCD and the remaining 85% for other RAL divisions.
____________________________________________________
| | REPAIR AGENCY | |
|Division |_________________________________| |
|-Project | TCOM | MSM | KODE |SIGMEX|OTHER| TOTALS |
|_________|______|______|______|______|_____|________|
| ADM | 4 | 1 | 10 | | 8 | 23 |
| CCD | 5 | 2 | 10 | 1 | 4 | 22 |
| CO | | | 6 | | | 6 |
| EBW | | 1 | | | | 1 |
| INF | 2 | 1 | 9 | | | 12 |
| PPD | 9 | 2 | 4 | | | 15 |
| RCR | 1 | | | | | 1 |
| SCI | 16 | 2 | 2 | | 1 | 21 |
| SL | 6 | 1 | 5 | | | 12 |
| SPA | 5 | 2 | 5 | | | 12 |
| TEC | 6 | 1 | 9 | | 1 | 17 |
|_________|______|______|______|______|_____|________|
| TOTALS | 55 | 13 | 62 | 1 | 14 | 145 |
|_________|______|______|______|______|_____|________|
The next three month period sees the preparation for tendering for the renewal of the three maintenance contracts for terminal repairs.
The optical fibre cable to R65 was terminated. An ether bridge was connected to it to provide the Technorth village with access to the site ether backbone. A thin ether multiport repeater was installed on the completed thin ether wiring in R12, R63, R65 & R66. A further thin ether segment was run to the R12 Klystron hall.
Coaxial wiring was completed at the Vickers Tower Millbank for BNSC.
Thin ether segments were installed in R68 and R25.
More than 800 cables were checked during the six-monthly Supply Cable Check at the Atlas Centre.
The BNSC village thick ether was extended to the ground floor in R68.
The TCH wiring continued with a second contractor being called in to finish work not done by the original contractor.
The links to Harwell to provide access to their Stores Database were completed.
Another DECserver was installed in R25.
New cabling was provided for a DECserver 300 in R68.
Many coaxial cables were installed around the RAL site for 'full screen devices'.
Office moves continued to provide plenty of work moving PAD, PACX and DECserver connections around.
More thin ether segments in Atlas, R68 ( BNSC), R25 (AIT facility).
Techelec thick ether to be extended to R25 Heavy Duty Lab. (HDL) & into R68 2.15. 128 coax cables for additional full screen controllers.
BT might eventually move the PWs for the communications at TCH. Additional wiring will be installed by contractors to extend the existing PWs in anticipation of BT not completing the move in time for a conference in April.
Coaxial wiring in TCH will be changed at the same time as the PWs are moved ( or extended, whichever is the earlier), to allow all communications to be controlled from the terminal room in the new Seminar Building.
R2 Dormitory wiring should be completed.
A visit will be made to DESY to change the 14.4Kbps modem for a 19.2Kbps modem. Other work will also be carried out and discussions held with DESY data comms. personnel.
A DECserver will be installed in the Atlas Centre to provide connections from conference rooms at RAL.
5.1.1 Network Software
CBS V5.2 (with St. Andrews PAD V5.2) was released in late November. This release fixes some of the major problems seen in V5.0 such as the queue file expansion problem that has caused the software to fall over, incorrect reverse address lookup, PAD session hanging and other security related problems.
Apart from providing some bug fixes, this release of CBS enhances the support of DECnet connected VAX machines including mail forwarding between DECnet and GreyBook. It also enhances the support of PSI Access running nodes.
JTMP V5.2 was released at the same time as CBS V5.2. It fixes some major problems one of which caused a process becoming CPU bound on jobs submitted with a unrecognised sink file type.
The delay on the release of the CBS update had caused some concern to some managers due to the seriousness on the problems experienced with V5.0. The SERC VAX managers, however, have been able to obtain an early update from the VAX Support Group as an additional advantage from the latter's involvement in the field test of the product.
There has been no change in the VAX PSI/LLC2 software in this quarter.
5.1.2 Network Hardware
There has been no change in network hardware on the Cray Front End machines and the Development VAX. However, three VAXStation 3100s were installed in late January. The VAXStations run DECnet over PSI Access, the latter allows the VAXStations to use the X.25 connection on the Development VAX to access JANET.
There is no change in the network hardware on the EARN G-Box. With the provision of a 9.6K line between RAL and CERN in January, the UK G-box is now connected to EARN OSI backbone network through the Northern Telecomms switch. There are currently four G-Boxes connected to the backbone.
The regular networking support of PSI with PSI Access , 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 new NRS update procedure for VAX machines to run CBS across to JANET through a Spidergate has been made available.
No major incidents were recorded in this quarter.
It has been announced that Unicos will be provided in production level in March. Some efforts will be required on the VAX Front-End to channel jobs submitted from JANET using the File Transfer Take Input mechanism to the new Cray operation system.
A Campus Name Server will hopefully be delivered to CCD in March. Some SERC sites have shown interest on this product and in particular its interworking with a Spidergate LAN/WAN gateway. It will be useful to gain some experience with it.
6.1.1 NJE
No change.
6.1.2 File transfer between EARN and JANET
No change
6.1.3 MAIL
The EARNGATE code is complete and has been used for test traffic. The code to extract the names from the personnel data base is now required. Great care is being taken before introducing the new code to ensure that the service is not disrupted.
The traffic levels, mainly caused by mail, now saturates the line. This is shown by the large queues that build up during busy periods. It would be possible to replace the modems with 19.2K modems.
6.1.4 LISTSERV
The service has operated well.
Quite a few new lists have been provided.
EARN now provides support for LISTSERV from Turkey. To obtain this service Rutherford needs to sign an agreement which requires Rutherford to cease using LISTSERV should they leave EARN. This is unacceptable and a solution is being sought.
The author of LISTSERV has now produced a new version (1.6) which some sites are taking. It is preferable to obtain support from EARN as this support is obtained under contract rather than by best endeavours.
6.1.5 EARN management
EARN funding for 1990 is now resolved.
The Executive has been asked to place EARN funding on a volume basis in 1991. Several models have been examined but they all fail. A volume charge will encourage each country to minimise their traffic and will merely result in each country paying the same as they do now. It is unfair to charge traffic generated by databases and distribution lists to the country operating them. It has not been found possible to take account of this traffic effectively. Thus a fixed cost model is likely to be recommended.
A document defining the EARN strategy and policy for the future is under production and will be presented to the next Board meeting.
EARN has accepted a report on SNA and will now allow it to be used freely on the international connections. This should improve the throughput of the network and relieve some of the bottlenecks.
A similar exercise is taking place with TCP/IP but this is at a very early stage.
Hans Deckers has been appointed the new EARN manager and will take up his post in a couple of months. He will be located in Paris and will have a staff of 3 or 4 one of which is funded by EARN.
6.6.1 Transition
All the switches and GBOXes are operating. Test traffic has been passing over the X.25 network and the signs are encouraging that the system is stable and reliable. Operator procedures and documentation is being produced. The GBOXes and switches are operated from the centre in Amsterdam where expertise is growing.
EARN is committed to taking part in the IXI pilot X.25 project. A preliminary project document has been produced and is under discussion. EARN is waiting for a connection between the IXI and EARN X.25 networks.
6.2.1 NJE
The traffic will have to moved off the HEP line. It will probably be moved to the current 9.6 lines used for X.25 testing. It is as yet unclear whether the traffic will use bi-synch or X.25.
6.2.2 File transfer between EARN and JANET
No change expected.
6.2.3 MAIL
The JANET side of the gateway will be replaced with an updated system which will incorporate the name database. The EARN side will follow in a few months.
6.2.4 LISTSERV
Some arrangement with EARN is required so that LISTSERV will be maintained by EARN staff. This is a complex issue.
6.2.5 Transition
Some parts of the EARN x.25 network should start to carry live traffic. The UK traffic may take this route.
The 9.6K line is overloaded. The use of 19.2K modems will provide relief. The use of IXI may also provide an alternative higher bandwidth service or may augment the current route.
There have been no problems with the Hyperchannel during the three months of the report.
Connection of the VAX front end to Unicos has been completed successfully, it only awaits heavy usage to see if the 'unsupported' configuration works o.k.
Monitor of VAX hyperchannel connection during Cos to Unicos transition.
None.
This report now covers both PC Support and PC Networking.
The death of Jill Banks (nee Cheney) was a great loss to PC Support and meant that the end of year rush had to be done without her excellent management of all the administration. The arrival of Simon Widlake has helped considerably and he is doing a lot of the site visits and sorting out of disc problems.
The statistics for the three months were 68 orders placed, of which 38 were for PCs, and a total value of 135,447 pounds. This is lower than last year due mainly to the spending restraints. The PC total, including those on order, is 333 and the requested man year charges levied on each Department have been increased accordingly. Whether we get them remains to be seen.
The PC market place is gradually moving towards 386 based machines rather than the 286 PC/AT type that RAL scientific staff currently use. IBM's main PS/2 machines are all 386 based and this architecture is now being exploited by the newer software packages. The arrival of the 386SX chip (a 16bit variant of the 32bit 386 processor) has meant that the price difference is only about 200 pounds above a 286 machine. Our main supplier, Tandon, does not have a suitable 386SX machine so an evaluation exercise was commenced to try and find a suitable supplier. Two machines are being evaluated but due to the pressure of support and ordering equipment, progress has been slow.
Virus' continue to be headline news and the much reported Aids Trojan was received in the post by staff at RAL and Swindon Office. Although it did not actually infect any PCs a significant amount of effort was expended in learning how it worked. As the virus has a long delay before activation and, contrary to some expert reports, did significant damage to the PC filestore, this effort does mean that we can now recover any infected machine and have learnt a lot more about virus'.
A more serious case was when two machines in separate public areas became infected by the 'Stoned' virus. Infected discs from these PCs were in use on other machines including one in a third public area but fortunately had not infected any of them. A rapid response from PC Support and an understanding of the potential hazard averted what could have been a major incident. The infected machines were cleaned up and floppy discs that could have been infected were checked. Virus checking software was also installed to catch any reinfection. The incident did however result in a few sleepless nights wondering if all traces had been located since this was the classic case whereby a virus could infect a large number of machines.
With the increasing dominance of the Microsoft C compiler in the market place, and educational discounts bringing a significant drop in price, it was decided to move all development over to this compiler and its Quick C stablemate. This has proved to be a slow and tedious process due to the increased type checking and the need for prototypes for all the routines. The majority of the RAL utilities have now been converted and are under test.
The software distribution system using the IBM PCSOFT 192 disc is now in operation. It currently contains the RAL Antivirus program and MOS2. The RAL utilities will be added when testing is complete.
One of the irritations of the DOS operating system is the fact that device drivers can only be loaded when the machine is booted. Since these often provided specialist interfaces such as graphics and communications they are not needed for a lot of time yet occupy valuable memory. This prevents some of the larger packages such as DW4 from running. As there was no product available to overcome this it was decided to write one. The result is LOADSYS which can load and unload Device Drivers and Terminate and Stay Resident Programs which are the two ways that extensions to the system are made. Initial tests show that the techniques work and that tinkering with the DOS internal tables is possible though reliability is currently a problem.
PC maintenance continues to bring in a steady supply of work and problems with getting equipment repaired are being overcome. The most troublesome equipment has been EGA screens and disc drives. Increasingly the total cost, including staff time, make repairs of cheaper items uneconomic.
The arrival in December of Kevin Hoadley has led to significant progress in the networking area. His first task was to produce a Pink Book interpreter for the LANalyser. He then turned his attention to the Rainbow software and has done extensive testing of this product. This has revealed several bugs especially in the newer facilities such as keyboard mapping and implementation of some IBM 3270 keys. Several problems are still outstanding but are under active consideration by Edinburgh.
Significant progress has also been made on TCP/IP as further free versions have been obtained and attempts at mounting them have been made. A site licence for 20 copies of the PC/TCP Plus product has been ordered and Chest have negotiated a deal for the SUN PC/NFS product. This is being purchased for Daresbury but as the site licence is for the whole of SERC, RAL will be able to make use of it. A table of which software provides what facilities has been drawn up and it is hoped to have a clearer idea of what will be recommended to users in the next few months. It is highly likely that most features will be free and it is only when X Windows is required that money needs to change hands.
One major omission from the current TCP/IP repertoire is a PC version of the print server LPD. If one could be found, or written, this would allow a PC on the ethernet to act as a print server to any machine that had the remote print spooler LPR. This would therefore provide a cheap and simple method of providing local printers which could optionally support graphics services such as Postscript. LPR is available on all Unix machines, the IBM and Cray Unicos systems as well as the PC. The only major system without it is the VAX. The TCP/IP world is currently being scanned for a PC LPD product.
MOS 2.1a has been released and cures many of the file transfer problems of version 2.1. The latter were mainly due to conflicts between filestore access and communications and were solved by removing all the parallel processing of these two activities. The implementation of the EEHLLAPI interface is now under test with the PROFS team and results are encouraging. MOS releases are now done via the PCSOFT 192 disc on the IBM and involve minimal effort.
Once the end of year deliveries arrive there should be a pause when progress can be made on evaluation of 386SX machines.
It is hoped that first release of LOADSYS will be made and a pilot PC LPD server may be installed.
The PC administrative load, especially at the end of the financial year is taking a major amount of effort and a replacement for Jill Banks is urgently required. It is a crass waste to burden highly trained technical staff who are in short supply with administrative jobs such as photocopying especially with the trek this entails from R30.
Should the RAR supply the man years requested for PC Support then there would be more than sufficient for an additional PC Support person to be recruited.
Running without support over Christmas only gave rise to one reported time out after seven days, from RHBNC. This did not seem to have caused any trouble there so in fact the period could be called trouble-free. After warnings to the EARNUS, uk-mail-managers and EARN-UG lists, Christmas users were aware of the situation, however no one found cause for complaint after Christmas (there was plenty of mail about the warnings and perhaps the correspondents were prepared). There were a few Christmas cards in DEADMAIL after the holiday, as you would expect when an address is only used annually.
We now receive NETSERV tables promptly. "Errors" caused by new additions testing email do upset the testers, but we now know from Holland exactly how new our tables are, so the conclusion must be that most new sites have two or three tries at registration and do not realise that their wrong entry has gone round the world.
The UNICOS course in January used TCPIP interactive access to the Cray through Spider PAD lines borrowed from ten users. Ethernet access to UNICOS is used by RAL and Daresbury Lab users. With the possibility of IP traffic over JANET, more users will prefer this route.
The mailers' testing and fall-back procedures still do not seem satisfactory. On one occasion when a change to the mailers went wrong, it took several days to successfully fall-back and valid mail was being rejected on USA-order names. Since the full text was returned to them, users encountering this problem were able to use the UK ordered names and get through.
The number of countries contactable by email continues to grow, the USSR, Hungary and Egypt are recent discoveries. The Egyptian support person visited UCL and asked me about email access; they have reached a few JANET sites successfully since. Egypt also connects the Saudi GULFNET to BITNET.
The mailer still rejects a lot of mail and clearing the dead mailbox is still a considerable chore. Forwarding dead mail seems to be more useful than waiting for complaints. When gateway support sees the actual error, it is possible to write advice about that particular problem and not generalise: Most time was previously wasted because inquirers did not save evidence.
The next release of the mailer should be ready soon. The lack of it is very visible to regular users. When it is installed the divisional nameserver tests can commence.
The arrival of the Cisco IP router will allow many more people to get good access to UNICOS.
The UNICOS migration will no doubt produce a heavy crop of user queries about job submission, output retrieval and interactive access.
Component Major Minor Traffic passed Traffic number
incidents Mbytes/quarter Calls /quarter
Local
CPSE 2 2 12,302
SEEL 1 n/a n/a
PADs 3 10
PACX 0 0
Lines/modems 4 9
Muxs 3 11
Backbone LAN
H/W 0 0
S/W 0 0
CCD LAN
H/W 0 0
S/W 0 0
JPSE 4 4 50,793
Lines/Modems 16
VMNCPE
Auscom H/W ? ? - -
Auscom S/W ? ? na na
370E
Auscom H/W ? ? - -
Auscom S/W ? ? na na
H/W ? ? np np
PIXNET
PIXNET H/W ? ? np np
PIXNET S/W ? ? - -
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 - -
IBM
4705 h/w 0 0 - -
VTAM/NCP/NPSI 8 6 na na
VMNCP total 6 3 - -
Network/3270 0 3 2400 62000
Line-mode 0 0 1000 49000
SSMP 0 0 65 900
NIFTP 0 0 13000 1300000
JTMP 0 0 550 16000
CMS-PAD 0 Some 80 42000
IBM Ethernet
VMNCPE total 0 0 - -
Network/3270 0 0 120 3000
Line-mode 0 0 5 500
SSMP 0 0 0 0
NIFTP 0 0 220 1800
JTMP 0 0 0 0
CMS-PAD 0 0 0 5
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.
The EARN traffic operated via a 9.6K channel on the HEP CERN link.
There is a 9.6K line to CERN which connects UKACRL via GBGBOX, the Northern Telecom switches, CHGBOX, to CEARN which was used for testing the NJE/X.25 link.
EARN has to vacate the HEP line by April 3.
Advantages.
Disadvantage.
Long term effect
Advantages.
Disadvantages.
Long term effect
Over the last week traffic has been moved bit by bit to use the X.25 connection and this has so far shown no problems. At the moment almost 100% of the traffic has been moved.
The NT switch hardware is maintained by Northern Telecom but there is no contract at the wish of NT. This is done free of charge. On the other hand the switches have yet to fail and there are plenty of spare parts.
The GBOXes are maintained by DEC during normal working hours. Again the GBOXes have yet to fail.
It has to be remembered that most parts of EARN to not have night and week end cover and such cover at RAL on this equipment could give a false sense of security.
The NT switch configuration is maintained by the EARN OSI Centre in Amsterdam. The GBOX tables are maintained from Amsterdam. RAL has expertise in both these areas but would not expect to use it in normal circumstances.
Documentation for the NT switches and GBOXes exist but is untried and still under development.
We need to decide whether to retain the status quo of leaving the EARN traffic using X.25 or to revert the line to BSC.
There are two fall back position should disaster strike. The line could be moved to BSC at a few hours notice. The traffic could be moved back to the HEP line although this fall back position is only available for two weeks.
There is a need for central output services with expensive, high volume, high quality, or other special output devices which cannot be justified in several places. These services are poor where output is required quickly.
Thus there is also a need for output services strategically located about the site for quick delivery.
Some users require private output services.
There is a need to output services remote to Rutherford both within JANET and elsewhere (DESY).
Currently there are about 25 Laserjet printers on site and 5 at Swindon. This number is likely to double. There are also output facilities associated with VAX machines which are under departmental control.
Applications operate devices via drivers. Drivers "know" the details of a device. With remote devices the principle should be that the driver local to the application still knows the details of the device and the communications channel is a bit stream, spooling. The code actually operating the device merely makes sure it is working properly and does not look at the data.
TCP/IP and a PC based server now exists. Current testing shows that files can be printed from XPRINT, VAX VMS, UNIX, and other PCs systems. PROFS printing is not (yet) available. The use of the system for non simple devices needs investigating.
SNA based servers are based on coax 3270 cables and possibly token ring. This allows a good service from the IBM to IBM devices (and non IBM devices?). Service from other machines (VAX VMS, PCs on ethernet, and UNIX) must go through the IBM. Although VAX VMS, PCs, and UNIX systems all have SNA code it would not be sensible to have all these machines on SNA and other networks.
DECNET provides output facilities which in principle could be used by other systems. Already the IBM exhibits DECNET and products can be obtained for PCs.
The use of X.25 Coloured Books only provides the PAD printer service which has not provided a particularly good service. On site there seems no reason for using this technology. Off site on some JANET sites there may be no option.
Dear Mr. Bartlett,
I have been asked by my management to investigate the possibility of connecting my site to the Government Data Network.
The Rutherford Appleton Laboratory is a station of the Science and Engineering Research Council and therefore its funding is from the Department of Education and Science. Its purpose is to house various large scientific resources which are available to academic institutes. We also collaborate in a number of international programmes with similar overseas organisations and with the European Commission.
In our work we have close relations with other government organisations in particular the Department of Education and Science, the Department of Trade and Industry, Chessington Computer Centre. Other establishments are accesses on an irregular basis.
I have some technical details of the network from Racal Data Networks Limited and I am confident that there are no technical problems.
At this stage I would appreciate an indication of whether we would be allowed to connect to the Network and under what conditions.
Yours Sincerely,
Paul Bryant - Head of small systems and communications group.
Dear Mr. Morgan
Further to my recent telephone call and a discussion with Stu Warford I am pleased to inform you that we are prepared to give to access to EARN via our facilities at no cost.
I attach a form which i would ask you to complete and sign.
You will have to organise your own access to the IBM computer at Rutherford. We can offer 2400 dial up access and I enclose details. You may also be able to gain access to the facilities at a local university which would reduce your call charges. All universities have access to the JANET network and thus have access to our facilities. I understand that you wish to use an IBM PC and I therefore enclose a floppy disc with a programme which will allow dial-up 3270 access to our facilities either directly or via facilities in a local university. The documentation is on the disk.
Yours Sincerely,
Paul Bryant - Head of small systems and communications group.
The "Communications and Small Systems Group" of the Central Computing Department provides general technical support service to various groups using small computing systems. Currently the service covers VAXes and PCs systems. Support is provided for systems on the Rutherford site and for systems provided by SERC to Universities and other research establishments. The support of the networking systems on these systems is of particular importance.
This vacancy is to permit the group's support to be extended to cover Unix systems.
The purpose of the post is to provide technical and management support as well as an advice service for small Unix systems to enable them to be effectively exploited by the scientists. This will be initially for systems located on the Rutherford site. The support of the effective networking for Unix systems will be a priority.
The objective is to instigate and build up the Unix support services being provided by the group.
The duties of the post are:
Applicants should have a good knowledge of the Unix operating system in particular in the areas of management and networking. A knowledge of the IP family of protocols would be an advantage. A helpful disposition is essential. Training will be provided to suitable candidates.
Dear Mr. Hemingway,
I enclose the EARN Charter and Code of Conduct which control the use of EARN.
I also enclose a document which describes how to use EARN from within the UK academic network JANET.
Whilst I am able to give permission for you to use the EARN Network you will have to approach Ian Smith of the Network Executive who is in the same building as myself.
As we discussed, the best method of access at this stage would be for you to use dial up to our facilities here. We can supply suitable code free of charge for an IBM PC to allow the PC to imitate an IBM 3270 terminal which is the only sensible way to use an IBM computer. We will have to charge you for any computer time used and I enclose a form you will have to fill in. I suggest that at this stage you set a ceiling of 500 pounds on your expenditure to see how it goes.
Yours sincerely
Paul Bryant.
Present - P Bryant, G Robinson, A Jessett, J Leak, J Hart, P Jeffreys, P Girard, and J Gordon.
NPNCG are interested in IP links to CERN and DESY and require a technical report from CCD at their next meeting on June 14.
The long term intention is to upgrade the CERN link to 128K (or more?) and operate the DESY traffic via that link and a 2M link from CERN to DESY. Thus any use of the DESY link for IP would be for about a year. This CERN link would probably be split four ways between IP, DECNET, SNA, and X.25.
Currently the CERN 64K link is split BSC, SNA, DECNET, and X.25 but the BSC and SNA will probably combine as soon as SNA is fully tested. NP is reluctant to split the link more than three ways to avoid loss of performance.
Currently the DESY 19.2 link is split RSCS, PVN, and X.25 but this will shortly change to SNA 9.6, DECNET 7.2, and X.25 2.4. The X.25 is needed to support a small number of terminals.
Technically IP can be run over SNA, X.25, or native. It cannot run over DECNET.
There is no problem with MVS operating at DESY and VM at Rutherford as FAL operates on both. It may be possible to remove the X.25 connection if the terminal traffic can find some other means. Certainly SNA/3270 or IP may be possible means. Thus the use of X.25 is not attractive. There is reluctance to provide native IP in the interests of conserving bandwidth at least until a demand for IP is established. Thus SNA seems to be the front runner.
The attitude of DESY is now known as P Bryant has contacted Hans Frese to find out their attitude to the various IP possibilities.
With CERN the situation is not so clear as the X.25 connection is better established. The attitude of CERN to an IP connection is not known but it is believed that CERN may charge for a dedicated connection into their CISCO router or a shared one via X.25. P Jeffreys will ask Francois Fluckiger.
It would be possible to operate IP across X.25 from a CISCO (or other) router and in fact the IBM can act as a router. This allows a number of opportunities. It is the CCD view that if possible switching should not take place in the IBM computer as this is a waste of resources and also gives a less reliable service.
Hans agrees that line to DESY should not be further split and should be phased out and the money put to wider bandwidth connections to CERN.
It is better for UK IP traffic to go via CERN to DESY as this simplifies routing and is in line with the view of having a small number of "fat pipes" across Europe and it will cost less. CERN to DESY IP now exists.
Finance for the use of the CERN DESY link will/may be needed possibly via HERA operating expenses.
Currently there is no CERN DESY SNA but this should be possible by the end of the year. DECNET will also be possible.
They would like to see "special" or "RAL" terminals scrapped at DESY.
CERN would prefer a UK IP connection to be on a dedicated connection or channel. Their second preference if for a connection over X.25.
IP over SNA is not recommended.
HEPnet recommend the use of CISCO routers for a dedicated or X.25 connection. There is a small and as yet unknown connection fee.
CERN would support a 128K RAL-CERN connection and there would be no cost for relaying traffic to DESY and elsewhere.
Unknowns
What is the cost of using a CISCO at CERN?
What is the cost of using the CCD CISCO?
Will DESY raise any charges for the use of their terminals or terminal ports?
The LINOTRONIC is a device for producing off-set litho plates. It accepts POSTSCRIPT files via RS232 or Cintronic's interface.
The device is connected via an RS232 interface to a SUN operated by Informatics Department. This provides a spooling system. The SUN is connected, or is capable of being, connected to an ethernet.
The spooling system in the SUN allows the operator to change the order in which files are output to allow some prioritization.
There are two problems known.
It is understood that John Cullen is still developing the system and that apart from the above problem the job is largely complete.
There may be problems with leaving the SUN next to the LINOTRONIC for ownership reasons. If moved then the LINOTRONIC operators would loose control of the device.
There is no reason to suppose that the project cannot be a success without evidence to the contrary.
There is a possibility that an IBM PC connected to ethernet and with a Cintronic interface to the device could drive it. The code exists with the current work on providing print stations. Some investigation would be needed to see what, if any, problems exist.
The PC spooling system has no facilities for reordering the print queue. In addition it has no facilities for splitting files into 15 page chunks although the use of the Cintronics interface may overcome that problem.
If CCD were to take over this project then it would be difficult to utilise the system so far developed as there is little experience of SUNs at that level in the Department.
If the project were to be moved to a PC then there are dangers that it could be open ended in that there is no specification of what exactly is required and what ongoing support is expected. There may be problems in the approach suggested that could cause much effort being expended.
It may be appropriate to have a look at the device and the documentation and to do a quick feasibility study. A few hardware checks could be done. This could be in the guise of evaluating the POSTSCRIPT offered in a rather direct way.
The EARN service is provided by the following route:
+--------+ +----+ +------+ |IBM 3090| |VAX | | NT | | +-NJE/BSC-9.6K-+ +-NJE/X.25-9.6-+ +-X.25 to EARN-9.6K |UKACRL | |GBOX| |Switch| +--------+ +----+ +------+
The Northern Telecom switch is connected to CERN and thence to switches at Montpellier and Amsterdam where there are GBOXes.
The connections are congested.
The NT X.25 network is likely to be phased out and the connection will be via the IXI network. Testing of this route is now under way.
The current GBOX to JANET (via campus GEC switch) is 9.6K and will be a bottleneck.
The proposed solution to the problems are:
RAL is taking part in the testing of the IXI network and traffic will not be moved onto this network until there is satisfaction that the connection is reliable and performant. Connections between the IXI network and the other parts of EARN will have to be satisfactory.
Minor effort will be required for the connection of the GBOX to the SEEL switch.
Some effort is needed to mount VMNET. The amount is unknown and Tim Kidd has the required expertise.
The project is in line with the policy of making local connections via the ethernet.
The project is in line with the policy of moving to a small number of X.25 connections to the SEEL switch.
When mail arrives from the wide world at the VM machine EARNGATE and it is destined for UK.AC.RL.IB (or its aliases) it is delivered if the userid exists. If the userid does not exist the name is searched for in a list of "names" against "name@addresses". If the "name" is found then an address substitution takes place and the mail is sent to the "name@address" found in the table. If no match is found then a set of fuzzy matches from the list is compiled and returned to the sender.
The list of "names" against "name@addresses" is extracted from the site database and this is augmented by a list of "special" entries. The special entries are used for a variety of purposes. For example, friends of Rutherford, forwarding mail for distribution lists on RL.GB, and technical reasons to do with distribution lists on LISTSERV.
The system is now operational and appears stable.
The list of "names" against "name@addresses" is a replication of the list which existed under the previous version of the mail system.
Tests have been run to demonstrate that this list can be generated from the site database.
No live tests have been run using data from the database.
No operational procedures have been set up to compile the list either every time the list changes or on a regular basis. In addition the development of the database is not quite complete.
There is a minor problem in that when names are provided from the data base then any corresponding entries in the existing list will have to be removed. This is a manual process but fortunately the existing list is quite small.
The number of entries in the site database is about 230 from CCD and ID. It is the same database that is used for the X.500 project. It is therefore feasible to construct the list from the data base and check by eye that it is correct. This can then be used. The user will find that names that currently work will still work as people who have multiple names in the existing list will still retain the alternative names to avoid any disruption (at least for the time being). The only difference will be that there will be a larger number of names available.
The EARN side of the gateway (MAILER) is complete and will be put into use when EARNGATE is stable. This will have no effect on the name server.
There are a number of minor enhancements which also await stability. These include:
An informal subgroup consisting of P Bryant, G Robinson, A Jessett, J Leak, J Hart, P Jeffreys, P Girard, and J Gordon had a meeting to discuss the possible options for an IP link to CERN and DESY. Discussions have been held with Hans Frese of DESY and Francois Flukiger of CERN.
No consideration was given to the need for such a connection.
Should an IP service to CERN and DESY be required then it is recommended:
2.1 There should be no direct IP connection to DESY
2.2 An IP connection to CERN should be established over an existing X.25 channel of the 64K HEP line. The connection should be to CISCO routers at each end.
2.3 IP traffic to DESY should use the IP connection recommended in 2.2 and the existing CERN to DESY IP connection.
2.4 The RAL CERN IP connection should be reviewed in the light of the growth of traffic and/or when a broader band connection to CERN is provided.
3.1 The connection to DESY is expected to be removed within a year and it would be inappropriate to mount new services on this connection. The link is at 19.2K (currently 4.8 NJE/BSC, 4.8 passthru/BSC, and 9.6 X.25 which may change to 9.6 SNA, 7.2 DECNET, and 2.4 X.25) thus the X.25 connection is too narrow, subdividing further to provide an IP channel would damage services, and IP over SNA is not recommended. DESY support this view.
3.2 The CERN link provides five channels carrying NJE/BSC, SNA, DECNET, X.25 ECITE and X.25 JANET. The BSC connection will soon be removed by migrating the traffic to SNA. There is reluctance to subdivide the line to provide an IP channel as this could damage existing services and it may be that the IP traffic is initially low. Operating IP over SNA is not recommended as the use of relatively unreliable central computers for switching provides a poorer service and wastes CPU resources. A further benefit is that the popular TN3270 protocol can be used directly from suitable terminals. Thus the recommendation is to operate IP over the existing X.25 connection. The connection to CERN would be via CISCO routers at RAL and CERN which would in turn be connected to the local ethernets. The equipment exists at CERN and RAL although the RAL equipment is currently used for test purposes. CERN state that a connection could be provided at two weeks notice. This view is supported by CERN.
3.3 If IP is required to DESY then this can operate via CERN and the already operating CERN to DESY link. It should be noted that a large IP network has been developing in Europe with wide band connections between major locations and a single connection into this infrastructure of good bandwidth is preferable to a number of minor connections. In addition a number of minor connections tend to complicate the European IP topology. The CERN DESY connection may be used free of charge.
3.4 The use that IP will receive is unknown. If it turns out to be light then the utilising X.25 will suffice. If it turns out to be large then there is a case for having a channel dedicated to IP in the interests of increasing efficiency and reducing the interference between various uses of protocols. In addition the installation of a wider band connection to CERN will also provide an opportunity to reconsider the situation. Such changes would probably have no cost implications.
4.1 CERN will make a charge for the use of their CISCO router. This is unknown but will be small.
4.2 As the RAL CISCO router is being used for testing there is no guarantee that it can be used for CERN traffic. If CCD did allow it to be used an availability date cannot be given although tests should be complete within two months.
I attach a few more details of the VMNET product.
Currently all our European Academic Research Network Traffic goes to Europe from the IBM computer via a VAX computer via an X.25 network to CERN. The traffic is about 2Gbytes a month and is an important service.
The capacity is controlled by two bottlenecks. The first is the 9.6K connection between the IBM and the VAX and the second is the 9.6K connection between the VAX and CERN.
The connection to CERN will be dropped in favour of a 64K connection courtesy of JANET.
The IBM to VAX connection cannot be made faster with the installed hardware. The preferred option is to operate the traffic between the two computers over the ethernet local area network which now pervades the site. This requires a software package on the VAX and a corresponding one on the IBM. The VAX package will be supplied free of charge by DEC. The IBM package is VMNET.
This is a unique software package and there are no other venders. The package has been produced specifically for the academic community and the charge made is to enable it to be maintained and for handling.
The package will only be used on our IBM and is invisible to the user.
I hope this helps.
Paul.
UK prices for a VAX for the EOC ex-discount ex-VAT. Educational discount would be 35%
Microvax 3100 with 8Mbytes 17,000
plus software ?
If a half inch tape drive is required a Q-bus machine will be needed
Microvax 3300 with 12Mbytes 29,000
X.25 device 4,000
Tape drive 10,000
======
43,000
plus software
If developing and testing software that requires a separate VAX, then the management becomes more of an issue, say 1/2 man year.
Small VAXes do not come with round tapes, only DEC cartridges.
Management of organising software and hardware maintenance needed.
If used as a service then management would grow. Once people see a VAX, they will want to use it for document production and mail etc.
1,3 "There is a demand", "Develop utilities". Need justification. How many VAXes etc.
2 "Orsay should offer the service". Should they? >
4 "To provide support a local VAX is an aid". Yes.
5 "Demands are complex", but only a minimal effort on "small" VAX. Explain.
6 What is "moderate price".
The case made out is not good. Specific questions are:
You are aware that the Particle Physics Network Group wishes to establish a pilot IP link to CERN across IXI. Other groups in Europe are using workstations via IP connections which the UK would like to investigate.
This connection requires permission to operate IP from our CISCO router via JANET to the IXI connection point and the registration of the CISCO router in IXI.
It is expected that the CISCO testing will be complete in a couple of months when it is envisaged that this connection would be made.
I have already spoken to you informally but now I ask for your approval? An early decision would be appreciated so that firm or alternative plan can be drawn up.
Thank you. Paul Bryant.
A long time ago the JNT "White Book", defining the transition to use ISO protocols", was approved and published. At the time there was much optimism that this heralded a move to a single set of network protocols across Europe. The UK would be well placed with this document to take an early advantage of such developments.
Whilst the production of the document gave much insight into the problems of a transition it also showed that there was much work to be done. Indeed, much of the work has taken place with developments in the Name Registration Scheme, significant progress with X.400 and now X.500. None the less the seemingly obvious objectives of that era have taken a battering from the external winds.
The pace of developments of ISO products has been slower than expected. In part this is due to the inherent complexity of the protocols and the resultant requirement for functional standards to ensure interworking. In part this is due to the popularity of the IP tranche of protocols made popular by their use in the States and the wide availability of cheap reliable and easily mounted products. At Rutherford it has been found that products exist for all popular machines and in many cases there are several good quality products which are sometimes free.
The popularity of IP has been more marked in the rest of Europe where networking has been less cohesive or well organised than in the UK.
There now seems an inevitable result that networking will increase in complexity with the need to support both the Coloured Book with a transition to ISO connection protocols as well as IP with a possible transition to ISO connectionless protocols.
The development of a European X.25 inter-country network, IXI, also has problems. I have no doubts that it meets the needs of the 1980s. That is, principally mail with modest speed terminal traffic and some file transfer. The needs of the 1990s are moving in the direction of applications requiring higher bandwidths and more responsiveness such as X-windows and high speed file access. This has led to the RIPE organisation which co-ordinates IP across Europe which looks to speeds in the 2M range. Thus we see the two strands of networking developing alongside each other. Whether this is a case of yielding to market forces, a crass waste of resources, healthy competition, or evolution makes an entertaining debate but does nothing to alter the fact that Rutherford is now committed to supporting a wider range of protocol products than at any time.
1.1.1 JTMP Host-end Service
Version 3.1B has been very reliable. The ability to 'KILL' jobs submitted to the CMS jobmill (SLAC BATCH) will be added during September.
1.1.2 NIFTP
No significant changes.
1.1.3 NETJOB
Work has not yet started on this.
1.1.4 SSMP
Version 3.0D3 remains the latest version at RAL, ULCC and MCC.
1.1.5 Pink Book
No significant changes.
1.1.6 CMS-PAD
No changes. The current version is 2.0
1.1.7 AMDAHL 4705
This is now supporting only a number of BSC lines (RSCS, CLUSTER, PVM, etc) together with the Telex traffic.
1.1.8 IBM 3745
This supports three 64K X.25 links and a number of SNI connections. The software is at last in a reasonably reliable state, and only occasional problems are being experienced with the current production module.
Attempts to move the remaining EP links from the 4705 to the 3745 have been abortive: Addition of these links causes the 3745 software to go into a loop several times a day. IBM are investigating.
SNI links to CERN, JACS (Swindon), and MNS (for Dial-IBM) are in service. There are some technical problems with SNI to DESY, but it is hoped that this too will be ready for service shortly.
Access to MSA at Swindon is available from authorised RAL terminals.
The networking aspects of the JACS Disaster Recovery plan (whereby RAL will be able to provide back-up facilities) have been resolved in collaboration with Swindon. Swindon will be producing a paper.
The long-standing problem with the VTAM buffer trace has been solved. Some fixes have also been received in connection with the NPSI Fast Connect feature, but these have yet to be tested.
New releases of VTAM and SSP have been received but not yet installed. New releases of NCP, EP and NPSI are due to arrive shortly. With these releases it should be possible to eliminate all local binary patches to the IBM code.
1.1.9 VMNCP
Version 6.8 remained in service throughout the period, and has been largely trouble-free apart from the need to 'un-stick' it occasionally due to a known problem in CP. Very occasionally, virtual store seems to fill up with undelivered VTAM buffers, causing a temporary hang of the virtual machine. This is being investigated.
1.1.10 RSCS
The RSCS rationalisation has continued with a number of milestones being reached - RSCS V1.3 has been removed from service and the main RSCS node (UKACRL) is now V2.3 running in the RSCS virtual machine.
We have only two links in use on the V1.2 (VNET) virtual machine: (1) The 3741 in R20 which is due to cease service at the end of August; (2) The AES word processor used by Laser Division which has no fixed termination date yet.
IBM has at last delivered an update for RSCS V2.3 which is correct (the previous three updates have all been 'in error')! This will bring us up to V2.3.05 from V2.3.0 and should be installed during September.
1.1.11 TCP/IP and the IBM 8232
Version 1.2.2 of the software has been delivered. Local modifications are being installed and the new version is due to deliver a production service at the beginning of September.
Initial tests on the new software indicate that the NFS component is still far from satisfactory. A production system based on NFS seems a long way off.
A Trainee Scientist (Milos Rodic) is working on the TCP/IP software for six months. His work will enable us to bring the development line printer spooler and server (LPR and LPD) to a production status.
1.2.1 Phasing out of the Amdahl 4705 by moving the remaining EP-based equipment to the 3745.
1.2.2 SNI link to DESY should replace the two BSC links. Other SNI connections may be needed.
1.2.3 Completion of the Pink Book interface.
1.2.4 The support of mail over TCP/IP should be investigated, particularly with reference to providing a gateway to JANET and EARN mail for PC based users.
1.2.5 The RLVM370 RSCS node (VNET virtual machine) should be removed from service, giving a "standard" RSCS service based on one node.
The latest IBM Announcements (early September) need to be studied. Clearly any future products for OSI will be supported under the new operating system rather than under VM/XA.
2.1.1 Local.
Staff level still causes considerable concern, with Reg Barnard retiring at the end of June and the failure of the first recruitment exercise to fill all the vacancies, the section is still 3 people light. The two new recruits are now managing to do some tasks unsupervised.
A considerable amount of effort was expended on the Open Week, both in preparatory work and as guides during the week itself.
The period appeared to be busy but that could have been due to staff shortage, summer holidays, and training new staff rather than the number of problems reported.
The statistics on the various X.25 exchanges are not given in this report as we do not currently collect them from the SEEL and the Network Executive does not release them for the Netcomm, therefore any details given would be incomplete and meaningless.
* ESAnet lines have been installed to RAE Farnborough and Kleinwort Benson Bank in London. However neither has yet been brought into service. ESA have been requested to support a PROFS over SNI over X.25 link for RAL - this they have agreed to and have chosen ESTEC to be the connecting site - no timescales are available as to when things will happen.
* The GPT switch (CPSE) had three problems during June. Two due to system errors which caused an automatic IPL, the other due to a faulty fan causing the system to shutdown. July and August were trouble free.
* The SEEL switch had no unscheduled outages. However some routing problems did cause problems early in the quarter, and tests for the CISCO router to run 1024 byte packets proved fruitless. Currently we are awaiting SEEL to install a XIO board to support a 2Mb link into the JANET Netcomm switch and install new software to bring us up to date and hopefully support 1024 byte packets.
* PACX had suffered a hardware failure causing the lost of half of the system. The problem appears to be Power Supply related and has not yet been satisfactorily cured, however users affected have had their connections moved to the working half.
* The level of PAD faults has been considerably lower this quarter, but three had to be returned to Camtec following power supply unit failures.
* A Camtec PAD has been set up for the ATSR project to allow their Spider Router (IP) and VAX to be connected to their PSS line at the same time. Initial test suggest that the throughput is better - So Camtec cannot be all bad.
* There appeared to be more BT faults than normal in the quarter, although none had long outages. The CERN line was affected on three occasions with faults on 'high order' links in Germany, and the Swindon Megastream on two.
* Ethernet has been reliable as far as hardware is concerned. The FF problem on the DEC bridges has now been fixed and all bridges brought up to date. A clash of IP addresses between two systems caused havoc for the IBM- IP service for a number of days.
* The line to TRRL has now been changed to a permanent connection. A 64K Kilostream line has been installed to The Cosenors House and a 9.6K line is on order to go to the Wessex Institute.
2.1.2 JANET
Another busy period with numerous line problems.
* More traffic is now going over the Netcomm switch as this now has Trunk links to BUCS and ULCC in operation. However some problems have been experienced with fallback routing looping round a number of switches, and with a hardware failure of the main MSX board. Attempts to connect the RAL and ULCC Netcomms together via a G703 interface over a Mercury circuit have been shown wanting - Netcomm are due to visit RAL to investigate the problem. A NGS system has been installed and gives graphic representation of the network - the value of this is still being investigated.
* Mercury lines to OCLC in Birmingham and to ULCC for the Fatpipe connection have been installed. The OCLC one has been back to Mercury a few times due to problems and the one to ULCC, not yet in service, is not that good. Mercury time to fix faults leaves a lot to be desired - a line to Daresbury was down for a couple of weeks as they decided what they could and could not do, it also took them 6 hours to respond and fix a faulty power supply in the mux at RAL. Mercury have been informed of our feelings on the service they provide.
* Another GDC multiplexor has been added to the network, this one at Cambridge. Problems were encountered when attempts were made to downline load the software from RAL to the Cambridge mux - it turned out that the Mercury line from Cambridge to ULCC had bilateral loops on. (Thank you Mr Mercury)
* There have been a higher number of faults on BT lines than normal. Most dealt with fairly quickly, on the digital side they were mainly due to faults in the Higher Order equipment, however we did have one outage of 90 minutes when the Mux at BT Oxford had a power problem. The number of analogue line faults that are returned with NFF is still too high for my liking - BT are aware of this and say other customers have expressed similar concern.
* The GPT JPSE still suffers from failures of PCC boards/codes and this often causes an IPL to regain the affected lines.
* Installation of XIO board on SEEL and 2Mbps from SEEL to Netcomm
* Rationalisation of RAL to JANET connections and routing.
* Maybe RAL ESA PROFS connection.
* More hardship as junior staff go to College.
* More staff.
* Statistics gathering program for SEEL.
* Ethernet monitoring equipment.
* Better ethernet stats collection program.
June saw the retirement of Reg Barnard, who handled the repairs of the movable terminals. At the moment there is no replacement for him so handling of these terminals has slowed dramatically.
Tenders from six agencies were received for the maintenance of fixed and movable terminals for the next three years. It was decided that Kode should be awarded both parts of the contract. In an attempt to stream-line the working of the new contract, all units will be badged with a 'device-no.' before repair and registered on Kode's database, when service line has been informed of the fault. In general only complete units will be dealt with, to ensure the fault can be observed by the engineer.
The faults figure is once more down, 108, despite a rash of burnt out PSUs during the hot weather. The sub-section staff repaired 28% of these the remainder was handled by the agencies.
The distribution of agency repairs is as follows:
Last qtr. This qtr.
MSM 20 23 Movable terminals
KODE 56 42 Non-movable terminals
SIGMEX 1 1 Sigmex terminals only
OTHER 8 14 Warranty repairs
The 108 faults have been analysed for divisional distribution. Of this total, 21 (19%) were CCD and the remaining 81% for other RAL divisions.
____________________________________________________
| | REPAIR AGENCY | |
|Division |_________________________________| |
|-Project | TCOM | MSM | KODE |SIGMEX|OTHER| TOTALS |
|_________|______|______|______|______|_____|________|
| ADM | 3 | 1 | 9 | | 2 | 15 |
| CCD | 5 | 4 | 6 | | 6 | 21 |
| CO | | | 5 | | | 5 |
| EBW | | | 1 | | 1 | 2 |
| INF | 2 | 1 | | | | 3 |
| PPD | 3 | 7 | 1 | | | 11 |
| RCR | 1 | | | | | 1 |
| SCI | 5 | 3 | 6 | 1 | 2 | 17 |
| SL | 2 | 1 | 2 | | | 5 |
| SPA | | 2 | 4 | | 1 | 7 |
| TEC | 7 | 4 | 8 | | 2 | 21 |
|_________|______|______|______|______|_____|________|
| TOTALS | 28 | 23 | 42 | 1 | 14 | 108 |
|_________|______|______|______|______|_____|________|
The new contract commences on 1st October and it is hoped that a smooth amalgamation of the two parts will be seen.
It should be noted here that any spare terminals that CCD holds have been provided by CCD and INF departments and are loaned to other department on a good-will basis. The variety available is limited, for example, CCD does not have any Cifer T2000 or Pericom terminals.
Quite a lot of time was taken up with office moves involving extra cables, usually coaxial for full screen devices, as well as moving connections from one device to another ( e.g. DECservers and PADs ) The optical fibres laid to R2 & R20 were terminated.
The ISIS village was connected to the Site ether backbone.
The Private wires to TCH were swung to the terminal room in the new building.
Wiring was provided for the Open Days including telephone extensions, ethernet and coax for full screen devices.
Thin ether was installed in the R25 Lab. Spectroscopy Area.
Costs were given to EBWU for an ether village in R18
One of the thin ether segments in R20 will be extended.
A thin ether segment in R1 will be extended.
A thin ether segment may be installed in R66, plus sixteen coaxes for full screen devices and cables for RS232 devices.
The Techelec village ether in R25 will be re-routed.
Wiring may be started in TCH to provide ethernet between devices in the conference rooms.
The six monthly Supply Cable Check will be carried out.
Various coaxial cables for full screen devices will be installed.
X.21 links may be installed to R25 and R1.
Terminals for various conferences at RAL and TCH will be set up.
Office moves will continue.
5.1.1 Network Software
An update of the WAN Device Driver Kit (V1.1A) was released in July. This release provides the device support for all new VAX processors and communication devices but does not contain any additional functionalities since V1.1.
There was an update of PSI (V4.3) and PSI Access (V4.3) in mid-August. This release allows VMS files of any type to be sent between two VAXes running PSI as mail messages using PSI-MAIL. It also provides fixes to some of the problems reported.
The PSI 4.3 kit has been distributed to the members on the joint network software maintenance contract.
The problem mentioned in the previous quarterly report about a X.29 call to a LLC2 machine from a PSI Access host that results in crashing the connector host remains outstanding. This problem will be pursued further with DEC.
There is no change on releases of CBS, JTMP, and LLC2. However, there is a problem to those who install LLC2 V1.1 for the first time with PSI V4.3. The installation will fail due to the absence of a PSI file that LLC2 V1.1 uses to check for version compatibility. Further details can be obtained from the VAX Support Group.
There is a patch for VOTS V2.0 as used on the EARN GBox to fix a transport sequencing error that happens when a Transport Protocol Data Unit size lower than 2048 is used. The patch is for VMS V5.3+ and only shipped upon request.
A new DECnet registration program is now available to assist VAX managers to register machines in the RAL DECnet.
5.1.2 Network Hardware
There has been no change in network hardware on the Cray Front End, the Development VAX and the four VAXStations.
The EARN GBox (GBGBOX) has been registered to use the IXI network in June. The 9.6K link on the GBox to CPSE has been replaced by a 64K link to the Seel switch in late July. The new link provides significant improvement on data transfer. A data throughput rate of 30Kbps has been observed in one of the tests with a Dutch GBox over the IXI network.
The IBM connection for the GBox over the 9.6K Bisync line is understood was switched to 3745 from 4705 in late August. No obvious performance changes have been observed on the GBox.
The regular networking support of PSI with PSI Access , 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 have been some modifications on the updates for LAN machines accessing JANET via a Spidergate to cater for reverse addresses and TS29 calls from LAN. It is realised that TS29 LAN calls are regarded as inappropriate and are not supported by the Spidergate.
A few sites have recorded some attempts to log in as privileged accounts from DTE 000012110256 (Bradford) in late August. None of the attempts were successful. Nevertheless, the incidents were forwarded to Bradford University who has promised to investigate further.
The migration plan to upgrade devices like KMV-11 and DEQNA to those that will be supported in DECnet Phase V is on-going. The plan includes a possible trade-in of all KMV-11 on site for a X.25 Router. There are financial and technical issues currently under study.
With the connectivity to IXI in place, the GBOX will undergo further testing of its capability and efficiency for shipping data under different X.25 setup across the international X.25 networks.
The joint maintenance contract on PSI, CBS and JTMP is due to renew on 1st October. There are currently 69 machines on the contract and the sites concerned will be contacted to confirm the continuation of maintenance in next contractual year.
The above contract also includes hardware and software maintenance on all DEC machines at RAL along with software maintenance for most Starlink machines. The contract has over 300 separate schedules with almost 2000 items on it and will take a considerable effort to renew.
6.1.1 NJE
Some rationalisation of RSCS on the IBM.
6.1.2 File transfer between EARN and JANET
No change.
6.1.3 MAIL
Both MAILER and EARNGATE are using the new versions of the Crosswell mailer and the associated RAL code for service. This has removed a number of longstanding problems with mail that could not be dealt with. The mailers now follow RFC822 closely.
There have been a few teething problems but these have not caused significant problems and have mostly been solved.
Even with this version of the Crosswell mailer there are still instances of mailer looping. There are no plans to investigate this problem beyond reporting the fault to Crosswell and hoping that a future release will be better.
6.1.4 LISTSERV
A few updates have been implemented by the EARN LISTSERV centre in Turkey. One of these uncovered a table fault which caused some inconvenience.
6.1.5 EARN management
EARN has made a number of significant changes.
EARN now allows NJE to operate over any underlying technology such as BSC, SNA, IP, DECNET, or OSI. This gives some routing and topology problems which are being investigated by a group set up for the purpose.
EARN now uses lines provided by IBM as part of the ESANET supercomputer network. In particular the line to the States which has had a beneficial effect on traffic to there.
Developments are well in hand for the connection of East European countries.
EARN now has four staff members and there is some contention as to what these staff should do. On the one hand there is the view that they should do technical work and on the other that they should be engaged in administrative work in the support of the various groups. This has yet to be resolved. In addition to these four staff there is a further member donated by EARN France and a number of staff donated by DEC in Amsterdam although these latter staff are only partly undertaking EARN work.
6.1.6 Transition
As reported in the VAX section, the testing of IXI for EARN use is progressing. Regretfully the two main sites are RAL and the EARN OSI Centre in Amsterdam. All the other sites with GBOXes are taking a less active part. I am fairly confident that from a technical point of view a service could be provided at about the turn of the year. There are still questions on whether there is the political will amongst members to make this a reality. Although IBM EBOX work is now progressing, there is still a lot of planning needed, for example, to ensure that the interconnection between tradition EARN and IXI/EARN is satisfactory.
The development illustrates the difficulties that a service organisation, such as EARN, has in undertaking significant and long term development projects.
It has still not been found possible to mount the EBOX code. It is understood from GMD BONN that the IBM OSI products should work under XA although not supported. It is now thought that VSAM requires remounting.
6.2.1 NJE
VMNET should be ordered and delivered. This will connect the GBOX and IBM via ethernet and remove the 9.6K bottleneck and allow the eventual exploitation of the better IXI bandwidth.
Further work on mounting the EBOX code is expected and hopefully some test should be run.
6.2.2 File transfer between EARN and JANET
No changes expected.
6.2.3 MAIL
The name server should be obtaining its names from the accommodation database.
The mail development should be put on care and maintenance.
6.2.4 Transition
Further IXI testing of the GBOXes which are to concentrate on performance studies.
Some testing of EBOX code is expected.
There have been no problems with the use of the 'unsupported' configuration on the VAX front end during the Cray transition to Unicos. During August, the VAX and the IBM reverted to their normal connection, no longer using the Hyperchannel as a production route, it will still be used for development purposes and as a backup route.
Cray Research Inc at Bracknell have connected their Cray to the RAL Cray using Hyperchannel using a 64K Kilostream link. This is in fact an extension of the Bracknell hyperchannel and does not connect to the RAL Hyperchannel.
Further tests will be made to see if it is possible to run TCP/IP over the Hyperchannel from a VAX.
None
This is the first report on the use of the Interlink gateway between the DECnet world and the RAL IBM. This gateway allows any machine running DECnet at RAL (generally VAX machines, but there are a few PCs and MACS) to access the RAL IBM for both file access and interactive full screen logon.
A few obscure minor bugs have been found and reported to Interlink but have not caused any disruption to service.
The following usage figures are in Kilobytes. It is hoped in future to break down the usage even further between file access and interactive logons. Thus for the table below, the 'connects' column indicates the total of the number of logons and the number of file transfers.
The figures are not complete for June, as accounting was only started just before the beginning of the production service.
Interlink gateway usage June/July/August 1990 --------------------------------------------- Week end date Connects Kb in Kb out Kb total --------------------------------------------------------------- 10/6 612 14573 259893 274466 16/6 482 9478 38724 48202 24/6 588 31056 44793 75849 1/7 637 33971 62503 96474 8/7 661 134262 63470 197732 15/7 917 106654 149621 256275 22/7 895 140434 107211 247645 29/7 865 42194 111920 154114 5/8 630 24519 62811 87330 12/8 588 23083 54133 77216 19/8 881 30845 72590 103435 26/8 1625 32116 117465 149581 =============================================================== Totals 10245 763619 1174911 1938530 Average/week 853 63634 97909 161544
Enhance the Interlink statistics.
Longer term plans will be to interface the gateway to central services such as line printers, graphics hardcopy etc and to contemplate providing a batch submission service to the IBM.
The statistics for PC orders over the last three months were 63 orders placed, which included 49 PCs, and a total value of £128,578. This was rather higher than normal due to one order being for 30 PCs from RAL Finance. The PC total, including those on order, now stands at 415. As a result of this large number of orders and the additional demands of Open Day the resources of PC Support have been stretched to the limit. One casualty has been the newsletter and this is now unlikely to appear before November.
Negotiations with Science Department on the shortfall in their contribution for PC Support have so far produced an additional 0.1my from Laser which still leaves us 0.1my short. The PROFS community have been allowed to only pay half their costs this year. When this concession was made they have two staff on the PC side and thus made less demands on PC Support. The sizable increase in the number of PROFS PC's and the possibility they will be back to one person on the PC side means a significant increase in this contribution will be needed next year.
There is still no sign of a PC Administrator being recruited so that it has been decided to make use the services of the temp who is currently being shared between T Daniels and P E Bryant. Whilst this is far from satisfactory it should help reduce the administrative backlog which now stands at six months on some items.
A new recruit to PC Support, Chris Stratford, started in the last days of August. His limited experience means it will be some months before he can make a significant contribution. His arrival also means that PC Support are considering moving office so that the members are nearer to each other and to allow further expansion.
The introduction of the Tulip 386SX as the new RAL standard has been well received and over a dozen have now been ordered. This represents a £500 saving over the IBM PS/2 55SX though this differential has just been reduced to about £150 by recent IBM price changes. RAL Contracts are also doing a tender exercise for the supply of PC's and the result should be a further reduction in prices.
The arrival of the much hyped Windows 3 has meant a lot of work in evaluating it. As it effectively becomes the machine's operating system it must be able to run a wide variety of programs without problems. This has proved to not be the case, especially for communications systems, though work around are gradually being developed for most of them. It seems likely that the success of Windows 3 will seriously damage the market penetration of OS/2 and possibly Unix on PCs.
The project to evaluate the upgrading of XT and AT machines by installing a 386SX motherboard has proved very successful and examples of both are now in regular use. Initial problems on the AT version taught some valuable lessons. The price for such boards is very volatile and until it settles no one supplier can be recommended and each installation carries a degree of risk.
The development of the LOADSYS program to load and unload PC Device Drivers and Terminate and Stay Resident programs is almost complete. It now supports Expanded Memory Managers such as QEMM and EMM386 thus allowing programs to be loaded above the 640K limit. This highlights a limitation in the IBM PS/2 machines in that their extensions to the BIOS reduce the additional address space available by 64Kbytes compared to a Tulip 386SX machine. The software is now being tried by a real user (T Daniels) and so far has proved reliable.
Tests of the Cisco router have taken considerably longer than originally planned. This was due in part to having to rely on other groups to provide and change the facilities that were being used. However the major reason was the difficulty in understanding what was going on. This was not helped by having different equipment at each end of the X.25 link since the Cisco and Sun workstation use different algorithms for packet size and window negotiation, and also IP and X.25 fragmentation. The characteristics of the Seel and then the Netcomm switch also compounded the problem. It especially highlighted the need to fully understand the X.25 implementation of the switch particularly with regard to local or remote acknowledgement and support of the D bit. The present situation is that throughput appears to be limited by the 200 packets/second of the Netcomm interfaces. An upgrade to increase this limit is imminent at which point further tests will be done.
One of the aims of the Cisco evaluation was to test an IP link over Janet and also to evaluate IP routers from different suppliers. To this end the loan of Wellfleet's equivalent of the Cisco was arranged with the aim of testing it between RAL and Daresbury. It took RAL over three days and much reconfiguring to get the Wellfleet's rather unusual X.25 configuration characteristics to work with a RAL exchange and eventually it was persuaded to talk to the Cisco. A Wellfleet was also delivered to Daresbury but because it had a fixed Logical Channel Number range which the GEC switch would only accept as Permanent Virtual Circuits it was not possible to make it work. The tests were therefore abandoned and negotiations are now in hand to try and talk to a Cisco at UCL over Janet.
One of the features of TCP/IP on a PC is that most software uses what is known as the Packet Driver interface to communicate with the ethernet hardware. Such drivers exist for most ethernet cards including the BICC variants though the latter are rather new and not without problems. The Rainbow software for the PC however only talks to the propriety and very large Multiprotocol Support (MPS) driver of the BICC cards and therefore is unable to be used on other makes without special drivers being written. To improve this situation an implementation of the MPS interface which talks to the Packet Driver interface (LLCPKT) has been written by Kevin Hoadley and has had rave reviews in the PC networking community. At a stroke it has made the Rainbow software available to a vast array of ethernet cards.
The advent of LLCPKT means that RAL is able to buy other makes of ethernet card and to this end an evaluation of very cheap cards (less than £100) is underway. So far the results have been very encouraging with the cheap card giving a far higher throughput than that of the BICC card. Given that most of the TCP/IP and all of the Rainbow software is effectively free the cost of networking PC's could be under £100 per machine plus the cost of cabling.
One of the current limitations of the ethernet software is that although it has full screen 3270 emulators (TN3270 on TCP/IP and Rainbow on Pink Book) this does not support the INT 15 and EEHALLPI interface used by the PROFS PC systems for file transfer and PASF. Such interfaces are supported by the RAL emulator, MOS2. An evaluation is therefore underway to explore the possibility of running MOS2 over the ethernet and the first task has been to mount it over the PADPORT program which is part of the RAINBOW system. This works moderately well but as it takes a large amount of memory and it is policy to minimise the usage of Pink Book it is unlikely to be released to RAL users. It may however be of considerable interest to the academic community. A developers toolkit for the PC/NFS system is being ordered so that the possibility of using MOS2 over TCP/IP can be evaluated.
In response to requests from the academic community and RAL users an investigation into the support of PCLK by MOS2 is underway. This has proved to be possible though it currently only works over the ethernet version of MOS.
The evaluation of the LPD print spooler has reached the stage of a trial service within the CSS Group. Whilst the development system continues to function perfectly the trial service machine has shown several problems. Pressure of the Cisco testing has prevented further investigations.
The rapid approach of deadlines for the move to an IP Broadcast convention of all ones and the need to harmonise the User IDs and Group IDs on Unix machines has highlighted the lack of effort in the area of Unix support. As a temporary measure Kevin Hoadley is stepping into the breach pending a more permanent solution.
IP Broadcast convention will change to all ones and Unix User IDs and Group IDs will be brought within RAL IP Subgroup guidelines.
With the purchase of a PC/NFS site licence there is a need to gain experience in the use of such a service. It is therefore planned to either purchase an NFS server or make use of another server to provide this service to the CSS Group.
At least one further post in PC Support will be needed next year along with a permanent Administrator.
A new site requested an early table update (lon.barts.v1) while we had rerouted hw.cs mail at their request owing to problems between our and their X25 connections (packet size negotiation was in error): we eventually updated in time for a demonstration of EARN facilities at London after discovering that Heriot-Watt could avoid the problem after we had warned them not to originate FTPs from the IBM. In July a new update of mailer had a serious problem which prevented mainly mailing list access. After asking Finland for help in testing, Roger Westlake was able to detect and remedy the error. The service to BITnet sites rather than networks beyond BITnet was not completely halted, however the problem was very public and some LISTSERV maintainers abroad received rejected files for about four days. A new mailer (2.03 rather than 1.25, Princeton rather than Columbia) was installed and programs added to DEADMAIL to forward any valid RCPT TO: fields from either release - this worked and covered the update period: Before we went to 1.25, files from 2.xx were passed on via DEADMAIL, afterwards files from 1.25 were forwarded.
Using EXECIO * STEM , the DEADMAIL auto-forwarding EXEC now never uses more than 5 per cent of the IBM, even when the machine is empty and it receives a very large file.
I am leaving at the end of October. I have documented my system as a help menu on PO2 and DEADMAIL , since there seems to be no replacement yet.
Thank you for your EEPG questionnaire. The reply on behalf of Rutherford laboratory is:
The international lines are:
CERN speed 64K multiplexed SNI 14.4, X.25 9.6, X.25 9.6, DECNET 28.8 note - the two X.25 lines are for technical reasons to do with access to the CERN IBM computer. funding by UK High Energy Physics. use restricted to UK High Energy Physics. the utilisation is not known but the line is well loaded. an IP connection via one of the X.25 connections is planned. it is expected to increase the bandwidth to 256K when funds permit. the contact is Paul Jeffreys at Rutherford. DESY Hamburg speed 19.2 multiplexed SNA 9.6, X.25 9.6 funding by UK High Energy Physics use restricted to High Energy Physics the utilisation is not known but the line is moderately loaded the line is expected to be removed when the CERN line is upgraded and all HEP traffic will go via CERN the contact is Paul Jeffreys at Rutherford ESA line to .. Holland speed 64K X.25 to ESA switch at Rutherford. funding ESA use restricted to ESA topics - that is space and astronomy. the utilisation is very low the line forms part of the ESA network the contact is Dave Terrett at Rutherford. Link to Brussels speed 9.6 IBM cluster controller in Brussels. funding Rutherford use restricted to administrators accessing Rutherford IBM computer The utilisation is not known but is likely to be low the contact is Jed Brown at Rutherford
My private view is that Europe will have a connection and connectionless network for general purposes plus a peripheral set of special purpose networks such as ESA which or one reason or another do not wish to combine with others. The connectionless will undoubtedly be followers of what happens in the States and will hopefully but not definitely migrate to ISO/IP. I prefer and hope that the two networks will be largely controlled by the users and be responsive to their needs. The connection network should meet the requirements of the 80s for mail and modest speed applications while I hope that the connectionless will provide a little more performance. There is little doubt that users will want more performance and there will no doubt be new technology. Of particular interest to me is ISDN which will hopefully will allow 64K or 2M dial-up connections which I am sure the PTTs will provide at low cost?
To: John Burren From: Paul Bryant Date: 15 October Subject: ERCIM meeting
I believe Tim Kidd has been in touch with you concerning this meeting. Facts are hard to come by. The organisation is of the various Research Council like organisations that have got together with a view to joint research activities. There has been a network group which has so far done absolutely nothing. For reasons I do not really understand I got appointed to be the UK representative. Unfortunately I have an other meeting in Egypt that week and so we gave the job to Tim Kidd.
I guess, and it is a guess, that the aim is to see whether there are any network activities of a co-operative nature which the organisations could or should undertake. The way this is to be launched is with this meeting and the organiser wants each site to lay on a few speakers. Initially, when I was going to do it, I was just going to drag together a few topics and mumble for an hour and call it a day but this does not seem to fit the bill and we need to put together something a bit more plush.
The paper I enclose gives the range of topics that CWI will talk about which gives you some idea of what is going on. I think we should follow this. Clearly Tim can talk at length on what goes on here at a service level. Bob Day will talk about the Informatics part of the empire. The missing section is our research activities which are really your corner.
I am not sure what comes out of this. It may be funds but from where? It may be some joint projects but what?
You know better than most that there seem to be a plethora of networking activities/initiatives and I cannot see where this one fits in but no doubt we shall learn. It would seem that at least there will be some interesting people there and I expect the dinner and drinks will provide the real opportunity for some progress.
I hope you will be able to go or send someone.
Paul
The JNT have set up a Group (Department of Defence Advisory Group) DODAG to advise on the provision of an IP service for the UK academic community. They have produced a report (DODAG report). The JNT have subsequently produced a report "Policy for TCP/IP Services Over JANET" (JNT report).
While both reports suggest some use of IP, the extent, detail, and control of such use is different.
It is the opinion of Rutherford Laboratory that in general the recommendations of the DODAG report should be adopted where there is conflict.
DODAG recommend that ALL IP services should be allowed but that SMTP(mail), RPC (remote procedure calls), UDP and TCP (transport facilities) should be discouraged and Berkely services should be actively discouraged on security grounds.
JNT recommend that X-windows and ARPA FTP should be permitted and most other services strongly discouraged. JNT suggest that permission to connect will be subject to site agreement to the acceptable use policy as approved by the Computer Board and the NAC. It is unclear whether this is an existing paper but it does seem to suggest that "strongly discouraged" may be an effective ban. If this is the case it should be opposed on the grounds that the use of IP services, particularly to overseas sites, is far easier using these protocols than via gateways and converters. To effectively ban such activities puts UK customers at a disadvantage.
Recommendation - there should be no political ban on any service but only discouragement. There may be a need for a technical ban or control on services in the light of the use of IP but this has yet to be demonstrated to be needed.
DODAG had difficulty in deciding whether the router on each site should be connected to every other router, whether there should be a number of central routers to which all others connect or a hybrid solution should be adopted. This assumes all traffic goes via the JANET X.25 network.
Every site connected to every site gives the best performance and load on the network as it avoids traffic transiting the network by a number of hops. It has the supposed disadvantage of being difficult to control. With central routers the network can control traffic (and even filter banned traffic) at some loss of efficiency.
If an IP network were to be set up with dedicated lines then central routers would be essential to economise on lines.
Thus, if IP is always to run over JANET X.25 then there is some merit in having no central routers. If IP is expected to eventually run over at least some dedicated connections then central routers have merit.
JNT recommend that central routers be provided and that the use of dedicated IP connections is not recommended which would appear to be the worst of all worlds.
If one expects that IP traffic will be "substantial", say, every site has a connection and 10% of traffic uses such a route then it is likely that dedicated inter central router connections would be needed and high use sites may wish for a direct IP connection from the local to the central router. This seems likely which supports the eventual provision of central routers.
Recommendation - As suggested by DODAG the initial IP connections for, say, six lead sites should be provided with no central routers to enable a pilot service to be rapidly established. Provision should be made for central routers to which all sites should be connected but that these should be installed depending on the demand and in the light of further study.
JNT suggest that sites pay for a connection depending on bandwidth. This is outside the terms of reference of DODAG.
Such a procedure for a basic service is alien to the traditional funding mechanisms for infrastructure. If such charges are levied then it is appropriate to ask whether other bodies or clubs may be able to provide a more cost effective infrastructure. This move can only be seen as a method of discouraging use since it would appear that the costs of such a service which would accrue to JANET are small compared to their budgets.
Some of the cost is for the central routers which are, in DODAG's opinion, still a subject of debate and perhaps should be acquired one at a time as the need is established.
JNT suggest 3 staff are required whereas DODAG suggest two. The need for the extra staff is not defined. It must be also stated that the DODAG estimate is not supposed to be accurate.
In the costings the need for trunk line bandwidth and truck multiplexers (170K) is difficult to justify on JNT recommendations that traffic will go over the current X.25 network and be restricted. In addition it could be expected that the IP traffic will to some extent be a move from the current service plus some natural growth.
Recommendation - There should be no charge for connection and each site will have a right to a connection. The cost of local routers will be born by the site and central routers by the JNT. Sites which are currently charged for services by JANET are outside the scope of this recommendation. Because of the difficulties of recruiting staff the initial service should be managed by a consortium of the sites involved pending permanent staff.
JNT express concern over the impact of IP on the JNT transition plan. This is a real concern and the issue is whether the fundamental assumption that transition must be to ISO protocols over X.25 as the unique direction is still valid.
Evidence is that IP is very well established in the USA and is becoming firmly established in Europe. The corresponding European X.25 service is showing signs of slow acceptance and an uncertain future (cf IXI developments). IP also has a transition path to connectionless ISO protocols which is progressing at about the same pace as the connection variety.
Thus, it is arguable that the UK, in following an exclusive transition path, is restricting the services available to the customers.
The JNT suggest that the use of IP in the UK is temporary pending transition. An alternative view is that once established it will expand rapidly and meet a user demand which may be difficult to satisfy by other means.
Recommendation - IP should be seen as an alternative and legitimate service. IP has a transition path to ISO protocols and plans for such a transition should be established in conjunction with overseas partners.
As a result of the DODAG report, its acceptance by the NAC and its expected acceptance by the Computer Board we can expect to have an IP network across the UK.
This network is initially expected to be via the current JANET X.25 network and via a number, possibly 8, central routers. Each site will access the network via a router.
It is expected that there will be no restrictions on the higher level protocols used.
Currently DODAG is expecting to refine its report and study a few new areas. There are, regretfully, no plans for a project plan at this time. There is no date for any implementation.
Rutherford expect to take an active part in the implementation and this paper raises a number of discussion points were Rutherford may wish to express an opinion.
The expectation is that there will be domain name servers. No doubt one on each site. Should there be central Name servers? If so where should they be? Should we investigate and set up a site name server as soon as possible? If so should this be on the IBM or where?
It is expected that IP names will be the same as NRS names in reverse order. It seems unlikely that IP addresses will be registered in the NRS which removes the problem of extracting date from the NRS to the DNS but does mean that we will have to maintain the DNS ourselves.
The question is not such much "should we run a DNS", but developing a firm plan - what equipment, who looks after it, and timescales.
In the light of this development should we review our current IP naming policy?
No doubt the central routers will need some form of management. Should this be based on SNMP? Should the management extend to site routers and possibly to equipment on local networks? Should we run SNMP on our site network if so what equipment should it be based on? Would the use of SNMP be just an experiment or would it useful on site?
Currently there are no restrictions on site on the protocols used. On the expected JANET service some protocols will be discouraged, such as SMTP mail as the Grey Book service exists, and NFS on security grounds. What services does Rutherford want to encourage/discourage on the local network and on the JANET network?
We now have a connection to CERN and we are seeking registration with NSF and seeking to the EASINET link from CERN to the USA.
We are under pressure from James Hutton to make an IP connection via JANET and ULCC. Since we have asked for an IP connection via JANET and IXI to CERN it is unclear whether there is substance in this pressure and on what time scale it will be offered.
Will multiple IP connections cause problems? Should we encourage the termination of the CERN IP link in the expectation of an early connection via JANET or should we advise HEP to wait until such a connection is established.
Following (4), we currently have connections to Daresbury, Sheffield, UCL, and Imperial College over a variety of routers and bridges. What should we do to rationalise this situation? Should we insist on only having routers to other sites? Should we restrict the types of routers used?
There may be merit in Rutherford having early direct connections to selected sites on a pilot basis (Newcastle, Edinburgh, Bristol, ULCC, Manchester, ..). This would be undertaken pending the installation of central routers.
Should we press for such a project? Which sites should be selected? How should we negotiate for such a project?
Are there any steps we need to take to protect our network?
Currently we only have a high speed connection to the USA. It is unclear how a high speed connection to Europe should be achieved. It may be that an IXI link would be sufficient. It would seem preferable for a dedicated link to, say, Amsterdam or CERN. How do we achieve this?
Should Rutherford start on a project plan with other interested sites? Should we volunteer management as well as technical effort and if so how much? Without some aggressive action the project may take some time to mature.
Should we draw up a project plan for our private use on site which would have to match what we expect to happen on the wide area?
The terms of reference below have been produced by the group set up at the last Executive meeting. The Executive is invited to approve the terms of reference by way of an electronic vote prior to their circulation to the Board of Directors and the Network Operations Group with a request for participation.
At their meeting on November 8/9 1990, the Board of Directors asked for a "technical strategy and political direction" group to be set up with representation from the Board of Directors and technical experts. The group should report back to the Board electronically and also deliver a written report to the next Board meeting in Spring 1991.
A draft terms of reference will be drawn up by a subgroup of the Executive. The terms of reference will be circulated to the Board of Directors and the Network Operations Group with a request for offers to join the group.
EARN is an association incorporated under French law. The Statutes are in BOD21 89. Its membership is the sites connected. Each country selects a Director and the Directors form a Board who are responsible for the network. The Board elects an Executive which is responsible to the Board and is responsible for the day to day operation of the network. The regulations governing the use of the network are in the "EARN Charter" BOD30 90. The regulations governing the conduct of the Board and Executive are in the "EARN operational procedures" BOD64 90.
Originally EARN used dedicated lines. EARN was based on a tree structure based on Montpellier. This was dictated by the high cost of lines the store and forward nature of the network. The store and forward nature of the NJE/BSC protocol used allowed very efficient use of resources. In addition there were few other international resources.
The situation has changed. There are now many more lines and networks. EARN traffic is now carried over BSC, IP, SNA, X.25, and DECNET. It is carried over lines, often high speed, which are often shared. However, EARN is still based on the NJE protocol and provides services such as mail, LISTSERV, Trickle, and non-interactive access to databases.
The changing circumstances have resulted in several re-appraisals of the technical and political polices that EARN follows.
Initially EARN developed an OSI strategy and project in response to pressure and encouragement from CEPT and RARE. With a more liberal attitude SNA, DECNET, and IP connections have developed and as a result EARN has additionally allowed the use of these protocols to carry NJE. In the light of these developments, EARN's Routing Project Group is proposing to set up an NJE mesh topology based on a number of "core" sites many of which have good USA connections. The bearer protocols will depend on the networks and lines available. See "RPG proposal for regionalisation of EARN" EXEC121 90.
EARN has developed an "EARN strategic plan" BOD3 90.
EARN regulated the network via a series of "directives and recommendations" the regulations for these are contained in EXEC77 89. EARN controls change by its "management of change" EXEC103 89 which ensures that any changes are acceptable.
It is within this framework that this group is asked to report.
The Group will be an EARN "Project Group". The definition of a "project Group" may be found in BOD31 89 "Organization of technical work in EARN".
In accordance with BOD31 89 the Executive or Board of Directors may appoint members. In this case those appointed will consist of volunteer members from the EARN Board of Directors, and members from any EARN Group excluding EARN staff (in order to avoid conflict of interest). There will be no other limitations.
The chairman of the Group will be appointed by the Executive after consultation with the participants.
The report will be drafted by the EARN manager or under his supervision as directed by the Group.
The Group will develop a report which will be distributed electronically to the Board of Directors by April 30 1991. The report will be presented to the Spring Board of Directors meeting.
The Group will report on the political direction of EARN. This will include consideration of the Status, of EARN's status as an association, the decision making mechanisms provided by Board and Executive, the means used to raise funds, and EARN's relationships with other organisations. The Group will recommend any appropriate changes for the Board's consideration.
The Group will report on EARN's technical strategy. This will consider the protocols used by EARN now and in the future at all levels. This will include consideration of the technical management of the network. Organisation changes and any costs will be identified. Account will be taken of other activities in organisations including RARE, COSINE, RIPE, HEPNET, EUNET, BITNET, CREN, NSF, and national organisation. The Group will recommend any appropriate changes for the Board's consideration.