Paul Bryant's Networking Correspondence
These proposals indicate possible expenditure in the financial year 1993/4. Items are marked as essential (E), Desirable (D) and speculative (S).
Annual software licences for EMUTEK, CGM * FTN/77 1300 E
The is a fee for a site licence for a popular product.
Two Evaluation 586/Pentium PCs 5000 D
The 586 is the next step forward in the '86 chip range and will be required by customers in due course.
Evaluation Windows NT + additional hardware to support it 2000 D
As yet it is unclear what the future for NT will be. This depends on the production of software and the customer attitude. It is important to be aware of the product and to be in a position to give advice.
Evaluation of high speed graphics cards for Windows and X support 2000 D
Already some evaluation has taken place which indicates that with such cards the PC is competitive as regards performance with dedicated X terminals. There is likely to be a demand for advice on these cards from customers.
Evaluation of high speed ethernet cards 1500 S
High speed ethernet cards become important if PC servers and performant X terminal emulation are to be provided.
Improved tape backup system 1500 D
Evaluation of printers (laser/inkjet/colour) 1500 S
Attractive printers need to be evaluated to enable advise to be given.
CD-ROM drives for evaluation and to equip some PC Support staff 2500 D
A number of products are becoming available which ether use a CD disc for programs or data. Customers need advise on purchasing.
Other evaluation hardware (multi-media, OCMCIA, SCSI, cache controllers etc.) 2000 S
Various products become available from time to time which need looking at.
Evaluation software and upgrades for current evaluation copies. 2000 D
New software and upgraded software must be evaluated to enable customers to receive up to date and comprehensive advice.
Software upgrades for the whole group (Word for Windows, DOS 6, Windows for Workgroups, etc) 3000 D
The group requires software to operate effectively.
Hardware upgrades for the whole group (memory, video, Etc) 2500 D
New and upgraded software for use or evaluation often requires additional hardware.
Refurbishment and repair of PC Support loan equipment 2000 E
Spare machines are kept for load in case of failure. These machines need to be kept in good order.
Training 3000 E
This is particularly needed for expected new staff.
Office furniture for new staff (desks, chairs etc) 1000 D
Travel 1000 E
Technical books and manuals 500 E
Computer sundries Floppy discs, printer cartridges etc. 1500 E
Sundries 500 E
Floppy discs, printer cartridges etc.
Spares for machines coming out of warranty. 10500 E
This takes account of the increased number of machines and includes incidental costs such as carriage.
Annual software licences (Ingress, X Windows) 1800 E
Ingress is required for MAILBASE evaluation.
Additional PC/TCP licences (%K overdraft from 92/93) 3000 E
PC/TCP continues to be popular.
PC FDDI card for evaluation and monitoring 1500 S
A card is expected to be loaned from 3COM for evaluation after which one may be purchased.
Training 1500 E
This is particularly required for expected new staff.
FDDI monitoring equipment 3000 D
The availability and need for equipment is not yet clear.
100 Mbit ethernet 2000 S
100 Mbit ethernet equipment is expected in late 1993 and it may be useful to evaluate it.
ATM equipment 2000 S
TM is expected to be part of SUPER-JANET. It may also be useful on the local network. As yet there are few details of equipment to hand.
Conference and travel (92/3 was 4000 to Christmas) 4500 E
LAN sundries (cable, connectors etc) 500 E
Sundries 300 E
Two Sun Workstation's maintenance 300 E
Connectionless Network Project, SUNNet OSI 2000 S
Possible testing of OSI products. This depends on progress of JNT OSI connectionless project and DECnet phase V progress.
SUN FDDI board 2500 S
Evaluation of high speed SUN connections. Almost certainly users will want high speed access between SUNs and the central file store.
Training 1000 D
Further Hardware, Disks, Memory 3000 S
Software 3000 D
Purchase of various pieces of software for evaluation or use as yet unidentified.
DCE/DME/DFS/AFS Project, Software and Licences 1000 D
Evaluation of file store products. Overdue but awaiting staff effort.
Platform 15000 S
Possible purchase of advanced workstations.
Dear Hans,
Herewith my expense claim for the recent Paris meetings:
Hotel 1980 FF
Train airport-Orsay return 89 FF
2069 FF = 250.41 UKL
Air travel 172 UKL
Total 422.41 UKL
With thanks,
Paul Bryant.
Members: P Bryant, P Cahill, G Christian, P Girard, T Kidd, K O'Neill, D Parker, R Westlake, J Wheeler
1 Notes of meeting held January 28, TFOM/18/92
2 Progress on mounting PP
3 Progress on moving EARN gateway to PP
4 Progress on use of NJE under UNIX
5 Progress on study of user interfaces
SMAIL study
Studies in office automation group
6 Progress on study of alternatives to LISTSERV
7 Progress on draft strategy.
8 Progress on study of X.400 to EARN mail
9 Progress with White Mail
10 Review of study areas
11 Date of next meeting
12 AOB
Members: P Bryant, P Cahill, G Christian, P Girard, T Kidd, K O'Neill, D Parker, R Westlake, J Wheeler
Noted
PP is now mounted on LETTERBOX and seems to be being used. Such users will be moved to DIRECTORY. G Christian will coordinate.
Noted that the VAX6000 (VXRAL) has no coloured Book software and has to use PP.
The service will be moved to LETTERBOX at the of March after which DIRECTORY will be used for development. J Wheeler is still looking into the publicity required for a service. Action J Wheeler
It was decided to phase out LISTRAL by moving its lists to LISTSERV. Action P Bryant
G Christian has circulated his plan.
No progress.
CC has been loaded and is being tried on a Novell LAN. The gateway has yet to be tried.
MS mail has still to be studied.
Windows for workgroups will be looked at. All actions K O'Neill
INGRESS has been delivered and MAILBASE can soon be mounted. Action R Westlake
No progress with UNIX LISTSERVs
None. Action P Bryant
This is not possible.
The mail store is still awaited. Action R Westlake
March 3, 1993 at 9am.
To: Richard Tuttle, LANCARE, Knowledge House, Mead Court, Cooper Road, Thornbury, Somerset, BS12 2UW
I am sorry but we are still stuck on the 3COM DECNET questions. Thank you very much for the manual which gave us some very useful information. I attach below a number of detailed questions which I would appreciate answering. Please confirm receipt for my peace of mind.
This is difficult to write down as there are so many questions! What I really need to see is a detailed document describing the implementation of the DECnet Phase IV / Phase V interworking, e.g. the support of Phase IV end systems in a DECnet/OSI Area running Link State routing (ISO IS-IS).
Some general questions first:
Now for some more detail on question 3)
Maybe the best way to proceed is to describe the situation re DECnet at RAL today and ask some questions:
We have one extended LAN which is bridged and not routed.
We have two Phase IV DECnet Areas, 19 and 30.
Area 19 is running Phase IV Routing Vector at both levels 1 and 2 and we have several L1 routers and several L2 routers, with many connections off site.
Area 30 is also on the same LAN, running Link State Routing at both level 1 and level 2. There is today just one DECnis 600 running as both a l1 and l2 router with several Phase V connections off site.
There are a mix of Phase IV end systems and Phase V end systems in both Areas. We use interphase links across the ethernet to route between the two areas.
Once we introduce the new FDDI brouters, there will be several routers between the end systems in a department (e.g. Dept A) and the DECnis 600 in the computing centre (CCD) which will continue to perform the off-site routing,
e.g.
Ethernet FDDI Ethernet
----------------- Brouter -------------- Brouter --------------DECnis---
Dept A CCD |
|
Area 19 is |
also here |
|
WAN to CERN
and UK sites
a) Can the brouters be configured to be L1 (and possibly L2) routers in Area 30 running Link State routing? The Area address would therefore be 47/0020/001E. Do your brouters consider Phase V areas with 'Phase IV' addresses, ie. Local Area in the range 0001 to 003F (hex), to be special in the same way as DEC. Can we do OSI routing across site, within an area that has a 'Phase IV' address?
b) Phase IV end systems in Dept A must be able to communicate with Phase IV end systems in CCD (Central Computing Dept). If the two brouters between them are both running Link State, how does this happen? Are the packets converted to Phase V in the first brouter and then converted back again in the second? Or does there have to be a Phase IV path all the way through? How and when does your 'gateway' operate?
c) Likewise, Phase IV end systems in A must talk to Phase V e/s in CCD also Phase V e/s in A to Phase IV in CCD also Phase V e/s in A to Phase V in CCD Can you explain how these all happen?
d) The same is true between end systems in Dept A and end systems reachable over one of the Wide Area connections from the DECnis. These packets have to pass through two of your brouters and then through the DECnis. Can you explain in detail how this will work? e.g. when and where do packets get converted?
e) How does any of this change once we introduce an "extended area address", ie a non-Phase IV compatible one, into one or all of the routers?
Distribute: J Barlow, P Bryant, T Daniels, J Hutton
1 Minutes of meeting held October 16, 1993
2 Matters Arising
3 Recent performance
4 Diversion of mail from BSMTP to SMTP
5 Finance
6 Board of Directors meeting
7 Date of next meeting
8 A.O.B.
Present: P Bryant, T Daniels, J Hutton
Approved.
There were no matters arising.
Performance had been very stable with no serious incidents. The queue levels had been low. The traffic levels show no discernible trend.
It was agreed to ask P Girard whether the Blue Book FTP to EARN traffic could be measured. It is thought to be low. Action P Bryant
It was agreed to ask T Kidd whether the SMTP traffic could be categorised with respect to its origins and destinations. These being UK, site and foreign. Action P Bryant
[Note. The SMTP traffic is logged in a "console file". Each transfer has a number records with a serial number. There is a record showing the source, one for the destination and possibly an error record. In principle the file can be processed to categorise the traffic. There is no code existing to do the analysis. The files are generated at random intervals when SMTP is restarted. There is no effort to undertake the analysis. The files can be made available to JNT who may wish to analyse them. An example file is attached.]
It was confirmed that no EARN traffic passes from the UK to CERN over the HEP link. Some traffic to the UK may travel over the CERN UK HEP line but this is outside the control of the UK.
It was agreed to suggest to D Jennings that he might like to consider passing the Irish EARN traffic via the UK and UKACRL rather the HEARN when he installs an EBONE connection via the UK.
It was confirmed that RAL intends to move its major mail activities to "LETTERBOX" which runs PP. This includes the EARN gateway. As yet there are no firm dates for such a change as far as EARN is concerned. A particular problem is the provision of NJE under UNIX.
It is understood that the problem of the legal status of EARN, which is preventing the payment of the subscription, is being resolved between H Deckers and J Hutton. There appears to be no problem with the level of the 1993 subscription.
It was noted that the Operations Unit may look after the management and finance of NJE. This has financial advantages as the Commission would then half finance the activity. As yet EARN has not been approached.
It was noted that RAL had charged JNT for about 1/2 m/y out of a possible 1 m/y.
May 4, 2pm.
Three levels of monitoring are considered:
Line monitoring. This is provided by equipment which monitors the cable. Traffic levels, some analysis of protocol statistics, and error counts are provided. Only a segment of a network and to a lesser extent parts of a bridged network can be monitored. Whilst equipment (usually based on a PC) is easily and cheaply available from an ethernet, FDDI monitoring equipment is likely to be expensive and no suitable equipment has yet been identified.
Simple Network Management Protocol. SNMP is a protocol which allows variables in a network entity to be read and in some cases written from a management station. Most routers, bridges, concentrators and many workstations and larger machines exhibit SNMP. The variables that can be accessed are well defined in RFC ****. In some cases only a subset are provided and in others additional variables are provided. Suppliers often provide management systems based on SNMP for their systems but often this is proprietary.
Polling. Systems can be constructed to check that high level services are operating. For example, the "Network Time Server" or X.500 service can be accessed and the result examined to see if they are operating correctly.
All three schemes are useful.
Line monitoring is important in determining the health of the cable and collecting some statistics, in particular loading levels. With a routed network, a monitor is needed on each network. With a bridged network the same is true to a lesser extent as a bridge will filter out some traffic. Thus as we move to a routed network line monitoring becomes rather more of a problem since ideally a monitor is needed on each FDDI network and each ethernet which is expensive and it is unclear how to utilise such a set of monitors distributed about the site. It is debatable whether CCD should be responsible for monitoring local divisional networks unless requested to by a division.
My apologies that you have not had your PCs attended to.
I think Andy Jesset has been with you today.
We have had some problems of late. Our ridiculous financing arrangements has meant that people have been buying PCs like they were going out of fashion and we have been rushed off our feet. We also have a problem that we are understaffed and I have been on my prayer mat trying to get permission to recruit - this has been going on for 6 months - I am sure you know all about our recent recruitment policies.
Andy has an interesting, and I hope productive, way of working in that a few days before doing a job he phones up to check that the customer will be in. If he gets no reply I am afraid he just goes on down the pile of jobs and I think he had a couple of tries to get you over the last few months.
However, I can only apologies that with our limited resources we cannot give the level of service we would like.
I would like you to appoint the following as Competent Persons for working on personal computers.
M Strange, A H Coates and M Fosker
The Group's Authorised Person is A Jessett and he will be consulted as required.
The duties involved are:-
The duties will not include operating High Voltage Equipment with covers removed.
I am satisfied that the staff named above appreciate the precautions to be taken and the dangers involved in the tasks.
The FDDI (Fibre optic Digital Data Interchange - a 100Mbit network technology) consists of a backbone FDDI network which interconnects 5 routers made by 3CON which are located in various "villages". As well as connecting to the backbone FDDI each router connects to a local FDDI network and to up to 4 local ethernets. Various parts of the existing ethernet network have been moved to be connected to the 3COM routers. The CCD router is connected to the existing ethernet backbone. The logical network diagram shows how the equipment is interconnected.
Although logically a ring, physically the network is built on a star basis with a pair of fibres connection to a central concentrator. The cross site connections are via a number of 8 core cables terminating in patch panels. The physical diagram shows the location of the equipment.
As with the ethernet network, which the FDDI network is enhancing and to some extent replacing, the network carries a number of different services. The major services are IP and DECnet. Novell, Appletalk and possibly other protocols are used. However, when fault finding a knowledge of IP is useful.
Fault correction by operators is restricted to restarting routers and the concentrator, checking cables and checking power supplies. Tests from a terminal can usually locate the failing equipment.
This is located in a rack together with the CCD 3COM router in the south-east corner of telecomms area.
The front panel, which contains the fibre optic connectors has a number of useful lights.
If there are no lights check the power supply and fuses. If the fault cannot be found the maintainer must be called.
On the right is the power supply which should have the "+5v" and "+12v" light illuminated and no "flt" light. If this is not so call the maintainer.
On the extreme left is the "CPU" board. Lights "+5v" and "THROU" should be illuminated and light "IRQ" should be flashing. If this is not the case the button marked "reset" may be pressed which will reinitialise the concentrator and may clear a fault. The "REMOVE NORM" switch should be down.
Next is the "MAC" board. Lights "+5v" and "PRI" should be illuminated and lights "RX" and "TX" should be flashing. If they are not try resetting the concentrator. The REMOVE NORM switch should be down.
The next boards are identical and each carries two FDDI concentrator ports. At the top are lights "+5v" and "M" which should be illuminated. If this is not the case try resetting the concentrator. A switch can be used to disable both ports. Above each port are lights "SD" and "ACS" which should be illuminated. If this is not the case it is likely that there is a cable fault and the cable from that port should be checked. The port itself can be checked by swapping the cable into another port to see if the fault moves. It does not matter which fibre optic plug is in which socket and if a port is broken a spare can be used. Fibre optic plugs can be removed safely with powered equipment although it will disrupt users. The "REMOVE NORM" switch should be down.
The concentrator has an IP address 130.246.4.254 which can be pinged. There is no other useful use for this IP address.
There is a terminal port which can be used for some limited setting up and control but is not useful in fault location. There is a host port which is of no use.
On the front are two lights, power and status which in normal operation should both be green. An LCD screen should display the message "3COM Corporation NETbuilder II". If there are no lights or display check the power supply cables and fuses.
Network connections are made to the back of the router and are of two types. The FDDI interfaces take two slots. The fibre optic cables are connected to the lower board and the upper board has 3 lights which should be green red and green. If they are all red then the fibre optic connection has failed and the plugs should be checked. Other light combinations also indicate either software or hardware failure. The ethernet connection take a single slot. A large light STUATUS should be green and a small one TX/RX should be flashing which shows that data is flowing.
At the top of the router is the processor board which should have a single indicator running lit.
If a software failure is suspected the router may be rebooted.
The software can be re-booted by pressing the two reset switches on the front concurrently. The hardware will first be checked and then the configuration will be read from a floppy disk which is under a sliding cover on the front right. Booting takes about a minute during which there will be much flashing of lights. If re-booting fails then this may be caused by a disk failure and a copy may be tried. If all this fails to restart the router then maintenance is probably required.
On the processor board is a terminal socket to which a 9.6K terminal may be connected. This may be used for setting up the router and monitoring its operation. Similar access is available by TELNET to any of the routers IP addresses. Access is protected by password.
The easiest way to check the network is to ping the interfaces on the routers. The logical diagram of the network indicated the IP address of each router port (in some cases a port may have several addresses any of which may be pinged). It is best to start with the router port on the network you are connected to and work outwards depending on the nature of the fault. Do not forget to ping the concentrator on 130.246.4.254.
If a particular interface on a router will not respond then this may either indicate that the board is broken or there is a cable fault.
There is currently one spare interface on the concentrator which may be used. Otherwise there is no user maintenance options if the concentrator is faulty.
There is sometimes spare interface cards on a 3COM router. The spare card must be inserted in the correct router backplane slot as each slot is configured by the software. There are no hardware switches on the boards. Hot swapping of boards is allowed. The router must not be operated for any long period with vacant slots for cooling reasons. Blanking plates are available.
Particle Physics Jason Leake R1 Dave Kelsey R1
Informatics Andrew McDermott R1
Space Science Chris Mutlow R25
Neutron Division Richard Brodie R3
Computing Roland Brandwood R31
Brian Day R31
Chairman Paul Bryant
1 Apologies
2 Minutes of meeting held January 27
3 Delivery time scales
4 Equipment location
5 Cables
6 Local FDDI networks and end equipment
7 IP addressing
8 DECnet addressing and gatewaying
9 Other protocols
10 Super Janet pilot projects
11 Date of next meeting
12 A.O.B.
Present: R Brodie ND R3 P Bryant CCD R30 B J Day CCD R31 G W Robinson CCD R30 T Kidd CCD R27 A McDermott ID R25 P Girard CCD R27 J Leake PPD R1 Distribute: To all those present plus: R Brandwood CCD R31 D P Kelsey PPD R1 C T Mutlow A&G R25 D L Terrett BNSC R68
R Brandwood
The FDDI type of connector for the JIPS Cisco router has not yet been determined. Action P Bryant
All equipment has now been delivered and accepted.
All equipment apart from the ND router has been installed. A rack will be provided for the ND router by CCD. Installation is not expected for a week or two to enable tests to continue.
All cables have now been installed. The CCD to R55 has yet to be terminated.
6.1 CCD. This FDDI network is live.
6.2 A&G. No information.
6.3 PP. Some FDDI interfaces and a concentrator are on order.
6.4 Informatics. £40K has been set aside for network development but it is unclear how it will be spent. An early connection to the FDDI network is not expected.
6.5 ND. No equipment is currently on order. However, ND want to split their current network. This will require the allocation of a further subnetwork and 130.246.84 has been provisionally allocated.
All the IP address changes have now been made.
DECnet V and IV as well as gatewaying have been demonstrated. Further discussions are to be held between P Bryant and D Kelsey to discuss if and how it should be used.
No problems are anticipated.
The Cisco router is expected in a couple of weeks.
April 2, 1993. Atlas Think Room.
It had been hoped to bring the 3COM routers into use on March 4 but faults had arisen and the change had to be backed out. The reasons for failure are not yet understood. The tests had not been advertised on PROFS and a little less than 24 hours notice had been given in the IBM login message. As the change caused disruption until 9.15 this had caused inconvenience. NTMPC needs to address the exact procedures for network testing with respect to publicity. Action P Bryant
Quotes for maintenance options have been requested from LanCare. Even so some failures could cause loss of the network for long periods. The possibility of reconfiguring the network without the concentrator in an emergency will be investigated.
Operator documentation is under production.
Members: P Bryant, P Cahill, G Christian, P Girard, T Kidd, K O'Neill, D Parker, R Westlake, J Wheeler
It seems that the minutes did not get circulated. This will be done.
All users are now on DIRECTORY rather than LETTERBOX.
There is still some work needed, in particular for automating the building of tables from the RACTEL data base.
It is still expected to move the service to Letterbox at the end of March. X.500 will stay on DIRECTORY.
It is intended to put in an MX record so that mail for DIRECTORY will go to LETTERBOX.
IBM NOTE needs to be removed.
User documentation will be produced and circulated to the group. Action J Wheeler
The EARN gateway will be moved to PP at the end of March.
Still an elusive object.
No report.
It would appear that MAILBASE is not as popular as thought as only 3 or so sites are looking at the product.
EXPLODE is on beta test at a few selected sites. Apparently it is then up to COSINE what happens to the product.
EARN is trying to get DEC to fund a VAX VMS version of LISTSERV. This will be NJE based and thus of lesser interest.
None.
Apparently Jeremy Sharp is looking at the product and it is hoped to get his opinion. At the PCsig there was encouragement for the product to be mounted over IP, presumably with RFC 1006.
Feelings are that effort should not go into the product until it is clearer that the community indicates that X.400 is popular.
No changes.
April 1, 1993, 09.00, conference room R31.
This document has been prepared in response to a request for comment on the draft report by the SERC Internal Audit Unit on Personal Computing Federal.
In general I found the document welcome and constructive. A number of issues are raised on the recommendation as seen from Rutherford Laboratory.
This document adopts the paragraph number of the report for ease of reference.
The review states that it concentrates on administrative computing. This class is a minority at RAL. The needs of the scientists are very different to those of administrators. However, many machines are used for both scientific and administrative computing as many managers undertake both classes of work.
In the subsequent text in the review it is unclear which recommendations are appropriate to scientific computing.
We are moving towards an organisation where customers pay for internal services. In this scheme they are interested in value for money. They will be unwilling to accept directives which may require them to buy non-optimal equipment. Thus any central unit may well have to sell its services rather than require the use of their directives. Thus cooperation and payment for services may be a better approach.
2.1 It is stated that the "precise implementation of the recommendations may require slightly different arrangements in a number of cases". The implementation of the recommendations may well depend more on the application area than on the site. For example, the security of data is more of a corporate issue with administrative computing than with scientific. There are many special cases in scientific computing where computer and software procurement is restricted by the application and in these cases standards would be hard to follow. For example, some machines are used for monitoring purposes where special hardware may be needed.
2.2 I support the statement that personal computing is becoming important. The formal and planned approach to purchasing, maintenance, security and disposal gives us some concern. The issue is whether there is sufficient commonality across sites and even between application areas to make such policies cost effective. My belief is that there is scope for a planned approach in a number of areas but in others such an approach may lead to difficulties in adapting to a swiftly moving market place, the purchase of non optimal equipment and software, and expenditure where none may be needed. These issues are explored in later sections.
2.3 Noted and supported.
Each area is examined in more detail in later sections.
Central Guidance
4.1 RAL certainly provides a PC support service to the site. There are also some 3 staff which provide PC support for administrative computing. This support is directed to the specific applications used by administrative personnel who are not PC experts. The PC support group tends to provide purchasing, hardware, maintenance and a general sorting-out service.
4.2 If equipment and software is recommended centrally then there is a problem of support since a central unit will not have detailed knowledge of the requirements on the other sites. If recommendations are followed then there is an implication that support from the central unit will be expected to sort out any resultant problems.
There is a problem that purchasing control is in the hands of the departments and thus they will not follow recommendations that are not to their liking. For example, the recommendation at RAL to use DW3/4 is ignored by scientists and by a number of administrators as not meeting their needs. Thus any recommending body will have to have a detailed knowledge of requirements and be reactive to the needs of the purchasers. There may be some reluctance to financially support a central unit which they feel is not in their interests.
4.3 Whilst the Information Systems Division has a clear interest in administrative computing it currently does not have expertise in scientific work. No doubt the Division could take over the current activities of PC support at Rutherford although their may be some resistance from scientists who may not be so happy with a remoter service. If this function is moved to Swindon then it may well become remote from the scientific requirements. If located at Rutherford (or another establishment) then it may become remote from the administrative requirements. In following this recommendation the staffing implications must be carefully studied. Currently it is difficult to envisage any reduction in staff on PC support at Rutherford and thus any transfer of staff to a unit with a wider remit would require further staff investment. The cost savings, in terms of better deals with suppliers and prevention of duplicate evaluations at sites needs careful evaluation.
Closer cooperation between existing PC Sections is certainly a more attractive proposal although when this was tried several years ago the needs of the sites were found to be fairly divergent making any close cooperation unattractive. It may be that in the current environment a further attempt at cooperation may be more successful.
The production of a guidance manual and its updating will be a significant task if it is to be both comprehensive and up-to-date. New products and updates come frequently and our experience is that some customers are anxious to take advantage of new developments at an early date.
4.4 We support the closer cooperation between sites as the better alternative for the reasons outlined above. I have strong reservations on the possibilities of success of a central unit which may become an object actively avoided by the community if it prevents the acquisition of equipment thought suitable by the purchaser.
Local Guidance
4.5 We support the areas where local guidance is required. We also feel there is a need to give advice on purchasing. The customer needs to be able to talk over his requirement with experts and to have advice on what to purchase. It would be difficult to provide such a service from off site. In addition sites have specific local standards and recommendations which must be dealt with at the local level. At RAL we have an informal system for advice and a more formal one would probably be useful.
Monitoring that recommendations are being followed would be a difficult task. With 900 machines this would take considerable staff resources and begs the question as to what action would be taken if recommendations were breached. I am continually finding machines and software that was purchased without the PC groups knowledge. Currently this is a case of buyer beware rather than a misdemeanour.
4.6 Noted.
Procurement
4.7 It is quite likely that SERC does not get the best deals with suppliers in a number of instances. Against this has to be put the cost of central coordination and the cost of inappropriate products which may be dictated by SERC wide policies.
It must be remembered that recommendations often last but a few brief months before developments overtake them. Thus in negotiating deals time is an important factor.
I feel that RAL already gets substantial discounts often due to getting educational discounts. For example, we get a 0.49% better discount on Viglen computers than we would under an HMSO bulk purchase agreement although we do not purchase in bulk. I understand that the contracts branches at the establishments already swap information on the prices for popular products.
Site Licences
4.8 Before undertaking SERC wide negotiations for licences a study needs to be made to evaluate the savings as against the costs of central negotiations. It would be surprising if there were not savings to be made, it would be surprising if the additional staff costs were not significant.
Unfortunately there are no site licences for many popular products, in particular for Microsoft and Lotus products which comprise the bulk of administrative computing. There are multi-user licences for server based products but their use needs a new way of working.
4.9 I firmly believe that IBM compatible computers are a commodity market where it is possible to purchase equipment at attractive prices. In such a market place it is essential to ensure that any machines are suitable for the purpose they are intended. Rutherford has undertaken extensive research into the market place and already implement this policy.
4.10 Noted.
Data Security and Integration
Security Awareness
4.11 Noted. It must be remembered that the security requirements of different applications differ. For example, machines used for monitoring and development have different requirements to one used for accounting data. It is my view that eventually people should be encouraged to use a central site data store for important information. I am not happy with security archives being kept on many floppies although at this stage there are few alternatives. I applaud the need for security awareness.
4.12 Whilst I agree with the sentiment of including security in the "Council's contract of employment" it is difficult to understand how such a recommendation could be put into practice. There are many other areas of similar concern which should have a similar treatment.
Inventories
4.13 Noted. The idea of a good inventory is recognised as is the cost of its production and maintenance. Rutherford has a partial inventory but in many cases machines and software have not been acquired via the PC group.
4.14 The cost of keeping an inventory must be weighed against the benefits.
4.15 Noted and fully supported.
4.16 Noted and supported. A word of warning on policing software use. It would take an estimated half hour to check a machine and with 900 machines that is 450 hours or about 3 months of effort. My PC group would be reluctant to police the software on machines as this would harm our good supplier/consumer relationship. This is a job for a specific officer who would otherwise have no contact with the customer.
4.17 The idea of a paper file beside every PC containing details of the PC as a principle it has much merit. On the detailed side it would seem better to have the information computerised so that it can be accessed by all the relevant staff.
4.18 I support the use of virus checking. I already offer a virus checker from CHEST - it is slow and thus there is a reluctance to use it. The product often detects non-existent problems which causes a lot of work by support staff chasing such phantoms. Viruses are a small problem at RAL - about one a month and mainly from university software. We have up-to-date virus checkers and look at software of suspect origin. The use of games or for that matter other software acquired in some way needs careful study. There is much useful free software which can be obtained in various ways and this will probably not be registered. In the scientific and network areas such software is essential but clearly must be virus free.
4.19 Noted and supported.
4.20 Noted and supported.
4.21 Noted and supported.
4.22 Tuning machines is a time consuming activity. I estimate that it takes 1/4 day to tune a machine or about a man year for our 900 machines. This is probably not a good use of time and a better scheme is to tune a machine on delivery and when new software is installed. Problems are often self inflicted by software being loaded by inexperienced staff but my staff are always willing to sort out machines. Reformatting a disk is only ever necessary in the case of hardware failure.
Equipment disposal
4.23 We use redundant machines as a source of spares and the resultant remains are of almost zero value. None the less there is merit in disposal regulations being amended to reflect reality although the current rapid pattern of change may not be permanent.
4.24 Noted.
Training
4.25 I am now investigating various video and computer based training packages and agree that this is a fruitful direction to follow.
I have as yet not studied the requirements of the EC directive on workstations. My initial and private view is that the directive is appropriate for staff who spend almost all their time in front of a terminal. Many of our staff use terminals only as part of their jobs and the directives appear to be an overkill. Staff usually have considerable freedom to organise their desks to their taste with respect to chairs, filters and other impedimenta of the modern office and may even resent so called improvements in their working conditions. However, we should certainly make them aware of their entitlements and of any dangers inherent in workstations.
The Central Computing Department at the Rutherford Appleton Laboratory provides large-scale computing services based on a Cray Y-MP8I, IBM 3090, DEC VAXes including a 6000 all linked to a 10 terabyte data store. It serves the needs of scientific research workers with their various workstations both in the Laboratory and University departments over the local network and JANET. It also has links into the major international networks and is an active participant in high speed academic networking initiatives.
The Laboratory has an extensive ethernet local area network. This is shortly to be enhanced by an FDDI network to allow new services such as high quality graphics and access to an expected high capacity file store. The network is expected to have access to Super-JANET, a very high speed wide area network connecting some academic sites. The principal protocols used are IP and DECNET phase IV and V although several other protocol stacks are in use, including X.25.
The aim is to provide a high quality service to the scientific staff both on the Rutherford site and to customers at remote sites. The network hardware technology and the protocols are continually evolving and customers are anxious to take advantage of any new developments.
It is expected that the use of UNIX will increase and be the dominant operating system over the next few years. Thus UNIX network products are most important.
The purpose of the post is to provide the technical expertise and management abilities necessary to develop the site wide local area network. With the increasing use of UNIX much of this work will be in connection with the networking of these systems.
The objective is to improve the quality of the services being provided by the network from its users' viewpoint by the management and enhancement of the network and the support of network software on UNIX systems.
The duties of the post are to:
Applicants should ideally have an excellent knowledge of communication, in particular ethernet and FDDI, IP and DECNET technology, be familiar with network operations and possess good organisational abilities. Experience in developing network software is desirable, but consideration will be given to candidates without this experience and knowledge where an ability to quickly become effective in a new field can be demonstrated. A good knowledge of UNIX is important.
Suitable training will be given where necessary.
Further information on this post is available from Dr. P Bryant RAL ext 5267. The Personnel contact is .... RAL ext ....
Permanent employees wishing to be considered for the above post should complete a staff applications form and forward it via the Head of the Group or Section to reach their Personnel Officer not later than the closing date.
A non-industrial employee of the Council servicing on AEA-type conditions would be entitled to retain those conditions on appointment to this post.
Non-permanent employees are advised that as this post is being advertised in the press they may apply as external candidates and should approach their local Personnel officer.
There is an action on me in the Executive minutes to produce some thoughts on the future of EARN. This is it. It is looking a bit dated since I wrote it some months ago as some of the ideas have already come to pass. Please put in the agenda. Thanks. Paul.
The UK decided to restrict EARN access to be a via a gateway on the basis that there was a sophisticated network centrally financed already in place. To have supported EARN connections would have entailed the installation of further lines for which funds would have been difficult to obtain. In addition many considered that there would have been a dilution of the efforts and resources which were then directed towards a transition to ISO protocol standards. Even if EARN had been encouraged the penetration would have been small as there were few IBM machines in UK universities. The incentive to connect VAX machines which already had Coloured Book connections and for which NJE is not native would have been small. Such connections would have entailed running two mail systems (UK domain order and World domain order) to the confusion of the users.
Initially EARN, via its gateway into the UK, provided the major international mail service. Recently this position has changed with the introduction of IP services and now it is reduced to a small fraction of the traffic. Indeed, care is taken to route all possible mail traffic across SMTP.
The file transfer traffic has always been relatively small since the gateway is not convenient to use. This traffic has also been eroded with many interesting information stores now being accessible via FTP. As an aside, the construction of an NJE to any other file transfer system is difficult because of the NJE addressing limitations (an 8 byte address plus two 8 byte components for the file name).
The introduction of ARCHIE, GOPHER and WWW have further popularised the use of IP since the NJE networks do not have well developed facilities of this type.
LISTSERV is heavily used although most use is not via EARN. Its continued use is because there is no comparable service.
To some extent the UK experience is being mirrored within Europe.
The NJE networks are well suited to slow unreliable lines. Temporary failure of any line or node are easily recovered from. High line utilisations are possible. It is less appropriate for the high speed reliable lines now common on substantial parts of the network. As an aside, the same comments are broadly true of X.25.
Much of the EARN NJE traffic now travels across IP connections. In fact it is EARN policy to use IP where possible. This means that one address scheme (NJE) is encapsulated in another (IP). This is slightly inefficient but more seriously required the maintenance of two address schemes. Such encapsulation is valuable during a transition but not so attractive on a longer term. It is worth noting that initially the UK encapsulated IP in X.25 but much of the IP is now native, current thoughts are of encapsulating the remaining X.25 in IP in the expectation that its use is diminishing.
Certainly, RAL is phasing out its IBM 3090 computer and it is highly likely that there will be no similar academic IBM machines in the UK within a few years.
It is thought that VAX VMS may go in a similar direction over a rather longer time scale with the steady migration to UNIX which appears to a direction with which DEC is happy.
There appears to be similar changes in some other countries.
Without IBM and in the longer term VAX VMS (there being no well supported NJE for UNIX) the future of NJE is bleak. Indeed, even with these systems NJE is not an attractive proposition with the better quality lines and the good IP implementations available on virtually all platform.
Leaving NJE aside, the remaining services are LISTSERV, TRICKLE, user support, documentation, support of emerging countries and conference organising.
The network monitoring service is closely associated with NJE. As such it does not have a long term future. There may well be a future in monitoring the performance of IP networks although this is an area which has not received EARN's consideration. It will also need agreements with RIPE and possibly others.
If it is accepted that NJE has a limited life then there may be merit in planning its removal.
Such a removal has financial benefits. The current expenditure on the maintenance of the NJE tables and on monitoring ceases.
NJE may well continue to exist within countries for some time. There may well be a case for countries organising NJE within their countries and providing a gateway to the rest of the world.
If an active encouragement to remove NJE is agreed then there are a number of steps needed.
Most important, LISTSERV must be developed to operate effectively over IP and this work is now in hand. TRICKLE may also need attention. Gateways between NJE within a country and the IP network exist but may need some attention.
The principle reason for the UK retaining NJE is to exchange mail with sites using EARN mail addresses. Thus there should be an encouragement to use valid domain addresses as a precursor to a transition to SMTP or using gateways elsewhere to SMTP.
Unsolicited file transfer has never been available in the UK and it is therefore difficult for me to comment on the extent to which it is needed. None the less the current work in defining such a protocol should help applications such as LISTSERV to continue without NJE. A gateway between NJE and an IP unsolicited file transfer is important.
Messaging protocols already exist although for reasons that I do not understand they have not been very popular. A study would be useful on the need to provide messaging over IP and if positive to ensure that a service can be provided on IBM computers.
Left to its own devices NJE and EARN could well continue for several years. Although the traffic levels are relatively stable they are now a small fraction of the total academic traffic which is still rising to take advantage of the higher bandwidths and more demanding applications.
The situation is similar to the UK Coloured Book protocols and X.25 where they are now a fraction of UK traffic and there are questions as to whether there should be an active campaign to remove them.
The EARN question is whether to promote an active campaign to remove NJE and to redirect resources as quickly as possible or to leave NJE to die a natural death with criticism over the cost of its geriatric care.
My own view supports a carefully planned end to NJE. In any such planning it is vital to protect the interests of the users and in particular those in emerging countries. This could well take the form of low bandwidth IP connections restricted to mail and with suitable spooling systems, use of data compression equipment and use of dial up SLIP.
Without NJE, EARN activities will have to move away from the provision of low level services. There has already been such a partial move with the development of support and documentation services. How much further scope there is for such changes is unclear. Certainly, EARN has identified an area which is not being developed.
Without NJE the funding of EARN will undoubtedly have to be on a different basis. There are a range of options to be explored from subscriptions from individual sites, charges for services to the sale of documents.