Paul Bryant's Networking Correspondence
This paper describes the current state of the Cambridge Ring at Rutherford and Swindon. It indicates areas where problems may occure.
Both Swindon and Computing Division have Ring cable installed which has a socket in each office. The Rutherford Ring also visits R1 but there are only a couple of sockets in There. All wiring and connectors are to CR82 standard. Both Rings operate satisfactorily but they have a higher error rate than expected due, probably, to the large number of connectors in the cable.
All the Monitors and Nodes are from Logica and operate satisfactorily. They are almost to CR82 but the differences to CR82 are small. It is unknown whether the equipment is under a maintenance contract as the author was not in charge of installation and also the equipment has come from several sources- CD, JNT or DCS purchases. There has always been spare equipment and broken items have been sent back to Logica.
The OLT equipment now operates satisfactorily. It is known that there is still a fault in the software and there may well be further ones so far uncovered. Although there are unlikely to be serious faults it will be difficult to investigate faults as the only means of investigation is the code in the GEC. No monitoring equipment was ever developed that would be capable of fault analysis. In any case fault analysis depends on staff being familiar with the Ring protocols.
The arrangements for maintenance of the OTL hardware and software is not known to the author.
The El Cheapo interface is based on the GEC PCC board and a board produced in house. Two hand wired boards exist in RLGK and PHGA. So far the equipment has functioned well in that they have so far not failed. The PCCs used have been of two varieties- the first is the obsolete HDLC boards which can only be used in non 4?9? series and secondly a recent HDLC board which can be used in a 4?9?. GEC have provided a modification to the obsolete board to allow it to work in a 4?9?. 3 boards have been modified but only one has been made to work so far.
A tracked version of the RL board is being produced and 5 copies will be made. This project has had a bad start as the first board had a large number of faults and is having to be retracked but in principle there should not be any problems.
Software for the board and driver has been produced by P Bryant and J N Mills (mainly Mills). The TSBSP code was received from GEC Great Baddow and is not a GEC product. This has been modified mainly to correct faults. Software currently has no known faults.
The equipment operates at about 50 k bits/sec.
This equipment has recently had considerable effort put into its development. Currently it is not CR82 compatible and a mod is expected from Logica. There has been a further fault which requires new proms for the board. The effort required to get it going has been surprising as there have been several other problems now overcome. It is surprising that the UNIVERSE project had not sorted out the problems.
The driver was written by GEC Great Baddow and the TSBSP code is identical to the El Cheapo code.
The principle advantage of the hardware is that it can operate at almost the Ring speed of 1.3M bits/sec. There may be problems in putting equipment on 4160 machines.
RL are no longer developing code for this equipment and DL is now providing it. The state of the equipment is unknown and there is no intention to consider it. A store director board was purchased for the project but has never been used.
This equipment received its field trial at Rutherford. many faults were found but it is now believed that it is substantially error free and has been shown to operate well.
Should such equipment be purchased then CAMTEC can support the equipment but it is unclear how faults are investigated without in house expertise.
The CAMTEC Ring X25 Gateway had its field trial at Rutherford. Many faults were found but the equipment is now thought to be substantially fault free.
Should such equipment be purchased then CAMTEC could maintain the hardware and software.
Currently there is no other equipment at Rutherford which supports CR82 but should the PERQ or PDP11s eventually support the protocol they should be able to interface to the equipment on the Ring. It is believed that the ACORN VAX interface is progressing but the author has no details.
Since the major bugs have been removed all the equipment has operated very well. The hardware problems encountered have been one or two node failures and a failure due to the illegal move of equipment which resulted in a blanking plug being left out of the circuit.
Traffic is now moderate which gives confidence that there are now no hidden faults. Since the GEC is now used for staging files between OTL machines the GEC interface has been heavily used. So far the low throughput has not been a problem. There has been light traffic between the Swindon OLT machines and Rutherford OTL machines proving that the gateway functions are satisfactory.
The Ring PADs can support terminals at up to 9.6K. The performance of the PADs is better than the X25 PADs as they are not limited to the 9.6K X25 interface. At Swindon the bottle necks are the 50K interface into the GEC and the 9.6K interface between the GEC and JANET, thus the Ring effectively provides no bottleneck. Note that the Cifer full screen terminal is in any case limited to 48K. One should also remember that IBM screen terminals connected over a multiplexor to RL will be limited to 9.6K by the communications link. Thus the best improvement in performance obtainable by installing IBM equipment (barring a mainframe) is a factor of 2. This is not an accurate calculation as the X25 line to the GEC may also be carrying other traffic unconnected with terminals. The provision of PAD terminals has the advantage that terminals can connect directly to the Swindon GEC which runs the Swindon mail service. IBM terminals would require access to that service to be via the RL IBM which would be a waste of bandwidth between the sites. It could be argued that perhaps the IBM should contain the Swindon mail service but remember that the IBM service is poor and relies on RLGM to contain the directories of participants and thus Swindon would have to rely on RL to maintain their mail directories (more staff needed).
The protocols run conform to CR82 which are unlikely to become international standards and so an abundance of equipment from many manufacturers is unlikely. The Ring hardware is possible going to ISO but without the higher protocols. If this succeeds and the Ring does become popular then the higher protocols will have to change to conform to those above IEEE 802. This possibility is so far in the future to be not considered further.
The only hardware which is not likely to have a maintenance arrangement is the RL produced board (either El Cheapo or UNIVERSE). The boards are cheap and spares will be produced. None the less, easy to use diagnostic programs have not been written yet and current staff problems may prevent their production.
Means of locating and identifying faults are not well developed. It had been hoped to develop such techniques but staff resources to undertake the work were never provided. Some Ring test equipment exists at RL which is capable of testing nodes and monitors.
Experience has shown that finding faults has not been a problem and that faults have been rare. There is insufficient experience to determine whether this reliability is a feature of the equipment or luck.
The use of the Ring at Swindon is attractive as it utilises the expensive wiring now installed. Any other technology would incur a heavy cost in terms of money, time, and equipment. The use of the Ring does make the best use of the bandwidth to Swindon and allows Swindon very good access to the rest of JANET independent to RL.
Faster terminals to RL at Swindon can only be provided if Kilostream or Megastream connections are provided. Such connections would only have a marginal effect of the performance of Cifer full screen terminals but considerable effect of IBM products (I believe, depends what IBM equipment is available).
If the Ring is used then it would be wise to retain expertise on the Ring software. It is highly unlikely that this would ever be adopted by GEC. It is advisable for test programs for the GEC Ring equipment to be developed.
As CAMTEC produce a Ring X25 gateway it would be possible to make the Ring X25 connection independent of GEC equipment. This development would require a further connection to an X25 exchange and would reduce performance to the local GEC although this is probably not a serious consideration. Certainly line utilisation would be reduced as it is advantageous to mix interactive and bulk traffic from an economy point of view.
The documents attempt to redefine the Slotted Ring standard to provide a MAC service conforming to the MAC service provided by the other IEEE 802 media (or the subsequent ISO standards). An attempt has been made to make as few changes as possible to the CR82 standard in the interests of retrospective standardization of existing equipment. On a cursory examination CR82 is a subset of the BSI standard apart from necessary changes to provide the MAC service which is mainly concerned with the MAC address.
The approach taken leaves the standard with some curiosities. The alternative approach is to make rather more extensive changes which would undoubtedly cause incompatibility with existing equipment. In practice it is of no consequence which approach is taken apart from the compatibility consideration. As far as the standard is concerned, the current BSI document may be altered by ISO to remove the curiosities in which case compatibility would be lost. Any such alterations will cause delays. On the other hand attempts to change the document does mean that others are taking the standard seriously. If it does go though "on the nod" then it may well turn out to be a hollow standard in that it will not be followed outside the UK or even beyond the current manufacturers.
These octets are now used to define whether 16 or 48 bit MAC address is in use. Compatibility excepted this is an expensive use of 16 bits. Arguments could suggest that there should be only a single octet or that one of the type bits could be used.
The argument that the header octets are needed to detect the start of frame is not good with the type bits being used for this purpose. There seems no reason why there should be a belt and bracers start of frame detection.
The particular bit patterns used are pure history and purists may well argue for 00000000 0000000x or other not so arbitrary pattern.
Only one of the type bits is used. Thus there seems no reason why there should be two. Unless one is used for determining 16 or 48 bit MAC addressing. Personally I do not like this use for the type bits. It would be nice if some use could be found for the second type bit to prevent it being argued away.
The Requirements paper suggests two mappings from a MAC address to the octal address required by the Ring. The first is a look up table and the second is to take one of the octets of the MAC address and use that. In face the second scheme is merely a special case of the first.
It could be argued that the Ring address of one octet is too short. It is shorter than the Token Ring and much shorter than CSMA/CD. My view is that a large address space is preferable as it allows a site with several rings to avoid duplicate addresses. Should ring interfaces become cheap then rings with a large number of directly connected work stations may require rings with more than 244 stations.
The MAC address is stated to be 48 or 16 bits. This is difficult to support from the IEEE documents. These documents seem to indicate that what is passed to the MAC layer is an "address" which may be something which is translated into the address required by the protocol. The attempt to use the 16 and 48 bit values used in the other media seems desirable but not strictly required.
Division Heads Committee have decided to set up a committee to coordinate the communications activities on the Rutherford site. The terms of reference of the committee are:-
It is envisaged that all network developments which will result in providing a service which is not private to a division will be referred to this committee for agreement before proceeding.
The membership will consist of a representative from each interested division and a representative from the Joint Network Team. Experts and observers may be co opted from time to time for specific items or on a longer term basis. Meetings will be held at three monthly intervals.
The letter from C Hobson was considered and the following points made:-
In general the BT conditions are considered reasonable. P Bryant will write to BT for clarification on the above points.
IBM agreed to find out the traffic levels on the VNET links for comparison. C Setford
Three amendments were proposed:-
The proposed figures are $27K for 1984 and $33K for the subsequent years. This would give traffic levels of 3Mbytes per week. This was thought to be a low estimate of traffic and that perhaps the figures should be higher.
Note that the cost of the Dublin link would be recharged to Dublin while the cost of the Cern end of the line would be recharged to Rutherford.
Rutherford intend to phase out the Memorex 1270 multiplexors in about 12 months. Future equipment will probably only provide X25 and asynchronous connections. Rutherford are worried that participation in EARN may prevent the multiplexors being removed. IBM agreed to investigate whether a 3705 with 4 lines could be provided for the project. C Setford
It was agreed to attempt to make a case for a connection between Hursley and Rutherford independent of EARN or JANET. The case would be based on the following requirements:-
This would be progressed by both sides and would be the subject of a separate agreement with IBM. P Bryant and C Setford
Ira Fouch will be asked for details of the particular brand of RFC 822 mail used in BITNET so that estimates can be made of the effort needed for the mail gateway. The best estimate is currently 3 to 6 months for a reasonable programmer. P Bryant
There is a slight possibility that IBM might be able to provide some effort for this work. This will be looked into and may be the subject of a separate agreement. C Setford
The lines to Dublin and CERN are now on order.
A rather more lively meeting than normal. A hot topic was European Harmonization and the effect it would have. The effect on XXX was of particular interest. Two presentations by BT were attempts to publicise a poor file transfer protocol being provide by MERLIN for micros and and a talk that convinced us that cable system standards are a disaster.
There was a complaint that services such as TELEX and PRESTEL over PSS seem to creep into existence and there seemed no way of finding out details of the services or even if they were services.
At last CTIG had had discussions with the TNA experts who were surprised that there were complaints on the problems of the protocol id and the very poor treatment of the X29 parameters. The PAD implementers guide is now out for comment. The register of PADs is not out.
There was a lot of worry that the European Harmonization work on XXX was done too fast and not very well - I do not disagree. My papers from the meeting will be circulated.
The group had not met. It had been proposed to develop a DTE which would work on all European networks. An alternative approach that was put forward was to encourage the harmonization of the networks themselves so that such exercises would be unnecessary.
This group is now working on ISDN. The group lacked effort. Work on network relays also lacked effort.
There was concern at the lack progress on authorization and encryption.
I gave an outline of the harmonization work in Brussels. There was some concern at the speed with which the proposals were being produced and the lack of consultation. There was also concern at the effect that the work would have.
It seems CCITT are not interested in the convergence protocol.
BT and BSI have now agreed on the use of the 32 digit addresses in CCITT 84.
Quality of service at all levels was a mess at all levels and there was now work to attempt to get the subject as a new ISO work item,
This was a presentation of a file transfer system being marketed by MERLIN. There was a lot of worry that BT was pushing a non standard protocol.
It seems that all the cable companies are using different systems, thus there will be little possibility for interchange of equipment. There must be some standardization here in the future.
The standard has been produced with a view to making minimum changes to the existing CR82 standard.
The benefit of this approach is that existing equipment and the expected chip will require little or no change. This will be a benefit to existing ring users and capitalise on the developments so far.
The disadvantage of the approach is that the standard includes curiosities to maintain this compatibility which those with no investment in rings may object to. The items of interest here are :- the spare type bit, the arbitrary initial two bytes of which only one bit is used and the use of an arithmetic check sum rather than a cyclic redundancy check.
If one takes the view that the standard should be revamped to correspond as closely as possible to the other IEEE 802 or ISO standards then perhaps the 8 bit address should be larger.
The approach taken to maintain compatibility is only sensible if almost absolute compatibility is kept. If any part is changed then existing equipment is rendered obsolete and whether the new standard bares any relationship to the old or not is irrelevant. Thus my view is that the two viable propositions are that absolute compatibility is kept or that the standard is completely revamped. Unfortunately it is not certain which of these is the best approach until after it has been through some discussions at ISO.
I would hope that it does get through ISO compatible as this will cause me least upset but I fear that ISO may put a tooth comb through it. We shall see.
As promised I give some details of protocol documents produced by the EEC. The work is not yet complete. I have not included full details of working documents.
These ARE NOT standards but are recommendations or guides to the "common use of OSI standards". The work has specifically not gone outside ISO standards and has not attempted to change or develop these standards.
The EEC Information Technologies Task Force is working towards various EEC standards for the EEC's work. These standards do not have any recognized standards stamp of approval.
I am not sure which if any of these documents should be included in the document- I will leave that to you. For information contact:-
Ken Thompson Commission of the European Communities Information Technologies Task Force Rue de la Loi 200 B-1049 Brussels
EARN is one of a number of academic networks. It is highly desirable for traffic to pass between these networks as freely as possible.
In an open community such as the world academic community any host should be able to communicate with any other. This would be easy if all the hosts were on the same network but this is not the case, it may never be the case, it may not even be a desirable aim. Thus it is not likely that all the hosts will be in the same naming domain. Each naming domain will define its own naming scheme (as JANET and ARPA have) and these are unlikely to be compatible with each other. Thus there must be gateways between the various domains which will allow traffic between them.
The domains of interest include:-
There are certainly others.
In addition there will be local area networks with there own naming schemes such as the CERN site.
The networks EARN will connect to exhibit a variety of technologies and protocols and thus there will be a variety of gateways. This is unfortunate since considerable effort will be needed to construct and maintain them.
The RSCS protocols allow an 8 character node name plus an 8 character 'process' name on that host. The process name may be a virtual machine name, a remote workstation name, the name of a class of local devices and so on. In particular the process name could refer to the virtual machines dealing with mail distribution, mail relay or file relay gatewaying. Any extra address information must be carried with the data. This is done in the case of the RFC 822 mail standard and also in the existing scheme used at Rutherford for passing data to CERN via JANET and the Rutherford CERN RSCS link. There may be other means of carrying addressing information over EARN which the author is unaware of.
There is a danger that each gateway will demand that gateway address information is carried over EARN is some gateway specific way. This would be unfortunate and if it is to be avoided some internet protocol must be provided which will be used by all EARN gateways.
There are currently two distinct types of traffic.
It is therefore proposed that a suitable protocol be defined to enable file transfer spooling gateways to be developed.
Since the information that can be carried in the node name and the process is limited and used for EARN purposes any internet protocol must be embedded in the data. This leads to the following requirements:-
Although it should be possible for the user to generate protocol records with no extra software it would be useful if programs were developed to help file transfer.
Gateway programs will be needed which extracts the protocol records and act on them. The gateway program for each network will be different. As protocol records do not head a document then the program will have to scan the document for the records and there is then the problem of what to do with the data before the protocol records.
At Rutherford a protocol has been defined to meet the above requirements albeit in a crude way.
The protocol is contained in a batch of records. The fields include:- The remote computers name, the file name, the user name and the user password. In all there are about 12 possible fields most of which are optional. It would be easy to extend the protocol to include further fields or more complex ones but rather more difficult to extend the program to deal with it.
The record takes the form of a JCL comment record and thus survives being processed as a job. It is possible for the user to output protocol records from a program which allows quite a bit of flexibility. Clearly it is not possible to demand that the protocol record appears in any specific position, such at the head of a document, and thus a document has to be scanned for a protocol record which in inconvenient.
It is suggested that it would be valuable to define a means of passing data between EARN and other networks. The work at Rutherford is an example of how it could be achieved but is not necessarily the best method.
Comments are invited with a view to producing a definitive proposal.
You are invited to the ninth meeting of the Communications Group, to be held on Tuesday 11 April in the Council Room at University College, Gower Street, London.
The meeting will start at 10.30 and there will be coffee available.
1. Appointment of secretary. Unfortunately Rutherford are unable to provide a secretary for this meeting.
2. Minutes of eighth meeting. (Already circulated).
3. Matters Arising:
Comments on auto-speed select. All JTMP and FTP under linked OS. D R Peters PAD Printing and down line loading A S Dunn Improvement suggestions for products All NTI changes J Eggeton State of Yellow Book product All Improvement suggestions H Roskoss
4. Proposal for changes in methods of working. (Paper attached).
5. Comms Progress:
Release date progress for X25 products. Future communications
6. User Experience:
An open forum on user experience with GEC products.
7. Progress with HASP.
8. User presentation.
9. Appointment of new chairman
Unfortunately the current chairman is no longer associated with GEC communications and it is appropriate for someone more directly concerned to take on the job.
10. Open Forum.
11. Date of next meeting.
The communication subgroup has operated in a fairly informal manner. Whilst this has kept paper work and effort to minimum it has meant that attempts to influence GEC have been poorly defined. It has been difficult for the Group or GEC to be clearly aware of the Groups views. In fact the only record kept is the minutes of the meetings which with the best will in the world have only been a rough indication of what is needed and has put a heavy burden on the secretary.
This proposal is that requirements or views of the Group should be put in a written form to GEC with the view that this will give a clear and reasoned input to GEC. This should be of great benefit to both GEC and the Group.
From time to time topics of general interest arise which concern the Group. After initial discussions to make sure that there really is a problem, a subgroup should be set up to document the problem and provide a paper for the Group and GEC. It is not intended that such a subgroup should be large or should ever meet, only that they produce a document- preferable short and clear. In fact a subgroup may only be a single person, or may merely do its work with a phone call or two to help the person writing the paper.
The work should be continual and coordinated by the chairman. The Group meetings will review what has been happening.
It is hoped that this procedure will provide the Group with a better method of influencing GEC and will give GEC a better view of the users needs.
The Group is invited to consider this proposal.
A well attended lively meeting. CTIG was wondering what to do next after CCITT 84 - well now it knows. Three topics got aired. A hot short term topic is the Telex Network Adapter. The medium term topic is what to do about harmonization. The long term topic is CCITT 88.
BT came back with some very weak arguments as to why:-
CTIG made strong representations that the Telex Network Adapter should follow Yellow book as closely as possible. In particular the protocol ID must be include and be 01 hex and that on a set and read the read should reject parameter settings the Adapter cannot cope with.
CTIG also recommended that BT look into putting a service identification in the use data field if the user did not provide data.
The harmonization document from the EEC is now broadly accepted with the proviso that manufacturers should be able to extend the X28 interface but that X28 must be provided. The transition to the recommendations will be a topic for the next meeting.
CTIG want one or two experimental implementations to see what happens in practice.
It was considered important that CTIG start to get recommendations together as early as possible - by the autumn in fact. The current list of topics looks a bit thin. The only one of real interest is block mode working.
CTIG would like to see a further crack at attempting to make many more parameters and parameter settings mandatory. The French must be lobbied on this topic as they said 'non' last time.
The problem of X29 over session came up. CTIG do not like the idea and prefer it to be over transport. They do not see what session adds to the service - in fact it subtracts in removing expedited. They intend to oppose the ITSU proposals when they come up.
Dear Jack,
I would have liked to attend your meeting to consider the Slotted Ring document but unfortunately the notice was too short and I am unable to get out of other commitments.
I have not given the document detailed study but none the less I have a number of comments based on a first scan through. I guess the object of the exercise is to get the standard to ISO via BSI.
I am sorry that I cannot join your meeting but I would like to take part in any further discussions.
Best wishes
P Bryant.
Dear Peter,
Thank you for your interest in BITNET or EARN (as the European part is called).
It is true that I am hoping that IBM will fund lines between the Rutherford 3081 and CERN as well as between the 3081 and University College Dublin as part of EARN. I am hoping that the lines will be available in June or July if the political problems can be overcome.
The original idea was to have a number of UK sites on EARN. This was not considered wise as it would set up a network in opposition to JANET. The acceptable alternative is to have a single gateway between EARN and JANET situated at Rutherford. I have been attempting to get a licence from BT to allow EARN to operate in the UK. I now have the terms of this licence which insist on there only being one EARN site in the UK but allowing traffic between JANET and EARN. The result, I am afraid, is that an EARN line to Reading is not possible.
There are two services that we will offer. The first is for file transfer. This service will be available as soon as the lines are installed from and to sites on JANET which can provide Blue book FTP. This system has been working for some time on our RSCS links to CERN and DESY so I have confidence that there will be few problems. The second service is to provide a mail gateway between the JANET Grey Book mail and a similar mail system used on EARN. This requires some development on the 3081 which we are planning to do if we can muster some staff effort.
Accounts will not be needed for either of these services.
I hope this answers your questions but if you should need any further advice I will be happy to try and help. I should add that I am the UK representative for EARN and so all EARN questions should come through me.
The JANET/PSS gateway is now run by JANET management and not Rutherford and you should contact Ian Smith who will be happy to provide you with an identifier.
Yours sincerely
P Bryant.
Dear Michael,
Full marks for even partially understanding the JNT Naming Scheme document. It is almost impossible for a native English speaker.
Many thank for your letter. I have a problem of terminology as I tend to discuss things in terms of ISO concepts while your paper tends to speak in terms of IBM. In addition you take the view of EARN and how it must deal with gateways. I would like to have a look at the problems from a global point of view and then see how EARN fits in with such a view.
I believe we have four distinct levels of names and addresses which are:-
The problem we now have to face is that EARN operates rather like mail in that data gets spooled at each node. It is rather like CCITT X25 84 in that names in EARN are global. Thus I find it difficult to MAP the structures used in ISO like networks into EARN structures. I take the view that EARN should be considered as providing end to end connections even though it does not. This is because from the outside it is impossible to tell that it is spooling (leaving aside delays). Thus I consider that the EARN node names must be regarded as potential components in a step by step addressing scheme. Thus a man on, say, Telenet wanting to get to a local area network at Kent University (possible?) would have to supply an address of the form :-
CUNY.BITNET.RUTHERFORD.JANET.KENT.VAX
The BITNET component is needed to instruct CUNY as to the network to be traversed next. It could be implicit if there is only one network to go to or could be deduced by looking up RUTHERFORD in a table. Similarly for JANET.
Now each naming domain has selected how it deals with internet addressing between its sub networks. In the UK we have adopted Yellow Book. Within itself EARN has no internet problem since it is a single network. Thus, whereas gateways within JANET have the easy job of dealing with a single internet addressing scheme, gateways between EARN and other networks have the problem of converting from one internet scheme to another. From this I make the deduction that EARN must provide an internet addressing scheme which is flexible enough to gateway to all the networks we may be connected to. I have no idea of the totality of these networks but it is something we need to find out. The ones I do know about are:-
JANET - requires Yellow Book.
CCITT X25 84 - requires global addressing. There may be no such networks just now but there certainly will be in the future.
ISO - requires Convergence Protocol addressing.
ARPA - I am not really familiar with it but believe that being a single network it does not have an internet protocol. It does have gateways into other networks but I believe that these only operate with mail or interactive traffic where RFC 822 or interactive means can be used to make connections.
It is my belief that global addressing is a subset of step by step addressing and, as I have pointed out, global addressing is not yet in a fit state to be followed. Thus if EARN were to provide such a step by step mechanism then this would provide the maximum flexibility. The data that would have to be carried between users on EARN and gateways as well as between gateways must contain a called address and, almost as importantly, a calling address (to enable the receiver to know where data is coming from and to allow traffic to be sent back to the originator). It is highly desirable to incorporate a comments field which should be carried transparently between the user and the service. This facility is very useful for carrying 'out of protocol' information for special purposes. In the UK we term this type of activity to be between 'consenting adults', that is, the two parties agree privately about what they are doing and nobody polices their activities.
If we believe such a scheme is needed (the alternative is we all become consenting adults and fix up ad hoc schemes with others) then we have to define very exactly how it is to be done. We can first eliminate mail from our consideration since mail carries sufficient addressing information in the protocol and is designed to be dealt with easily in gateways. This leaves us with traffic to IBM machines on other networks and file transfer traffic. The transfer to another IBM machine implies that the RSCS process name has to be preserved to be presented to the IBM but apart from that it seems to have no problems over those for file transfer. I leave aside the question of how such a transfer can sensibly get into the IBM as this is a problem for that network and not EARN. Regretfully, file transfer requires more information than a called and calling address can supply and moreover the information required by a file transfer mechanism differs from protocol to protocol. I do not think it would be profitable to define some mechanism that tried to carry enough information to satisfy all protocols as this would merely be defining yet another protocol and would be a difficult job. The alternative proposition is to carry such information in the comment field I defined above.
Like you, I can see no alternative to carrying the internet information in with the data. Ideally this information should be the first record(s) in a document so that they can be easily located and manipulated. At Rutherford we have been unable to insert information in this position particularly in job output as the system insists on putting banner information and so forth at the front. Our belief is that it should be possible if someone could provide the required effort to find out how to do it and how to do it so that it is maintainable. Code is also required when jobs are executed to extract the internet information, to generate the required headings and do the necessary insertion. Gateway code is not such a problem as this would be special code which would not have to be put in every EARN machine. You will have seen the 'bodged up' way we have done this at Rutherford with 'file records'.
I am not at all aware of how much effort would be required to do these developments. I am sure they are needed and that each machine on EARN should provide the means of generating the internet headings.
The ideas outlined above are very similar to yours and really only taking the subject a bit further. It also put the problem in a broader context and in ISO and CCITT terms.
I believe that the next stage must be to investigate whether such a scheme is possible (I leave this to the IBM experts) and if so to define the exact formats to be used where I can be of assistance.
I think we should have a get together of those interested in Paris and try and decide on how to tackle the work.
I very much look forward to seeing you there.
Yours sincerely
P Bryant.
Dear David,
Thank you for your letter. I feel I will soon have to resign from Council but I was thinking of seeing the GEC year out. However if you would like to replace me I am happy to retire whenever it suits you. I will, in fact, be unable to make the next meeting as I have to give a lecture in Amsterdam.
The Deputy Director of Keele, whose name escapes me, was also willing to chair the Comms Group but I feel he was doing this under pressure and is not one of our regulars. However Iain Leitch sounds to be a useful man who we should cultivate.
Let me now turn to our ideas on the S63/40. About a year ago I was cooking up a plan to get a 63 machine and to run OS6000 on it. We had done quite a bit of planning to see what ideas we would like to pursue. I felt that the 6300 was a poor communications machine because it had no built in Nucleus. It was in fact a number cruncher. The 4000 was the reverse. The idea was to put as much of the OS4000 operating system as possible in the 4000 and leave the 6300 to crunch the numbers. To achieve an efficient system we really required a dual access disc with a channel to each machine although a lot of interesting developments could be done without it. Since the 4000 could get at the file store and understand it, it could deal with all traffic from the outside world without worrying the 6300. The 6300 would just see things appearing and disappearing in the file store and would receive and transmit some control information over a direct link. We believed our objectives could be achieved by one of the machines having a dummy CSFM which was only capable of sending messages to the CSFM on the other machine. In this way the use of the file store could be interlocked quite easily. For example if the 4000 was about to receive an FTP transfer it would open the file via its dummy CSFM which would send a message to the CSFM on the other machine. That CSFM would undertake whatever was necessary to deal with the file and return a suitable message. To the 6300 it would look like someone was using the file.
This idea is capable of considerable development. There is no reason why spooling done on the 6300 should not be de spooled on the 4000. Quite a bit of the multi access terminal code could be in the 4000. In fact bits and pieces of the operating system could be moved between the machines. There is not much new in these ideas as many of them are in the linked OS system.
In the early days before we could persuade GEC to build a dual access disc the idea was to simulate a disc channel over the direct connection between the machine.
We never looked at how such an idea would fit in with the 6300 as a UNIX machine.
I hope these notes are of help. Unfortunately we never produced much written material even though we examined some critical pieces of code.
I am finding the globe trotting a bit exhausting and I hope it does not go on much longer. Anyway I am off on holiday for a couple of weeks in the sun.
Yours sincerely
Paul Bryant.
Dear Colin,
Thank you for attending the very useful progress meeting last Thursday. I attach the minutes for your consideration.
We considered two areas where Rutherford would have difficulties providing support for EARN and I agreed to write to you requesting help.
We are funded to provide the services requested by our committees and therefore have few resources to undertake support for activities not directly related to the Council's program. This affects both equipment and manpower although we can find the computing resources and operational support required for EARN.
Where we do have difficulties is in the provision of the required communications multiplexer as all our capacity is expected to be absorbed with Council supported work. I would therefore like you to consider whether IBM could supply us with suitable equipment. At our recent meeting we thought a 3725 would be suitable. The equipment would be dedicated to EARN use and so allow for expansion should this be needed. There would be minor associated software and maintenance charges.
We also have difficulties finding the manpower to produce the EARN to JANET mail gateway. We do not have sufficient details to give an exact estimate of effort but initial indications are between 3 and 6 man months. Ideally we would like the work to be done at Rutherford so that the expertise gained on producing the product can be retained. This is possible if funding is made available to increase our staff levels during development. The funding required would be for not more than 5 months effort at the internal staff rate of 22,000 pounds per year giving a ceiling of about 9,200 pounds. May I ask you to consider whether such funding can be made available from IBM.
I appreciate the help and assistance IBM have been giving us in bringing EARN to fruition and hope that our requests can be met.
Yours sincerely
Paul Bryant.
Dear Nick,
Many thanks for your paper. Yes - I am very interested in the subject although I have not been active. I rather lost interest after I put forward my views to TSIG and John Larmouth gave them the 'big E'. Since then I believe the subject has been moribund. In fact someone was charged with producing an alternative proposal but I guess it is still at the bottom of the 'in tray'. It is not an easy subject - made more difficult by the needs of existing systems which prevent an ab initio start. Alwyn Langsford of Harwell is active in the area from the standards side and I believe his group holds the view that authorisation is something to do with applications layer. My view, not strongly held, is that session layer seems the right place. Although the finer points of layering get lost when we survey the mess of existing needs some guidance would help to sharpen the thought process. I guess the real problem is that this topic was not taken into account throughout the protocol invention process and we are now left with a grafting job. I am tempted to say 'better luck next time round'.
Forgive me if I use the term 'authorization' instead of 'authentication'. I realize they are different but they seem inextricably connected. I lump the two together.
I forget whether you were in on the TSIG fiasco so I will briefly review my thoughts at that time. I was primarily interested in authorization to go through a gateway. I use the word 'gateway' to denote some point where onward connection may be denied or allowed. I recognized, as you do, that the world is made up of domains interconnected by these gateways. I regarded each domain having independent management which gave rise to the concept of a gateway being 'double' in that permission to get out of a domain was needed as well as permission to enter the other domain. I believed that one could not trust other domains. If I read your scheme correctly you are willing to trust the authentication servers in other domains which is interesting.
Getting down to the mechanics of the scheme. I saw two viable schemes. The first followed the global view of the world in which the user provided some global information which would be checked at each gateway. For example, a specific user id and password combination would be known about at each gateway. The second followed the concatenated view in which the user provided a string of bits of authorization information and the relevant bit would be peeled off at each gateway. I followed the latter view as this was in keeping with the way that we saw addressing working. On more mature thought and forgetting how we implement, I believe both schemes could be defined in a single standard - but I have not had time to explore this.
In implementing a scheme for JANET I had severe problems. I could not introduce a new bit of protocol at any level as the coloured books are now cast in concrete and any changes would have been forbidden. I felt that as the authorization was to be done at gateways then one would not want to go above transport layer even though my gut feeling was that session was the place. Even if session was the place there is no relevant coloured book. I therefore felt transport was the place. The added protocol had to be put in transport so as not to effect the standard. A new field called 'authorization' would have been ideal. I thought about the comment field but here the danger is that implementers may well decide to corrupt this for legitimate reasons. This really only left the address field. I therefore proposed that each address element should be followed by an authorization component. This was quite nice as the right component would come up easily at the gateway. (I ignore the small but important point that address gateways are not the same as authorization gateways - but this can be solved easily). Thus the scheme was that the user should supply the authorization information which would then be carried to the gateways for checking. Like you, I noticed that this scheme could easily be extended, in concept, to cover authorization to use any facility in the network. For example, an interactive service has a gateway in front of it which extract the normal 'logging in' information from the transport level. It all looked very neat and tidy. But it did not fit in with JTMP authorization for reasons that I still do not understand.
From the authentication point of view, like you, I envisaged an authentication server. I envisaged one per domain. All computers and gateways could access this. It would contain all information relevant to use of facilities- User ids, passwords, allocations, and just everything. As resources were used it would keep records and perhaps cut off resources. This would be very expensive in terms of network traffic to run so I envisaged each authorization point keeping a cache of information. Keeping that lot in step in a large network is an interesting problem. I notice that you do not favor this. At Rutherford it would have been useful for our Resource Management group who could have done all their control of all our machines from one data base.
Before I turn to your paper there is one more interesting initiative. ESPRIT got Michael Purser to do a study with a view to setting up an ESPRIT virtual network. He put forward the view that ESPRIT should have an authorization server (or a number of them). He saw all traffic as going via this server and not just getting information from it. Thus if you wanted to get to service X you would access the server which would then onward link you to the service and log you in or whatever. The server would have some sort of 'standard interface' for the user. This proposal was not very well received. It was clearly expensive in network resources. It would take a lot of effort to set up such a system and be costly. Perhaps the common thread of all our ideas is that in some way there should be authentication servers around.
Let me turn to your paper. You envisage the security servers being able to talk to each other and be trusted. This seems fine in a well ordered world where the control of the servers is guaranteed. In the university community (not well ordered) I do not see how I can trust a server in another domain. For all I know the server may be being run by a load of network hackers intent on destruction. Thus I would be happy to trust another server for access to facilities in another domain, I would not trust him in allowing access to facilities in my domain.
I was unclear as to why a Token had a limited lifetime. I can envisage some applications where access is for many hours at a time- for example, users of our PROFS system log in at 8.30 and off at 5pm.
There seems to be problem if a Security Server fails. After a short time the Tokens will become out of time and I suppose everything could potentially stop on all machines.
In section 4.2 it seems difficult to determine the route between the Host and security server as the network may re route calls or attempt to load share calls over several routes. It seems a strong requirement that the link cannot be tapped by outside users. The networks we are using are becoming very complex and to ensure the security of a network becoming progressively more difficult.
In section 4.3 I ask what happens if you decide not to trust the server in another domain. I guess the reply is you just don't communicate. Why do you only have to assume that communications in another domain are 'moderately' secure. Security seems to be an absolute attribute
Section 5 is where the scheme may fall down for JANET use. There is considerable, and increasing traffic to and from JANET from domains which can be regarded as anything but secure. These domains would not wish to be involved in any security scheme parochial to JANET. The only way to deal with this sort of traffic seems to be with gateways at every point into and out of JANET which would do any authentication. There is an interesting problem, that I really never got to grips with, of how you allow people in other domains to reply to mail. Clearly you cannot have everyone who you may want to receive mail from to be in the tables on the other hand you have no way of knowing that a call is mail unless you start un picking the higher level protocols.
I like the idea of the Server logging all unsuccessful attempts to access the network. We do this with our file transfer so that a user can see if someone is trying to get at your file store.
I would not like to put any specific length restriction on a token. All too often any arbitrary length restriction turns out to be too short.
Section 7.2.1 contains the interesting comment that Tokens will only be used in NIFTP if both end agree. From this I assume that any network will contain secure and insecure parts which seems at variance with the tone of earlier parts of the document. From your comments here I gather that Security information can travel in a high level protocol. Of course it is difficult to know the exact level of elements of NIFTP!
To make the type of security system you propose work (or most other security systems) the hosts will have to be provided with the relevant code. This would seems to be a significant task.
I am not optimistic that such a scheme could be widely used in JANET. The arguments against it would be:-
My personnel view is a little different. I like the idea of the Security Server as I think this is needed if you want to keep overall control of your resources. My inclination is to prefer a system where each secure facility, on receiving a call, goes to its Security Server to ensure the authenticity of the user rather than the authentication being performed before any connection is attempted. Such a scheme removes the element of 'trust' which makes me uneasy. It maybe that both schemes are or could be facets of a single scheme.
I hope my comments are of interest and I will follow progress with interest. Perhaps I should apologize for not being able to spend as much time on your paper as it deserves and have probably misunderstood a few points.
Yours sincerely
Paul Bryant.
Dear Peter,
I have a few updates for the next version of the document.
Delete the three 'Draft' documents under EEC and replace with:-
COS-3 Local area networks COS-4 Triple X - CCITT X.3, X.28, X.29 COS-5 Session layer Recommendations on MHS (X400) under preparation.
I have omitted the 'presentation' document as this seems unlikely to appear for a long time.
Yours sincerely
Paul Bryant.
Dear Rick,
I enclose the COS document for distribution to CTIG.
I spoke to a PHILL ASHBEE who is the manager for international TELEX and lives on 01-936-2191. It seems BT intend to offer a new product which will be like the TNA but will spool TELEX messages. It seems that this one will also use triple X but in this case one will have the added advantage of being able to go in via a PAD and pick up your TELEX messages. He tells me that the design is not yet finished. I impressed on him our desire to have a look at what they are doing before the design is frozen. He has agreed to think about coming to the next CTIG meeting to talk to us about it. It was left that I would contact him just before the agenda was made up to see how he felt. I think he will come. Could you bare it in mind to contact me at the appropriate time. I should add the good news that this new animal will come with international TELEX.
I also attach a paper I got from JNT which is believed to be the block mode that George described in some detail at the last meeting.
Best wishes
Paul Bryant.
Attached is a paper approved my NDM which defines a proposal to reorganize dial up services. This will save a useful amount of money, free off a bit of floor space and provide added features such as 1200/1200 working.
May we proceed with the proposal? I expect Peter Blanchard to organize the work and to pass the completed installation to operations.
A very good pair of meetings.
Networkshop was on a high plane and much of the rubbish talks were cut out. In particular we were spared long rambling progress reports. The move to ISO protocols was an important topic as was JTMP. LANs were not as much in evidence as I would have expected. The parallel sessions, contrary to my expectation, were quite good and led to some useful progress.
The ECFA meetings are still concentrating on getting all the European Labs to a sensible level of networking. The X25 at CERN now looks to be about to become a good service with sensible connections into our network. The local area work concerned with the use of connectionless services looks to be important. EARN came in for some humorous discussion, this is now falling fowl of the European PTTs. Beware the satellite. Mervyn Hine is cooking up a project with, amongst others, John Burren to use a satellite for an HEP service. We must watch this.
The workshop had a lot of discussion on JTMP and the feeling is that services will become available quite soon, say the autumn. The VAX version is reaching completion as is the GEC and UNIX ones. There were a few acid remarks about the GEC one and why RL had abandoned it. If statements are to be believed the official IBM version is now near to completion but will need a series one front end. I suspect we will start to be pressured for service dates in a few months.
It seems that the Name Registration scheme will be a long time a-coming. There was a discussion on naming and it is very evident that the NRS is urgently needed. The name situation is now chaos as mail and JTMP are having great difficulties. The main problem is that few if any machines can cope with NRS unless they have the privilege of running the Salford JTMP. Even then the data base is not yet ready.
Considerable discussion was held on this topic. It is clear that gateways between old and new protocols will be needed. There will have to be considerable planning especially for places like RL with a multiplicity of machines. This will require some skilled staff to be around if it is not going to be a shambles going on for years. THIS IS A WARNIMG.
The X25 CERN network is now coming into being. We plan to have a gateway between our switch and the CERN switch. This will be the existing work station. WE WILL HAVE TO LOOK AFTER IT.
Mervyn Hine is working up a satellite project for HEP to be financed by the EEC. This is intended to be a service. We must take a strong interest in this. Mervyn has been talking to John Burren and Kerstein. I encouraged him to talk to us if it is indeed expected to be a service.
The EEC Harmonization is being heavily supported by CERN which is excellent.
There is quite a bit of interest in the full screen Cifer, in particular in Upsala and Oxford.
CERN are now doing a lot of work on the development of connectionless services based on the new ISO standards. THIS IS VERY EXCITING AND IS CERTAINLY THE WAY TO GO FOR DATA COLLECTION AND NEWCASTLE CONNECTION. We should follow and support this work if at all possible. It will need effort. I suggest we send someone to CERN for a few weeks to find out exactly what is happening.
Dear Colin,
I enclose a letter from Chris Hobson in reply to a letter from me seeking clarification of a few points. I also attach my original letter. The letter clears up a few points and I make a few comments keeping to the paragraph numbers in the two letters.
2. Authorization. I have tried to get details of the CUNY code from Ira with no success. My electronic and paper mail gets no reply. I think we must get this sorted out in Paris.
4. Israel looks to be a problem as contrary to popular belief they are not in CEPT. Thus charges to Israel will be heavy.
5. It looks like the PTTs have got their act together which, I hope, means that in future they will be speaking with one voice. The various separate talks going on throughout Europe was causing a very confused situation. The last I heard from Dennis Jennings was that he was thinking of running his line to Paris rather than Rutherford to avoid charges, this should at least stop such nonsense. None the less the charges are very high particularly as both ends will be charged.
The last paragraph is a little depressing as it seems to add more delay. I had encouraged Chris that CEPT should talk to the 'Board of Directors of EARN' as I thought IBM did not want to appear to be running EARN. If CEPT does insist on the use of the public networks then I suppose we will have to see if we can run RSCS protocols over X25. This would, of course, avoid all the nonsense we are getting involved with and would be a useful product irrespective of EARN.
I enclose the documents from BT for the CERN line for your records. As you will see they do not mention EARN but do indicate the UK cost.
Have you made any progress with the agreement? Since we are now liable for charges my management is getting anxious.
For the record may I confirm that I have an agreement with my management for the Hursley link that that IBM will not be progressing this until the EARN license is finalized.
I look forward to the Paris meeting.
Yours sincerely
Paul Bryant
Dear Steten,
I enclose the spec of the full screen Cifer which imitates an IBM 2780 over an asynchronous connection. As you will see it really provides an alternative form of framing.
I also enclose a user spec for the Cifer and the IBM PC version. Both of these should work over an X25 network as long as the PAD is capable of dealing with PAD parameters correctly.
I can supply you with a copy of the IBM PC code if you have a machine to run it on. It is an enhanced version of KERMIT which I originally got from QZ. I am not happy to release the code yet as I am still working on it but I would be happy to send you a version in binary on a disc. I am not sure that I can transfer binary to QZ. Let me know if you want it via QZ COM.
I hope you will find it useful.
Yours sincerely
P Bryant.
Dear Will1e,
I enclose the spec of the full screen Cifer which imitates an IBM 2780 over an asynchronous connection. As you will see it really provides an alternative form of framing.
I also enclose a user spec for the Cifer and the IBM PC version. Both of these should work over an X25 network as long as the PAD is capable of dealing with PAD parameters correctly.
I can supply you with a copy of the IBM PC code if you have a machine to run it on. It is an enhanced version of KERMIT which I originally got from QZ. I am not happy to release the code yet as I am still working on it but I would be happy to send you a version in binary on a disc. I am not sure that I can transfer binary to Oxford. Let me know if you want it via QZ COM for speed or Oxford COM for slow.
I hope you will find it useful.
Yours sincerely
P Bryant.
Dear Nick,
I enclose a number of papers you may be interested in. They come from CERN where there is now considerable activity to foster the new ISO connectionless network service over local area networks.
You will see that the work is still at a primitive stage but none the less is very interesting.
There have been a number of meetings to foster the work and I hope to go to an ESONI one in Brussels in the near future. There are some hopes that some EEC money may be available.
My view is that this protocol is the best bet so far for data collection and like activities which, I guess, are important in the industrial field. I should think the work would be of great interest to the MAP project you are involved with. The protocol still leaves a lot of questions unanswered such as what protocols to run over it. Pending further ISO standards in this area, which will be a long time coming, one could well imagine that the remote procedure call or Newcastle Connection style of working would fit over it. A nice benefit from running the protocol over LLC1 is that it does not preclude the running of other protocols, possible connection style.
I hope you find the papers interesting and can make use of the work.
Yours sincerely
Paul Bryant.
Since the last meeting of the group the outline proposal paper has been considered by ITSU in order to determine whether they are prepared to support the work.
I have had further discussions with Di Davis of ITSU and Dr. Manning of Rutherford Laboratory to see if the project can be progressed and I am optimistic that we can get support. Although I do not have a definitive statement from DTI I believe we should prepare for the next stage. The next stage will have to produce a detailed program of work.
The development of the program of work will be based on the following considerations:-
I would like to prepare for the next phase of work in anticipation of a favorable response from DTI which will take a month or so. In the mean time I would like you to consider whether you wish to participate in the next phase which is based on the assumption that the participants will want to join the consortium. May I therefore ask you to consider whether you wish to join and let me know your position in the next month.
If you know of other companies who could join the consortium I would be happy to approach them if you would let me have their names and possibly the name of a contact.
I enclose a later version of the FDDI standard.
I hope you will be able to participate in the work.
Yours sincerely
Paul Bryant.
ESONE is the European organization which is interested in data collection and experiment control in research laboratories. they were responsible for CAMAC. Some time ago they felt that they ought to initiate work in the utilization of LANs in laboratories.
At the ESONE Berlin meeting (see relevant meeting report by the author) there were a number of papers on LANs and a lot of encouragement to make some sort of initiative. The result was a meeting in Brussels (again see the relevant meeting report) at which a number of papers were presented which gave some guidance. Since then there has been very little action and it seemed that no one had much idea how to proceed.
This meeting was set up as a make or break meeting. It the response was negative then the project would be abandoned.
12 people attended representing the major laboratories including CERN, HMI, DL and RL. Ted Owen chaired it. There had been quite a number of apologies from people supporting the work.
The first afternoon was dead boring as the discussion rambled round the subject. As usual with an open ended discussion the topics were too broad to lead to anything useful.
At this point, let me point out that CERN have been working on a project to exploit the new ISO draft for a connection less network layer. I believed that this was the right approach and had encouraged Mike Sendall from CERN to put it forward at the meeting. Aver the booze we decided some steam rolling had to be done if progress was to be made.
The next morning session soon came round to the proposition that connection less services were needed and that the CERN work should be followed and fostered. The discussion was then mainly about how to proceed.
The secret of getting progress was to narrow down the aims of the work. Ideas of open systems connection over wide areas and then over a connection less local area was a subject for further study. In addition the applications which could not make use of connection less services were also treated to 'further study'.
The result was that some documents and proposals will be produced and a conference will be held in the autumn to launch the project.
The proposal will cover:-
The work items for the immediate future are the production of three documents which will be contributed to by members and developed into a proposal. the documents are:-
Reasons for the requirement for connection less services. Some experts believe that connection less service are not required and that everything can be done over connection ones. This group did not agree but did believe that a convincing case must be made if funds are to be obtained. The editor will be Paul Kummer.
Outline of the protocols required over the network layer to enable a project to define these protocols to be made. The editor will be Paul Bryant.
Draft proposal for a program of work. Editor Ted Owen.
The time table will be:-
I think that this is an important initiative as I see LANs as having an important part in the laboratories and that standards in this area are important. We can already see the results of lack of standards in that the Bubble chamber group and SNS are 'doing their own thing' and there is no possibility of encouraging them to follow standards until there are standards.
I would encourage any one with ideas in this area to share them with me to help the work along. As usual there will be 99% sweat and toil and 1% glory and a lot of discouragement before we get anywhere.
While in Brussels I had further discussions on ESPRIT communications. They are absolutely dedicated to communications and standards as a vital and important part of their work. They now have a number of contracts supporting this. They have consortium putting in LANs which are committed to providing ISO standard protocols. In particular they are pressing ahead with TELETEX as fast as they can and putting in heavy resources. It is disappointing that Alvey is not following their lead. The Committee Support Scheme (CSS) is being very heavily pushed as the best way of controlling ESPRIT. ESPRIT has installed a COM system in Dublin as the best way of keeping workers in touch with each other and this is becoming very valuable.
Dear Dr. Schlinder,
I have been discussing the needs of the Alvey directorate for communication between the members of committees. These requirements are very similar to the needs of ESPRIT and I am attempting to influence Alvey into adopting the CSS ideas. This is a difficult task due to the lack of components which are available just now and the difficulty of giving some sort of demonstration on which to base a proposal.
I understand from Ken Thompson that you have developed a TELETEX package of hardware and software for the IBM PC which could be very valuable in helping my case. Unfortunately I did not visit the Hanover Fair where I understand your system was demonstrated and well received. I really would be most grateful is you could give me details of the development. I would be very interested in your plans to manufacture and market the product and what the cost will be. May I also enquire whether I would be able to buy two sets of equipment in the near future on which to conduct an evaluation and demonstration.
May I thank you in anticipation that you will be able to help me.
Yours sincerely
Paul Bryant.
CCP asked John Barlow to organize a meeting to consider the standardize the use of microprocessors within SERC. The meeting had representatives from all the groups concerned with microprocessor developments. There were also representatives from CERN.
John had produced a report some two years ago and the initial idea was to see what various groups were doing and to update the report. In fact the results of the meeting were very different and quite exciting.
There are many groups in SERC who use a variety of processors and a variety of techniques. It was very clear that most were ignorant of each others existence and they were all more or less 'doing their own thing'. If nothing else the meeting indicated many areas of potential cooperation.
CERN has standardized their use of micros and David Willams described this.
It was unanimously decided that CERN should follow the CERN lead as closely as possible. Doing this would allow SERC to obtain products and experience at a very low cost and would also encourage cooperation to continue to the mutual benefit of CERN and SERC.
The CERN standardization scheme is caller PRIAM. The standard in brief is:-
It is likely that SERC will require some support for LSI11 products.
It was decided that the CERN method of working should not be changed. Thus a coordinator for the SERC activities will be required and there was some worry that SERC would be unwilling to appoint someone at a sufficiently high grade. It was recommended that SERC should have its own newsletter rather than use the CERN one.
It was definitely not recommended that a central group should be set up as it was felt that such a group would demand projects and the other groups would be suspicious of it and this would have a negative effect on cooperation.
A VAX UNIX system will have to obtained to mount the CERN software on. It was not recommended that any other type of machine should be used as this would require the CERN software to be checked out on that machine and also it would prevent the free exchange of software with CERN.
I believe that if the report to CCP reflects the feelings of the meeting outlined above then the work should be supported. It is vary rare to attend a meeting with such a high degree of agreement and such a willingness to cooperate.
Network facilities are provided to the UK universities and associated organizations by the Joint Academic NETwork, JANET. JANET is a large X25 network based on about 12 switches distributed around the country. Most of the 100 or so universities and associated sites are connected to the network. Many of these sites have quite substantial local area networks based on X25, Cambridge Rings or Ether nets and these are connected to the wide area network. There are now about 250 connections to the network from local area networks and computers. Gateways are provided to the public packet switched network and ARPA. A gateway to EARN, the European Academic Research Network, is being planned. The high level protocols, which provide file transfer, job transfer, mail and interactive services, were designed by the community and there is now a plan being formulated to move to ISO protocols in the next few years. The network has been developed from very humble beginnings in 1977 and will be developed further as demanded by the universities.
Dr. Paul Bryant gained a mathematics degree and a PhD in applied mathematics from Southampton University in 1959 and 1962 respectively. In the early 1960s he looked after the system software on the Atlas Computer at the Rutherford Appleton Laboratory. Atlas was one of the first paged computers built and for its time had a very sophisticated operating system. In 1970 he led a team looking after and developing the George III operating system on an ICL 1906A. This work led to the development of a front end processor dedicated to networking which allowed the machine to share HASP work stations initially provided for IBM computers. His network interests developed further with the installation of a large number of GEC mini computers in universities departments which were connected by means of an X25 network which eventually became the JANET network. These machines provided an interactive service to engineers. He has been very active in the development and promotion of JANET and also the protocols used over it.
The United Kingdom universities and Research Councils are funded by the Department of Education and Science (DES). The five Research Councils fund research mainly in universities and also operate a number of establishments for the benefit of research workers. In the early 1960s DES recognized that computing was expensive and it decided to fund computing via an organization known as 'The Computer Board for Universities and Research Councils'. The board was set up following a report produced by a working party chaired by Professor Brian Flowers. Following this report the Board decided to set up a number of large scale sites which would supply resources to smaller sites. The smaller sites would have more modest equipment. This scheme exists to this day. Each large site tended to specialize in a particular manufacturers equipment there being IBM, CDC and ICL specific sites. The smaller sites were free to select the equipment most suited to them but baring in mind the size of the site, its requirements, its history and often government purchasing policies. The result is that the universities contain a very wide range of equipment from many manufacturers.
From an early date it was clear that postal services were unsuitable for distributing computing power from the large sites. The turn round was far too slow and it was costly. It was therefore not surprising that networks of remote job entry stations (RJEs) sprang up round the large centers in the early 1970s. These were most often based on RJEs supplied by the manufacturers of the central machines or 'look alike' equipment. Favorite equipment was based on the Hasp protocols, CDC user 200 terminals, and ICL 7020s.
These networks worked quite well and grew large. It became apparent that the networks were becoming a problem as many sites became equipped with a number of different RJEs to obtain services from many central sites. Several attempts were made to rationalize the situation which were only partially successful. The Science and Engineering Research Council (SERC) set up a packet switched network based on the public Experimental Packet Switched Service (EPSS) ideas. This network connected a number of IBM computers and an ICL 1906A in a network with 20 or so EPSS remote job entry stations. Switching took place in the IBM computers or, in some cases, front ends. The stations provided for a small number of interactive terminals and used HASP protocols inside the EPSS frames, this was known as 'packetized HASP'. In the London area a network called Metronet was set up. This was a store and forward network based on a number of large machines in London and elsewhere. The protocols were the normal manufacturers remote job entry protocols and protocol conversions took place in various computers. Edinburgh set up a packet switched network based on packetizing RJE protocols in a similar way to the SERC work. The southwest of England were lucky in only using ICL equipment and set up a packet network with a CDC 1700 acting as a switch. This was unusual in operating over 48K lines. There were a number of other developments which fitted into no pattern.
In the mid 1970s it became very clear that the university networking needed some sort of coordination and rationalization. To achieve this the JNT was set up under Mervin Williams and Roland Rosner. For some time activities centered round fostering the existing networks and encouraging universities to cooperate in their use.
A useful activity fostered by JNT was Networkshop. This was a workshop run once or twice a year which considered the universities networking needs and how the needs could be met. The workshop has been a very valuable way of fostering developments and cooperation and has become very popular with 200 or so delegates attending the 1984 one at Bath.
It soon became apparent that the only long term solution to producing sensible inter working was to find a set of standards for university networks and to promote their use vigorously. Any other policy would never produce a coherent network. Such standards would have the objectives of allowing any terminal to connect to any host, allowing files to be moved between any two machines, allow jobs to be submitted from anywhere to any host and to provide mail services. As well as standards some way of implementing a network would be needed.
In the late 1970s the standards were largely agreed. In the early 1980s plans were formulated to set up the JANET network. The standards were encouraged by making the provision of suitable hardware and software a requirement in tenders for new computers. While this has been helpful it has not been entirely successful as there are a great many special cases where the type of computer was more important than the provision of network products.
SERC provides computing resources to many scientists in the universities and was thus very active in developing networking from an early date. They are also closely associated with the JNT in that both come under the Department of Education and Science. Also the JNT were located in the Rutherford Appleton Laboratory which is part of SERC.
In 1977 two very important activities took place. The first was that the X25 standard was published. The second was that SERC was charged with installing a large number of mini computers in university sites for interactive use.
SERC had been using techniques developed from the British Telecom Experimental Packet Switched Service and had expected that this network would become a public service in the UK. It became apparent that this would not happen. Unfortunately the EPSS protocols were completely different to the X25 ones and it was clear that X25 would be the only acceptable standard for public packet switched networks for the foreseeable future. A decision had to be taken as to whether to continue with the EPSS technology or abandon it in favor of the emerging X25 standard. To continue with EPSS would have been the least disruptive but would have led to SERC having a network with obsolete protocols with the attendant problems of support and maintenance. The decision, taken after much heart searching, was to follow X25. This 'clean start' was valuable since it allowed the network expertise acquired in the EPSS development to be used with great confidence in producing the products required in a very short time. It enabled the mistakes of the past to be given a decent burial.
The primary product was an X25 switch based on a GEC mini computer and this was completed in 1977. Three other products followed. The first was an X25 implementation on the IBM machine. The second product was a work station based on a GEC 2050. This was convenient as HASP work stations had been developed for this machine and so there was a lot of equipment and expertise available. The third product was X25 for the GEC 4080 mini computers which were being installed in the universities for the interactive project. All these software products were developed by the Rutherford Appleton Laboratory. Similar products were developed at Daresbury Laboratory, a sister organization near Manchester.
High level protocols were provided by an odd assortment of products. Job transfer from the work stations and minis was achieved by 'packetizing' HASP. This was a cheap and very effective technique as a lot of software already developed could be reused. Interactive services were provided by a protocol called Interactive Terminal Protocol (ITP) which had been developed as a by product of the EPSS work. File transfer was only available between the GEC minis and used a newly defined protocol which later became the famous 'Blue Book FTP'. All the equipment used bi-synch instead of HDLC as HDLC equipment was unobtainable on any of the machines.
The most remarkable observation was the speed and cheapness with which the network was put together and how well it worked. It took a year to complete this first phase which brought it to a reliability and performance comparable with the RJE network it was replacing. All the equipment required was re used EPSS equipment or other redundant items.
The next few years saw three areas of development. Firstly the number of types of machine increased to a dozen or so. Secondly the size of the network rose from a half dozen hosts to over 200. Thirdly there was the gradual introduction of better protocols and the phasing out of old ones.
The first new machines added to the network were PRIMEs and PDP10s which were being installed as part of the interactive network. The PRIMEs were unusual in that the manufacturer was offering X25 at a very early date. PRIMEs had the problem that they only offered X25 over HDLC whilst the switches were still operating with bi-synch. Considerable work had to be done to adapt it to the SERC use as it had hitherto only been used for PRIME to PRIME communications. In addition the high level protocols had to be provided. The DEC10 product was in the form of a gateway between SERCs network and DEC NET. This work was done at York University. Later VAX computers and Honeywell were added as a result of work at the University of Wales Institute of Science and Technology and the Natural Environment Research Council respectively. Many other machines have now been added. In fact there are now few machines which cannot be connected. Unfortunately new machines arrive faster than network code can be developed.
The increasing size of the network led to the installation of several more switches around the country. This was a gradual process and although such an expansion had never been expected there were no great problems. Perhaps the most worrying aspect is the lack of any good management facilities. The only method used is for one of the hosts to try to make a call to every host in turn and so find out if it is responding. From the resulting data the state of various parts of the network can be inferred. It is surprising how effective this technique is especially when the information is displayed on colour screens with facilities for switching between various screens.
During this period considerable developments had taken place in protocols. The academic community had more or less decided that X25 was the way to proceed and had set out on a path of defining the high level protocols needed. The resulting protocols are collectively known as the 'Colored Book Protocols' and provide for file transfer, job transfer, mail and interactive use. In SERC these protocols were adopted as quickly as resources would permit. The first to be adopted was the Blue Book file transfer protocol which was essential for moving software around the interactive machines. The second move was to adopt the so called triple X interactive protocols from CCITT which took the place of ITP. Mail, which follows the ARPA RFC 822 standard, was a popular development which was defined and implemented in a short space of time due to user demand. The Red Book job transfer protocol is the last to be adopted and, in fact, this task is still far from complete. A number of related products were developed. The most important was a gateway to the public packet switched service. This had to deal with authorization and address translation problems. The product has been heavily used for making interactive calls to other countries. It has also allowed other countries to access the machines on JANET. University College London developed a gateway to ARPA. This gateway provided interactive, file transfer and mail facilities and has been an important link in allowing the UK research workers access to universities in the USA.
The manufacturer involvement with the development of the network was very disappointing in almost every case. Whilst no obstacles were put in the way there was very little encouragement or support. Until 1982, that is a period of 5 years all code, with the exception of the PRIME and VAX x25 products, was produced in the community. Even now many products are not manufacturer supported.
A reason for the lack of support was probably that the high level protocols being used were UK standards and not international ones. None the less quite a few of these products are being adopted as they are proving to be in great demand outside the community. This is because there are very few ways of communicating between heterogeneous machines over X25 networks. In the USA the major use of X25 has been for interactive services and the interest in other protocols has been fairly small. The same comment holds for the UK public network. The reason for this is in part due to the tariff structure favoring low volume high connect time calls.
Although there had been a firm decision to develop an academic network in the UK in 1980 it took 2 years to decide how to do it.
There were a number of options. First, the public packet switched network could be used. Second, a bran new network could be set up. Third, the SERC network could be expanded to be JANET.
The use of the public network posed a number of problems. The main difficulty was the tariff. It was estimated that a private network would be cheaper. In addition it was felt that if traffic was to be charged on a volume basis then it would inhibit the use of the network and the idea was to encourage its use in the interests of cooperation between users, economization of equipment, development of mail and so on. It was also felt that the organization to deal with charging would be very costly. It was apparent that the PTT was not very willing to negotiate some sort of deal with the community to make the use of the network financially and organizationally acceptable. There are some worries that decreases in packet switched tariffs and increases in leased line tariffs could make the public service more attractive.
The development of a new network was not seriously considered as the recruitment of staff, obtaining of equipment and organization would be difficult and expensive.
The further development of SERCs network was attractive as this formed a ready made infrastructure on which to develop. The network already had links to most universities and there were many man years of experience in place. The work involved in this option was merely to expand the network and in many cases to reuse the lines to sites for the good of the whole site rather than the small groups the lines were provided for. Often this could be achieved by connecting the network to any developing local area network on the site. Unfortunately the network will take part in third party switching which requires a license. Discussions on a license are currently being held with British Telecom who look after regulatory affairs until 'privatization' takes place in mid 1984.
It was in 1983 that the network was transferred from SERCs management to a new group called the Network Executive. The transfer of power was not as traumatic as it might seem as the network was still to be run by the same set of human beings.
JANET will eventually consist of an X25 network with a connection to each university or similar site. This adds up to about 100 or so sites. On each site there is or will be a local area network to which the computers and other equipment will be connected. JANET connects to a number of gateways providing services to the public packet switched network, ARPA and EARN. There will be a number of services providing directory and similar services. There are an increasing number of value added services such as conferencing systems for the common use of the community. The network uses a common set of protocols.
The development is ambitious but a considerable part of the network is in place and future developments will be concentrating on improving the network in many ways rather than any grand new developments.
This now consists of 12 or so switches in various parts of the country. They are installed in existing university computer rooms where they can be looked after by the existing staff and thus installation and supervision has been cheap. It is fortunate that many sites have considerable network experience from earlier activities.
The lines between switches operate at 9.6K and in several cases multiple lines exist between switches to provide the required capacity. It is hoped to replace these lines by Kilostream which provides digital links at 64K (48K realizable). This will take a year or two due to the poor coverage of the UK with this service. In time Megastream, 2M, lines may be installed. This will require some expenditure as the current communications boards in the switches cannot run at this speed. It is doubtful whether the software can operate at that speed either.
The Switches are based on the GEC 4000 series computers. The software was developed at Rutherford Laboratory but it is hoped to move to manufacturer supplied software soon to ease the maintenance problems. The manufacturer software should provide much better management facilities which are sadly lacking in the Rutherford product. The larger switches have a throughput of 700 packets per second. This is satisfactory for the present but in the future either GEC or some other manufacturer will be expected to supply switches with an order of magnitude better throughput.
There is a small team, called the Network Executive, based at the Rutherford Laboratory which manages the network. This team is also responsible for long term planning. Liaison with the users is by means of regular meetings held in the various regions of the country.
Sites are encouraged to provide local area networks and the Joint Network Team give then help and encouragement. The team also ensure that these local area networks conform to network standards so as to allow them to be connected to JANET and also to use components which are common to many sites.
Most sites, currently between 20 and 30, have opted for X25 local area networks. This is an easy decision as all the products developed for wide area networking can immediately be used on the local area. The main problem with this approach is that X25 networks have a relatively low performance and a relatively high cost.
Several sites have adopted Cambridge Rings. This technology has been slow to develop and there is still a lack of components. There are some worries over the long term future of the technology unless it can get some ISO stamp of approval. None the less it is an elegant form of network and is providing good and interesting services. The Joint Network Team have put considerable resources into developing components for the technology.
Several sites are intending to adopt the IEEE CSMA/CD standard. This is so far poorly developed in terms of the software products needed. In addition the definition of the these products are still under discussion. The main problem is that there is an understandable temptation to use ISO protocols whereas the wide area uses the colored books. Thus gateways will be needed.
There are one or two sites which, contrary to policy, have developed their own technologies. There is a feeling that too much standardization will stifle innovation so perhaps such activities should be allowed in small quantities.
The Joint Network Team have supported and financed many developments of components which have been required by the community. Contract have been placed with both industry and universities depending on who was best suited to produce the products. Of particular note was the development of an X25 PAD. A PAD is a Packet assembler Disassembler which act as a terminal concentrator. The initial product was developed by a university and then manufactured and marketed by a small company called CAMTEC. Universities have invested heavily in these PADs. The development of Cambridge Ring equipment has not been so successful but this has been a very advanced area to work in.
In general it has been found that the small companies have been much more willing to undertake projects whereas the large companies have generally only been prepared to offer advice. This attitude seems to be changing as computer manufacturers become more interested in communications and as interests shifts to ISO protocols.
For the time being the colored book protocols are in use. This is because there are now implementations for most of the protocols on most of the machines and thus interconnection is easy. There are 5 colored books.
Green Book is not a standard but is a recommendation on how to use the triple X CCITT interactive protocols X3, X28 and X29. The document ensures that the protocols can be used to best advantage. The Book defines how these protocols can be used over a transport service as this is important in going between the wide and local area networks.
Yellow Book defines a network independent transport service. It also defines an internet protocol to allow traffic to pass between local and wide area networks via gateways.
Blue Book is the oldest protocol and defines a protocol for file transfer. It had its origins in the Experimental Packet Switched Service. This protocol is quite widely used outside of the UK academic community. It is a complex protocol which allows files to be transferred to and from any reasonable file store.
Grey Book defines a mail protocol. This standard was put together in a hurry and is basically the ARPA RFC 822 protocol. It used Blue Book FTP to move mail around. The choice of RFC 822 is fortunate as this protocol is also used in ARPA and EARN and eases the production of mail gateways to these networks.
Red Book defines a protocol for job transfer and the manipulation of jobs. It also uses FTP to move data about. This protocol is fairly complex and there it is only now that a few implementations are coming to fruition. The protocol allows a job to be launched which can collect other files as it travels to its destination. The job can launch other jobs as it progresses. Output generated can be returned to any machine. Facilities are provided for tracing the progress of a job and controlling its progress.
Unfortunately the Colored Book protocols are not the ISO protocols. The community is dedicated to moving towards the ISO protocols. This is sensible since few manufacturers are interested in supporting Colored Books but on the other hand considerable pressure can be put on them to produce ISO products. The transition will take some 5 years (the authors estimate). It will have to be done carefully if users are not to be upset. It will be achieved with the use of gateways between the old and new protocols of one sort or another. It is likely that a machine will only be moved to ISO when a complete set of protocols exist for it rather than taking a piece meal approach. This is thought to present least upset and danger. It is hoped that other countries academic networks will adopt the protocol, this will lead to the easy interchange of information between academics.
The UK community has been very active in the standardization committees to ensure that the new protocols are sound. Their experience with the Colored Books had paid handsome dividends in speeding up the ISO work and encouraging manufacturers to be interested. The work of the EEC in harmonizing the European academic networks is exciting as is the work of the UK Department of Trade and Industries work in promoting ISO. It is hoped that this work will lead to manufacturers producing products for the community. The community is unwilling to produce products for the second time and would prefer to concentrate on the exploitation of the network.
It is important to ensure that only one set of protocols is used within JANET. This is to ensure interconnection and reduce costs. Thus there is pressure to ensure that other network techniques are not encouraged. Thus networks based on DEC NET or other proprietary or private protocols are discouraged even though they may use the X25 network. It is recognized that in some cases other organizations using different protocols have to be communicated with and the accepted technique is to provide a single gateway. This approach has been taken with the ARPA and EARN networks.
It will be quite interesting to see how new and attractive technologies are dealt with. There are a number of experts who believe that networks should be based on circuit switched technology which will be provided by ISDN. If this proves popular then there will be pressure to adopt such techniques. So far there has been little interest in ISDN. Satellites are another area of development which experts find attractive. There have been a number of successful experiments based on the Orbital Test Satellite, such as Stella, Universe and Satine, which suggest that these techniques are cheap and provide high band width facilities.
The development of JANET has shown that the standardization of network methods can have far reaching benefits. Without these standards there is little doubt that universities would have great difficulty in communicating. It is now becoming a rare event to write letters or exchange software except via JANET. Running jobs on distant machines is no harder than running them locally.
Now that the UK has JANET it is inconceivable that it would ever return to using nonstandard methods. The pressure to retain standards is universal whereas in the early days there were many who doubted the wisdom of standards as they considered it would prevent them from enjoying the richness of their particular favorite brand of networking and inhibit innovation. In reality there are several network experiments, such as UNIVERSE, which give ample scope for innovation and eventually the work will result in new standards.
This was the second meeting of the EARN board of directors and as usual the meeting consisted of a representative from each country together with IBM 'minders' from each country. There were two new members being Belgium and Denmark.
Dennis Jennings of University College Dublin was elected chairman by the university representatives. In my view a very good choice.
The topics discussed were:-
There had been a lot of development in Germany where many machines were now connected. There will eventually be 25 or more machines. Italy has 12 machines connected or expected to be connected plus the link to America. There are no international links due to the problems with CEPT. However all the international lines are now on order but will not be used until the CEPT situation is sorted out.
IBM (Herb Budd) is quite angry at the attitude of the PTTs as he believes that the USA is far ahead of Europe in the use of networks by universities and he is sad that the PTTs are not enthusiastically supporting EARN.
There is so far no license from the PTTs to use EARN but there have been several developments. Perhaps the most useful one is that CEPT has taken an interest in the network and is likely to make a recommendation which the PTTs will probably all follow.
CEPT held a meeting and indicated that they were not happy with allowing EARN as it would undermine the development of public networks. They believed that EARN should be based on ISO protocols and public networks. They requested a meeting with IBM which was duly held and resulted in a letter that the meeting considered. The letter stated:-
The meeting agreed that it was happy to commit to use public networks assuming that suitable products were forthcoming and that the tariffs were acceptable. IBM asked the chairman to write to IBM asking when suitable code was to become available.
The meeting could not understand why the CEPT was demanding the use of ISO high level protocols and believed that this was outside their jurisdiction and that they could only demand the use of X25.
The tariffs were a considerable worry. IBM are very unhappy to undertake to pay unless there was a ceiling on the costs. It was felt that in the interest of launching an academic network that the PTTs should give the network some preferential tariff.
It was agreed to seek a meeting with CEPT which will be attended by D Jennings, D Lord (CERN), H Hultsch (Darmstadt) and myself or a subset depending on availability. IBM would not be present.
A number of subgroups have been set up to develop EARN and I am in charge of technical coordination. Other groups are considering CEPT, utilities and so on.
The next meeting will be in Rome in 6 months or so.
So far the development has been a bit of a shambles. Almost no documentation has been circulated and members have been kept very much in the dark as to what is going on. I hope that the new chairman will bring order to the situation.
Progress has been a bit slow but the contacts with CEPT show some promise that at least the means of making progress are now clear. It was un realistic of IBM to think that the European PTTs would not want to have some say in the project and they should have been contacted long ago and sounded out by IBM.
As a supported of EARN I should be annoyed that CEPT is insisting on public networks and ISO protocols but with my EEC hat on the move is most healthy.
The high tariff must be sorted out and I hope that a deal can be done with CEPT. I would like CEPT to agree to a reasonable tariff for the current EARN and its successor over public networks in return for a commitment to move to public networks and ISO protocols.
I do not think we should count on a service before early autumn and we should avoid any publicity until there is more certainty.
Dear Mr. Hyvarinen,
I have pleasure in enclosing a copy of my presentation for the Seminar which I hope is in a satisfactory format. If not I am happy to reformat it for you.
The paper is rather background to my talk as there is far to much material for the time I have available. I will be concentrating on describing the network as it now exists rather than its historical development which is the approach taken in the paper.
I shall be staying for the whole week and look forward to meeting you and participating in the Institute.
Thank you for your invitation.
Yours sincerely
P Bryant.
Dear Chris,
I return the document you sent me all covered in comments. I have had little time to study it so feel free to extract and use anything you feel is useful.
In general I think it all looks very good. There are quite a few detailed points which may well be misunderstandings on my part.
Perhaps my biggest worry is that the work seems to be on the basis that only Esprit is producing comms products. My feeling is that many of the bits and pieces may well be coming from elsewhere and there seems little point in putting resources into duplicate products. The document suggests in several places that the aim is to produce portable products that will gradually move onto all interesting machines. I feel that a more realistic scenario is that several machines will have comms code suitable for IES produced my manufacturers for good commercial reasons which will be good efficient non portable products. I fear that the potable products will turn out to be awkward to mount as I have found that comms products interact very closely with the operating system. I advise that you study the career of the portable JTMP product from Salford which is two years late on a two year project which has been done on two machines with machine dependent products in 9 months. I would add that JTMP is at the extreme edge of what one could attempt with portable products.
Turning to your specific questions-
I am not too worried over the tone of annex A. It certainly leaves the reader in no doubt that we were not very happy being ignored. I say let it stand- at least in substance although one could tone down a sentence here and there.
I think file transfer could have a higher priority as the movement of binary and other stuff that mail cannot deal with is important. Item 5 should be an on going activity from day 1. There is no point in putting up facilities if no one knows they are there. I would put LAN-X25 gateways before item 6. These are important if, as I expect, sites are going to set up LANs. Certainly satellite work is a bit more futuristic than mundane gateways. I am not certain what you mean by X75 gateways. X75 is defined for gateways between public networks and should be none of our concern. Certainly gateways between private X25 and public X25 networks has at least the priority of LAN-X25 gateways. However these exist already from a variety of places and should be purchased off the shelf.
Annex C does accord with my views apart from feeling there should be comments about cooperation with other bodies and manufacturers with a view to sharing the costs of producing the goods we need. This applies from page 20 onwards. I would , for example, point out that X25, X3, X28 and X29 already exist in a product from York so why not use it or at least use it as a starting point for productization.
I worry that the manpower figures seem high- however I come from an economic organization who can stick things together and make them work but who decline to document and decline to generalize their products. Perhaps it is better to overestimate and then perhaps get a reasonable sum rather than skimp and get less than we want.
I hope these comments are of use. Sorry not to use Kom but it was easier to scribble on the original.
Had a terrible journey back to London. The Metro broke down. After a hectic taxi ride I found the plane over booked and had to wait two hours for the next one.
Best wishes
Yours sincerely
Paul Bryant.
JANET is a large private X25 network used by the UK universities. It is used for interactive, file transfer, job transfer and mail traffic. The protocols needed have been developed largely by the academics and are the only ones recommended for use. This has ensured good interconnection especially for mail. The majority of the sites now offer mail facilities which are probable the most popular service available. Mail is distributed in that users expect to receive and send mail from their favorite machines. The development of mail has led to a number of interesting developments and uncovered many problems. Some of these are discussed in this paper.
The UK universities together with some related organizations are centrally funded by the Department of Education and Science. The funds for computing are administered by the Computer Board. The Board decides which machines go where as a result of applications from the universities. In the early 1960s the Board, recognizing that computers were expensive, decided to set up a few large centers which would supply computing power to smaller sites. The smaller sites would have more modest provisions. This pattern exists to this day.
The centralization strategy led to networks of remote job entry stations (RJEs) being set up round the large centers. As these grew it became wasteful and expensive as many sites had RJE connections to many centers.
The Joint Network Team (JNT) was set up in 1976 to try and rationalize the networking scene with a view to reducing costs and improving services. After a year or two of supporting some pilot network schemes in various parts of the country, they decided that the only sensible way forward was to set up a national network based on the X25 protocols which are used in the public packet switched networks. Rather than use the UK public network or build a network from scratch, it was decided to extend the existing Science and Engineering Research Council's network which by 1983 had grown to 200 connections and had links to most universities. The network was named JANET.
The idea is that each site has a local area network which is connected to the wide area X25 network. The wide area network has a number of services such as gateways to the public network, to ARPA and soon to EARN (the European Academic Research Network supported by IBM).
There are now 15 X25 switches located in various universities. These are GEC 4000 series mini computers. The number of connections is now about 250. There are about 100 sites about half of which now have local area networks, other sites are served by connections directly to central machines. The number of connection is artificially high for historical reasons in that SERC has all its many machines on the main network. Most of the lines are 9.6K leased lines but many of these are expected to become Kilostream 64K lines. Universities have just about every type of computer imaginable and a high percentage of these are connected to JANET. Most of the network software is produced by the community but increasingly they are looking to manufacturers to supply it.
A network without high level protocols is no use. When the network started the International Standards Organization had not even produced the famous Seven Layer Model let alone the protocols themselves. Thus working parties were set up to produce a set of protocols which became known as the 'Colored Book Protocols'. It was essential that common protocols were used if interconnection was to work. The protocols are:-
Grey Book mail is designed for network use. Thus a piece of mail is headed by addressing information which allows the system to send it to its destination. This is in contrast to systems such as Telecom Gold and the Swedish Com which are centralized mail systems in that the user has to log into a central machine to send and receive mail.
Thus a mail document is headed by a number of fields which contain information which the mail systems need. Some of the information is provided by the user, such as the intended recipient, and other information is added by the mail system, such as the time, date and senders name. Grey Book provides a very rich set of facilities and therefore there are a large number of fields. A subset of the ones that the user can fill in are:-
A selection of the fields filled in automatically are:-
The RFC 822 standard from which Grey Book originates is designed for a network that needs to relay mail. That is, a mail document has to be staged from machine to machine to reach its destination. In the case of JANET this was not thought to be important as it is an X25 network thus it is possible to send mail directly between any pair of machines. While this is true it has been found that the relay facilities have turned out to be very important as will be discussed below. Relaying works by each machine that the mail goes through stamping the mail with a 'via:' field. Thus the recipient can see how the mail arrived and more importantly the mail system can work out how a reply to the mail can be sent. An important mail relay point is the gateway between ARPA and JANET which allows a free flow of mail between the two networks.
An example of a mail message as seen by the receiver follows:-
Via: RLGK; Fri, 25 May 84 15:09 GMT (V31 at RLGB) From: NSIN99@RLGK (on GEC 4090 at Rutherford) To: Paul Bryant Date: Fri, 25 May 84 15:09 GMT Subject: A Test Message Message-Id: <25 MAY 1984 15:09:41 NSIN99@RLGK> This is the text of the message.
Note that a via: field has been added by the computer originating the message. RLGK; defines the computer and the rest of the line gives time, date and the version of the mail program in use. The from: field defines user NSIN99 on machine RLGK to be the originator.
The remainder of this paper describes the installation of a mail system at Rutherford. Rutherford tends to be ahead of most other sites who are undertaking similar activities.
Ideally one should be able to send mail to a name such as Paul Bryant. This would require each computer offering mail to have a directory, or access to a directory, of all the people mail may have to go to. With 50 universities each with 5000 people, not to mention the organizations on the ARPA network, that is a large directory. Keeping it up to date is just not feasible. Thus mail to Paul Bryant is not generally possible. A further problem is that machines know people by login identifiers and not names and thus his login identifier, NSIN01, is liked better by computers. At first login identifiers and X25 addresses were used but much better schemes have now been developed.
So far JANET has not agreed a general solution but a solution seems to be emerging as outlined below.
Every JANET site has a name assigned to it. Each site keeps or should keep a directory of possible mail recipients on its site and furthermore defines the address of a mail machine on the site which contains the directory. Thus if the name of the person and the name of the site is known the mail system on the local machine can find out where to send the mail. The mail machine at the remote site is now responsible for extracting the name of the person and finding out where to deliver the mail. This is a mail relay operation and that is why the relay facility has turned out to be so important. The implementation of such a system does not preclude mail being sent directly to the person as long as the address of his machine is known and possibly the recipients login identifier.
Some examples of valid names are:-
Paul Bryant. Now this is an interesting case. If Paul Bryant is on the same machine as the mail sender then the mail system can easily have a table of names against login identifiers and sort out where to send the mail. If he is not on the local machine then the mail system can assume he is on the site and send the mail to the site's mail machine which should know about everyone on the site. Hence the mail has a high chance of being delivered. If the mail machine cannot sort it out then there is little that can be done.
Once there are table look up mechanisms these can be extended to deal with distribution lists. These can be quite complex as each machine may have its own sets of lists. Thus mail can be sent to a distribution list which points off to further distribution lists, possibly on other machines. This allows good economy of network traffic in that a piece of mail need only be sent to a machine once for distribution.
Names can be notoriously difficult to spell and, moreover, there are many similar names such as J Smith. Some way of dealing with these problems is needed. The scheme used on some JANET machines is to first search for the name as given. If this produces multiple results, for example, the user sent mail to Smith, then the mail is returned and the user informed of the many Smiths that he may be alluding to. If there is no match at all then the fuzzy matching takes place using the Soundex algorithm which is used by the airlines. Again the results of the fuzzy match are returned to the sender. Mail is never delivered unless the recipient is identified exactly.
The form of names in the directories was difficult to decide on. Many people wanted to be known by their nick names and others wanted multiple names for themselves. The final decision was for the name in the directory to consist of the first name a possible initial and a second name, for example, Paul E Bryant. The search mechanism insists that the second name is present but allows the first name and the possible initial to be optional but if present to be correct. The first name may be contracted to an initial. If a second name is not unique then a first name or initial must be given. Various separators are allowed. Thus valid names are- Bryant, P.BRYANT, P.E.Bryant, Paul E BRYANT.
The use of sophisticated table look up mechanisms is very powerful in providing a helpful and easy to use mail service.
Some mail systems are very good and have the sort of facilities outlined above. Others are extremely poor and can do little except send mail to a name and receive mail addressed to a login identifier. This is sad but inevitable. However, it is not a great problem as long as there is one good mail machine on a site. There is no reason why the poorer machines cannot use the facilities of the better ones. For example, if the local machine has no distribution list facility then the mail need only be sent to a machine that has, after all, the sending machine has no idea what a name means.
Thus as long as all machines have some sort of mail system and there is at least one sophisticated system on the site a sensible mail service can be set up.
So far the discussion has been about the underlying mechanisms of the mail systems on JANET. Of equal but local importance is the user interface.
The user must be able on construct, receive, reply to and forward mail. He will also want to be able to file or discard mail.
Unfortunately there is no agreed mail interface standard in JANET and all there is is a weak recommendation to use the EMAS mail interface which came from ARPA. So far this has only been adopted on machines at Edinburgh and on the GEC 4000 machines. A PRIME version is being built. On the other machines various techniques have been used which have usually been to try to use the manufacturers mail product. For example, on the Rutherford IBM the CMS NOTE scheme has been adapted with good success. Some machines have very poor interfaces and even have different programs for receiving or transmitting mail with no provision for forwarding or replying to mail. Where semi standard interfaces such as EMAS cannot be provided then it is best to try and adapt the manufacturers product as this will be familiar to the user and be well documented. This does mean that the full potential of a network mail system is difficult to realize.
With the EMAS mail interface the user is normally informed if he has any mail when he logs in. He then runs the mail program. Incoming mail is held in a pending file and the mail program first analyses this file and displays the sender and subject of each message. He is then invited to press return to see each message but he may elect to go and do something else. The system has the concept of a current message which is the one just displayed. This message may be replies to, forwarded with a comment, deleted or filed. The default is to file it. It may be filed in one of a number of folders. This allows mail to be filed under various headings for easy reference. There is the concept of a current folder and the user can move from folder to folder. The mail stored in each folder is serial numbered and the user can call up any piece of mail by number. He can also scan the folder for mail with a particular attribute such as, it was sent from a particular person or on a particular day. The scan criteria are quite rich. When a scan is made the items matching the criteria have their headings and serial numbers displayed so that a specific mail item can be selected to be the current one. The selected item can then be dealt with as if it was a new piece of mail, that is replied to or whatever. Experience shows that users tend to accumulate large amounts of mail and means of keeping track of it are important. Perhaps the most useful facility is being able to delete all mail with some attribute- like it came from the tax man!
Earlier the directory mechanisms behind the mail systems were described. There is no reason why the user should not be able to set up his own directory and thus give himself some powerful techniques for dealing with the sending of mail. For example, this provides a nick name facility or private distribution lists. For group leaders and executives this has proved very useful.
A further useful facility is the ability to incorporate files from the normal computer file store into a mail document and conversely to place a mail document into a file. Thus nicely formatted documents can be mailed. Printing facilities are provided for outputting all or selected pieces of mail. The printed word is still the best if a document had to have a lot of study. For sloppy workers, like the author, whose mail gets out of hand the best solution is to print the lot and then delete the lot!
Facilities exist for editing a piece of mail which is to be sent or which has been received. This is achieved by calling the editor of the users choice which will allow him to edit each field separately. Of course he must take care if editing the headings as addresses are sensitive to errors.
Users make errors. A good system is helpful when errors are made. Before mail is dispatched the various fields are checked and useful diagnostics returned if there are errors. The next stage is to submit the destinations to the local directories. This may detect errors in which case the mail is returned together with a diagnostic. For example, if mail is sent to Smith it will be returned with a diagnostic asking which of the many Smiths is required. Similar checks are made as the mail progresses to its destination and whenever a problem is encountered the mail is returned. It is vital for the user to have confidence that if mail cannot be delivered then he is informed otherwise he will not rely on it.
The JANET mail system is not secure against corruption, eves dropping and malicious activities. However reasonable steps are taken to ensure mail is delivered and if it is not it is returned. Most of the underlying file transfer systems repeatedly try to transfer a file for up to a week before giving up. A useful feature in the EMAS mail system is that the system can send an automatic mail message to the sender when the mail is displayed by the receiver. Thus a positive response is possible. Normally this is not used.
Some time ago Rutherford set up an office automation scheme based on the PRIME OAS system. The managers and their secretaries were each given a terminal. This was a complete failure. It turned out that when a secretary wanted to send out mail and only a small proportion of the recipients were OAS users she typed it out on paper and sent it in the traditional way. The lesson learned was that any mail system must include sufficient of the staff on a site to ensure that paper mail is not required. This turns out to be more or less 100% of the organization. There are always some people who cannot or will not use a terminal which makes 100% impossible. Fortunately the people who will not use terminals do not usually generate mail. The solution to this problem is to allow people to elect to receive electronic mail on paper. Thus, not all the people in the directory have computer accounts and in these cases the directory causes the mail to go to a convenient printer for distribution by the postman. Electronic mail will not replace the postman but does help in that the majority of the paper post is junk.
Each site sets up its own mechanisms so the comments here are relevant to the experience at Rutherford which contains 1700 people and the computing division contains 150.
The initial mail systems were installed in 1978 and were primarily for the computer users. This had few problems since computer users are used to dealing with meaningless jumbles of characters. Only a few machines had mail systems and there was little inter working between different manufacturers equipment.
It was in 1981 that Grey Book was produced and effort was put into inter working generally. Progress was patchy with the mini computers which provided interactive facilities leading the way. It was at this time that the disastrous OAS experiment took place. There was no connection between OAS and the Grey Book mail. By 1983 most machines had Grey Book and there was pressure for a new office automation scheme.
Two disjoint activities took place. The IBM PROFS system was adopted and an experiment was run to put everyone in the Rutherford computing division in the mail directories. The setting up of the directories and distribution lists turned out to be quite time consuming. It also turned out that it takes considerable effort to keep it up to date. It soon became apparent that there was great pressure to connect PROFS into Grey Book mail or PROFS was going to fail. This pressure came from people outside the division who found they had to use PROFS and the Grey Book mail and were reluctant to have to use two different machines. The connection was achieved and was immediately well used even though it was not technically very elegant.
A number of related organizations also set up mail systems which interacted well with the Rutherford one and the scheme has been growing.
So far there has been no attempt to set up a directory for the whole site as this would take a lot of manpower. An alternative scheme is to extract the directory from the personnel data base but the work to do this is not yet complete. However the lesson is that maintaining directories of people is a non trivial task and that if it can be related to some other activity so much the better.
The use of Grey Book mail in the universities is patchy and depends how keen on networking the sites are. A rough estimate is that half the sites use mail and perhaps a quarter are using or have plans for sophisticated directory schemes like the one at Rutherford. It must be noted that this sophisticated mail scheme has been adopted by the manufacturer GEC as a commercial product. The UK Alvey project has installed two linked machines for their requirements.
The connection to ARPA has already been mentioned. This gets very heavy use. Another gateway planned is to the European Academic Research Network. Fortunately this network also used the RFC 822 standard and thus the gateway will be simple to build.
The gateway to the public packet switched network allows connections to other sites who can provide Grey Book. Surprisingly there are now several dotted around Europe. These are mainly owned by the High Energy Physics community with which SERC is closely associated. Ireland is intending to adopt the Colored Book protocols for use on its academic network so this will give mail facilities between the two countries.
There is a gateway between the public network and Telex. Facilities have been put into one of the mail machines to allow Grey Book mail to be converted to a form acceptable by the Telex gateway. Unfortunately international calls cannot be made over this link and it seems to be a fact of life that most telexes go overseas. The Telex answer back is returned to the sender in a computer generated mail message thus giving him a guarantee of delivery. Apparently the answer back has some sort of legal significance in proving a Telex has been delivered. There is no reason why a Teletex gateway should not be developed although the use of this service in the UK is currently very small.
The cost of the mail system is impossible to calculate. This is because the computers used have been installed for other purposes and the percentage of the machines used is not known. The cost of the network is again difficult to find out as mail uses a percentage of a network installed for scientific and academic purposes.
The savings are that real mail costs are reduced both in terms of postage costs and the secretaries time typing. There must also be some financial gains from the higher speed of electronic mail.
Over a large diverse organization such as the UK universities it would be impossible to set up a single centralized mail system. For a start it would be costly and funds would be difficult to get. For the finish the academics would argue as to what sort of system should be set up. With a distributed system the sites have a good degree of autonomy and may even elect to have no mail system at all. Thus distributed mail gives academic freedom and interconnection.
The disadvantage of a distributed system is that its cover of the organizations is likely to be patchy and some people will be disadvantaged. This problem will hopefully be solved by the users demanding services from their sites and also the manufacturers supplying products.
The UK had taken an early lead in exploiting mail and will have to pay the price in that the protocols used will soon be obsolete. Manufacturers are unlikely to provide products based on Grey Book whereas they are likely to provide products conforming to the X400 mail standard defined by CCITT which is similar to Grey Book. The transition to X400 will probably be achieved via relays of one sort or another. It will be costly and take several years.
The character of electronic mail is very different to paper mail. Whereas paper mail is usually well typed, well spelt and contains lots of padding, electronic mail is badly typed, badly spelt and concise if not cryptic. This is usually because the sender types his own mail and cannot be bothered to correct it. He is only interested is sending the minimum number characters containing the maximum amount of information. A second observation is that electronic mail tends to consist of a number of pieces of mail between the people over a short period of time. This is rather like a short discussion. This is possible since in general mail only takes a few seconds to reach its destination. The advantage is that less human time is spend concocting florid phrases and more time dealing with real information.
A disadvantage of a complex distributed mail scheme is that the user has difficulty comprehending it. The headings at the top of a document are difficult to understand and in some cases, particularly where gateways have to be traversed, difficult to set up. Some joke mail from ARPA has a couple of hundred via: fields. Although this is unusual 10 or so is quite common. The problem should be simplified as networks converge to ISO standards, if in fact they do.
Standards are not static. Standards always have faults and ambiguities regardless of the effort that goes into their definition. Grey Book is no exception. This problem has been solved by setting up an implementors group who attempt to resolve difficulties. However there is a lot of resistance to changing the standard as this could cause interconnection difficulties during any transition phase. Also transitions are very expensive in terms of re-implementation and organization.
The use of distributed electronic mail has proved very popular. The demand is to extend the service as fast as possible to all the people the site has to deal with. In many cases SERC has computers on remote sites and these provide mail facilities. There is also a demand to improve the user interface to a uniformly high standard.
These aims can only be achieved with close cooperation between the various universities and a close adherence to standards. There can be little doubt that the JANET mail system will soon reach all parts of the universities.
Ir. F. H. W. Komhoff Euroforum Piazza 401, Postbus 845, 5600 AV Eindhoven Nederland.
Dear Mr. Komhoff,
Thank you for your invitation to participate in your conference and for booking me accommodation.
I produced my paper before I received your last letter and therefore wrote it round the topic of 'Experience with interconnected incompatible systems'. The paper is background to by talk and I will concentrate on the experience and less on the description of the UK university mail system. I have difficulty talking about the disadvantages of incompatible interconnected systems as there are none - if the protocols are compatible. I also have problems with different types of protocols as the university network works on the principle of standard protocols. However I guess you will be able to get the drift of my talk from the latter half of the paper. I hope the paper will fit in with the other speakers and I think the experience of the UK universities is worthy of study.
I am sending you the paper rather early as I shall be on holiday for a couple of weeks from June 1st and would value any comments so that I can adjust the paper and talk accordingly. I will aim the talk at the person who has used a computer from time to time.
I will be using overhead foils and considering the time scale and possible postal delays I will produce these here. In any case many of the foils will be from my extensive collection.
I look forward to the conference and meeting with you.
Yours sincerely
Jean, Mr. J Nuyens,ULB Mr. Weets, Mr. G Weets,IBM Belgium Jean, M. J Delhaye and J C Ippolito,CNUSC M. Mercouroff, M. W Mercouroff,ENS ULM M. Gollois and Rodier, M. G Gollois and P Rodier,IBM France Hagen,Mr. H Hultzsch, GSI Peter, Mr. P Streibelt, IBM Headquarters Germany Boud, Mr. B. Kirchner, IBM Germany Dennis, Dr. D Jennings, Computer Centre, University College Dublin Mick, Mr. M Donohue, IBM Ireland Mr. Trumpy, Mr. S Trumpy, CNUCE Alissewlro, Mr. A Fusi, IBM Italy Jose Luis, Mr. J L Becerril, IBM Scientific Center Mr. Mate, Mr. L Mate, Universidad Politecnica de Madrid Birgetta, Ms. B Carlson and Mr. B Hellsen, QZ Stockholm University Mr. Heritier, Mr. C A Heritier, IBM Switzerland Prof. Bauknecht, Prof. Bauknecht, Universitat Zurich-Irchel Colin, Mr. C Setford, IBM UK, Hursley Park Paul, Dr. P Bryant, Computing Division, Rutherford Appleton Lab Ira, Dr. I Fuchs, City University New York David, Dr. D Lord and O Martin, CERN Alain, M. A Auroux, IBM Europe, Tour Pascal Herb, Mr. H F Budd, IBM Europe, Tour Pascal Mr. Aagaard, Mr. H O Aagaard, NEUCC Mr. Cohen, Mr. A Cohen, Tel-Aviv University Lars, Lars Backstrom, Computing Centre, University of Helsinki Odd, Odd Meland, Director of EDP-service, RUNIT, The Computing Centre, University of Trondheim Ir. C.A.M. Neggers, Ir C.A.M Neggers, Universiteit Nijmegen Pall, Mr. Pall Jensson, Computing Centre, University of Iceland Matti, Mr.Matti Ihanuotile, Vtkk Mr. Greisen, Mr. F Greisen, , NEUCC
To get TELEX messages to and from the computer Grey Book mail system.
This will provide TELEX services to and from PROFS and any other computers offering mail services. Any service must operate as automatically as possible and preferable show some cost savings.
This paper reviews the possibilities with a view to clarifying the options rather than coming to any recommendations.
It would be wrong to consider TELEX only in the light of PROFS as there is a demand for TELEX from many of the computers. TELEX is a facet of communications and as such should be considered as part of the communications infrastructure. TELEX provides a mail like service and it therefore seems appropriate that ideally a gateway should be provided between TELEX and the Grey Book mail service provided on most of the computers. This approach will allow TELEX to be utilized from any computers providing Grey Book mail which includes machines at the other SERC establishments.
Whilst many suppliers will claim to solve all known problems with their particular unique offering it does seem that there are four possibilities which cover all suppliers products.
Manufacturers are starting to come forward with equipment for TELETEX which is heralded as super TELEX. This, to my mind, will be a replacement for TELEX but this is likely to be some years off. Before TELETEX is a viable proposition there must be a large body of subscribers, a good supply of equipment, interconnection with our mail system and interconnection with TELEX. These requirements are not likely to be fulfilled in the near future. Thus any use of TELETEX can only be seen as experimental. In fact some TELETEX work was started some time ago but lack of staff has caused the experiments to be abandoned. It is of interest to note that ESPRIT intends to use TELETEX as the basis for communication between committee members throughout Europe. The equipment and systems developed for ESPRIT may be of use to us.
Note that TELETEX is designed to operate over the X25 packet switched networks or over dial up. It provides a service for transporting documents in such a way that the received document is identical to the original one. Thus the service knows about character codes, paper sizes, character spacing and many other aspects of a document. Transmission speeds are only limited by the network used and the terminals used and speeds of 200 times the TELEX speed can be expected.
The service is based on the use of the British Telecom Telex Network Adapter which provides a link between PSS and TELEX.
This service exists and works quite well. It provides a gateway between TELEX and Grey Book mail. It provides sophisticated facilities such as proof of delivery on outgoing TELEXES and code to attempt to deliver an incoming TELEX to the correct mail box by scanning the TELEX for the name of the recipient. It suffers a major drawback of not allowing international TELEX traffic. This is a BT restriction and pressure on BT by various bodies has so far yielded no results. Should this restriction be lifted then the service is very attractive since all the equipment and software exists. The cost of the service will be the normal TELEX charges plus PSS charges. The PSS charge is 0.5p plus 0.25p per 64000 characters plus 0.25p per hour of use- these charges are negligible.
There is a problem on incoming TELEX in that the remote TELEX operator has to send the TELEX to the TELEX number of the British Telecom Telex Network Adapter which is the gateway between PSS and TELEX. The operator also has to give the PSS number of Rutherford. How operators will adapt to this added complexity is uncertain. One hopes that BT will provide suitable operating procedure documents.
The code exists on a GEC computer and unfortunately the freezing of GEC development may cause maintenance problems although there are some hopes that GEC may support the system. The system is used regularly by a small number of people and gives no problems.
These are boxes which connect to a number of TELEX lines. The boxes can provide a variety of services such as spooling TELEXES, editing and composing as well as continually dialling an engaged number. Ordinary terminals can often be connected to the boxes and often over dial up connections. At Rutherford it would probably be possible to connect such a box to PACX and so provide a service to anyone with a suitable terminal.
Equipment of this types is available from Hasler or Racal and has been investigates in the past. A number of other companies provide similar equipment which may be worthy of study. The cost of the equipment has to be compared with the cost of the current TELEX equipment. Call charges would be identical.
This type of device will not provide a service into the mail system although a cooperative company may be willing to modify and develop their equipment to provide a gateway to Grey Book but this seems unlikely. Such a development would ideally connect to the network with an X25 connection and thus a considerable amount of protocol code would have to be produced. Alternatively it would have to look like some form of interactive terminal which would be likely to provide an unreliable service as well as being limited by the facilities available via a terminal. Thus it is unclear how such a connection could work.
It would be possible to build a TELEX concentrator at Rutherford which could connect to the mail system and this would be surprisingly easy. The technique would be to modify the current GEC TELEX code (see section 4) to drive a genuine TELEX line rather than to operate over X25. The result would be almost indistinguishable from the current TELEX service over X25 but would allow international traffic. It turns out that only a small part of the code would need to be rewritten. This development would provide a variety of interesting possibilities as the TELEX code could decide whether to use direct TELEX or TELEX via PSS depending on a users request, cost criteria or traffic conditions.
It should be possible to produce such a product on other machines, in particular the IBM. This is likely to be a more difficult and lengthy task because of the less advanced starting point.
Easylink is an example of a TELEX bureau. Essentially the supplier has a connection to TELEX and undertakes to send and receive TELEXES on the customers behalf. Bureaus exist in a variety of shapes and sizes from the local town bureau, which has a small number of clients and takes messages by phone, to the larger and more sophisticated ones such as Easylink which provide a more automatic service. Never the less the service is similar. In the Easylink case the customer sends and receives TELETEX via the public switched telephone network.
The customer has to supply a suitable terminal and modem to use the service. The Bureau makes money by having a standing charge and putting a premium on the TELEX charges. Thus for an organization making few TELEX calls it can be economic as the premium on the TELEX charges is less than the BT standing charge for TELEX. For a large user it can be expensive as the premium on calls will dominate the cost.
The service will give no access to and from the mail service. Although Easylink are looking into the possibility of a link to PROFS it is difficult to see how such a connection will work without considerable development. It is unclear whether this development is on the Easylink equipment, Rutherford equipment or both. In any case it seems to me that such a development will be a long time coming.
The costings for the various services are difficult to determine exactly but some indications of the factors to be taken into account are given.
The equipment costs are impossible to determine as new equipment is likely to become available over the next few years. It is known that an IBM PC implementation will be available and the cost of a PC for such a job is likely to be $2000 or more. Implementations on other machines, in particular to provide a gateway into the mail system, are likely to be available from academic sources and will therefore suffer the advantages and disadvantages of software from those places.
Call charges will be cheap as PSS charges, on which TELETEX will be based, are low compared with TELEX. Standing charges will be zero as PSS connections already exist. With such a superior service it can be expected that users will send larger documents and so real charges may not reduce.
The charges are normal TELEX plus PSS charges. The PSS charges are so low that there would be a net saving from the removal of direct TELEX connections and equipment. No new equipment is needed.
The cost of the concentrator must be set against the cost of TELEX terminals. There may be some added cost for PACX connections.
If a GEC is used as a concentrator then no new equipment is needed and there will be a saving from the removal of current TELEX terminals.
The cost comparisons are taken from the Easylink costs.
The savings will be the removal of BT TELEX equipment.
The cost will be- the cost of terminals but existing ones will probably be adequate - the registration fee which is negligible - the cost of Easylink numbers at between $8 and $12 per month which is small - the premium on TELEX charges which is very large.
The cost of inland TELEX over 56Km is 2.75p per 20secs which gives the cost of an 800 character TELEX as 11p or realistically a few pence more. A similar Easylink TELEX costs 50p. A similar European TELEX costs 30p and over Easylink 100p. American and other countries show a similar cost ratio. Since the volume charge dominates it can be seen that the cost of TELEXES will be at least treble.
Conclusions are difficult as none of the options give the service required without developments which may or may not be possible. A striking fact is the high cost of going via a bureau. If only BT would allow international calls via PSS then that solution would be highly attractive. In the long term my opinion is that TELETEX is the way to go and that we should now be looking on some interim, and thus cheap, scheme to get us through the next few years. Perhaps we should obtain TELETEX equipment with a view to gaining experience.
Dear Jan,
You will recall that we talked about the work of the ECC in attempting to harmonize the tariffs and practices of the EEC PTTs. The name and address of the man involved with this work is:-
Mr. Ken Thompson C.E.C. DG III/TFTI Rue de la Loi 200 B - 1049 Brussels Tel. (02) 235.12.70
He is part of "Task Force Technologies Information".
I enjoyed my visit to Amsterdam and I hope I will have the pleasure of meeting you again soon.
Yours sincerely
Paul Bryant.
Dear David,
Nice to hear from you. It seems ages since we last met.
The problem with the Grey Book mail, that we are all constrained to know and love, is that each implementor has gone out and invented his own user interface. This has been caused by a number of factors which you may like to relate to your students as reasons why we do things as badly as we do. First- several machines have some sort of local mail system between the users of that machine and Grey Book implementors have attempted to imitate or extend its user interface on the grounds that this will give users least trouble and, incidentally, will obviate the need to document what they are doing. Second- most implementors know just what the user needs and thus are justified in going out and implementing just what he needs, such interfaces are so good that they usually do not need documenting. Thirdly- anything anyone else does is bound to be poor so I must avoid their poorness and invent something better. Fourthly- pig ignorance of what anyone else has done. I will leave you to categorize the various offerings if you can find their documentation.
To be more serious, the Mail Implementors Group did consider a user interface. In fact I put forward the view that we should standardize on the EMAS mail interface- not that it was the best but on the grounds that it was well suited to the Grey Book mail as it was based on an ARPA standard. This would maximize the number of people who use the same interface and minimize documentation. I failed and came out with the weak recommendation that it should be used where a machine had no other mail interface.
Basically a mail interface invites a user to provide the name and address of the recipient(s), a subject and some other optional information so that the underlying protocol can do what a protocol has to do. It should also provide means of examining incoming mail, replying to it, forwarding it and last but not least deleting it.
The GEC mail system which will be provided on the GEC machine you have somewhere, for getting jobs into ULCC, will have the EMAS mail interface if it is not already in place. The only other machine to provide it is the PRIMEs we run (that is beside EMAS and ARPA machines). In all the other cases implementors have cooked up something horrid. On the IBM we (sorry they, I refuse to be associated with it) have bent the CMS note system. On VAX the very poor VAX mail interface has been bent, this provides different programs for receiving and sending mail. I don't know about other machines as life is too short to investigate.
It is, perhaps, a minor miracle that all these systems can actually pass mail and do it with a good measure of success. The mail systems also provide some added befits. The first is a gateway to TELEX via PSS, this is useless as it will not deal with international TELEX (BT stupidity). There is a gateway to ARPA courtesy of Peter Kirstein at UCL. There will be a gateway to the European Academic Network (if it ever happens) courtesy of Rutherford. Unfortunately in going through gateways horrid things happen to addresses and I find that it is rarely possible to reply to such mail without an honors course in mail (presumably not from Southampton from your letter).
You will have gathered by now that there is no Noddy documents on mail. The 'well found' mailer is armed with the manual for his machine plus a lot of folk law. The amount of folk law depends on the user interface and the 'goodness' of your local center. Some mail systems are helpful in that sending mail to BRYANT or even PAUL BRYANT is successful. Other systems, without extensive directory facilities, will insist that you address me as BRYANT@RLGB (RLGB is my favorite machine). Others may insist that you quote the X25 address of my machine instead of RLGB.
Thus naming is a mess. In principle each site should have a designated mail machine which contains a directors of all people on the site and their favorite machine on which they like to receive mail. Thus if I send mail to BARRON@SOUTHAMPTON my directory will know the address of the Southampton mail machine and send the mail to it. It will then look through its directory and see that you live on such and such a machine and that perhaps your login id is so and so- it can then forward the mail to you. If it cannot it should send it back. Such machines should also be able to deal with distribution lists, have fuzzy matching facilities and if you send mail to 'Smith' to send it back and ask which 'Smith'.
There are a lot a nice facilities that a good mail service on a site should provide and only one or two sites can provide such facilities. I hope we do not have to spend too long waiting for them to be available everywhere.
I enclose the user specification of the GEC mail system. First you should be amazed at its length of 41 pages. Second I believe that it is the Rolls Royce of mail systems in that it can provide all the fancy facilities outlined above. Thirdly I am proud of it as my staff developed it. An interesting point is that a site need only have one good mail machine providing the fancy stuff as all the other machines can make use of it.
I hope these notes clarify a few points and I will measure my success by how long it is before I get a mail message from you.
Yours sincerely
Paul Bryant.
The presentation will concentrate on mail and conferencing.
Statement that the use of mail and conferencing is becoming the main use of both domestic and international networking.
Statement of benefits of mail and conferencing. Avoids travel, increases speed of interchange of information, improves or makes possible cooperative projects between distant sites, and lastly improves international understanding.
Description of mail and demonstration of mail on GEC. Bemoan fact that so many different interfaces and poor implementations exist. Describe Lab mail system.
Note that there are many mail systems and that work is in progress to gateway between them. Mention Paris conference. Mention the hope that the MHS protocols will become commonly available. NOTE NEED FOR FUNDS TO HELP TO BRING MHS TO FRUITION.
Describe conferencing and note how it differs from mail. Give demonstration of Swedish KOM or failing that Dublin KOM. Note that ESPRIT, HEP and many other groups now rely on KOM. Note the production of PORTA KOM and note the hope that this can be mounted at Rutherford for the benefit of SERC. NOTE THAT THIS WILL NEED RESOURCES FROM INFRASTRUCTURE. Note hope that KOM will become a standard.
Describe EARN and the EARN gateway at Rutherford. Note need to keep JANET pure. NOTE THAT THE PROJECT NEEDS RESOURCES FROM IBM, INFRASTRUCTURE AND POSSIBLY JNT and that it is for the benefit of the community. Note that it is hoped that it will have a transition to use ISO protocols eventually. Note main use of EARN will be for mail- particularly to USA.
Temporary note - the proposal refers to CCITT 1984 publications prepared for the Plenary Assembly pending the publication of definitive recommendations.
There is now considerable terminal traffic between PADs and hosts offering various of the optional X3 parameters and various of the optional parameter settings. This has led to considerable difficulties in attempting to provide implementations that will inter work satisfactorily.
Implementors who have been provided with networks supporting a rich set of optional features have tended to use these features to provide a better service. For example, use of certain settings of parameter 13 can allow type ahead without the danger of over typing the previous line- use of the facility to allow local editing characters to be set can allow a terminal connected to a PAD to operate more like a local terminal. Host implementations written to make use of the optional features have to become fairly complex if they are also to operate with PADs which do not provide the facilities required. Moreover, the users of such PADs provide a reduced quality of service.
Manufacturers are expected to produce equipment which provides the parameter features and only those parameter features of the customers network. Thus the manufacturer has to produce a number of versions of his product which is an expensive undertaking. Some suppliers are reluctant to do this and so reduce the customers choice of equipment.
The exercise to harmonize the European academic networks which was supported by the EEC and DTI recommended that all implementations should provide all the parameters and their settings. This was to promote interconnection and to allow the best possible quality of service.
Experience of implementation suggests that the full implementation of the parameters is only marginally more expensive in terms of effort and run time computer resources.
With international terminal traffic the use of private or national X3 parameters has caused poor quality service. Implementations have been produced to take advantage of this feature on the incorrect assumption that they would not be used on international connections.
For CCITT 1988 the second octet of the protocol identifier should be 88 hex. The purpose of this change is to allow a PAD to determine whether CCITT 1988 is being used.
| 8 7 6 5 4 3 2 1 |
--+--------------------------------+
1 | 1 0 0 0 1 0 0 0 | )
--+--------------------------------+ )
2 | 0 0 0 0 0 0 0 1 | ) Protocol
--+--------------------------------+ >
3 | 0 0 0 0 0 0 0 0 | ) identifier
--+--------------------------------+ )
4 | 0 0 0 0 0 0 0 0 | )
--+--------------------------------+
. . )
. . > Call data
N . . )
--+--------------------------------+
4<=N<=16 octets
FIGURE 1/X.29
Call user data field format
In the Harmonization of European Academic Network activity there were certain parameter values which were seen to be useful but which had been arbitrarily excluded. This was particularly noticeable with the forwarding condition (parameter 3), the idle timer delay (parameter 4) and line feed insertion (parameter 13). The proposal is to made all the possible values legal. Implementors suggest that it is more trouble to make certain values illegal that to allow all values. If the proposal to make all current optional parameter settings mandatory then parameter 4 needs no further consideration.
P Bryant B Day E Sampson M Spray W Robinson A N Other
The meeting was an informal exchange of views on various topics effecting Swindon.
In general they are pleased with the performance of the Ring which they claim has had very few problems. In particular the GEC Ring interface has been reliable. I assured them that we now had spare Ring boards so that in the event of the GEC Ring interface failing we could replace the board. However, we do not have diagnostic code and thus maintenance will have to be on an exchange and hope for the best basis.
During the discussions a few worrying comments were made such as "When we tried this the Ring fell over so we don't do it now". This seems to suggest that there are some problems which are not being reported and thus no action is being taken. I impressed on then the importance of reporting faults, not that instant cures would be forth coming, but that we could see whether some action is needed.
They are thinking that they would like extra capacity between Swindon and RL and a possible idea is to put in a CAMTEC Ring gateway. Thus they would have two X25 connections and would divide the traffic in some arbitrary way. This would also prevent lack of access in the event of the GEC or CAMTEC gateway failing. This idea will be pursued by Swindon.
They claim to be amateurs in setting up the Ring PADs and claim that the PADs have to set up in some specific way to work with the full screen Cifers. Since Brian Day now looks after PADs it was agreed to get CAMTEC to visit Swindon to advise on setting up the PADs and Brian would go over and learn. The exact nature of the problem was impossible to determine from the Swindon staff at the meeting.
There was no discussion on the Diamond word processors which could mean that they are all working satisfactorily or (more likely) not used much.
Swindon made it abundantly clear that they did not want to share their communications facilities in any way with NERC. I got the feeling that relations between the two parts of the Swindon site are not improving. I assured them that there were no plans to encourage SERC Swindon to cooperate with NERC communications wise.
There are attempts to get a Kilostream link and we thought that this could best be used on the X25 connection in the first instance. I made the point that I thought all the lines to Swindon should be replaced by Kilostream but there is a problem in that multiplexing equipment to divide such lines down to 9.6K required by the IBM equipment is expensive.
Inevitable we considered the full screen Cifers. The Swindon members were generally sympathetic to the use of Cifers and felt that they could meet most requirements. There is one man who is demanding IBM equipment and only IBM equipment and he does not seem to have a lot of sympathy in Swindon. It is thought that there are a small number of applications where response is important and where IBM terminals may be better, such applications are where girls are continually inputting data. It seems that the real problem is the unpredictability of the Cifer in the way it displays data.
We considered the so called faults in the Cifer which seem to become apparent when using Passthrough. Swindon cannot help us in determining whether the fault happens on all terminals or just Cifers so it looks as though we must do some investigation.
Swindon have ordered Winchester discs for the GEC. We cannot support these without development. I got the feeling that Swindon were embarrassed that they had not consulted us. Various ideas were considered. The best one seems to be to cancel the order and replace by 300Mbyte drives and Swindon will pursue this. Another idea is for Swindon to seek support from Daresbury who may well be able to support their machine. The problem here is that Daresbury would not be able to support the Ring interface until the MACE became available. If Daresbury did take over the job then I feel it will be viewed as yet another failure of Computing Division and yet another move towards Daresbury being the administrative computing center for SERC.
Outside the meeting I got the distinct impression that Swindon were unhappy with the service they are getting. I asked why they were considering having their own computer or using Daresbury and got the reply that because of the so call bad service they are getting. The bad service fell into two parts. First, there seemed to be some un predictability in the availability of the IBM. When questions are asked the answers tended to be of the sort 'well you asked for this change and the engineers are just doing it'. I had the feeling that they felt that they were not being given fair warning of planned down time. Second, they feel they are being treated as a nuisance and treaded rather formally rather than as honored customers and flexibly. I also got the feeling that Swindon feel they are being messed around with different stories and policies coming out of different parts of Rutherford, I can sympathise with this. Whether their feeling are real or imagined or perhaps aimed at achieving some undeclared goal I would not like to say.