Paul Bryant's Networking Correspondence
Currently EARN is controlled by its members. It is their privilege to decide how they would like to approach the problem of providing the funds required. A number of options have been explored and are put before the meeting.
It is vital that a funding strategy is decided on so that it can be pursued and the continuance of EARN UK assured.
Certainly IBM will be providing no further funds although we must be grateful for the funds they have already provided.
Other commercial concerns could be approached but it is unlikely that they would be inclined to help.
Members could be approached for a membership fee.
Since the network benefits SERC it would be appropriate to approach them.
The network also benefits university staff and so the Computer Board is a possible source.
The funds required to continue the present arrangements and gateway service for 1988 are:-
Line cost to CERN (varies with Swiss Franc, inc.VAT) 30653
Or line cost to Montpellier (varies with French Franc,
inc. VAT) 20558
Cost of USA line to Darmstadt 69215 (2)
Cost of USA line to Montpellier (provided by IBM) not known(1)
Contribution to EARN association (provided by IBM) not known(1)
User support 1/2 man (provided by IBM) 11800 (1)(3)
Meeting organisation etc. 1/2 man (provided by IBM) 11800 (1)(3)
Software maintenance 1/2 man 15267 (3)
Management 1 month 4238 (3)
EARN Executive/Technical Director 4 months (avoidable) 16951 (3)
Computer resources (token estimate) 2500
Total for 1988 approximately (CERN line) 69609
or (Montpellier line) 59514
(1) These costs have not been included in the total as they will not be paid in 1988 but must be taken account of in 1989.
(2) The way the cost of the Darmstadt-USA link will be split between the countries is undecided. This is not included in the total.
(3) The manpower costs are according to the full economic recovery costs Rutherford would charge customers and depend on the grades involved.
Additional manpower may be required if the funding bodies require further accounting and control software.
The UK takes a very active part in the management of EARN and provides an Executive member and the Technical Co-ordinator, this takes 4 man months of effort. Much of the work is involved with the migration of EARN to ISO protocols. The management line could be reduced significantly if the UK withdrew from this activity.
The gateway is fairly crude and does not contain accounting and control software. This means that charging on a per user, per file, or per volume basic is not in place. Such software could be developed at the cost of a man year. Such a development has to be set against the EARN migration plans which would give such software a short life expectancy. The collection of charges would itself cost resources which would have to be added to any tariff.
The costs of EARN are fixed. If a per user, per file, or per volume charge were introduced then there would be no guarantee that the cost of the gateway could be recovered or that Rutherford would not make a profit.
EARN has produced a funding document (attached). This indicates that the UK will have to contribute to the inter-continental links to the USA and the EARN management costs but the full cost will probably not be in 1988 due to the residual IBM support. As yet these costs are unknown. The favoured model is that the UK will have to pay for one international line (RL to CERN or Montpellier) for 1988.
There are three basic funding models:
It would be possible to initiate a membership fee which, with the 50 or so members would work out about 1000 pounds each assuming no sites left.
It could be argued that SERC should pay a rather higher fee as half the traffic is attributable to HEP/CERN activities. Thus one could argue for the membership fee to be nearer 500 pounds.
The model could preserve the membership's right to determine the future of EARN in the UK.
Negotiations would have to take place between EARN, SERC, and the computer board. It would not seem unreasonable for the cost to be split equally between the bodies.
As a result of such funding SERC and the Computer Board may wish to obtain some management control of the EARN activities. Certainly they would require some figures on the use of the network and these are becoming available. It would be possible to fix the costs with respect to the historic use of the network.
It is uncertain to what extent the membership will retain control of the activities.
The Network Executive would welcome the opportunity of assuming the management responsibility for UK EARN. They would be likely to favour the third form of funding model defined above, and intend to define their proposals during the summer after the costs have been estimated more precisely. The method of cost recovery could include an element based on volume related charges. If these proposals are accepted the Network Executive would become responsible for the EARN gateway and the current membership would probably either make their views felt via the JANET user groups or via some advisory body. It is likely that the actual operation of the gateway would be contracted to Rutherford.
It would also be possible for Rutherford to operate such a scheme with the membership retaining management control. It is unclear whether Rutherford would support this.
Regardless of the management responsibility, software to identify use with funding bodies would require a man year of effort. Current software only monitors the source and sink addresses as well as volumes, thus some registration scheme would be needed to relate these to user groups. Software would also be needed to prevent use by un-registered users.
There has been some pressure from the JANET user groups for the network executive to take a greater interest in the management and funding of the various gateways into JANET. Historically these gateways have been developed by site initiatives. Not surprisingly all these gateways are concerned at the resources such activities absorb as they mature and provide large scale services.
The issues are made complicated by the EARN policy to migrate to ISO protocols.
The results of this policy are:-
A conclusion from this uncertain future is that the exact nature of funding should be considered on a short term basis (say 2 years) since the technology changes will effect the funding model in ways which have yet to be determined.
Dear Mr Wright,
Thanks for your letter and our telephone conversation.
I now understand that the connection of the ECMRWF to EARN requires a licence. I would therefore ask you to consider the provision of such a licence.
The diagram below shows the nature of the connection. All the connections apart from the one to ECMRWF already exist.
+--------+
| ECMRWF |
+--------+
|
|
+---------------+ +---------------------------------+ +--------------+
| JANET network |---| Gateway 3 Rutherford EARN node |---| EARN network |
+---------------+ +---------------------------------+ +--------------+
It is proposed that the ECMRWF will be an integral part of EARN by virtue of its direct connection to the Rutherford EARN node (which is already an integral part of EARN). The connection is required to enable ECMRWF to communicate with a number of European institutions with which they have research connections. The traffic will be of a non commercial nature.
ECMRWF is an institute set up by treaty between the European countries. You may wish to investigate their status further. If so please contact:
Geerd-R Hoffmann Head, Computing Division European Centre for Medium Range Weather Forecasting Shinfield Park Reading RG2 9AX.
Yours sincerely
Paul Bryant.
Dear Mr. Geerd-R. Hoffmann,
I have now received a letter from DTI concerning your proposed connection to EARN and have spoken with them. I now understand that the current EARN licence cannot be extended to cover your connection and that a separate licence will be required.
I have, therefore, now made application for this licence. This will involve you in a small fee which has yet to be determined but I can tell you that the original EARN licence was 250 pounds. Mr. Mike Wright of DTI may be in touch with you if he has any questions concerning your status. His address is -
Room 517
1-19 Victoria Street
London SW1H OET.
Yours sincerely
Paul Bryant.
Dear EARN member,
The EARN Board of Directors has now agreed its finances for the calendar year 1988.
In brief, this requires the UK to pay for the leased line to CERN and a proportion of the transatlantic line between Montpellier and City University New York. For 1988 no further expenditure is demanded by the Board.
At the UK EARN members meeting the decision of the EARN Board of Directors was endorsed.
The UK will also have to pay any costs within the UK such as manpower, equipment maintenance and so on.
The UK members meeting considered carefully how EARN should be financed within the UK. The meeting was aware of the discussions within the JANETNational Advisory Committee (NAC) which advocated far closer co-operation between gateway providers and JANET management. This had led to a suggestion from JNT that EARN should come under the control of the NAC and that JNT would prepare a proposal for funding from the various interested bodies for presentation to the NAC. The meeting felt that any other avenues of funding would be unlikely to succeed and therefore agreed to this strategy.
The meeting recognised that the strategy would entail ceding management control of EARN UK to the NAC and felt that before this was done they should have an opportunity to consider such a proposal when complete. A final decision on the basis of a proposal should be taken at the next EARN UK membership meeting on November 5. They considered and agreed a list of recommendations which they felt would ensure the interests of the users would be preserved and should be incorporated in a proposal.
The document for consideration by JNT and the NAC is appended.
Since this is an important step I am circulating this to all members for urgent consideration. I regret that the deadline for comment is short as the next NAC meeting is on 9 June.
I hope that you are in agreement with the decisions of the EARN UK users meeting. I look forward to your comments and will be happy to discuss any questions you may have
Yours sincerely
Paul Bryant.
The EARN membership meeting of 27 May 1987 considered the funding of EARN UK for the calendar year 1988 and made the following agreements and recommendations.
The EARN funding decision reached at the EARN Board of Directors meeting held in Nice 21/22 May 1987 was endorsed. This commits the UK to:-
It was agreed that the management responsibility for EARN UK should be ceded to the NAC on the basis that this would be in the best interests of the EARN users and ensure funding for the calendar year 1988. It was agreed that a formal decision should be taken at the EARN membership meeting to be held 5 November after due consideration of proposals for the funding and management. If agreement is reached then the NAC should take management responsibility from 1 January 1988.
It was recommended that the EARN UK membership meeting should be reconstituted as an EARN users meeting with appropriate representation on the NAC from 1 January 1988.
It was recommended that the EARN users meeting should propose the EARN Board of Director's member. It is understood that Board of Director members are normally elected by the membership within a country. Since the basis of membership is likely to change within the UK an appropriate agreement needs to be reached with the EARN Board of Directors to define the meaning of 'membership' within the UK.
It is recommended that EARN UK remains an open network as long as volume charges are not imposed by the PTTs which the UK will have to meet. This implies that charges and authorisation are not reflected to the individual user.
The costs of operating EARN in the UK in 1988 were noted are are:
Line cost to CERN (varies with Swiss Frank, inc.VAT) 30653UKL
10% contingency 3065UKL
Line cost Montpellier-CUNY 847200FF (varies with the
French Frank)
UK contribution 8.6%847200FF 7511UKL
10% contingency 751UKL
Software maintenance and development 15267UKL (1)
Management 1 month 4238UKL (1)
EARN executive technical Director 4 months 16951UKL (1)(2)
Computer resources (token estimate) 2500UKL
Total 80936UKL
(1) The manpower costs are according to the full economic recovery costs Rutherford would charge and depend on the grades currently employed. If Rutherford agreed to use the rates charged to Government departments the costs would reduce to 11050, 2930, and 11721 UKL respectively giving a total of 70181UKL.
(2) UK is not obliged to supply the EARN Technical Director which is an EARN Executive appointment which is made on an annual basis. Current work is mainly in the area of migration of EARN to ISO protocols which is thought to be in the UK interests.
It is noted that the costs shown enable EARN to operate in its current mode. Should the funding bodies, NAC, or JNT require changes in the mode of operation, for example to produce accounts, then this would have to be costed when such requirements are known.
It is noted that user support is financed by IBM until the end of 1988 at the level of one man.
This is confidential from the point of view that it makes some rather candid comments on the proceedings.
1. Minutes. I arrived after this item.
2. Liaison - CEPT, SPAN, EUNET. A meeting is to be held between EARN and CEPT to consider items of mutual interest (tariffs). CEPT had originally tried to make this an EARN, CEPT, RARE meeting but this was not in accordance with the original discussions and it was felt that there were matters that did not concern RARE. A RARE, CEPT, EARN meeting will be held the same day. Joe Chester has attended 3 SPAN meetings. It is hoped that there will be some co-operation in future. There is likely to be opportunities for co-operation since EUNET is about to start testing X.25 switches. (This was news to me, I do not believe that this is imminent).
3. Finance. O dear, what a cock up!. Jean-Claude was asked to produce the audited accounts and a budget. He brought these to the meeting. The accounts for 1985/6/7 were single sheets of paper just saying the figures balanced with absolutely no detail. The budget was little better. The meeting was quite kind to J-C but the BOD meeting the next day gave him a hard ride. The accounts for 1985/6 were accepted and the ones for 1987 were noted and sent back for some detail. I am amazed that J-C, who runs a very large computing lab is totally incapable of producing a budget and FYFL. I am embarrassed since JNT is continually asking me how much money is wanted in future. I am pressing very hard for sensible figures.
The trans-national payments were sorted out. EARN will send an invoice to each country for the USA line for payment on Jan 1. I shall probably not pay this so that RAL can decide whether to pay it this or next financial year.
Regretfully (see below) RAL will not be moving its line to Montpellier. Also I have no finance for the first quarter 7.5K. About 2K has been raised from maintenance from IBM. I think RAL will turn a blind eye.
Payments for the other lines will be arranged between countries.
4 EARN 88. Arrangements going quite well. The programme is not yet complete.
5 Migration. Here I tried to get the Executive to define the next step. As usual they are reluctant to make decisions and I had to put the words into their mouth which is not really satisfactory. I am insisting that when we meet DEC we go with some definitive plans otherwise the meeting will be fruitless. It seems DEC want to put some sort of team onto the project. See the end of this document for some further information.
6 Volume charging. The usual comments on the German problem. Michael Hebgen is very angry that EARN has done nothing until now (topology change). Dennis excused the Executive by saying this was to allow the German PTT a last chance but it is rather the difficulty of making decisions in EARN.
7 Topology. O what a lovely row! The topology group decided a topology in Paris. This showed the start of the X.25 'square' based on RAL, Copenhagen, CERN, and Montpellier. At Geneva the Executive (I did not attend and Birgitta did) this was changed by effectively replacing Copenhagen by Nijmegen. This was because Kees Neggers was invited to the Executive as he had made some comments that the Dutch PTT would host an EARN switch. At this executive Birgitta (and myself to a lesser extent) went 'up the wall' and there were many further meetings. Eventually a compromise on 'least change' was agreed. In fact Kees Neggers 'won' as you will see below. The whole episode left a very sour taste in my mouth as half the Exec do not know what was going on.
8 Technical group. The Lisbon meeting agenda was considered with little comment.
9 Press and Public relations. The various press releases were considered. We were asked to send them to papers in our countries. In my case I would be foolish to do so as RAL policy is to leave the press severely alone. Some of my colleagues (and myself) think that the press releases may well be counter productive.
10 Membership. We now expect applications from India, China, Hungary, and possibly Poland. It was agreed, not withstanding comments from Herb Budd, that we should proceed with these applications unless stopped by governments or other insuperable obstacles. Associate membership was considered and there is some friction as the membership committee and the administration seem to act independently.
11 UK double board member. There was a close study of the EARN Association rules and this does not seem to allow more than a single member per country. It was also clear that Dennis was not happy with the proposal. Hence I was not able to get an agreement. In discussions with Michael Hebgen it is clear that he has the same problem and we have agreed to consider further actions. I also raised the point that EARN UK now had no membership and we wanted JANET to be a corporate member. Despite me pointing out the ridiculous situation they decided to consider it at the next executive meeting.
12 Operating committee (I would call it a standing orders committee). Michael Hebgen is very keen on this. It is clear that the Executive and BOD have no standing orders and this makes decisions difficult to take as it is unclear what the procedures are. For example, Michael wants to define electronic voting methods. He also wants each board member to have a deputy who would vote in his absence. (This gives me an idea - we could use this device to allow you and me to be effective joint BOD members especially as EARN will now invite observers from national networks to attend meetings). If we take the EARN rules seriously the UK is not entitles to be a members we do not allow the membership to elect a BOD member. In fact we have no membership. We could take the attitude that the UK has only one member (RAL) as the rest of the UK is only connected via a relay. Thus RAL could appoint the BOD member with its single vote. We must talk about this.
Board meeting (copy of notes from Joe Chester with comments)
Minutes- approved
Migration - Report on DEC support accepted
- EARN network enhancement and OSI integration strategy
approved (that's my Valencia paper). (I wish I knew what
'integration' meant).
- Report of Technical Group (Perugia) endorsed. (Difficult as
there was some disagreement).
- Executive Committee to present detailed implementation plan
for the next meeting (that's if I get round to producing it).
- Interim stage to be implemented if and where possible (Ah! the trap door - see below).
Management report endorsed - (This was verbal)
Operating procedures - Electronic Voting Procedures adopted
- Representation by deputy adopted
- Only financial documents confidential.
Publicity - Annual report by December 1 agreed
- Action to improve (stop in my case) press relations at
country level to be investigated.
Development strategy - Comment by Board Members by December 31. (This
was a terrible paper from Joe Chester).
It stating objectives such as 1000 associate
members. This paper must be stopped as it will
cause a lot of problems ).
Volume charging - Report of Executive Committee endorsed, action to
continue to seek elimination in co-operation
with other organisations.
Associate membership - Membership committee report endorsed (there
wasn't one). Membership of committee to
remain as at present. Annual membership
agreed - to be implemented at country level.
(No level of fee was fixed).
Membership - 4 new countries elected
Hungary and China position to be addressed by the
President.
Bitnet report endorsed (this was verbal and content free).
Topology - Interim topology agreed (after another first class row led by
Denmark this time). Action agreed to (a) develop a better
process for deciding topology (b) to prepare proposals for
a new topology for approval at the next meeting
Technical Group - Agenda for Lisbon meeting approved (but amended).
Finance- Auditors report 1985/6 adopted subject to additional
endorsements (don't ask me what endorsements).
Report for 1987 noted.
Report on legal requirements in France requested.
Report on presentation of budget requested (after a first
class argument on the one presented. This was led by
our Gnome of Zurich - Kurt Bourknet).
Agreed to prepare a detailed FYFL for circulation in Feb 88
Agreed details of trans-national payments for 1988
Review country arrangements for securing the required
line financing for 1988
EARN 88 - programme approved
Liaison - Report on a wide range of activities adopted, and approval
given to continue discussions.
I had a discussion with Kees Neggers. We have agreed to produce a proposal for a 64K X.25 EARN line between RAL and Nijmegan as part of the EARN migration. We expect the line to be financed by DEC. RAL will loan a switch until DEC provide the EARN switches. Dennis is broadly supportive. This is confidential until Kees and myself have produced the proposal and made sure we can do it. We shall have to talk to our managements but at this point it would cause embarrassment with other members if it were known we were doing this considering the topology row.
I hope you find this useful and I am happy to expand on any items that interest you.
Paul.
There have been a number of requests for changes to the EARN international topology each of which is justified in isolation.
The EARN transition proposal requires fairly major changes to the EARN topology.
The EARN transition proposal has not yet been agreed in detail and we therefore have the problem that line changes made now may be counter productive to the transition.
The current thinking is that there should four X.25 switches located at Rutherford, Stockholm, Montpellier, and CERN.
The current configuration is shown in Fig. 1 and the proposed one in Fig. 2. The style of the diagram is to emphasise the X.25 topology and to make clear the proposed changes. It should be noted that the proposed changes will make savings in line costs since high tariff or volume tariff countries tend to be avoided or have few connections. The topology is fairly similar to the so called 'leased cost' topology which was illustrated in the paper on EARN funding which was presented at the Nice EARN Board of Directors meeting.
I propose that the future changes to the EARN topology take account of the EARN transition proposal.
Reykjavik---------+
Trondheim--------+|
Dublin-----+ Helsinki--------+||
| |||
RAL----r--------+ Stockholm
| |
| |
| |
| |
Brussels-r----Paris | |
| | |
| | |
| | |
Lisbon | +----------------+|
| | ||
r Montpellier----------------------Geneva
| |||| | |
Barcelona--+||| | +-rx--Darmstadt
Abidjan-----+|| | ||||
|| | r||+rx-Vienna
|| | x|+rx--Copenhagen
|| | |+-rx--Nijmegen
|| | |
|| | Washington
|| |
|+-----------------------------Pisa
| ||||
CUNY |||+--rx--Heraklion
r|+---r---Izmir
x+----rx--Tel Aviv
|
CUNY
rx=lines scheduled for relocation, r=lines to be relocated for X.25
Copenhagen---n-----+
Nijmegen--n--+ Reykjavik---------+|
Brussels--n-+| Trondheim--------+||
Dublin-----+|| Helsinki--------+|||
||| ||||
RAL-----------n------------------Stockholm
| |
| |
| |
n |
| |
| |
| |
| |
| |
| |
Montpellier----------------------Geneva
|||||||| ||
Barcelona--+||||||| |+-n----Bonn
Abidjan-----+|||||| +--n----Vienna
Lisbon----n--+|||||
Heraklion-n---+||||
Izmir-----n----+||| ?
Tel Aviv--n-----+|| |
Pisa-------------+| Washington
|
|
Cuny
n=relocated lines
The main business of the meeting was the future of EARN in the UK and its funding.
It is well known that the funding for the EARN international lines from IBM ceases at the end of 1987. EARN has now decided that the UK will have to find the cost of the international line to CERN and a percentage of the line form Montpellier to the USA. In all 41K pounds.
The UK community has been concerned to bring the various gateways from JANET into some sort of order and are proposing that JANET takes a management interest in the gateways and that funding is provided by the various major groups. To this end Rutherford has been invited to estimate the UK EARN running costs apart from the line costs and these come to 40K pounds making a grand total of 81K pounds. This is the amount Rutherford will have to recover from the community.
The meeting gave the matter careful consideration and eventually felt that other funding options would be risky and asked Rutherford to proceed along the lines proposed by the JNT. They also made a number of recommendations on the operation of the service which they felt important. They expect a detailed proposal to be provided for their Autumn meeting when they will take a final decision on the future. If the proposal succeeds then the EARN membership meeting will become a special interest group under the NAC and will cease to have management powers.
Full details are in the minutes of the meeting and accompanying papers which are available from Rutherford.
The network has continued to provide a satisfactory service and has had a period of stability with no major changes. The volume of traffic has increased and during one month topped 1000Mbytes. The network itself has continues to grow and has 400 nodes in Europe and 1700 world wide.
EARN is planning to make a transition to use ISO protocols and planning documents are now becoming available. This transition is likely to start sometime in 1988. There are still many details to resolve but it appears that EARN will be running an international private X.25 network over which it will operate the current popular protocols. The ISO high level protocols will be introduced as suitable products become available. The main aim is to maintain and possible improve the current level of service.
EARN has produced a draft transition report and requests comment on all parts of it. This is to make sure ensure that the direction of development of EARN is technically in line with RARE/COSINE views. The period for comment depends on the particular topics but for X.25 implementation should take place in the first half of 1988 with decisions being taken very early in the year.
In the case of WG4 EARN is particularly interested in comments on the following topics:
EARN requests that WG4 address these and any other topics of interest in the appropriate sub-groups.
Paul Bryant - EARN Technical Director.
Thank you Michael for your reply to my comments on SNA.
It is not the 'religious' question of SNA that gives me concern. It is not the technical necessity or desirability of its use. My concern is the authority that the BOD has over the operation of our network. From a discussion with Peter Sylvester my concern has been increased.
I asked Peter to raise the technical issues of the use of SNA at the technical meeting. This he did not wish to do. Further more, he led me to understand that the protocols used between Bonn and Montpellier were a matter between Bonn and Montpellier and were of no concern to the Technical Group, the Executive, or the BOD. He views the network as having decentralised management. If this is the situation then I am gravely concerned over the future of our network in that it will not be possible to have any control over its development, quality of service, or range of services as far as the BOD is concerned.
I firmly believe that a successful network must have good central operational management regardless of the technology used and the use to which the network is put. Without this I do not believe we can make plans for the future on behalf of our users.
My concern over the proposed SNA connections between Bonn, Pisa, and Montpellier increase. I now understand that these will use X.25. I understand that this is in line with the Perugia meeting.
I have to point out that the Perugia meeting considered a draft document. There are as yet no agreed detailed transition plans. Any such plans must be produced and adopted by the BOD before other than pilot work can proceed.
The intentions of this SNA development may well be in line with ideas developed in Perugia. We cannot study this since no proposal document has yet appeared. Thus any technical comment is not possible. It is appropriate to ask:
There may be other questions and I am not looking for replies via this list. I am looking for a definitive detailed proposal so that we know exactly what is being proposed.
If the BOD allows this development without a proposal and its subsequent approval then it is an invitation for further bilateral agreements between countries. These will undermine any control and planning that the BOD/Executive may wish to impose on the network. This is counter productive to the well ordered operation of EARN. It is counter productive to the development of the closer relations we would like to see fostered between countries. It may lead to anarchy within our community as well as suspicion and friction between countries.
I ask you to give this matter your most urgent and close consideration.
Paul Bryant.
I wish to employ Mr. Eric Thomas of 'Ecole Centrale de Paris, France' as a consultant for a period of 20 working days from 16 July at a rate of 20 pounds per working day.
Mr. Thomas has expertise in the area of IBM network software and we will use him for the following tasks:
The Computing Division of the Rutherford Appleton Laboratory provides many of its services via the connections it has to a number of networks. In particular the Division has connections to the European Academic Research Network with some 1700 computers world wide and to JANET, the United Kingdom academic network, with connections to most academic institutes in the UK. The division operates a gateway between the two networks based on systems residing in the large IBM machine in the Division.
There is a vacancy for a programmer to maintain and develop the gateway. A knowledge of computing and networking is an advantage and training will be available. This is an ideal opportunity for a young graduate to obtain expertise in the IBM VM operating system and networking. Much of the programming will be in assembly code. The successful applicant will be expected work in other areas connected with networking as his expertise develops.
Dear Jean-Claude,
Please would you meet the expenses for my attendance at the EARN Executive meeting which are as follows:-
Air fare 252.00UKL
Taxi to hotel 24SF
Hotel 80SF
104SF @2.42 42.97UKL
Total 294.97UKL
Please make the cheque payable to 'Rutherford Appleton Laboratory'.
I am sorry you were unable to attend. It was a very productive meeting with finance, tariffs and migration the main topics. Having permanent staff is proving a great help.
With best wishes,
Paul Bryant.
Present: R Cooper, B Davies, T Daniels, and P Bryant
CCD agreed to provide gateway traffic figures on a per NRS name basis indicating received and transmitted volumes. These would be provided on a per month and a per year basis.
CCD agreed to provide gateway access control on a per NRS name basis. Control would be manual and would only permit full access or no access. Changes would be made at any reasonable time by request from the JANET executive.
CCD agreed to provide gateway access control to prevent traffic to and from CERN. This would only be provided if HEP decided they did not wish to fund such traffic. Prevention of the traffic would be by request from the JANET executive.
CCD will not be required to provide figures on a per funding body basis.
CCD will not be required to provide access control on the basis of traffic generated or received by any particular user, NRS name, or funding body.
CCD will not be required to provide warnings to users, NRS names, or funding bodies that they are approaching any specified traffic levels.
CCD will provide the volume of traffic to and from NRS names over the last six months as soon as JNT are happy with the format. JNT will do an analysis of these figures and define the funds required from each funding body on the basis of HEP being a participant, as far as CERN traffic is concerned, and also of them HEP not being a participant.
The finance to be recovered will be on the basis of the figures provided by P. Bryant which amounts to 70181 UKL. In the event of difficulties in raising this amount there will be further discussions between CCD and JNT.
The JANET executive will collect the finance from the funding bodies.
It is expected that the proposed EARN special interest group will propose the EARN Board Member and their recommendations will normally be respected (this is requested by the EARN membership meeting).
It is expected that the JANET Executive will wish to run a management meeting between themselves and CCD to consider the provision of the service.
It is apparent that various countries are raising funds in various ways and there is concern that in some cases the methods are against EARN rules.
EARN expects there to be no control on the use of EARN by connected institutions. It is recognised that with the need to raise finance and the variety of political and technical situations in countries that EARN needs to study this topic. It was agreed that the secretariat would survey the funding and control mechanisms within all countries and provide recommendations to the next EARN Executive meeting for development and presentation the the November EARN Board of Directors meeting.
EARN rules require a Board member to be elected by the membership and membership is on an institutional basis. In the case of the UK, and possible other countries, one may wish to apply for a country membership or a per funding body membership. It was agreed that the secretariat would examine the issue and provide recommendations to the next EARN Executive meeting for refinement and presentation to the November EARN Board of Directors meeting.
The EARN executive were unhappy that the UK would not allow traffic from institutions or machines within institutions on the say so of a funding body. Whilst they were unhappy with barring traffic from any legitimate places they would at least like to see the possibility of particular institutions being permitted to pay some subscription to gain access regardless of other funding bodies.
EARN is expecting to define membership fees for Associate members. It was agreed that the secretariat would prepare a proposal for the next EARN Executive meeting.
Dear Chris,
Thank you for hosting the interesting and informative meeting we held recently.
At an EARN Executive meeting we had a long discussion on finance and the problems of moving money between countries for line costs. It is fairly clear that there would be considerable advantage in EARN being able to collect money from the various participants and then to pay for all the lines to one organisation. After our discussion with you on 'one stop shopping' I agreed to make some enquiries to see if it would be possible.
Ideally we should like to pass all our existing international lines to a single supplier after which he would be responsible for billing EARN, the provision of new lines and the termination of existing ones. If this procedure is possible then I suspect that EARN would like to approach several suppliers for quotations for such a service.
Although I realise that at this stage of the European PTTs development this procedure may be impossible I am approaching you on the basis of 'nothing ventured nothing gained'.
You may not be the one to field this request so may I ask you to forward this letter to the appropriate person?
I attach a map of the existing lines to give you an idea of the size of the task.
I look forward to a pleasant surprise.
Yours sincerely
Paul Bryant.
Dear Mr. Harris,
I am writing to you on behalf of the European Academic Research Network EARN. We operate a private network of some 500 machines across Europe for the benefit of the academic community. I enclose some publicity material.
The international part of the network is provided by about 20 international leased lined operating at 9.6 or 14.4 K bits/second. The network currently uses IBM RSCS protocols but is expecting to move to an X.25 private network next year.
We currently pay each PTT for the parts of the leased lines terminating in each country. We deal with the various PTTs via a variety of organisations in whose premises lines terminate. This presents us with the problems of :
With these problems in mind we are approaching a number of organisations with a view to seeing if we could obtain all our international lines from a single source with billing to a single point.
The EARN organisation is funded by its members and we operate a private network as this is the most cost effective procedure. As we move to X.25 we intend to continue with a private network again for financial reasons. However we are interested is exploring other alternatives which could meet our financial constraints. The financial constraint is roughly that any solution should not cost significantly more than the current one.
We hope to progressively move towards the use of 64K lines as these become available internationally.
I enclose a map of the current lines to guide your thoughts.
I look forward to hearing if you are interested in discussing this project further.
Yours sincerely
Paul Bryant.
Dear RARE/COSINE Project team,
We wish to respond to the request for a study to be carried out in the framework of the EUREKA COSINE Project to study 'Migration Strategies for FTAM/File Transfer in COSINE'.
Attached, for your consideration, are the details of our proposal. Please do not hesitate to contact me should you require any further information.
Yours sincerely
P Bryant.
On behalf of W Black, P Bryant, A Dand, and S Weston.
cc: J S Hutton
The RARE Association has issued a request for a proposal for a study within the 'COSINE Specification Phase' to study 'Migration Strategies for FTAM/File Transfer in COSINE'.
It is proposed that a consortium of four people carry out the study.
W Black: Dr. Black is employed by Oxford University in the Nuclear Physics department. He has been involved with the GIFT project which is a converting gateway between various file transfer protocols. He is a member of the UK Transition Group which is defining how JANET should migrate to use ISO protocols. He is a member of the subgroup 5 of the European Committee for Future Accelerators which advises on the use of networks by high energy physics groups. He is therefore an expert on gateways, file transfer protocols, and the requirements for such products in the international high energy community.
P Bryant (Consortium secretary): Dr. Bryant is employed at the Rutherford Laboratory. He is currently involved in defining how EARN should migrate to use ISO protocols which involves consideration of various file transfer gateways. He is a member of the UK Transition Group. He has been associated with a number of projects to implement Blue Book FTP. Since EARN is an important network in Europe it is vital that their transition is taken into account.
A K Dand: Mr. Dand is employed by Avon Universities Computer Centre. He is an expert on the FTAM protocol having sat on the relevant ISO committees. He is chairman of the UK FTAM implementors group and chairman of the Uk IGOSIS 2 group on file transfer. He has attended NBS workshops on behalf of the UK Department of Trade and Industry. His expertise on FTAM and other protocols will be an important aspect for the study.
S Weston: Mrs. Weston implemented large parts of the GIFT project code concerned with the Blue Book FTP component. She is also an expert on DECNET protocols. Her detailed knowledge of FTP and DECNET as well as implementation experience will be an important contribution.
We believe that the team is strong and contains much of the expertise needed to undertake the study proposed. However, in some cases it will be necessary to call on other experts to advise on some protocols.
The information on the usage of various file transfer systems is fragmentary and, as far as is known, no detailed studies have been made.
Some figures are already available from some networks such as JANET and EARN. It is intended to enhance and cross check such figures with a survey of academic sites.
It is unlikely that the figures obtained will be accurate but they should be good enough to base proposals for gateways and relays.
The results of the study will be part of the report.
The team already has within it the expertise for comparing Blue Book FTP, DECNET, IBM NJE, KERMIT, and FTAM. The team is confident that it will be able to analyse the file transfer protocol used within DFN and UUCP to the extent required. There may be other file transfer protocols being used within the community which will be identified and studied.
Tables will be constructed to compare the facilities offered by each protocol. Particular attention will be paid to addressing, binary transfers, and character sets. A list of implementations will be provided.
The study will in particular consider the protocols with respect to converting gateways and relays between them.
An analysis of the benefits and drawbacks of converting relays (such as the EARN/JANET so called gateway) and converting gateways (such as the GIFT system) will be undertaken.
A survey and analysis of the existing and planned converting relays and gateways will be undertaken.
Taking into account the traffic levels a list of the converting relays and gateways required will be produced with recommendations as to how they could be provided and where they should be sited.
The management of the converting relays and gateways will be considered. The extent to which such facilities should be considered as site, national, and international services will be studied.
During a transition there will be difficulties with knowing which machines will be using which protocols also which converting relays and gateways traffic for specific machines should traverse.
It is intended to study what information and/or registration systems will be required and how they should be provided.
Sites tend to be cautious and in many cases they will operate more than one file transfer service in order to give the maximum access to and from their services.
The use of multiple protocols within a machine and the use of converting relays and gateways will be studied.
Although at this stage any time scales will be unreliable and dependent on many factors outside the communities control none the less some estimates will be provided together with the dependencies on which they are based.
No detailed financial statements can be made within the study.
The factors needing to be taken into account in a detailed financial statement will be identified and commented on. These will include the impact on traffic costs by the use of remote converting relays and gateways, the costs of equipment, the implementation costs, and the management costs.
The final report will be based on the topics outlined above.
It is not intended to produce any interim reports considering the small amount of effort involved.
It is intended to use the first three months collecting and analysing information and the last month producing the final document. The information expected to be to hand at the end of the first three months is:
The group considers that the study will require four man weeks to complete considering the complex nature of the protocols, their large number, and the wealth of literature already produced which requires study.
The group is prepared to undertake the study for a total of 10,000 UKL. This includes all overheads.
The rate per day is 400UKL with 100UKL per day expenses which include travel and secretarial costs.
The group is prepared to deliver the study within four months of date of acceptance.
Network Security: No progress
ISO Country Code Changes: Changes are being made and will be completed within the next two weeks.
Liaison with BITNET: There is no mechanism to determine when BITNET meetings will occur. This is a problem which needs addressing.
LISTSERV servers: Compatibility between servers is no longer a problem because BITNET has installed Eric Thomas' implementation.
Michael Hebgen presented the ISO transition strategy for the German EARN/DFN environment. They plan that an EARN host will migrate to OSI and function as a gateway between EARN and DFN. Some functionality will be lost at the OSI boundary. These services will be offered using other intermediate solutions e.g. over an SNA network.
Peter Sylvester presented his software which supports SNA/NJE sessions over X.25 Switched Virtual Circuits.
He also presented the status of a project to develop an X400 implementation for MVS systems.
Paul Bryant described the strategy for JANET's OSI migration. Migration will be performed on an application by application basis rather than layer by layer of the OSI model. So, for example, bluebook over yellow book will be replaced by FTAM over ISO transport layer when available.
Niall O'Reilly spoke about Michael Walsh's work with the Queens implementation. The system has been installed and is being tested. This implementation contains gateways to Rice Mail and PROFS.
A study has been carried out to suggest how EARN could undertake a transition to use ISO protocols. The results of the study so far were considered and developed.
The following proposal for migration to OSI was agreed upon:
The following questions were identified:
NOTE- as a result of this meeting a transition strategy document has been produced and presented at the RARE Valencia Networkshop and at the EARN BOD meeting in Nice. The document is now the EARN transition strategy. This document is appended. Comments are still invited. A detailed plan is now being developed and will be available for comment shortly. Experts wishing to participate in the production of the detailed plan are invited to contact Paul Bryant.
Marco Sommani will look at the impact on the gateways of Pisa and Wisconsin of restructuring the addressing structure to domain addressing.
Paul Bryant and Michael Walsh will write a proposal for RFC822 addressing structure within the migration proposal paper.
EARN will submit an X.400 addressing proposal to RARE.
The recommended protocols and use of RFC822 was covered under migration strategy.
The group did not have sufficient knowledge of existing protocol implementations to make an exhaustive list. The following actions will be taken to acquire this knowledge:
A report on the recent BITNET meeting provided various pieces of information.
The existence of a new Coloured Book network, SPEARnet (South Pacific Education and Research) was reported but little information was available. Any further information will be put in NETSERV.
It was noted with some surprise that the routing tables in the USA were sometimes in error due to typographical errors during the manual updating procedures.
It was thought worthwhile that the various RFC documents be brought over from the USA and stored on a NETSERV in order to limit the volume of trans-atlantic traffic. As the documents are large they will be held at one site.
The first release of RSCS V2 is reported to be much slower than V1 and caution was advised on those installing it. Release 2 is far better due to a re-design and thus it seems reasonable to use it. Olivier Martin offered to produce some figures on the performance.
Peter Sylvester presented the N.I.C.E. project (Network Information Centre Environment). Copies of the foils were distributed. The concept and aims of the group were generally applauded. Paul Bryant will ascertain the status of the group as far as EARN is concerned.
On a number of occasions the lack of any VAX expertise was regretted. It was felt that NICE would benefit from a VAX section. It was regretted that EARNTECH distribution list seemed to contain no VAX experts.
This failing was having a detrimental effect on transition and on the operation of EARN as VAX problems were not being considered.
It was requested that members should try and identify suitable experts who could be encouraged to join the various activities.
There was a lengthy, but inconclusive, discussion on the 'large file problem'. It was agreed it was a problem with no clear solution. Tools for further examination of the problem should be investigated.
Sixth meeting,14/15 September 1987, Perugia, Italy. (Arrive evening of 13).
Seventh meeting, Spring, Portugal.
Thanks were expressed to Hara Tomara, for arranging the meeting and for the cultural events which all ensured a successful and enjoyable event.
Pedro Amorim Univ. of Lisbon AMORIM@PTEARN Sitki Aytac Ege Univ. BILSAY@TREARN Heidi Bergh-Hoff RUNIT, Trondheim NEIDI@NORVNIT Daniele Bovio CNR SIAM, Italy HI@IMISIAM Wim Brems Univ. Leuven, Belgium LAAAA.5@BLEUVL11 Paul Bryant RAL BRYANT@RL.AC.UK W Burraston RAL AWB@UKACRL Miguel A Campos Univ. of Barcelona EARNMAIN@EB0/UB0/11 Dominique Dumas CNUSC, Montpellier, BRUCH@FRMOP11 Rene Florizoone Univ. Leuven, Belgium, LAAAA04@BLEKUL11 F Payidar Geng Metu, Turkey Fragiadakii Gianni Univ. of Crete FRAGIAD@GRCKUN11 Ulrich Giese Univ. Nijmen, NL UOO1212@HEARN Hara Tomara Univ. Research Center, TOMARA@GREARN Michael Hebgen Heidelberg Univ. $O2@DADURE1/RZ02@DHDURZ1 William Jan Karman Univ. Nijmen, NL UO70070@HNYKUN11 Peter Kaufmann DFN, Berlin, Germany KAUFMANN@VAX.HNI.DBP.DE Jukka Korpela Helsinki Univ. of Tech.LK-SKO@FINHUT Freben Lehrmann Lyngby, Denmark NEUPL@NEUVM1 Angel Llopis Vela IBM Sci. Cent, Madrid LLOPS@EEARN Olivier Martin CERN MARTIN@CERN Andrea Mattas-glio Cilea, Italy MATTA@IMICLVX Udo Meyer GSI Darmstadt, Germany MEYER@DEARN Niall O'Reilly Univ. Coll. Dublin NOREILLY@IRLEARN Berthold Pasch IBM Heidelberg PASCH@DHDIBM1 Dominique Pinse IBM France PINSE@FRPOI11 Jerard Pitteloud Univ. Zurich K12630/9@CZHRZU1A Harri Salminen Helsinki Univ of Techn.LK-HS@FINHUTC Marco Sommani CNUCE, Pisa, Italy VNETMNT@ICNUCEVM Lasse Stamnes RUNIT Trondheim, LASSE@NORUNIT Peter Streibelt IBM HW Germany CASTER@DS0/IBM1 Peter Sylvester GMD, Bonn, Germany GRZ0/26@DBNGMD21 Gligor "G" Tashkovich Cornell Univ, USA RMXJ@CORNELLA Eric Thomas Ecole Centrale Paris ERIC@FRECP11
Dear Jean-Claude,
Herewith two claims for expenses for X.400 work which I would be pleased if you would pay from the X.400 fund.
Please would you let me know how much there now is in this fund.
Thank you.
Best wishes,
Paul Bryant.
Dear Mr. Chris,
I am sorry the organisation for our meeting was a bit chaotic with holidays and so forth.
I have put together a few topics that we would like to talk to you about.
1. We would like to talk about how the upgrading of the international X.25 links to 64K is going. We are seeing a wide range of performances from our end.
2. Tariffs are always of interest and we would like to know how they may change. Of particular interest are your views on the German ideas to levy volume charges on leased lines. We understand that they are now installing equipment to make the measurements.
3. EARN has been starting to plan its transition to ISO protocols. I attach a paper which is the strategy they are likely to follow. Your views would be welcome.
I am sure there are several other topics which will arise.
I looks forward to meeting you on Friday.
Yours sincerely
Paul Bryant.
Dear Mr. Pickard,
I am very encouraged by your reply to my letter concerning 'one stop shopping' for EARN's international lines.
We are very interested in pursuing the concept and we are happy for you to circulate my letter to CEPT and other PTTs as an encouragement to obtaining their support. I am sure there are many other organisations which would find such a service useful and give us their support.
At this stage all that we are doing is making enquiries but as soon as there is a possibility of a service we will want to have further discussions with you and possibly other suppliers to discuss the prices and conditions in detail.
I would be grateful if you could contact me again when you feel we could progress further. If there is any further information you need please do not hesitate to contact me.
Yours sincerely
Paul Bryant.
Dear Cliff,
Much as I would love to come to your leaving celebration I have organised a week end in Wales with my sister. With her and my week end commitments we cannot find an alternative date and we have been promising ourselves a trip for a long time to visit the village one of our ancestors came from. Thus with, regret, we cannot come.
We would like to wish you good luck in your new job,
Paul and Julie Bryant.
The EARN (European Academic Research Network) Executive, in pursuance of the requirement for EARN to move to use the ISO (International Standards Organisation) protocols, initiated a study to recommend a transition strategy.
A group, set up to study transition strategies, recommends that:
Tactical details of the migration are outlined in subsequent sections together with areas requiring further study.
EARN has agreed to migrate its network to use ISO protocols as a result of a request form CEPT (the advisory committee for the European PTTs).
It had been hoped to conclude this transition by the end of 1987 to meet the request from CEPT. As a result of the slow development of some of the essential standards and subsequent products this date can not be met. There is now sufficient information to produce a firm proposal for the initial stages of transition including the costs and time scales.
A working group set up by the EARN Executive to study the transition of EARN. Various strategies were developed and a final one was determined and agreed at EARNTECH FIVE held in Crete, 25/26 March. Subsequent refinement has taken place as a result of further discussions and investigations. The EARN Board of Directors has endorsed this strategy.
The EARN Executive requested a further report to further define the strategy and tactics in full detail. This document is a resultant report. This document was considered at a joint meeting between EARN and RARE experts held in Perugia 14/15 September 1987 after which this final document was produced.
The strategy recommends the setting up a private leased line X.25 network. Although this is contrary to the CEPT request the group concluded that the public networks could not be used as they do not currently provide X.25 (1984), which is required to support the ISO network service. In addition, the early services require the use of X.25 permanent virtual circuits (PVCs) and these are not available on international connections. The use of a private leased lines network does not exclude the possibility of migrating part or all of the service to the public X.25 services at a later date.
Although other bodies are involved with the elaboration of functional standards, all references in this document refer to those of CEN/CENELEC and CEPT.
Leaving aside political considerations the main concerns are tariffs and performance.
Current calculation show that the current EARN traffic would be between 5 and 10 times as expensive if carried on the public X.25 networks. The exact value has not been calculated but the cost will certainly effectively prevent much of the EARN traffic ever being generated and so disadvantaging the community.
The public X.25 networks will continue to attract a volume tariff in the foreseeable future. The tariffs are likely to remain relatively high since X.25 networks are not very profitable. A private X.25 network is cheaper since it does not have the same level of availability (24 hour staffing). In a private network many of the costs are hidden since the operation, maintenance, and management of the network can be undertaken by computing centres at marginal cost. The benefit of a leased line network is that its cost is known and fixed. Thus the exact amount of money needed can be requested from the funding bodies or the users.
The principle draw back of a volume tariff is the inescapable conclusion that the costs have to be returned to the end user to avoid a given user bankrupting the organisation. The management of such accounting and control mechanisms is difficult and expensive.
The public packet switched data networks have, for the most part, been used for interactive or transaction purposes when connection times are high and data volumes low. These calls are cheap and do not demand high data rates. In fact the user should not expect more than 2000 bits per second on an international link. This is compensated by the ability to sustain a number of connections but this is of less value for a network passing bulk traffic.
EARN is characterised by bulk traffic which is therefore expensive on a public X.25 network.
Most of the international lines in the Public X.25 networks are 9.6 K bits per second. It is understood that these links will be upgraded to 64K digital ones as these become available. The effect of this is difficult to estimate. The expectation is that public networks should be able to provide the performance required at some future date. A private network with about the same number of international leased lines as EARN should be able to provide a performance similar to the current EARN network. This is supported by observation of some existing private networks.
There are some indications that private networks, such as EARN, may have more freedom to exist in the future with the further liberalisation of the European PTTs.
Ideally the world should be served by a single set of communication protocols. In this way services could be provided to all regardless of the various systems used and constrained only by management and not technical considerations. This is particularly important in the academic community with the wide variety of equipment and wide range of serviced required.
Currently the academic community use a wide variety of communications protocols and this is proving an impediment to the increasing demand for academic collaborations.
The community is now faced with many gateways between the various sub networks which cause loss of quality of service, such as loss of some service or loss of some aspects of a service. The many gateway systems require considerable resources to develop them and maintain them.
Within Europe there is now widespread acceptance of the ISO protocol standards and confidence that manufacturers will provide these as fully supported products both on existing and future systems.
When EARN was set up the ISO protocols were not well defined and furthermore implementations were not expected for some years. Moreover, a large variety of protocols were in use within Europe which gave no indication of the possible directions of development.
The recently set up RARE organisation has brought together the major academic networking interests in Europe and from the discussions and statements made it is clear that there is confidence that services in the near future can and will use ISO protocols and such services will continue for many years.
The working group was constrained by the terms of reference determined by the EARN Executive. These are:
The academic wide area networking in Europe is expected to be based at the lower levels on ISO transport service over an X.25 packet service.
The upper levels are likely to be MOTIS (or its CCITT equivalent X.400 series Recommendations) for mail and FTAM (file transfer and management) for file transfer both using the appropriate ISO session and presentation layers. JTP (job transfer protocol) and VTP (virtual terminal protocol) are not yet stable enough to be considered.
Interactive services will be provided by the CCITT X.3, X.28, and X.29 over X.25 Recommendations although these protocols are not, and are unlikely to become, ISO standards. None the less, these protocols are in widespread use and this is likely to continue for some years.
RARE is expecting to follow the functional standards being elaborated by the CEN/CENELEC CEPT project. Functional standards define the exact stacks of protocols to be used to provide given services. They define the options to be provided and any parameter values required. The use of functional standards ensures that implementations will interwork.
It is not the task of EARN, and it is beyond the resources of EARN, to develop the products required for a transition. Thus, the task of EARN is to select products already available which conform to the relevant standards and functional standards. The speed of the migration of EARN is, to a large extent, dependent on the emergence of such products.
The connection mode protocols RARE is advocating are well suited to the relatively slow and error prone lines currently in use. There are attractions in following the ARPA TCP/IP protocols in that BITNET, Israel (and possible other countries), and many local area networks are following them. EARN would have difficulty following TCP/IP as part of its transition strategy since they are not part of the ISO set of protocols and one would be faced with a further migration to ISO transport protocol class 4 (TP4) over appropriate lower layers at a future date. Consideration of the use of TP4 based services should be considered when higher speed lines with low error rates are available as well as stable ISO protocols and products in this area.
This document does not consider the RARE and CEN/CENELEC work in detail but further study will be required in the future particularly with the adoption of higher level ISO protocols.
At the lower layer X.25 (1980) is available for all major systems as fully supported products from the manufacturers. In many cases there are alternative products for machines from third parties. Products conforming to X.25 (1984) are available for a small but growing number of systems. The availability of X.25 (1984) is expected to improve as the PTTs start to offer services based on it. In many cases no firm dates have been announced. In principle it is not possible to operate ISO network service without X.25 (1984) since this Recommendation contains essential facilities for the support of the ISO network service. These facilities allow network level gateways. The lack of these facilities may be overcome in a single network but in concatenated networks higher (than network layer) gateways or relays would be needed at some inconvenience. The relevant functional standard is T/31 which is now available. The conformance of products with T/31 has yet to be determined.
Products to support CCITT Recommendations of the X.400 series are becoming available from several major systems. In the case of IBM there is currently an experimental version for use under VM. A supported IBM product under MVS has been announced. DEC now offer a fully supported product. There are a number of third party products available or under development. A major incentive to provide these products is the expected introduction of services by the PTTs and value added suppliers. The performance of X.400 products is not yet well known and will depend not only on the protocols themselves but on the quality of their implementations. The relevant functional standards are A/3211 and A/323 which are available. The conformance of products with the functional standards is not known. X.400 is currently undergoing revision for the CCITT 1988 Recommendations. Opinion suggests that services should be targeted on this version and in the mean time only experimental or pilot services should be offered.
A small number of FTAM products exist mainly as experimental implementations or following the MAP (Manufacturing Applications Protocol) recommendations. The performance of FTAM has yet to be established. FTAM is not expected to be widely available for some time. The relevant functional standards are being elaborated.
At a future date JTP (job transfer protocol) and VTP (virtual terminal protocol) will be available but the standards for these are currently unstable. The relevant functional standards are not yet being elaborated.
The CCITT Recommendations X.3, X.28, and X.29 are not ISO protocols but they are expected to provide an interactive service for the foreseeable future. Products to support these Recommendations are available for all major systems. These mainly provide services for line mode terminals. Some products are available for providing screen mode services over X.29 but currently there are no standards in this area. The relevant functional standards are Y/11 and Y/12 which are available.
As yet, products do not necessarily conform to the CEN/CENELEC CEPT functional standards as these have only been in place for a short time or are still to be finalised. However there is expectation that products will conform.
Conformance test centres are to be set up which will guarantee that products will interwork. EARN should acquire certified products where possible.
EARN currently provides file transfer, job transfer, mail, and messaging services. Network management is provided on a pragmatic basis in that the management tools have been produced by EARN and BITNET themselves.
EARN provides added value services which currently include the NETSERV information services, directory services, the LISTSERV mail distribution system, and RELAY the interactive real time conferencing system.
The RARE recommended protocols will probably provide file transfer, mail, and interactive services. Job transfer and better interactive service will be provided at a later date. Note that job transfer services may be provided using FTAM but with limited functionality.
Some study is being undertaken in RARE into services similar to NETSERV.
There is, therefore, a mismatch between the services provided in the two cases.
The NETSERV information service could be provided easily. It could be via gateways or directly using X.400 or FTAM. There are development projects within DFN to provide such facilities. The content of NETSERV will need some enhancement to reflect the new styles of networking in EARN.
X.400 currently has no distribution list services but the 1988 revision will. It would not be difficult to modify LISTSERV to provide these services to X.400 and RFC822 services.
Directory services are not all that successful although the current service could be used via X.400. CCITT is defining directory services but these are not likely to be available for a some time.
The EARN message service will be lost. This service is popular and its loss is serious. To some extent its loss can be ameliorated by the use of interactive services or mail. It would be possible to develop a protocol to carry the EARN messaging service across X.25 but such a move would require resources and be counter to the objectives of a transition. Further study is required to assess the impact of this loss. Further study is needed to determine if and how an alternative service could be provided. RELAY is based on this service.
It is inevitable that the user interfaces may be different. This is not serious as long as the services are more or less as easy to use.
Ideally the user interfaces should not change or should only be extended to avoid confusing the users.
Temporary note - I am not so sure. Some of the user interfaces are not very good and would benefit from a decent burial. Also I would like to see some conformance with user interfaces which do exist e.g. X.28- but I am biased.
User interfaces depend on the particular implementations. There is no intention in this exercise to recommend any move to common user interfaces. If this is to happen it should be as a result of further standardisation activities of standards bodies or at least of RARE. In many cases ISO applications will be provided via existing user interfaces possibly with some extensions.
EARN may have to use software and maybe hardware provided from a variety of sources on a particular machine. This strategy is preferable to waiting for systems from particular sources which could delay a transition.
It is vital that at no time should the network be divided into two or more unconnected parts either logically or physically. Thus gateways or relays are needed between different network systems to preserve interworking.
During transition there will inevitable be a measure of disruption as network methods and user interfaces change. This must not adversely effect the users even though there may be some inconvenience. Careful testing of new equipment and software is essential before it is brought into use.
The initial migration will concern the international nodes or a subset of them.
All the international nodes are machines operating under the IBM VM/CMS or MVS systems. These use RSCS(revision 1), RSCS(revision 2), or JES2. The services NETSERV, RELAY and LISTSERV operate under VM/CMS.
The initial stages of migration will therefore only concern IBM VM and IBM MVS machines.
The migration of EARN within a country is expected to be the responsibility of the management in that country in order to take account of any national plans. In some cases countries will expect to receive some assistance from EARN to aid their migration.
It is important to consider how systems other than VM/CMS and MVS ones can migrate either instep with the international part of the network or at some other time. The DEC VMS systems are of greatest interest as these constitute over 40% of the EARN nodes.
A network aligning with the CCITT recommendations 1984 is required as only this type of network can support the ISO network service. This is because the network service access point (NSAP) address is carried in the 40 digit extended address of the X.25 call request packet. During the early stages of transition the network service would not be required but using a network based on the 1980 recommendations would then require a further transition to the 1984 recommendations at some inconvenience.
An X.25 infrastructure will be developed. Initially this will connect a few international nodes with good network experience. The remaining international nodes will be connected at a later date. Countries may wish to connect their own X.25 network to the EARN infrastructure. These connections require further study on a case by case basis as requests are received.
Systems connected to the X.25 infrastructure should conform with the functional standard T/31 where ISO applications are supported.
The lines for the infrastructure will be provided in three ways:
EARN will requires a number of switches to provide the X.25 backbone.
The factors affecting the number and location of switches are:
An analysis of the EARN traffic and line tariffs was undertaken by IBM (annex 5). As a result of this study a minimal line cost topology was developed and is in the 'Financing of EARN during Year 1988' 30 April 1987 as 'Fig 3' (annex 4). This suggests that a network based on 4 interconnected 'stars' at Rutherford Laboratory, Montpellier, CERN, and Stockholm would provide near minimal line costs. Such a configuration would also be suitable for an X.25 network with switches of about eight line capacity at these sites. A small number of changes would be needed to the topology in 'Fig 3'. A fairly substantial reconfiguration involving about 9 lines is needed to move from the current leased line network to the proposed one.
Initially the four sites would be connected in a square which will provide a certain amount of resilience in the event of line failure. If and when traffic levels rise wider band connection could be made and/or cross connections between the corners of the square as traffic dictated.
Some of the reconfiguration will be undertaken as a result of currently developing plans for the EARN RSCS network and hence the reconfiguration as a result of transition is small and results in reduced costs.
It will be convenient if new lines were to operate with X.25 from installation thus providing a good fall back position during the changes.
As some national parts of EARN migrate and possible become part of the EARN address space a different switch topology may develop due to the provision of local switches which could be used for local and international EARN. This is any area for further study.
It is recommended that:
Areas for further study:
Reykjavik---------+
Trondheim--------+|
Dublin-----+ Helsinki--------+||
| |||
RAL----r--------+ Stockholm
| |
| |
| |
| |
Brussels-r----Paris | |
| | |
| | |
| | |
Lisbon | +----------------+|
| | ||
r Montpellier----------------------Geneva
| |||||||| | |
Barcelona--+||||||| | +-rx--Darmstadt
Abidjan-----+|||||| | ||||
Heraklion-----+|||| | r||+rx-Vienna
Izmir----------+||| | x|+rx--Copenhagen
Tel Aviv--------+|| | |+-rx--Nijmegen
Pisa-------------+| | |
|| | | Washington
|+-----------------------------------------+
| |
| |
CUNY CUNY
Fig. 1 Current Configuration of EARN
rx=lines scheduled for relocation, r=lines to be relocated for X.25
Copenhagen---n-----+
Nijmegen--n--+ Reykjavik---------+|
Brussels--n-+| Trondheim--------+||
Dublin-----+|| Helsinki--------+|||
||| ||||
RAL-----------n------------------Stockholm
| |
| |
| |
n |
| |
| |
| |
| |
| |
| |
Montpellier----------------------Geneva
|||||||| ||
Barcelona--+||||||| |+-n----Bonn
Abidjan-----+|||||| +--n----Vienna
Lisbon----n--+|||||
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa-------------+| Washington
|
|
Cuny
Fig.2 Proposed X.25 infrastructure
n=relocated lines
The requirements for an X.25 switch are:
There are a large number of X.25 switch suppliers most of which expect to develop X.25 (1984) products. A survey in the UK suggested that that there are a number of possible products meeting the EARN requirement (see annex 1). IBM can provide a switching service based on 3725 equipment together with an MVS system for management.
It is essential that the network is provided with a management service and this implies (with the current state of standards) that the switches are provided by a single supplier.
The IBM product, X.25 SNA interconnect (XI), can provide an X.25 network. It has the attraction that some of the equipment required already exists. Currently, of the projected switch sites, only Rutherford and Montpellier have IBM 3725 equipment and thus equipment would be needed at Stockholm and CERN. The purchase of equipment for these sites would incur a high cost, in fact higher than the cost of four switches from an alternative manufacturer. Alternatively a different topology could be considered which would probably incur higher line costs and may have performance implications. Due to the relatively small number of IBM 3725s at the international sites it would not be possible to set up such a network without substantial reconfiguration. The provision of an MVS system to manage the network would not be a problem since this function only requires a fraction of a machine. If existing equipment were to be used then this equipment would in most cases be providing other services and would be more liable to failure or interruption for reasons connected with the local service. It is unclear how prepared sites would be for their equipment to be managed from elsewhere. If new equipment were to be purchased for all the switch sites this would be expensive compared with switches from other sources.
A further advantage of using IBM switching equipment is where countries have substantial amounts of IBM equipment and wish to be part of the EARN managed X.25 infrastructure then this could be easy and cheap to do. On the other hand countries with little IBM equipment and wishing to be part of the EARN managed X.25 infrastructure would find it expensive compared with the purchase of alternative switches.
The UK switch survey suggests that the TelePAC switch provides the cheapest suitable equipment. The company claim to provide X.25 (1984). Six UK universities and Rutherford now have such switches. The TelePAC switch is based on M68000 processors. It can be expanded up to 32 lines, can switch 1162 packets per second, support 1500 channels, and support lines up to 153K bits per second. It can be mounted in conventional 19inch racks and has no moving parts.
Details of the TelePAC switch are in annex 2. This is not an endorsement of this particular switch but is evidence that at least one suitable switch exists.
If equipment were purchased specifically for the network based on the requirement for up to 8 lines at 4 sites then such switches would cost about 10,000UKL each excluding management equipment.
It is recommended that:
EARN must define an X.25 DTE address structure. A number of considerations are relevant:
The CCITT X.121 Recommendation defines a DTE numbering scheme and is the only standard in this area.
X.121 states that an address is of the form:
+-----------+------------+----------------------------------+ |P | DNIC | NTN | |up to 1 | 4 | up to 10 | |digit | digits | digits | +-----------+------------+----------------------------------+
P is the international prefix. As yet its use requires further study by CCITT but it is expected to differentiate between various address formats. From X.121 it is far from clear how the digit is used and the points of question are:
DNIC is the Data Network identification code. This consists of a 3 digit country code (see below for the European codes or see X.121 for a complete list) plus a further digit to identify the network within the country.
NTN is the National Terminal Number. This is allocated by the network operator. Common use indicated that the NTN should be 8 digits followed by a optional 2 digit subaddress which is not policed by the network. Several administrations split the 8 digit number into an area code (identical or similar to the telephone area codes) plus digits to differentiate between equipment in the area.
Temporary note - HEP have proposed an address scheme for their community which:
Without prejudice to further discussions with HEP and other communities EARN should adopt X.121.
It is considered that the P digit only has local significance.
An attempt could be made to select the fourth digit of the DNIC so as to make the EARN address orthogonal to those of the PTTs. There is no guarantee that this can be achieved or maintained. There could be merit in selecting the digit so that EARN is orthogonal to other private networks with which EARN may wish to connect. For the time being the recommendation is to make the digit 0.
The X.121 DNICs for Europe are:
Austria 232 Belgium 206 Denmark 238 Eire 272 Finland 244 France 208 Germany 262 Greece 202 Israel 425 Italy 222 Ivory Coast 612 Luxemburg 270 Netherlands 204 Norway 242 Portugal 268 Spain 214 Sweden 240 Switzerland 228
The 8 digit part of the Network Terminal Number defines the data terminal equipment within the country. Countries are responsible for selecting the national number scheme but it is suggested that the first 4 digits should define the site and be based on the public telephone area codes. The subsequent 4 digits should define the DTE within a site. Many public X.25 follow a similar scheme.
The final and optional 2 digits which are termed the subaddress will not be policed by the network. No specific use has been specified for these digits.
It is essential that the DTE numbers are registered centrally in order to maintain the consistency of the network and to provide directory facilities. This should be undertaken by a network management centre.
The recommended scheme will provide a firm base for almost unlimited growth both in the countries connected and within the countries and sites.
It is recommended:
+------------+----------------------------------------------------+ | DNIC | NTN | | 4 +-----------------+---------------+------------------+ | digits |4 digit site code|4 digit machine|2 digit subaddress| +------------+-----------------+---------------+------------------+
The X.25 infrastructure will require management to:
Initially this will require a modest amount of effort at one central site and a small amount of effort at each switch site. The effort required will increase with the extension of the X.25 network into some national parts of EARN. None the less each country will have the responsibility of managing its part of the network in conjunction with the international management. Further study is needed to provide a more accurate estimate but the total should not be dissimilar to that absorbed by a comparable RSCS network.
It is advisable to locate the centre at a site which already has expertise with network management. This should reduce the costs involved and ensure a high standard of management.
It is recommended that:
It is essential that EARN maintains its connections with the existing user base. It is desirable that EARN has connections to other existing and emerging academic networks.
The decision as to whether EARN within a country will operate over the public X.25 network, use leased lines for X.25, or use some other technology will be a local decision depending on national academic plans.
Countries may wish to share the EARN DTE address scheme. In this case the country may join the EARN X.25 management structure which would (with current standards) almost certainly require them to use the same switches as the international part of EARN. If a country uses alternative switches then they will have to totally manage their network and a suitable management interface will be required to ensure that service is maintained between the networks and that the number scheme remains consistent.
Where countries have entirely separate networks gateways and relays will be required at network or higher levels which are considered in section 8. In this case there may be restrictions on the traffic which can pass between the networks.
It is recommended that:
The network products of IBM will normally be based on the SNA (system network architecture) products. Products within this architecture allow the IBM NJE protocol to operate over X.25. This scheme demands the use of X.25 permanent virtual circuits. Currently the PTT X.25 networks do not provide such circuits on international links. In addition several national PTT networks do not provide them.
Temporary note - Recent announcements by IBM indicate that NJE can operate over switched virtual circuits. This announcement has yet to be studied.
The use of the IBM NJE over X.25 products will allow the current EARN traffic generated in the existing nodes to cross the X.25 network with out change to node software or user interfaces. That is, apart from the changes in the nodes directly connected to the X.25 network.
It is possible to operate a number of proprietary IBM protocols over the X.25 infrastructure such as LU 6.2 or IBM 3270. If these protocols are introduced, which patently have no current ISO equivalent, the removal of IBM proprietary protocols will be made more difficult.
It is recommended:
It would be possible to consider the NJE over SNA service as a single SNA network and take advantage of the management. This is not recommended as:
It is recommended:
All the international EARN nodes operate under the IBM VM or MVS operating systems and these are the only systems capable of operating NJE over X.25.
For both VM and MVS the software stack is:
+-------------------------+
| RSCS V2 or JES |---- to national EARN nodes
+-------------------------+
| VTAM |
+-------------------------+
|
+-------------------------+
| NCP |
| NPSI |
+-------------------------+
|
X.25
The software products required are:
ACF/NCP V4 5668-754 ACF/SSP V3 X.25/NPSI 5668-981 ACF/VTAM 5664-280
The hardware required is an IBM 370 computer or similar with an IBM 3720/3725 communications adapter or IBM 4361 or 9370 with integrated communications adapter.
The availability of the hardware and software on international sites is:
Site Sys VTAM NCP NPSI RSCS2 JES2 3720 3725 3705 4705 FINHUTC VM Y(1) FRMOP11 VM Y Y Y Y DBNGMD21 MVS Y Y Y Y Y DEARN VM Y Y(2) Y EBOUBO11 VM Y Y Y Y CEARN VM Y EARNET VM Y Y IRLEARN VM Y CIEARN VM Y(2) Y HEARN VM Y(2) Y UKACRL VM Y(2) Y(2) Y(2) Y(2) Y Y Y SEARN VM Not known BEARN VM Not known PTEARN VM Not Known AEARN VM Not Known TREARN VM Not known GREARN VM Not known TAUNIVM VM Not known NORUNIT VM Not known DKEARN VM Not known (1) Equipment on loan from IBM. (2) Software expected before the end of 1987.
There are large user communities within Europe who use DECNET, Coloured Book, and other protocols. These communities are unable to move to ISO protocols in the near future. They use a mixture of leased line and public networks.
In the interests of reducing the overall costs to the academic community and the provision of greater connectivity there is merit in allowing such protocols be be used over the EARN X.25 infrastructure.
Such services would have to be provided by connections from the EARN switches to relevant machines or to national X.25 services to which the machines connect. The exact mechanisms will have to be studied within each country. Note that such provisions may require further connections into the proposed switches or for switches to be provided within the relevant countries. The financing of this equipment requires study.
It is likely that there will be a demand for gateways or relays between the various gateways. The provision of these requires further study.
The use of these protocols should be phased out as soon as suitable ISO alternatives become available.
The protocols of most interest are:
There may be other interim protocols of international interest which could be considered. The increase in the number of protocols should be discouraged to avoid problems in phasing them out.
It is recommended:
In general the high level protocols require an underlying X.25 network as far medium speed wide area networks, such as EARN, are concerned. At the start of transition the EARN X.25 network will only connect to a small number of machines. Thus the provision of ISO protocols on these machines will attract little use initially. However, such services should be mounted as soon as convenient to gain experience and to encourage the use of ISO protocols.
In addition to the ISO services, converting gateways and relays will be needed to maintain connectivity between users. These are considered in section 8
The first ISO high level protocol to be introduced is likely to be X.400 the message handling or mail protocol. This protocols is now well developed and there are several implementations now in existence.
Current products are based on the 1984 version. The 1988 version is expected to have various changes which suggest that it would be unwise to provide a service based on the earlier version as this would entail a transition to the later one at some inconvenience.
EARN is now concluding a study of the IBM Heidelberg X.400 system developed by the IBM European Network Centre. The conclusion of the study is that the system is capable of providing a service of the type required by the academic community. It is close to the CEN/CENELEC functional standard and indications are that it will interwork with other implementations. The group understands that the system is being modifies to operate over the IBM X.25 supported products and will therefore be able to coexist with the NJE product. It currently uses an IBM Series/1 computer to provide the X.25 packet service. The system has the useful facility of allowing part of the user agent to be remote and across an NJE or other suitable network. This will allow X.400 to be available rather more widely than the EARN X.25 infrastructure. There are a number of other X.400 products such as EAN, for use with VAX computers, and DEC's own X.25 product. As these products do not operate on the international nodes their use becomes of interest as the EARN X.25 network expands into countries or connects to other X.25 networks.
The product stack for an IBM VM system is:
+-------------+
|Heidelberg |
|X.400 |
+-------------+
| OTSS |
+-------------+-----------+
| OSNS | RSCS V2 |---- to national EARN nodes
+-------------+-----------+
| VTAM |
+-------------------------+
|
+-------------------------+
| NCP |
| NPSI |
+-------------------------+
|
X.25
It is recommended:
X.3, X.28, and X.29 provide interactive services. They are not and are unlikely to become ISO standards. They are popular and implementations are widely available. If offered this will provide a new type of service for EARN.
Although the basic protocol is matched to simple terminals it has been found possible to provide more complex services such as IBM 3270 albeit at a slow speed using protocols over X.29. For example, the Rutherford 'async 3270' and the UK 'simple screen mode protocol'.
No extra equipment or expense is involved in the provision of this service by EARN although countries or sites may wish to provide PADs (packet assembly disassembly facility) to aid access.
Systems providing the protocols should conform to functional standards Y/11 and Y/12.
It is recommended:
The ISO protocols FTAM (file transfer and manipulation), VTP (Virtual terminal protocol), and JTP (job transfer protocol) are not as well developed as other protocols.
FTAM implementations should be available in a year or so and pilot implementations are now in existence. If these implementations are used then services may be disrupted as the products developed and possible change to align with the functional standards being elaborated.
VTP and JTP standards are unstable and implementations are unlikely in the foreseeable future. EARN is particularly interested in VTP developments since many services now require full screen services as provided on local terminals by IBM 3270 and DEC VT200 equipment.
It is recommended:
There are three cases to be considered:
Currently all networks fall into this category. Initially EARN will only provide ISO protocols at and below network layer.
A variety of converting relays and gateways will be required. Many of these exist or are under development. The products required will change as EARN and the national networks develop. The availability of such products is examined in section 8.
In the initial stages of transition, that is with IBM NJE protocols over X.25, all the current relays (there are no gateways in the strict meaning of the term) will continue to operate unchanged. Thus user will perceive no change in the perception of the service.
The application relays depend on the use of high level addresses such as those found in X.400 and RFC822. In both of these areas agreements are required. There is some progress in this area within RARE.
On the assumption that EARN and the national network will be running compatible products, that is conforming to relevant functional standards, then there will be network level relays between the networks. In the mean time it is difficult to make any further statements as plans for such networks are only now emerging and certainly there are no definitive statements.
The use of network level gateways requires the use of NSAP (Network Service Access Point) addresses and these are an area of study. EARN will need to study how it will connect to such networks as their details emerge.
In a number of cases countries may wish to share the EARN X.25 DTE number plan in which case they will be part of EARN as regards the services offered at the X.25 level. If they use the same switch manufacturer then the network management will be able to be common. If different switch manufacturers are selected then it is unlikely that the management will be common and suitable pragmatic management arrangements will have to be developed to maintain the service between the networks in each case. There will clearly be advantages with respect to reliability and availability if the management is common but the political and financial consequences require study.
Although in this case the X.25 network would be common the higher level protocols may be different although this would be undesirable. None the less if it is the case converting relays or gateways may be needed.
It is recommended that:
The first target is to provide an international X.25 infrastructure and to encourage the development of an X.25 network within each country. For financial and political reasons whether this takes place and by when cannot be stated. Therefore, in practical terms the discussion is centred on the phasing out of non ISO protocols on the international X.25 infrastructure.
With an X.25 network it is not possible to police the higher level protocols used and therefore the phasing out of non ISO protocols can only be by removing their use within a country and/or by providing suitable converting relays and gateways between the national networks and the international part of EARN.
The principal protocol to be phased out is NJE which would include the use of RFC822 over NJE. The prerequisites for this are an X.400 to RFC822 relay and an FTAM to NJE relay or gateway. Since EARN currently uses these protocols exclusively and some countries are likely to take some time to be in a position to phase them out it is likely that there early removal will be difficult. Relays exist between NJE and Blue Book file transfer and DFN file transfer. These protocols are expected to have gateways or relays to FTAM which will remove the need for relays to NJE.
It is understood that DEC intend to migrate DECNET to ISO protocols. The details of this move are not entirely clear as there are some services within DECNET which currently have no ISO counterpart.
The UK is planning to phase out the use of Coloured Book protocols in favour of ISO ones. Any use of these protocols within EARN is therefore expected to cease with their removal from JANET.
A number of converting relays and gateways will be required in order to preserve the current connectivity and to enable EARN to reach a larger population.
A converting relay is required between IBM NJE over bi-synch and IBM NJE over X.25. This relay is essential for connecting the current EARN network to the proposed X.25 infrastructure and is provided as a supported product from IBM.
X.400 is expected to be the first ISO high level protocol be be used over the EARN X.25 infrastructure.
DFN is promoting the production of an RFC822 to X.400 relay which is being undertaken by Softlab GmbH. It is hoped that EARN will be able to use this product which will be an important and essential for providing a gateway between the RFC822 and X.400 communities. The product will operate operate under the IBM VM operating system and therefore further hardware should not be required. The product is scheduled for completion by the end of 1987.
The relay between RFC822 and X.400 is expected to be in accordance with RFC987. This raises difficulties as the address scheme of EARN is unsuitable as it is not based on domain concepts. It is possible to modify the EARN RFC822 address scheme to be changed to provide a domain address scheme which would be easy to relay. Details of this scheme is in section 14.
A relay exists between Grey Book mail and X.400 which operates on a VAX. Such a product will be required if EARN moves to X.400 before the Coloured Book community. This product has been developed by the Computer Science Department of University College London.
It is recommended that:
A converting relay between NJE and FTAM is not a difficult proposition but due to the simple nature of NJE and the complex nature of FTAM the gateway will be awkward and along the lines of the current JANET to EARN file transfer relay as there are similarities between Blue Book and FTAM. In particular address problems will in general demand that such information is carried in the body of the NJE file. In addition certain types of file will be difficult to deal with.
With current state of development of FTAM a relay is not an urgent consideration.
It is recommended that:
Since the IBM NJE protocol is based on relay principles a gateway between IBM NJE and FTAM would at first sight seem to have no advantages. However, because of the existence of the GIFT project such a development may be useful.
It may be possible to utilise the GIFT system which currently provides a converting gateway between Blue Book, CERN, and DECNET file transfers. This product is an international collaboration initiated by the high energy physics community. This would need extending with FTAM, which is planned, and NJE which is not. Further study and possible development is required.
It is recommended that:
JTP and VTP are insufficiently well developed to currently demand any action. a
It is recommended that:
No explicit gateways are required. It is normally possible to use the PAD and packet mode DTE within a node to form a crude but effective gateway.
It is expected that facilities will be developed to allow the protocols to gateway through a network level gateway. This depends on certain extensions to X.28 expected in the 1988 Recommendations to allow the extended address to be specified.
It is recommended that:
A suitable relay exists at Rutherford Laboratory and no further action is required.
It is recommended that:
The extent to which the EARN X.25 infrastructure will carry DECNET traffic is not known. It must be remembered that DECNET provides process to process communication and that any file transfer facilities are provided by operating system facilities, such as a copy command. JNET may operate over DECNET by one JNET process making a connection to a remote one. The two most satisfactory solutions would either be DECNET on an IBM machine or NJE over X.25 on DEC machines together with suitable relay software, these do not exist and could be substantial projects.
There are two further options for a file transfer gateway both of which have awkward address mechanisms:
For DEC mail the only possibility is the CERN MINT system.
It is recommended that:
UNIX systems on EARN have an implementation of NJE and it would seem unlikely that this could be enhanced to emulate the IBM NJE over X.25. This is a similar position to DEC machines with JNET with the exception that there is no possibility of operating NJE over other low level protocols.
UUCP is the principle file transfer and mail system for UNIX systems and in the main it operates over dial up connections. There appear to be a number of ways of getting between EARN and UUCP which require further study.
It is recommended that:
Network level gateways will be required between the EARN X.25 infrastructure and some national or public networks. These will be required as these networks adopt X.25 (1984). As yet there is no indication of where such products will come from.
It is recommended that:
This document is not an exhaustive survey of the gateways and relays which may be required.
It is recommended that:
This section surveys some of the ISO products which are available. It is not definitive and further details can found from the various suppliers.
There are a number of products which are of interest from various sources.
The IBM SNA(ISO) products provide services up to and including session level. X.400 has now been announced. As yet FTAM has not been announced. IBM supports X.25 (1980) and has not yet announced support for X.25 (1984). X.3, X.28, and X.29 (1980) PAD and packet mode DTE support is provided but no support for the (1984) version has been announced. It is believed that the 1980 products will interwork with DCE equipment supporting 1984. The provision of 1984 will only become important as the higher level ISO services are introduced and as the need to traverse network gateways develop.
The Heidelberg X.400 system provides support for X.25 (1980) via a Series/1 front end for VM systems. There is no information on the support of X.25 (1984). There is confidence that the Heidelberg system will be developed to operate over the SNA(ISO) products.
There are several other product sets which are mainly aimed at the support of national network services although operating over X.25. Examples of these are the Rutherford Laboratory and Salford University products which support Coloured Book protocols. Indications are that these systems could connect to the EARN X.25 network if required. These systems are likely to be phased out as networks move to use ISO protocols and manufacturer supported products.
Salford university has developed a version of FTAM which operates over a Series/1 front end and indications are that this could coexist with the Heidelberg X.400 system. It may also be possible to develop it to operate over the IBM X.25 product which could give some early services with this protocols. This requires further study.
Note that only IBM computers and systems can offer NJE over X.25 which will limit the penetration of this method of working within countries.
As with VM the IBM SNA(ISO) products offer a service up to and including session level. X.400 has been announced for use within DISSOS.
Temporary note - what do we know about X.3, X.28, and X.29 also X.25 (1984)?
A version of the Rutherford Coloured Book protocols operate under VMS.
DEC provides X.25(1984) in the current release of PSI. X.400 is now on field test. FTAM will be available this year but this will be a version conforming to MAP requirements. DEC provides support for X.3, X.28, and X.29 (1984) for PAD and packet mode DTE. There is also a PAD available from St. Andrew's University for the (1980) Recommendations. A version of X.400 is available from Queens University Canada or from Sydney Corporation which has achieved some popularity in the European academic community. This is known as EAN.
The DEC product structure is:
+------------+ +------------+ +------------+
| X.400 | | FTAM | | PSI PAD |
+------------+ +------------+ +------------+
| | |
+---------------------------+ |
| OSAC | |
+---------------------------+ |
| |
+---------------------------+ |
| VOTS | |
+---------------------------+ |
| |
+--------------------------------+------------------------+
| PSI | Packet mode DTE |
| +------------------------+
| |
+---------------------------------------------------------+
|
X.25
The hardware required is:
VAX (not micro VAX) with KMS11 or DMF11
or
Micro VAX with KMV11
Most, it not all, other systems now have X.25 (1980) support and have plans to provide (1984) versions as well as ISO higher level protocols. Details of these products are of less interest and are not included here.
Many PAD manufacturers are expecting to support the 1984 Recommendations and although migration does not depend on such equipment there will be no difficulty obtaining PADs. PADs supporting the 1980 Recommendations will normally interwork with packet mode DTEs supporting the 1988 ones and vice versa (see Y/11 and Y/12).
A number of schemes have been developed for supporting IBM 3270 and DEC VT200 over X.29 connections. Async 3270 has been produced at Rutherford and allows special terminals, IBM PCs, or VT200 (connected to a VAX) to operate as 3270 terminals. The UK has develop Simple Screen Mode Protocol which also operates over X.29. This allows a range of terminals to connect to special boxes and emulate a wide range of screen mode terminals. The protocol has also been implemented on an IBM PC. This protocol allows the emulation of many types of screen mode terminal.
The extent of the requirement for screen mode services is not known. The effect of such services on the performance of the network is not known.
All the products required to implement the X.25 backbone are available. It is assumed that before a decision to proceed is agreed that the topology, switch locations, and switch supplier will have been decided. The principle events with respect to a start date when decisions have been agreed and finance is available are:
- Decision to proceed 0 - Order switches 0 - Order line between Rutherford and Montpellier 0 (1) - Order line between Rutherford and Stockholm 0 (1)(2) - Experiment between Rutherford and Montpellier 3 (3) - Service between Rutherford, Montpellier and Stockholm 6 - Conversion of CERN/Stockholm and CERN/ Montpellier to X.25 8 (4) - Conversion of international sites and topology changes 6 onwards - X.400 on some international sites 6 onwards - Provision of RFC822/X.400 gateway 6 - Migration of national EARNs 6 onwards - Provision of FTAM, JTP, and VTP As available
(1) There is a spare pair of IBM modems from the Rutherford/Dublin link. Rutherford is prepared to loan EARN modems. Eventually modems will be recovered from the redundant lines. Thus no modem purchases are envisaged unless speeds greater than 9.6K are required.
(2) The Stockholm line is dependent on the provision of VTAM, NCP, NPSI, and RSCS V2 at Stockholm.
(3) Rutherford is prepared to loan EARN switch capacity if the delivery of switches is delayed beyond the delivery of the lines.
(4) The conversion of the CERN/Stockholm and CERN/Montpellier line depends on the provision of VTAM, NCP, NPSI, and RSCS V2 and suitable hardware at CERN.
The transition of some international nodes are likely to be delayed by lack of suitable hardware and software. The transition of national parts of EARN will be dependent on local circumstances.
The X.400 system to be used initially will be from Heidelberg but this decision must be reviewed as other systems become available.
X.3, X.28, and X.29 will be provided as and when nodes wish to provide them either as PADs or packet mode DTEs.
The aim of functional standards is to ensure that implementations will interwork. CEN/CENELEC and CEPT are producing a range of functional standards which will meet all the requirements of EARN. The functional standards of interest are:
Only the basic version of VTP is complete but this provides little or no further functionality that X.3, X.28, and X.29 provide. The more advanced version is far from stable. Thus no functional standards in this area expected for some time. There is some pressure for a functional standard for ISO 6429 over ISO session from the European commission but this will be unlikely to provide the screen mode services users would like.
Currently no products conform with the functional standards. This situation will change as manufacturers and customers become familiar with them. EARN should attempt to procure conformant products.
In the short term non conformant systems may have to used but EARN should take all possible steps to ensure that the systems migrate to conform.
It is recommended that:
Detailed costs depend on the exact equipment required and the discounts that suppliers will give.
The funding sources are a matter for the EARN Board of Directors.
A survey of manufacturers suggests that suitable switches can be obtained for 10,000 UKL making 40,000 UKL in total. See annex 1 and 2.
The eventual line charges should be less than the current ones as the topology expected is near optimal from the studies carried out by IBM and D. Lord (annex 4 and the 'financing of EARN in 1988'). Each line relocated will incur an installation charge estimated at 2,000 UKL. There will be an overlap of lines which depends on the overlap time and is estimated at 3,000 UKL.
It is not possible to estimate the cost of IBM hardware and software as these depend on local discounts.
It is expected that any costs incurred beyond the X.25 international infrastructure (the four switches), some line costs, and possible some costs associated with the international nodes will be met nationally. These costs may include national X.25 switches, further hardware and software on national node, and any line costs.
As with the current EARN network manpower will be required for the management of the X.25 infrastructure. It is reasonable for this to be met centrally. If the management also looks after national parts of EARN then a contribution would be expected from that country. Some effort would be needed during the setting up of the infrastructure estimated at two man months. Running effort would be about one man month a year assuming that the international infrastructure remained fairly static and that the equipment and lines were not unduly unreliable.
The ISO network service is defined in IS 8348. The network layer is above the X.25 packet layer and below transport layer. It provides an end to end service across a concatenated set of X.25 networks. This is achieved by the use of a 'network service access point' (NSAP) address which defines the remote entity. The NSAP address can be regarded as a global address. In the case of an X.25 network the NSAP address is carried in the 'extended address' which is an 'optional user facility' in the CCITT X.25 (1984) recommendations.
EARN expects to be connected to other X.25 networks with different address schemes and must decide what NSAP address scheme to use.
The NSAP address is 40 decimal digits or binary fields. Since it is more convenient to 'name' entities a name registration mechanism will be needed to define the mapping. Users on other networks will have to have access to the mappings as well as EARN having access to theirs' if entities are to be known universally by names rather than the 40 decimal digits which may also be more liable to change.
EARN will not only have to deal with its own NSAP addresses but also those of other networks to enable such traffic to be directed to the correct gateways. The difficulty, or otherwise, of this will depend on the schemes chosen by the networks and currently only JANET has proposed a scheme.
The OSI NSAP addressing scheme defines a number of allocation schemes for a set of hierarchical nested registration bodies. An NSAP address starts with an initial domain part (ISP) followed by a domain specific part (DSP). The ISP is further divided into an authority and format identifier (AFI) and initial domain identifier (IDI). There are AFIs for various PTT network types (X.121, PSTN, Telex, ISDN, etc) and for ISO network independent schemes. The network independent schemes are the ISO-DCC scheme, which names national registration authorities, and the ISO-6523-ICD scheme, which names international organisations and authorities.
The network independent schemes are preferred as they are not tied to any particular network type and are thus potentially more stable. Note that this type of scheme has been adopted by JANET.
It is unclear whether EARN should regard itself as an international organisation and come under the ISO-6523-ICD scheme or a set of national organisations and be registered with or alongside other national networks. There appear to be three options:
Current opinion is that the EARN international X.25 infrastructure is likely to develop into an overlay network between national networks which would favour the first option.
If ISO-DCC is followed the format of the NSAP will be:
+----------------------------------+-------------------+ | DIP | DSP | +--------+-------------------------+ | | AFI | IDI | | +--------+----------+--------------+-------------------+ |ISO DCC |Country |Allocated by |For allocation by | | AFI |identifier|National |customer | | (38) |ISO 3166 |Administration| | +--------+----------+--------------+-------------------+ The case of the UK the NSAP will be: 38 826 1100 DSP
where 826 is the UK ISO 3166 code and 1100 has been allocated to JANET by the British Standards Institute.
The format of the DSP has been decided within JANET but each country will have to consider its own schemes or RARE may provide recommendations.
The NSAP should contain the DTE address of the EARN entity or possible the DTE of a local area network the entity is attached to so allowing algorithmic extraction of the DTE address.
It is unclear what facilities suppliers will provide in their products.
It is recommended that:
EARN has connections to several networks providing electronic mail using various protocols and various addressing schemes. Important representatives are ARPA, JANET, UUCP and EARN which use variants of the RFC822 protocol and EAN using a variant of X.400. Further X.400 networks can be expected soon including EARN.
Users require mail exchange between current EARN systems, future EARN X.400 systems and systems accessible via gateways. This involves four protocol/address schemes:
The native IBM NJE-RSCS address scheme used in the IBM systems is the RSCS 'spool tags' or MVS 'destination/subdestination'. It consists of an 8 byte 'user identifier' and an 8 byte 'node identifier'. The RFC822 mail system used within EARN uses these 8 byte pairs as the RFC822 addresses of the form 'user identifier'@'node identifier'. Mail may be generated by the user either by the use of an editor or one of the several mail programs or systems.
Many sites operate mail user agents, for example the Crosswell mailer. These are also capable of utilising the 8 byte 'user identifier' and 'node identifier' pairs. In addition these systems can (generally) deal with 'internet domain addresses'. The internet domain address scheme is based on a hierarchical mail address. They provide an address scheme for a set of concatenated networks. The scheme is used in a number of networks with which EARN and BITNET have connections. The top level domains have tended to be large organisations in the states, such as EDU or BITNET, whereas in Europe the ISO 3166 two character country codes are favoured. The second and subsequent levels are at the discretion of the organisation 'owning' the top level domain. For example, CAMBRIDGE.AC.GB could be the address of some facility in Cambridge which is within the academic community which is within Great Britain.
There are conflicts with domain addresses in that an address may be reachable via several routes or no routes. For example, name@VAX1.CAMBRIDGE.AC.GB generated in domain EDU, say, may arrive via:
The problem can be overcome by the use of 'source routing'. This requires the user to have knowledge of the route the mail is to take. The use of such routing is discouraged and not universally supported.
In some cases a country may be in several disjoint mail systems and only particular routes will be successful. For example, name@BONN.GMD.DE may be accessible via EARN but not DFN. The basis of domain names is in RFC 920. RFC997 defines the internet addressing rules.
It would be possible to register the address of all entities centrally but this is unlikely in view of their large number. It is more likely to be done on a per domain basis.
X.400 addressing is based on OR (Originator/Recipient) names. A name consists of a number of 'attributes'. The registration of OR names or parts of them is unclear. In some countries it is expected that this will be organised by government agencies. The attributes are:
CCITT claim that Country and AdministarationDomainName are mandatory. The implication of this is that PTTs expect mail passing between private mail domains is expected to pass through a public one. Some commentators believe that such an activity is un-enforceable both practically and legally. For example, it does not seem possible to legally differentiate between mail and other data traffic.
ISO regard both PrivateDomainName and AdministrativeDomainName as optional. This recognises that private mail domains may interconnect directly but still recognising the possibility of public suppliers providing the interconnection between private mail systems if wanted.
An EARN X400 service may take a number of options:
It is unclear what name structure will be recommended by RARE. There is some pressure for the country name to be longer than two characters (against CCITT Recommendations). However there is some agreement that the X.121 codes should not be used. It is unclear whether the AdministrativeDomainName will be used and if used which one of the several registered in a country will be used.
The PrivateDomainName may be allocated on a per site basis in some countries (Germany) while in others the academic community is expected to have a single name for the community and for an OrganizationName to be allocated to a site.
Temporary note- The author has not been reading the latest documents from the relevant RARE working party and the above comments may be out of date.
EARN will require a relay between RFC822 and X.400. Recommendations are needed for the address mappings which may be different in different countries but should follow RFC 987.
If EARN were to use domain addressing then it would be possible to follow the recommendations in RFC 987 which defines how an RFC822 to X.400 should operate. It would not be possible for mail based on the EARN 8 byte 'user identifier' and 'node identifiers' to pass through a relay to X.400. It would be possible for X.400 mail to pass through a relay and to sites only accepting the 8 byte form. This would be undesirable in the interests of a consistent address strategy.
The key document for the production of an RFC822 to X.400 gateway is in RFC987. The fields of the X.400 name are mapped to the components of an RFC822 name. The RFC987 assumes that the RFC822 name follows the DARPA domain recommendations.
Domain addressing with RFC822 (see RFC920) demands that a mail box has a unique name and address. The address has a hierarchical form so that addresses can be selected at a particular level without reference to other parts of the structure while still maintaining uniqueness.
The top level is normally a country code and it is recommended that this is the two character ISO 3166 code. The structure below the country code is at the discretion of the 'owner' of the country code. In general this would take the form of an organisation such as an academic community. At the next level there would be a site name. At the bottom level the name of a machine. However there is considerable flexibility at the lower levels. The name and address are separated by '@' and the domain components by '.'. The most significant part of the address comes last. A typical name and address would be:
P.Bryant@IBM-B.Rutherford.AC.GB
It is unclear what the exact form of RFC822 and X.400 addresses will be within Europe. It is fairly certain that the country code in X.400 and in RFC822 will be the two character ISO 3166 one.
It should be added that the adoption of domain addressing will allow a much more flexible mail service in that it will no longer be necessary for each site to have a record of the universe of mail addresses within EARN.
Some minor developments within the mailer may be needed.
The ISO 3166 European two character codes are:
Austria AT Belgium BE Denmark DK Eire IE Finland FI France FR Germany DE Greece GR Israel IL Italy IT Ivory Coast CI Luxemburg LU Netherlands NL Norway NO Portugal PT Spain ES Sweden SE Switzerland CH
The RFC822 mail systems would require rather more extensive tables since they would have to know about each RFC822 to X.400 gateway and which addresses should be sent to it. For example it is likely that all addresses ending in AC.UK would go to a single gateway. In Germany there is expected to be many PrivateDomainNames and mail would be directed to one or more gateways. This situation may become more complex if countries decide on a wide variety of interpretations of the X.400 OR name. This reinforces the urgent need for EARN recommendations for mail addressing and address mapping.
It is likely that nodes will be members of EARN as well as other networks. Ideally the address of an entity should be the same for all the networks connected to. This implies that EARN should make an attempt to use any address scheme decided on within the academic community of a country. This should present few problems as it is expected that RARE will provide recommendations. Thus each country must discuss their X.400 addressing with RARE.
The conclusion is that RFC822 mail within EARN should adopt domain addressing. This will involve a radical change in EARN mail. It will cause difficulties with sites not operating mail systems. There is therefore an urgent need to encourage all sites to operate mail systems and to use domain addressing as soon as possible.
The EARN mail systems would have to be adapted to deal with addresses in a given domain some of which are in EARN and some which may not. The Crosswell mailer is capable of this but a study of other mail systems is required.
It is recommended that:
The CEN/CENELEC CEPT functional standards are:-
PrENV 41 104 T/31 Transport service over X.25
PrENV 41 201 A/3211 MHS-UA+MTA: PRMD-PRMD (P2+P1)
A/323 MHS-(Intra-PRMD) (P2+P1*)
A/325 Mailbox Service Access (P7)
A/111 Simple File Transfer
A/112 Positional File Transfer
A/113 Full File Transfer
A/122 Positional File Access
A/13 File Store Management
PrENV 41 901 Y/11 Y/12 X.3, X.28, and X.29
Note- Items with no Prenv numbers are not available but are currently of secondary interest.
D H Crocker, Standard of the Format of ARPA Internet Text Messages, RFC 822, August 1982.
J Postel and J Reynolds, Domain Requirements, RFC 920,
S Kille, Mapping Between X.400 and RFC 822, RFC987, June 1986.
ISO 6429, Information Processing - ISO 7-bit and 8-bit coded character sets - Additional control functions for character-imaging devices. IS: 1983.
ISO 7498, Information Processing Systems - Open Systems Interconnection - Basic Reference Model IS: 1984
ISO 7776, Information Processing Systems - Data Communications - HDLC - Description of the X.25 LAPB compatible DTE single link procedure DIS May 1985.
ISO 8072, Information Processing Systems - Open Systems Interconnection - Transport Service Definition IS: 1986.
ISO 8073, Information Processing Systems - Open Systems Interconnection - Transport Protocol Definition IS: 1986.
ISO 8208, Information Processing Systems - Data Communications - X.25 packet level protocol for DTE DIS March 1985.
ISO 8326, Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Service Definition DIS September 1984
ISO 8327, Information Processing Systems - Open Systems Interconnection - Basic Connection Oriented Session Protocol Definition DIS September 1984.
ISO 8348, Information Processing Systems - Data Communications - Network Service Definition DIS July 1985.
ISO 8571/1, Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management - Part 1 : General Description DIS July 1986.
ISO 8571/2, Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management - Part 2 : Virtual Filestore DIS July 1986.
ISO 8571/3, Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management - Part 3 : File Service Definition DIS July 1986.
ISO 8571/4, Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management - Part 4 : File Protocol Specification General Description DIS July 1986.
ISO 8648, Information processing Systems - Data Communications - Internal Organisation of the Network Layer DIS February 1986.
ISO 8822, Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Service Definition DIS May 1986.
ISO 8823, Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Protocol Definition DIS May 1986.
ISO 8824, Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1) 2nd DIS May 1986.
ISO 8825, Information Processing Systems - Open Systems Interconnection - Basic Encoding Rules for Abstract Syntax Notation One (ASN.1) 2nd DIS May 1986.
ISO 8878, Information Processing Systems - Data Communications - Use of X.25 to provide the OSI Connection-oriented Network Service DIS March 1986.
ISO 8880/1, Information Processing Systems - Data Communications - Specification of Protocol to Provide and Support the OSI Network Service - Part 1, General Principles 2nd DP June 1986.
ISO 8880/2, Information Processing Systems - Data Communications - Specification of Protocol to Provide and Support the OSI Network Service - Part 2, Provision and support of the Connection-mode Network Service 2nd DP June 1986.
ISO 8883, Information Processing Systems - Text Communications - Message Oriented Text Interchange System - Message Transfer Sublayer, Message Interchange Service and Message Transfer Protocol Dis 1986.
ISO 9065, Information Processing Systems - Text Communications - Message Oriented Text Interchange System - User Agent Sublayer, Interpersonal Messaging User Agent - Message interchange formats and Protocols. DIS October 1986.
ISO 9066, Information Processing Systems - Text Communications - Message Oriented Text Interchange System - Reliable Transfer Service and use of Presentation and Session Services DP December 1985.
X.3 Packet Assembly/Disassembly Facility (PAD) in a Public Data Network. CCITT Red Book, Volume VIII - Fascicle VIII.2, 1984.
X.25 Interface between Data Terminal Equipment (DTE) and DTA Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode and Connected to Public Data Networks by Dedicated Circuit. CCITT Red Book, Volume VIII - Fascicle VIII.3, 1984.
X.28 DTE/DCE Interface for a Start-stop Mode Data Terminal Equipment Accessing the Packet Assembly/Disassembly Facility (PAD) in a Public Data Network Situated in the same Country. CCITT Red Book, Volume VIII - Fascicle VIII.3, 1984.
X.29 Procedures for the Exchange of Control Information and User Data between a Packet Assembly/Disassembly (PAD) Facility and a Packet Mode DTE or another PAD. CCITT Red Book, Volume VIII - Fascicle VIII.3, 1984.
X.400 Message handling systems: System model-service elements, CCITT Red Book, Volume VIII - Fascicle VIII.7, 1984.
X.401 Message handling systems basic service elements and optional user facilities. CCITT Red Book, Volume VIII - Fascicle VIII.7, 1984.
X.408 Message handling systems: encoded information type conversion rules. CCITT Red Book, Volume VIII - Fascicle VIII.7, 1984.
X.409 Message handling systems: presentation transfer syntax and notation. CCITT Red Book, Volume VIII - Fascicle VIII.7, 1984.
X.410 Message handling systems: remote operation and reliable transfer server. CCITT Red Book, Volume VIII - Fascicle VIII.7, 1984.
X.411 Message handling systems: message transfer layer. CCITT Red Book, Volume VIII - Fascicle VIII.7, 1984.
X.420 Message handling systems: interpersonal messaging user agent layer. CCITT Red Book, Volume VIII - Fascicle VIII.7, 1984.
Transition to OSI standards, Report of the UK Academic Community OSI Transition Group, 1987.
D. Lord, The funding of EARN for 1988.
BOD The EARN Board of Directors
CCITT Comite Consultatif International Telegraphique
Telephonique
CEN/CENELEC Comite Europeen de Normalisation/ Comite Europeen de
Normalisation Electrotechnique
CEPT Conference Europeenne des Administrations des Postes
et Telecommunications
DTE Data Terminal Equipment
EARN European Academic Research Network
FTAM File Transfer and Management
IBM International Business Machines
ISO International Standards Organisation
JTP Job Transfer Protocol
MHS Message Handling Service
NSAP Network Service Access Point
OSI Open Systems Interconnection
PRMD Private Mail Domain
PTT Posts, Telegraphs and Telephones ?
RARE Reseaux Associes pour la Recherche Europeenne
RFC Request For Comment
RSCS Remote Spooling and Communications System
SNA Systems Network Architecture
VAX
VM/CMS Virtual Machine/Conversational Monitor System
VTP Virtual Terminal Protocol
At the Berlin EARN Board of Directors meeting in November 1987 a study was commissioned to determine how EARN should migrate to use ISO protocols. A strategy document was produced (paper 2) as a result of the EARN technical meeting in Crete in March 26/27 1987. This document was presented at the RARE Valencia workshop on May 4/5/6 1987 and to the EARN Board of Directors in Nice on May 21/22.
The Board of Directors commissioned a detailed plan based on the strategy which is (paper 3). The EARN Executive at their meeting in Geneva on 13/14 July 1987 considered an early draft of the plan and decided to dedicate the September 14/15 1987 EARN technical meeting in Perugia to a workshop on transition at which the plan would be refined.
The transition plan (paper 3) falls into a number of sections. Some sections are very detailed and concern the early stages of transition. Some later sections, for example to do with JTP and VTP, contain little more than statements of intent.
A considerable number of statements are made which are open to question, such as the use of X.121 DTE addressing. However there are many other areas where decisions are needed, for example with X.400 OR names. In some of these cases the decisions being made by the CEN/CENELEC functional standards activity or the RARE working parties will change or extend the plans.
The workshop will start with consideration of the plan as a whole when there will be an opportunity to decide whether it is indeed the best strategy.
Assuming there is a good measure of agreement on the strategy it is proposed to split into a number of working parties to consider in detail various aspects of it.
The object of the Workshop is to produce a better transition plan for EARN.
I look forward to an exciting and fruitful meeting as EARN starts to progress towards its transition.
The details of the agenda may change as the meeting progresses.
Sunday 13 September Arrive.
Monday 14 September.
9.00 Consideration of the strategy (paper 2).
There will be a half hour presentation which will assume members are familiar with the it.
This will be followed by a half hour discussion to determine whether this is the best or
indeed the only strategy.
10.00 Coffee
10.30 Set up working groups.
There will be a half hour presentation of the plan (paper 3) after which the
working groups will be set-up. It would be appreciated if members would decide
which group they wish to join and be familiar with the relevant sections.
11.30 Working groups
1 X.25 infrastructure to include:
Topology and location of switches.
Selection of switch manufacturer.
DTE address scheme.
Management.
2 NJE over X.25 to include:
The hardware and software requirements.
Migration problems.
Management.
3 Use of X.400 mail to include:
OR names
use of 1984 or 1988 recommendations
possible products
time scales.
13.00 Lunch
14.00 Working group continuation.
16.00 Reports from working groups.
17.00 Close.
Tuesday 15 September.
9.00 Summary of progress so far.
9.30 Set up working groups. The groups to be set may well depend on the previous days progress. Suggested topics for working groups:
1 Use of other high level protocols to include:
Use of DECNET.
Use of Coloured Books.
Other protocols.
Advisability of allowing these protocols.
Gateways required.
2 High level ISO protocols FTAM, VTP, and JTP
gateways required
possible products
time scales.
3 Mail gateways between X.400 and RFC822 to include:
The possible introduction of domain addresses into EARN
the possible products.
4 Extension of EARN to include:
Connections to existing networks
NSAP addresses
extension of the EARN X.25 infrastructure
management considerations.
5 Some groups will continue from the previous day.
10.30 Coffee
12.00 Progress reports
13.00 Lunch
14.00 Final session
assessment of progress
production of report
future activities
time scales.
16.00 Close.
Steve- I will give you the history of the EARN transition project and then write down what I think you were telling me on the phone. Over a phone line it is not all that easy to get things right.
Transition has been on the agenda since EARN started as a consequence of CEPT and it was supposed to be complete by the end of this year.
The first serious steps were taken at the Berlin meeting when the BOD asked me to do a study. There were two radically different options.
One fraction wanted to run SNA (proprietary) (the full works) between the international nodes starting with a Darmstadt to Montpellier link. The plan was then to move to ISO protocols as and when products became available from IBM. The benefits of this procedure were that no new lines or hardware were needed and that sites could join this 'better' EARN as and when they ran SNA. The expectation was that all sites would slowly move to SNA which offered a lot of technical advantages quite apart from EARN. The flaw in this argument seems to be that there is no clear transition path from SNA to ISO. There seems to be as much upheaval going from NJE/bi-synch to ISO as SNA(proprietary) to ISO.
(A word on terminology - every time I use the work 'NJE' I get my ear chewed off for not calling it 'RSCS' and every time I use 'RSCS' they say I should call it 'NJE'. Thus in my book, and I no longer listen to any corrections, NJE is a high level protocol which operates over bi-synch or over SNA. RSCS and JES are implementations of NJE. SNA(proprietary) is the protocols implementations within SNA which do not include NPSI, OTSS, OSNS. SNA(ISO) is the implementation of ISO protocols within SNA which includes NPSI, OTSS, OSNS.)
The other fraction thought that an X.25 network should be set up by taking a portion of the bandwidth from each international line to form the X.25 network and connecting machines to this network as and when they offered ISO protocols. The advantage is that one can see immediate, if not very useful, progress to ISO from day one. The disadvantage is that it would degrade the current EARN network, it could result in two separate networks.
The solution seemed to be to combine the two proposals by setting up the X.25 infrastructure and running the SNA(ISO) over it and running NJE over the SNA(ISO). Thus the X.25 would be used from day one and also the use of SNA(proprietary) would be prevented.
The current proposal is based on this scheme which we now believe is viable.
To fill in one or two details. It is proposed to have 4 X.25 switches, possibly from Telepak, which will be located at Rutherford, Stockholm, CERN and Montpellier and this will form a square backbone to which all the other countries will connect. Eventually we would expect the square to be 64K lines and there to be cross connection in the square. By the way the switches cost 10,000UKL (say 15,000 USD) each. I should add that IBM were quite keen for us to use 3725 equipment with XI for switches. Whilst some suitable 3725s exist the purchase of enough extra 3725 equipment would have been rather more that the 40,000UKL. In addition the performance of the 3725 is not very good as a switch. There are some further arguments against 3725 which I will not relate.
The next problem in transition is how to move forward. With an X.25 line going to an IBM international node in a country running NJE how do you get to ISO or use it for DECNET or Coloured Books or TCP/IP all over X.25. The way this is envisaged is that the countries will decide how to do it in conjunction with national networking activities. This is not a cop out! There are several cases to be considered. In the case of the UK we would expect to put in a network level gateway between EARN and JANET at an early date and to have our NJE/X.25 on the JANET side. Some countries which do not look like having an X.25 network may like to extend EARN into their countries by buying EARN compatible switches and sharing the DTE address space and network management. In other countries they may which to share the DTE address space with EARN but to manage their own X.25 network. Yet other countries may wish to stay with traditional EARN. We would start to see ISO operating when these types of connections were made. Before this happened one would expect pressure to allow DECNET, Coloured Book, and TCP/IP to operate over X.25 and we intend to allow this as it will be the major early reason for making connections and extending the X.25.
With all these different protocols there is the real danger that the network will separate into non communicating fractions. We therefore envisage gateways and relays. Many of these already exist - for example the NJE/RFC822 relay to Coloured Books at Rutherford, the GIFT machine, the X.400 to RFC822 at UCL, MINT, DFN X.400 to RFC822 and probably a few more.
Now as we both realise NJE/X.25 a la IBM is not exactly an open system. Ideally to run NJE over X.25 we would like something that was capable of operating on a number of machines - this would encourage the X.25 to penetrate faster. My quick investigation showed that it should be possible to operate NJE (JNET) directly over PSI (you may say this is not possible) and one could do a similar job on the IBM. The obvious problems are addressing and call set up. IBM get over this by the rather sly ploy of putting it across a PVC. (I gather they have a method of doing it across an SVC but so far my friendly IBM rep has been unable to give me the document as to how it is done). However, having thought about this we would find EARN saddled with producing and looking after two pieces of code on DEC and IBM. My experience of running services on such code leads me to be pessimistic. It would certainly take some time to put in place whereas NJE/X.25 as IBM does it is off the shelf. Ideas of NJE over network or transport seemed equally difficult and at this stage there seemed no advantage of putting NJE any higher than packet level.
The ideas from Norway (or my interpretation of them) is to run NJE(JNET) over DECNET/X.25. It would be possible to use this instead of the current IBM international nodes. The technical problems are broadly similar. The technical advantage is that DEC is committed to migrate DECNET to ISO and so there would appear to be an end to all proprietary protocols except NJE itself. However, I am not sure that this is a very strong argument as the DEC transition looks to be a slow process and I do not see how some features of DECNET can do a transition without further ISO protocols. The disadvantages of this procedure are that it would mean a completely new set of international nodes. In some cases this may mean moving to another site. Thus there would probably be new Board of Director Members new staff looking after the node. We have the problem of what to do with NETSERV and its bits and pieces. I could not envisage these services not being on the international nodes. I think you can see that such a proposal would be political dynamite. I might add that every director come from a 'true blue' site and we have never had a JNET/DEC expert at an EARN technical meeting. You can draw your own conclusions.
Now the product which you spoke to me of is JNET over VOTS over PSI or in other words NJE over transport (class 0?) over X.25 (1984). This could then be connected to the current international IBM node over a short connection which could be NJE/bi-synch or possible at a later date a channel connection. The cost of a dedicated VAX to do this would be 20,000USD. As the proposal stands this would be functionally similar to the use of NJE/X.25 by IBM but the protocol over the X.25 would have a higher ISO content. This would be an advantage if other machines were to offer NJE/transport. The principle advantage is that the IBM node would be unaltered and the site would not have to buy SNA hardware and software. Whether this gives a net saving or not is a delicate calculation. Remember that most sites have 3725/3720/3705/4705 to run current EARN although these may well have to be enhanced to run NPSI which requires more store. I estimate that 40% of sites intend to have SNA regardless of EARN. Add to this the fact that SNA takes more machine cycles and more manpower to look after and we have a difficult sum to calculate. I would not like to say whether one is cheaper than the other.
A further benefit of a VAX front end is that it offers NJE/TCP/IP and thus in countries such as Norway this community could connect more directly to EARN rather than having to go NJE/TCP/IP-VAX-NJE/bi-synch-IBM-NJE/X.25. Similarly the NJE/DECNET community would have a more direct connection.
As I mentioned earlier, the ideal situation would be to mount NJE over OSNS which would then allow VAX and IBM to interwork over X.25. I think such a project would be difficult but perhaps you know different.
Now what about Perugia? As the poor sod who is going to collect the mud at this meeting I am quite prepared, in fact I welcome, alternative proposals. As I see your proposal it will be an alternative to the section which advocated NJE/SNA/X.25. I do not think any of the other sections need changing. The benefits of a better relay to NJE/DECNET and NJE/TCP/IP are clearly an added bonus which do not really impact the other sections which address such issues as X.121, X.400, NSAPs, gateways, connection to national networks etc. What I will do is to mail you the relevant chapter (the full document is 42 pages and a bit big for electronics). I will also mail you (surface) the full document on the understanding that it is my current thoughts and not yet approved for the Perugia meeting. I do not intend to change this document for purely technical reasons. What I am prepared to do is prepare a supplement which will contain the microvax proposal and several other corrections and suggestions. I would be most happy if you would like to pen such a section.
Please correct my impressions from our phone conversation if I have got it wrong.
If I had a clean sheet of paper I would set up one giant SNA(proprietary), one giant DECNET, and one TCP/IP network and build 3 gateways!
Paul.
The network products of IBM will normally be based on the SNA (system network architecture) products. Products within this architecture allow the IBM NJE protocol to operate over X.25. This scheme demands the use of X.25 permanent virtual circuits. Currently the PTT X.25 networks do not provide such circuits on international links. In addition several national PTT networks do not provide them.
Temporary note - Recent announcements by IBM indicate that NJE can operate over switched virtual circuits. This announcement has yet to be studied.
The use of the IBM NJE over X.25 products will allow the current EARN traffic generated in the existing nodes to cross the X.25 network with out change to node software or user interfaces. That is, apart from the changes in the nodes directly connected to the X.25 network.
It is possible to operate a number of proprietary IBM protocols over the X.25 infrastructure such as LU 6.2 or IBM 3270. If these protocols are introduced, which patently have no current ISO equivalent, the removal of IBM proprietary protocols will be made more difficult.
It is recommended:
This document should be read in conjunction with the EARN transition proposal and provides further information and details.
Section 4 paragraph 4 (page 20) - Replace second occurrence of 'gateways' by protocols.
Section 9 3 (page 29) - For VMS read MVS.
Section 9 3 (page 29) - For DISSOS read DISOSS.
The availability of the hardware and software on international sites is:
Site Sys VTAM NCP NPSI RSCS2 JES2 3720 3725 3705 4705 FINHUTC VM Y(1) FRMOP11 VM Y Y Y Y DBNGMD21 MVS Y Y Y Y Y DEARN VM Y Y(2) Y EBOUBO11 VM Y Y Y Y CEARN VM Y EARNET VM Y Y IRLEARN VM Y CIEARN VM Y(2) Y HEARN VM Y(2) Y UKACRL VM Y(2) Y(2) Y(2) Y(2) Y(1) Y Y SEARN VM Not known BEARN VM Y(2) Y(2) Y(2) Y(2) Y PTEARN VM Not Known AEARN VM Not Known TREARN VM Y GREARN VM Not known TAUNIVM VM Not known NORUNIT VM Not known DKEARN VM Y Y (1) Equipment on loan from IBM. (2) Software expected before the end of 1987.
The table of various codes for countries have been brought together.
Table of ISO country codes, country numbers and X.121
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
United Kingdom GB GBR 826 234
The United Kingdom of Great Britain and Northern Ireland
IN discussions with the Nordic countries it appears that Copenhagen would be a better switch site. This has the advantage that Copenhagen already has some of the relevant software. A disadvantage is that three further lines will need to be relocated.
Sites with VTAM are now marked with '*'.
Geneva has been replaced by CERN which was the original intention.
The amended proposal is below.
EARN X.25 INFRASTRUCTURE
Stockholm---n------+
Nijmegen*-n--+ Reykjavik---------+|
Brussels*-n-+| Trondheim---n----+||
Dublin-----+|| Helsinki----n---+|||
||| ||||
RAL*----------n------------------Copenhagen*
| |
| |
| |
n |
| n
| |
| |
| |
| |
| |
Montpellier*---------------------CERN*
|||||||| ||
Barcelona*-+||||||| |+-n----Bonn*
Abidjan*----+|||||| +--n----Vienna
Lisbon----n--+|||||
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa*------------+| Washington
|
|
Cuny
Fig.2 Proposed X.25 infrastructure
n=relocated lines
*=sites with VTAM, note at CERN VTAM is not on CEARN.
The Nordic countries have suggested that since traffic from their countries is relatively small they would only require a single line to the rest of EARN and that this should go to either CERN (as they have considerable high energy physics traffic) or to Montpellier (as they have the major link to the USA). There are a number of issues that should be considered.
The scheme would reduce costs as outlined. However the UK, as a result may call for the UK-CERN connection to be retained thus loosing the financial advantage.
The loss of the proposed 'square' backbone means that the loss of any of the inter-switch links would cause loss of service rather than degradation of service.
If the Nordic link goes to CERN then traffic from the Nordic countries to the countries connected to the UK would go through at least four switches thus contributing to the overloading of some lines and switches.
If the Nordic line goes to Montpellier then the switch there will become very critical and also may need to be larger (depending on supplier).
The acceptance of the Nordic suggestion would not preclude the UK-Nordic link at a later date.
It is important to view the switches and their interconnected lines as a European issue and not a regional one and thus some areas or countries may be advantaged or disadvantaged to the common good. It is likely that the switches and their interconnecting lines would be financed centrally by a levy on membership or other central funding. Thus the costing of the scheme should be considered in total.
EARN X.25 INFRASTRUCTURE (NORDIC PROPOSAL)
Stockholm---n------+
Nijmegen*-n--+ Reykjavik---------+|
Brussels*-n-+| Trondheim---n----+||
Dublin-----+|| Helsinki----n---+|||
||| ||||
RAL* +----n------------------Copenhagen*
| |
| |
| |
n |
| |
| |
| |
| |
| |
| |
Montpellier*---------------------CERN*
|||||||| ||
Barcelona*-+||||||| |+-n----Bonn*
Abidjan*----+|||||| +--n----Vienna
Lisbon----n--+|||||
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa*------------+| Washington
|
|
Cuny
Fig.2 Proposed X.25 infrastructure
n=relocated lines
*=sites with VTAM, note at CERN VTAM is not on CEARN.
Initially the the connections between the switches would be 9.6K.
A cursory examination suggests that this should provide a service which is better than the current one on the following grounds:-
The inter switch links are clearly critical to performance. It would be a trivial exercise to enhance the speed to 14.4 with new modems. Further enhancement could ether be to replace the lines with 64K (when available) and/or introduce the cross connections UK/CERN and Copenhagen/Montpellier.
It would be possible for a country with specific requirements to connect to more than one switch or for direct country to country links as the network grows.
EARN X.25 INFRASTRUCTURE (POSSIBLE ENHANCEMENTS)
Stockholm---n------+
Nijmegen*-n--+ Reykjavik---------+|
Brussels*-n-+| Trondheim---n----+||
Dublin-----+|| Helsinki----n---+|||
||| ||||
RAL*----------64K----------------Copenhagen*
| \ / |
| \ / |
| \ / |
64K \ / |
| \ / 64K
| / \ |
| / \ |
| / \ |
| / \ |
| / \ |
Montpellier*----64K--------------CERN*
||||||||| ||
Barcelona*-+|||||||| |+-n----Vienna
Abidjan*----+||||||| +--n----Bonn*
Lisbon----n--+|||||+------------------------------------+
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa*------------+| Washington
|
|
Cuny
Fig.2 Proposed X.25 infrastructure
n=relocated lines
*=sites with VTAM, note at CERN VTAM is not on CEARN.
Section 3 suggests that NJE is carried over X.25 using IBM proprietary protocols. Two additional methods have been proposed.
The advantages of the use of IBM protocols are:-
The disadvantages are:-
The product stack is:-
VM
+-------------------------+
| NJE (RSCS V2) |
+--------+----+-----------+
| NJE | | SNANJE |
+--------+ +---VTAM----+
+--------+ +---NCP-----+
BSC-+ EP | | NPSI +-X.25
+--------+ +-----------+
MVS
+-------------------------+
| JES |
+--------+----+-----------+
|DMTVMB | | SNANJE |
+--------+ +---VTAM----+
+--------+ +---NCP-----+
BSC-+ EP | | NPSI +-X.25
+--------+ +-----------+
The second proposal is to use JNET over DECNET. This will require a VAX computer on each international site which would be between the switch and the IBM international node to which it would be connected by NJE over bi-synch. The use of DECNET would also for preference use X.25 PVC connections.
The advantages are:-
The disadvantages are:-
The product stack is:
+---------------------+
| JNET |
| +--+---------+
|BTDRIVER| |DECNET |
+--------+ +---------+
+--------+ |PSI |
BSC -+ DUP11 | +---------+
+--------+ |DMF22 +-X.25
+---------+
The third proposal is to implement NJE over packet, network, or session layer. This scheme requires further study. In particular it would not be advisable if it delayed transition or required products to be developed by the community.
The advantages are:-
The disadvantages are:-
The protocol stack is:
VAX IBM
-----------------+ +-------------------+
JNET | | RSCS V2 or JES |
DRIVER+-+Glue | +-???--+------+-----+
------+ |OSAC? | |Glue | |NJE |
|VOTS? | |OSNS? | +-----+
+--------+ |OTSS? | "
|PSI | +VTAM--+
+--------+ +NCP---+
+--------+ |NPSI |
|DMF22 +X25+ |
+--------+ +------+
TCP/IP is an important protocol which is widely used in the community. It is unclear whether it can be used over X.25 and further study is needed.
Converting relays or gateways are required between TCP/IP and other protocols and this needs further study.
There has been some correspondence in EARNTECH on the effect of transition on nodes.
Experiments indicate that the use of NJE/SNA/X.25 had considerable overheads compared with NJE/bi-synch. On the other hand files will be transferred directly from transmitting to receiving node without being staged in intermediate nodes thus reducing the consolidated overheads. The issue is further complicated as traffic will already have traversed (possibly) some traditional EARN nodes. It is even further complicated in that the mix of X.25 and tradition nodes will be changing with time.
The unsatisfactory conclusion is that it is difficult to calculate whether the consolidated overheads will increase or decrease and further study is required.
If NJE is carried over DECNET/X.25 then there should be a decrease in overheads as only the reduction in the number of nodes a file is staged through will be relevant. However, the penetration of X.25 may well be reduced by the need for each IBM node to be front ended by a VAX and increased by the fact that there are already a large number of VAX nodes which can take advantage of the use of NJE/DECNET/X.25 with little expenditure.
It is difficult to determine whether the use of NJE over session, transport, network, or packet layer would be more or less expensive on IBM and DEC systems. On an IBM machine VTAM would still be utilised but the overheads of setting up pier to pier SNA connections removed. The overheads of OTSS and OSNS are not to hand. On a DEC system DECNET would not be required thus reducing overheads but OSAC and VOTS may increase them.
Reykjavik---------+
Trondheim--------+|
Dublin-----+ Helsinki--------+||
| |||
RAL----r--------+ Stockholm
| |
| |
| |
| |
Brussels-r----Paris | |
| | |
| | |
| | |
Lisbon | +----------------+|
| | ||
r Montpellier----------------------CERN*
| |||||||| | |
Barcelona--+||||||| | +-rx--Darmstadt
Abidjan-----+|||||| | ||||
Heraklion-----+|||| | r||+rx-Vienna
Izmir----------+||| | x|+rx--Copenhagen
Tel Aviv--------+|| | |+-rx--Nijmegen
Pisa-------------+| | |
|| | | Washington
|+-----------------------------------------+
| |
| |
CUNY CUNY
Fig. 1 Current Configuration of EARN
rx=lines scheduled for relocation, r=lines to be relocated for X.25
*=sites with SNA
Copenhagen*--n-----+
Nijmegen*-n--+ Reykjavik---------+|
Brussels*-n-+| Trondheim--------+||
Dublin-----+|| Helsinki--------+|||
||| ||||
RAL*----------n------------------Stockholm
| |
| |
| |
n |
| |
| |
| |
| |
| |
| |
Montpellier*---------------------CERN*
|||||||| ||
Barcelona*-+||||||| |+-n----Bonn*
Abidjan*----+|||||| +--n----Vienna
Lisbon----n--+|||||
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa*------------+| Washington
|
|
Cuny
Fig.2 Proposed X.25 infrastructure
n=relocated lines
Stockholm----n-----+
Nijmegen*-n--+ Reykjavik----n----+|
Brussels*-n-+| Trondheim----n---+||
Dublin-----+|| Helsinki-----n--+|||
||| ||||
RAL*----------n------------------Copenhagen*
| |
| |
| |
n n
| |
| |
| |
| |
| |
| |
Montpellier*---------------------Geneva
|||||||| ||
Barcelona*-+||||||| |+-n----Bonn*
Abidjan*----+|||||| +--n----Vienna
Lisbon----n--+|||||
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa*------------+| Washington
|
|
Cuny
Fig.2 Proposed X.25 infrastructure
n=relocated lines
Stockholm----n-----+
Nijmegen*-n--+ Reykjavik----n----+|
Brussels*-n-+| Trondheim----n---+||
Dublin-----+|| Helsinki-----n--+|||
||| ||||
RAL* +-------n------------------Copenhagen*
| |
| |
| |
n |
| |
| |
| |
| |
| |
| |
Montpellier*---------------------CERN*
|||||||| (full) ||
Barcelona*-+||||||| |+-n----Bonn*
Abidjan*----+|||||| +--n----Vienna
Lisbon----n--+|||||
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa*------------+| Washington
|
|
Cuny
Fig.2 Proposed X.25 infrastructure
n=relocated lines
Stockholm----n-----+
Nijmegen*-n--+ Reykjavik----n----+|
Brussels*-n-+| Trondheim----n---+||
Dublin-----+|| Helsinki-----n--+|||
||| ||||
RAL*----------n------------------Copenhagen*
| \ / |
| \ / |
| \ / |
n \ / n
| \ / |
| / \ |
| / \ |
| / \ |
| / \ |
| / \ |
Montpellier*---------------------Geneva
|||||||| ||
Barcelona*-+||||||| |+-n----Bonn*
Abidjan*----+|||||| +--n----Vienna
Lisbon----n--+|||||
Heraklion-----+||||
Izmir----------+||| ?
Tel Aviv--------+|| |
Pisa*------------+| Washington
|
|
Cuny
Fig.2 Proposed X.25 infrastructure
n=relocated lines
+-------+----------------------+ |P digit|Public address of node| +-------+----------------------+ P international prefix defines public or private network - but does it exist? What if a site has a LAN? What if a site has no public connection? As public addresses start with 3 digits country code - no conflict.
If ISO-DCC is followed the format of the NSAP will be:
+----------------------------------+-------------------+
|Initial Domain Part |Domain |
+--------+-------------------------+Specific |
| AFI |Domain IDentifier |Part |
+--------+----------+--------------+-------------------+
|ISO DCC |Country |Allocated by |For allocation by |
| AFI |identifier|National |customer |
| (38) |ISO 3166 |Administration|(DTE number?) |
+--------+----------+--------------+-------------------+
38 826 1100 (9 31 digits) for GB
AFI (Authority and Format Identifier) - X.121, PSTN,
TELEX, ISDN, ISO-DCC, or ISO-6523-ICD
X.121 assumes global address space - no good
Is EARN international (ISO-6523-ICD) or set of national
networks ISO-DCC?
If international - node may have 2 NSAPs.
Recommend ISO-DCC scheme.
+-----------------------------------+
| Traditional EARN |
+-----------------+-----------------+
|
+-----------------+-----------------+
| ? ? ? |
+-----------------+-----------------+
|
+-----------------+-----------------+
| X.25 Infrastructure |
+-----------------+-----------------+
|
+-----------------+-----------------+
| ? ? ? |
+-----------------+-----------------+
|
+-----------------+-----------------+
| Traditional EARN |
+-----------------------------------+
+-------+ +-----------------+ +--------+ | X.25 +--+Application level+--+National| | EARN | |relay/gateway | |network | +-------+ +-----------------+ +--------+ +-------+ +-----------------+ +--------+ | X.25 +--+Network level+--+National| | EARN | | gateway | |network | +-------+ +-----------------+ +--------+ +-------+ +--------+ | X.25 +-----------------------+National| | EARN +-----------------------+network | +-------+ +--------+ +----------------------------------------+ | X.25 National+ | EARN network | +----------------------------------------+
+----+---------+------------+-----------+
|DNIC|site code|machine code|sub-address|
+----+---------+------------+-----------+
+3 1| 4 | 4 | 2 |
Note: DNIC = 3 digit country code + 1 digit
network code
Mandatory- use of 3 digit country code
Country code selected by country
Recommend use of 4 digit site code, 4 digit
machine code, 2 digit sub-address
No attempt to be orthogonal to PTTs or
national networks.
NJE/SNA/X.25
Advantage: Off the shelf software
Hardware in many places
Disadvantage: Only available on IBM.
VM
+---------------+ +-------------------------+
|NJE(RSCS V1or2)| | NJE (RSCS V2) |
+---------------+ +--------+----+-----------+
|DMTVMB | | NJE | | SNANJE |
+---------------+ +--------+ +---VTAM----+
+---------------+ +--------+ +---NCP-----+
| EP +-+ EP | | NPSI +-X.25
+---------------+ +--------+ +-----------+
MVS
+---------------+ +-------------------------+
| JES | | JES |
+---------------+ +--------+----+-----------+
|DMTVMB | |DMTVMB | | SNANJE |
+---------------+ +--------+ +---VTAM----+
+---------------+ +--------+ +---NCP-----+
| EP +-+ EP | | NPSI +-X.25
+---------------+ +--------+ +-----------+
NJE/DECNET/X.25
Advantage: Off the shelf software
Direct connection to DECNET and
NJE/TCP/IP ?
Disadvantage: Only available on VAX
Hardware on few EARN int. sites.
+--------+ +---------------------+
| JNET | | JNET |
| | | +--+---------+
|BFDRIVER| |BTDRIVER| |DECNET |
+--------+ +--------+ +---------+
+--------+ +--------+ |PSI |
|DMF32 +- BSC -+ DUP11 | +---------+
+--------+ +--------+ |DMF22 +-X.25
+---------+
NJE/?/X.25 (?=session, transport, network,
or packet levels)
Advantage: More ISO like, less proprietary
Disadvantage: Does not exist.
-----------------+ +-------------------+
JNET | | RSCS V2 or JES |
DRIVER+-+Glue | +-???--+------+-----+
------+ |OSAC? | |Glue | |NJE |
|VOTS? | |OSNS? | +-----+
+--------+ |OTSS? | "
|PSI | +VTAM--+
+--------+ +NCP---+
+--------+ |NPSI |
|DMF22 +X25+ |
+--------+ +------+
X.400 / RFC822 Must follow RFC987 Requires EARN to adopt domain addresses Recommend use of 2 character country codes Unfortunately minority of sites run mailers. Recommend use of mail systems. Useful products: Softec X.400/RFC822 in Germany UCL X.400/EAN in UK
Problems: Do we wait for X.400 1988? How do we migrate to X.400? X.400 over RSCS?
Encourage use of Heidelberg X.400 on international nodes. Can extend the User Agent over RSCS. Encourage X.400 on X.25 in countries. Encourage a gateway in each country.
Useful for getting to QZCOM cheaply. Can operate full screen services (network 3270, SSMP etc) Available on all computers PADs in abundance A nasty protocol with few problems.
FTAM - NJE gateway easy (just like Rutherford Blue Book to NJE) - but very nasty. Could enhance GIFT - quite difficult. Currently no suitable FTAM available - wait 2 years? VTP and JTP are not well developed - no products expected.
Network level gateways to other X.25 (1984) Gateways or relays to other protocols the author has forgotten Way of using IBM messages over X.25 - may need a new protocol.
Month Decision to proceed 0 Order switches 0 Order line RL/Montpellier 0 Order line RL/QZ 0 Experiment RL/Montpellier 3 Service RL/Montpellier/QZ 6 Conversion CERN to X.25 8 Other international nodes 6+ X.400 on some sites 6+ X.400/RFC822 relay 6 Transition national EARNs 6+ FTAM, JTP, and VTP As available
Switches cost 10,000 UKL each
Cost of lines reduced - some installation costs
Node H/W S/W often 0 - depends on discounts.
National costs - met by country.
Management - 3 man months over current effort.
Cost of software (DEC PSI and X.400, IBM SNA)
very expensive.
P.Bryant@IBM-B.RUTHERFORD.AC.UK
|
Name
|
OrganizationalUnit
|
OrganizationName
|
PrivateDomainName/
AdministrativeDomainName
|
CountryName
How would you map P.Bryant@UKACRL ?
Reduce number as they are expensive Increase number to reduce line costs Put in low tariff countries Topology to maximise performance Locate where there is good X.25 expertise.
X.25 (1984) SVC and PVC up to 20 DCE interfaces at 64K 500 virtual circuits 800 packets per second support EARN addressing support in many countries provide management.
Ethernet boards are available from BICC and 3COM. As far as is known only the BICC board supports Pink Book. There are no plans known for the 3COM product.
Under a contract from IBM, Pat Morran, has produced a network service interface specification for the IBM PC. The aim is that it should be possible to 'mix and match' various lower and various higher level protocols from multiple sources which adhere to the interface specification.
The document has been studied by Graham Robinson and some exploratory implementation attempted. This has shown a number of minor faults but has proved the specification to be sound. Interestingly the interface will pass the Q bit thus allowing X.29 to be supported (as per transition document).
All other developments at Edinburgh are concerned with UNIX on PCs and not PC/DOS.
Exeter have produced a version of Blue Book FTP to operate with the BICC board. They have produced complete code for the board and PC. LLC2 operates in the PC rather than the board which may depress performance.
The product is monolithic and quick and dirty. Both P and Q are supported. It is being investigated by Graham Robinson and ULCC.
The BICC board has been modified to work with Intel 80286 processors which work up to 12 Megs.
BICC will be offering the Blue Book from Exeter and a Green Book PAD from Exeter. It will not be possible to modify this to support network 3270 but they have no objection to customers taking the product from Exeter and modifying it (Exeter willing). They envisage customers wanting the P end FTP and having little interest in the Q end. They do not intend to offer Grey or Red Book. They claim that PCs will be used part time for communications and thus mail, job transfer, and Q end FTP are of little interest. My view is that this is short sighted since I can envisage a PC being a server for these facilities on a network of PCs.
They intend putting the Exeter product into a multi support system which will allow Pink Book to coexist with MS net or Novell. Curiously this does now extend to running multi high level protocols. Thus Blue Book and X.29 cannot co-exist.
I asked BICC what they intended doing about the Edinburgh interface and although they had it they had not read it!. Also they wanted to support Green Book rather than Y/11 Y/12 as they claimed it was simpler and that they did not need to allow parameters to be modified.
BICC say TCP/IP can be obtained for 50UKL or PC/IP which is an updated version from of the MIT freebie. They will sell this. This will support TFTP. PC/TCP will follow with more goodies.
Dear Mats,
Thank you for your invitation to your networking meetings and your hospitality during my visit. I hope I was of service to you. Certainly I had a most interesting stay.
I attach my invoice for my expenses which I hope is in order.
Yours sincerely
Paul Bryant.
Dear Mr. Ogilvy-Morris,
Thank you for your recent request for connection to the EARN/BITNET network.
You may apply to use EARN/BITNET and it is possible to send and receive files and mail via this route if you are part of JANET. There are a number of problems in your case.
I enclose some items that may interest you.
I am sorry that I am unable to contact you electronically due to having no way of translating your address into anything useful for the gateway. This may well be a problem that information to you from EARN may encounter.
Please feel free to contact me further if you want more information.
Yours sincerely
Paul Bryant.