Paul Bryant's Networking Correspondence
These are some first thoughts on the resignation of Gunadhi.
I believe there will be no effect on the local area network installation program since this is well under way and is 'off the shelf'. The setting up of the bridges can be done by Mike Walters and is easy.
Our expertise in Pink Book will sadly be reduced.
The Auscom is the principle cause for concern. Currently it is stated to be stable. The exact meaning of 'stable' is unclear since it has not received heavy traffic.
The options open to us appear to be:
My feeling is that I would not like to recruit another PDP11 expert as there is no one to train him, he will not be part of a team, and we will remain vulnerable to his departure. I am attracted by the idea of further building the VAX team but the magnitude of the task worries me.
The active sites involved with the evaluation are:-
Heidi Berghoff RUNIT Olivier Martin CERN Gerard Pitteloud Zurich Hans Goossens Nejmegan
The project has reached the stage where the system has proved to be good. It interworks with other implementations, it is reasonably fault free. It is not worth proceeding with any further work and the project should now be regarded as complete.
The system has been developed to operate over the IBM OSI products by Heidelberg. Evaluation of this system is not in the agreement with IBM and no work has been attempted. Unfortunately it was not clear that a new arrangement would be needed and negotiations are only now starting to examine the possibilities.
If the system is to be used more widely then it will have to operate over the IBM ISO products since it is unlikely that sites will want to install Series/1 front ends when their 37xx equipment will be supplying their other X.25 services.
The RFC822 to X.400 gateway code is not available from Heidelberg and such a system will be available from the Softec/DFN project.
The Heidelberg system should only be studied further if we can arrange to have access to the system using the IBM ISO products and if IBM indicate that we can use it for service purposes with EARN.
An additional consideration is the expected X.400 product from IBM. If this materialises at an early date then it may be appropriate to wait for it rather than use a semi-supported system from Heidelberg. This presupposes that this product will be suitable for EARN - for example, it it is bundles with PROFS it may not be suitable.
In summary - I am now talking to Heidelberg about the use of X.400 over the IBM ISO products and about its wider use within EARN. I do not believe we should support the wider use of the current system because of the requirement for a Series/1 front end.
Please would you resister the following partial domains in MAIL context and NRS destination UK.AC.RL.EARN, these are domains known in EARN for which we are prepared to accept traffic
BE Belgium CA Some sites in California CSNET Computer Science net in the USA DFN A gateway in Germany GUELPH FI A gateway in Finland HEPNET High energy physics network in the USA IL EARN in Israel INFNET A gateway in Italy MLNET A gateway in USA NET A gateway in USA NETNORTH Canadian part of EARN NL EARN in Holland IT EARN in Italy UCHICAGO A gateway in USA AUT UNINETT UTORONTO A gateway in Canada SE A gateway to UUCP in Sweden UUCP A gateway to UUCP UWO WATERLOO A gateway in Canada WESLYN A gateway in USA WUSTL A gateway in USA
I would also have liked to register the following which are accessible from EARN but others have claimed them
ARPA CDN CHUNET COM DE EDU We have 20 gateways! GOV FR IRL MIL ORG US
I would also like to register the following NRS names both ways
UK.AC.EARN-RELAY context MAIL 000000000002.FTPR.MAIL UK.AC.BITNET-RELAY context MAIL 000000000002.FTPR.MAIL
in both cases the long form is the same as the short.
I understand from Roland that these have to be registered via you. If this is not the case please let me know the procedures.
It gives me some concern that some partial domains of interest to the EARN gateway and ARPA gateway cannot be registered to point to either gateway (I understand the problem!) and that it seems that the first gateway to try and register it is given it. There must be a better way.
Please let me know if there are any problems.
Paul.
In a number of places in X.3, X.28, and X.29 CCITT declare that some 'networks' may operate in some specific way. This is particularly prevalent in changes proposed for the 1988 revision. For example, see X.28 end of section 4.6. These texts refer to some feature of PADs.
In X.28 (1988) 3.2.2.1.2 we see a feature which may not be supported by all 'PADs'. Should this be 'networks'?
The use of the term 'networks' in these circumstances seems anomalous as a network may contain a number of PADs with different characteristics and such a situation would not be allowed by the recommendations.
Temporary document 287 used the digits represented by 16, 32, and 64 in parameter 6 to define whether the PAD is in extended mode and if so which language the various signals are in.
This scheme suffers the weakness that some current packet mode DTEs are in the habit of setting parameter 6 and may thus defeat any action by the operator to enter and remain in extended mode.
Contribution RGIH-1929-3415 proposes that the packet mode DTE should only be able to alter these bits if one or more is set to one and the bit represented by 8 is set to 1. Whilst this proposal overcomes the problem it sets a new precedent of having parameters which may be altered in rather complex ways which would seem undesirable. It should be added that the 'LANGUAGE' command also introduces the new concept of X.28 command signals which operate on part of a parameter.
There appear to be two other options which do not suffer this draw back.
Option one. This to introduce a new parameter whose only purpose is to define the language used. When the UK introduced the idea of using parameter 6 this was only done because of the natural reluctance to introduce new parameters and without considering the full consequences.
Option two. This is to use a 'hidden' parameter for indicating the language, that is one that the packet mode DTE cannot observe or change. There is a case for arguing that the packet mode DTE should never need to modify the language used or whether the PAD is in 'extended mode' this being a choice of the operator. On the other hand it could be argued that a packet mode DTE may wish to interrogate the parameter and as a result provide some service in a compatible language. This scheme would set a new precedent in that currently there are no such hidden parameters.
On balance CTIG is in favour of the second option.
Comment by Paul Bryant. Although this is what we decided, on reflection I prefer option one as this removes the precedent of having hidden parameters.
It is proposed that the meeting report is circulated to the participants for comment and is then circulated freely after any amendments.
The section on future actions requires agreement of the Executive and little can be done before the funding issue is resolved. I do not believe we are justified in asking our experts to invest any further effort into the transition until we can see that there are good expectations of an implementation.
I would like to invite the Executive to comment and then decide on any relevant actions.
The document was neither accepted or rejected. Although there was much comment, this tended to be questions and suggestions for further study rather than definite recommendations. Thus there is insufficient additional material or changes to warrant a further edition at this time. There was nothing said that suggested that the broad lines of the proposal were not correct. As the first stage of the migration is concerned with X.25 infrastructure and NJE over X.25 this area received much more attention and this could go ahead before the full details of other aspects of the proposal are refined.
The 'square' infrastructure was accepted but it appears that it would be better if it were RAL-CERN-Montpellier-Copenhagen-RAL. The Netherlands member suggested that that country would be a suitable switch site as an alternative to RAL. At first it was suggested that traffic studies were needed to select the switch sites and the rest of the topology. This was thought unnecessary if 64K lines were provided for the square. It may be that we could proceed on the use of 9.6 or 14.4K lines on an interim basis as acquiring 64K lines could cause a long delay. There was a view that when the infrastructure was in place the traffic figures would change due to new protocols and new users which would render any detailed figures collected now to be wildly inaccurate. Thus the current figures and educated guesses could be sufficient. None the less further figures would be welcome but the e meeting did not suggest how these could be collected. This should be considered at the Technical Meeting.
There was a suggestion that EARN should wait for the COSINE infrastructure to be set up rather than sets its own up. It was also suggested that EARN should ask the various PTTs whether they would like to run all or parts of the network assuming the tariff was acceptable. The counter view was that details of the COSINE plans were insufficient to give confidence that this was a viable option at this time. There was some scepticism that the PTTs would be able to meet the EARN requirement but none the less this should be explored.
It was also suggested that EARN together with RARE should approach CEPT and only set up their own network as a last resort but this should not delay work as the negotiations may not succeed.
EARN should take part in RARE working group 4.
The effort needed to set up and run the infrastructure was thought to be too low. It was suggested that a full time financed co-ordinator for transition should be appointed.
Mechanisms should be set up to use the PTT X.25 links in the event of failure between a country and a switch. The 'square' infrastructure was thought resilient enough to need no back up. A way of financing such PTT connections was needed. It may well be that such connections should be restricted to certain types of low volume traffic. Further study in indicated.
There was concern that the popularity of connections to Montpellier made that site very critical (not only in an X.25 scenario) from the point of view of failure and performance. The various gateways to EARN that exist and may appear should be in different places to decrease the dependence on Montpellier.
It was recommended that a 'request for proposals' is undertaken to select the switch supplier. There was a suggestion that switches could come from several manufacturers or that the infrastructure should be lines between national X.25 networks but this did not gain support. The Cosine network management group should be followed.
The meeting rejected NJE/DECNET/X.25 on several grounds. First expense. Second further complexity. Thirdly the international sites did not have the expertise. Fourthly there would be a higher level of disruption.
NJE/?/X.25 was rejected as there were only experimental versions and there was doubt that a suitable product(s) could be developed to a suitable level of performance in the time scale. This was thought to be an optimal solution.
Thus NJE/SNA/X.25 was recommended. It was suggested that NJE/SNA/SDLC could be used on lines prior to moving to X.25 but this would be for tactical reasons. The use of SNI for the required SNA addressing was recommended.
It was questioned why the HEP scheme was not adopted. The use of the lower 11 digits was questioned but no other scheme was put forth except the HEP one. It was suggested that a decision should not be made before the result of the ECFA SG5 meeting were known. (Note- SG5 was given a verbal presentation of the HEP scheme for information and no decisions were made). One must assume there was no objections. It should be added that the two schemes are not incompatible as the EARN scheme for the 11 lower digits is only a recommendation.
It was recommended that X.400 (1984) should be used. They was no support for the use of part of the user agent across RSCS as allowed by the Heidelberg system. There was a strong call for EARN to participate in the RARE X.400 activity. EARN should set up a permanent working group to liaise with WG1. There should be co-ordination at the country level.
Pilot X.400 sites should be set up to include the international and other sites. These pilots should use any appropriate systems such as Heidelberg, EAN and so on.
It was suggested that EARN should only support the use of NJE and ISO protocols. EARN should leave any relays and gateways to these protocols to national components. The use of other protocols would be allowed but not supported.
The Nordic countries may wish to use NJE/DECNET/X.25 within their countries.
There were some worries that the use of these protocols could overload the network.
No comments were made due to lack of time.
Actions leading to the establishment of the infrastructure are shown below. Little can be done until the funding situation is resolved unless we expect the support of the infrastructure to be on a voluntary basis. The Executive is asked to comment.
2.1 Seek funding for:
Switches estimate 40000 UKL
Lines (only Rutherford/Copenhagen needed initially)
Manpower 6 man months installation, 1.75 man years recurrent.
Transition co-ordinator 1 man year.
2.2 Select switch sites and network management centre. Considering the initial square infrastructure is agreed and the suggested sites are Rutherford, Copenhagen, CERN, and Montpellier the question is whether any other sites would like to replace one of the four. It is suggested that the Board of Directors should be asked for further bids to become an initial switch site. This would not preclude sites having switches at a later date. Bids should be invited to become the network control centre. The estimate is that a switch will take 1/4 man year and the task will be correction of line faults, correction of switch faults, line reconfiguration, and liaison with the management centre. The management centre will require an additional 3/4 man year and will re-configure switches, collection of statistics, fault monitoring, and reporting to the Executive. This assumes that the network does not grow to encompass national parts of EARN. It is assumed that EARN will fund this manpower.
2.3 Issue a 'request for proposals' to switch manufacturers for 4 switches based on current specification which should result in a short list of suppliers. A subsequent 'request to tender' will be issued when funds become available. Orders will then be placed.
2.5 Order lines (RAL-Copenhagen). This deals only with the square infrastructure and that some current changes are accomplished. It assumes that initially the infrastructure is based on 9.6 or 14.4K lines. 64K lines will be the subject of a further request for funds. This will be done when the delivery date of switches is known and funds are available.
2.6 Set up management centre and install switches.
2.7 Set up NJE connections.
2.8 Open negotiations for wider use of X.400 from Heidelberg using the 37xx equipment.
The EARN Executive is asked to approve the date and place of the next EARN Technical Group meeting and the agenda. Unfortunately we did not have time to debate the content of the meeting so I have added comments where I require advice.
Proposed date 30 November 1 December.
Proposed location Lisbon
Proposed agenda:-
1. Election of secretary.
[Unfortunately due to staff loss I am unable to bring one of my staff to take the minutes. There has been much reluctance to undertake this task at previous meetings. The options are :- take no minutes, attempt to get someone to volunteer (who?), or the administration to minute. Please advise]
2. Proposal for support of EARN after IBM support ceases.
The non exclusive options are:-
Option 1. EARN to finance a post to undertake the current duties. This post may also undertake further duties concerned with migration.
Option 2. EARN to finance support activities at several locations.
Option 3. EARN to contract support to a commercial organisation.
Option 4. EARN to seeks voluntary effort at one or more sites.
Option 5. EARN to attempt to share tasks with BITNET.
The Technical Group is asked to advise.
[A paper is required to define the current duties undertaken by IBM and others with a view to determining where duties should be located. Berthol Pashe is a candidate for producing it]
[The Executive is asked to advise whether there is a possibility of financing EARN support - if not then these options should not be included. However, considering the substantial amount of effort involved and the difficulty in getting some work undertaken by voluntary effort I do not rate the chances of voluntary effort doing the tasks very highly. If finance is available then I would envisage asking for bids from sites.]
3. Topology.
The current topology is shown in .. and the Executive has proposed changes which will result in the topology shown in ..
The Technical Group is asked to comment and to suggest desirable topological developments.
[From the discussions at the executive it appears that relocation of lines is as a result of tariffs and the views of specific countries. To some extent this is caused by the lack of any statistics. I suspect that the Technical Group will merely call for statistics. Should this item be on the agenda? Please advise.]
4. Discipline.
In the past EARN has had little success in encouraging sites to co-operate fully in the activities of EARN.
The Technical Group is invited to suggest ways in which sites can be encouraged to follow EARN Executive and Technical Group decisions.
5. Proposal for domain addressing.
Domain addressing for mail is an aid to migration. The current situation is somewhat chaotic with entries in the DOMAIN NAMES file being entered as requested by sites. It is proposed to attempt to bring order by defining a scheme for domain mail names in EARN.
Option 1. Do nothing.
Option 2. Enter the ISO two character country codes into 'DOMAIN NAMES'. Insist on one machine in each country being able to deal with the country's domain. Countries will be able to enter further domain entries starting with their country codes. European entries in 'DOMAIN TABLE' will be policed to be in line with the two character codes.
Option 3. As option 2 with relaxation on country codes.
Option 4. As option 2 or 3 without policing.
The Technical Group is asked to advise.
[A paper is required. Who would be best to write it?]
[Perhaps it is premature to propose such a scheme. Please advise]
6. Proposal for control over file sizes.
The proposal is to insist that international nodes restrict file sizes transmitted to other countries to ...K. Files will be transmitted in priority order. Nodes will be required to install relevant changes...
The Technical Group is asked to endorse.
[A paper is required to define the technical options. I suggest that Eric Thomas may be the best co-ordinator for such a paper].
7. Proposal for the collection of statistics.
International nodes will be required to install .....
The Technical Group is asked to endorse.
[A paper is required. Perhaps Marco Sommani is the best author]
8. Proposal for future of Technical Group Future.
The current group meets infrequently and is rather large for making rapid decisions.
The proposal is to set up a 5 man Technical Executive which will meet 4 times a year and take technical decisions within the technical policy laid down by the a full Technical meeting which will be held once a year. Meetings of the Technical Executive will be funded.
It is expected that the decisions of the Technical executive will be followed by sites.
The Technical Group is invited to comment. If the proposal is accepted then nominations for the group which must be endorsed by the Board Member of the nominee will be welcome and the the EARN Executive will select the Technical Executive.
[The current Technical group is too large and a lot of time is spent in education. It meets infrequently. It is difficult to get decisions. It is difficult to get sites to take any notice of decisions. Is this a better scheme? Is there funding for this activity?]
I was unclear from the executive meeting as to the exact topology changes. Could we please have a statement from the administration so that we can approve it and act on it?
May I remind you that the UK request for a connection to Montpellier was not considered. Could you add it to the agenda for the next meeting.
The magazine Nature has asked to join EARN. I have studied the regulations for associate membership and find that they do not fall into any of the four categories. They are part of a profit making publishing organisation and they are clearly not
a) Independent non-profit making research organisation
b) Research unit within a non-Governmental organisation
c) National, International or Governmental agency....
d) Research centre of commercial organisation.....
Do they fall into any of these categories? If not should we amend the regulations to embrace organisations of this sort? I seem to remember that associate members were allowed to communicate with specific full members and not full members in general (am I right?). If I am right then we are in a difficult position as they wish to communicate with people on any site who happen to be commenting on articles for them. I suspect that they may well wish to communicate with associate members where there happens to be people who are commenting on material for Nature. Does this also need an amendment to the rules if we wish to accept Nature as an associate member?
The responsibilities of an EARN member.
This section claims that the only cost to an EARN member is the cost of the leased line.... This would suggest that the international sites are not able to reflect the cost of the expensive international line and of the French connection to America to other sites in the country. This would appear to be unfair to the international sites and in any case some countries are reflecting these costs to the members. Does the brochure need changing here?
I was unable to stay for the discussion on the 'strategic objectives of EARN.
Structure and Organisation. I fully agree that the funding model for 1989 should be developed as a matter of urgency considering the time it took to produce and agree the 1988 one. We considered collecting money centrally. I believe we should develop this concept. With X.25 it will become appropriate to collect funds to support the expensive 64K lines, the switches and the management of the infrastructure. These costs can then be distributed according to a formula to countries. It should be debated whether this should also extend to the other international lines. I would envisage that a percentage should be added for management and technical support of EARN (and subtract funds from sponsors). I believe we should have an initial draft for the next executive.
I agree that EARN has concentrated on funding for the political arm of EARN. We have to consider how we fund the technical support after IBM withdraw and this is urgent and the technical group will be unable to progress until the funding is sorted out. It does not seem fair that UK is supporting 1/2 a man (me) to develop migration and run technical meetings (others also contribute significantly to the detriment of their organisations.)
I believe that EARN should principally be concerned with Europe. We already have a lot of problems. If we add further countries from distant places then our problems multiple. For example, Africa does not have to contend with CEPT, RARE, and the CEC. I prefer the model of other areas of the world setting up EARN like organisations. We should give such organisations as much help and encouragement as possible.
I fully agree that we need more participation by institutes in EARN. I am not so sure that we should have targets for membership although we must ensure that membership is available if required. We must be careful not to tread on the sensitivities of countries. For example, a recruiting campaign in the UK would be counter productive.
I worry over associate membership as we could be accused of taking revenue from the PTTs. It is likely with 1000 associate members we will have some commercial traffic which could cause us problems. I have always considered associate membership as an exception to be used where there was a proven need for communication for a specific project. This needs debate.
It would be nice if someone could build a computer model of the network both in its current and projected form which could help to solve topology issues. The current network encourages countries to attempt changes to their particular benefit (UK Montpellier) which may not be to the common good. An X.25 network will be far easier to control and develop as the infrastructure will have to be centrally managed.
Complete backbone by end of 1989. I hope so.
I do not really understand this section. Interactive services are the only one missing. I agree that capacity should be increased.
Good thinking.
I would aim this at making EARN acceptable to everyone. (Difficult). Whilst we may well be an important European networking organisation it would be counterproductive to see this as some sort of competition with, say, RARE, JANET, DFN, SPAN etc. We must be seen as utterly co-operative. In fact EARN has a lot of shortcomings such as poor protocols, poor control over members (see arguments on file sizes and difficulties over statistics collection), little finance.
Dear Dr. Maddox,
Thank you for your recent enquiry. I attach some information concerning the EARN network.
I am sorry that I have not contacted you before. This has not been lack of action but because your request has raised some issues which have been difficult to resolve. However, progress has been made and I think we can see a way to meet your requirements.
I have approached the UK Joint Network Team with a view to securing your access to EARN via the national academic network JANET. After a long and detailed discussion the view taken was that your proposed activities were commercial in that the ability to contact various parties via the academic network was to your commercial advantage. It was also felt that Nature was a profit making publication in contrast to the learned journals such as the Proceedings of the IEE again indicating your use would be commercial. Thus, the option of using JANET as an access mechanism is closed.
At a meeting of the EARN Executive I had a long discussion on your case with the President, Dr. Dennis Jennings. Whilst appreciating the JANET view he approached the matter from the another aspect claiming that the use of EARN by Nature would be beneficial to the academic community. The result is that we can proceed to examine ways in which you can connect directly to EARN. I have to add that your application will still have to go through the EARN membership committee.
There are two ways in which you could use EARN.
The first option is for Rutherford Laboratory to allow you to use their computers. This would involve you in computer charges which would be a registration of 200 UKL plus usage charges which would be of the order of 1000 UKL per year. You would access us via dial up at 300, 1200/75, 1200, or 2400 bits per second or via dial up and PSS. In both cases you would attract the normal BT charges. You would need an appropriate modem costing between 100 UKL and 600 UKL depending on speed. You would need appropriate terminal equipment and your proposed PCs would be ideal. We would be prepared to supply you with software free of charge although you may well already have suitable software. Since you would not be operating an EARN node you would not be entitles to be an EARN member and thus all that is required is for you to assure me that you were not going to use EARN for commercial purposes. Knowing the nature of your activity I would clear this with the EARN membership committee to ensure that your activities are legitimate. I enclose details of the charges we would make for our services and how to apply for them.
The second option is for you to connect your computing equipment to EARN via a leased connection to Rutherford Laboratory. The computing equipment would have to be capable of supporting the relevant IBM NJE protocols and this would require as a minimum an IBM 4000 series or a Micro VAX. There would be some expenditure for appropriate software. The cost of the leased line would be of the order of 2500 UKL. I would have to get my EARN licence from DTI amended to include you. I have been attempting to do this with another client and nothing has happened for 6 months but I have not been pressing. However, I would not advise buying equipment before we had assurances that a licence would be forthcoming. I would add that it would probably be a very expensive option to buy equipment just for access to EARN. You would have to apply for Associate membership of EARN which would restrict you communications to full EARN members and in theory named sites. A bit more restrictive than as a 'member' of Rutherford Laboratory.
The service you would get from a direct connection to EARN would be superior in that your mail would end up on your own computer automatically. In the dial up case you will be faced with capturing information sent to your terminal while you sit in front of it. This is not difficult but just a bit tedious. Sending out documents is a bit more tricky in that you either type it in as you sit logged into our computer or you pre-prepare it and get our computer to capture the data as the PC transmits it from its disks. Again, not difficult but tedious.
Having laid the situation before you the next stage is for you to decide how you would like to proceed.
If you have any further questions I shall be happy to help you further.
Yours sincerely
Paul Bryant
Dear Mr. Robinson,
You will be aware that Mr. N Gunadhi is leaving our employment to take up a position with your company. Mr. Gunadhi was employed in developing and maintaining code in our Auscom equipment. This project has reached the stage where we do not intend to develop it further and we are therefore reluctant to retain Auscom expertise.
I understand that you may be prepared to allow Mr. Gunadhi to continue to maintain the system he has developed in exchange for use of our IBM equipment for testing Auscom equipment. We find this suggestion attractive and I would like to explore the proposal further.
I am of the opinion that a legal agreement between us may be difficult to draft in view of our contracts department wanting to evaluate the benefit of support against the cost of the IBM resources. They would also require to define closely the level of support provided and the amount of any computer resources. I would therefore suggest that we would do better to exchange letters of understanding which will certainly cause us less problems.
I would envisage that you would use your best endeavours to maintain the code in the Auscom and undertake minor modifications. We would use our best endeavours to allow you exclusive use of the IBM during our development periods for short periods and by prior arrangement. In addition we would allow you free use of the IBM computer at other times for the development of code associated with the Auscom which dose not require exclusive use of the computer. The agreement would be terminated by mutual consent.
I would value your opinion on this proposal and look forward to concluding a mutually acceptable agreement.
Yours sincerely
Paul Bryant.
Present: B Davies R27 F16 CCD (Chair) P Bryant R30 8 CCD CSS (Sec) C Reason R1 1.76 LAS ENG R E Thomas R1 2.78 INF INF T Daniels R27 F12 CCD CSO W Turner R1 2.07 ADM Apologies: J Sherman R68 1.30 BNS DPR R Cooper R31 F55 CCD SJN
The minutes were accepted.
M5.5.1 Provide 'NRS site responsibility paper' - retain Action: R Cooper
M5.2.1 There appear to be no outstanding problems with PADs and the action is removed.
M6.4.1 Provision of a TELEX Grey Book service via the Systime code. Action retained. Action: T Daniels
M6.7.1 A partial solution has been agreed with respect to the inclusion of Grey Book addresses in circulars to which recipients may respond.
M7.3.1 There has been no further responses to the request for input to the document on 'new science driven requirements'. The action is removed.
M7.3.2 Provide paper on the state of implementation of SSMP on various machines. Action retained. Action: R Cooper
P Bryant gave a verbal report on NDM. Attention had shifted to the provision of the local area network and this is reported elsewhere. The problems with PADs, the interface to the IBM, and the NRS were now largely over. It was now realised that the current X.25 network had disappointingly more or less reached the limits of its performance. Faster and more reliable connections seem to require a new technology.
It was likely that connections to villages that currently had no equipment would be connected at the same cost as current villages.
There is no reason why groups should not join existing villages if they could not justify a direct connection to the network.
It was unclear to which village the PRIME computers would connect to if they were to be equipped with suitable interfaces.
Agreement on the EARN funding was almost achieved. It appears that HEP will not want to use EARN for CERN traffic.
The transition of EARN to use ISO protocols was now progressing well. The transition should start next year.
There was a full discussion on the future of RCCC and NDM. B W Davies agreed to investigate whether RBM wanted RCCC to report to it and to define the role for it. Action: B W Davies
It was agreed that R E Thomas would be the chairman of NDM
To be in January or February.
Details of accommodation and travel will be circulated separately.
This document is being distributed to EARNTECH, EARNEXEC, and EARN-BOD.
Additional agenda items and comments are invited.
Meeting papers will be circulated in early November and the authors have yet to be confined.
I look forward to a lively and useful meeting.
Paul Bryant.
Sunday - Arrive.
Monday - (all times approximate).
0930 Minutes of last meeting (previously circulated) and matters arising.
0915 Workshop on the problems of managing international networks.
Presentation on the management of DEC's corporate network (Speaker to be announced)
Presentation of the management of IBM's corporate network (Speaker to be announced)
Presentation on the management of EARN (Berthol Pasch)
Study groups:-
Group 1 - Essential management tasks. How should they be allocated? How can EARN ensure they can be carried out?
Group 2 - Network topology and planning. Various changes have been made recently. Are these sensible? How should changes be decide upon? Are there rules that can be defined to help decide on changes?
Group 3 - Traffic monitoring. How important are the collection of statistics? How should it be achieved? What figures should be produced and how often? How can it be ensured that figures are produced?
Group 4 - User support, information services, and information dissemination. How satisfactory are the current procedures? What additional services are needed? What is the level of satisfaction with services particularly those provided by gateways?
1400 Issues to be resolved
1 EARN management.
The paper from Berthol Pasch defines the tasks and manpower needed to manage EARN. The Technical Group is asked to resolve how this should be undertaken after IBM support is withdrawn in 1988. It is unlikely that finance will be available for this task. Delegates are asked to determine whether their countries/sites will be able to take on some or all of the EARN management tasks.
2 Control of file sizes and traffic priority.
The paper from Eric Thomas proposes a possible strategy for the control of traffic on international links. This will involve international nodes being obliged to install various parameter settings and changes to network code. The Technical Committee is invited to approve the proposal.
3 Mail domain addressing.
The paper from Paul Bryant proposes a strategy for the wider use of domain addresses in preparation for the introduction of gateways to X.400. The Technical Group is invited to approve the proposal.
4 Topology.
The paper resulting from the Topology Working Group of 15 October shows the agreed topology. The Technical Group is invited to approve these changes.
5 Statistics.
The paper from Marco Sommani defines desirable statistics collection mechanisms. It is proposed that these are made mandatory for international nodes. The Technical Group is invited to approve the proposal.
6 Network discipline.
The paper from Paul Bryant highlights the difficulties of operating a network run on a co-operative basis in that it is difficult to impose standards and working practices. The Technical Group is invited to comment.
7 Future of the Technical Group.
The paper from Paul Bryant proposes the setting up of a 5 man Technical Executive which will meet 4 times a year and take technical decisions within the technical policy laid down by the full Technical Group which will meet once a year. This will allow quicker and more effective decision making. The Technical Group is invited to approve the proposal. If approved nominations for the Technical Executive, supported by the appropriate Board Member will be invited.
8 Items from the study groups not covered in previous discussions.
9 Date of future meetings.
10 Any other business.
Tuesday -
0900 Continuation of issues to be resolved.
1300 Approximate finish.
In common with many other organisations, the IBM PC has become very popular in the Laboratory. It is difficult to single out any particular application as machines tend to be bought for specific purposes because the relevant software exists. A popular use is for office automation since the machine provides both word-processing and access to PROFS.
There are now about 120 PCs on the site. There are a wide range of models from a variety of manufacturers. IBM has, until recently, been the preferred supplier but as their new PS/2 machines have diverged from the PC standard to which a lot of software and hardware is built, other suppliers are now being recommended. Such is the diversity of use within the Laboratory that great care is required in selecting suppliers since not all conform exactly to the IBM standard.
The PCs are supported by two staff members who deal with purchasing, delivery, maintenance, and user support. In addition some software and hardware is bought speculatively for evaluation. The software and equipment evaluated covers a wide range from new models of PCs, such as the PS/2 range from IBM, to software for giving presentations.
The PCs do not have a maintenance contract. First line maintenance is provided by the laboratory and to this end there is a pool of spare parts which can normally keep machines serviceable. More major repairs are carried out by various organisations but in many cases it is more convenient to purchase new equipment particularly where the failing parts are reaching the end of their useful life. In practice the machines have proved very reliable.
The applications being attempted are becoming more and more demanding as the power of machines increases and software is developed. Desk top publishing and small scale computer aided design look to be the most likely areas for exploitation.
The computing division provides a support service for other VAX computers both at Rutherford and in Universities which have been supplied by SERC. This has proved to be popular in that installations have good access to a pool of high grade expertise almost instantaneously. The main area for support is for communications software which is complex and difficult to deal with. Advice is also provided on many other topics. A repository for public domain software has recently been set up to avoid the need to have it available on all sites.
Development of the GIFT project, for providing file transfer between various networks, has continues. A trial service on the second stage has been introduced. The second stage enables CERN DECnet users to initiate file transfers to JANET machines.
An important activity has been the negotiations for discounts and bulk deals. This saves SERC money at the expense of the considerable administrative effort required.
A MicroVAX now front-ends the CRAY XMP-48 as an alternative access route. The connection is via a Hyperchannel. Although this has been a highly successful development considerable effort is needed to develop it. In particular in the areas of graphics, accounting, operation, user support, help systems, general utilities, and above all documentation. None the less, the popularity of this route is such that it may be appropriate to install a larger and more powerful VAX.
P Bryant
I have now studied the documents relating to the setting up of a political fund by IPCS.
I can appreciate why a political fund is desirable. It is important that IPCS is in a position to approach MPs and other bodies to achieve benefits for the members. Not being an expert on the relevant acts of Parliament I have to accept the position as outlined in the document from IPCS 'A change in the law - a change in our rules'. I would appreciate a comment from the relevant ministry on the statements made to ensure that they are correct.
The comments made in the document appear to go far beyond activities required to protect members interests. I refer to the section entitled 'Campaigns and politics'. In this it is implied that the union would mount activities on such issues as 'privatisation', 'cuts in agricultural R&D', 'energy policy', 'nuclear industry', and 'defence policy'. These are all issues on which the population has made its voice heard via the ballet box and are the subject of party politics. I can agree that these policies have, are, and will have an effect on our members. It is right that the Union should be concerned at this effect. But the duty of the Union is to ensure that the execution of the government policies to not harm members and not that the policies should not be carried out. Thus, they should be concerned with appropriate redundancy conditions, appropriate redeployment terms, appropriate relocation terms.
To bring this down to the Rutherford position I have to say that the funds available for science are not the concern of the Union. They are the concern of staff as private individuals who will no doubt take such action as they see fit. It is also the concern of Rutherford management. The concern of the Union is to ensure that in this situation members interests are protected if redundancies and redeployment are required.
In my view the IPCS has spoilt its case by requiring a political fund for legitimate union activities and then going on to quote almost exclusively party political examples for it.
Before I could support the setting up of a political fund I would need assurances on two fronts:-
1 That the fund is required for activities which are in the interests of members. This needs a clarification of the legal situation. I am unhappy with the Unions interpretation.
2 That such a fund would not be used for party political purposes. I class privatisation, defence policy, cuts in funding for science as party political issues.
The traffic levels still vary considerably from month to month. The trend is still upwards with levels of 1 Gbyte being frequent. The analysis of the traffic is achieved in three parts. The first is mail, the second file transfer, and the third is the RSCS traffic which is generated and received by the IBM computer at Rutherford. In a typical month the figures are:-
% Number of users Number of files
EARN JANET EARN JANET
Mail
FTP
RSCS ? ? ? ?
The RSCS traffic figures will be available in the future.
So far the line to CERN is able to cope with the traffic. It is currently operating at 9.6K.
The file transfer gateway has had no changes. Unfortunately traffic to the States now goes via Montpellier which is an MVS site. This prevents the file transfer macro operating from the States as MVS does not pass the NOP records transparently. This also seems to prevent PROFS mail to the States. This is being investigated.
A consultant was employed at Rutherford to bring into use the new version of the MAILER. This was important as the old one did not deal with headers correctly and had a large number of bugs. The new gateway is technically much better in that it is more stable and more automatic in operation. In addition new versions of the MAILER can be adopted with little effort.
Unfortunately, the change has had two unfortunate consequences. The first is that the domain order of non UK addresses now have to be in UK order. The second is that the gateway is far stricter in the addresses accepted and this caused some illegal addresses, in particular from GMAIL sites, to be rejected. Fortunately the required change to GMAIL is trivial.
Changes are planned to re-introduce a more relaxed attitude to addresses.
A number of topology changes are being planned. These are aimed at reducing costs and preparing for transition.
Regretfully the German PTT is imposing volume changes and thus all lines, apart from one to CERN, are being re-routed. The line to America may be removed now the Montpellier line is operational.
The lines to Italy are being re-routed to Montpellier which has lower tariffs. The line to America may be removed now the Montpellier one is operational.
Unfortunately, Tony Burraston, who produced the gateway has now left. This coincided with the consultants work. This resulted in the rather swift introduction of the new MAILER, it was then or never. It was a little later that the problems outlined above came to light.
Currently there is a bar on recruitment and a replacement for Tony is not possible. A small amount of temporary effort has been loaned from another group.
The financing of EARN is dealt with in detail elsewhere.
The financial model for 1988 was agreed at the EARN Nice meeting. It is likely that the model for 1989 will be different. By that time EARN should be well into its transition to use ISO protocols. This will require central funds for the purchase and operation of X.25 switches and the lines between them. It would be wrong if this expenditure fell on the switch sites. Thus it is likely that EARN will be receiving more funds from countries and then distributing them equitably in some way.
The outline transition document which was distributed at the last meeting has been followed by a detailed one which was considered at a technical meeting in Perugia. This meeting recommended many changes but in detail rather than in concept. Full detailed plans are now being produced for the first stages of transition. It is hoped to implement the plan during 1988.
Finance for migration is being sought from a number of sources and indications are that help will be forthcoming from several sources.
On reflection I think that the 5 year forward look (FYFL) should include all the expenditures even though these may not pass through the EARN accounts. The reason for this is that it would be very useful to see exactly what the cost of running EARN are. My management has been asking this question for a long time as they feel that at some time the complete cost of EARN may be shared between the countries and they would be upset if they do not have some idea of these cost now. I believe we also would find such figures useful. Below, I have added some draft FYFL 'lines' with some comments. All the figures are illustrative. The result will be a complex FYFL and I believe we should use a spread sheet program to allow the figures to be manipulated as we work towards an agreed document. We should each provide 'bids' for funds to Jean-Claude for the FYFL which can then be turned into a document. It is not sensible to expect Jean-Claude to know all the figures and all the 'heads' and I think it was a little unfair to expect him to produce the documents without help from us. In executive we should then make the figures 'sensible. We should also balance the figures and I suggest that we introduce the membership fee which will balance any deficit and perhaps provide a small surplus for safety.
Would this be a more useful document than the one proposed? What do you think?
1987 1988 1989 1990 1991
International -2000000 -2400000 -2400000 -2800000 -2800000
Line costs
Country pay 2000000 2400000 0 0 0
for lines
(Note 1988 reflect new countries, 1990 reflects 64K X.25 lines
1989 reflect possible payment of lines via membership fees)
Membership 0 0 3000000 3500000 3500000
fees
Associate 100000 20000 30000 40000
fees
(Note fees reflect possible payment of lines via membership fees
and payment of EARN office of technical staff after IBM funds are
exhausted)
Technical 0 0 - 50000 - 10000 - 10000
staff
(Note this reflects the eventual desire to provide permanent technical
staff, one in 1989 and 2 in 1990 onwards)
X.25 64K 0 -100000 -400000 0 0
lines
X.25 switches 0 - 20000 - 60000 - 20000 0
switch maintenance 0 - 2000 - 8000 - 10000 - 10000
Donation to X.25 0 122000 458000 0 0
(Note this shows one switch and one line for X.25 in 1988, three more
in 1989 and one more in 1990. This is expected to be financed by DEC in
1988/9 but by the membership thereafter. The X.25 line costs will be
absorbed into the other line costs when operational.)
Executive - 20000 - 20000 - 20000 - 20000 - 20000
travel
Hotel cost - 1000 - 1000 - 1000 - 1000 - 1000
BOD
Liaison costs - 5000 - 5000 - 5000 - 5000 - 5000
(We need to know where we can make cuts and also what various activities are costing us, Dennis notes the high cost of liaison with RARE/COSINE and thus we should monitor these).
The above is by no means exhaustive and we should each provide figures in the areas we know about.
As agreed in Paris I have produced a draft proposal for an X.25 experiment between RAL and Nijmegen. I suggest we keep this strictly confidential until we have worked on it and are confident it is possible. I suspect that if others 'get wind' of it it may cause friction which would be a pity particularly if it we failed. We shall have to talk to our managements though.
EARN is proposing to undertake a transition to ISO protocols from 1988 onwards. This involves the installation of a square X.25 backbone based on Rutherford, Nijmegen, CERN, and Montpellier with 64K lines. There may be changes to this topology.
It is expected that DEC will finance the switches at the four sites and the 64K lines or part of them.
The EARN transition strategy is defined in a paper presented to the EARN Board of Directors at their meeting in Nice in spring 1987.
A further detailed elaboration of the strategy was considered at a meeting in Perugia when further developments were made.
The transition project has now been split into a number of sub projects. The first two of these define the X.25 infrastructure and the second the use of NJE/SNA/X.25 which are the minimum requirements for the provision of a service. (Note, the first of these is in draft form but the second has not been started. I am hoping Michael Hebgen will draft it but I do not have a lot of confidence. Perhaps your staff can? I will send you a copy of the first part). (Also note that this first document will need altering to reflect us having a pilot project).
A 64K digital connection will be installed between Rutherford and Nijmegen. It is expected that DEC will finance this line as part of their support of the EARN transition.
Rutherford will loan an X.25 switch (the existing Telepac switch which meets the technical requirements) if switches are not obtained as part of the project by the time the line is delivered.
The Rutherford and Nijmegen IBM VM systems will be connected to the switch. The machines will utilise RSCS V2/SNA/X.25.
After initial tests the connection will carry the Nijmegen/Rutherford traffic.
The switch will be replaced by EARN supplied switches which are expected to be financed by DEC. This will be delayed by the requirement for a tender exercise before purchase.
The line will become an integral part of EARN (in the EARN tables) once confidence has been established.
The DTE addresses for Rutherford machines will be 23400009xxxx?? . The Rutherford IBM computer will be 23400009000000. The DTE addresses for Nijmegen will be 204xxxxxxxxxxx .
3.1 Possible loan of switch.
3.2 Setting up of switch. An operator is being trained to set up the Telepac switch and this will not involve more than a few days effort.
3.3 Negotiation for line with BT and Nijmegen. One man week. (Roland Brandwood). The UK cost of the line is 25375 UKL per year plus 750 UKL. Delivery is 4 months.
3.4 Mounting of SNA/X.25. This is under way as part of the project to mount VMNCP over VTAM. (Peter Girard)
3.5 Mounting of RSCS V2. This is under way for the current EARN connection. ( )
3.6 Mounting of RSCS V2 over VTAM and use of SNI addressing. IBM help is expected. Co-operation with Nijmegen will reduce the effort needed. Best estimates indicate that one man week will be needed. (Peter Girard).
3.7 Monitoring and report production. This will be provided by various people and take one man month (Paul Bryant, Peter Girard, Mick Reid, and Philip Overy).
3.8 Three visits to Nijmegan should be allowed for.
5.1 Finalise proposal.
5.2 Agree project with sites.
5.3 Agree project with EARN executive.
5.4 Negotiate for support with DEC.
5.5 Project start (guess February 1988)
5.6 Order line
5.7 Delivery of line (April 1988)
5.8 Experimental service (May 1988)
5.9 Service use (July 1988)
5.10 Replacement of switch (July 1988)
6.1 RAL and UK will retain a leading position in EARN.
6.2 RAL will be provided with an improving service to EARN.
6.3 It is expected that the connection will also provide a direct connection into JANET when compatible protocols are available in UK and the Netherlands.
6.4 The Netherlands is the centre of UUCP network connections and the connection will provide a better connection to UUCP for the UK assuming that any regulatory problems can be overcome.
The EARN technical group currently meets twice a year. The meetings tend to attract 25 or 30 delegates. The meetings tend to be partly decision taking but mostly educational. The decisions of the Technical Group tend to be difficult to impose probably due to the problems of discussing topics to the depth required and the production of detailed agreed proposals.
A solution to this problem is to make the current Technical Group an educational and policy group and to set up a Technical Executive which will meet more frequently and implement the policy.
The Technical Executive will operate as follows:-
The EARN Executive is invited to set up the EARN Technical Executive.
The EARN Executive is asked to approve the date and place of the next EARN Technical Group meeting and the agenda. Unfortunately we did not have time to debate the content of the meeting so I have added comments where I require advice.
Proposed date 30 November 1 December.
Proposed location Lisbon
Proposed agenda:-
[Unfortunately due to staff loss I am unable to bring one of my staff to take the minutes. There has been much reluctance to undertake this task at previous meetings. The options are :- take no minutes, attempt to get someone to volunteer (who?), or the administration to minute. Please advise]
The non exclusive options are:-
Option 1. EARN to finance a post to undertake the current duties. This post may also undertake further duties concerned with migration.
Option 2. EARN to finance support activities at several locations.
Option 3. EARN to contract support to a commercial organisation.
Option 4. EARN to seeks voluntary effort at one or more sites.
Option 5. EARN to attempt to share tasks with BITNET.
The Technical Group is asked to advise.
[A paper is required to define the current duties undertaken by IBM and others with a view to determining where duties should be located. Berthol Pashe is a candidate for producing it]
[The Executive is asked to advise whether there is a possibility of financing EARN support - if not then these options should not be included. However, considering the substantial amount of effort involved and the difficulty in getting some work undertaken by voluntary effort I do not rate the chances of voluntary effort doing the tasks very highly. If finance is available then I would envisage asking for bids from sites.]
The current topology is shown in .. and the Executive has proposed changes which will result in the topology shown in ..
The Technical Group is asked to comment and to suggest desirable topological developments.
[From the discussions at the executive it appears that relocation of lines is as a result of tariffs and the views of specific countries. To some extent this is caused by the lack of any statistics. I suspect that the Technical Group will merely call for statistics. Should this item be on the agenda? Please advise.]
In the past EARN has had little success in encouraging sites to co-operate fully in the activities of EARN.
The Technical Group is invited to suggest ways in which sites can be encouraged to follow EARN Executive and Technical Group decisions.
Domain addressing for mail is an aid to migration. The current situation is somewhat chaotic with entries in the DOMAIN NAMES file being entered as requested by sites. It is proposed to attempt to bring order by defining a scheme for domain mail names in EARN.
Option 1. Do nothing.
Option 2. Enter the ISO two character country codes into 'DOMAIN NAMES'. Insist on one machine in each country being able to deal with the country's domain. Countries will be able to enter further domain entries starting with their country codes. European entries in 'DOMAIN TABLE' will be policed to be in line with the two character codes.
Option 3. As option 2 with relaxation on country codes.
Option 4. As option 2 or 3 without policing.
The Technical Group is asked to advise.
[A paper is required. Who would be best to write it?]
[Perhaps it is premature to propose such a scheme. Please advise]
The proposal is to insist that international nodes restrict files transmitted to other countries to ...K. Files will be transmitted in priority order. RSCS V1 nodes will be required to install mods..
The Technical Group is asked to endorse.
[A paper is required to define the technical options. I suggest that Eric Thomas may be the best co-ordinator for such a paper].
International nodes will be required to install .....
The Technical Group is asked to endorse.
[A paper is required. Perhaps Marco Sommani is the best author]
The current group meets infrequently and is rather large for making rapid decisions.
The proposal is to set up a 5 man Technical Executive which will meet 4 times a year and take technical decisions within the technical policy laid down by the a full Technical meeting which will be held once a year. Meetings of the Technical Executive will be funded.
It is expected that the decisions of the Technical executive will be followed by sites.
The Technical Group is invited to comment. If the proposal is accepted then nominations for the group which must be endorsed by the nominees Board Member will be welcome and the the EARN Executive will select the Technical Executive.
[The current Technical group is too large and a lot of time is spent in education. It meets infrequently. It is difficult to get decisions. It is difficult to get sites to take any notice of decisions. Is this a better scheme? Is there funding for this activity?]
I was unclear from the executive meeting as to the exact topology changes. Could we please have a statement from the administration so that we can approve it act on it.
May I remind you that the UK request for a connection to Montpellier was not considered. Could you add it to the agenda for the next meeting.
The magazine Nature has asked to join EARN. I have studied the regulations for associate membership and find that they do not fall into any of the four categories. They are part of a profit making publishing organisation and they are clearly not
Do they fall into any of these categories? If not should we amend the regulations to embrace organisations of this sort? I seem to remember that associate members were allowed to communicate with specific full members and not full members in general (am I right?). If I am right then we are in a difficult position as they wish to communicate with people on any site who happen to be commenting on articles for them. I suspect that they may well wish to communicate with associate members where there happens to be people who are commenting on material for Nature. Does this also need an amendment to the rules if we wish to accept Nature as an associate member.
The responsibilities of an EARN member.
This section claims that the only cost to an EARN member is the cost of the leased line.... This would suggest that the international sites are not able to reflect the cost of the expensive international line and of the French connection to America. This would appear to be unfair to the international sites and in any case some countries are reflecting these costs to the members. Does the brochure need changing here?
I was unable to stay for the discussion on the 'strategic objectives of EARN.
Structure and Organisation. I fully agree that the funding model for 1989 should be developed as a matter of urgency considering the time it took to produce and agree the 1988 one. We considered collecting money centrally. I believe we should develop this concept. With X.25 it will become appropriate to collect funds to support the expensive 64K lines, the switches and the management of the infrastructure. These costs can then be distributed according to a formula to countries. It should be debated whether this should also extend to the other international lines. I would envisage that a percentage should be added for management and technical support of EARN (and subtract funds from sponsors).
I agree that EARN has concentrated on funding for the political arm of EARN. We have to consider how we fund the technical support after IBM withdraw and this is urgent and the technical group will be unable to progress until the funding is sorted out. It does not seem fair that UK is supporting 1/2 a man (me) to develop migration and run technical meetings (others also contribute significantly to the detriment of their organisations.)
I believe that EARN should principally be concerned with Europe. We already have a lot of problems. If we add further countries from distant places then our problems multiple. For example, Africa does nor have to contend with CEPT, RARE, and the CEC. I prefer the model of other areas of the world setting up EARN like organisations. We should give such organisations as much help and encouragement as possible.
I fully agree that we need more participation by institutes in EARN. I am not so sure that we should have targets for membership although we must ensure that membership is available if required. We must be careful not to tried on the sensitivities of countries. For example, a recruiting campaign in the UK would be counter productive.
I worry over associate membership as we could be accused of taking revenue from the PTTs. It is likely with 1000 associate members we will have some commercial traffic which could cause us problems. I have always considered associate membership as an exception to be used where there was a proven need for communication for a specific project. This needs debate.
It would be nice if someone could build a computer model of the network both in its current and projected form which could help to solve topology issues. The current network encourages countries to attempt changes to their particular benefit (UK Montpellier) which may not be to the common good. An X.25 network will be far easier to control and develop as the infrastructure will have to be centrally managed.
Complete backbone by end of 1989. I hope so.
I do not really understand this section. Interactive services are the only one missing. I agree that capacity should be increased.
Good thinking.
I would aim this at making EARN acceptable to everyone. (Difficult). Whilst we may well be an important European networking organisation it would be counterproductive to see this as some sort of competition with, say, RARE, JANET, DFN, SPAN etc. We must be seen at utterly co-operative. In fact EARN has a lot of shortcomings such as poor protocols, poor control over members (see arguments on file sizes and difficulties over statistics collection), little finance.
I am often asked 'why is EARN determined to use ISO protocols when the current network is providing an excellent service'. There are number of reasons:-
The transition of EARN will not be easy. Any changes must not disrupt the service to the users. EARN is a fairly loose association of sites with a degree of autonomy and located in different countries. Thus there will be a variety of differences in detail and time scale for transition in the network. Earn has limited finances and can certainly not finance the complete transition and thus much of transition will be in co-operation with national components.
It is vital that EARN will be able to inter-work effectively with other networks using ISO protocols. To this end EARN intends to support products conforming to the functional standards being developed by the European standards organisation CEN/CENELEC. Most, if not all, academic networks also intend to follow these. EARN is in close consultation with RARE, the European academic networking organisation, who are studying the relevant standards.
A transition plan has been developed over the last year. This recognises that transition has to be taken in phases with each phase being based on well proven equipment and software and each phase resulting in benefits to the customers. The plan recognises that although it is possible to undertake some of the early phases, the later ones depend on products which are still under development or in some cases are still being developed in the standards committees.
An outline plan was first presented at the RARE conference in Valencia in May 1987 and subsequently to the EARN Board of Directors in Nice a week later. The outline plan was favourably received and a more detailed plan commissioned. This was considered at a meeting of EARN experts with RARE participation. This provided further valuable development. The input document for Perugia is available in the EARN NETSERV document service.
The first phase of migration is now well defined and is to set up an X.25 infrastructure. To maintain current services the current IBM NJE protocol will be carried over the infrastructure using well proven IBM SNA technology. The initial infrastructure is planned to be based on four X.25 switches located at strategic points in Europe. The aim will be to put switches in locations with low PTT tariffs or where there is a high traffic volume. Discussions on the exact locations are now commencing.
There are a number of possible X.25 switch manufacturers. A specification has been drawn up and a final choice will be made when finance has been assured.
The switches will be connected in a 'square' which will give a good level of reliability against line failures. It will also provide some load shedding facilities. Although initially the lines between switches will be 9.6K, it is planned to use 64K as soon as possible.
Initially, countries other than the four with switches will be connected, as now, to the international IBM node computers. However, these machines will also be connected by X.25 links following the development of the switch sites.
This phase will preserve all the current services with the same or better performance.
The development of X.25 services within a country will depend on the local situation. In some cases there will be gateways into networks within the country and in others the EARN X.25 network will extend into the country. Care will be taken to co-operate with any national plans. Countries may have to run relays and gateways between EARN and national networks.
At this stage EARN will be supporting the existing IBM NJE services and X.25. However, the X.25 network may well be used with other popular protocols such as DECNET and Coloured Books on an interim basis until ISO protocols are widely available.
An important aim will be to maintain if not improve the existing services to the user.
Once the X.25 service is established attention will turn to the establishment of the higher level ISO protocols.
The first ISO protocol will be X.400. There are already a number of implementations available and although these may not currently conform to the 'functional standards' their use will be encouraged in the expectation that they will develop to conform in time. Relays between X.400 and the current EARN mail system (RFC 822) will be needed and there are developments which give confidence that systems will be available.
So far only experimental versions of the ISO file transfer protocol FTAM exist. The job transfer (JTM) and virtual terminal (VTP) protocols are not yet stable and implementations are not expected for some time. In these cases EARN will wait for suitable systems before further planning in this area takes place.
At the time of writing it is expected that the switches and X.25 infrastructure should be in service before mid 1988. The extension of X.25 connections to other countries will probably take until early 1989. X.400 services will probably start in mid 1988 but there wide use will depend on the availability and quality of implementations and of relays between the current mail service and X.400. At this stage it is difficult to predict when other ISO high level protocols will be in use and even more difficult to predict when the use of the current protocols will be phased out.
(Note - I think that this paper should be sown as being authored by the Executive rather than myself to give it greater authority.)
Dear Jean-Claude,
Here is my claim for my travel with respect to the EARN topology meeting.
Air fare 162.60 UKL RER 51,60 FF @10 5.16 UKL Total 167.76 UKL
Please make cheque payable to 'Rutherford Appleton Laboratory'.
Thank you.
With best wishes,
Paul Bryant.
Grade: SSO
Duties:
Managements of purchase, evaluation, development, maintenance, and user support of IBM personnel computers and similar equipment.
Management of some aspects of local area networks.
Management of four (three in post) staff employed on PC duties and local area networks.
Management of students and Trainee Scientists, typically two.
Liaison with IBM and other manufacturers on new products and assessing their utility for the site.
Development of a number of PC network products for use of the PC as a terminal and for use on the local area network.
Comment:
There are now 130 PCs on the site and the number is growing. The group is the only support of these machines and plays a vital role is ensuring that the users obtain the right equipment and that it performs satisfactorily. The high rate of development by manufacturers imposes a high level of continuing education and evaluation of new equipment. At this time it seems appropriate to centralise all aspects of PC support within a single small group of experts.
Grade: HSO
Duties:
User support for personal computers. Any request from a user is reacted to by appropriate means including personal visits.
Evaluation of user requirements and subsequent equipment purchase. Each machine is composed of a kit of hardware and software components which requires considerable expertise to list and order from a variety of suppliers.
Evaluation of new software and hardware.
Setting up of the hardware and software on user's machines. The aim is to provide the user with an operational machine with the selected software in place.
Production of documentation on various topics including utilities written 'in house' and other areas where users find difficulty. A newsletter is produced.
Education of users.
Management of a student.
Comment:
There are now 130 PCs on the site and the number is growing. The group is the only support of these machines and plays a vital role is ensuring that the users obtain the right equipment and that it performs satisfactorily. The high rate of development by manufacturers imposes a high level of continuing education and evaluation of new equipment. At this time it seems appropriate to centralise all aspects of PC support within a single small group of experts.
Grade: SSO
Duties:
Management of the support for about 50 VAX computers purchased by SERC.
Management of two staff employed on VAX support and development.
Management of students, typically one.
Management of the VAX front end to the CRAY computer.
Liaison with DEC to secure suitable financial arrangements for hardware and software purchase and maintenance.
Liaison with the sites hosting VAX computers.
Support of many aspects of the local area network which contains many VAX computers.
Participation in projects to develop network software required for VAX computers.
Comment:
The group is charged with supporting the VAX computers purchased by SERC as a way of ensuring their satisfactory operation and to reduce costs. This requires a high degree of expertise in VAX computers and their software. The greatest need is in the support of network products. These products are vital in the connection of VAX computers to JANET and to local area networks.
Grade: HSO
Duties:
User support. Questions on all aspects of VAX computers are accepted and may be subsequently passed to DEC if too difficult.
Maintenance of a library of software.
Development of network software. In particular the GIFT file transfer software in conjunction with CERN and others.
Support of network software needed to attach to the JANET network.
Organisation of meetings of various sorts between users, DEC, and SERC.
Management of the group's VAX computers including the connection to the CRAY.
Liaison with DEC on various topics.
Comment:
The group is charged with supporting the VAX computers purchased by SERC as a way of ensuring their satisfactory operation and to reduce costs. This requires a high degree of expertise in VAX computers and their software. The greatest need is in the support of network products. The group operates and maintains the VAX front end the the CRAY computer and a VAX dedicated to development. These products are vital in the connection of VAX computers to JANET and to local area networks.
RL.VE is running field test PSI V4.1 and CBS V4.2-3. PSI V4.1 should be released during the first week of November and CBS V4.3 next year. It is expected that RL.VE will be a field test site starting in November
A field test version of LLC2 has been run in conjunction with the 'Pink Book' project. It is expected to buy the software in due course.
Support has continued to be provided in the following areas:
PSI, CBS and JTMP - Advice on initial installations, advice when software stops working. Problems with interworking with other implementations. Advice to potential users - best DEC X.25 board to buy? Expected CPU and memory usage of CBS on a VAX? Problems with PSI Mail.
LLC2 - Work has been done for the Field Test. Queries from VAX managers about LLC2.
LAVC - Lots of new LAVC installations (Local Area VAX Cluster). Queries on how to set up have been responded to..
Hacking - RL.VE (as well as other RAL VAXes) seems to have suffered many hacking attempts. Time has been spent identifying where the hackers come from, informing the other RAL managers of "suspect sites" and reporting the hacking attempts to the JNT and universities concerned. Leading on from this Managers have been keen to get a copy of the X29 logging program which identifies where remote login attempts originated from. Time has been spent aiding managers to install this.
NRS - NRS updates continue to be produced once a fortnight. Regular requests are received from other Managers for the latest updates.
DECNET - Queries on installation problems are dealt with. Time has been spent discussing with a DEC consultant and other RAL VAX managers concerning rules for the DECnet to be run on the Site Wide Ethernet.
Site LAN - Members of the group attend the LAN Management Committee. The LAN bridges and RBMS from DEC have been ordered for the site LAN. The first two bridges have been delivered and installation in Informatics and HEP.
DEXPAND - The DEXPAND and DEC communications Boards are being compared. There are problems with outgoing X29 calls and with setting up NETAUTH for DEXPAND.
Joint Network Maintenance Contract - New machines have been asking to be added to the contract. A few obsolete machines removed.
GIFT - Work continues on the CBS slots of GIFT. A trial service for the P end has started. User support is provided. An investigation has started into the ISODE code (a portable set of implementations for ISO protocols) with a view to providing an FTAM slot.
Other queries include :
JANET Mailshr Help on installation, queries on how to use.
SPOOL Information required on Cranfield/Stirling SPOOL package.
X400 Information on DECs product.
PSS/IPSS Advice on accessing machines on PSS/IPSS.
EARN Queries on how to access EARN sites.
VMSCOMMS Requests to be added to the VMS Comms list.
Queries about whether the list is working.
The activities to connect the MicroVax as a front end to the Cray XMP-48 have continued particularly in the areas of graphics, accounting, operations, user support, help systems, and general support. Most of these areas need further enhancements and extensions and most of all - documentation.
The recent move of the Hyperchannel adapter has incurred a lot of effort
A large amount of negotiation has taken place over the Central SERC contract for DEC's network software. This year there was an increase of 50% applied which has now been reduced by 27%.
Time has been spent looking at the normal DEC software contract to see if it could be made easier to operate. Currently, the contract is in total chaos and needs some more effort to bring about a saner way of working.
The site hardware contract is much better this year but still relies on volunteer effort from Neutron Division. Maybe CCD could step in on both contracts to help out.
Work in setting up a site contract for NAG on VAXes is in hand.
Negotiations with DEC on a bulk purchase deal for their Pink Book software are at an advanced stage. This will be for all academic sites, not only SERC.
A deal for VAX archiving has been worked out for various machines at RAL with United Informations Systems.
Installation of VAXSET (VAX software tools) should allow all other VAX installations on site to be dependent on CCD making a considerable saving on maintenance costs.
A version of FTP over Pink Book on the BICC ethernet cards is being evaluated as part of the Pink Book project. The initial findings are that the product works but requires some development by the supplier.
The network 3270 product has been further developed to allow it to operated properly at 19.2 K and to co-exist with other PC software. This has involved the production of a new screen manager.
An asynchronous driver with the Network Services interface has been developed for use with the network 3270 and the console monitor project.
User support has continued and has seen a rise in the hardware support needed with the increasingly elderly PC population.
A lot of effort has been required to understand the new set of IBM PS/2 products and the OS/2 operating system.
In view of compatibility problems of the new PS/2 machines with IBM PCs 15 Tandon machines have been ordered and installed. A number of software changes to RAL and IBM code have been needed to support them.
8 PS/2 machines have been ordered and installed although the direction of PC development on the site is not yet clear and will remain so until the direction of IBM and other suppliers is clear.
A Zenith lap held machine has been evaluated.
Many pieces of software have been evaluated including:-
MS Windows IBM Graphics Terminal Emulator Pagemaker DW4 PC3270 Emulator V1.1
A further edition of the PC newsletter has been produced.
The equipment for the site wide ethernet has been ordered and much of it has been delivered including the fibre optic repeaters and two DEC bridges. No major problems have been encountered.
The Spider PAD has been evaluated as part of the Pink Book project. This appears to be a good product but still has a number of problems which should be solved before they are purchased for service use.
A certain amount of hardware PC maintenance is now undertaken. In some cases it is now being found that the cost of repair is similar to the cost of new equipment (in particular disc drives).
The Console Monitor Project being undertaken on behalf of JNT is on schedule for completion in early January. The work has included the evaluation of Vitamin C, a system for window control and of the VDI interface.
A 'C' to MASM data structure conversion program has been produced.
The IBM 3278 emulator software and file transfer mechanism has been investigated. This has led to the production of a more robust file transfer system and remote command execution on the IBM mainframe from a PC.
A proposal was produced under the leadership of N Gunadhi for a site wide ether net LAN. The production of the document was a co-operative venture between several divisions. The proposal was accepted and implementation has proceeded. A number of aspects have been reported on in sections 1 and 2.
The complete network is expected to be operational this year. Some modest expansion is expected but most development will now be expected in the sub-networks (or villages) located in various parts of the site. The connections between the villages are expected to have sufficient capacity for 5 years when they could be replaced by a faster technology now being developed by industry. This should provide an evolutionary process.
N Gunadhi has now left but there is sufficient expertise to operate a service although there is a need to acquire high grade expertise in this area.
The Pink Book software has been provided on the IBM computer via an Auscom front end. The code was developed in house by N Gunadhi. With his departure a arrangement with his new employer is being worked out to allow him to continue to maintain the system. A longer term, manufacturer supported solution is being sought but with little prospect of success, at lease in the immediate future.
On the whole the JANET/EARN gateway has provided a good service. It now passes about 1Gbyte per month. Although many queries are received these tend to be for information rather than complaints. The gateway is stable.
A consultant was employed to upgrade the mail gateway code to the latest version. This coincided with the resignation of A Burraston. The exercise was successful although some subsequent problems have caused some concern. The new system is far more robust and requires far less operational control. It is now easy to move to new releases.
Some further development work is needed and P Randels of Systems group is undertaking some of it.
This is carried out by P Overy of Support Services.
RSCS was carried out by A Burraston but is now undertaken by M Reid of Operations.
Funding problems have now been resolved with JANET for 1988 and the existence of the gateway is secure for 1988. It is anticipated that funding for 1989 will be forthcoming under a similar arrangement. The service is now funded by the users via their funding bodies.
P Bryant continues to be a member of the EARN Board and EARN executive as the EARN Technical Director. In this capacity he has directed the study on the transition of EARN to use ISO protocols and there is now considerable progress towards this end.
1.1.1 JTMP host-end service:
There has been a spate of reliability problems in recent weeks, possibly provoked by the increasing traffic in and out of the Cray via JTMP. Tim Kidd has been spending significant time analysing the problems and trying to rescue user output. Unfortunately, user output is still being lost quite frequently. The interface for CMSBATCH is ready for service, but has been awaiting CP Release 4 SLACBATCH in the 3081.
1.1.2 NIFTP: Static. No significant problems.
Tim Kidd has completed the user-end JTMP support in NIFTP by adding status/modify facilities. Not yet in service. He has also re-designed and re-organised the NIFTP maintenance system in a more satisfactory way. The module currently in service was generated from scratch using the new maintenance system.
1.1.3 SSMP:
This is in service using the original release of the Edinburgh SSMP/3270 package. It appears to be reliable, but suffers from various shortcomings, including slowness, which users have been specifically warned about.
1.1.4 PINK BOOK:
This is being used over the local Ethernet between the IBM, Spider-PADs and VAXes. It is not a service. Performance and overhead measurements are still required, as well as more severe testing under load. Full I/O chaining in the MAC driver has not yet been successfully used under VM. ULCC are working on these final refinements. Unfortunately, our principal LAN expert, Gunadhi, has now left.
1.1.5 CMS-PAD:
Version 1.5 was introduced in October, removing a number of bugs and deficiencies, and allowing full NRS addresses on the command line.
1.1.6 VTAM
VTAM/NCP/NPSI software has been generated, and so has the application interface software for using Coloured Books over VTAM. The Development 3705 is now connected between the IBM and a PSE. Everything is ready to test, but progress has been at a snail's pace due to other demands on time and effort.
1.1.7 Network connections
Three 38K X25 links are now driven, one to the CPSE and two to the JPSE, with outgoing calls split between the CPSE and JPSE depending on the destination address. It has been confirmed that the reason for our inability to use higher speeds lies in the PSE and not in the 4705. The Network Executive are pursuing the matter with GEC.
1.1.8 Routine maintenance: VMNCP, MVSNCP, NIFTP, CMS-PAD, 4705 software,
JTMP, Coloured-Book software at CERN, NRS tables. No significant problems, except as mentioned above.
1.2.1 JTMP host-end
The fundamental requirement is to obtain the next release of Network/VM from Salford. This appears to be still delayed by contractual problems between IBM and Salford. When obtained, work will be required to fit the interface to VMNCP onto the new version.
1.2.2 NIFTP
The completed JTMP user-interface support is working, and should be introduced fairly shortly. This involves additions rather than changes to the existing facilities.
1.2.3 SSMP
Attempts are being made to get Version 1.1.2 of the Edinburgh code, as it is said to be significantly better than what we have.
1.2.4 VTAM
Serious testing of the whole package should get under way, and investigation of the changes needed to NPSI in the front-end should also be undertaken.
There are no specific future requirements at this time.
The Operations section of Telecoms has been brought back up to complement by the arrival of two new members of staff. They are currently learning ropes' and relieving the pressure on other members of staff.
A GEC4195 was installed at the beginning of August as a second CPSE hardware configuration is such that it can currently support 28 links 20 of which are currently in use.
There is still one exchange at RAL (RLE1) and one at CERN (CPE1) running software running RAL software. The one at RAL supports BSC connections to UTS (RL.ID), MVS (RL.IC) and Imperial College (IC.PH.IA). Test were carried out at Imperial College with an Edinburgh Box (BSC-HDLC converter) but problems were experienced and the test need to be carried out again and closely monitored.
The hardware in general terms has been satisfactory, the areas for concern being the CAMTEC PADS and BT. During the period 28 faults occurred on PADS, 10 required just a power OFF/ON, 8 CPU faults of which 5 required returning to CAMTEC and 6 channel board problems requiring SIO/DART chips changed or boards to be set back to CAMTEC. The meantime to repair line reported to BT seems to be increasing, although this is more noticeable on JANET lines, some local lines have also been affected. Lines to ORHA, Swindon and Wantage schools are particularly bad.
PACX has been very reliable during the period with only two boards required replacing this followed the air conditioning shutdown and affected a limited number of people for a short period.
The X.25 exchanges have been reliable, downtime in general has been with power problems, air conditioning shutdown or system changes. The table shows the statistics for the period
CPSE CPSE2
Aug Sep Oct Aug Sep Oct
Downtime 1.57 .05 3.22 .03 .03 3.02
Scheduled 1.00 .00 2.39 .00 .00 3.02
Unscheduled .57 .05 .43 .03 .03 .00
Interruptions 4 1 4 1 1 6
Scheduled 1 0 2 0 0 6
Unscheduled 3 1 2 1 1 0
MTBF 248Hrs 720Hrs 370Hrs 744Hrs 720Hrs 744Hrs
Availability 99.73 99.99 99.54 99.99 99.99 99.59
Ave Traf/Day 201MB 146MB 165MB 45MB 40MB 48MB
The drop in the traffic levels from August to September on the CPSE was caused by changes in the way the IBM routed its traffic. External traffic is now directly to the JPSE, this lightens the load on the CPSE and more important the line between the CPSE and JPSE.
The Starlink Vax which was on the JPSE, due to flowcontrol problems on software, has now been moved to CPSE2.
Problems have been experienced with the link between the two CPSEs. One thinks the line is DOWN and the other does not, this has been report GEC.
Test were done running the Amdahl/CPSE line at 48K, but this produced problems when a number of short frames followed a long one from the Amdahl, the GEC could not cope and a fix to the microcode is awaited.
Further investigation into BSC/HDLC converter problems with the intent of changing Imperial College Physics Dept IBM over and hopefully moving RL.IC RL.ID onto HDLC as well. The latter two do not depend on the BSC/HDLC converter.
No other changes except those mention in Telecoms Installation and special investigations are envisaged.
Consider the implication of running X.21 from the Amdahl 4705 at 64K an implications of going or not going to GEC PSE Type 3 software. This requiring purchases of software and hardware if Type 3 is installed.
The traffic level on the X25 network appear to be fairly stable and there do not appear to be any further expansion that would require large additional funding, with the exception of that previous noted.
During the period 190 terminal faults were reported. Of these 70 were rectified by telcoms staff and the remaining 120 were dealt with by maintenance agencies.
The breakdown of the 120 is as follows:
DPCE 1 Contact for Tally line-printer MSM 56 Movable terminals KODE 40 Non-movable terminals SIGMEX 20 Sigmex terminals only Other 3 Warranty and specialist repairs.
There have been no major problems in the running of these contracts since their renewal in April this year. But there appears to be a general decrease in the 'Mean-Time-to-Repair.
An increasing number of terminals belonging to divisions other than CCD have been registered on the telecoms database labelled to reflect ownership. This makes the administration of the repair pool and charging for repairs much simpler.
None.
Not known.
During this quarter there was the usual round of office moves involving the installation of additional data sockets in some offices with more connections to PACX and JNT PADs. There was a marked increase in Ethernet installations during this period. Standard (10base5) ethernet cables were installed for A&G (R25 covering various floors), BNSC (R68 1.14 to R25 2.51), Technology (R25 2.51 to 2.81) and Computing (Telecoms room to the R26 Computer room north). Several thin ethernet (10base2) segments were installed for I.D. in R1, two in R68 and one in R25 for Technology, and several in R30 for Computing. A Decserver was installed on the A&G ethernet in R25 to provide terminal access to their ethernet. A cable with 12 fibres (50u) was installed between Atlas and R25 2.51 as part of the ethernet backbone, this cable will support the Technology, A&G and BNSC bridges.
The RAL communications equipment in the 'Barn' at CERN was relocated in the main computer room.
Wiring the main Console and Service Line desks in the console room at Atlas for data and power was started.
An investigation was carried out at Polaris House into problems with 'full screen terminals'. As a result of this it was discovered that certain integrated circuits on the 3270 interface boards were faulty.
The rest of the fibre optic cables for the ethernet backbone will be installed, terminated and commissioned. PACX will be upgrade to a PACX 2000. A fibre optic link will be installed between Atlas and R1 for a pair of IBM 3044 channel extenders.
The Grapevine equipment currently located in the telephone exchange in R1 will be relocated in the R1 Lab 11 communications room.
An optical multiplexer will be installed in R2 and another in R5.5 to provide V24/RS232 connections to those buildings.
A large amount of rewiring will be carried out at Atlas to replace the office wiring currently routed over the roofs of R26 and R27.
A coaxial link to Harwell Contracts for a 'full screen terminal' will be commissioned.
A coaxial cable and an X.25 link to MRC will be commissioned.
The A&G ethernet will be extended in R25 for a temporary computer relocation.
Data links will be installed between R1 I.D. and Reprographics in R3 for a Linotron typesetter.
Not known.
5.1.1 Software being run
RL.VE is running field test PSI V4.1 and CBS V4.2-3. A field test version of LLC2 has been run, it is hoped to buy the software in due course.
5.1.2 Support areas
PSI, CBS and JTMP
Advice is provided
LLC2
Work has been done for the Field Test. Looking at the possibility of getting a bulk deal for LLC2. Queries from VAX managers about LLC2 have been dealt with.
LAVC
There are of new LAVC installations (Local Area VAX Cluster). Queries on how to set these up have been dealt with.
Hacking
RL.VE (as well as other RAL VAXes) seems to have suffered many hacking attempts. Time has been spent identifying where the hackers come from, informing the other RAL managers of "suspect sites" and reporting the hacking attempts to the JNT and Universities concerned. Leading on from this, managers have been keen to get a copy of the X29 logging program which identifies where remote login attempts originated from. Time has been spent aiding managers to install this.
NRS
NRS updates continue to be produced once a fortnight. Regular requests are received from other managers for the latest updates.
DECNET
Queries on installation problems are dealt with. Time has been spent discussing with a DEC Consultant and other RAL VAX Managers concerning rules for the DECnet to be run on the Site Wide Ethernet.
Site LAN
There is represented on the LAN Management Committee. Bridges and RBMS have been ordered from DEC for Site LAN. The software for the two bridges in Informatics and HEP now delivered has been mounted.
DEXPAND
The DEXPAND and DEC Boards have been compared. Problems with outgoing X29 calls have been investigated. Problems of setting up NETAUTH for DEXPAND have been solved.
Joint Network Maintenance Contract
New machines have been added to the contract. A few obsolete machines removed.
GIFT
Work continues on the CBS slots of GIFT. Trial service for the P end has started. User queries have been answered. An investigate into ISODE for the FTAM slot. (ISODE is a portable implementation of various ISO protocols in 'C' which is in the public domain).
Other queries include :
JANET Mailshr Help on installation, queries on how to use.
SPOOL Information required on Cranfield/Stirling SPOOL package.
X400 Information on DECs product.
PSS/IPSS Advice on accessing machines on PSS/IPSS.
EARN Queries on how to access EARN sites.
VMSCOMMS Requests to be added to the VMS Comms list.
Queries about whether the list is working.
PSI V4.1 released is expected during the first week in November. CBS V4.3 is due for release next year. It is believed that RL.VE will be a field test site of CBS V4.3 starting in November. It is hoped to buy LLC2.
It is expected to receive ISODE V3.0 tape. This should run on a VAX/VMS system and is expected to offer FTAM over X.25.
The principle future requirement is for high speed graphics.
The need to use TCP/IP is under consideration.
6.1.1 NJE
The NJE service has been stable at RAL. Various changes elsewhere in the network have caused problems. The principle line to the USA is now a 56K satellite link from Montpellier. This operates using JES2. This prevents some forms of file transfer from JANET from the USA as well as PROFS traffic. In addition, management quality is reduced. This is under study. by EARN.
With the departure of Tony Burraston, Mick Reid is now responsible for RSCS.
6.1.2 File transfer between EARN and JANET
There have been no changes.
6.1.3 MAIL
Following the visit of Eric Thomas to RAL for a month and the departure of Tony Burraston a new version of the mail gateway was brought into use.
The new version is far more automatic and uses the latest release of the MAILER code. It is now easy to upgrade to new releases. The change was put in with some haste because of the problems with staff. Unfortunately there were some problems most of which were dealt with swiftly and others which are still outstanding. These are mainly to do with mail addresses.
Some extensive topology changes are expected to reduce costs and prepare for transition to ISO protocols. The changes involve the removal of most lines from Germany. RAL is expected to be connected to Nijmegan and Montpellier but will only pay for the Nijmegan (a saving of 14K UKL).
The current problems with the mail gateway should be removed.
The principle change will be the move to ISO protocols.
This is now expected to start towards the end of the first quarter of 1988. RAL expects to play a major role and to host one of the X.25 switches. The transition is expected to be supported by DEC but the details are still under discussion.
7.1.2 Move of A400
There are currently three adapters on the hyperchannel trunk:-
The A400 has four ports for connection of workstations, computers etc. Currently, only one port is connected. This port connects the MicroVAX 2 Cray front end.
There are plans to connect three more devices to the hyperchannel in the near future as Cray front ends:-
All three require access to the A400 within a distance limitation of approximately 20 feet. The A400 was initially in a rack in the machine room next to the Cray. To install three further, user accessible devices in the machine room is not a going concern! Thus the A400 had to be moved to a more appropriate situation.
The A400 was moved to the North computer room on the 15th October where the VAXen currently are (FR80 room to those who remember).
The move should only have taken a couple of hours but the engineer was on site from 9 a.m. until 7 p.m. This became a totally frustrating day with no VAX access to the Cray for the whole period.
The the diagnostics were run by RAL as the engineer was not too sure how to use them! These appeared at first glance to run successfully. Unfortunately the Cray station software on the VAX would not connect to the Cray.
After a very long period of suspecting every bit of hardware and software the engineer discovered that he had set the timing up wrong on the adapters. This he corrected - it made no difference! During this time the VAX to Cray connection would occasionally work, but after reloading the VAX or powering off the A400 it would then fail.
As it was now getting late it was left alone when it was working to some extent. Since then the Cray station software is continuously reporting errors (approx 1% of data), when prior to the move none were logged.
On contacting N.S.C. the day after it was discovered that the only engineer who appears to be any good was just about to go on leave for a fortnight!
This is the somewhat unhappy state as of the end of October.
7.1.2 Reliability and Performance.
7.1.2.1 Reliability
The hyperchannel connection has been very reliable except for one break after a major power failure. Unfortunately, this break took a lengthy time to cure, with the engineer not being sure what he had done to fix it! A close monitor needs to be kept on the reliability and time taken to fix. Specifically in the light of the problems encountered (and to be encountered) with the move of the A400.
7.1.2.2 Performance
The only measurements have been done using the Cray station STRSTAT command (Stream status information). THis shows a maximum transfer rate of 1.6 Mbits/sec doing a Cray disk to VAX memory transfer. The limits here will certainly be the VAX cpu and its I/O bandwidth.
This rate could be improved by increasing the block size from it's current 8 Kbyte level, but this would affect interactive response and leaving things at the current state would seem most appropriate.
As outline above the major changes during this period will be the connection of the three workstations.
It will be essential to get the VAX to Cray connection working reliably before we attach further devices as fault finding which is difficult now will be even worse.
The two Suns will be connected to the Hyperchannel using an IKON 10090 interface card, the IRIS will use an IKON 10070 card. All these cards have to be obtained from the U.S. directly and come with no U.K. maintenance.
If the hyperchannel gets very busy and there are unacceptable problems it may be worth considering some form of monitor kit for the future. However, this comes extremely expensive from N.S.C. and not to be considered unless a last resort.
No further expansion of Hyperchannel kit is currently envisaged.
Further developments of Network 3270 now allow it to operate at up to 19.2K and provide greater reliability. In addition it will now co-exist with other PC software.
There are now 10 BICC ethernet boards on site or on order. A 'cheaper net' ethernet has been installed in R30 to which a number of PCs are being connected. This is being used for evaluating the Pink Book software from Exeter and other products. It is still too early to determine when useful service will be available.
No major changes expected.
Use of ethernet by PCs is expected which will require further BICC ethernet boards but these will be purchased piecemeal by the users.
Following the acceptance of the report produced by the local area network working party, the relevant equipment for the backbone has been ordered. So far, two bridges, the fibre optic repeater, and a number a fibre optic lines have been delivered. HEP, Informatics, and CCD are now connected and confidence testing is in progress. So far there are no snags.
Eight villages now require to connect to the backbone which requires the purchase of a further fibre optic repeater.
The Pink Book collaboration with ULCC is proceeding at a reasonable pace. The following machines have been connected:
IBM VAX VMS Spider PAD IBM PC
The Spider LAN/WAN gateway is being tested at ULCC.
The results of the work are encouraging and a service should be possible next year.
The Spider PAD looks encouraging and gives an enhanced performance with network 3270. The other systems are reported on elsewhere in this document.
The backbone network will become operational. A service should build up and the extent to which it removes traffic from the X.25 network and PACX will be studied. No further villages are expected in the immediate future.
The Pink Book project will continue with a view to providing a service next year.
Most requirements will be within the villages.
A well supported ethernet connection into the IBM is vital. This should preferably be from IBM. With the loss of N Gunadhi the connection into the IBM is vulnerable and poorly supported.
9.1.1. Current Situation
Some mail from within EARN stops the IBM mailer. The source of the problem is invalid addressing methods. The MAILER sometimes recovers or sends an error message; on being informed, the relevant site (Toronto) 'fixed' the problem. Mick Reid is writing a 'crash proofer' which will mask the problem. GMAIL users still cause problems of occasion. Sweden is now in touch through EARN via SEMAX51, but only by old SUNET names - Linkoping seems not to work while Uppsala does.
Movement to release 1.25 of the MAILER has had no bad effects whatsoever - the mailing list problem was present before the change.
JTMP is being tested from various sites. The real users seem to get a reliable service. Ted Chance, a user in Pennsylvania of the ULCC Cray via the Daresbury protocol converter, seems in principle to be able to do this despite the Montpelier MVS machine, using *FILE cards instead of JANETFTP.
The production Fawn Box seems to work well and only SSMP interruptions provoke any criticism; there are heavy users testing it thoroughly. Network 3270 is only upset by Multivac - the lack of function keys past PF10 can be overcome. Many people use ULCC's Network 3270 implementation for the BBC.
The trial to adapt CP release 4 caused a certain amount of disruption last month.
9.1.2 Routine Tasks and Investigations
The return of 'dead letters' is undertaken manually if possible. We have attempted to return 'dead' failed mail; it is not a top priority as it takes a long time, but supplies useful background information on what really goes wrong.
The translation table in the IBM causes problems to people sending graphics as well as mail; word-processor output is also affected and is a reasonable use of the mail. The way round this is quite involved and can only be made to work by systems people if the site has restricted access to its mailer; if people do need to send word-processor output or graphics, they should filter their output as none of the special characters involved are standard on european keyboards.
The absence of 'postmaster' on some EARN sites is a problem; some sites are disorganised and can only be reached when they complain directly to UKACRL or post hard copy to RAL (not Manchester, Glasgow ...). Sites without systems support must find the authors of packages or they will not resume contact.
There are new customers for the EARN service, eg universities running Unix. They find the EARN addressing syntax awkward (it is a different interpretation of RFC822); a fix is being negotiated which requires little effort either by users or RAL.
A large portion of US mail is EARN out and ARPA back (it seems even some ARPA sites are unreachable from UCL); this causes no problems unless UCL reject unauthorised users' mail. UCL's status as the UK gateway and the demise of WISCVM compel the UCL return path.
FORUM articles make clear the problems of tracking EARN. There is usually success in solving technical EARN problems (usually instances where 'modifications' in the USA cause trouble).
The user interfaces are documented on EARN. The EARN situation is becoming clearer; there are many supercomputer mail interfaces but problems on supercomputers are quickly fixed, so this is of no importance.
SSMP and Curlew access should probably be backed up by a few reference sources on the network, it would be possible to condense information for NETDOC, but it takes time - as the present users have documentation, this is a low priority.
Contact with commercial organisations subsidising educational projects continues - mainly with Alvey and IBM people. A user called Geoff Tyson, who co-operates with business schools has been visiting and swapping expertise.
A public-domain Modula-2 compiler has been fetched; is this of any interest here? (it was done for CMS users at Imperial).
No changes expected.
Authorisation needs to be sorted out.
Mail contact and capacity problems are often caused by charging policies in the local PTT. CSNET, Australia, Japan, CERN Germany and Switzerland are areas where contact is piecemeal. LAN implementations cause security problems on EARN. There are some RSCS-based 'LANs'.
Full-screen terminal services are still a long way behind the mouse-and-window displays of Macintoshes and single user systems, so there may well be pressure to alter SSMP, however users who only had incompatible and line mode services before are very pleased with it. Curlew would be an better default editor than 'ed' for X400 mailers.
Mailing lists and other extra features are being added to EARN.
So far X400 development is limited to text, but we are trying to find reports on early fax, video and voice implementations.
An attempt has been made (successful) by Racal to mail over cellular telephone. They initially had problems configuring BT PADs.
The meeting does not feel competent to report on PIXNET.
NTMPC has been asked to report on how EARN should be developed.
It is proposed to set up a working party to produce a report for approval by NTMPC and submission to TMPC.
The working party will be:-
P Bryant P Girard P Overy M Reid P Randles
NTMPC is invited to set up the working party.
In each case comments will be needed on manpower and timescales for any developments.
A framework paper will be produced by P Bryant which will be followed by one or possibly two working meetings.
The topology working party met in Paris and decided on a topology. This attempted to take account of the German tariff, the low tariff countries, the traffic levels, and X.25 transition.
At the subsequent Executive meeting in Geneva the topology was changed because of the concentration of lines in Montpellier, the poor east west connectivity for the north European countries, and Dutch desire for better connectivity. A number of members had reservations.
The reservations resulted in further consideration at the Paris Executive and Board of Directors meetings. Here it was decided to make the minimum number of changes to remove lines from Germany. It was further decided to reconsider the topology later.
The diagram below defines the expected topology. Lines marked with 'n' are relocated ones.
The EARNTECH is invited to consider the new topology with a view to advising how future topology changes should be arrived at. The factors to be considered are:-
Stockholm
Copenhagen-------n-----+||||
Reykjavik---------------+|||
Trondheim----------------+||
Dublin-----+ Helsinki------------------+|
| |
RAL Nijmegen |
\ / |
Brussels \ / |
| \ n |
| \ / |
Paris \ / |
| / \ |
| / \ |
| / \ |
| / \ |
| / \ |
+--------Montpellier----------------------CERN-------+
|||||| || ||
Abidjan----+||||| || |+-n----Vienna
Heraklion---+|||| || +--n----Bonn
Izmir--------+||| |+------------------------------------+
Tel Aviv------+|| |
Pisa-----------+| |
Barcelona-------+ |
| |
| |
| |
Lisbon Cuny
n=relocated lines
Present:
Carlos Salenca FCCN@PTEARN David Lord PFKDN@CERNVM Joe Chester JCHESTER@IRLEARN Jukka Korpela LK-JKO@FINHUT Harri Salminen LK-HS@FINHUTC Angel Llopis LLOPIS@EMDCCI11 Berthold Pasch PASCH@DHDIBM1 Udo Meyer MEYER@DEARN Peter Sylvester GRZ027@DBNGMD21 Peter Streibelt CASTER@DS0IBM1 Jose Maria Blaso BLASCO@DBNGMD21 Ulrich Giese U001212@HEARN Kieran Carrick CARRICK@IRLEARN Dominique Dumas BRUCY@FRMOP11 Dominique Pinse PINSE@FRMOP11 Alain Auroux AUROUX@FRMOP11 Luis Penedo IBM Potugal Eric Thomas ERIC@FRECP11 Wim Brems LAAAA05@BLEKUL11 Fernand Benebet BENEDET@BLIULG11 Daniele Bovio HI@IMISIAM Sitki Aytac BILSAY@TREARN Henri Marciano DEC Geneva Odd Jorgensen DEC Geneva Marc Latouche DEC Varbonne Tam Chong Chi OPTCC@PTEARN Samuel M Eleuterio SAMUEL@PTIFM Jose Armando Silvan DEC Portugal Miguel A Campos EARNMAIN@EBOUBO11 Paul Bryant PEB@IB.RL.AC.UK Pedro Amorim AMORIM@PTEARN
It was proposed by P Sylvester, seconded by D Lord and carried that:
P Sylvester was appointed to produce a report of this meeting. Action: P Sylvester
Approved.
ISO country code changes are progressing.
Liaison with BITNET at the technical meeting level is tenuous. It was agreed to ask BITNET to appoint an officer for EARN technical liaison who would replace A Ecock. Action: P Bryant
Experts had been invited to participate in the production of the transition proposal and this was currently at the stage of a draft document.
Some text had been added to the transition proposal concerning RFC822 addressing and this would be further considered in a proposal for Domain Addressing at this meeting.
No X.400 addressing proposal had been submitted to RARE as EARN had not developed a definitive proposal yet.
No further information was available on VAX mail systems.
Details of the mail services used within EARN had not been collected.
Many of the RFC documents were available within EARN but details were not available. It was agreed to ask G Tashkovich what the situation was. Action: P Bryant
Performance test has been carried out on RSCS V2 and had been published in EARNTECH.
The NICE project had now terminated but there may be a second phase.
It was agreed that:
It was agreed that the tasks to be carried out by the proposed two EARN support staff are:
It was agreed that the attributes for the posts are:
The paper "File traffic control proposal" by E Thomas was considered. This will be re-drafted as a result of the discussions. It was agreed that the proposals would be classed as "mandatory directives" and "recommendations" and treated accordingly. This assumes that the proposals within agenda item 9 are accepted by the BOD. Action: E Thomas
It was agreed to continue with EARN Technical Meetings at six month intervals.
It was agreed to set up an "Operations Group". The group would be responsible for ensuring the effective and efficient operation of the network. They would undertake any changes required by the BOD. They would not initiate any changes. The group would operate via an electronic distribution list moderated by the Network Manager, currently Alain Auroux. The group would consist of the EARN Co-ordinator (U Giese), the Country Co-ordinators, and those responsible for important pieces of software (E Thomas and B Pasch). Action: A Auroux
It was agreed to set up "Task Groups". The groups would be set up for short periods of a few weeks to address specific issues. Examples of topics are gateways, domains, modelling/statistics, transition and user interfaces. They would operate via electronic distribution lists which would be "read only" apart from the group members. The results of their deliberations would be published in EARNTECH for wider comment and possible submission as "mandatory directives" or "recommendation".
It was agreed to set up a series of papers named ERFCs (EARN Request For Comment). These would cover a wide variety of topics. They would be developed as "Draft ERFCs" until adopted by the EARN BOD. When adopted they would define the strategy and policy for the operation and development of the EARN network. They would also define projects that EARN may wish to undertake. Outside the meeting it has been proposed that the administration (Joe Chester) should maintain the register of ERFC documents. ERFCs would be held in NETSERV.
These proposals are subject to agreement by the EARN Executive. Action: EARN Executive
It was agreed to set up a task group to consider mail domain addressing. The proposed members are: K Carrick, M Campos, P Bryant, and H Salminen. O Martin and H Nussbacher would be invited to join. Action: P Bryant
It was agreed that further consideration of topology should await better traffic figures.
It was agreed to set up a task group on statistics and traffic figures. The membership would be U Meyer, D Dumas/Pinse(?) plus M Sommani and P Sylvester subject to agreement. They should report within 2 months. Action: J Chester, P Bryant
It was agreed that a task group on topology would be set up when the statistics group had reported.
The paper from P Bryant on "Rules for the control of EARN nodes" was agreed subject to the renaming of "directives" as "mandatory directives" and "recommendations". "Suggestions" are dropped. The paper will be amended and reissued for comment in EARNTECH prior to submission to the BOD. Action: P Bryant
The next meeting will be 15/16 April 1988 in Izmir by kind invitation of Turkey. This is just before EARN 88 and is subject to confirmation.
The subsequent meeting will be in Finland subject to confirmation.
The X.400 project has reached the stage where its future must be considered. O Martin is interested in developing a better user interface possible based on the Rice mail interface and P Bryant is interested in the wide use of the system within the proposed EARN X.25 infrastructure. It was agreed to set up a meeting with the ENC involving O Martin, G Pittiloud, and P Bryant. Action: P Bryant
The university of Lisbon and in particular Pedro Amorim were thanked for organising the meeting.
DEC were thanked for their presentation on the management of Easynet and for hosting the dinner which was greatly appreciated.
IBM were thanked for providing a sight seeing trip around Lisbon after the meeting.
Ask BOD to invite the meeting reporter to present the
report of EARN Technical Meetings to the BOD. P Bryant
Produce the report of this meeting. P Sylvester
Invite BITNET to appoint an EARN liaison officer. P Bryant
Ask G Tashkovich about the state of RFCs in Netserv. P Bryant
Undertake EARN master co-ordination. U Giese
Undertake NETSERV administration. E Thomas
D Dumas
D Pinse
Undertake support of country co-ordinators. E Thomas
D Dumas
D Pinse
Consider provision of staff in 1989. EARN BOD
Produce updated "File traffic control proposal". E Thomas
Set up "Operations Group". A Auroux
Agree proposal for future of Technical Group. EARN Exec.
Set up "Domain Task Group". P Bryant
Produce updated "Rules for the control of EARN nodes". P Bryant
Set up X.400 meeting with the ENC. P Bryant
Reproduced below are the foils and other output from Perugia. Due to the limitations of terminals, information which was crossed out on the foils is enclosed in % %. Words which could not be read are marked as ????.
The information is in no particular order and no attempt is made to interpret or correct them. There may be other foils that I do not have.
Paul Bryant.
1. SQUARE TOPOLOGY - BUT NEEDS BETTER
TRAFFIC FIGURES
64K lines - MONTPELLIER BOTTLENECK?
(RELIABILITY/PERFORMANCE)
2. PTT X.25 USED AS BACKUP ROUTE
* - COST? next
- APPLICATIONS? meeting
3. SWITCHES - RFP SHOULD BE PRODUCED *
(84) WHO? - BOD
MANPOWER FOR INSTALLATION UNDERESTIMATED
& MANAGEMENT
X121
4 ADDRESSING - AWAIT ECFA (Rome)
& WG 3 & 4 of RARE
5 MANAGEMENT - NEEDED FOR BACKBONE
* ad-hoc or central group?
6 ACTIONS - INSTALL X25(84)
(BoD to DECIDE SITES &)
( TIMESCALE )
- TRAFFIC (RAL, CERN, PISA, COPENHAGEN
NIJMEGAN, DARMSTADT, MONTPELLIER
VIENNA)
* - CO-ORDINATION? SHOULD BE APPOINTED
FULL TIME?
1 BEGIN NOW - TEST SNA CONNECTIONS
* FOR ALL INTERNATIONAL NODES
- MOVE TO X.25 AS SOON AS
to BOD SWITCHES are available
- end nodes may try other
NJE/X.25 possibilities
2 NO TECHNICAL OBJECTIONS TO NON NJE
NON ISO
BUT :- EARN TECH MNGT will only
provide for OSI, NJE (interim), X.25 infrastructure
LISTSERV, NETSERV ETC
(SNA to PROVIDE NJE INTERIM ONLY !!)
(PRICE of SNA are decreasing)
(NJE/X.25 developments not worth it)
%VTAM %
%SNA is locally needed for%
%OSI on IBM systems %
%NJE/X.25 %
1 PROCEED WITH X.400 (1984)
2 PILOT SITES - not just backbone
Products: SOFTLAB, HEIDLEBERG, QUEENS, EAN, etc
3 FURTHER STUDY OF X.400 AND domain addressing
sub group of EARNTECH?
CO-ORDINATION WITH RARE
& at COUNTRY LEVEL
4
DEFINITION OF GATEWAY REQ'D
INSIDE EARN
sub group of EARNTECH?
5 ISSUES ARE VERY COMPLEX
& nor solved
NOT TO BE DECIDED IN
ISOLATION
6 Agree with p.39 Recommendations
TRAFFIC STUDIES - WHO AND HOW AND WHEN
SWITCHES - HOW AND BY WHO
X121 -
TIME SCALE - ?
SG2
REJECT - NJE/DECNET/X.25 AND NJE/?/X.25
CLARIFY NJE/SNA/?
MOVE TO SNA LONG BEFORE X.25
OR JUST BEFORE
TIME SCALE - START NOW
SG3
JOIN RARE GREOUPS. NO AGRESSIVE
MOVE TO X.400
NEED WRITTEN REPORT TO CIRCULATE
-----------------------
FUTURE. DO WE MEET AGAIN - WHEN
WHAT WILL WE ACHIEVE BY NEXT
MEETING AND HOW?
-----------------------
EXEC. EXPECT UPDATE OF 'GREEN BOOK'
- NOT POSSIBLE. THERFORE NO AGREEMENT FOR
BOD IN NOVEMBER - NEXT OPORTUNITY
MAY BOD
There is no need to have a compete SNA network over SDLC lines before moving to X.25. As soon as an SNA connection has been tested without any loss of service for the rest of the network, it can be moved to SNA/X.25. However, nodes are invited to start preparing for the SNA/X.25 connections while waiting for the X.25 switches. The SNA/X25 migration is a necessity for the transit international nodes. End node countries can decide other ways to provide NJE/X.25 by bilateral agreements with some SNA transit node.
There is no technical objection against the usage of ??? NJE and non ISO protocols over the X.25 network. However, the EARN protocols over the X.25 network. However, the EARN technical management will only be concerned with.
The EARN management will be concerned with problems related to SNA only for the purpose of providing NJE during an interim period; all agreements concerning resources, naming, connections, etc. will not take into consideration the usage of other SNA applications.
The management of other protocols and their related gateways is not the concern of EARN, but of the groups who manage those protocols.
Topic: Provision of NJE/X.25 on the backbone. Connections within countries can be either via X.25 or BSC.
NJE over X.25 is provided by JNET/DECNET or SNA. Although JNET/DECNET is not recommended as a general solution, because there may be connectivity problems between JNET and IBM products, it can be selected by peripheral set of countries. This requires the coexistence of IBM and Digital equipment in some countries, with a BSC line between the two systems. The existence of a DECNET solution should be mentioned in section 3.
Prices are no more a problem for SNA, there are 90% discounts on software. The price of a 3720 is about 50000 Dollars. Most IBM OSI applications will require VTAM.
It is not recommended to wait for the availability of NJE applications over X.25 although if other implementations become available, the can be used.
Topology and location of switches
a- proposed topology of the report is based on a financial model which considers only the line tariff in each country: additionally traffic figures are incomplete in some cases incorrect (RAL-CERN), traffic measurements were made at different periods.
In order to be able to set up a consistent topology the following points should be considered first:
-statistics has to produce passthrough figures ?????
-tariffs of lines at more than 9.6K (64K especially).
A further unknown is the model is the traffic generated by accepting DECNET, Coloured Book etc.
b - Care should bee put on the particular situation of Montpellier: the high concentration of lines on this node will lead to the same bottleneck as once in BITNET, (the same remark applies to the proposed Copenhagen nodes); the type of system used (heterogeneous on the backbone) Montpellier (MVS) does not allow the provision of EARN services like LISTSERV, ?????? on other directly on the backbone (traffic optimisation consideration!).
c - Extension of the model: provision of backup facilities for the nodes out of the basic (square) backbone via the PTT X.25 network. (The backbone should be reliable enough).
This proposition implicates
-solution for financing problems of eventual backup traffic.
-DTE addressing scheme has to comply with PTT one.
d - Further considerations: attitude of PTT in various countries, NL as a suitable location was mentioned, interworking with CEPT.
Selection of switches
The WG is not able to evaluate just now the switches, the process should follow the principles of a request for Proposal. WG only expressed the following remarks:
- There is no consensus on the exact value? of the future X.25 version of 84, does it really fit our needs, will the first implementation be stable and conformant?
- The manpower required by the installation and management of X.25 84 switches is underestimated in the report.
DTE Addressing
- Question: Why not use HEP addressing?
We don't have the ?????, should wait for result of ECFA (Rome).
- Anyway addressing scheme should be open enough to allow other communities to access EARN.
RFC 822 mail systems have been steadily adopting domain addressing.
Details of domain addressing can be found in RFC 920.
This proposal is that EARN should encourage the use of domain addresses. The benefits are:
For historic reasons the use of domain names in the USA has tended to be based on networks and has resulted in top level names of the form ARPA, COM and so on.
In Europe the desire is to adopt the two character ISO country codes as the top levels such as FR and CH.
In Europe the objective would be for the address of a mail box to be the same regardless of which network it is on and the access route. In fact a mail box would have an RFC 822 form and an X.400 form. RFC 987 provides the mapping between the two.
EARN would recognise within Europe 20 or so top level domains, one for each country. The other components of an address would be a matter for resolution within a country and agreed with all the interested parties. In some cases decisions have already been taken.
The proposal requires that a single system exists in each country which will accept mail addressed to the country. It may be that initially such mail will be rejected until systems within the national EARN can accept the addresses and/or relevant relays to national networks have been established.
The top domain names will be in the NETSERV file DOMAIN NAMES as .FR .CH and so on. The top level country codes should be registered in SRI-NIC. This may not be possible in some cases as the code will have already been registered by some other organisation.
Countries shall set up a single mail service capable of receiving mail addressed to the country domain.
Countries shall if possible register their country domain name in SRI- NIC.
Countries are encouraged to extend the use of domain addresses within their country and to provide relays to appropriate national mail services.
Approved.
Section 2. The registration of new names for the EARN gateway such as UK.AC.RL.EARN-RELAY and EDU.. were being discussed with with Jim Craigie of the JNT.
Section 4. The proposed link with Montpellier had not been initiated. Topology is considered below.
A financing proposal for the UK gateways was put before the meeting. This covers all the costs of providing the service.
The costs of running each gateway are given as:
x1000 pounds
PSS/IPSS 190
ARPA 100
USENET 120
EARN 60-80
X400(EAN) 80
SPAN 80
FTAM 60 (when it is opened)
Gateways were established in an ad hoc manner and financial control has been poor. Guidelines are proposed for the establishment or continuation of gateways which are that there is:
EARN UK is funded by IBM until the end of 1987, however future costs would be recovered from the users or their funding bodies.
The cost of the EARN gateway was 60,000 pounds.
Given the use by individual groups and the decision by HEP to remove the EARN traffic from the CERN line the costs falling on the funding bodies are:
x 1000 pounds
Nuclear physics (27 per cent of traffic) 18
Computer board (56 p.c) 37
ASP (7 p.c) 5
Alvey (3 p.c)
Engineering Board(3 p.c)
Science Board (3 p.c)
It is not economical to recover less than 5000 pounds.
Money was now available for 1988 and the Computer Board would fund the gateways for two years provided that the guidelines are met.
A liaison model was explained demonstrating the path by which the Network Executive and Network Advisory Committee managed services (eg gateways) for the community. The path by which users comment on services is via the various JANET user groups and so to the NAC. NAC also advises the funding bodies after consulting user groups.
It was considered that since many liaison meetings already consider EARN, the model gave EARN user interests an adequate voice.
Bob Cooper felt that the Computer Board's offer was a very good deal.
Discussion of Bob Cooper's paper.
The meeting unanimously decided to advocate a joint membership of the EARN board by Paul Bryant and Mike Wells.
Asked whether Mike Wells would be elected by the EARN membership, Bob Cooper said that representation would be as in the liaison model.
Asked whether the joint membership should pose any problems, Paul Bryant said that several countries were in a similar situation to the UK and saw difficulties with the Board of Directors Membership. He had hopes that the situation could be resolved.
Bob Cooper said that the EARN board member(s) would be appointed by the NAC taking into account the views of the EARN users.
Bob Cooper's EARN UK funding proposal was approved.
Asked about the EARN funding model for 1989, Paul Bryant said that it was undecided at present. Proposals are being considered ranging from the continuation of the current model to one based on membership subscriptions which may also cover administrative and development activities.
HEP withdrawal: The removal of the HEP traffic would halve the traffic on the UK CERN line and this would delay any need to upgrade the line.
Backbone problems: The introduction of an MVS node at Montpellier has caused some file traffic from the UK to BITNET to fail. However, this could be got round at some inconvenience. Montpellier were looking at the problem. It is believed that PROFS traffic is also prevented.
Software update in August: The development and installation of a new mailer, undertaken by Eric Thomas (a consultant), had solved many problems. There were unfortunate side effects due to a syntax change and stricter checking of headers. The new mail system is far more robust and maintainable. The suddenness of the update was unfortunate and was caused by the departure of Eric Thomas and the resignation of Tony Burraston.
Future topology of EARN, ISO migration: The introduction of volume charging by Germany has led to the removal of most lines from Germany. It is now proposed that the UK will be connected to Nijmegen and Montpellier. The UK will pay for the Nijmegen line. Traffic to the USA now goes via Montpellier. The new topology paves the way for the transition to ISO protocols.
[Note- the EARN BOD has altered the topology and the UK will retain the single link to CERN]
New EARN members: Yugoslavia, Algeria and Cyprus were joining EARN but the UK may block traffic to Yugoslavia (as it is a member of COCOM) or to Cyprus (as it is a war zone)- these reserved rights were unlikely to be used.
US ARPA-BITNET gateway: The ARPA gateway at Pisa will not be available for UK traffic. It had been hoped that this would take the place of the Wisconsin gateway which is being phased out. It is hoped that alternatives to WISCVM can be found.
[Note- A connection to ARPA is now assured.]
Responsibility for connection to other networks: The EARN gateway can only assure traffic to and from EARN and BITNET nodes. Help with mail via EARN to other networks is provided on a 'best endeavours' basis.
The majority of problems are with traffic to networks other than EARN. In most cases satisfactory, if inconvenient, paths can be found. Unfortunately networks remote from EARN change, as do their gateways to EARN, and these changes are often only detected when traffic fails. The situation is improving as the quality of gateways improves.
The effects of syntax changes were described. In particular the way in which problems with the gMail package had been handled. The syntax change caused a reversal in the way % domains has to be ordered. The gMail problems had been caused by stricter checking of the syntax of addresses. There are about 800 VAXes on BITNET/EARN which use gMail to access other networks through EARN.
The EARNUS mailing list , set up at the last meeting, had been a much-used and worthwhile facility. It was used to distribute information during the update of the mail gateway.
Large files had recently been shipped across EARN without problems. Large files are causing some concern in EARN and it is better to use the utilities which exist to split and re-merge them so that they do not have an adverse effect on others.
Despite rumours in the press, there is no intention by EARN to move to DECNET protocols or to be 'taken over by DEC'. Transition to ISO is still the EARN policy. There is an agreement that DEC will provide EARN with help in its transition. The exact form of help is yet to be agreed and may be in the form of equipment, manpower or finance for lines. The help given by IBM and that expected to be given by DEC is gratefully acknowledged.
At the last meeting in Perugia of the EARN technical committee, it was proposed to begin transition by installing a backbone of 4 or 5 X.25 switches running SNA/RSCS over X25 which would maintain the file transfer facilities. OSI higher-level protocols would be added later when available. EARN, COSINE and RARE are co-operating in the EARN planning activities. The project is expected to start next year.
12th May 1988 at UCL.
The next and subsequent meetings will be devoted to the use of EARN. Political and financial issues will now be dealt with in the JANET user groups. It is appropriate for sites to reconsider their representation at meetings. Paul Bryant and Phil Overy will still attempt to advise on all aspects of EARN.
A number of problems were considered.
A high speed local area network is being installed. This is based on ethernet technology and a set of LAN bridges.
The aim is to develop an improved network service to the site in terms of speed reliability and the services provided. It will eventually allow the older slow speed technology to be phased out.
As yet the complete set of components is not available and new products are appearing which it may be appropriate to use. In particular components for providing the 'Pink Book' services are not all to hand.
The purpose of the post is to:
The duties of the post are:
Applicants should posses the following qualities:
Further information on this post is available from Mrs J McDermott. Personnel Section. Rutherford Appleton Laboratory (Ext 6604).
Permanent employees wishing to be considered for the above post should complete a staff application form and forward it via the Head of the Group or Section to reach their Personnel Officer not later than the closing date.
A non-industrial employee of the Council servicing on AEA-type conditions would be entitled to retain those conditions on appointment to this post.
There are now 130 IBM Personal Computers (PCs) on the site and the number is growing. The group is the only support of these machines and plays a vital role is ensuring that the users obtain the right equipment and that it performs satisfactorily. The high rate of development by manufacturers imposes a high level of continuing education and evaluation of new equipment. This is best achieved by centralising all aspects of PC support within a single small group of experts.
The development of a site wide local area network is of great importance and many of the IBM Personal Computers will connect to it.
The purpose of the post is to:
The main duties are:
Applicants for this post should:
Further information on this post is available from Mrs J McDermott. Personnel Section. Rutherford Appleton Laboratory (Ext 6604).
Permanent employees wishing to be considered for the above post should complete a staff application form and forward it via the Head of the Group or Section to reach their Personnel Officer not later than the closing date.
A non-industrial employee of the Council servicing on AEA-type conditions would be entitled to retain those conditions on appointment to this post.
There are now 130 IBM Personal Computers (PCs) on the site and the number is growing. The group is the only support of these machines and plays a vital role is ensuring that the users obtain the right equipment and that it performs satisfactorily. The high rate of development by manufacturers imposes a high level of continuing education and evaluation of new equipment. This is best achieved by centralising all aspects of PC support within a single small group of experts.
The purpose of the post is to:
The main duties are:
Applicants for this post should:
Further information on this post is available from Mrs J McDermott Personnel Section, Rutherford Appleton Laboratory (Ext 6604).
Permanent employees wishing to be considered for the above post should complete a staff application form and forward it via the Head of the group or Section to reach their Personnel Officer not later than the closing date.
A non-industrial employee of the Council servicing on AEA-type conditions would be entitled to retain those conditions on appointment to this post.
SERC has purchased about 60 VAX computers which are installed on site and in Universities. Rutherford Laboratory provides support for these computers to ensure their satisfactory operation and to reduce costs. This requires a high degree of expertise in VAX computers and their software. The greatest need is in the support of network products. These products are vital in the connection of VAX computers to JANET and to local area networks.
The CRAY computer is front ended by a VAX computer which provides a service to a growing number of users. The service is popular and visible outside of the department and must be supported to the highest standard.
The purpose of the post is to:
The main duties are:
Applicants for this post should:
Further information on this post is available from Mrs J McDermott. Personnel Section, Rutherford Appleton Laboratory (Ext 6604).
Permanent employees wishing to be considered for the above post should complete a staff application form and forward it via the Head of the Group or Section to reach their Personnel Officer not later than the closing date.
A non-industrial employee of the Council servicing on AEA-type conditions would be entitled to retain those conditions on appointment to this post.
SERC has purchased about 60 VAX computers which are installed on site and in Universities. Rutherford Laboratory provides support for these computers to ensure their satisfactory operation and to reduce costs. This requires a high degree of expertise in VAX computers and their software. The greatest need is in the support of network products. These products are vital in the connection of VAX computers to JANET and to local area networks.
The CRAY computer is front ended by a VAX computer providing a service to a growing number of users. The service is popular and visible outside of the department and must be supported to the highest standard.
The purpose of the post is to:
The mail duties are to:
Applicants for this post should:
Further information on this post is available from Mrs J McDermott. Personnel Section, Rutherford Appleton Laboratory (Ext 6604).
Permanent employees wishing to be considered for the above post should complete a staff application form and forward it via the Head of the Group or Section to reach their Personnel Officer not later than the closing date.
A non-industrial employee of the Council servicing on AEA-type conditions would be entitled to retain those conditions on appointment to this post.
TMPC is concerned that the Auscom IBM ethernet interface is not well supported. They believe that a well supported ethernet interface should be sought. They have therefore asked NTMPC to undertake a survey of possible interfaces.
It is proposed to set up a working party to undertake the study.
The study may well involve visits to sites such as Edinburgh and CERN and will therefore take a long time. The projected report date is the start of April.
Members of the group are those with specific expertise and are:
Auscom A Jesset as is with Dexspan as SNA device PU2.0 and LU 2.0 emulating 3274 1A (code from Auscom). 3870 P Girard DACU G Robinson VME system C Osland VAX system (Auscom boards) M Waters CERN P Bryant IBM SERIES/1 ? ACC ? Fibronics/Sparticus ? Interlink ? IBM plans ? Daresbury and other sites ? Other products ?
It is essential that any product must support Pink Book. It is desirable to support TCP/IP and/or DECNET.
Each "solution" will have a section with the following subsections:
There will be a final section summarising the findings of the study and giving any recommendations.
TMPC has been asked by TMPC to define how the Department could obtain TCP/IP expertise. This may involve setting up projects.
It is proposed to set up a working party to produce a proposal.
The possible members who have knowledge of TCP/IP are:
M Waters, G W Robinson.
I crept up on LISTSERV and caught it when it wasn't looking and finally beat it! To get it working properly there seems to be a number of options.
Any views please?
Is there any reason why I should leave you as one of the POSTMASTERS? There seems to be a minor fault in that attempts to ADD to a list which has no owner fails with an error 24.
Dear Mr. Kloack,
I look forward to our meeting in Utrecht on 6 January. I shall be arriving on KL114 at Amsterdam at 0905 so I should be with you shortly after 1000. This is earlier than I had expected but I shall have to depart a little earlier than expected to catch BA417 departing at 1930. I hope this causes no inconvenience.
I enclose three papers which I have produced:
These three papers have not yet been issued so I would appreciate them only being shown to people who need to know the content.
I have the agreement of my management and JNT to progress this proposal. I have also been assured of the manpower I require.
At our meeting we need to agree a list of actions and a time scale. I am anxious that we should now proceed with minimum delay.
The scope of the project is to use NJE over an X.25 connection between our countries. I believe we should also consider what other uses we could make of the connection. I have a partial agreement with JNT that we can connect JANET directly to the EARN X.25 network. This would allow us to develop interactive and other services. I think it might be counter productive to bring these other services into our initial proposal as they may attract adverse comment and unduly complicate matters.
I understand that Bob Lindhout will be attending the meeting.
With best wishes
Paul Bryant.
The transition of EARN to use ISO protocols is split into four parts:-
Part 1 - Earn X.25 infrastructure.
Part 2 - NJE over X.25.
Part 3 - X.400
Part 4 - FTAM, VTP, and JTM
This document is part 1 of this series.
The X.25 network may be provided by the PTTs, other suppliers, or the community.
The criteria for the selection of a supplier is that the network must be provided with a non-volume tariff and at a price the community can afford.
Until recently only the community could provide such a service but there are now indications that there is at least one possible alternative supplier.
A non-community supplier is preferred as long as they have the relevant expertise.
The line topology is shown in figure 1.
Copenhagen*-n-------+
Stockholm---n------+|
Reykjavik---n-----+||
Brussels*-n-+ Trondheim---n----+|||
Dublin-----+| Helsinki----n---+||||
|| |||||
RAL*---------------n-------------Nijmegen*
\ /
\ /
\ n
\ /
\ /
/ \
/ \
/ \
/ \
/ \
Montpellier*---------------------CERN*
||||||||| ||
Barcelona*-+|||||||| |+-n----Vienna
Abidjan*----+||||||| +--n----Bonn*
Lisbon----n--+|||||+------------------------------------+
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa*------------+| Washington
|
|
Cuny
Fig.2 X.25 infrastructure
n=relocated lines
*=sites with VTAM, note at CERN VTAM is not on CEARN.
Switches will be located at RAL, Nijmegen, CERN, and Montpellier.
Initially and where possible existing lines will be used at the existing speeds. The connections between RAL, Nijmegen, CERN, and Montpellier will be replaced by 64K connections as soon as lines are available from the PTTs and finance is available.
The initial lines will include the lines between the switch sites.
The remainder of the connections will be required as and when countries decide to join the infrastructure.
The requirements for an X.25 switch are:
The requirements for X.25 DCE connections are:
The LCN allocation will be:
Permanent virtual circuits- groups 0 through 3 One way incoming- groups 4 through 7 Two way- groups 8 through 11 One way outgoing- groups 12 through 16
The use of 'one way incoming' and 'one way outgoing' groups are for further study. The range of LCNs for 'two way' will be contiguous from the lowest. The range size will be a subscription time option. The DCE will allocate LCNs is ascending order. The DTE is recommended to allocate LCNs in descending order. PVC LCNs between an IBM SNA node and a switch will be the same as the SNA network number of the local SNA network. (See 'Use of SNA on the EARN X.25 infrastructure). In brief, the network number will be obtained by listing all the EARN countries in alphabetic order of their two character ISO country code and then numbering then from 1 upwards). The PVC number between switches will be the 'lowest SNA network number'*32+'highest SNA network number'. The allocation of PVC logical channel numbers for other purposes, for example DECNET, is for further study.
The CCITT X.121 Recommendation will be used.
DTE number will be:-
+------------+----------------------------------------------------+ | DNIC | NTN (Network Terminal Number) | | 4 +-----------------+---------------+------------------+ | digits |4 digit site code|4 digit machine|2 digit subaddress| +------------+-----------------+---------------+------------------+
The DNIC shall be the three digit country code as specified by CCITT followed by a digit to be selected by the country but 0 is recommended.
It is recommended that the '4 digit site code' should be selected by the country and that it is based on telephone area codes.
It is recommended that the '4 digit machine' should be selected by the site but a country may wish to impose further recommendations.
The optional '2 digit subaddress' will not be policed by the network and the use to which these digits are put is not defined.
The DTE numbers shall be registered with a network management centre.
Countries will connect to the X.25 infrastructure in one of the following ways:-
For interim periods countries may have more than one connection to the X.25 infrastructure to enable any transitions to be safely accomplished.
Permanent multiple connections from a country to a switch will require finance for relevant additional equipment from the country.
1/4 man year is required at each switch site which will ensure the switches are operational and will manage any required reconfiguration of hardware.
One man year is required at the management centre which will monitor performance, provide statistics, re-configure software, allocate DTE numbers.
Some manpower will be required at sites which do not have SNA or X.25 expertise.
Capital Recurrent
UKL UKL
Four switches at 10000 UKL each 40000 4000
Line to complete square (assuming
current proposed changes take place) 20000
1/4 man year switch support per site 30000
One man year network management centre 30000
Costs for connection of computers and other equipment to the infrastructure will be met from national resources. This will include any international line changes.
The finance required will depend on the supplier. An estimate is that the cost of connections should be the leased line costs plus 4000UKL. This estimate is based on the cost of private switches doubled to take account of their management.
The actions required to implement the the X.25 infrastructure are:-
The actions required for the provision of the X.25 infrastructure are:
Country ISO 3166 2 and ISO 3166 X.121
3 character code number DNIC
Austria AT AUT 040 232
Republic of Austria
Belgium BE BEL 056 206
Kingdom of Belgium
Denmark DK DNK 208 238
Kingdom of Denmark
Finland FI FIN 246 244
Republic of Finland
France FR FRA 250 208
French Republic
Germany DE DEU 280 262
Federal Republic of Germany
Greece GR GRC 300 202
Hellenic Republic
Ireland IE IRL 372 272
-
Israel IL ISR 376 425
State of Israel
Italy IT ITA 380 222
Italian Republic
Ivory Coast CI CIV 384 612
Republic of the Ivory Coast
Luxemburg LU LUX 442 270
Grand Duchy of Luxembourg
Netherlands NL NLD 528 204
Kingdom of Netherlands
Norway NO NOR 578 242
Kingdom of Norway
Portugal PT PRT 620 268
Portuguese Republic
Spain ES ESP 724 214
Spanish State
Sweden SE SWE 752 240
Kingdom of Sweden
Switzerland CH CHE 756 228
Swiss Confederation
Turkey TR TUR 792 286
Republic of Turkey
United Kingdom GB GBR 826 234
The United Kingdom of Great Britain and Northern Ireland
As agreed I have amended the draft proposal for an X.25 experiment between RAL and Nijmegen.
EARN is proposing to undertake a transition to ISO protocols from 1988 onwards. This involves either:
or:
It is expected that DEC will finance the switches at the four sites and the 64K lines or part of them - or contribute to the supplier provided infrastructure.
The EARN transition strategy is defined in a paper presented to the EARN Board of Directors at their meeting in Nice in spring 1987.
A further detailed elaboration of the strategy was considered at a meeting in Perugia when further developments were made.
The transition project has now been split into a number of sub projects. The first defines the X.25 infrastructure and the second the use of NJE/SNA/X.25 which are the minimum requirements for the provision of a service.
The technical detail will depend of whether the community or other supplier provides the network.
A 64K digital connection will be installed between Rutherford and Nijmegen. It is expected that DEC will finance this line as part of their support of the EARN transition.
Rutherford will loan an X.25 switch (the existing Telepac switch which meets the technical requirements) if switches are not obtained as part of the project by the time the line is delivered.
The switch will be replaced by EARN supplied switches which are expected to be financed by DEC. This will be delayed by the requirement for a tender exercise before purchase.
The line will become an integral part of EARN (in the EARN tables) once confidence has been established.
A suitable supplier will be identified. The supplier will need to be agreed by EARN for the complete network as it will be counter productive if the pilot project uses a different supplier to the final network.
An important aspect of the project will be to evaluate the performance of the supplier to confirm that he can provide the infrastructure.
The Rutherford and Nijmegen IBM VM systems will be connected to the switch. The machines will utilise RSCS V2/SNA/X.25.
After initial tests the connection will carry the Nijmegen/Rutherford traffic.
The DTE addresses for Rutherford machines will be 23400009xxxx?? . The Rutherford IBM computer will be 23400009000000. The DTE addresses for Nijmegen will be 204xxxxxxxxxxx .
Section 3.1 through 3.3 are only relevant for a community provided infrastructure and section 3.4 if from a supplier.
3.1 Possible loan of switch.
3.2 Setting up of switch. An operator is being trained to set up the Telepac switch and this will not involve more than a few days effort.
3.3 Negotiation for line with BT and Nijmegen. One man week. (Roland Brandwood). The UK cost of the line is 25375 UKL per year plus 750 UKL. Delivery is 4 months.
3.4 Evaluation of suppliers and negotiation for a connection.
3.4 Mounting of SNA/X.25. This is under way as part of the project to mount VMNCP over VTAM. (Peter Girard)
3.5 Mounting of RSCS V2. This is under way for the current EARN connection. (J Wood)
3.6 Mounting of RSCS V2 over VTAM and use of SNI addressing. IBM help is expected. Co-operation with Nijmegen will reduce the effort needed. Best estimates indicate that one man week will be needed. (Peter Girard).
3.7 Monitoring and report production. This will be provided by various people and take one man month (Paul Bryant, Peter Girard, Mick Reid, and Philip Overy).
3.8 Three visits to Nijmegen should be allowed for.
5.1 Finalise proposal.
5.2 Agree project with sites.
5.3 Agree project with EARN executive.
5.4 Negotiate for support with DEC.
5.5 Project start (guess February 1988).
5.6 Order line or service.
5.7 Delivery of line (August 1988). BT claim 4 months, Dutch PTT claim 6 months.
5.8 Experimental service (September 1988)
5.9 Service use (October 1988)
5.10 Replacement of switch if required (? 1988)
6.1 RAL and UK will retain a leading position in EARN.
6.2 RAL will be provided with an improving service to EARN.
6.3 It is expected that the connection will also provide a direct connection into JANET when compatible protocols are available in UK and the Netherlands.
6.4 The Netherlands is the centre of UUCP network connections and the connection will provide a better connection to UUCP for the UK assuming that any regulatory problems can be overcome.
This document is incomplete and is released for the purpose of the topology working party and should be used for no other purpose.
The transition of EARN to use ISO protocols is split into four parts:-
Part 1 - Earn X.25 infrastructure.
Part 2 - NJE over X.25.
Part 3 - X.400
Part 4 - FTAM, VTP, and JTM
This document is part 1 of this series.
The line topology is shown in figure 1.
Stockholm---n------+
Nijmegen*-n--+ Reykjavik---------+|
Brussels*-n-+| Trondheim---n----+||
Dublin-----+|| Helsinki----n---+|||
||| ||||
RAL*-----------------------------Copenhagen*
\ /
\ /
\ n
\ /
\ /
/ \
/ \
/ \
/ \
/ \
Montpellier*---------------------CERN*
||||||||| ||
Barcelona*-+|||||||| |+-n----Vienna
Abidjan*----+||||||| +--n----Bonn*
Lisbon----n--+|||||+------------------------------------+
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa*------------+| Washington
|
|
Cuny
Fig.2 X.25 infrastructure
n=relocated lines
*=sites with VTAM, note at CERN VTAM is not on CEARN.
Switches will be located at RAL, Copenhagen, CERN, and Montpellier.
Initially and where possible existing lines will be used at the existing speeds. The connections between RAL, Copenhagen, CERN, and Montpellier will be replaced by 64K connections as soon as lines are available from the PTTs and finance is available.
The initial lines will include the lines between the switch sites.
The remainder of the connections will be required as and when the countries decide to join the infrastructure.
The requirements for an X.25 switch are:
The LCN allocation will be:
Permanent virtual circuits- groups 0 through 3 One way incoming- groups 4 through 7 Two way- groups 8 through 11 One way outgoing- groups 12 through 16
The use of 'one way incoming' and 'one way outgoing' groups are for further study. The range of LCNs for 'two way' will be contiguous from the lowest. The range size will be a subscription time option. The DCE will allocate LCNs is ascending order. The DTE is recommended to allocate LCNs in descending order. PVC LCNs between an IBM SNA node and a switch will be the same as the SNA network number of the local SNA network. (See 'Use of SNA on the EARN X.25 infrastructure). In brief, the network number will be obtained by listing all the EARN countries in alphabetic order of their two character ISO country code and then numbering then from 1 upwards). The PVC number between switches will be the 'lowest SNA network number'*32+'highest SNA network number'. The allocation of PVC logical channel numbers for other purposes, for example DECNET, is for further study.
The CCITT X.121 Recommendation will be used.
DTE number will be:-
+------------+----------------------------------------------------+ | DNIC | NTN (Network Terminal Number) | | 4 +-----------------+---------------+------------------+ | digits |4 digit site code|4 digit machine|2 digit subaddress| +------------+-----------------+---------------+------------------+
The DNIC shall be the three digit country code as specified by CCITT followed by a digit to be selected by the country but 0 is recommended.
It is recommended that the '4 digit site code' should be selected by the country and that it is based on telephone area codes.
It is recommended that the '4 digit machine' should be selected by the site but a country may wish to impose further recommendations.
The optional '2 digit subaddress' will not be policed by the network and the use to which these digits are put is not defined.
The DTE numbers shall be registered with a network management centre.
Countries will connect to the X.25 infrastructure in one of the following ways:-
For interim periods countries may have more than one connection to the X.25 infrastructure to enable any transitions to be safely accomplished.
Permanent multiple connections from a country to a switch will require finance for relevant additional equipment from the country.
1/4 man year is required at each switch site which will ensure the switches are operational and will manage any required reconfiguration of hardware.
One man year is required at the management centre which will monitor performance, provide statistics, re-configure software, allocate DTE numbers.
Capital Recurrent
UKL UKL
Four switches at 10000 UKL each 40000 4000
Line to complete square (assuming
current proposed changes take place) 20000
1/4 man year switch support per site 30000
One man year network management centre 30000
Costs for connection of computers and other equipment to the infrastructure will be met from national resources. This will include any international line changes.
The actions required to implement the the X.25 infrastructure are:-
Country ISO 3166 2 and ISO 3166 X.121
3 character code number DNIC
Austria AT AUT 040 232
Republic of Austria
Belgium BE BEL 056 206
Kingdom of Belgium
Denmark DK DNK 208 238
Kingdom of Denmark
Finland FI FIN 246 244
Republic of Finland
France FR FRA 250 208
French Republic
Germany DE DEU 280 262
Federal Republic of Germany
Greece GR GRC 300 202
Hellenic Republic
Ireland IE IRL 372 272
-
Israel IL ISR 376 425
State of Israel
Italy IT ITA 380 222
Italian Republic
Ivory Coast CI CIV 384 612
Republic of the Ivory Coast
Luxemburg LU LUX 442 270
Grand Duchy of Luxembourg
Netherlands NL NLD 528 204
Kingdom of Netherlands
Norway NO NOR 578 242
Kingdom of Norway
Portugal PT PRT 620 268
Portuguese Republic
Spain ES ESP 724 214
Spanish State
Sweden SE SWE 752 240
Kingdom of Sweden
Switzerland CH CHE 756 228
Swiss Confederation
Turkey TR TUR 792 286
Republic of Turkey
United Kingdom GB GBR 826 234
The United Kingdom of Great Britain and Northern Ireland
This is the final document from the working party on EARN. It defines how EARN should be provided as a service and also how to provide a mail service. NTMPC is invited to endorse the recommendations and submit the document to TMPC.
This paper defines the work needed to provide a "service gateway" between EARN and JANET and provide improved mail services. It defines a FYFL for manpower.
Implementation of the recommendations may depend on agreements between the Central Computing Department and other interested parties.
The current service based on RSCS V1 is satisfactory.
The manpower required to maintain RSCS V1 over and above its maintenance in the absence of EARN is 0.2 MY per year.
It is desirable to move to RSCS V2 in order to keep in line with IBM developments. The effort required over and above normal maintenance is 0.2 MY once off. It is expected that this should be complete by mid February depending on CP4.
The manpower to maintain RSCS V2 over and above its maintenance in the absence of EARN is as for V1 at 0.2 MY per year. There should be no overlap for maintenance.
The total recurrent manpower is 0.2 MY.
The total once off manpower is 0.2 MY.
The file transfer service is satisfactory and no changes are envisaged.
The mail gateway code is deficient in the following areas:-
Domain reversal in the JANET to EARN direction for the first % component is not dealt with correctly. In addition, domain reversal should be dealt with more flexibly to allow for users making mistakes. The effort required to correct this is 0.1 MY once off.
The mail gateway is inefficient. A study of the inefficiency has not been carried out but it is known that tables are searched linearly. Also it would be more efficient to combine the gateway into a single process. The MAILER can now deal with "real" names. Thus it could take the place of the GEC mail system. However, this is unsatisfactory as the code is inefficient and should be improved. The production of the list of names should be via the site personnel data base. The development effort required is 0.5 MY once off. This is a token pending a detailed study.
Distribution lists are now available via LISTSERV. This system has not been exploited due to lack of effort. The effort required to bring LISTSERV into use is 0.2 MY once off. The recurrent effort required is 0.2 MY per year but there will be a saving in that the GEC distribution lists will not need maintenance.
New MAILERS should be adopted as soon as they are made available. This is now a straight forward task requiring little expertise. The recurrent effort required is 0.1 MY per year.
The total once off effort is 0.8 MY.
The total recurrent effort is 0.3 MY per year.
The Rice mail interface should be supported. User support can be provided by the current support staff at no extra effort as the system is already in use from UDISK.
The latest Rice mail interface should always be used. The recurrent effort to mount the latest versions is trivial and there may never be another version.
Work is in progress to correct faults in the current system. This should take 0.1 MY once off. Any further developments await further requirements.
There would be advantage in all grey book mail passing through the mail service provided by the Crosswell Mailer. This will give automatic access to the name list and the distribution lists. The effect of this will be to make mail slightly more inefficient and will make mail service a more important system. Currently there is great confusion between the mail addresses UK.AC.RL.IB and UK.AC.RL.EARN and the use of the mail service as suggested will make the two addresses identical.
Use of the Rice mail interface should be encouraged as this provides a more satisfactory interface to RFC 822 (Grey Book and EARN) mail systems.
The NOTE command should send Grey Book mail through the mail service. The code for this exists. Incoming mail should be directed to the mail system.
Distribution lists should be moved from RL.GB to LISTSERV and support provided.
RAL (P Bryant) takes part in the planning for EARNs transition and this absorbs 0.1 MY per year.
Preliminary planning is going on for a pilot EARN X.25 connection to xxxxxxxx. This will hopefully be funded by DEC. The requirements on RAL will be:
Thus, equipment costs are zero or (IBM costs awaited). The manpower costs are not yet clear but are estimated at 0.2 MY for SNA/X.25, 0.1 MY for provision of lines and connections, and 0.1 MY for management.
The involvement with EARN migration is carried forward into subsequent years to cover the effort needed during EARNs full transition.
Recurrent effort 0.5 MY per year.
User support of EARN requires 0.8 MY per year. This is required on a continual basis. It is difficult to differentiate between the user support of EARN and other network services.
This is supported by IBM for 1988 at the rate of 1 man year. However, this includes some management tasks concerned with the maintenance of the EARN membership lists and running meetings which will no longer be required.
Running EARN involves some operator effort which is estimated at 0.1 MY per year.
The management of EARN is estimated at 4 man months and includes the optional involvement with the EARN Board, Executive, and Technical group. This line was eliminated from the request for funds from JNT and RAL should attempt to reinstate this in future.
Manpower required for EARN and mail support in man years
+-------------------+---------+---------+---------+---------+---------+
| |1988 |1989 |1990 |1991 |1992 |
+-------------------+---------+---------+---------+---------+---------+
|User support |1 (1) |1 |1 |1 |1 |
|and LISTSERV (EARN)| | | | | |
|MAILER development |0.2 |0 |0 |0 |0 |
| (EARN)| | | | | |
|MAILER development |0.6 |0 |0 |0 |0 |
| (RAL) | | | | | |
|RSCS maintenance |0.2 |0.2 |0.2 |0.2 |0.2 |
| (EARN)| | | | | |
|MAILER maintenance |0.1 |0.1 |0.1 |0.1 |0.1 |
| (RAL) | | | | | |
|Statistics |0.1 |0 |0 |0 |0 |
| | | | | | |
|Transition |0.5 (2) |0.5 |0.5 |0.5 |0.5 |
| (EARN)| | | | | |
|EARN management |0.4 |0.4 |0.4 |0.4 |0.4 |
| (EARN)| | | | | |
|Operations |0.1 |0.1 |0.1 |0.1 |0.1 |
| (EARN)| | | | | |
+-------------------+---------+---------+---------+---------+---------+
|Total (EARN)|2.5 |2.2 |2.2 |2.2 |2.2 |
| | | | | | |
|Total (RAL) |0.7 |0.1 |0.1 |0.1 |0.1 |
| | | | | | |
+-------------------+---------+---------+---------+---------+---------+
(1) Financed by IBM in 1988.
(2) 0.4 MY is subject to the transition pilot project being accepted.
+-------+ .
|(Lists)| .
| | .
| | .
+---+---+ .
+-------<--+ .
| | .
+-------+-------+ | . +-------+ +-------+
| | | . |(Users)| |(Users)|
EARN--+LISTSERV | | . |MAIL | | |
| | | . | | |NOTE |
+-------+-------+ | . +---+---+ +---+---+
| | . | FTP
| | . | |
+-------+-------+-<+------<---+-------+-------+ +---+---+
| | . | | |
EARN--+MAILER +-----------+EMAILDEV +--FTPR--+FTP+--JANET
| | . | | | |
+-----------------+ . +-------------+ +---------+
: . :
: . :
+---------------+ . :
|NETSERV | . (Udr File)
EARN--+(Domain Names) | . (Vmncp Titles)
|(Xmailer Names)| .
|(Mailer Names) | .
+---------------+ .
.
EARN Domain . JANET Domain
Current structure of EARN/JANET mail relay
+-------+ . +-------+
|(Lists)| . |(Lists)|
|(EARN) | . |(JANET)|
| | . | |
+---+---+ . +---+---+
+-------<---+ . +-->-------+
| | . | |
+-------+-------+ | . | +-------+-------+ +-------+
| | | . | | | |(Users)|
EARN--+LISTSERV +-------------+LISTSERV | |MAIL or|
|(EARN) | | . | |(JANET) | |NOTE |
+-------+-------+ | . | +-------+-------+ +----+-------+
| | . | | |
| | . | | |
+-------+-------+--+ . +--+-------+-------+---+ +-------+
| | . | | | |
EARN--+MAILER +--------------+EMAILDEV +--FTPR--+FTP +--JANET
| | . | | | |
+------------------+ . +---------------+ +---------+
: . :
: . :
+---------------+ . :
|NETSERV | . (Udr File)...............(Personnel
EARN--+(Domain Names) | . (Vmncp Titles) data base)
|(Xmailer Names)| .
|(Mailer Names) | .
+---------------+ .
.
EARN Domain . JANET Domain
Proposed structure of EARN/JANET mail relay
The financial requirements from 1988/9 are the line costs for Geneva and the contribution to the USA line.
The line costs are likely to rise from 1990 if EARN decides to install 64K lines and when DEC withdraw their possible support of the X.25 infrastructure. In addition EARN may alter its funding model. As a token half the cost of the 64K line to xxxxxxxx is shown in 1990 and the full cost from 1991.
Computing resources are shown as 56 UKL which is an estimate of the 1987 spend. This will reduce from 1989 onwards as the EARN transition causes more traffic to by-pass the IBM computer. In addition the 1988 cost will be lower due to the removal of the CERN HEP traffic from the EARN line.
In 1989/90 EARN will change its funding mechanisms to support the permanent staff which now number 3 and may rise to 6. A token contribution of 15k is shown which is calculated from 30k per man and the UK contribution according to the RARE key.
Financial requirements for EARN in K UKL
+-------------------+---------+---------+---------+---------+---------+
| |1988 |1989 |1990 |1991 |1992 |
+-------------------+---------+---------+---------+---------+---------+
|Line cost CERN |30.65 |30.65 |30.65 |30.65 |30.65 |
| | | | | | |
|Contribution USA |8.27 |8.27 |8.27 |8.27 |8.27 |
|line | | | | | |
|64K X.25 line (1) |0 |12.69 |25.38 |25.38 |25.38 |
| | | | | | |
|Upgrade to 3725 |2.5 |0 |0 |0 |0 |
| | | | | | |
|Maintenance 3725 |5 |5 |5 |5 |5 |
|and modems | | | | | |
|Computing costs |56 (2) |56 |56 |56 |56 |
| | | | | | |
|Contribution EARN |0 |15 |15 |15 |15 |
|management | | | | | |
+-------------------+---------+---------+---------+---------+---------+
|Total |102.42 |127.61 |140.31 |140.31 |140.31 |
| | | | | | |
+-------------------+---------+---------+---------+---------+---------+
(1) This is the cost for the UK part of the line. Assume pay 50% in 1989
(2) This is the cost of operating the mailers which absorb 400 AUs per month
at 20 UKL per AU. Speculative reductions due to loss of HEP traffic and
transition as well as increases due to traffic increases are not allowed for.
Income from funding bodies (1)
+-------------------+---------+---------+---------+---------+---------+
| |1988 |1989 |1990 |1991 |1992 |
+-------------------+---------+---------+---------+---------+---------+
|Nuclear Physics |18 |(2) |(2) |(2) |(2) |
|Computer Board |37 |(2) |(2) |(2) |(2) |
|ASP |5 |(2) |(2) |(2) |(2) |
|Others |0 |(2) |(2) |(2) |(2) |
+-------------------+---------+---------+---------+---------+---------+
|Total |60 |76 (3) |76 |76 |76 |
+-------------------+---------+---------+---------+---------+---------+
(1) The income will be collected by JNT. Line costs will be paid directly
by JNT and manpower recharged to JNT.
(2) These figures will depend on usage.
(3) This figure reflects the withdrawal of user support by IBM but does
not include the speculative contribution to EARN manpower to EARN
transition shown in the expenditure.