Paul Bryant's Networking Correspondence
The academic community is large, diverse, international, demanding, and penny less. This is as true of their networking activities as any other. So - we have the invention of an assembly of diverse networks to meet the perceived needs on various sites or in various countries and we have the users wanting easy access to anywhere in the academic world. This has led to a large number of networks and a demand for the interconnections between them.
The result has been the development of numerous gateways littered around the globe.
Gateways would be fairly easy to build if the various networks were built on similar principles but this is certainly not the case. To take a few trivial examples- The UK academic network JANET provides interactive services whereas EARN does not, in general a file transfer in JANET requires a password in EARN this is not the case. The result of the mismatches is that in general gateways cause a loss of quality of service which can be severe.
A further problem the academics have to face is that the various networks have different managements and rarely do they perceive each others problems with much understanding.
Thus the problems are- loss of facilities, awkwardness in use, and loss of reliability. Finally there is the problem of who pays for the traffic particularly is some portion of the route is over a public network.
As can be appreciated the situation is very complex and unsatisfactory, so what can be done? Ideally a single set of network standards are needed. As far as Europe is concerned the need for such a development is well understood. International establishments, such as CERN, have long suffered from various countries wanting to access their facilities using their national networking methods. It is believed that the only sensible set of protocols are the ones produced by the International Standards Organization.
About a year ago an organization called RARE was set up with the three aims of:-
The activity was initiated with a conference in Luxembourg hosted by the European Commission and has now developed a number of working groups. The work has been supported by all the western European countries' academic communities.
There was really no alternative to the use of ISO protocols. Had DECNET or SNA been selected then this would have disadvantaged certain suppliers. Regretfully, if interconnection is not a requirement the proprietary protocols can normally provide a far better quality of service. If proprietary protocols had been used the community would have been at the mercy of a commercial enterprise who could change the protocols as he saw fit whereas the community requires protocols which could not be so changed, would have a long term future, have good development potential, and be stable. The disadvantage of adopting ISO is that very few examples of the protocols exist and, moreover, several of the higher level protocols have yet to become stable. A disappointing aspect is that it will be a long time before the quality of service provided by proprietary offerings will be matched by ISO ones.
The migration to ISO is encouraged by their acceptance by manufacturers. A few years ago few manufacturers considered that they would become popular and were intent on developing their own proprietary networks. We now see that DEC is intending to migrate DECNET to be an ISO network. IBM is now offering a number of ISO protocols as part of SNA but their position is that they see ISO as providing a 'link' between various proprietary networks rather than a network system in its own right. Having seen the considerable shift in IBMs position one can anticipate even more movement in the future.
The smaller manufacturers, particularly in Europe, have been keen to adopt ISO as they are not capable of supplying all the networking components needed and only by using these standards can they offer their customers a full breadth of services. The European Computer Manufacturers Association (ECMA) have been active in developing and fostering the use of ISO protocols and the ESPRIT project of the European Commission has required the use of ISO in a number of its projects.
The current situation is that there are quite a few different networks used in Europe by academics as well as several in the States. None are yet ISO. Thus gateways are essential.
Gateways have tended to spring up where networks meet and centres of gateway excellence have grown round them. In Europe gateways have been built between most of the networks at CERN, Stockholm, University College London, the Rutherford Laboratory in the UK, and Darmstadt in Germany.
Academics are interested in four types of traffic. These are interactive, file transfer, mail, and job transfer. They do not currently have much interest in transaction work.
CERN, being an international collaboration, has network connections to many European countries together with their own on site network. There principle interest has been in file transfer and their GIFT project has resulted in a gateway between their on site network, DECNET, and the UK Blue Book file transfer. The problem has been to match the various protocols. This has been achieved by mapping them all into a virtual protocol.
The QZ computing centre of Stockholm university is a centre of excellence for conferencing. Their main interest has been the interconnection of various mail systems with there conferencing service KOM. Perhaps this is not strictly a gateway but it does enable mail to be accepted and distributed in a wide variety of protocols.
University College London has operated a gateway between the ARPA network and the UK JANET network for a long time. This provides a wide variety of services.
The RARE objective to encourage gateways between existing networks is more or less achieved although the quality of the various gateways leaves a lot to be desired. As well as the loss of quality, the gateways have tended to be produced and operated by various university sites. They require a lot of maintenance as the networks on ether side develop and change. They are not manufacturer supported, in fact they are normally supported and run on a shoe string.
For networks that offer interactive services gateways are relatively easy to produce. The reason is that a user can first access a gateway and then interact with it to provide additional information to connect onwards. Thus the problems of the gateway are given to the user rather than being enshrined in protocol. It certainly makes it difficult to traverse a gateway. Using this approach the use will also have to cope with the well known problems of double line feeds or no line feeds at all which plague such activities. None the less it is effective as the human is an excellent error correction mechanism.
Not so with file transfer as this has to take place automatically. Networks offering this type of service often have protocols that are designed to work in a single network. Thus it is difficult to send enough information with the file to a gateway to enable the gateway to send the file onwards. To traverse a number of gateways is normally impossible. An example of the problem is with sending files from EARN to the UK JANET network where the additional information required to drive the gateway has to be inserted as text at the head of the file. Fortunately this can be done easily with suitable programs and the gateway is sensible enough to strip out this information.
Mail is far easier to deal with, or at least in principle, as it carries a considerable amount of addressing information in its headers which is easy to process. It is fortunate that there are only two popular mail protocols in the community.
The first of these is the ARPA RFC822 protocol which is also used within the European Academic Research Network (EARN) and JANET. The second is X.400 which although developed by CCITT is also an ISO standard. The major problems now are how to organize addressing on an international scale. Should there be a hierarchy, if so should it be based on countries or on networks? The solutions to these problems are almost solved.
So far there is little ISO networking as the protocols are only now becoming stable. Hence the next stage is to develop the existing gateways to cope with ISO protocols or produce new ones. Plans for these are well advanced. EARN is just starting a project to evaluate X.400 and part of the work is to evaluate a mail gateway between the mail EARN uses now and X.400. The UK has had a group studying how to migrate what is now a very large network to ISO. A detailed document has now been produced and the work will start soon. It will involve a number of gateways which will attempt to migrate the network without undue disruption to the users. It will take several years.
Unfortunately ISO protocols have been designed to be very flexible and encompass many way of doing things. Thus further standards, now known as "functional standards", are needed to define the options used under certain circumstances to ensure the implementations interwork. CEN/CENELEC (the European standards organization) and CEPT (the European PTT association) have a joint activity to produce these standards and the academic community will follow these. Unfortunately there are similar exercises in the USA and it is unclear whether both sides of the Atlantic will come up with the same results. Even when all the wide area networks are using ISO the problem will still be with us as the USA academic community is likely to also migrate to ISO but to use different selections from the protocols. In addition local area networks are becoming popular and these often use different types of ISO protocols or even proprietary ones. Thus gateways are going to be with us for a long time to come.
There were 12 members present mainly from ROE and RGO.
The agenda circulated at the meeting covered a wide range of topics. The subsequent discussions were also wide ranging and explored the topics in modest depth.
There were no papers apart from the minutes of the 'Steering Committee for the Remote use of Overseas Telescopes'.
There were only a few resultant actions and all of a fairly minor nature. The major activity was to evaluate DECNET protocols over X25.
There was general agreement that the X.25 networks should be used. Most of the group felt that DECNET should be used over X.25 as most if not all of the astronomical sites run DEC machines. The use of Coloured Book protocols is not liked as it does not provide process to process communication. The problems of operating DECNET through gateways and the address problems are recognized but not thought serious. The fact that non VAX computers would not be able to take part in remote observing did not seem serious.
There is a suggestion that the ADAM code should used for multi-tasking.
The next meeting will be in 6 months or so. It is unclear what is expected to be achieved by then.
It is unlikely that much progress will be made until a model for remote observing is established. This view was aired at the meeting but no specific actions were made to produce it. Such a model would have to include:-
Reliability of instruments. Standard interfaces for instruments to control computers. Local area networks for the control computers and the protocols for them. The telescope control computer which interfaces between the local and wide area. The wide area network and its protocols. The remote computer and its functions.
The current work will probably result in some relatively modest advances based on DECNET. This is likely to be very useful services if limited.
There seems only modest resources to put into the study. Certainly the communications expertise is small.
The reasons for remote observing were reviewed.
It was agreed to study a few of the popular instruments to see what problems they posed
Remote observing has only been attempted at UKIRT. There has been little progress beyond interactive access to the computers there. A severe problem had been the lack of a VAX computer there and thus machines with networking capability had not been on the site. This is disappointing after the expectations a few years ago.
La Palma is trying to get a public X.25 line installed and intend to use it for remote observing. They seem to have no definitive plans yet but intend to try a few things out. They have a local area network there but this is only used for driving certain instruments with private protocols.
The early American experiments has not continued and the reason for this was not clear.
The use of ADAM was discussed together with the sort of information that should be sent across the wide area network.
There is a clear need to develop techniques for compressing data to enable an observer to get a view of the star field. It was felt that with more accurate telescope control and methods of automatically adjusting it by comparing the seen star field with data supplied by the observer there may, in general, be less need for the observer to see a visual picture of what the telescope is seeing.
Ideas ranged from the far sighted ones of installing process to process communication between the computers at the telescope and the remote observers computer to means of person to person communication.
DECNET is clearly popular but it is difficult to support it without a scenario of how remote observing should operate. Although the use of public X.25 is also popular on costs grounds other options such as X.25 over a leased line or the use of EARN for off line bulk traffic should not be forgotten.
Various other scientists, such as the HEP community, are putting in X.25 leased lines across the Atlantic and there may be mileage is sharing these lines.
Dear Guenter,
Last year the EARN Board of Directors asked me to investigate how EARN should migrate to use ISO protocols as a result of pressure from CEPT. After a number of meetings and discussions it was decided that the IBM Heidelberg/GMD X.400 system would be the best way to migrate or at least to start such a move.
Eight sites have been selected or volunteered to take part in an experiment which we shall start in April and will last six months. This will start with a one week course starting on the 7th April.
Dr. Thomas Schuett will be the course manager. As you have expertise on the system we would like to invite you to participate in giving the course. We have already drawn up an agenda in the hope that you be able to participate.
Thomas tells me that he has already approached you and I therefore look forward to your presentation to the group.
I attach a copy of the proposed agenda. I hope we will have a dinner probably on Monday which I would be delighted if you could attend.
With best wishes
Paul Bryant. (EARN Technical Coordinator) PEB@CERNVM
Dear Eckart,
Last year the EARN Board of Directors asked me to investigate how EARN should migrate to use ISO protocols as a result of pressure from CEPT. After a number of meetings and discussions it was decided that the IBM Heidelberg/GMD X.400 system would be the best way to migrate or at least to start such a move.
Eight sites have been selected or have volunteered to take part in an experiment to use X.400 which we shall start in April and which will last six months. This will start with a one week course starting on the 7th April.
Thomas Schuett from IBM will be the course manager. As you have expertise on the system we would like to invite you to participate in giving the course. We have already drawn up an agenda in the hope that you will be able to take part. Thomas tells me that he has already approached you and I therefore look forward to your presentation.
I attach a copy of the agenda.
I hope to organize a dinner, probably on the Monday, which I hope you will be able to attend.
With best wishes,
Paul Bryant. (EARN Technical Coordinator) PEB@CERNVM
EARN X.400 COURSE
Class Manager: Dr. Thomas Schuett
AGENDA
Monday, April 7
13.00 General Remarks T Schuett IBM
P Bryant EARN
13.30 European Network Centre G Mueller IBM
16.00 Break
16.30 Gateway: Overview B Schulz IBM
19.00 Dinner
Tuesday, April 8
9.00 S/1 and its connection to VM W Schulz IBM
10.30 Break
11.00 S/1 system generation and installation W Schulz IBM
12.00 Lunch
14.00 Transport Layer Virtual Machine D Kropp IBM
15.30 Break
16.00 Demonstration of Transport Layer D Kropp IBM
16.30 S/1 installation W Schulz IBM
Wednesday. April 9
9.00 Session Layer L Eckstein GMD
10.30 Break
11.00 Reliable Transfer Service H Ehmke GMD
12.30 Lunch
14.00 Gateway: RIO-Component U. Viebeg GMD
15.00 Break
15.30 Gateway: Message Protocol Mapper U. Viebeg GMD
17.00 Exercise: installation of the gateway H Ehmke GMD
W Schulz IBM
U Viebeg GMD
Thursday, April 10
9.00 X.400 MHS-Components W Racke IBM
10.30 Break
11.00 X.400 Virtual Machine definitions W Schulz IBM
12.00 Lunch
14.00 Experiment planning session P Bryant EARN
15.00 Break
15.30 Exercise: X.400 Virtual Machine installation W Schulz IBM
Friday April 11
9.00 User interface Examples (Noteplus) T Schuett IBM
10.00 Break
10.30 Distribution of installation tapes T Schuett IBM
12.00 Lunch
EARN (European Academic Research Network) is a large international network based on the use of the IBM NJE protocols. The network is used for academic and research pursuits and carries no commercial traffic. The network was started in 1983 and has now grown to some 350 machines. There have been a number of problems caused by the international nature of the network and also due to the tariffs imposed by the PTTs (the telephone companies). The network has to migrate to use public networks and use ISO protocols by the end of 1987 and this has caused EARN to undertake a migration project.
Although many will be familiar with the EARN (European Academic Research Network) this section outlines the early development of the network.
The Network Job Entry (NJE) protocol was developed for remote job entry and is a fairly simple protocol by current standards. It has an unusual and powerful facility which allows a document sent from a computer to be staged through a number of machines until it reaches its final destination. This allows a fairly complex network to be constructed for file transfer, job entry, and mail. It is not suited to interactive traffic.
In early 1981 a small network using NJE protocols and leased telephone lines was set up centred on the City University New York. This network, called BITNET, grew in a fairly informal way. BITNET may be translated as "Because IT's time NET". The participants agreed, as a consequence of membership, to allow other sites to connect to the network via their machines. The network has now grown to 800 machines. At first only IBM computers were connected but there are now ones from many manufacturers and in particular VAX/VMS, VAX/UNIX, and CDC machines.
IBM generously agreed to support the international links for a similar network in Europe. This included a link between Rome and City University New York. This project started with a whirlwind tour of Europe by Ira Fuchs of the City University to launch the idea. This was in 1983. Ira was the 'founding father' of BITNET. As a result EARN was set up and held its first meeting at CERN in late 1983 when Dennis Jennings of University College Dublin was elected its first director.
The countries involved are all the European Community and European Free Trade Area countries without exception.
The network was adopted in various countries in different ways.
Germany, with a large number of university IBM installations, rapidly connected a large number of computers now numbering 120. At the other extreme the UK decided that since, it already had a sophisticated Academic network, to develop a gateway between EARN and their network JANET. The other countries have fitted between these two extremes with, for example, France having 20 and Italy 17 nodes.
In many of the countries, as in the UK, gateways have or are being produced between national networks and EARN.
In all European countries EARN would be illegal without some sort of license from the regulatory authority. This is because it infringes the PTT monopoly on switching traffic between different organizations. Unfortunately the PTTs see universities as a large number of organizations.
Unfortunately these regulatory authorities in each country have differing views on how to regard EARN. Initially some were very happy to allow EARN to operate with few conditions such as in Ireland. At the other end of the spectrum the UK again features as an extreme in requiring a formal license before they would consider installing lines or discussing the tariff.
In fact EARN started at a very awkward moment in the UK when BT (British Telecom) was being privatized. In 1983 BT were reluctant to issue a license knowing that privatization with all its uncertainties was about to take place. After the event negotiations had to start again, but this time with the Department of Trade and Industry who had become the regulatory authority. They were grossly overloaded with similar requests and this delayed matters until the end of 1985. A delay of almost two years.
All the PTTs have now given permission for EARN either implicitly or explicitly. However the PTTs have imposed a wide range of tariffs and this is now causing some concern.
CEPT is the advisory body for the European PTTs.
The PTTs eventually decided that they ought to consider EARN at one of their CEPT regulatory meetings and come to a common approach to the network.
The results of their deliberations caused as many problems as they cured. The major advance was the decision to allow EARN to exist. On the negative side they decided to recommend that the PTTs impose a volume tariff. They did not define the precise nature and level of the tariff. Thus tariff introduced varies widely from zero (just the leased line costs) to a tariff as close to the X.25 international packet switched charges as possible. Such X.25 charges are high! Certainly several times the leased line costs for modest line utilization. Several PTTs have yet to decide on a tariff which is causing some concern. Certainly several PTTs are making ominous noises that volume charges are on the way.
The international X.25 charges are high. The PTTs expected these networks to be used for interactive traffic or transaction use. For interactive use the volume is low and the duration long which makes it fairly cheap. The transaction use is characterized my short high value activities, for example, the network costs of transferring a couple of million pounds between banks is a few pence. The academic traffic is characterized by being of high volume and low value. For example, the loss of a few high energy physics events is not important but the cost of transferring them is fairly high.
Thus the imposition of volume related tariffs is hard for the academic community to carry.
The German PTT is about to impose a time related charge based on the ISDN (integrated Services Digital Network) one. This is presumably since they expect most data traffic in the future to use this service. The overall effect will certainly be to have a tariff lower than the one which would have resulted from X.25 related charges. There are problems in that it is unclear how you measure 'time' on a leased line.
Negotiations are taking place with CEPT to see if a better tariff can be agreed and for it to have a common basis across Europe.
The PTTs have the problem that they are unable to give preferential treatment to any specific group of users. Thus any tariff appropriate to academics must also be offered to other customers. It is unclear how you can base a tariff on the type of usage and not give room for a lot of misuse.
As part of their package of recommendation, CEPT, want EARN to migrate to use ISO (International Standards Organization) protocols and to use public networks by the end of 1987.
It is important to realize that EARN is a fairly unsophisticated network which is very stable and providing a practical and reliable service to the academic community. Networks based on ISO protocols have not reached this stage. Indeed, the higher layers of the protocols are only just becoming stable and implementations, if available, are more often than not of an experimental nature.
Thus a transition is no easy demand as it would be foolish to replace the current service with one which is not at least as good. Moreover the characteristics of the two styles of networking are radically different. The use of ISO and public networks is based on the computers being connected to a network consisting of packet switching exchanges. EARN is based on interconnecting host computers based on store and forward principles. It is very unclear how such a migration could take place.
With this uncertainty as to the quality and time scale of ISO protocols products the confidence that the migration can be achieved by the end of 1986 is low.
Once EARN is using ISO and public networks then it is difficult to see how it could be regarded as an identifiable network. Also once it is in this state it is hard to see how CEPT or indeed EARN could demand any particular high level ISO protocols be used as long as these can operate over the public networks. Indeed, to do so would be to discriminate against this community.
In practice there is some expectation that the PTTs will allow EARN to continue until ISO products can be shown to be as reliable and usable as the current NJE ones. Certainly EARN and CEPT will have had further discussions to consider its continues existence and the form it should take. Indeed, it may well be that EARN will have to continue to use leased circuits if the PTTs are unable to accommodate the very high traffic levels of EARN regardless of the protocols used.
As a first stage of the migration to use ISO protocols EARN is about to undertake an experiment in using X.400 message handling protocols (the ISO mail protocol) between a number of international EARN sites. The system selected has been produced by IBM Heidelberg and GMD Darmstadt. It was exhibited at the Hanover Fair in the Spring of 1986. A meeting was held shortly after at Heidelberg to launch the project which will run for six months and decide just how far the system can replace the use of NJE.
It is unlikely that the result will be a 'yes' or a 'no' as X.400 is radically different from NJE. None the less it will provide a valuable start. It must not be forgotten that a large part of EARN traffic is mail.
The questions to be answered are:-
No doubt there are many other aspects to be studied.
At the conclusion of the study in October 1986 a decision will have to be taken on the EARN migration policy. The decisions include:-
The project will keep close contact with the other activities in this area particularly by the RARE organization (the association set up to coordinate European academic networking) and the CEN/CENELEC/CEPT (European standards organizations) functional standards activity.
This project has been generously supported by IBM
EARN is managed by a Board of Directors who are responsible for all aspects of the network. There is one Board member from each country. IBM are not involved with the executive management of the network although they do generously provide considerable and valuable advice. They also have provided material help in many ways to ensure the network prospered.
The Board used to meet four times a year. Such a large group had difficulties making decisions and was expensive on people's time. An executive of just the EARN officers now meets in the basement of Paris airport every few months and the full board only meets once a year. As an aside, the use of the airport is highly convenient as it removes the trauma of being stuck in traffic jams and missing flights.
EARN is an association set up under French law. This enables EARN to negotiate with CEPT, IBM and other organizations effectively.
At one time it was thought that EARN could be a fairly informal network and would require little management. BITNET was run in this way. However this has proved not to be true particularly as Europe is not as homogeneous as America. BITNET itself has found that as the network has grown management has become important. They have set up a small group to administer the network called BITNIC. They make sure things run smoothly and they also run an information service.
EARN is considering having a small permanent staff as it is clear that like BITNET it is not sensible to expect the Board Members or the association officers to be able to give sufficient time to EARN to ensure its smooth running. Fortunately IBM has put quite a bit of support into the development of the NETSERV system which provides means of helping to manage the system. This can be no substitute for some human management.
As EARN is specifically for non commercial use the BOARD has had to produce a charter to define the uses to which the network can be put. It also defines the organizations which can become members. This is most important as BITNET has similar rules and it is vital to have a free flow of traffic between the networks. It should also be added that the rules imposed by the PTTs are far stricter in Europe and if commercial use was made of the network it is likely that the PTTs may be less tolerant of EARN.
The basic network only provides for file transfer, mail, and messaging. Additional facilities are needed to manage the network and provide some additional facilities for the users.
The principle facility is NETSERV. This is a complex system which runs on the principle node in each country. It provides mechanisms for managing the network and providing information services to the users.
Each computer in the network must contain routing tables to control traffic and it is essential that these be kept up to date and consistent. This is achieved by a network change being reported to the national NETSERV by filling in a proforma. This information is then checked and sent to the European NETSERV centre at Darmstadt in Germany. The European updates are then sent to BITNIC (a similar organization in the USA) where all the information is again checked and the routing tables constructed. These are then distributed back through the European NETSERV and national NETSERVs and finally to the nodes themselves. This takes a few days to accomplish and takes place about once a month. Although tedious it is essential if the network is to remain consistent.
NETSERV contains a large number of information files. Users may request any of these files which contain the lists of nodes, news, technical information, and any other useful data. There are about 400 of these files. About 100 of the files are 'restricted' as they contain 'execs' and other information which is only of use to network administrators. Information files are updated by updating the local copy and NETSERV then ensures that the new version is distributed to all the other NETSERV sites.
Since mail is one of the most popular uses of EARN a directory service is being provided. This will provide for locating where a person is or for finding people with particular interests.
While mail service and their associated distribution lists give a valuable service there is also a need for a conferencing service. Unlike mail a conferencing system allows information to be selectively requested by a user and removes the requirement for the person sending the information to be aware of who is receiving it. A number of systems such as PORTACOM and GRAND are being evaluated.
About twice a year the technical experts in EARN meet to discuss the technical development of the network.
From these meetings it is clear that the development of a high quality large network is far from easy.
The EARN network is subject to loss of service rather more than X.25 networks. This is because the service depends on the availability of large machines which tend to have down time for various scheduled and non scheduled reasons. Quite a lot of study has gone into how to keep the network as available as possible and to provide early warnings when scheduled down time is expected on essential nodes. Some of the reasons for failures can be quite bizarre such as salt on the insulators causing failure of the public electricity supply.
EARN has adopted the RFC 822 mail protocol (an ARPA network standard). This has caused some very long discussions as it is only available on a subset of the operating systems. The benefits of using a mail protocol are not immediately obvious to some sites as the file transfer mechanisms allow mail like services as in general no passwords are needed to send a file. The real benefits are starting to be seen with the large number of gateways which are being produced and often demand that RFC 822 is used. In addition more use is being made of distribution lists and eventually it is hoped to be able to send mail to 'real people' rather than cryptic user ids. The technical group will soon be discussing whether it would be appropriate to migrate from RFC 822 to X.400 as the rest of the European academic networks are moving in this direction.
Even the humble task of naming nodes takes quite a bit of discussion. Whilst in principle a node can be called whatever the site wishes as long as it is unique, there is some merit in making it meaningful. Thus the first two characters normally define the country, the next few the site, and the final group the type of computer and operating system
At every meeting there is the discussion of the bugs and features in the various implementations of the NJE protocols. This is very useful as a number of problems have been solved from the combined knowledge of the group.
The group continues its work using the mail distribution services throughout the year.
The network provides a fairly restricted range of services. None the less it is proving very popular. The principle reason is that no special arrangements have to be made to use it and a very large international population can be contacted very cheaply.
It is unfortunate that many of the other networks have restricted geographical areas, such as the UK JANET academic network. Or they are difficult to get permission to use, for example ARPA. Or they are expensive and have restricted facilities such as the public X.25 networks. However, it is important to produce gateways between EARN and these networks to work towards the total connectivity of the academic community.
Many of the lines are now reaching saturation and plans are being formulated to increase the bandwidth on some critical links to 48K or more. The most urgent need is for the connections to the USA and a satellite connection at 56K is under urgent consideration.
In general the international lines are financed by IBM while the national ones are financed by other means.
Clearly when IBM support terminates at the end of 1987 the network will have to seek finance from elsewhere. It is very unclear where this will come from.
It would be difficult to charge users as this would involve a very expensive organization to administer it, to collect the data, and to issue the bills. Moreover, inventing charging rates which are fair in the light of the various charges levied by the PTTs would not be easy.
Subscriptions are a better alternative but this is open to criticism by sites which make little use of the network.
The principle problem is the high premium charged by the PTTs on international lines within Europe. The reduction of these charges would reduce the problem and also allow greater capacity to be installed between countries.
EARN is but one of a large number of networks for use by the world academic community. It is one of the few international ones. Part of its attraction is for international traffic and it is thus important for it to gateway to various other networks which are normally national.
Most European countries now have national academic networks or are planning them. The existing ones use a variety of technologies. The planned ones are all destined to use the ISO protocols. Hence eventually one can envisage a Europe with only one homogeneous set of networks.
The day of 'perfection' is a long way off and so a wide variety of gateways are needed. In fact, almost every country needs a different one. Gateways already exist in the UK and Ireland (which, incidentally, use the same network technology - the so called 'Coloured Book' protocols). Sweden is well advanced with the production of a gateway between SUNET (the Swedish academic network) and EARN. Germany is producing a gateway between DFN (the German academic network) and EARN. DFN is the first academic network to use ISO protocols and will initially offer X.400 and so the work of Heidelberg which EARN hopes to use is closely related to the DFN gateway.
EARN is not the worlds most elegant network. Neither is it rich with facilities. Its strength lies in the fact that it is installed, it works reliably, it is cheap, and it is international. It is providing a valuable service to the academic community now.
Dear Thomas,
Having at last managed to return to my office for a day or two I can take the opportunity to thank you on behalf of EARN and the participants of the X.400 project for organizing the course for us. I have no doubt that my 'experts' are now a lot more expert than when they arrived.
I expect you look forward with as much as I do to see how it all goes. I suspect rather slower than we would like- but that's life.
So my sincere thanks for you, your staff and the lecturers for their efforts. Perhaps if funds permit we should have a final, and I hope, celebration dinner when we have finished.
With best wishes
Paul Bryant.
Dear Robert,
I expect you will be aware by now that, as a result of the problems with Y11/Y12, I have suspended the groups meetings.
I attach a letter I sent to the working group which outlines the problems as I see them. I also attach a note that I sent to IST/-/2 explaining a number of problems I observe.
I am most anxious for the functional standards to be produced as quickly as possible and certainly my colleagues are very anxious for these to be used extensively in the work of migrating JANET to ISO standards. On the other hand it is vital that the standards are 'good' and 'correct'. Thus I believe it is vital that Y11/Y12 work should be fully harmonized with the activities of CEPT in this area or we shall find that they are unusable. It is most regrettable that this could be seen as a delaying or obstructionist tactic on behalf of the UK and it is therefore vital that the UK position is clarified (if indeed the UK support my position).
I am therefore of the view that SOGITS should consider the problems I have encountered.
I have two areas of concern.
Therefore I would put forward two proposals :-
Perhaps we should consider these topics at the pre SOGITS meeting which, if my diary is correct, is on the 25 of this month. At this meeting it would be valuable to have any output from the IST/-/2 meeting which regretfully I could not attend.
I look forward an early solution my worries.
Best wishes
Paul Bryant.
The X.400 responsibilities are listed below. The site responsible for an activity is expected to collect information from all sites on that activities as well as doing appropriate experiments. The list drawn up at Heidelberg was:-
Reliability Hans Goossens Holland Conformance Staffan Johansson Sweden User interface John Nolan Ireland Replacing RSCS Olivier Martin CERN Gateways Olivier Martin CERN Naming Addressing ??????????????????????????? Problem of mounting Gerard Pitteloud Switzerland Overheads Staffan Johansson Holland Maintenance ??????????????????????????? Enhancements Jukka Korpela Finland Function Standards ??????????????????????????? RARE liaison Heidi Bergh-Hoff Norway EAN tests etc. Heidi Bergh-Hoff Norway Accounting Michel Auffret France ??? Cost of running Michel Auffret France ??? Prob. of Char. set Gerard Pitteloud Switzerland Lead site Paul Bryant UK Use over 3705 Peter Girard UK
Please reply if the list is not correct or if you think there are further activities.
Naming. I have spoken to a number of gurus and the following appears to be current thinking. Heidi- please consult with Alf Hansen to see if it corresponds with his view. :- Country name- 2 character ISO name-
United Kingdom GB
France
Holland
Germany
Ireland
Norway
Sweden
Ireland
Italy
Finland
Switzerland
Belgium
Iceland
Have I missed any?
Administration Management Domain ADMD- This should be provided by your country administration. Suggest we leave blank for now.
Private Management Domain PRMD- should be something like 'academic community' Shall we use EARN for now? Could be different for each county. Uk may prefer to use AC.
Organization name- Should be the site name (rather than machine name) and should be short and meaningful such as- Rutherford, RUNIT, CNUSC, QZ, Nijmegen. Can we decide on the full list please?
Organizational Unit- optional- could be 'computing division', 'physics'.
Heidi- please check with Alf.
DTE numbers so far:- Salford 23426164321090 UK 234223519191xx (xx to be supplied) EAN
Can we have any other DTEs please.
The expected start dates are :-
Ireland June Holland June Norway June Sweden May Switzerland May CERN May UK July Germany June France ? Finland May Italy ? Salford now ENC now
Michel Auffret- sorry you could not come to Heidelberg. The group decided that they would like to have the next meeting in Montpelier in (lets say) late August or early September. Do you think you could organize it. We will need one night hotel and a meeting room and I guess there will be about a dozen of us. Of course- we would also like an 'interesting' evening. Will that be OK? (What happens when you're not about!). Also we did not allocate you any area of special interest. Could you please give this some thought. Thanks.
The first reports are due on 2 May and should be sent to the X400@CEARN distribution list, this should be done regardless of progress.
Comments of interest should be to the distribution list.
Best wishes and thank you for attending the Heidelberg meeting.
Paul Bryant .
Dear Mrs. van Heugten,
Air fair 210.00 pounds Train 14.60 pounds Honorarium 100.00 pounds Total 324.60 pounds
I enclose the used tickets.
I do not wish to claim for hotel costs.
Thank you for the opportunity of speaking at SEAS and I hope that the manuscript I recently sent you was satisfactory.
Yours sincerely
Paul Bryant.
Dear Brian,
Thank you for your letter containing the job specification for the proposed EARN support post.
The specification is for a broad range of duties and my experience is that we will be unlikely to find anyone who will tackle both the support duties and the software enhancements in the last paragraph of the spec. I think that we should concentrate on the support side as this is where the pressure now is. I think I have the software side well under control. Since I spoke to you last that side of thinks has all come together very nicely and it can continue to develop with little effort. In fact, much of that extra development is also for Rutherford's own purposes. So - I have re drafted a bit.
I have made a few other changes. The first change is to include help with my duties as EARN technical Coordinator and leader of the X.400 project. The second change is to leave out the comments on mimicking CMS features as I think we are really talking about enhancing the visibility of the networks across the gateway which is a more general requirement. Lastly I have left out the 'Service improvements' (not that these should not be furthered and discussed by the user group).
I guess I will have to write and ask you for support so I have drafted a first stab at such a request.
I will show this to my management and perhaps we could have a further discussion to finalize it in a week or so. I have no doubt that the user group will be enthusiastic as they must be getting tired of having to wait for me to come back from trips before getting the odd minute of my time! None the less after the next iteration I will send it for comment to (say) 4 of the users who came to the last meeting.
I am most grateful for your kind offer as I am currently finding that the burden of support is using a lot of my time which I would prefer to dedicate to the other EARN duties I have.
Incidentally the Hedelberg X400 launch meeting was most successful and I look forward to an exciting and hopefully successful project.
Yours sincerely
Paul Bryant.
cc C Setford, IBM Hursley, B Davies, Rutherford
Dear ?,
The UK academic community was provided with access to EARN towards the end of 1985 after a license had been obtained form the Department of Trade and Industry. Access is provide via a gateway located at the Rutherford Laboratory which allows all UK academics to use EARN via the JANET network. This gateway is now fully functional. The finance required to build the gateway was generously provided by IBM.
It was initially believed that the user support of the UK community would be a marginal activity. This has proved to be incorrect and it is turning out to be virtually a full time job. In addition the UK EARN board member has taken on the duties of both the EARN technical coordinator and now the leading of the X.400 EARN migration project. Rutherford is therefore finding that the support of EARN is absorbing far greater human resources than expected. This reflects the increasing use of the gateway which is now at 70 Mbytes a month and rising.
In the light of this Rutherford is seeking temporary additional support. It is proposed that this should take the form of a 'user support' post for a two year period. The cost is 2500 pounds per year.
The post will improve the support of EARN and give a far more satisfactory service to both UK academics and those in other parts of the world accessing the UK.
Rutherford would be grateful if IBM would consider providing this additional support.
The job specification is appended in the form of the job advertisement that we would hope to issue.
Yours sincerely
Paul Bryant.
The Rutherford Laboratory operates a gateway between the European Academic Research Network and the UK academic network JANET. This provides international network services for academics throughout the western world. There is a vacancy for a post to provide user support and various other duties to support the team operating the service. Applicants should have an interest in networks and an interest in communicating with people. There will be some travel including European.
The duties will include:-
To be available to give advice by electronic mail, telephone and personal contact. To give appropriate advice, particularly on addresses and services available on the networks. To collect and collate users experience with a view to improving the service. To visit JANET sites which have special needs. To analyze any reliability problems. To organize user meetings and document them. To maintain the EARN information services to EARN and JANET users. To run a newsletter and conferencing service for the gateway users.
To maintain the list of the member sites of EARN in the UK. Maintain distribution lists, electronic and postal. Collection and analysis of statistics to determine how the service is being used and to predict usage trends. To assist the EARN technical coordinator with his duties associated with the whole EARN network.
2 years ago I produced a proposal paper for Rutherford Laboratory to host the EARN/JANET gateway. In consultation with Operation and Support groups I included one man years worth of effort for both groups.
The relevant Group Leaders Meeting decided that the support of the gateway could be done with existing effort. That is except for the gateway development for which IBM was offering 6 man months of support.
Projects rarely run to plan!
The gateway code has been (almost) completed within budget but late due to illness and the high demand for RSCS support.
Operations support required has been close to zero and not likely to increase.
Support group has provided no support due to loss of support staff.
Minimal support has been provided by myself and Tony at a level of 2 days a week. This is high per user due to the newness of the service but may not decrease as the service improves due to the increasing number of users. (Traffic is currently running at 60Mbytes a month and will rise to 300 Mbytes a month which is the maximum the line can be expected to support).
Development of documentation and running a user meeting and setting up the user group has absorbed about 2 months of my time and has been done poorly because of lack of time. The maintenance of address lists sending out documents and so on has taken 10% of a secretaries time.
For reasons that I do not understand I am the EARN technical director as well as the UK Board of Directors member and this has taken 15% of my time particularly with the development of the X.400 project.
Excluding the X.400 project and the gateway software which IBM is funding we are spending about 75% of a man and providing minimal user support.
IBM is offering to support a post for 2 years for user support and help with my duties with EARN. I am negotiating with IBM and attached is correspondence with IBM.
I believe that this will solve the problem IF a suitable candidate can be found.
The gateway is now supporting considerable traffic and providing a valuable service to the academics. I have a number of very happy users. I believe that it is enhancing the reputation of the laboratory if we ignore the professional Rutherford sniping community.
Dear Martin,
I expect you are familiar with the CEN/CENELEC/CEPT functional standards project which is expected to have considerable effect on our academic networks. I am the chairman of the Y/11 Y/12 working group which is producing a functional standard for the CCITT X.3, X.28, and X.29 recommendations. This work is now well advanced but has recently been suspended as we understand that CEPT is producing a 'functional standard' (my description) for X.25, X.3, X.28, and X.29 for European public networks which is not part of the CEN/CENELEC/CEPT activity and thus we do not have access to their work. None the less it could have considerable effect on it.
However the work is progressing by correspondence. This work will no doubt effect your own work within DFN and I am therefore sending you a copy of the working draft in case you or your colleagues may wish to comment. Unfortunately there are no Germans on my working group.
With best wishes
Paul Bryant.
Dear John,
Thank you for your very welcome letter. I appreciate all the comments I can get - and there are few. I enclose the latest draft which will answer some of your points.
I would value any further comments you have on the new draft which you will find significantly altered from the one you have. You will also see that there are still a number of points still to be resolved although I think we have made considerable progress. (I hope you agree).
Thanks for your interest and I am sure CTIG would value you support if you can ever find the time.
Yours sincerely
Paul Bryant.
Attached is an agreement with IBM for which I would like a signature. It is to allow us to evaluate a piece of software which is IBM property. I see no objections to the wording from my side. You will note that no finance is required. I shall be happy to discuss it with you if needed.
Please could you arrange signature as soon as possible as I am anxious to progress the project.
Dear Jeff,
You asked me at the Heidelberg meeting for possible topics on telecommunications.
There are a number of very serious problems with the PTTs which Require urgent attention and the SEAS conference may well be a vehicle for exploring some of them and perhaps setting up some mechanisms for solving them. I list the items in no particular order.
1. The PTTs are very keen to sell us services such as the public packet switched services. We would like to use such services if they could provide the service we require. In discussions with BT international they refused to reveal the level of international traffic and they revealed after some pressure that the lines to some European countries were one or two 9.6K lines and to the States 7 9.6K lines. Moreover they did admit that one could not expect more than 2000 bits/sec on a connection.
I find these figures frankly staggering. The academic community is expecting to have 64K lines across Europe (or equivalent) and would like to use public services but the capacity is just not there.
Therefore the conference should attempt to explore the PTT plans across Europe and expose then to critical appraisal. The PTTs must be dissuaded from just giving bland sales presentations and lists of services but must provide hard figures, their plans and how they expect to meet the customers requirements. Perhaps some users could give their expectations on traffic levels, performance, and quality of service.
EARN is perturbed by this as they see no way in which the public networks can provide a comparable service to the current leased line one and yet is being pressured by CEPT so to do.
2. The PTT tariffs for data services are very high for the bulk traffic the academics expect to pass across them. EARN is expected to migrate to public networks and this would raise costs by about an order of magnitude over the leased line costs. Is this reasonable?
Of particular interest is why the premium on trans European traffic should persist when we see the unification and breaking down of barriers within Europe on other fronts. The PTTs may like to defend these tariffs and I am sure that the European Commission would like to see them reduce.
There may well be cases for differential tariffs for classes of traffic. Thus bulk low value traffic of the academics could attract a lower tariff than the high value low volume tariff of (say) the banks.
3. CEPT is a very obscure organization. I am sure others, like me, would be interested to know who the body is, how it operates and whether it is in the public interest. To the observer it appears to be an organization that PTTs hide behind when approached on tariff and services yet they run the organization.
4. RARE, the new European network organization should have an opportunity of stating its objectives and how it is getting on with achieving its goals. This subject is of great interest for academics and I am sure others will be interested in how by uniting more can be achieved. Peter Linington or Klaus Ullmann could talk on this.
5. Many organizations with which I am not familiar are running extensive networks and it would be interesting to see what they think of the PTTs and how they organize their services. Banks, airlines, railways, insurance companies and government.
6. An exposition of the ISO protocols would bore me stiff!
7. ISDN is another well publicized service. Rather more interesting is when international services will be available and what they will cost.
8. For entertainment a discussion on the PTT monopolies, liberalization and the like would be interesting. Clearly liberalization and competition should improve services and reduce costs but on the other hand may lead to non communication between various operators.
9. CEN/CENELEC/CEPT are drawing up functional standards for networking. Can we expect this to force the PTTs to provide uniform services across Europe? In fact what effect do we expect this work to have. Jan Van Herp heads up this work.
10. I am fairly sure that the PTTs will be only too happy to attend and give their usual very boring sales talks and this must be resisted to the utmost. The last thing we need is that. We really want to know how they operate and what is happening where we cannot see. Thus we need to get at some useful names. On CEPT tariffs Thomas Hubner springs to mind as EARN has been negotiation with him. Ken Thompson of the ITTT in Brussels is an old adversary of CEPT and will be good for a cutting exposure of something. Roth is an expert of the PTT X.25 networks Europe wide.
11 ? of the International Telecommunications User Group should have an interesting tail to tell as his organization is permanently locked in battle with the PTTs.
12 An interesting talk would be about the IBM VNET network which must have interesting information on how the various PTTs perform. As a side issue an interesting question is why IBM is not using SNA in any quantity on this network. Also why they need to hack RSCS to pieces to make their network work and do not give customers the benefit of this work.
13 Although I gave a progress report on EARN at the last SEAS no doubt a further talk which concentrates on the problems with the PTTs would be interesting.
I hope you find a few items of interest and I will be happy to help you further if need be.
Yours sincerely
Paul Bryant.
Thomas Hubner, CEPT Coordinator Ken Thompson, Commission of European Community Wolfgang Roth, Deutsche Bundespost Klaus Ullmann, DFN Jan Van Herp, CEN/CENELEC Peter Linington, Joint Network Team
The ISO communications standards have progressed to the point where it is becoming possible to provide products based on them. It has become apparent that since these standards have many options it is easy to produce products which conform to the standards but which cannot inter work. The purpose of a 'functional standard' is to impose restrictions on implementations of sets of protocols to ensure that they will inter work. CEN/CENELEC, the European standards body, and CEPT, the advisory organization for the European PTTs, have set up a work item to produce functional standards primarily for use within Europe. This paper outlines the history and organization of the activity. It defines how far the work has progressed and how it is likely to progress.
It was in the Autumn of 1984 that CEN/CENELEC (the European standards organizations) and CEPT (the advisory committee for the European PTTs agreed to produce a range of functional standards for use within Europe.
In 1983/4 the European Commission hosted a number of meetings aimed at harmonizing the use of communications protocols particularly in the academic field. This was commonly known as the Zander initiative as the work was initially proposed by Professor Karl Zander of Hahn-Mietner Institut, Berlin. This work resulted in the COS (Common use of OSI Standards) documents which dealt with:-
Connection mode network layer COS-1 Transport layer COS-2 Local area networks COS-3 Tripe X (the X.3, X.28, and X.29 recommendations) COS-4
The work was, perhaps, a little premature and little practical use was made of it particularly as the funds 'dried up' and there was no early follow up.
However, the work was not in vain as it was adopted by SPAG who produced the GUS (guides to the use of standards). This group extended the work to cover many more protocols, in fact it was almost a total cover of the popular protocols expected to be in common use and issued as standards or recommendations by one or other of the standards bodies.
By this time it had become clear that 'interpretation', 'harmonization', and 'inter working' were important issues which ISO was not addressing. Effective, products in a multi vendor environment require far more than the basic standards - they require documents on how these standards should be used in specific situations. The standards were designed to be all things to all men whereas the customer wanted some very specific services. Thus the term 'functional standard' was coined to cover this area.
A functional standard specifies the application of one or more standards in support of a specific requirement for communication between computer systems. It does not alter the standards to which it refers but makes explicit the relationship among a set of standards used together and may also specify choices of options and values of parameters to be used.
A document of agreement setting up the co-operation between CEN/CENELEC and CEPT is known as HD 40001. The overall responsibility of the work lies with SOGITS (the Senior Officials Group for Information Technology Standards) which is a committee of the European Commission which directs CEN/CENELEC in this area and a similar group in CEPT. At the next level there is ITSTC (Information Technology Steering Committee) which is responsible for the political direction of the work. Next is ITAEGS (Information Technology Ad hoc Experts Group) which monitors the technical progress of the work. This committee has representatives from CEN/CENELEC, CEPT and the chairmen of the working groups also attend. Each of the functional standards has a working group associated with it which is either run by CEN/CENELEC with observers from CEPT or is run by CEPT with observers from CEN/CENELEC.
ITAEGS first task was to produce M-IT-01. This is a memorandum defining the terms of reference of the activity. This is more or less complete. The group is now dealing with the technical issues between groups and also planning the future programme.
SPAG had produced a large list of potential functional standards in their documents. This was adopted. Priority items were selected and formed the basis of a document M-IT-02 which was a list of the work items. This document is continually being modified to reflect the work of the working groups and the addition of new work items.
Each of the working groups has met on several occasions to produce working draft functional standards and eventually drafts for 'voting'. The final draft is then distributed to the member bodies and a period of three months is allowed for comment. Voting on the draft takes place at a meeting and there is a fairly complicated set of rules to ensure that the process is 'fair'. The resulting document becomes an ENV (European Pre Norm).
During the initial stages of the activity ITAEGS produced drafting recommendations to ensure that the documents achieve a uniform quality of presentation. For example, the first few chapters have identical headings in each standard and even the content of these chapters is controlled. The later chapters are less constrained but none the less care has to be taken with the language to ensure that the meaning of the text is clear and unambiguous.
Unlike an ISO standard, a functional standard may include as appendices tutorial material and advice for implementors. This is indicative of the fact that a functional standard is likely to be used by implementors and there is merit in attempting to influence implementations in following certain good practices. The tutorial and advice information is not part of the functional standard and need not necessarily be followed.
Each functional standard is designated by a code (a scheme invented by SPAG). The first letter signifies the type of functional standard:-
T Layer 1-4 A Layer 5-7 Q,S Content, Repertoires R Relay Y Non OSI C Telematic combinations
The initial functional standards are:-
T/621x CSMA/CD Connection less CEN/CENELEC T/31x Transport service over X.25 CEPT A/31x Access to public MHS CEPT A/32x Access to private MHS CEN/CENELEC Y/11/12 X.3, X.28, and X.29 CEN/CENELEC Q/21x Character-coded text CEN/CENELEC A/221 Teletex CEPT
It is expected that functional standards for these will be voted on by the middle of the year.
A second set of work items are now being planned:-
A/11 FTAM A/3xx MHS access protocol (P3 and P5) C/11x Teletex service Q/241 Videotex content T/32,T/4x1 Connections to wide area networks T/611 CSMA/CD connection orientated network service T/622x Token bus connection less network service R/1x,R/2x Relays between connection less connection network service
A third set of work items are being planned to start at the end of 1986:-
A/231,241 Teletex FAX mixed mode A/325 MHS access P7 C/13x Mixed mode service Q/113-4 Mixed mode formats Q/22x Mixed mode content T/2x Telephonic WAN T/621 Token bus connection orientated network service
The above two lists are subject to change.
It is interesting to note that the split between 'high' and 'low' level protocols is at the top of transport level. There is an argument that it would be better made at the top of network level. The reason for the current split is historic in that when the work started transport has a far more stable definition than network and thus this division was less confusing. A decision now would probably favour network layer.
There are a number of other similar activities. In particular the National Bureau of Standards Open Systems Workshop is undertaking similar work in a rather different way. So far liaison has been by means of participation in their work by a few people also involved in the functional standards. It is important that eventually the results are harmonized if differences in European and American products are to be avoided. ITAEGS is considering ways of closer co-operation with America.
The MAP (use of OSI in manufacturing), TOP (use of OSI in office automation) and COS (Corporation for Open Systems) projects are rather more like the SPAG. This is because the work is manufacturer and/or product led. None the less their work is closely associated with functional standards.
There is a real problem in ensuring that all these groups eventually agree common functional standards.
It is expected that manufacturers will produce equipment that conforms to the functional standards. Such conformance claims need testing if the customer is to be certain that he can believe the manufacturers claim. Also a manufacturer needs to have his equipment tested to ensure the quality of his product. To this end a number of contracts have been let to develop conformance testing centres. Eventually this should lead to the certification of products.
Fairly detailed plans for certification by CENCER (the CEN certification organization) have been drawn up. So far it is not clear when these centres will be available and when certified products will be available.
Recently the ITAEGM (Information Technology Ad hoc Experts Group in Manufacturing) has been set with similar terms of reference to ITAEGS but in the manufacturing area. This work is closely associated with the MAP and TOP activities.
One would not use OSI standards for procurement because of the vast array of options. Functional standards are closer to a procurement standard but even then these are insufficient in that a piece of equipment needs to conform to other things, for example, a functional standard applied to a start-stop mode DTE does not demand that it has a keyboard let alone one with particular characteristics. Thus there is probably a further level of abstraction from the functional standards to produce procurement ones.
The success or failure of RARE depends on whether inter working between different products on different networks in different countries. Thus functional standards are of vital interest. It is most important that an interest is taken in the documents at an early stage when input can be made to ensure that they meet the requirements of the community and are also of a high quality.
Dear Jean-Claude,
I enclose the expense claims for the people who came to the Heidelberg meeting. I believe IBM has given the EARN association money for this. I am still expecting a few more but if they do not claim the money will last a lot longer! The deduction of 200DM from Goosen's claim and the addition to Peter Girard's is because Peter lent him some money as he came with almost nothing!
It would be useful if you could keep a record of expenses paid for the X.400 project as this money will be paid on my request and I would not like to over spend (also I would not like the association to spend it if they fall upon hard times).
With best wishes
Paul Bryant.
Recruitment has always been a moving and obscure target for those requiring staff and I have a long memory.
There appears to be 'rules' which are applied in an arbitrary way. For example, at times salaries seem to be flexible (upwards) and at others rules are applied with some rigidity and we loose good recruits. The civil service commissioner often is at the back of such differences. In fact the purpose of having a commissioner to allow certification seems a waste of effort as just about no one takes advantage of it.
We have tried various experiments, like open days. It is disappointing that after such experiments which show early promise there is a gradual reversion to the 'traditional' scheme. i.e advertise, board and offer. We do not seem to have progressed very far with combining public relations with recruitment. The experiment with open days which I had a lot to do with was promising.
We do not seem to have learnt that recruitment is a seasonal activity. In the Spring/Summer graduates are looking for jobs. In Autumn/Winter they are still looking for jobs - but only the dross - and I use that word advisedly.
The board method of recruitment is guaranteed to give a negative reaction from the candidate. In my experience it is usually an obscene session of the board members trying to see how clever they are or searching desperately for a question. It is no pleasure for any of the parties. In my view the board does not get a good idea of the candidates abilities in a less stressful environment. The rest of the world seems to have gone for a small number of man to man interviews of a far more informal type with the people with which they are going to work.
The time taken for recruitment is a disgrace. If formal boards were dispensed with recruitment could be on a more continual basis where interviews could be arranged at short notice to see one or two casual applicants. Ideally the candidate would have an offer subject to health and documents before he left the site.
I am, of course, an amateur in recruitment as are 100% of the rest of the laboratory.
As to the letter attached to the note I plead 'not guilty'.
Unfortunately I have every confidence that we will continue to recruit according to the rules until doomsday.
Dear Dr. As'ad Abdul-Rahman,
I enclose a few documents about EARN for your interest. Should you wish to connect to EARN in some way then you should address your request to:-
Dr. David Lord (EARN Director) D.D. Division CERN Geneva 7 1211 Switzerland.
Connection to new countries have to be considered by the EARN Board of Directors at their regular meetings.
I also enclose the latest report of the Rutherford Laboratory. At Rutherford we have a gateway between JANET (the UK academic network) and EARN. We did this as we already have a very sophisticated network but we also needed access to the facilities of EARN.
Thank you for your interest and I hope we can look forward to greater cooperation between the academic communities of our two countries.
Yours sincerely
Paul Bryant.
The CEN/CENELEC/CEPT working group Y/11 Y/12 is producing 2 functional standards associated with the CCITT recommendations X.3, X.28, and X.29 which are widely used for interactive services over X.25 networks. Y/11 deals with the packet mode DTE (host) to PAD connection and Y/12 deals with the PAD to start-stop mode DTE (terminal).
It is well known that services using these recommendations are less than satisfactory. In many cases the user is faced with having double 'line feeds' between lines or none at all. 'Break in' often has no effect and often has undesirable and surprising effects such as closing a call. The quality of implementations of the protocols is often poor. Many PADs do not respect the recommendations in that parameters may not be implemented or if implemented have curious or no effect. Packet mode DTEs are little better in that they often fail to set parameters and are happy to leave PAD and DTE in blissful ignorance of each others characteristics.
The functional standard is aimed at curing these problems. Equipment that conforms to the functional standards will inter work effectively and with zero (hopefully) user intervention.
The functional standard attempts to make the best possible use of the recommendations. To this end it demands that PADs provide all optional as well as mandatory parameters and their settings. Thus the PAD is as flexible as it can possibly be.
The function standard allows the packet mode DTE to operate in one of 5 different 'profiles' (sets of parameter settings). The first two are the two CCITT profiles and are only included for inter working with existing PADs which are unable to meet the functional standard. The third profile is designed to make the best possible use of the parameters on a line at a time or message mode. The fourth profile also makes the best possible use of the parameters but for character at a time use. The fifth profile gives maximum transparency between the start-stop mode DTE and packet mode DTE and is useful for controlling automatic equipment, graphics devices and so on.
Rules are laid down for switching between profiles which can be done at any time. The rules ensure that if parameters are altered for some reason in one profile these changes will not be reflected in returning to a profile used previously. There is thus a principle that profiles are independent of each other.
Some parameters in some profiles are designated as being 'packet mode DTE dependent' and the control of these parameters is by the packet mode DTE. The parameters controlling 'break in' fall into this category. Clearly it would be foolish for the packet mode DTE not to set these properly or 'break in' may become impossible. The other parameters are not the concern of the packet mode DTE and are normally concerned with the connection between the start-stop mode DTE and the PAD. An example is the parameter concerned with padding after a line feed which is clearly dependent on the mechanics of the start-stop mode DTE.
A small class of parameters need to be controlled by both parties. The parameter dealing with 'echo' is an example. Here the packet mode DTE needs to control it for password suppression and the user may which to control it to cope with a half duplex terminal.
In all cases strict rules are laid down as to which parameters can be changed and under what circumstances. Rules also define how parameters should be changed to avoid confusion between the two ends of a connection.
A tutorial containing hits for implementors is in an annex which is not part of the functional standard. There are also a number of more speculative annexes which may be omitted or developed further.
It is suggested that RARE should sponsor a group to work on the triple X protocols. It is further suggested that the group should work entirely by mail. If there is sufficient interest I am willing to organize the group. If you are interested please fill in the list.
Attached is a copy of the functional standard. It is still in draft form and incomplete. Comments are urgently required to ensure that it satisfies the requirements. If you would like to comment you can obtain a copy by adding your name and address on the list below. Or by applying to:-
P Bryant, R31, Rutherford Laboratory, Chilton, Didcot, OX11 OQX, UK.
Or Bryant@UK.AC.RL.IB (JANET)
Or PEB@CERNVM
8 members out of a total of 21 attended and that included the chairman and secretary. Two chairman including me attended. This was not encouraging although some members were at the COS meeting and there were other important meetings elsewhere.
This is not completely finalized but the meeting was pleased to avoid yet another session devoted to it!
It was generally agreed to be desirable for ITAEGS to hold further open meetings to publicize and obtain comments on plans and to get early comment on drafts.
The idea of a newsletter was considered and it may be appropriate to use some other newsletter such as the IES one. I gather that ITTT have made a offer for its use.
It was suggested that stable drafts should be circulated very widely. The existence of such documents could go in a newsletter or publicized in EUROKOM. Here again there should be no difficulty.
As usual the problem will probably be the effort needed to undertake these activities.
There was encouragement that the functional standards should be seen by ISO (as opposed to submitted) so that they would be aware of the activity.
There is some indications that ISO may well start work on functional standards and it was unclear what, if anything, should be done just now.
A new copy of M-IT-02 is almost finished but was not tabled. It was understood that several changes had been made including the changes proposed my me (but not ratified by my group) for Y/11 Y/12. It was again noted that this was a mobile document regardless of its acceptance by CEN/CENELEC/CEPT. It thus seems to me that 'acceptance' of the document is a hollow activity. My view that the document needed careful rewriting to make it consistent and of a high quality was greeted with sympathy but it seems unlikely that the required technical authoring effort will be found. Thus improvement will be on the 'drip feed'.
There appears to be a copyright problem with CEN.CENELEC documents and there is some reluctance to copy documents regardless of the fact that they may be drafts and regardless of the fact that maximum circulation is desirable. There seems no solution. (It's more than my jobsworth).
It seems that we shall soon have a list of members of the committees and groups. Again effort not desire is the problem.
It should be possible to update an ENV before its validity expires. It was considered inadvisable to upgrade a document before at least 12 months had expired.
This document was not given much attention but it is clearly an area where we can expect action soon.
It was agreed that ENVs should contain no material on conformance testing. Useful, as this removes the very worst chapter from Y/11 Y/12!
There was an inconsequential discussion on how various bodies did their business and on how various bodies had changed their names mainly in the MAP area.
The private MHS vote is expected on May 12.
The Public MHS vote will be May/June.
There was a long discussion on when balloting and voting would take place.
My thunder was taken from me by the announcement that Van Herp is attempting to get the CEPT X.25 and PAD work under the functional standard activity. If this succeeds this will be a major victory.
The chairman of the Q group working on 'characters' attended and came in for heavy questioning if not an inquisition. The discussion turned into a technical discussion which confirmed the view that the group was in deep trouble. For example, it transpired that it was uncertain whether the group was talking about character sets or the representation of characters in the sets. On the brighter side it appears that the London meeting will have considerable input on paper and men. Not least we understood that Hugh McGregor Ross intended to submit a number of draft proposals. Should be interesting and looks encouraging.
It seems that observership is now working somewhat better. Apparently the chain of command within CEPT is rather longer than we had been led to believe.
Token ring will be included plus a number of high level protocols that I did not note including FTAM. The next version of M-IT-02 should be worthy of careful study!
It is still clear that the activity is under resourced administratively although we believe the position should improve soon.
I was far happier with the direction that ITAEGS is now taking. It is very regrettable that more chairmen do not attend the meetings. In fact more attendance 'full stop' is desirable. Of the 8 attending only 4 made any noticeable contribution and that is far too few for a variety of views to be taken into account. It also limits the actions which can be placed on members and, frankly, puts all the burden on the chairman and secretary who in the circumstances are coping exceedingly well.
File transfer has remained stable and no further improvements are planned.
Since mail came into being in January it has attracted a lot of adverse criticism. The initial version had numerous shortcomings. For example, * error reports were non-existent in many cases
Since then numerous improvements have been made in the light of use and experience. For example:-
A new version of the gateway guide is now available.
The work on the gateway has revealed the lack of standards documents within EARN. Although the network reputedly uses the mail standard RFC822 there are several limitations and quite a few of the problems have been due to the difficulty in finding out exactly what is required. It is unclear how such documents could be produced.
Currently one or two hundred messages a day are passing the gateway and this is rising.
The April traffic figure was 143 M bytes.
About 30 people attended the meeting which was held at the IBM Scientific Centre in Paris. Dominique Pinse did an excellent job of organizing the event.
On this occasion we welcomed representatives from Greece and Portugal. Unfortunately all the USA representatives, except G, were unable to attend due to the unsafe situation in Europe and of air travel.
Reports from the sites showed that there was still quite a lot of growth and that traffic levels are increasing.
There are a number of problems with RSCS and there were thoughts of trying to obtain the IBM VNET version as this may well cure many problems. Negotiations will continue. The number of 'fixes' for this problem or the other is worrying and some uniformity would be desirable.
Several sites will be running the conferencing system 'GRAND' and evaluating it. IBM gave a presentation on GRAND.
The discussion on the migration paths of BITNET and EARN was disappointing due to the lack of US experts. It is unclear how serious the plan to use TCP/IP is and if serious what the time scale would be. The impression is that there are a number of experiments going on and no definitive plans.
Discussions on gateways revealed quite a number of plans but as yet the number of active gateways is small. A discussion on whether EARN should try and use X400 over RSCS decided nothing should be done.
Peter Silvesta gave a presentation on MAIL under MVS which indicated that this was in a good state.
NETSERV is working very well and the steady stream of improvements are welcome.
Reliability problems seem to have 'gone away'. It is unclear whether we merely went through a bad patch or if we are just going through a good patch now. The distribution list for failure information is working well and seems to help to alleviate aggravation. The meeting did not seem to worry too much about the down times at Christmas and wondered if much effort should be expended considering the low usage at those times and the nature of the network.
My feeling was that the meeting, as before, had been well worth while and a considerable amount of information disseminated. None the less I do get the feeling that we do not have enough technical coherence. For example, the definition of the mail standard(s) we use are not available in detail. Indeed several mail systems are used such as IBM note and RFC 822 and it would be useful to encourage one or other.
The next meeting will be held after the Berlin conference.
At the last UK EARN meeting mail was about to be offered experimentally. Unfortunately there were still a number of problems to be solved which gave it a very shaky start. There is always a problem in bringing up a new service as to whether to offer it as soon as possible or to wait until it is fully developed. We decided to offer it as soon as possible and thus attracted a lot of problems in the first week or two of use. Most of these are now solved and after a couple of months of use the traffic has risen to a few hundred a day which shows quite a bit of use regardless of its unfinished state.
The first problem was with the NRS as to what names could be used. When this was sorted out there was still a long delay in getting the names registered and I regret that some of the reasons were our own confusion as to who was registering what for which we offer apologies.
The second problem was that mail system itself only offered a subset of the facilities needed. You may recall that we only offered 'source routing' of mail and not 'domain' addressing. This drew some adverse criticism from within EARN as the addressing methods were not common in that network although well known in JANET. The documentation produced reflected the confusion that existed.
It had been expected that a new version of the mail gateway and a new document would be produced towards the autumn. If fact developments have gone far better than expected and many of the new features have been incorporated and a new document produced. The latest version is 4. The promised short user guide has yet to be produced.
Domain addressing is now incorporated but unfortunately there is some work still to be done to produce the correct From: fields. This is causing some concern in EARN in that it prevents automatic replies in some circumstances.
During the last few months the reliability has improved considerable. In addition the number of cases where we can return error replies is now much larger although the nature of the network makes it impossible to guarantee that either mail will be received or an error returned.
A small amount of testing has been done through gateways from EARN to other networks. This has mainly been done by users with mixed success. However the success is rising as problems are solved.
The information service, NETSERV, has been unreliable but it is hoped that this is now cured. For some reason it took a long time to get the service available permanently. We also had a spate of loosing critical files which we believe was due to the interaction between the various NETSERVs across Europe.
File transfer has caused no problems. It is, of course, not the most convenient of services but none the less appears reliable. It is not planned to enhance this service.
Most user support has been provided by Tony Burraston or Paul Bryant. Unfortunately the Division has not has any network support specialists. There is some hope that we have at last recruited someone but it will take a little time before he will be making a full contribution.
There have been very few queries about FTP. Initially most question were about mail into EARN especially when it was in its early days. Lately the comments have been concerned with access to other networks via EARN.
The traffic between EARN and JANET is as follows:-
Total (Mbytes) Charged (Mbytes)
October 12 6
November 80 10
December 52 15
January 231 43
February 91 36
March 62 106
The high January figure was caused by the failure of the non EARN connection between Rutherford and EARN. This line carries about 300Mbytes per month.
If the EARN traffic were to rise to 300Mbytes per month of charged traffic then this would attract a volume charge of 36,000 pounds. Current funds allow for 26Mbytes per month.
There is advantage is moving traffic between the two lines but this has not been possible in general as the Swiss PTT has not set a tariff and CERN are unhappy to allow any such moves until it is fixed.
The full executive:- David Lord, Stephano Trumpy, Jean-Claude Ipollito, Birgitta Carlson, Michael Hebgen, Paul Bryant. In addition Herb Budd and Alain Auroux of IBM.
Neither of either.
The meeting was dedicated to this topic.
Date is Monday October 27 to Wednesday October 29 in Berlin. It will be for 300 delegates and quotas have been given to each country from 100 for Germany through 30 for UK and 2 for Greece. The numbers are based on requests from Board members. All costs apart from travel will be met. Speakers costs will be fully met. It was felt inappropriate to pay speakers. IBM has donated 150,000 Dollars. Requests for places is 15 September after which untaken places will be re-allocated. Final list will be on 10 October when preliminary programme will be sent to participants. Brochures will be produced but no posters
The conference will be mainly concerned with networking at a high-ish and philosophical level. And considerable thought was given to the 'shape' of the conference. The three key speakers will give an EARN, a US, and a European view of academic networking followed by discussion. A second topic will be a view of the future from the PTTs. It looks like it will be enjoyable. The rough program is:-
Monday - start mid day. Welcome from Mayor of Berlin. Use of networks in space - Curian from ESA Use of networks in HEP - Shopper from CERN Use of networks in education - Hubbard View of future from PTTs - someone from Bundespost There will probably be some entertainment laid on. Tuesday Introduction of philosophical matters - Zander EARN - David Lord US - Dennis Jennings or someone. European view - Peter Linington. Lunch The telecommunications challenge - ? my notes failed me Round table discussion. After dinner speech - Davinion from commission Wednesday View from Japan - my spelling fails me WONet - Herb Budd Finish with buffet lunch.
The above is inaccurate!!!
David Lord's term as director ends at the new year and the EARN statutes bar him from re-election. It is unclear who will take his place.
A meeting has been scheduled with CEPT for 20th attended by Hultch and Hebgen.
IBM will finance a man and secretary for EARN. It should be hosted by an existing site. The only candidate so far is Jean-Luc Delahey from Montpelier. It is up for grabs. Is Rutherford interested?
A final document expected.
A good meeting with a lot of progress.
Dear Jean-Claude,
As we discussed in Paris Alain and I have agreed to pay the expenses of Gligor to the EARN Technical Meeting of 21st 22nd April. I attach his claim for 575.59 US Dollars. This will be paid from the X.400 resources.
The cheque should be sent to:-
Gligor Tashkovich Seal and Serpent Society 305 Thurston Avenue Ithaca New York 14850 - 2429 USA
It should be payable to Gligor.
Thank you.
Best wishes,
Paul Bryant.
Those who have a rough idea of what EARN and JANET are and want to move data between the two networks should turn immediately to section 5 on how 'To Get Going'. Sections 2 through 4 give an introduction to the two networks. Section 6 describes the EARN information system NETSERV. Section 7 through 13 contain further technical details which may be required in a few cases.
EARN (European Academic Research Network) is a computer network between academic institutions like universities or research centres for the purpose of world-wide communication. It consists of a set of independent host nodes connected by means of leased telecommunications lines in an open, un meshed topology. A central computer in each country provides international connectivity and some central services.
EARN is a 'store and forward network'. It utilizes the transmission techniques of the JES2/JES3 or RSCS subsystems of the IBM operating systems MVS and VM respectively. Emulations are available for several non-IBM systems such as SIEMENS BS2000/BS3000, DEC VAX VMS or UNIX, or CDC Cyber NOS.
The following functions are available:
EARN provides world- wide connections to:
In the remainder of this document any statements concerning EARN will also be true of BITNET and NORTHNET as the networks are technically a single network and differ only in their management.
The European scientific community gratefully acknowledges the support of IBM, supplying skilled technical staff and carrying the costs for international and some national PTT-lines as well as for the central node computers of the EARN backbone network for the duration of four years.
JANET (Joint Academic Network) is a computer network for the use of academic and research institutes in the UK. It has connections to virtually all such sites although in many cases these connections are to local area networks to which the various nodes are connected. There are gateways to the public X25 network, to ARPA and to EARN.
JANET is an X25 network and provides facilities for file transfer, mail, interactive services and job transfer although the services on any system depend on the particular machines and on the local management. The protocols used are the so called 'Coloured Book' ones. The network is expected to migrate to the use of ISO protocols over the next few years.
The UK has a single EARN node at the Rutherford Appleton Laboratory. This node is also connected to JANET. A gateway is provided between the two networks which allows the transfer of files and mail.
In JANET the file transfer facility is restricted to machines offering 'Blue Book' file transfer. In addition files may only be 'sent' to EARN nodes and may not be 'fetched'. The transfer of binary files is probably only meaningful if both the EARN node and JANET node are IBM or IBM compatible machines.
To transfer mail the EARN node should offer an RFC822 mail service. RFC822 is an ARPA mail standard. This may be provided by the Columbia Mailer and its associated user interface. The JANET node must offer a 'Grey Book' mail service.
Message transfer from EARN is only possible to the Rutherford EARN node and is not possible to and from JANET nodes.
The Rutherford EARN node, in common with the other EARN backbone nodes, offers NETSERV which provides an EARN information service. The information files may be accessed with 'Blue Book' file transfer from JANET nodes. Those with accounts on the Rutherford IBM computer may access NETSERV as if they were on an EARN node.
There are six possible functions. The minimum amount of information is given about each of the functions in the following subsections. This should satisfy the majority of requirements. Each section is self contained.
If there is doubt as to whether suitable facilities exist on some system then the local management should be consulted.
The list of nodes within JANET is held in NETSERV as file NRS DATABASE. The list comes from the UK 'Name Registration Scheme' and each service has an entry even though many of the services are inaccessible from EARN, for example interactive ones.
The Rutherford node operates under VM/CMS and the normal means of file transfer using the IBM NJE protocol RSCS apply.
The Rutherford node runs under VM/CMS and the normal means of message transfer apply.
File transfer is only possible if the JANET node offers 'Blue Book' file transfer and the NETSERV file NRS DATABASE gives this information.
On an IBM VM system the FTP exec may be used to send or fetch files, and to receive reports of the transfers' success or failure. Warning- if there is an MVS machine between the EARN node and UKACRL the transfer will fail as MVS corrupts NOP records on which the system relies.
The most useful FTP command structures for sending, fetching, and sending in DISC DUMP format follow but there are several other modes available. Full details are in the FTP Help file.
FTP SEND fn ft {fm} {AS remfile} TO userid {pswd} AT nrsname (options
FTP FETCH remfile {AS fn ft} FROM userid {pswd} AT nrsname (options
FTP DUMP fn ft {fm} TO userid AT nrsname
Items enclosed by {} are optional. Upper-case denotes fixed keywords.
'fn ft fm' are CMS filename, filetype, filemode.
'remfile' is the remote file name on the JANET node. It must be a valid file name on the remote node.
'userid' is normally the 'user id' associated with the file store of the JANET node.
'pswd' is normally the password associated with the user id. For VM systems it is not required with SEND, and is the 'read-password' with FETCH.
'nrsname' is the name of the JANET node. 'options' are such things such as BINARY, LOG2, etc. (See HELP file).
The DUMP mode delivers arbitrary files in DISK DUMP format.
The FTP EXEC is available in the UK NETSERV and maybe others as composite file JANETFTP PACKAGE.
If a VM system is not available it is possible to send files to JANET by inserting '*FILE' records at or near the front of the file. It is not possible to fetch files or to receive reports of the progress of a transfer once it has arrived at the JANET gateway. The files must be sent as either 'punch' files of up to 80-character records, or as 'print' files of up to 132 characters plus carriage control.
The format of the '*FILE' record is :-
//* *FILE SITE=nrsname,USER=userid,PSWD=pswd,DEV=FILE //* *FILE FILE=remfile,KEEP=NO
The file is sent to the EARN node UKACRL and user JANET.
The JANET node must offer 'Blue Book' file transfer.
Files may be sent to an EARN node but may not be fetched.
The file to be transferred is sent to the JANET node UK.AC.RL.EARN with user id 'VNET/earnnode.userid' or 'VNETP/earnnode.userid'. The file is any valid CMS file name. No passwords are required since file transfers within EARN are placed in spool areas prior to being accepted. If the form 'VNET/earnnode.userid' is used, the file will be delivered in DISK DUMP format; if the form 'VNETP/earnnode.userid' is used, the file will be delivered in card image format and record lengths within the file must not exceed 80 characters. 'earnnode' is the name of the EARN node and lists of these are held in NETSERV. 'userid' is normally the logginh in identifier on the remote node.
Examples for popular machines transferring a file named FRED to SID at EARN node DEARN are:- (Note responses from the system are underlined)
For VAX computers running VMS and UWIST communications software:-
$ TRANSFER %_input filename ? FRED.DAT %_output filename ? UK.AC.RL.EARN::"XX XX" %_remote username ? "VNET/DEARN.SID" %_remote username password ? $
For IBM computers running VM/CMS and Rutherford communications software (but not the Rutherford machine as it is connected directly to EARN and thus the CMS command SENDFILE or similar should be used):-
FTP SEND FRED DAT AS XX XX TO VNET/DEARN.SID AT UK.AC.RL.EARN
UK.AC.RL.EARN is registered in the UK 'Name Registration Scheme' with FTP context as DTE 000000000002 and 'Yellow Book' sub-address FTP.
The EARN node constructs mail to the RFC822 standard. The Columbia Mailer user VM with a suitable internet exit is suitable. It is possible to construct such mail using a text editor but this is liable to error. The mail is routed to user id MAILER at EARN node UKACRL. The JANET node must offer 'Grey Book' mail. BSMTP headers are accepted but ignored.
The 'To:' field should contain:-
recipient@revnrsname or recipient%nrsname@AC.UK
'recipient' is the name of the receiver of the mail and 'nrsname' is the name of the system in JANET which the mail is for. 'revnrsname' is an 'nrsname' with the components in the reverse order to conform with EARN practice. For example a typical 'nrsname' is UK.AC.RL.GK and the 'revnrsname' is GK.RL.AC.UK.
Thus to send mail to Fred on RL.GK using the Columbia Mailer and its user interface the command is:-
MAIL Bryant@GK.RL.AC.UK or MAIL Bryant%UK.AC.RL.GK@AC.UK
A full list of 'nrsnames' can be obtained from NETSERV file NRS DATABASE or in a more convenient form JANET SITELIST.
Note that for mail purposes the Rutherford IBM computer is a JANET node and mail would thus be addressed, for example, to Fred@IB.RL.AC.UK.
The JANET node must offer 'Grey Book' mail. It is convenient but not essential for the EARN node to have a mail system such as the Columbia Mailer although its absence should only be an inconvenience and may, for example, prevent some error reports.
The 'To:' field should contain:-
recipient@EARN.revearnnode or recipient%earnnode@UK.AC.RL.EARN
'recipient' is the name of the recipient of the mail and 'earnnode' is the name of the EARN node which the mail is to go to. 'revearnnode' is an 'earnnode' with the components reversed to conform to JANET practice. EARN node names are a single component but several components may be needed if a gateway is to be traversed.
Thus to send mail to Fred on DEARN the 'To:' field should contain:
Fred@EARN.DEARN or Fred%DEARN@UK.AC.RL.EARN
Lists of 'earnnode' are held in NETSERV.
Note that for mail purposes the Rutherford IBM computer is a JANET node and mail from this machine would, for example, be addressed to Fred@EARN.DEARN.
Note that UK.AC.RL.EARN is registered in the UK Name Registration Scheme for MAIL as DTE number 000000000002 and 'Yellow Book' sub-address FTPR.MAIL. EARN is registered as an incomplete domain in the same way.
There are a number of gateways from EARN to other networks and these are known to the JANET EARN gateway and it is not necessary to know where the gateways are. The 'To:' field should contain:-
recipient%<domain>@EARN
Where 'domain' is the address of the recipient.
Thus to send mail to Fred at the ARPA location UCL-CS the 'To:' field should contain:-
Fred%UCL-CS.ARPA@UK.AC.RL.EARN
A number of '%<domain>' fields may preceed the '@'.
The current list of gateways is:-
DEC ARPA UUCP CCNET CSNET MFENET MAILNET GOV EDU COM MIL ORG UWO CDN BELL CERN UUCP MLNET SUNET UNINETT
Testing of these gateways from within JANET has not taken place.
NETSERV is an information service provided within EARN. There is one site in most countries providing this service. The JANET network is technically different to EARN and the service has been adapted accordingly.
From within JANET the service is accessed using 'Blue Book' file transfer.
A request for an information file is sent to NETSERV in the form of a file or an RSCS message and the information file is then returned. Any of the NETSERV facilities within EARN may be accessed in this way.
If an RSCS message is used then it should have the form:-
TELL NETSERV GET filename filetype
or if it is not on the local computer:-
TELL NETSERV AT earnnode GET filename filetype
If a file is used to request information then it should contain:-
GET filename filetype
'filename' is the name of the information file required.
The file NETSERV HELPFILE returns a file of about 1600 records which has all details of the use of NETSERV. This document is JANET EARNGATE.
EARN information files from NETSERV may be obtained within JANET using Blue Book file transfer.
The required file is fetched from JANET node UK.AC.RL.EARN with user id NETSERV//diskname. The file name is the name of the information file required and takes the form of an IBM CMS file name. No password is required. The information is on a number of CMS 'mini disks' and the 'diskname' is appended to the user id NETSERV except if the file is on the 'default disk' but otherwise takes the form //number, where 'number' is the virtual address of the disk. No spaces are permitted in the field.
The file FILE$ LIST$ is on the default disk and contains a list of all the files available together with the disks they reside on.
Files may not be sent to NETSERV and it may not be used for interactive access.
To obtain the file FILE$ LIST$ to the file F.LIST on a VAX computer running VMS the commands would be:-
$ TRANSFER % input filename ? RL.EARN::"FILE$ LIST$" % output filename ? F.LIST % remote username ? NETSERV % remote username password ? $
To obtain the file JANET EARNGATE which is on disk 193 to the file JANET.GATE on a VAX computer the commands would be:-
$ TRANSFER % input filename ? RL.EARN::"JANET EARNGATE" % output filename ? JANET.GATE % remote username ? "NETSERV//193" % remote username ? $
Unfortunately naming and addressing is a complex subject and is liable to leave the user confused even though the object is to provide a user friendly interface.
Addressing is fairly simple in that every accessible 'entity' has a network address. An 'entity' is some service accessible via a network such as a mail service and thus a particular computer may be several network entities. Each network has its own address scheme and gateways attempt to sort out how an entity on one network can be accessed from another. Unfortunately this often means that additional addressing information has to be supplied by the users to enable the gateways to operate. Even more unfortunately this may have to be provided in an inconvenient form, such as, within the data file being transferred.
Using addresses is inconvenient as these are often changed and they are also not easy to remember. Thus entities are usually 'named'. Unfortunately the use of names is far from simple.
Each 'name administration' has named the entities in its 'domain' and possibly in other domains. Typically EARN, JANET and ARPA are name administrations who have set up schemes for naming. It is worth drawing a distinction between names used for file transfer and those used for mail although they look somewhat similar. In the case of file transfer names can usually only be used for moving files between entities in the same administration and if a file is to be sent to an entity on another one some fairly ad hoc schemes may have to be devised. In the case of mail the naming information is designed to go through gateways and thus can be made easier for the user. It is fortunate that the same mail system is used in EARN and JANET which allows the mail gateway to be fairly convenient. This is the ARPA RFC822 standard.
A full list of EARN, BITNET and NORTHNET node names can be obtained from NETSERV.
A name is normally associated with a computer. The names have no hierarchical structure except in the case of mail which is to pass through a gateway. Names have some informal structure as in many cases the first few characters define the country, the next the site and the rest may indicate the operating system in use. The network protocols limit a name to 8 or less characters.
Names in the JANET network are registered with the Name Registration Scheme. Names are hierarchical. The top level is UK and the second level contains AC - meaning academic community. Site names are at the third level. Any structure below the third level is at the discretion of the site. The name components may have a 'standard form' or a 'short form'. The two forms are provided as a compromise between meaningful names and quick to type ones. In practice the standard form names have encountered problems with some systems with the structure of tables and size of files. In a number of cases sites have elected to have the standard form names identical to the short form. The components of a name are separated by '.'. The two forms of name may be used via the gateway although all examples have used the short form. A name has contexts associated with it which define which services it applies to.
A typical standard form name would be:-
UK.AC.RUTHERFORD.GEC-K
The corresponding short form would be:-
UK.AC.RL.GK
For use within JANET the UK.AC. may be omitted.
On any system only a selection of names may be available. Currently the name UK.AC.RL.EARN must be available in FTP and MAIL contexts. In the case of file transfer it may be possible to use some alternative method of addressing the IBM computer at Rutherford. If there are difficulties the local site management should be consulted.
The names of entities within JANET are held in the UK NETSERV as file NRS DATABASE. Only the file transfer and mail entities may be accessed from EARN and not the others such as interactive ones although the list contains a complete set.
The RSCS protocol is unable to carry sufficient information within the protocol to satisfy the requirements of the 'Blue Book' file transfer protocol used within JANET. The additional information required has to be carried either as NOP records in the spool file (as inserted by the FTP exec), or within the data using '*FILE' records. The '*FILE' records should be as near to the front of the file as possible, as their content must be determined before the file transfer itself can start.
It is recommended that if the EARN node uses VM then the FTP exec should be used as this provides reports on a transfer's progress, allows files to be fetched and is more convenient to use. The exec may be found in the file JANETFTP PACKAGE in NETSERV which is a composite file that also contains some help files. This method should not be used if there is an MVS node between the VM node and UKACRL as the MVS node will alter the NOP records which the FTP exec generates.
If the '*FILE' records are to be used, the file containing them is sent to EARN node UKACRL and user id JANET.
There may be several '*FILE' records and their format is:-
//* *FILE key=value,......,key=value
The 'key'='value' pairs from all the '*FILE' records provide the parameters to control the file transfer through JANET and they may occur in any order. The 'key' is a keyword and the possible 'values' are defined below:-
SITE The 'Yellow Book' internet address of the destination entity within JANET. This will generally be a name such as RL.GK but it could be an X25 DTE address with 'Yellow Book' sub-address (normally .FTP).
USER This is the user id on the remote entity if required.
PSWD The value is the password associated with the user id on the remote entity if required.
DEV The options available depend on the remote entity but normally include:-
FILE - the file will go to the remote file store with access mode 'replace or make'. Thus if the file already exists it will be over written and if it does not it will be created. LP - the file will be printed at the remote entity. JOB - the file will be expected to be a job for execution at the remote entity. RDR - the file will be sent in printing format to a virtual reader (IBM systems only). No checks are made as to whether the file is suitable for the purpose defined or whether the remote entity is a suitable recipient. In most cases the transfer will be rejected by the remote end if the transfer is not sensible.
FILE If the value of DEV is FILE the value is the name of the file on the remote entity. This must be in a form suitable for the remote entity. If the value of DEV is LP the value will probably be used as a banner on the line printer output. If DEV is JOB the value will probably be used to identify the job on the remote entity. The exact effect will depend on the destination system.
QUAL If a value for QUAL is supplied it will be sent in the 'device qualifier' parameter. This parameter is only useful if the remote entity attaches a specific meaning to it.
TRANSP If the value is 'NO' all control characters are translated to nulls. If the value is 'YES', which is the default, no translation takes place.
MAIL The value is a CMS user id on the Rutherford IBM system to which file transfer logging information is sent. This is used for testing and monitoring only.
CC For a file being sent as a print file (using Take Job Output) CC=NO would cause the carriage control character at the start of each line to be suppressed.
KEEP If the value is 'NO' all the '*FILE' records will be removed from the file. Note that only the first adjacent set of '*FILE' records will be recognized.
PSIZE If the value is 128 an X25 packet size of 128 will be requested otherwise a packet size of 256 will be used. There should be no need to use this facility which exists for historical reasons.
DTYPE If the value is BINARY the file will be sent as binary and no code translation will take place. The remote end must support the reception of binary. This facility is mainly useful for sending MODULE files to another IBM. The file must still conform to the general requirements for 'job output' such as the limit of 80 characters per record for punch files or 132 characters plus carriage control for print files. By using DISK DUMP format (which is transmitted as 80 character punch records), any type of file can be sent between two VM/CMS systems.
If a value contains a blank, a comma, or a single quote then the value must be enclosed in single quotes. Single quotes within a value must be doubled. More than one *FILE record may be used, but if so they must be adjacent and a parameter must not span records. If a sequence number is present in columns 73 to 80, then there must be at least one blank between the last parameter value and the start of the sequence number. If sequence numbering is not used then *FILE records may be up to 80 characters.
Example of parameters specified on two adjacent records:-
//* *FILE SITE=RL.GK,USER=DEMO,PSWD='ABC DEF' //* *FILE DEV=FILE, FILE=.TESTFILE
Once the file has entered the gateway no diagnostics or indications of success or failure are returned.
The system must offer 'P' end 'Blue Book' file transfer. The details of any particular system should be obtained from the local management.
The file transfer parameters should be set as follows:-
All other file transfer parameters are optional and are ignored.
Once a file has entered the gateway no further diagnostics or indications of success or failure are returned.
The EARN node must offer some means of constructing mail according to the RFC822 standard and for sending it to user id MAILER at EARN node UKACRL. The destination system must offer 'Grey Book' mail.
The 'To:' field must contain:-
receiver@revnrsname or receiver%nrsname@AC.UK
'receiver' is normally the identification of a recipient which may be a distribution list, a user id, or a real name depending on the destination. 'nrsname' is a registered name of a 'Grey Book' mail system. 'revnrsname' is an 'nrsname' with the components in the reverse order.
Access to a number of destinations is barred for regulatory reasons.
The JANET system must offer 'Grey Book' mail and the receiving system should offer an RFC822 mail system although its absence will only cause inconvenience.
The 'To:' field must contain:-
receiver@EARN.revearnnode or receiver%earnnode@UK.AC.RL.EARN
'receiver' will usually be a user id on the remote entity but may also contain further routing and addressing if distant gateways are to be traversed. 'earnnode' is the name of the remote EARN node. 'revearnnode' is an 'earnnode' with the components in the reverse order. 'earnnode' may refer to a node outside of EARN which can be accessed via a gateway.
Examples are:-
FRED@EARN.DEARN HARRY%CUNYVM@UK.AC.RL.EARN
Mail is dispatched to the EARN gateway which will normally be automatic as EARN and UK.AC.RL.EARN are registered in the UK Name Registration Scheme. If this is not the case there are a number of system dependent methods of overcoming the problem and the local management should be consulted.
The name EARN is used regardless of whether the mail is for EARN, BITNET or NORTHNET.
In passing the JANET EARN gateway a 'received' field will be added to conform with the EARN standard.
Mail which cannot pass the gateway will be returned to the sender with a suitable diagnostic if possible.
Details of the various 'Grey Book' mail implementations are outside the scope of this document.
Once mail has left the gateway its reception is the responsibility of the remote system and there is no guarantee that it will be delivered or that non delivery will be notified. The use of so called 'mailers' at EARN sites makes delivery highly likely but only 50% of sites do so.
If mail is destined for a node within EARN then the 'receiver' is checked by the gateway to ensure that it is 8 or less characters. If the mail is for a destination outside EARN then the gateway only checks that the mail can be forwarded to a suitable exit gateway from EARN.