Paul Bryant's Networking Correspondence
Dear David,
I enclose the proposed agreement between IBM and Rutherford which shows the amount that IBM will be contributing to the lines.
The document was drawn up a long time ago before the volume charge was known about. At that time it was agreed that Ireland would pick up the bill for the Dublin link. Now that we know the tariff, Colin Setford is talking to his Irish counterpart to see if that agreement is still acceptable since I suspect they may be unhappy with the open ended nature of the commitment. I suspect that in the event it may be simpler if the UK carries all the problems of this BT volume charge rather than spreading the problem around the countries. I guess it would have been easier if we had decided to meet all costs in the country that they were generated. Signing an agreement is not delaying things.
I now have the agreement from BT for ordering the CERN line and I enclose a copy for your records although it says nothing new.
There is a meeting between Tony Proudman and John Fairclough of IBM and Geoff Manning to discuss EARN. This will be on the 24th of this month. In the light of this IBM (Colin Setford) prefer to wait until this meeting has taken place before ordering the CERN line. Another delay I am afraid- but at least this one is within our control.
I have asked Geoff Manning for advice on requesting some support from BT for the international connections and he has encouraged me to draft a suitable letter. I do not intend to do anything until after the meeting on the 24th. I think this approach may have a reasonable chance of success.
A point that does worry me in the IBM agreement is that it is for two and a half years. In days gone by we were expecting four years of support or even five. Clearly what has happened is that the cut off date for IBM support has been static and the start date slipping. To be cynical - with a few more delays the start date will catch up with the cut off date and there will be no support. To be more realistic - I do worry over the amount of effort going into a service which may only give two and a half years of service. To be more constructive - the support of EARN after IBM withdraw should now be high on the Board of Directors meeting agenda for the 24th of this month.
With only two and a half years of support the finance required for the lines is now quite small compared with that for four years and perhaps we can persuade IBM to be a bit more generous. Certainly it seems pointless to go into further rounds of discussions with BT and IBM which would cause further delays and cost more than the money they save. The only sensible discussions are those aimed at a Europe wide agreement on the tariffs.
Regarding the X25 meeting. I have had difficulty getting in touch with all the people needed to discuss the management issues. None the less I will attempt a discussion at Heidelberg as you request. In particular, Jurgen has gone to ground. I do have a good set of people for the X25 migration meeting itself and my hopes are to produce some proposal or at least report for the BOD meeting so perhaps you could reserve me a slot.
Are you expecting me to give a report on the European Networkshop on the 24th or will you be doing it? I will have the documentation from that meeting available in a week. If this is to be circulated before the meeting with other documentation going out could you give me a dead line for giving you a batch of documents.
There has been one or two interesting developments from the Networkshop. In the electronic conferences there has been some concern at the adverse comment on EARN made at the event. There is a strong feeling that an accommodation must be found. I share this view and feel we need a discussion on this issue. DECUS has made an initial approach to 'joining' the proposed association on the grounds that user groups may be allowed to join at some time. I think this has resulted from a misunderstanding of what 'user groups' means. I suspect that their approach will be rejected but that there will be an encouragement for them to cooperate with the association. I suspect that EARN will be in a somewhat similar position.
Best wishes
Paul Bryant.
Dear Alain,
I would like to thank you for organizing the IBM side of the recent meeting. I should also like to apologize that my side on the organizing was such a shambles. None the less it turned out to be a most successful meeting. I hope the subsequent activities will be equally successful.
I look foreword to seeing you in Stockholm soon.
Best wishes
Paul Bryant.
Dear Guenter,
May I take this opportunity of thanking you for hosting the recent meeting. To my mind it turned out to far more successful than I expected. I should also apologize that my side of the organizing was a bit of a shambles. None the less I did manage to get most of the academics along that I wanted.
As I said to you I am most anxious to involve Rutherford Laboratory in the migration. Recently the Lab has fallen on hard times and for one reason or another we have lost many of our networking staff. I believe I see an opportunity here of building it up again and hopefully helping to lead the UK academic network towards ISO as far as IBM computers are concerned.
My major areas of interest are:-
Following our discussion on our priorities in life I find mine differ from yours. I am a European first, British second and a supporter of standards third!
I very much look forward to cooperating with you in the future.
Yours sincerely
Paul Bryant.
Dear John,
The situation regarding Coloured Book products on the IBM, VAX VMS and PRIME computers is unfortunately complicated. I will attempt to describe the situation.
IBM. There are two products which are not totally independent. The first and the oldest and most mature has been produced at Rutherford lab and is available free of charge from us but we offer no support. However several sites are using it with little problem. There are two variants. The first drives the line in Bi sync and therefore a 'stunt box' is needed to strip off the Bi sync and replace it with HDLC. Such a box can be bought from Edinburgh University for 2500 pounds or so. It is just a Z80 micro with a few bits and pieces. It will all work at 9.6K although the Bi sync from the IBM will go up to at least 48K. The second option is to use a 3705, 3725 or 4705 and put in some software from COMPRO into the device and this will allow our code to produce HDLC directly. The cost of COMPRO is 500 dollars a month and we also have to give Amdahl 150 pounds a month as they support it in the UK. Our product offers everything except Red Book job transfer.
The other IBM product is from Salford University. This requires a Series 1 front end. Recently our X25 code has been developed to front end the Salford product so it is possible to run it with COMPRO and a 3705. The product offers all the couloured book stuff. So far it is on field trial. It tends to be a bit big and cumbersome as the code was written with portability in mind and shares the hall marks of portability- slow, large etc. The product costs 17000 pounds to which you have to add the cost of the Series one with the X25 software and suitable operating system. I seem to recall that this could set you back 20000 pounds. The code has to be had from Salford.
VAX VMS. The X25 code comes from DEC and is the PSI software. The high level Blue Book was written by University and Wales Institute for Science and Technology. There is a triple X package from St. Andrews University which is said to have some advantages over the DEC product but I think they are marginal. The UWIST stuff contains mail and they are doing Red Book just now. DEC was supposed to market the package but are very reluctant to do so outside the UK. This has annoyed a lot of people and so the product tends to get overseas by semi illegal means. We are hoping that DEC will sue someone. The issue is that DEC are supposed to distribute it and support it and are not doing so. If you want a copy then the easiest method is to go to the Anglo Australian Telescope in Australia and they could give you a copy for VMS version 3. One is a bit reluctant to encourage people to knock off the version 4 product just yet. I enclose some interesting documents on the product.
PRIME. The prime product is derived from the Salford code, or rather the IBM version was derived from the PRIME one. It is marketed by PRIME. Like DEC they are playing silly buggers and will only supply it if it was in a contract to purchase a machine. This attitude is also causing some annoyance. There is a second product which we produces at Rutherford which, if you can get it, it is free. It requires some changes to PRIMOS to patch up their grotty code. It has a sensible triple X system, for example, which is produced by patching the PRIME one. The Blue Book stuff is quite good and stable. The Mail works but the user interface could benefit from some attention. Last time we tried to give the product away PRIME objected but I do not know why. If you really wanted it I could probably arrange it.
You are right that you could not use my id on the VAX here for mail. In fact something has to be set up in my login.com file and I will get that done. Truth is the id was only being used for testing the X400 code from the University of British Columbia. This software seems to have got a large following in Europe.
Since speaking to you last a few interesting events have taken place regarding the migration of the European Academic networking to ISO protocols. EARN (the European arm of BITNET) has decided to use a product from the Heidelberg Scientific Center of IBM. THis product looks well suited to our needs as it does not involve SNA as IBMs main line ISO product does. This stuff will initially offer X400 and other protocols will follow. These products may well be produced by IBM/Academic cooperation. The product needs a Series 1 front end but I am hoping that Rutherford's slice of the action will be to front end it with a 3705 with the COMPRO stuff. This will also give it triple x and 3270 over X25. It all seems to fit together quite nicely. The results of the European Academic Networkshop gather momentum as the working parties get going. The most active is the X400 one which meets in Amsterdam soon. The paper work from the meeting will be available later this week and I will send you a copy after it has been sent to the participants.
It you seriously intend to use coloured books then I would be happy to pull what strings I can to get you copies of code for the various machines. However, that would take quite a bit of effort and I would not want to do it unless you have serious intentions to use it. Certainly the first step would be to get Grey Book mail between your VAX and here so that we can improve our discussions. Unfortunately I do not really have the time to service any more mail boxes, I have far to many now.
I hope this is useful to you.
Best wishes
Paul Bryant.
2 pm Tuesday 16 July R31 Conference Room 1. MINUTES OF PREVIOUS MEETING 2. MATTERS ARISING 3. EXISTING NETWORKS AND FUTURE REQUIREMENTS RCCC/P6/85 4. THE SUPPORT OF PADS 5. MAIL 6. NAME REGISTRATION 7. TELEX AND TELETEX GATEWAYS Verbal report by P Bryant. 8. DATE OF NEXT MEETING 9. ANY OTHER BUSINESS
A recent meeting with CERN has resulted in a proposal to adopt the Columbia Mailer for mail between CERN and Rutherford VM/CMS systems.
The Columbia Mailer is a Mail Transfer Agent. There is a corresponding User Agent produced by MIT and RICE university which it is also proposed to adopt. The definition of a Mail Transfer Agent and a User agent are to be found in an earlier paper to GLM. Briefly, a Mail Transfer Agent is responsible for organizing the movement of mail between machines while the User Agent, with which it interfaces, provides a user interface. This mail system, commonly known as MAILER is widely used on BITNET and EARN. It follows the ARPA RFC822 standard and is thus very similar to Grey Book mail.
The system could be mounted at Rutherford with very little effort. In fact a version has been in use experimentally for some months with no problems. The situation is complicated by the EARN/IBM/Rutherford project to provide a mail gateway between EARN and JANET which will be based on the MAILER. As provided the MAILER will only provide mail between Rutherford and the EARN world which includes CERN. The gateway project will allow mail to pass between EARN and Grey Book domains to the advantage on the academic community as a whole.
There are two possibilities. The first is to mount the MAILER as it is and at a later date incorporate the gateway or to wait until the gateway is complete and to mount that. The first option is complicated in that it would ideally require a change to the user interface when the gateway is provided which could cause some disruption.
The gateway was scheduled for September but it is more likely to be in October. The slippage has been due to pressure on Tony Burraston's time rather than any problems being found in the project. The project was scheduled to take 6 man months but this is an over estimate. In all, about 8K of code is required. Approaching half the code has been written but, more importantly, considerable study has taken place to ensure that the project is sound and feasible.
This is the area where there will be disruption.
EARN is a mail naming domain and so is JANET. Thus names like OXFORD are not known in EARN and names like ROME are not known in JANET. Thus to pass from one domain to the other one has to go through a gateway which knows about both domains and can undertake some processing of the mail heading information. It must be remembered that it is practically impossible to have a single naming domain as this would imply a single network management structure which would be unacceptable to both networks. In the case of an EARN JANET gateway this processing is minimal since the structure in both cases follows RFC822 which is a very happy accident.
If the MAILER were to be mounted as it currently is then the Rutherford users would be in the EARN domain for sending mail to CERN and the JANET domain when sending mail to other JANET machines, this implies having two mail systems. This is clearly undesirable and thus one would really like a user to be permanently in one domain and to have only one mail system to contend with.
It appears preferable that Rutherford should be in the JANET domain as most mail is to and from JANET and there are obligations towards supporting JANET.
There will be two MAILERs running in the IBM with identical code. The first MAILER will run in the EARN domain and the second in the JANET domain.
The MAILER in the EARN domain will only transfer to and from RSCS or to and from the JANET MAILER. It will not be allowed to communicate with a user thus preventing a user operating in the EARN domain.
The MAILER in the JANET domain will only transfer to and from the users, the EARN MAILER or FTP. Thus the users will operate in the JANET domain.
The EARN MAILER will be driven by tables derived from the EARN network and the JANET MAILER will be driven from tables derived from the tables used by the existing network control program. Since the MAILER code is identical a fairly large piece of set up code has been provided. This is entered when the first file is sent to the MAILER. The exit needed to allow this is the only code change made to the MAILER and there is a high probability that this exit will be provided in the 'standard' MAILER as a result of this work.
Mail destined for the other domain can easily be detected and an appropriate exit used. This exit manipulates the headers and then directs the file to the other mailer.
+---------+
|USER |
|INTERFACE|
+---------+
|
+------+ +------+
|JANET |---------------|EARN |
|MAILER| |MAILER|
+------+ +------+
| \ | \
To FTP +--------+ To RSCS +-----+
|Table | |Table|
|derived | |from |
|from NCP| |EARN |
+--------+ +-----+
Mail which does not use the gateway needs an address of the form:-
BRYANT@RLGB in the JANET case PEB@CEARN in the EARN case
That is, they are identical in structure but the names used are private to the particular domain.
Mail which passes from JANET to EARN needs an address of the form:-
PEB@EARN.CEARN
Mail which passes from EARN to JANET needs an address of the form:-
BRYANT@RLGB.JANET
Note that the last two forms are not symmetric due to different ordering conventions of name components in the two networks.
Thus, if one started the project with Rutherford in the EARN domain addresses of the form PEB@CEARN would work but later addresses of the form PEB@EARN.CEARN would be needed if and when the gateway was brought into use. It would be difficult to allow PEB@CEARN to continue to work as there is no fool-proof way of deciding whether CEARN is a JANET or EARN name and thus where to send the mail. In fact the only way of allowing it would be to have two mail commands, one would operate in the EARN domain and one in the JANET one and this goes against the principle of a single mail command. When one considers that there are 600 machines in the EARN domain and a similar number in JANET there is a lot of room for ambiguity if any deductive means of determining the domain are used rather than explicit routing to another domain.
The introduction of the system would not prevent the current mail user interface from working but would provide an alternative which had the added attraction of providing mail to EARN. It is envisaged that the new interface would be more popular and that the current one could be withdrawn after a suitable period.
The advantages of the new interface are:-
It is unclear whether PROFS could take advantage of the MAILER. It would certainly not have a detrimental effect since current methods would continue to work. It is desirable for PROFS to use the system so that the older systems need no longer be maintained. Work is in progress at City University New York to connect PROFS to the mailer and further study is needed to see if this could be used at Rutherford.
The MAILER is supported by a small number of people in the EARN community and it is free. Thus, there is no guarantee of continued support. On the other hand, since there are a large number of sites using it, it would be unlikely that the community would allow it to become unsupported. It is expected that the system will be improved into the foreseeable future and Rutherford would automatically be able to take advantage of such developments.
The gateway code is Rutherford's responsibility and although there is talk of one or two other sites using it, it would seem unlikely that support would be obtained from elsewhere. It may be possible to get modest finance from IBM to improve it.
Care is being taken to make minimal changes to the MAILER as delivered and, in fact, efforts will be made to get such changes adopted as they are useful in any gateway activity. Discussions with the author of the MAILER, Alan Crosswell, make such adoption almost certain.
It is proposed that a trial service is mounted for 4 or 5 users at Rutherford and 4 or 5 users at CERN with a view to obtaining user reaction and also confirming that the product is suitable. The results of the trial will be presented to the CERN/Rutherford meeting in September to confirm the intention to provide a service. The provision of a service will be delayed until the gateway software is available. It is proposed that further study should take place to see how best PROFS can take advantage of the development.
Group leaders are invited to consider the options:-
If the proposal is rejected then Rutherford is still obliged to continue with providing an EARN mail gateway which may be inaccessible from the IBM computer except via another computer.
If the MAILER is mounted as provided then users will be faced with two mail systems depending on which direction mail is to take. In addition, when the gateway is provided either there will be some disruption or the gateway will be inaccessible from the IBM.
If the use of the MAILER is delayed until the gateway is complete (October) there should be least disruption and a single mail interface to JANET and EARN. This is the recommended option.
The mailer is free.
The development of the gateway is funded by IBM.
Documentation will be required but this should be common to CERN, Rutherford and other sites using the system.
There are two risks. First, that the MAILER will become unsupported. Second, changes to the MAILER may require changes to the Rutherford produced code.
It should be remembered that in the next 5 years it is likely that the current mail systems will start to be replaced by ones based on the X400 standard and hence the product has a limited life expectancy.
The MAILER is not as sophisticated as the GEC one. It has no staging facilities or facilities for matching real names to user ids. Thus it is not a competitor for a site mail system. This is a pity. None the less the MAILER is a developing system and such facilities may become available if there is sufficient interest and pressure in the community.
Networking in Europe developed ad hoc Developed to meet national needs Different protocols in each country Initially access to local centre Later access to various national m/c Now want international access
Most European countries have a plan All interested in heterogeneous nets No manufacturer protocols acceptable Desire to use manufacturer products Only acceptable option ISO Strong support for ISO from ESPRIT, European Commission, ECMA.
ISO not complete Easy to produce incompatible products Difficult to get products Europe has inter county problems Manufacturers apply pressure to adopt their products
1983 Karl Zandar wanted to harmonize German and Italian protocols Widened to whole of Europe Series of meetings in Brussels 5 COS documents:- Network layer Transport layer Session layer LANs Terminal access XXX
Funds ran out! Work taken up by Esprit Academics quietly forgotten Lot of unhappy people
Late 1984 a group decided to try again Invited small organizing committee to meeting Decided to set up a workshop Set up sponsors:- European Science Foundation ECFA COST Decided to get representative in each country to select delegates Object - sort out European Academic Networking.
Presentations restricted to use of current technology No research topics Aim to invite leaders in European Academic Networking Invite CEC, CEPT to get their support CEC keen offered Luxembourg site Academics all very keen.
Lot of hard work resulted in good meeting Karl Zandar in opening address wanted an 'ASSOCIATION' + coordination Evening meeting proposed a plan Plan endorsed by full meeting
Set up an association- initial members are COST 11 countries and CERN- European commercial research laboratories will be associated later as will user groups Set up liaison with CEPT to sort out tariffs and services (X25 84) Set up liaison between academic network operators Set up working party on X400 Set up working party on FTAM Set up working party on X25 84 Set document collection/distribution service Set up working party on full screen.
RESEAU ACADEMIQUES ET DE RECHERCHE EUROPEENS To foster European networking with open systems interconnection Want high quality network infrastructure to support academic endeavor Base services on public networks.
Finance will probably come from COST Set up small secretariat Finance for meetings No finance for projects- already enough in national programs Encourage OSI nets, encourage transition interconnect current nets.
Results well received Organizing committee continues to organize Results of meeting now published Determination to maintain momentum
Expect Europe to have strong, coordinated and harmonized approach to X400. Short term expect mail gateways Long term expect only European academic mail system to be X400 Anyone with similar ideals is welcome to participate.
All networking groups with similar ideals urged to cooperate under RARE EARN can and is providing communication between RARE workers NOW. EARN could lead work required to ensure IBM machines have excellent harmonized network products EARN experience and expertise must influence the work.
CEPT requires EARN to migrate to the use of ISO protocols and public networks by the end of 1987.
A meeting was held 8/9 July 1985 at the IBM Heidelberg Scientific Centre between EARN and IBM experts to decided on a migration strategy. This document is a proposal resulting from that meeting.
It was agreed that the Heidelberg X25 ISO product was best suited to EARN use. It is proposed that this product should be further evaluated to confirm its suitability. It is proposed that a number of developments are undertaken to better match the product to EARN use, some of these are essential and some desirable. It is proposed that the product be adopted if the program of work defined below is successful.
The program of work proposed is:-
A small number of lead sites in different countries be identified and are provided with suitable hardware and the Heidelberg product. The sites will undertake an evaluation using the public X25 networks which will start in December 1985 and terminate in June 1886.
If the evaluation is successful lead sites in each country will be selected who will install the product and provide a pilot service.
Subsequent to the operation of a pilot service traffic will be moved to the new service from the current RSCS service with a view to completing the transition by the end of 1987. This will be undertaken with care to avoid disruption.
It is proposed that a study be undertaken to identify the enhancements which are essential to providing a service and a proposal produced as to how such enhancements should be provided.
It is proposed that a study be undertaken to identify the desirable enhancements and a proposal produced on how these could be provided.
It is proposed that a study is undertaken to clarify the financial considerations in adopting X25 protocols and secondly in using public networks.
Finance will be required to provide a number of Series 1 processors to enable evaluations to take place.
Finance for staff to undertake the evaluations is required.
Finance may be required to commission enhancements to the Heidelberg product.
The EARN Board of Directors are invited to support this proposal and to consider how it may be financed.
The use of non X25 networks such as ISDN were rejected on the grounds that there were no Europe wide or in most cases national services available or likely to be available within the time scale in which EARN is required to migrate. In addition, manufacturer products to take advantage of these services are unavailable. Thus only options based on X25 services are considered to be viable migration options. Non X25 options should be further considered as and when suitable services and products become available.
The following options have been considered:-
The advantages of selecting one of the options offering RSCS are:-
The disadvantages of selecting RSCS are:-
It was considered that a migration involving RSCS was undesirable.
A presentation of the IBM ISO products was provided. These are a complex and developing set of products associated with SNA. The advantage of the products are:-
The disadvantages of the IBM ISO products are:-
It was concluded that at this stage it was not a suitable product for using in the migration of EARN but it would probably become more attractive when protocol standards had stabilized and the products were more mature and proved to be suitable.
Salford University in the UK have a 'Coloured Book' communications product for IBM computers which is under field trial at Liverpool University. This product uses a 3705 or Series 1 communications processor. They have finance to adapt the Blue Book file transfer product to be ISO FTAM and expect this to be available in March 1986. They believe they will have finance to adapt the Grey Book mail to be X400. They have no finance, as yet, to adapt the Red Book job transfer to be ISO job transfer protocol. The product also provides triple X.
The advantage of the Salford product are:-
The disadvantages of the Salford product are:-
It was concluded that this option had a high risk and that it may be difficult for EARN to influence the direction of development.
There was a presentation of the Heidelberg product. This is being developed in conjunction with DFN at the IBM Scientific Centre. It currently provides MHS. It also will provide a gateway between EARN and ISO protocols which are being used by DFN.
The advantages of the product are:-
The disadvantages of the product are:-
It was concluded that the Heidelberg product could provide a suitable vehicle for migration and was the most attractive option. It was further concluded that the product offered good development potential which would allow it to be developed to meet the emerging requirements of the users as well as the requirements to harmonize with other academic ISO activities.
This decision would not prevent a migration to an alternative product, which could be an IBM strategic one, at a later date.
A program of activities has been developed and is proposed to migrate EARN using the Heidelberg product.
The Heidelberg software will be mounted on a Belgium machine as soon as possible in order to convince the PTT to allow Belgium to participate in EARN. This should not be regarded as a integral part of the program.
A small number of lead sites from different countries will be selected which will acquire Series 1, and mount the Heidelberg product in December 1985. A representative from each of the sites will attend a two week meeting at Heidelberg to familiarize themselves with the product just prior to installation.
A six month evaluation phase will test the product over various X25 networks. One site will be designated as a 'master' and will coordinate the activity. It is expected that the evaluation will reveal various operational and technical problems which will hopefully be solved. It will also reveal to what extent the product can replace the current RSCS network and if there are deficiencies these may be rectified or lead to further developments.
At the conclusion of the evaluation phase and if successful the product will be mounted on at least one site in each country. These sites are expected to be those which now have international connections. A pilot service will be mounted with the aim of moving traffic gradually from the international leased lines to the X25 connections. This migration should be completed before the end of 1987.
At the conclusion of the evaluation phase countries may migrate their national connections to use the Heidelberg product but this would depend on local circumstances and would be planned on a national basis.
It is recognized that the Heidelberg product is deficient in only providing X400. It is unable to provide all the services that can be provided by RSCS. Moreover there are facilities which RSCS cannot provide, which are desirable and can be provided with the use of ISO protocols. It is proposed that a long term study be undertaken to identify the developments which are essential to allow a migration and those which are desirable to provide a richer service. The study will recommend how these developments should be undertaken. For example, by Heidelberg, by contract with a university or other organization, or by unfunded enterprise in the community.
It is proposed that a report is provided at each Board of Directors meeting on the progress of the project.
Some, if not all, of the lead sites will require Series 1 computers. The cost per series 1 is about $35,000. Software costs are about $9,000. The software is:-
RPS operating system - 5719/PC6 X25 - 5719/HD1 370 channel software - 5719/CA1
The subsequent installations may require similar equipment depending on whether or not the product is developed to enable a 3705 to be used instead of the Series 1. Many sites already have 3705s which could be used. Although many sites have series 1 computers these are usually dedicated to special tasks and would not be available for EARN to use.
The Board of Directors is invited to consider how the equipment should be financed.
It is estimated that each lead site will require 2 man months spread over the 6 months. In addition the master site requires 4 man months to take account of the coordination activities.
Subsequent installations should require no more manpower than is required for running the current EARN connections.
Finance will also be required for travel and subsistence, in particular for the initial 2 week meeting in Heidelberg.
The Board of Directors is invited to consider how the man power requirements should be financed.
EARN contains DEC VAX and CDC computers in addition to those of IBM. For the replacement of the international links the non IBM machines need not be considered as these links only go to IBM computers and the other manufacturers equipment can gain access via the EARN ISO gateway which is part of the Heidelberg products.
DEC have recently stated that they intend to provide ISO communications products. It is therefore anticipated that if a particular countries network is to migrate to ISO then the DEC product should be used. There may be problems of compatibility that will have to be addressed when the various products are all available.
CDC will provide ISO products under their new operating system NOS VE.
There is a miss match between the services that RSCS provides and those that the Heidelberg product offer. There are additional services that the product can provide depending on the protocols which are eventually added.
The principle added service is interconnection with a wide range of products which are expected to provide ISO protocols in the future.
The table shows the comparison between the RSCS services and ISO services.
+--------------+---------+-----------+------------+ |Service |RSCS |ISO |Heidelberg | +--------------+---------+-----------+------------+ |File Transfer |yes |FTAM |no | |Mail |yes |X400 |X400 | |CP messages |yes |no |no | |3270 |no |no |no | |interactive |no |triple X |planned | |full screen |no |VTP | | +--------------+---------+-----------+------------+
The table is not satisfactory as in it does not give an accurate view of the situation and the following notes add some useful comments.
The Heidelberg product will not initially provide FTAM and thus file transfer. None the less X400 can be used for file transfer to a limited extent which is sufficient to give the functionality provided by RSCS.
Further study may show that CP messaging can be provided by using one of the existing ISO protocols or defining a special one.
Although there is no explicit support for 3270 in the ISO protocol range several methods have been demonstrated for achieving this end by, for example, defining a protocol to operate over triple X.
The provision of interactive services will be a very useful addition to EARN services and it is likely that the Heidelberg product will include triple X at an early date.
Mention is made of full screen services which will be provided by VTP for completeness. Currently the protocol requires considerable development before any services can be defined to use it. Hopefully it should be able to support 3270 or 3270 like services but this is speculative.
It was considered that the provision of triple X was essential as this could substitute to some extent to the loss of CP messaging and is in any case a highly desirable service. All the other services are regarded as desirable.
The Heidelberg product operates under VM. It was considered that a similar product was required for MVS as there are a number of such machines in the community. It is unclear how this can be provided and further study is recommended.
The Heidelberg products include an EARN ISO gateway. Gateways will be required to other networks such as JANET, SUNET and possibly others. The provision of these gateways is considered to be essential. These should not be difficult to build or develop from the EARN ISO one. Further study is needed in each case.
It is likely that at some stage traffic to BITNET will have to pass through a gateway. Care must be taken to ensure that the use of this gateway will not inhibit traffic and that it will be of a high quality.
The Board of Directors is invited to consider how the development of gateways should be financed.
There are now many groups developing ISO networking in the European academic community. At a recent workshop in Luxembourg the community enthusiastically agreed to set up an association to coordinate the many activities and to ensure that the protocols used were to harmonized standards. This should ensure ease on interconnection. It is recommended that EARN should cooperate in this activity and ensure that the Heidelberg products conform to harmonized standards. The meeting was pleased to note that the X400 definition provided by DFN which will be respected by the Heidelberg product is being considered by the X400 group set up as a result of the Luxembourg meeting.
EARN should cooperate with harmonization activities involving other protocols.
From the meetings participants 5 lead sites were identified subject to confirmation. These are:-
GMD Germany Leuven or Leige Belgium Dublin Ireland Rutherford UK CERN Switzerland
It is proposed that GMD should be the master site since it has good access to Heidelberg.
Other sites should have the opportunity of offering to be lead sites and the Board of Directors should, if necessary, select a suitable set.
With the information to hand little progress was made on studying the relative costs of the current RSCS network, an X25 network based on leased lines and an X25 network using the public networks. Such an exercise is very complicated due to the many different tariffs in the countries and also the difficulties of measuring traffic. In addition the future changes in tariffs are unknown as are the future traffic levels in EARN. A further complication is that the three options require different man power and equipment levels and these costs must be taken into account. It is likely that the way networks will be provided across Europe will not be uniform. For example, the UK has already opted for a leased line X25 network while DFN has elected to use the public network DATEX-P.
It is believed that some useful figured can be achieved by studying the current EARN network.
It is proposed that the current statistics programs be developed to allow the traffic to be costed as thought it came over an X25 network. Each main country node should be encouraged to modify the program with its countries X25 tariff structure, to run the program regularly and collect the results. These results should be collated and analyzed to provided some cost figures at a single site.
The meeting did not consider the implications of using a leased line X25 network. If it is considered desirable then a study will have to be carried out which would include the selection of suitable switches and the redesign of the topology of EARN. This would be a major activity.
The attendance was from members of the technical committee who had volunteered to take part in this activity at the last EARN technical meeting. In addition IBM generously provided experts. Thanks are particularly due to Alain Auroux for organizing the event under very difficult circumstances.
Paul Bryant Rutherford Lab. UK. PEB@CERN
Michael Walsh University College Dublin WALSH@IRLEARN
Marco Sommani CNUCE-CNR Pisa VNETMNT@ICNUCEVM
Alessandro Fusi IBM Rome Sci. Centre FUSI@EARNET
Kund M Roehr IBM Stuttgart ROEHR@DEARN
Colin Setford IBM Hursley HEL11@WINVMD (VNET)
Guy Weets IBM Belgium WEETS@BRUVMIS1
Alain Auroux IBM EHQ Paris AUROUX@FRMOP11
Berud Kirchner IBM Stuttgart KIRCHNER@DEARN
Didier van der Straien IBM Belgium 62483080@UITHONE
(VNET)
Guenter Mueller IBM Germany MUE@DHOIBM1
Berthold Pasch IBM Germany PASH@DHDIBM1
Roland Wolf GSI Darmstadt WOLF@DEARN
Oliver Martin CERN MARTIN@CERN
Jurgen Harms University of Geneva HARMS@CGEUGE51
On the face of it Ted Owens proposal is attractive.
Certainly, given effort I would like to run it or cooperate with it. The problem is 'given effort'. The items listed all look like absorbing effort of one sort or another. To get a strategy agreed and maintained looks like a new series of meetings. On evaluation of PCs and interfaces- we do some of that now - however doing it for a group of people would mean that the results would have to be written up carefully - no bad thing but effort. Producing and contributing to a newsletter is effort.
Currently we are putting one and a half men per year into PCs. About a year of that is now dedicated to user support, running the purchasing agreement and assembling kit. As the numbers of PCs rise so will the amount of effort needed. That leaves 6 man months doing development and evaluation work which is very small.
To comment further on Teds proposal:-
I do not think SERC should evolve a network strategy- this is something to be done in conjunction with JNT. That is not to say that we should not take an active part in helping JNT- as indeed we are.
Evaluation of PCs and interfaces is something we do a bit of. Much of the work is done for us by magazines and it is more about being aware of what is happening and reading than running test and so on. To do real evaluation of any magnitude takes more effort that I have got.
Evaluation of commercial packages comes about in two ways. The first is that we have a lot of pieces of software which have been bought for evaluation and by customers and which we look at as it passes through. This is a valuable exercise. However many commercial packages have been well evaluated in the mags to a higher quality than we could achieve with our resources.
SERC wide licenses would be useful if they saved us money. I am very doubtful if we could get such licenses. The agreement with IBM is good and is unlikely to be bettered. Thus we are talking about other products. In fact 'other products' tend to be special one off purchases of items. To get any sort of deal we would need to get a supplier who we agree to buy from who would give us a good discount on all the odds and sods we want and which IBM cannot supply. This would be difficult especially as dealers tend to deal in only a selection of products. An exception to this could be if we decided to put all our machines on an ether net in which case we would want to buy 30 or so boards when a sensible discount would seen appropriate.
On software development we have developed only three large products. The first is our multitasking sub operating system and second the full screen Cifer code which fits in it. The third is disc dumping software. It now appears that the PC is endowed with such a wealth of software that the only stuff it is sensible to develop is real applications stuff. This cooperation would be in that area. In fact I only have one user in Laser Division who is seriously writing his own software. All the rest of my clients are running of the peg software.
I like the idea of a newsletter. In fact I have been intending to write one for the site for 6 months but it has never come up to the top in my priority tray. This is to be regretted. However - if I did put one out the number of PCs could increase and give me more work! In any case my clients seem highly satisfied with the PC and highly delighted with the support they get. We now have two clients who have inadvertently wiped out their disks and are our friends forever when all was restored.
I like the idea of information exchange. In fact when in CERN I usually ferret around to find out what is happening on PCs and find that they are used in much the same was as at Rutherford.
I certainly will need more effort if many more PCs come on site and we must explore ways of providing it. One way would be to start charging but this is only sensible if the charges can be turned into manpower. Offering to run the coordination service is another way of upping manpower which is attractive.
To sum up - I would certainly encourage the idea but dread the thought of it absorbing some of my very scarce resources.
It has turned out that IBM PCs, unlike UNIX and many other of our machines, do not need an army of systems programmers. The systems come with good software which is well documented. They are designed with the novice in mind and tend to be comparatively easy to use.
The major gap in the PC is its lack of networking suitable for this site. That is following ISO JNT lines rather than proprietary stuff. This gap should be filled with various products which are under heavy development and which we hope to help the JNT to evaluate in the new year. In the mean time I tend to resist ideas of putting then all on 3270 cables or some similar idea. In fact my users are not particularly interested in communications as most have stand alone requirements.
This may all change if we start to look after UNIX IBM PCs. We hope to get it for evaluation soon. UNIX, of course, takes an arm and a leg to look after and we shall have to think very carefully before we make any commitments in that direction.
I hope that is helpful.
Present:- Paul Bryant, Michael Walsh, Marco Sommani, Alessandro Fusi Kund M Roehr, Colin Setford, Guy Weets, Berud Kirchener, Berthold Pasch, Roland Wolf, Olivier Martin, Jurgen Harms.
The meeting was to explore some of the problems in managing EARN. A number of other items were also covered.
There is a feeling that EARN is 'drifting' and that some corrective action is needed to tighten up on procedures.
Name tables are taking a long time to be updated once a new node has requested connection. It was reported that it had taken 15 days on one occasion.
The procedure is that the site fills in an electronic form at their national centre. This is passed to the European centre at Darmstadt. It is then sent to the world centre at CUNY. The world tables are then distributed back down the chain.
It appears that the European part of the organization is working well but that there is currently some reorganization in the USA which is causing delays. Arte Ecock no longer had time to do the job and this was now being done by Candice Willut (CANDICE@BITNIC).
It was a sites responsibility to go and get new tables. It was felt that some way of informing all sites when new tables were available was needed. In addition it would be useful if there were some automatic way of checking if sites had failed to put up new tables, in particular the backbone nodes.
The BITNIC centre, which is now dedicated to EARN management, consists of a machine and 6 people. There is a lot of voluntary labour.
It was agreed that relations with BITNIC should be discussed at the BOD meeting when hopefully Ira would be present.
It was felt that each site needed a liaison officer to contact when things went wrong. This should not be the normal support but someone in authority who could take decisions. It was decided to talk to Arte Ecock to see if BITNET felt it needed such people.
There are still problems with formats between VM and JNET as well as VM and VMS. It was thought that Netlink would one day be the only standard but it was unclear when this would be. Apparently Zurich had written a utility to undertake conversions which ran as a virtual machine under VM. It would be useful if this could be made available in NETSERV.
There were problems with machines being unavailable due to holidays, maintenance, and sometimes week ends. There seems to be a problem somewhere in the network about once a week. Ideas of sending notes to sites whose availability dropped below 80% were suggested. This could be a subject for the next technical meeting.
The automatic updating of NETSERVs was now almost working which would ensure that they were all consistent and obviate the need to access NETSERVS in other countries.
Again a subject for the technical meeting. It seems GRANTS is the favoured system.
The French project was near completion and again this should be discussed at the technical meeting.
The last technical meeting had recommended a Europe wide newsletter but this had not yet happened. This should be discussed at the BOD.
It was unclear how travel and subsistence should be claimed. The BOD should be asked to produce the rules and regulations. It was felt that it should be offered as a right rather than only to needy cases.
The Rutherford Laboratory has defined a protocol for allowing a data stream suitable for driving an IBM 3270 terminal to be carried over an asynchronous connection. The connection may be a physical connection or a virtual X29 connection over a network. This allows a terminal directly connected to an IBM computer or to a PAD to imitate a 3270 terminal. It also allows a 3270 connected to an IBM computer to access a remote IBM computer as though it were a locally connected 3270.
IBM PC ASYNC/3270 is a implementation of the ASYNC/3270 on an IBM PC. Other implementations exist on a CIFER terminal and a BBC micro.
A technical description of the protocol is in 'ASYNC/3270' by P Bryant which is available from the Rutherford Laboratory.
The product operates under all versions of PC DOS and on all PC clones so far tested which are suitably configured.
The system is built into a multitasking operating system which is used for a number of other products. This means that several load modules are needed which represent the various parts of the system which are needed. However the system is started with a single command. A second command is needed to select the subsystem even though in most cases there will be only one such subsystem. An interesting, but probably not very useful feature, is that up to 8 sessions can be run concurrently given that there are enough asynchronous ports and enough memory. There is an opportunity to reconfigure the asynchronous port to match the characteristics of the connection with respect to speed, parity etc.
The protocol expects a terminal to operate in two modes. First as a scroll terminal and second in 3270 mode. The switching between the modes is by means of an 'escape sequence'.
In 3270 mode the data is packetized into blocks which represent a data unit between the computer and the terminal. The blocks are split into sub blocks of 256 bytes or less for ease of handling. The is a sequence check in the sub blocks which has the effect of causing an error message if it fails. There are no other checking features. The content of the blocks is very similar to the data stream which would go to a 3270 from an application. However a major difference is that the data is encoded in 7 bits which allows it to pass through most networks. The data is mainly in ASCII except that certain command bytes and the sequence number map onto 7 bit codes.
In 3270 mode the device becomes half duplex in common with the 3270. This is enforced by locking the keyboard after generating a transmission. The keyboard is unlocked by the computer. Clearly this implies that in error conditions a deadlock is possible which is overcome with a reset key. If used during data reception data will be lost and confusion will result until the operator causes the screen to be refreshed.
IBM have a policy of continual improvement in their products. This means that at any time the implementation on a terminal may not contain new facilities. However the protocol is insensitive to new facilities as these are ether private to the terminal or carried in the data stream transparently.
The product has been proved to work at all speeds up to 9.6K bps and there is no reason to suppose that it would not work at higher speeds. Failures at higher speeds will be the loss of characters input and this will be reported to the operator.
IBM-PC or similar. IBM asynchronous adaptor or similar. 128K memory. Single floppy disc or hard disc. Monochrome display or colour display. Direct connection to an IBM computer or via an X25 PAD
The IBM computer will require for a direct connection ... from the Rutherford Laboratory.
The IBM computer will require for an X25 connection either the Salford 'Rainbow' package or the Rutherford X25 package.
Support is on a best endeavour basis from Rutherford laboratory.
The product is free to academic institutes.
Send an IBM floppy disc to P Bryant Rutherford Laboratory and the product will be supplied as soon as possible together with user documentation. There are no options.
The product has a number of limitations:-
Colour is not supported although the use if a colour screen is. This may be included later.
Entry assist is not supported although there are plans to include it.
There is no file transfer facility although there are plans to include it later.
The 3270 part of the product was written by P Bryant, the suboperating system by D C Toll and modifications have been made by G W Robinson.
The protocol is asymmetric with one end of a connection being HOST and the other TERMINAL.
The protocol has a level structure which does not match the ISO model.
LEVEL 1 DATA UNIT Byte with bit 0 being 0.
The means of transferring the LEVEL 1 DATA UNIT are outside the scope of this protocol.
Command - valid only when received by TERMINAL.
ESC | <type> [should this be followed by <CR>, if now how can you
detect ESC | O 34 say]
3270 PART DATA UNIT
STX <seq> <3270 DATA> <ETX> <CR>
3270 FINAL DATA UNIT
STX <seq> <3270 DATA> <ETB> <CR>
3270 NOT CR DATA UNIT
STX <seq> <3270 DATA> <ETX> <CR>
There is one major mode:-
3270 MODE or NOT 3270 MODE
In 3270 MODE there are two minor modes
CR MODE or NOT CR MODE
N MODE or NOT N MODE
Command types
Type Effect
C set 3270 MODE, set N MODE, set NOT CR MODE, set DELAY=2, set
<seq>=X'20'
C set <seq>=X'20'
D set NOT 3270 MODE
L toggle CR MODE
O<delay> set DELEY=<delay>
o<delay> set DELAY=<delay>
N toggle N MODE
Note: ESC | not followed by a valid command is not a command.
This was the annual get together of the folks across the world interested in mail, otherwise known as the Landwebber meeting.
About 30 people attended. There were only two formal talks from Dennis Jennings and myself. Dennis is on a sabbatical from Trinity College Dublin to a group in USA who are setting up a network for super computers. He described how the American networks were intending to migrate to ISO. The idea is to adopt TCP/IP and then migrate that to transport class 4. They do not feel that the use of X25 is necessary as the X25 public networks in the USA are poor and they believe that the protocol is not suited to high speed networks which they hope to have soon. My talk was on RARE which defines the direction Europe hopes to go in. It looks very much as though Europe and the USA will be going in different directions. The one advantage that the Americas have is lots of money.
Where there is unanimous agreement is in the use of X400. We split into a number of groups to study various aspects. One did gateways, another charging and I led a group on directory services. In this we studied the new CCITT proposal which is fascinating. It advocates that the directory services should be based on things called DSA (Directory Service Agents) which really form a distributed data base of directory entries. There are DAs which are directory agents which give access to the system. We studied how such a system should be constructed for the world academic community. We thought there should be a master DSA which contains details of countries and major organizations. Under this there would be national DSA- one in each country- containing details of organizations. Finally there would be DSAs in the organizations but we could not decide how they would be structured. There are protocols defined for accessing the DSAs and moving data about. There would have to be a lot of duplication to reduce network traffic.
It was a very useful meeting and very timely considering the interest on site for a directory service.
This also split into working parties and a number of issues predominated.
It is clear that the organization needs funds and it has been decided to have a fund raising study. Ideas are to seek funds from other organizations than IBM- ICL, Bull, CEC, PTTs and so on. There may well be a subscription of 250 pounds per site. How this will apply to the UK is unclear. The money is needed for travel and minor developments.
The results of the migration to ISO meeting were well received and so I now have to put together a more detailed plan to adopt the Heidelberg ISO software. I hope to get some IBM funds for Rutherford so that we can participate in the evaluation. Looks promising.
I gave a presentation of the RARE meeting. It had a mixed reception- more accurately a religious reception. Certainly there are people who feel it is unfortunate. Some feel that such an organization should be of networks not countries, that it should concentrate on future high speed technology and not X25, it should not be so shackled to X25. On the other hand it was welcomed by some as a vital step forward and that consideration of high speeds and other matters could evolve. Most of the board were silent. I believe EARN is more than likely to cooperate with RARE.
Tariffs came up for discussion and in particular the UK ones. Thomas Huebner of CEPT was at the meeting and was very helpful and I think I have yet another way of persuading BT!
The CEC were represented by Chris Wilson and I think he will go back to Brussels less frightened of EARN having seen the people involved.
We have now decided to have board meetings only once a year and an executive has been set up which will meet 4 times a year. However we will have a board meeting in Brussels at Christmas when we also hope to have discussions with CEC.
It seems BITNET will migrate to TCP/IP in time and EARN to X25. Thus I expect the two networks to part company technically in 2 or 3 years.
Dear EARN Colleague,
The next EARN Technical Meeting will be held at 'La Mainaz'. This is a hotel and conference centre which is 25 km from Geneva and across the French border. Being at 1500 meters in the mountains the scenery is superb but the climate chilly so bring warm cloths!
The cost will be 600 FF per person. The hotel takes all credit cards. Travel costs will be reclaimable from the association.
The hotel has accommodation for 30 people but it only has 25 bedrooms. Thus late bookers may have to share a room.
As with the previous meeting we will ensure that each country has two places and allocate any remaining places and places not required by a country on a first come first served basis.
If there is sufficient demand we intend to run a coach from Geneva airport leaving at 18.15 hours.
We will arrive the evening of 18 September and a meal will be available. We will leave the hotel at 14.00 hours and a coach will be provided if there is a demand.
I am sending this letter to the participants at the last meeting plus the Board of Directors members. Please would you ensure that it gets to the right people.
I look forward to a lively and constructive meeting as the Coseners' one was.
Yours sincerely
Paul Bryant.
EARN TECHNICAL MEETING
AT LA MAINAZ
September 18/19/20 1985
DRAFT AGENDA FOR THE SECOND EARN TECHNICAL COORDINATION MEETING
SEPTEMBER 18/19/20 AT LA MAINAZ
As with the last meeting, I expect it to be fairly informal with an opportunity to educate ourselves as well as deciding on the future technical direction of the network. I would appreciate people being prepared to talk on topics they feel they can contribute to. These will be more valuable if written contributions can also be provided. Please let me know if there are any additional items you would like to add to the agenda.
September 18.
Arrive. A meal will be available and there will be an opportunity for informal discussions which are so important at these meetings.
September 19.
1 9.00 Introductions.
Minutes of the previous meeting.
Matters arising:-
Use of two character country codes (item 4)
Berthold Pash, Doninique Pinse and Arthur Ecock
to study directory services (item 9)
Roland Wolf, Mats Brunell, Michael Walsh and Tony Burraston
to study the MAILER (item 8)
Appointment of country coordinators
Mechanisms for problem reporting (item 10)
Roland Wolf to evaluate accounting and statistics tools (item 4)
Marco Sommani to investigate the relation between packets
transmitted and bytes transmitted for accounting (item 4)
Newsletter progress (item 10)
Paul Bryant to set up ISO transition meeting (item 3)
2 10.00 Review of the state of EARN.
Participants are asked to produce a brief review of the
state of EARN in their countries.
3 11.00 Migration of EARN to ISO protocols.
Attached is the report of the EARN ISO migration working party
which met at Heidelberg on 8/9 July. The report was accepted
by the Board of Directors at their meeting at Stockholm on
24/25 July. The meeting is invited to consider the report and
decide what further actions are needed. In particular:-
How is the coordination to be handled?
Who are the experts involved at the lead sites?
What additional facilities are required to allow it to replace RSCS?
What are the priorities for enhancements?
Are there any national plans for migration to ISO protocols.
4 12.00 EARN management.
Attached is the report of a meeting held after the ISO meeting
at Heidelberg to consider some management aspects of EARN. The meeting
is invited to consider the report and decide what
actions are needed. Particular topics are:-
Keeping tables up to date.
Link reliability.
The problem of knowing when machines are down.
The collection and publishing of statistics.
Provision of figures to the PTTs.
Node naming.
13.00 Lunch.
5 14.00 BITNET.
Report of BITNET technical progress.
6 15.00 Applications.
Discussion on the progress of the conferencing and bulletin boards
GRAND and POTACOM. When and how should services be provided?
Progress with NETSERV and BITSERV.
What additional developments are planned and needed.
7 16.00 Gateways.
Reports on the various gateways, UK, Germany, Sweden,
Norway, Switzerland, Finland and others.
User information on gateways.
17.00 Finish.
September 20
8 9.00 Mailers.
It was recommended that the Columbia mailer should be run on
sites. How mail services are developing will be considered.
The acceptance of X400 has been faster than expected, how will
this effect EARN? Should the British Columbia EAN system be
considered for use.
9 10.00 Name servers.
Presentation and discussion of the French project.
10 11.00 Operational problems.
JES3 and other software problems.
Hardware problems.
Other operational problems.
Newsletter.
11 12.00 Date and location of next meeting.
Switzerland as the organizer of this meeting are ruled out as
is the UK. Any offers?
Any other business.
12.30 Lunch.
Dear Mr. Roberts,
I first must apologize for not replying to your two letters. I am afraid that are pitiful staff levels have meant that it has stayed rather near the bottom of my in tray.
I find that apart from our PC AT all our machines have warranty cards. The AT has not got one yet as we are still awaiting the delivery of a disc.
Some time ago I had a veritable snow storm of blank warranty cards and I merely took the next card from the pack as new machines came in. Thus there is little relationship between the card numbers you sent me for specific shipments and the use to which the cards were put. I gather that the problem was that you had some reorganization that caused some hiccup - an effect I am well used to here and sympathize with. Thus I am very happy with the warranty situation.
While on the subject of warranty I do have a problem that I raised with Celia Ward. We had a number of XT/370 delivered and one set of 370 boards was faulty. We use Kode services for our warranty work but they refused to touch the boards as they had not dealt with them before and I was advised to send them and the machine to your Greenford plant. In fact the 370 boards were not being used and we were reluctant to send you a machine which was in heavy use. Apparently you would not accept the boards on their own. This seems a pity considering the high cost of carriage and the inconvenience. Is there anything that can be done?
Not wishing to end on a dull note I must express my pleasure at the high reliability of the PC and the very little trouble they have caused.
Yours sincerely
Paul Bryant.
Dear Bob,
At the last CTIG meeting we reviewed where we were with the various inputs we wanted to prepare for CCITT 88. One of these was the definition of changes and additions to X28 to make it easier to use which you offered to draft. I guess that like me you have little time for these activities but the meeting did ask me to see if you could produce something for the next meeting on 10 September. I fear that 1988 is a lot closer than we think for influencing the work.
I worry that our input from CCITT is well filtered before it gets to CCITT and similarly the feed back from BT is less than satisfactory which makes the work very tedious. None the less we have to try.
Best wishes
Paul Bryant.
Dear John,
Enclosed are tapes for IBM and DEC software which I hope you will find useful. Sue seems to have lost her installation guide and I have no idea how difficult it will be to mount it without the book. If you do have trouble then I guess I can get one. The PRIME one will be a week or so before I send it as the right man is on holiday.
Although I can give you no official support we will try and help you with any problems you have. To this end I have set you up a username on the VAX which is JH with password JH which you should use instead of PEB to avoid confusion.
I wish you luck.
I am developing an EARN/BITNET gateway which will run on our IBM and as I mentioned this will be available in a couple of months. It is crude and it is aimed at dealing with mail. I enclose a project spec which was for my management and has some irrelevancies in it but I think you should be able to get the drift. It is possible to gateway files now. On outgoing (coloured book to EARN) it is easy. All you do is to send a file to the IBM, it is sent to <file name> with user id being VNET <EARN address>. Thus if from our VAX you send the file to RLIB file XX XX and user id VNET CERNVM.PEB the file will end up on my IBM account on the CERN IBM machine. In the other direction it is more difficult as the RSCS address mechanism is not sophisticated and further information is needed. This is supplied by * FILE records at the head of the document which have the form :-
//* *FILE SITE=RLVE,USER=JH,PSWD='JH',DEV=FILE,FILE=JUNK
If this is sent over an RSCS link to us with RSCS address UKACRL JANET the *FILE record will be used to relay the document onwards through NIFTP and the above record would cause it to end up in your file store on the VAX. Not very elegant but usable.
Best wishes
Paul Bryant.
Members of Y/11 Y/12 are not experts on this subject and would value the advice of the character group to put into the functional standard.
May I ask
Those who have a rough idea of what EARN and JANET are and want to move data between the two networks should turn immediately to section 5 on how 'To Get Going'. Sections 2 through 4 give an introduction to the two networks. Section 6 through 13 contain further technical details which may be required in a few cases.
EARN (European Academic Research Network) is a computer network between academic institutions like universities or research centres for the purpose of world-wide communication. It consists of a set of independent host nodes connected by means of leased telecommunications lines in an open, un meshed topology. A central computer in each country provides international connectivity and some central services.
EARN is a 'store and forward network'. It utilizes the transmission techniques of the JES2/JES3 or RSCS subsystems of the IBM operating systems MVS and VM respectively. Emulations are available for several non-IBM systems such as SIEMENS BS2000/BS3000, DEC VAX VMS or UNIX, or CDC Cyber NOS.
The following functions are available:
EARN provides world- wide connections to:
In the remainder of this document any statements concerning EARN will also be true of BITNET and NORTHNET as the networks are technically a single network and differ only in their management.
The European scientific community gratefully acknowledges the support of IBM, supplying skilled technical staff and carrying the costs for international and some national PTT-lines as well as for the central node computers of the EARN backbone network for the duration of four years.
JANET (Joint Academic Network) is a computer network for the use of academic and research institutes in the UK. It has connections to virtually all such sites although in many cases these connections are to local area networks to which the various nodes are connected. There are gateways to the public X25 network, to ARPA and to EARN.
JANET is an X25 network and provides facilities for file transfer, mail, interactive services and job transfer although the services on any system depend on the particular machines and on the local management. The protocols used are the so called 'Coloured Book' ones. The network is expected to migrate to the use of ISO protocols over the next few years.
The UK has a single EARN node at the Rutherford Appleton Laboratory. This node is also connected to JANET. A gateway is provided between the two networks which allows the transfer of files and mail.
In JANET the file transfer facility is restricted to machines offering 'Blue Book' file transfer. In addition files may only be 'sent' to EARN nodes and may not be 'fetched'. The transfer of binary files is probably only meaningful if both the EARN node and JANET node are IBM or IBM compatible machines.
To transfer mail the EARN node must provide the Columbia mailer or compatible system and the JANET node must offer 'Grey Book' mail.
Message transfer from EARN is only possible to the Rutherford EARN node and is not possible to and from JANET nodes.
The Rutherford EARN node, in common with the other EARN backbone nodes, runs NETSERV which provides an EARN information service. The information files may be accessed with 'Blue Book' file transfer from JANET nodes. Those with accounts on the Rutherford IBM computer may access NETSERV interactively.
NOTE. Mail will not be available until Autumn 1985.
NOTE. The NETSERV information services will not be available until some minor developments have adapted them for use via JANET.
There are six possible functions. The minimum amount of information is given about each of the functions in the following subsections. This should satisfy the majority of requirements. Each section is self contained.
If there is doubt as to whether suitable facilities exist on some system then the local management should be consulted.
The Rutherford node runs under VM/CMS and the normal means of file transfer under RSCS apply.
The Rutherford node runs under VM/CMS and the normal means of message transfer apply.
The first record(s) of the file to be transferred must be:
//* *FILE SITE=<site name>,USER=<user id>,PSWD='<password>',DEV=FILE //* *FILE FILE=<file name>,KEEP=NO
The <site name> is either the JANET name for the JANET node or the explicit address of the site's FTP service (beginning with a DTE number).
The <user id> is normally the logging in identifier associated with the file store the file is to go to.
The <password> is normally the logging in password associated with the <user id>. In some cases, particularly IBM VM/CMS machines, this field may be omitted.
The <file name> is the name the file will be known as in the remote file store. If the remote system is VM/CMS, the file will be sent to the appropriate virtual machine reader, but a valid CMS fileid must still be supplied for it.
The file must be sent to the EARN node UKACRL and user JANET.
Once the transfer has passed through the gateway its success or otherwise will not be reported to the sender.
The JANET node must offer 'Blue Book' file transfer.
The file to be transferred must be sent to JANET node UK.AC.RL.IB with user id 'VNET <EARN address>'. The file name must be any valid CMS file name.
Examples for popular machines transferring a file named FRED to SID at EARN node DEARN are: (Note responses from the system are underlined)
For GEC computers running OS4000 and Rutherford communications software
TRANSFER SITE=RL.IB LOCALFILE=.FRED REMFILE='XX XX'
REMUSER='VNET DEARN.SID'
For PRIME computers running PRIMOS and Rutherford communications software
FTP FTP V8.5: Default parameters: No default site Local tree path = <your account> >SITE RL.IB >RTREE XX XX >SEND VNET DEARN.SID >Q
For VAX computers running VMS and UWIST communications software
$ TRANSFER %_input filename ? FRED.DAT %_output filename ? "RL.IB::XX XX" %_remote username ? "VNET DEARN.SID" %_remote username password ? $
For IBM computers running VM/CMS and Rutherford communications software but not the Rutherford machine for which use the CMS command SENDFILE or similar
FTP remote computer RL.IB local file FRED FILE remote file XX XX remote username VNET DEARN.SID remote password remote account options
The EARN node must be running the Columbia Mailer under VM/CMS or a similar compatible product and the JANET node must be running 'Grey Book' mail. The command is usually:
MAIL <recipient>@<JANET site>.AC.UK
Thus to send mail to Fred.Man on RL.GB the command is:
MAIL Fred@GB.RL.AC.UK
Note that for mail purposes the Rutherford IBM computer is a JANET node.
Note that the components of the name are ordered in opposite directions in the two networks.
The JANET node must be running 'Grey Book' mail and the EARN node should be running the Columbia Mailer although its absence will merely be an inconvenience to the receiver. The 'To:' field should contain:
<recipient>@EARN.<EARN site>
Thus to send mail to Fred on DEARN the 'To:' field should contain:
Fred@EARN.DEARN
Note that for mail purposes the Rutherford IBM computer is a JANET node.
Note that the components of the name are ordered in opposite directions in the two networks.
Unfortunately naming and addressing is a complex subject and is liable to leave the user confused even though the object is to provide a user friendly interface.
Addressing is fairly simple in that every accessible 'entity' has a network address. An 'entity' is some service accessible via a network such as a mail service and thus a particular computer may be several network entities. Each network has its own address scheme and gateways attempt to sort out how an entity on one network can be accessed from another. Unfortunately this often means that additional addressing information has to be supplied by the users to enable the gateways to operate. Even more unfortunately this may have to be provided in an inconvenient form, such as, within the data file being transferred.
Using addresses is inconvenient as these are often changed and are also not easy to remember. Thus entities are usually 'named'. Unfortunately the use of names is far from simple.
Each 'name administration' has named the entities in its 'domain' and possibly in other domains. Typically EARN, JANET and ARPA are name administrations who have set up schemes for naming. It is worth drawing a distinction between names used for file transfer and those used for mail although they look somewhat similar. In the case of file transfer names can only be used for moving files between entities in the same administration and if a file is to be sent to an entity on another one some fairly ad hoc schemes may have to be devised. In the case of mail the naming information is designed to go through gateways and thus can be made easier for the user. It is fortunate that the same mail system is used in EARN and JANET which allows the mail gateway to be fairly convenient.
A full list of EARN, BITNET and NETNORTH node names can be obtained from NETSERV. Details are not yet available. The names of entities within JANET are not known to EARN and thus names of JANET entities must be obtained from elsewhere. In addition, the EARN network cannot know whether a transfer to JANET will be successful but has to let the gateway take responsibility for this.
The names within the network are not hierarchical. A name is usually associated with a computer and the same name may be used regardless of the service being accessed.
In the case of MAIL names are hierarchical particularly if mail is passed through a gateway. In this case the top component of the name normally defines the gateway the mail is to go to and the remaining components identify the system within that network.
Names in the JANET network are registered with the Name Registration Scheme. Names are hierarchical. The top level is UK and the second level contains AC - meaning academic community. Site names are at the third level. Any structure below the third level is at the discretion of the site. The name components may have a 'standard form' or a 'short form'. The two forms are provided as a compromise between meaningful names and quick to type ones. In practice the standard form names have encountered problems with some systems with the structure of tables and size of files. In a number of cases sites have elected to have the standard form names identical to the short form. The components of a name are separated by '.'.
A typical long form name would be:-
UK.AC.RUTHERFORD.GEC-B
The corresponding short form would be:-
UK.AC.RL.GB
For use within JANET the UK.AC. may be omitted.
On any system only a selection of names may be available. Currently the names EARN or BITNET or UK.AC.RL.IB (which are synonymous) must be available or some alternative method of addressing the IBM computer at Rutherford. If there are difficulties the local site management should be consulted. Further names referring to domains that can be accessed via EARN will be provided later.
The Rutherford EARN to JANET gateway only has knowledge of a limited set of JANET names. The exact set will be available shortly. If names are absent the X25 DTE number or similar low level address may be used instead of the name. A number of names of mail services within EARN may be defined for convenience.
Advice on the availability of names may be sought from user support at Rutherford.
The system must provide 'P' end 'Blue Book' file transfer. The details of any particular system should be obtained from the local management.
The file transfer parameters should be set as follows:-
SITE (Mandatory) The site dependant alternatives are-
EARN
BITNET
NORTHNET
UK.AC.RL.IB
UK.AC.RUTHERFORD.IBM-B
RL.IB
RUTHERFORD.IBM-B
Note that the JANET X25 DTE number is 000000000002
FILENAME (Mandatory)
This may be any CMS file id consisting of a filename, a
filetype, and optionally a filemode although this is ignored.
The parts may be separated by space or '.'. The gateway makes
no use of this name.
USER ID (Mandatory)
VNET <EARN node>.<EARN user>
<EARN node> is the name of the EARN node which is a string
of 1 to 8 characters. <EARN user> is a user identifier on
the relevant node and is between 1 and 8 characters.
ACCESS MODE (Mandatory)
The access mode must be one of the following:-
Make only, Replace only, Append only, Make or Replace,
Make or Append. (These are all equivalent).
Take job input. (For delivery of 80 column punch format).
Take job output. (For delivery of printing format).
FILESIZE (Optional)
Files must be less than the 'filesize' if supplied. If no
filesize is given a file must be less than 8 M Bytes.
CODE (Optional)
EBCDIC, IA5 or BINARY are supported. BINARY is only meaningful
between IBM computers. The effect of BINARY is mostly to
ensure that no translations are carried out en route. The
default code used between IBM systems is EBCDIC to avoid
inconsistent conversion tables.
PFCONTROL (Optional)
ANSI paper-feed control should be specified for files destined
for a CMS file of filetype LISTING.
MAXIMUM RECORD SIZE
The maximum record size is 252 bytes. Files of arbitrary
record size can transferred between IBM systems by means of
DISK DUMP format.
BINARY WORD SIZE (Optional)
For the transfer of binary files the word size must be 8.
All other file transfer parameters are optional and are ignored.
Once a file has entered the gateway no further diagnostics or indications of success or failure are returned.
The RSCS protocol is unable to carry sufficient information within the protocol to satisfy the requirements of the 'Blue Book' file transfer protocol used within JANET. The additional information required has to be carried within the data using '*FILE' records. These can occur anywhere in the file but it strongly recommended that they should be in the first few records of the file, as their content may impose some restrictions on the transfer.
The file containing the '*FILE' records must be sent to RSCS node UKACRL and user JANET.
The format of the '*FILE' records is:-
//* *FILE <key>=<value>{,<key>=<value>}
The <key> <value> pairs from all the '*FILE' records provide the parameters to control the file transfer through JANET and they may occur in any order. The <key> is a keyword and the possible values are defined below:-
SITE The 'Yellow Book' internet address of the destination entity
within JANET. This will generally be a name such as RL.GB but
it could be an X25 DTE address with 'Yellow Book' sub-address
(normally .FTP).
USER This is the username on the remote entity if required.
PSWD The value is the username password on the remote entity if
required.
DEV The options available depend on the remote entity but normally
include:-
FILE - the file will go to the remote file store with access
mode 'replace or make'. Thus if the file already exists it
will be over written and if it does not it will be created.
LP - the file will be printed at the remote entity.
JOB - the file will be expected to be a job for execution at
the remote entity.
RDR - the file will be sent in printing format to a virtual
reader (IBM systems only).
No checks are made as to whether the file is suitable for the
purpose defined or whether the remote entity is a suitable
recipient. In most cases the transfer will be rejected by the
remote end if the transfer is not sensible.
FILE If the value of DEV is FILE the value is the name of the file
on the remote entity. This must be in a form suitable for the
remote entity. If the value of DEV is LP the value will
probably be used as a banner on the line printer output. If
DEV is JOB the value will probably be used to identify the job
on the remote entity. The exact effect will depend on the
destination system.
QUAL If a value for QUAL is supplied it will be sent in the 'device
qualifier' parameter. This parameter is only useful if the
remote entity attaches a specific meaning to it.
TRANSP If the value is 'NO' all control characters are translated to
nulls. If the value is 'YES', which is the default, no
translation takes place.
MAIL The value is a CMS userid on the Rutherford IBM system to
which file transfer logging information is sent. This is used
for testing and monitoring only.
CC For a file being sent as a print file (using Take Job Output)
CC=NO would cause the carriage control character at the
start of each line to be suppressed.
KEEP If the value is 'NO' all the '*FILE' records will be removed
from the file. Note that only the first adjacent set of
'*FILE' records will be recognized.
PSIZE If the value is 128 an X25 packet size of 128 will be
requested otherwise a packet size of 256 will be used. There
should be no need to use this facility which exists for
historical reasons.
DTYPE If the value is BINARY the fileyou to bring this to the attention
of your working group?
Yours sincerely
Paul Bryant.
Regretfully Peter Blanshard will be leaving at the end of September. Unfortunately a number of projects were dependent on his leadership and some reorganization is needed to ensure that the loss is minimized.
The principle areas are the supervision of the hardware group, the project will BT, the PRIAM work, dial up equipment, NRS, and ethernet work.
The proposed changes are:-
Graham Robinson will now supervise the hardware group and will continue to supervise the IBM PC work.
The project with British Telecom will be undertaken by Tim Kidd during his vacations.
Graham Robinson will look after the organizational aspects of the PRIAM project. An attempt will be made to recruit a suitable junior staff member to undertake the technical work of PRIAM.
Ethernet work is at a fairly low level and Gunadhi will look after it.
The responsibility for the dial up equipment will move to Operations Group.
Responsibility for NRS coordination will be decided later.
In order to release Graham from some of his current tasks with the IBM PC he will delegate some of them to the hardware group as appropriate.
I hope that this change will allow most activities to continue but perhaps at a slower rate. I am optimistic that with the high quality of the staff and particularly the current batch of students we can continue to make progress.
The proposed group structure is now:-
Paul Bryant (Group Leader, EARN liaison)
Peter Girard (Deputy Group Leader, IBM Coloured Book and ISO developments)
Tony Burraston (IBM RSCS, EARN gateway)
N Gunadhi (IBM Ethernet, Ethernet test equipment)
Graham Robinson (IBM PC, Workshop Supervision, PRIAM management)
Andy Jessett (Hardware development)
Peter Tomlinson (M6803/09 software)
Clive Lambourn (M6803 software)
Tim Kidd (Student, British Telecom project, training, software design work)
Adrian Robinson (ASO trainee, IBM PC)
Andrew Wilson (Student, IBM PC)
David Barham (Student, lecture theatre project)
Ned Jones (Student, M6803 software, 6803 hardware, Dragon)
Thierry Massart (IBM bursary, evaluation of EAN)
The Development group has 3 major activities:-
The IBM PC has become popular mainly as a result of the very large amount of software which is available for it. To allow advantage to be taken of the PC as conveniently as possible the group provides a service which includes:-
To aid this work the group has investigated a large number of software products and can demonstrate them to clients. In addition various PC 'look alike' machines have been evaluated as well as hardware additions from various sources. A number of software developments have been under taken mostly to provide utilities of common interest.
The development of products from manufacturers has been very rapid and it has not been wise to develop any applications packages as it would be difficult to match the quality of manufacturer supplied items and would demand a continuing maintenance activity. The one exception has been the development of code to allow the PC to emulate the 3270/CIFER.
A few presentations have been arranged for suppliers to demonstrate their wares. These have been popular and led to a number of orders. None the less the group provide services rather than actively attempting to advocate their use.
Currently the main activities are:-
The 'Coloured Book' communications products provide one of the main access routes to the IBM computers. There are many desirable enhancements still to be done and also a demand for better quality services. Some of the current major activities are the introduction of the Amdahl 4705 and the introduction of the Name Registration Scheme. Shortly Job Transfer and Manipulation Protocol will need to be provided to match developments elsewhere in the JANET network. In the future the migration of JANET to use ISO protocols will demand effort.
Rutherford will shortly provide a gateway between the European Academic Research Network (EARN) and JANET. This will provide cheap access from UK academic institutes to similar ones in Europe, the USA, and many other parts of the world. The group is developing this gateway and taking an active part in the administration of EARN. EARN is committed to migrating to use ISO protocols and the group expect to take an active part in this work which is closely associated with the migration activities of JANET.
High speed local area networks are still in an immature state and the group is engaged in small scale projects to provide special services and to maintain expertise. There are two principle projects. The first is to connect the IBM computer to the HEP VAX via an Ethernet to allow data from magnetic tapes on the IBM machine to be used by the 370/E processors on the VAX. The second project is to investigate Ethernet connections into IBM PCs and a number a products are being evaluated. An additional activity is investigating maintenance aspects of Ethernets and evaluating various monitoring tools.
The support of the RSCS communications is needed as there are many such connections needed to provide services to remote IBM equipment. In addition EARN uses these protocols.
An electronics workshop has recently been set up to undertake small projects mainly in the communications area. Current projects include a monitoring system for high speed communications lines and a system for allowing a teacher to interact with a class sitting at terminals. The group has a strong interest in hardware standards and projects in the future will attempt to use standards advocated by CERN in their PRIAM project. It is hopped to make available the PRIAM software on one of the computers with a view to making it available SERC wide and so encourage hardware standardization.
Dear Mr. Donn,
You have written to me at a time when I am busy helping some of your colleagues in New Zealand set up a network and so I can give you some information which may well be of help to you.
First let me give you a number of facts.
EARN, BITNET and NORTHNET are essentially the same network. This network is based on connecting together by leased lines a number of computers which exhibit the IBM RSCS, JES2 and JES3 protocol systems. The network is world wide with some 600 or more computers. The network is mainly in the USA where there are 400+ machines and in Europe where there are 100+ machines. There are now machines in the Middle East, Japan and I believe that machines will soon be added in Australia and New Zealand. Currently the network is part financed by IBM who pay for lines and some equipment particularly outside of the USA.
In Europe there are connections in most countries. Germany has many sites while in the UK we will only have a gateway to EARN located at the Rutherford Laboratory. We are taking this approach because the UK already has a sophisticated network in JANET and so we do not require or want an alternative one which would siphon resources from JANET.
The Rutherford gateway will provide File Transfer and Mail facilities to and from EARN. The gateway will not be perfect and there will be some loss in quality in passing through the gateway. For example it will not always be possible to determine whether mail has been delivered or not. In addition the RSCS messaging facilities will not be available.
BITNET has a number of gateways in particular to ARPA, CSNET, MAILNET and some other popular academic networks. It will therefore be possible to send mail to and from JANET to these networks. It is expected that there will be a number of gateways in Europe to various networks such as DFN and SUNET.
I have been in touch with John Houlker of University of Waikato, Private Bag, Hamilton, NZ. who in interested in setting up an academic network as we have in the UK. He is highly likely to adopt the protocol standards we have in the UK- namely the so called 'Coloured Book' ones. I have sent him a number of software products which he is mounting on VAX, PRIME and IBM computers in New Zealand. He will be connecting his computers to the public packet switched network in New Zealand which is now operational. In fact I have been conversing with him across the public networks for some time.
So some of the facts are:-
You will not be allowed to connect your IBM 4341 in Cambridge to EARN but you will be able to use EARN via the Rutherford gateway. All you will need to do is to connect it to JANET which, if you are in the academic community, you can do as of right. The code to do this can be supplied by Rutherford although some hardware at about 3000 pounds may be needed. I assume you are using VM/CMS, if not there may be problems.
I am not sure whether you were referring to your machine in New Zealand. If you were then it is likely that you will be able to connect to EARN. You may be encouraged to connect to the New Zealand packet switched network in which case it is highly likely that there will be gateway between it and EARN. In fact the gateway we are producing at Rutherford will be offered to John Houlker.
You ask about costs. This is a difficult question. In general, to join EARN all you require is a leased line to the nearest EARN node. If IBM is generous they may pay. This is unlikely as IBM usually only pay for the international nodes. The built in coupler on an IBM 43?? can be used but if this is already in use some equipment will have to be bought. In the case of connecting to the public network the costs are very different and it is not possible to say whether they are larger or smaller as the costs are traffic dependent. You will (currently) have to buy a so called 'Edinburgh Box' which can convert the IBM bi sync standard to the HDLC standard required by the public networks. This is less than 3000 pounds. You will have to pay an installation charge and a rental charge plus call charges. The exact figures can be obtained from the New Zealand PTT but the UK prices can be taken as a good guide.
Finally I will make you aware of the future of networking both in Europe and New Zealand. In Europe all countries academic communities are committed to moving towards the use of the ISO protocols. Indeed EARN itself is so committed and I am in charge of defining how this should happen. The change will take place in the next 3 years. In the UK we will also be moving to these protocols and a steering group is planning the change. New Zealand, if they adopt the current ' Coloured Book' protocols will have to migrate at the same time as we do. Incidentally the Irish are also using the same 'coloured Book' protocols and will also migrate with us.
I would recommend that you get in touch with John Houlker on your return to New Zealand as I am sure he will be happy to advise you on your best course of action.
I hope this has been of some use and I will be happy to answer any further questions you may have.
Yours sincerely
Paul Bryant.
I will first make a few statements which I believe are fact.
The GEC mail system is to the full Grey Book spec and can undertake jobs such as mail forwarding, real name to login id look ups, fuzzy matching, source routing, return of sensible error messages, distribution lists.
The Columbia mailer can do none of the above. It would be possible to enhance it to do these jobs but this is a major task with probably 6 to 12 months effort depending on the staff quality. In fact the tables the mailer works from are the list of CMS user ids, list of RSCS nodes and the list of JANET nodes. Thus if you sent BRYANT@RL to it there is currently no way in which it could sort it out. Thus it is very primitive. However it is better than what we have now which is nothing. Although is under constant development I do not think it is likely to develop as we would like. If we were to develop it ourselves then we may well end up with a product we had to maintain ourselves totally whereas we now depend on Columbia for support.
Grey Book mail has a limited life. This is put variously between 3 and 10 years. Thus any effort put into mail should take account of this.
X400 is expected to take over and we already have a version working on a VAX at RL and in December I hope to have a version on the IBM as part of the EARN migration project. As yet it is unknown what sort of directory facilities this has. The VAX X400 has primitive directory facilities. In fact you can only really address mail explicitly i.e you have to know the user id on the target VAX. The system does allow a 'nick name' like service so that the user can have a table of read names against mail names. No site wide service could be planned with either of these products at this early stage.
The reason these X400 systems do not have sophisticated directory services is that a directory service is defined that is separate from the mail system. It is in fact a distributed data base specifically for mail. This is now well defined. When we start to move seriously into the X400 world we will probably have to use this standard in order for us to access name servers on other sites and for them to access us. This is a rather different scheme to the Grey Book one we have here. In the X400 scheme you first find out where to send mail and then send it and in our scheme you first fire of the mail (say to Bryant@Rutherford) and let the mail worm its way through the system. It is interesting and important to debate whether both schemes should coexist in the future.
Now how does this effect what we do now? We should ensure that any data base holds information in a form which can satisfy the needs of the CCITT directory scheme. Thus if and when we turn to CCITT it is a question of defining new access methods on an existing suitable data base or extracting suitable tables from that data base (to my mind the route taken is a matter of expediency although you may have points of principle from the data base system). My point of principle is that it will have to obey CCITT directory protocol.
My gut feeling is that without extensive work on a new mailer on the IBM or considerable extensions to the Columbia one we have no option but to use the GEC mailer. I would add that the PRIME and VAX mailers are as pathetic as the IBM one. Thus the problem resolves in the short term to how the tables should be generated and how they should be updated.
Now let me turn to your text.
From page one I agree up to and including (g). The rest of that section is outside the scope of what RCCC requires but intuitively the ideas look sound.
Section 3 - Again outside the scope but in the wider world sensible.
Section 4 - Whilst the idea of a central data base is sound this should not preclude extracts of that data base being made for specific purposes on various machines. This should be how network traffic is reduced, not by locating the data base to minimize network traffic on the assumption that all requests have to go via one machine. For human look up of names response is important, for mail it is not since the look up will be done after the sender has finished with it and thus a delay of many seconds is not important- delays of minutes may be. While on performance one should also note that the performance of the data base is important. For certain human types of look up one wants sophisticated facilities (no doubt). For a automatic mail look up system the look ups are of a very specific type and thus systems can be developed to deal with such look ups far more efficiently. For example, the GEC name look up is very fast and takes no network resources whereas a general purpose system would use more machine cycles and if on another machine network time (assuming we had protocols to do remote look ups).
Section 5. last section -the GEC also allows fuzzy matching and alerts users if a name is not unique. I am not sure what the 'more detail is' that you require. Maybe it is in my opening comments.
Section 6. Yes- but the words are open to a multitude of interpretations. A statement such as that still begs the question that Grey Book and X400 require more addressing information than can be typed in in a command thus forcing the use of nick names. The statements also give no ideas on how we avoid different sets of mail interfaces for PROFS users and non PROFS users. However , this is no doubt an area where we just have to smile and accept the mess. I have yet to find out how they use the PROFS mail interface to drive X400 at Heidelberg- this may be THE solution.
Under section 7 the current Columbia mailer work is all RFC822 and goes no way towards ISO and also does not help the PROFS problem. What it does provide is a single mail system to satisfy the use of JANET and EARN. If the MIT mail interface is used it provides a single user interface to the two but this is not for PROFS users. We shall see what Heidelberg turn up shortly.
At the end of that section I comment again that the Columbia mailer has no way of using a name server without substantial work and thus the option of generating a suitable file for the GEC is the only viable solution I can see.
You give an example of the layout of the database. I attach the requirements from the CCITT recommendations. I strongly advise that you study this document to ensure your layout is compatible. This study should partly or totally answer your problems as to what X400 requires. For PROFS- X400 we again wait for Heidelberg. On point c I leave to your judgment.
On the user interface- again this is your area of expertise. On the applications interface I see no problem from mail point of view if the GEC system is used as it has all the sophistication it needs and all that is required is a suitable report generator to produce the tables and some way of FTPing them to the GEC. In fact no GEC work is needed it will all be data base and IBM stuff.
Most of the effort required is nothing to do with the RCCC mail requirement but everything to do with setting up a general purpose name base. The only mail item is c and i. The interface to PROFS is really a parochial PROFS problem and not a site wide mail problem and as such is the sort of work that has to be done on any machine to sort out local problems. Thus only a small part of the proposal is mail.
On personal. You are right that the vast majority of the work is data base and not my scene. I cannot see Tony Burraston being much help unless he is able to undertake the vast amount of work needed to tart up the mailer. (That goes against vanilla products!!!).
I hope this is helpful and I think we need another iteration bringing in the X400 issues and deciding whether we want to propose to tart up mailer.
This paper is the result of some theoretical calculation and some subsequent experiments to test the theory. It is not exhaustive but does throw up some interesting observations on the observed performances. The most surprising observation was the consistency of the measurements with very few bad observations.
The basis of the investigation is to calculate and to measure how long it takes to refresh a fairly full screen of information on 3270 and 3270 like devices and to compare the results.
The experiment was to measure how long it took between pressing the CLEAR key and the keyboard unlocking. The screen selected was the first HELP screen on XEDIT which is moderately complicated and, perhaps, involving an above average size data transfer for an interaction.
There are four routes considered. First, via the network. Second, via a 3270 connected via a coaxial cable. Third, via a 3270 connected via a bi-sync line. Fourth, via a direct connection to the 1270.
The first task is to calculate the amount of data passing across links. In the X25 case this is easy as there is sufficient knowledge to calculate this accurately. In the case of the IBM equipment some assumptions have been made which may be inaccurate.
It is assumed that the terminal is connected to a PAD at 300, 1200, 2400, 4800 or 9600 BPS. The PAD is connected to a switch at 9600 BPS. The switch is connected to the IBM at 48000 BPS using bi-sync.
The data between the terminal and IBM is:-
CLEAR order to IBM 5 bytes Data from IBM 1541 bytes = 6 full packets of 254 bytes + 17 bytes Total traffic 1546 bytes
Between the terminal and PAD each byte is 8 data bits and one stop bit the traffic is 13914 bits or 15460 bits at 300 BPS as at that speed there are 2 stop bits.
The minimum times to refresh the screen are:-
9600 BPS 1.45 Sec 4800 BPS 2.90 Sec 2400 BPS 5.80 Sec 1200 BPS 11.60 Sec 300 BPS 51.53 Sec
The X25 data passing between the switch and the PAD is:-
Clear order to IBM 10 bytes Data from IBM 1611 bytes = 6 full packets of 259 bytes + 22 bytes Total 1621 bytes = 12968 bits
The minimum times to refresh the screen are:-
9600 BPS 1.35 Sec 4800 BPS 2.70 Sec
The data between the IBM and the switch which is bi sync is:-
CLEAR order to IBM 15 bytes Data to terminal 1611 bytes = 6 full packets of 264 bytes + 27 bytes Handshake 74 bytes = 9 handshakes Bi sync overhead 63 bytes = average of 3.5 bytes per packet Total 1772 bytes
The minimum times to refresh the screen are:-
48000 BPS 0.30 Sec 9600 BPS 1.47 Sec 4800 BPS 2.95 Sec
The X25 window between the PAD and IBM is 4 and thus 4 packets can be transmitted before an acknowledgment is demanded. It is likely that at least one acknowledgment packet will be needed which is 5 bytes between the PAD and switch and 10 between the IBM and switch. This overhead has not been included and makes the figures slightly optimistic.
The minimum figures via a directly connected terminal (via PACX) only depend on the speed of the connection from the terminal and at 4800 BPS is 2.90 Sec.
The data over X25 is optimized whereas the data to a 3270 is not. The number of bytes needed to refresh the screen is 1883 or 15064 bits. The relatively poor optimization improvement in the number of bytes transferred is because the data on the frame being used is fairly random and also fairly full.
The optimization of the data should not be confused with the optimization in the X25 case which 'remembers' the content of the screen and only transmits changes.
The directly connected 3270 operates via a 3274-1A which transfers data at 100,000 BPS. Thus the refresh has a minimum time of .15 Sec.
Assuming that the 3270 connected via a 9600 BPS bi-sync line the refresh has a minimum of 1.57 Sec.
These two calculation are suspect since the exact nature of the data stream over a coaxial cable is not known and the bi-sync connection has some additional overheads which have not been analyzed. None the less the figures are only likely to be slightly optimistic.
In all cases there is a processing time in the computer. This is assumed to be negligible although on rare occasions it becomes large at a couple of seconds or so probably due to the job being swapped out.
Experiments were carried out at various times of day over the 17 and 18 April apart from the 3270 over a bi sync line which was taken in July. Care was taken to ensure that some sets of measurements were well before 8.30 am to ascertain a best performance whilst others were taken at fairly random times. At each route and speed 10 measurements were taken to see if there was much variability over a short time span. The measurements were taken by stop watch which makes then liable to errors of .1 Sec or so.
The first result was the remarkable consistency in the timings. There were no observations of contestant bad performance except in the case of a connection via a PRIME. The conclusion to be drawn is ether that performance via most routes is contestant and that observed bad performance is due to lack of computing resources in the IBM (avoided in this experiment) or that the experiment was 'lucky' and avoided periods of bad performance or the routs used happened to be ones not normally congested.
The second result shows that the PADs and GECs have predictable and comparable performances. The PRIME has an erratic performance, this is not surprising due to the structure of the PRIME software.
The fourth result is surprising and worrying. It seems that the Cifer cannot cope with a speed of 4800 BPS. It overcomes this problem by buffering input from the line. The observable result is that the Cifer appears to operate at 2400 BPS. Unfortunately it is not possible to operate the full screen Cifer at other than 4800 BPS to investigate the phenomena fully.
The best times on an IBM 3270 were of the order of 0.2 Secs which confirms that the computer processing time can be ignored.
The best times for an IBM PC with a 3270 IRMA board on a coaxial cable was 1.2 Secs. This confirms some commentators observation that the IRMA board is slow and adds something like a second to the time to display a full frame. Casual observation of IBM PCs using other boards suggest that performance is similar. One could conjecture that the processing overheads on an IBM PC for a frame of data is of the order of a second.
Most experiments were with an IBM PC connected to RLCM connected to PSE1 at 19200 BPS connected to RLIB at 48000 BPS. In this case the dominant time is between the terminal and PAD. The results were:-
Speed Best Time Average Time Worst Time Theoretical Best 9600 2.6 2.6 2.8 1.45 4800 3.9 4.1 4.4 2.90 2400 7.1 7.2 9.4 5.80 1200 13.7 13.9 15.9 11.60 300 52.0 52.4 52.9 51.52 All the figures apart from the 4800 are on a small sample.
The observation is that the various delays in the network and in the PC are causing about a 1 Sec delay. However the performance was quite contestant with occasional long delays (1 in 50) which may have been network congestion or the effect of the job being swapped out. This indicates that under favorable conditions an optimum performance is possible. It is tempting to suggest that as the processing overhead with an IRMA board is a second then the observed depredation above optimal of a second is due to the PC and not the network.
The second analysis is operating at 4800 BPS via various routes to examine the effect of different speed X25 connections and different PADs. These were all carried out using the IBM PC.
Route X25 Speed Best Time Average Time Worst Time RLCM 19200 3.9 4.1 4.4 RLCA 9600 4.0 4.4 10.2 RLGB 19200 4.0 4.3 5.5 PLPA 9600 5.3 5.7 5.9 PACX 4800 3.7 4.0 4.4
RLCA is connected to PACX and so is heavily used which may be the reason for a number of isolated long responses which are probably due to contention between full screen Cifer use. There was only a marginal improvement with a direct connection between a terminal and the IBM. This leads to the suggestion that the degradation of a second may be due to overheads in the PC rather than network overheads.
The third analysis is between the full screen Cifer and the IBM PC both using RLCA at 4800 BPS.
Machine Best Time Average Time Worst Time Theoretical Best IBM PC 3.9 4.1 4.4 2.90 Cifer 7.7 7.9 9.5 2.90
The figures show the poor observed response of the Cifer and suggests that it is pointless to operate them on lines greater than 2400 BPS. This is not strictly true as it may be that the transmission of data from the Cifer is not limited in the same way. It should also be pointed out that the measurements were in a very specific situation which may or may not be typical.
The fourth analysis is for a 3270 connected via a 9600 bps bi sync line. There was only one 3270 connected via the line and thus line contention was excluded.
Best time Average time Worst time Theoretical Best 1.63 2.15 4.25 1.57
These test were carried out when the IBM was moderately loaded which explains the rather high average time. The worst time was an isolated measurement and tends to suggest that abnormally long response times are a feature of the IBM rather than the connection method of the terminal.
The experiment was principally conducted to examine the performance of a terminal connected at 4800 BPS over the X25 network. The other measurements were to provide supporting evidence and were not exhaustive.
The small sample of evidence only uncovered fairly rare examples of poor performance and these were restricted to isolated events rather than protracted periods.
As far as the network is concerned there seemed to be adequate band width and it is difficult to see that any major improvements would improve performance which seems to be near optimal over the routes tested.
A cause for concern is the poor performance of the Cifer itself. If this could be improved to take advantage of the 4800 provided or even 9600 then performance should be much better and may then indicate that a better network band width would be desirable.
The measurements of on a 3270 connected via a 9.6K bi-sync line performed very much as calculated. The measurements were on a single terminal on a multiplexer and so avoided any contention.
The most interesting comparison is between the full ASYNC/3270 and a 3270 on a bi sync line. The experiments showed that from the network point of view it is possible to provide a performance which on a worst case of a full screen refresh of 2.6 seconds for the ASYNC/3270 and 1.8 Secs for the 3270. This assumes a 9.6 connection for ASYNC/3270 and ignores the performance problem of the Cifer itself. As this result was obtained using an IBM PC it cannot be ruled out that the performance of the PC has run out and that the network may be better than indicated. A further aspect not taken into account is that the data passed across the X25 network is optimized in that the IBM remembers the contents of the screen and only refreshes parts that require changing which can have a beneficial effect with some applications.
Dear Dr. Boswell,
Your letter arrives at a time when I am in discussions with a number of your colleges in New Zealand and I can therefore give you some useful information.
First on EARN. I thought, and I may be wrong, that IBM would be paying for the international lines for EARN in which case you would only have to find the cost of a line to the New Zealand international node. Where this node is I know not.
In Europe EARN is well established but due to pressure from the European PTTs we are under heavy pressure to migrate to the use of ISO protocols in the next few years. We intend to do this by adopting some work being done at the IBM Heidelberg Scientific Centre. This will initially provide the X400 mail protocols and later the other ISO offerings such as FTAM and JTP. We hope to start preliminary experiments in December.
There was an important meeting a few months ago at which I was part of the secretariat which attempted to define what Europe should do about net working and we have come up with some important statements. Roughly these say that we all migrate to ISO in the next few years. I enclose a copy of the minutes of this meeting for your information.
In the UK we have a national network called JANET which used semi ISO protocols in that it is based on X25 but uses the so called 'Coloured Book' protocols. Thus we are providing a gateway between JANET and EARN to be built here at the Rutherford Laboratory. This is almost complete. We took this approach to prevent two competing networks growing in the UK.
Ireland is also adopting our Coloured Book products as have many isolated sites world wide. These include many High Energy Physics sites and some astronomy centres - including the Anglo Australian Telescope.
Some time ago I was approached by John Houlker of University of Wailato, Hamilton, New Zealand. He is involved with the provision of networking in New Zealand and is investigating the use of the Coloured Books in your country. I have sent him code for Prime, VAX and IBM VM/CMS which he is now assessing. You may well like to talk to him.
Some time ago Frank March from the Department of Scientific and Industrial Research was with us for a few months and also has a good grip of what we are doing in the UK.
There is not really a lot of useful paper coming out of EARN. It has very limited services as it offers only mail and file transfer. The protocols are fairly static. Most of the effort is in management- that is, trying to keep the think running nicely. However I am enclosing a copy of our proposal for the migration of EARN and I will put you on the list for the minutes of the EARN technical meeting which takes place in France next month.
I will be most happy to meet you when you come by in November.
I hope this will be useful.
Yours sincerely
Paul Bryant.