Paul Bryant's Networking Correspondence
Dear James,
Thank you for the comments on the ENV and I have incorporated them all. Your notes were clearly better than mine and I missed a lot. I have not had a response from Vince and will give him a ring in a few days.
I have had a look through the minutes. I have rewritten section 6.1 to try and forestall any further questions:-
"Mr Hathway asked on behalf of BSI whether the mandate for PrENV 41901 intended it to be applied to PADs as well as to packet mode DTEs and start-stop mode DTEs. The chairman confirmed that PrENV was intended to apply to PADs. The mandate and M-IT-02 now contains no statements or implications which would exclude PADs although text in early versions of M-IT-02 did exclude PADs. He reported that ITEAGS had ruled out the possibility of a separate functional standard for PADs. CEPT encouraged the view that PADs should be included.
The principle concern of CEPT was the demand that PADs should provide all additional parameters and optional parameter values thus excluding many existing public PADs from conformance even though they would align with the CCITT recommendations. CEPT were happy that the requirement to provide these parameter values could be an ultimate objective. It was agreed to provide two levels of conformance - "basic" and "full". The basic level of conformance would allow PADs aligned with the CCITT 1980 recommendations and providing no additional parameters and optional parameter values to conform. Relevant changes to PrENV 41901 were tabled and agreed as set out in annex 1."
On page 4 7.2 m) - the acceptance of the text is also mentioned on page 3 6.2 1. Suggest second is replaced by (See minute 6.2 1.)
On page 8. The Belgium comments were accepted!
Suggest we clarify page 5 section 10. Replace "integrated PADs" by "PADs integrated with X.25 switches". and delete "(non detachable)".
Suggest we interchange 12.1 and 12.2 - otherwise it looks like we went on to discuss outside contributions in spite of his comments (even if that is what happened).
We still have a problem or two with Annex 2 as on closer inspection there are some further facilities which are also subscription choices. Also we have a problem that X.2 declares 'transit delay selection and indication' to be essential. I suggest we revisit this at the next meeting.
Look forward to the final version in a week or so.
Best wishes
Paul Bryant.
Dear Alan,
I am very pleased that James Boyd will be joining Jan Van Herp on the CEN/CENELEC functional standards programme as I am sure that he will make a significant contribution to the activity. Unfortunately this means that he will be unable to arrange the future meetings of Y/11 Y/12. I am sure that you are aware that the UK has accepted the responsibility of organizing these meetings.
It had been hoped that the Y/11 Y/12 work would have been concluded by now but unfortunately it now appears that there will be two further meetings. The first will be held on 16/17 February in London and the final one has yet to be arranged but will probably be in May. The secretarial effort now required is fairly small. I believe a room has been booked for the next meeting and the remaining tasks are to distribute the minutes of the last meeting (now being finalized by James) and the distribution of the latest version of ENV (being prepared by myself) and any further contributions received. Minutes of the meeting will be needed but these can be brief as the output is edits to the ENV.
The final and voting meeting will also require a room booking and minuting. However Jan Van Herp sends out the calling notice and any papers although one does well to monitor this activity to ensure the relevant UK groups obtain relevant documents.
May I ask you to confirm that BSI will be able to provide services? It would be useful to know who will be looking after these meetings as soon as possible so that I can brief him.
I enclose a copy of the RARE document I agreed to provide to IST/-/2.
Best wishes
Paul Bryant.
The 'universal goal' of networking is to provide the ability for network services between any suitable systems regardless of their manufacturers.
The reality is that many networking methods have grown up for various good and bad reasons which has defeated the objective.
In the UK academic community the objective has been met to some extent by the imposition of the 'Coloured Book' protocols which have at least allowed networking between the machines in that community. These protocols have only had limited acceptance outside of the community and the 'new way forward' is now seen to be the adoption of the evolving protocols from the International Standards Organisation, at least within the European academic community and hopefully in many others. Indications are that this endeavour will be successful but will take several years to achieve.
Unfortunately, the services that can be provided on specific machines with proprietary networking methods, usually from a single manufacturer, tend to be much richer than those provided by the more general ISO ones. There is some hope that this situation will improve as the ISO protocols develop.
The comments here are restricted to the slower speeds of less than 64K bits/second. In time services based on much higher speed can be expected which will require further developments in protocols.
The UK academic network strategy, evolved over about 8 years, is to provide a uniform set of services to all who require them.
The services in principle allow:-
The tactics to obtain these objectives is to impose a set of protocols known as the 'Coloured Books' on the community. This imposition was achieved by constraining computers provided by Computer Board funds to exhibit the required protocols.
The strategy for any particular range of computers has provided services which are inferior than those which could be provided by some proprietary systems. On the other hand it has achieved its objectives of interworking between heterogeneous machines.
The 'Coloured Book' protocols are more or less parochial to the UK. This means that implementations are always likely to be reluctantly produced by suppliers or provided by the community. The alternative is to adopt a more acceptable set of non proprietary protocols such as those defined by the emerging ISO protocols. Indications are that these will be widely supported by manufacturers.
Currently implementations of the ISO protocols are only now becoming available and not yet in the abundance required to mount services. It will be a difficult job to migrate the current UK academic network to ISO.
For some time a JNT led group has been developing a transition strategy to ISO protocols and this is now well advanced. It will still be some time before these systems will be in place. The transition strategy has defined how interworking can be maintained while moving to ISO protocols systems.
The evolving documents defining the transition may be obtained from the JNT at Rutherford.
All the other West European countries are also intent on using ISO protocols. The RARE organisation has recently been set up to co-ordinate these networking activities across Europe. The protocols to be used and the exact details of them are now fairly firm.
Currently each country has a different set of national facilities.
The UK is alone in having an extensive private network and the provision of a uniform service to virtually the whole community and is envy of other countries.
A full survey of provisions across Europe (and the world) is beyond this document and there are a large number of such surveys which have been given at various network conferences (Luxemburg and Copenhagen RARE conferences). Also, each country has supplied descriptive documents from time to time.
However, some brief comments are useful.
Germany has a large project to provide an ISO network known as DFN which will use the public X.25 networks.
Italy has a number of networks based on DECNET and IBM RSCS protocols.
France has two thrusts which are both expected to migrate to ISO protocols. The first is based on IBM RSCS protocols and the second on ISO protocols. The situation is a little confused.
The Nordic countries have been keen to provide facilities such as enjoyed in the UK. This has been modestly successful but they have not had the scale of the UK to encourage manufacturers to provide the products or the effort to provide them themselves.
Other European countries either have relatively small scale efforts or use any facilities that come to hand.
The American situation is confused in that a large number of networks have been provided based on a wide variety of technologies. These have often been based on communities of interest such as NASA or high energy physics. Since there has often been cross interests, gateways between various networks have been developed or logical networks spanning a number a physical networks serving a single community, for example CSNET have evolved.
The principle international network for academic use is EARN/BITNET. Although not providing interactive facilities it has now invaded most countries of the Western World. It has an advantage that it is simple to organise and to join and cheap to operate. This is particularly true in Europe where it has been underwritten by IBM until the end of 1987. It is based on IBM proprietary protocols and mainly offers file transfer and mail services.
The ARPA network has international links and like EARN is fairly open to general academic use. Since it is far more complex and expensive than EARN it has not enjoyed the same penetration. ARPA provides a wide variety of services.
All the other international networks are for specific communities and operate a miscellany of technologies. For example, the UNIX community use the UUCP network which tends to use 'dial up' connections and a store and forward technique. The astronomy computers tend to use the DECNET protocols.
No one would argue with the premise that a single set of networking methods is desirable. Only in this way can there be freedom from the worries of what will connect to what.
For a variety of technical and political reasons only the ISO protocols are acceptable. Whilst these protocols are becoming well defined they are not yet widely available and also lack some important services which such systems as SNA and DECNET can provide. In particular process to process communication.
The network purists would want to introduce ISO as swiftly as possible and to restrict and reduce the penetration of other systems.
The user view is that the important aspect is to provide the best possible service within the cost constraints as early as possible.
In the short term the two views are incompatible and hence a process of transition from the currently available methods to ISO methods has to take place. Unfortunately this is a difficult task since the service to the user has to be maintained while the networks change. In practical terms this involves the use of complicated gateways between the various networking systems which are inconvenient and expensive.
The central development of academic networking in the UK is strong and its benefits are now apparent. One can envisage that if JANET had not developed then the astronomy community, for example, would be faced with the high cost of installing lines to all the sites they wished to communicate with. The resultant total cost to the scientific community would have been far higher and would have preserved islands of non communicating groups.
Having achieved a sophisticated national network service it is likely that JNT and a fair proportion of the community will be reluctant to allow alternative services to be introduced. This attitude is likely to harden rather than soften as the community goes into a very delicate transition to ISO exercise.
The access to international facilities is recognised as important. The attitude here is to encourage the provision of gateways to and from JANET. The five major gateways are to ARPA (UCL), EARN (Rutherford), PSS (ULCC and Rutherford), UUCP (Kent), and EAN (UCL).
With these gateways it is possible to access virtually all other networks albeit with loss of quality. The loss of quality can range from trivial to severe. The severe problems are normally caused when a number of gateways have to traversed or when the facilities on the two networks do not match. The more trivial aspects are when some 'magic incantations' are required.
Time scales for the development of network services are very hard to define. In the case of setting up special networks for specific groups with heterogeneous machines it can be a few weeks.
In the case of migrating a network such as JANET to use ISO protocols then times of ten years have been mentioned although substantial steps should be made in the next year.
In the case of ISO network services across Europe or the world then the situation will depend on the various countries.
Network services may be provided by private networks where the customer switches traffic, such as JANET, or where the carrier switches traffic, such as PSS.
With a private network the cost of the network is fixed regardless of traffic. Where a carrier switches traffic then the tariff is charged by volume and time.
Depending on country, a private network is far cheaper to operate but is often not allowed due to the PTT monopoly regulations. Traffic figures show that the EARN network would cost about 10 times as much to operate over a public network and would effectively reduce traffic considerably.
It is unclear how tariffs and regulations will develop. It is clear that there is pressure on the PTTs to reduce the costs of the public services. On the other hand the current liberalisation of the PTTs may allow private networks to flourish in the future.
Dear Richard,
At the recent ad hoc joint CEN/CENELEC CEPT Y/11 Y/12 working meeting the French CEPT member was concerned that in a number of systems PADs are integral with X.25 DCE equipment. Such equipment does not exhibit levels 1 and 2 of X.25 and a number of elements of X.25 level 3 may be omitted. Thus, such PADs will not conform as Y/11 is currently written.
The meeting was sympathetic to the concern and a number of issues were raised:-
The meeting decided that the advice of ITAEGS should be sought to resolve the issue. May I ask you to place this on the next meetings agenda?
The next meeting of Y/11, which is also a joint one, is scheduled for 16/17 February.
With best wishes
Paul Bryant.
I have edited the document according to the comments received.
Text which is not agreed is enclosed by **** **** and includes comment on the disagreement.
A third option has been included which will be supplied by Dennis Jennings. The option envisages mounting ISO application layers over NJE as a first stage.
A section on X.400 addressing has been introduced as a result of discussions which indicates that this is an important subject.
Comments please. Paul Bryant.
P Bryant Rutherford Laboratory UK PEB@IB.RL.AC.UK F Caneschias CNUCE Italy REELCA@ICNUCEVM M Hebgen Heidelberg University $02@DHDURZ1 D Jennings University College Dublin JENNINGS@IRLEARN P Sylvester GMD Germany GRZ027@DBNGMD21 M Walsh Ireland WALSH@HEARN A N Other Sweden
EARN has agreed to migrate its network to use ISO (International Standards Organization) protocols.
It had been hoped to conclude this migration by the end of 1987 to meet the request from CEPT (the advisory body of the European PTTs) . As a result of the slow development of some of the standards and subsequent systems it is unlikely that this date can be met. ****There is now sufficient information to produce a firm proposal for the migration including the costs and time scales. (This is contested but on the other hand is the object of this exercise).****
A working group set up by the EARN Board Of Directors has identified (1?), 2, (3?)... migration strategies which are detailed below.
The working group recommends that......
This document does not consider whether EARN should be based on a private X.25 network or the public one which, to some extent, is a political and financial choice. Some costings are included which may influence a choice.
The working group was constrained by the considerations:-
The academic wide area networking is likely to be based at the lower levels on ISO transport service over an X.25 service.
The upper levels are likely to be X.400 and FTAM (file transfer and management) using the appropriate ISO session and presentation layers.
Products to support CCITT Recommendations of the X.400 series are already available (or soon will be) for several major systems although in the case of IBM it is an experimental system.
Interactive services will be provided by X.3, X.28, and X.29 over X.25 although these protocols are not and are unlikely to become ISO standards.
Products to support CCITT Recommendations X.3, X.28, and X.29 are already available (or soon will be) for all major systems.
At a future date JTP (job transfer protocol) and VTP (virtual terminal protocol) will be added but these are currently not stable.
There is some consideration of interim recommendations from RARE and CEN/CENELEC for driving full screen terminals. These concern the UK Simple Screen Mode Protocol (SSMP) and the use of ISO 844.
RARE is following the functional standards being generated by the CEN/CENELEC CEPT project. Functional standards define the exact stacks of protocols to be used to provide given services. They define the options to be provided and any parameter values required. The use of functional standards ensures that implementations will interwork.
**** FTAM does not provide to the receiver information about the filesize as NETDATA does. (FTAM does provide information on the filesize but its provision on all systems depends on it being in the various FTAM functional standards). ****
**** FTAM does not provide recovery. (Again FTAM does provide the facility. Some SPAG profiles do not include recovery but there is pressure for the CEN/CENELEC one to have it). ****
The performance of both X.400 and FTAM are not yet known. Performance will not only depend on the protocols themselves but on the quality of their implementations.
EARN currently provides file transfer, job transfer, mail, and messaging services. Network management is provided.
EARN also provides added value services which currently include the NETSERV information services, directory services, the LISTSERV mail distribution system, and RELAY (what's this?).
Temporary note- are there others?
The RARE recommended protocols will provide file transfer, mail, and interactive services. Job transfer and better interactive service will be provided at a later date.
Some study is being undertaken into services similar to NETSERV.
The EARN message service will be lost. This service is popular and its loss is serious. To some extent its loss can be ameliorated by the use of interactive services or mail.
It is inevitable that the user interfaces may be different. This is not serious as long as the services are more or less as easy to use. A study of the user interfaces for each option is included.
Ideally the user interfaces should not change or should only be extended to avoid confusing the users.
User interfaces depend on the particular implementation. There is no intention in this exercise to recommend any move to common user interfaces. If this is to happen it should be as a result of further standardisation activities of ISO or at least RARE activities. In many cases ISO applications will be provided via existing user interfaces which may be extended.
EARN may have to use software and maybe hardware provided from a variety of sources on a particular machine. This strategy is preferable to waiting from systems from particular sources which could delay migration.
It is vital that at no time should the network be divided into two or more unconnected parts. Thus gateways are needed between different network systems to preserve interworking as defined in each option.
During transition there will inevitable be a measure of Disruption as network methods and user interfaces change. This must not adversely effect the users even though there may be a measure of inconvenience. For each option the possible disruptions are considered.
All the international nodes are IBM machines operating under VM/CMS or MVS. These use RSCS(release 3), RSCS(release 2, or JES2. The services NETSERV, RELAY and LISTSERV are operate under VM/CMS.
The migration of EARN within a country is expected to be the responsibility of that countries management in order to take account of other national plans. In some cases counties will expect to receive some assistance from EARN to aid their migration.
It is important to consider how systems other than IBM VM/CMS ones can migrate either instep with the international part of the network or at a later date.
The most important are is electronic mail. EARN has connections to several networks providing electronic mail using various protocols and various addressing schemes. Important representatives are ARPA, JANET, UUCP and EARN which use variants of the RFC822 protocol and EAN using a variant on X.400. Further X.400 networks can be expected soon.
Temporary note - We have to discuss the question of whether EARN will become an "official" domain of the internet scheme. If so rules are needed for naming subdomains. Countries can now become domains. In addition one can expect that each EARN X.400 system will become an X.400 MTA and this will require some naming rules.
An EARN user requires mail exchange between current EARN systems, future EARN X.400 systems and systems accessible via gateways. This involves three protocol/address schemes:
a. The native IBM NJE-RSCS addressing
b. Internet domain style addressing
c. X.400 addressing
a. This is not a problem. Either user@host.BITNET, user at host, or user@host are used Temporary note - I do not understand this. There seems to be a problem that such mail cannot interwork through gateways. In that sense it certainly isn't a problem! Also user@host.BITNET demands the use of some sort of MAILER while user at host does not.
b. and c. are local matters for each country. Thus only a framework of addressing concepts is necessary.
b. The internet naming rules (we need a reference to these rules) require that any address (in Europe) should end with a country code as the top level domain. The registration of countries and the selection of subdomains is a matter for each country. Currently there is only one conflict (which is?). At some places gateways to subnetworks appear (example?) that use addresses that fall inter the internet name space (legally or illegally?). To avoid routing problems within the international EARN and internet community such addresses are discouraged as long as the country is not reachable via ab EARN-internet gateway. Temporary note - I do not understand the above. Does it say that local networks which have an addressing scheme which conflicts with the registered internet addresses should be encouraged to change?
c. It is likely that in the future EARN systems will become members of X.400 networks, i.e. each EARN node will have a set of X.400 attributes which define the node. (MTA-node-mapping).
Thus each country must discuss their X.400 with RARE.
Temporary note - Should EARN discuss this with RARE or the national academic community?
Temporary note - I am worried that the above text is insufficient to put across our point of view.
Three options have been identified which are outlined below. The options are known as "SNA option", "X.25", and "top down" option.
Note - To avoid confusion the term SNA(IBM) refers to the IBM proprietary protocols implementations and SNA(ISO) refers to the IBM(ISO) protocols implementations. Both of these form part of the SNA range of products.
IBM's network products will normally be based on the SNA (system network architecture) products. Thus, both the SNA(IBM) proprietary protocols and SNA(ISO) protocols will be within SNA. Currently the SNA(IBM) proprietary protocols are available and SNA(ISO) ones are becoming available.
Currently IBM uses two different implementation techniques: X.25 PVCs can be used as a substitute for the lower layers (of what?). GTMOSTI will allow the running of OSI level 5 protocols above SNA(IBM) session.
The migration path is to first migrate the international links to use the proprietary SNA(IBM) protocols. This change will be invisible to users.
This will provide better performance, network management and reliability by facilities like load balancing and alternate routing.
The second stage is to use X.25 on the international links which will again be invisible.
The third stage is to migrate the upper protocol layers. It is at this stage that gateways between the current EARN protocols and the ISO ones will be required.
During the second stage a decision will be needed as to whether the international links will operate over the public networks or whether the existing network should be used with the use of suitable X.25 switches.
Current IBM products like JES2, JES3, and RSCS support at the same time BSC, SDLC, and X.25-PVC. The PTTs do not currently provide cross border PVCs and therefore the public switched data networks cannot be used at this stage in the migration.
Using the existing leased lines with X.25 switches would allow a private X.25 network with PVCs. It is not recommended that SNA(IBM) is used on all lines but only between IBM systems. There are several reasons why a complete SNA(IBM) network is undesirable (what are they?).
The decision as to whether EARN within a country will operate over the public network or use the leased line for X.25 will be a local decision depending on the national academic plans.
The VAX computers offer the IBM proprietary SNA protocols and can follow a similar migration path. Alternatively a country may wish to move directly from the current systems to ISO ones.
Many other computer vendors offer SNA(IBM) protocols. Because the IBM products JES2, JES3, and RSCS support BSC, SDLC, and X.25-PVC at the same time the migration path for non-IBM systems are not dependent on that for international nodes.
Note from Peter - given the fact that VAX systems are not on EARN backbone systems it is outside the scope of this work to discuss how VAX systems are migrated to ISO protocols. The only relevant question is whether EARN backbone system will allow concurrent use of SNA and ISO protocols (on a certain level). Note from Paul. You have to consider the implications of the migration on the systems within a country. Could you sort out what you want to put in.
The first stage is to provide an X.25 infrastructure. This may be based on the public networks or on taking a portion of the current bandwidth on the international connections. The use of leased lines will require the use of multi channel modems and the installation of a number of X.25 switches.
The second stage is the provision of gateways between the current EARN protocols and the ISO ones.
The third stage is connection of machines to the X.25 network as they are able to provide ISO protocols.
A set of selected countries which are willing and able to run an IBM SNA machine (either VM-SP4 with RSCS-V2 or MVS with JES2 or JES3-BDT) should use the existing EARN international lines and build an SNA(IBM) network. This backbone will provide virtual point to point connections between each country. In the first step the only SNA(IBM) application will be NJE. Each backbone serves as a store and forward node into a country network. Countries which are not able to connect with SNA(IBM) can be connected as now.
To be supplied.
The SNA option allows two alternative migration techniques: Using IBM products like GTMOSTI, ISO high level protocols can be sun above SNA(IBM) session. The other alternative is using X.25 switches and replace the backbone by a private X.25 backbone with SVCs and PVCs and using PVCs for the SNA applications.
Currently no further gateways are needed. During the migration it will be necessary to install hardware and software at the backbone nodes.
It should be possible to set up a kernel backbone within six months. This depends on the availability of SNA software on the backbone hosts. Currently France, Italy, and Germany have SNA software.
The prices for the IBM products taking into account discount but not tax are:
Software product Monthly charge Onetime charge ACF/NCP V4 5668-754 DM 427 - ACF/SSP V3 DM 572 DM 1716 X.25/NPSI 5668-981 DM 449 DM 1347 ACF/VTAM 5664-280 DM 1749 DM 5252
The ACF/VTAM product can optionally be ordered with a one time licence fee. This fee is dependent on the processor power and is:
DM 16224 for processor group 10 DM 28386 for processor group 20 DM 40554 for processor group 30 DM 64884 for processor group 40
The discount for educational and research establishments of 40% is included. Not included is the so called ASIA regulation where the software products stated above may be used for one year effectively without charging because it is a problem to convert it to running costs due to the different estimation of software lifetime.
The prices for the connection of DEC VAX11 systems under VMS is:
For the connection to a packet switched network the PSI software is required. Installation have to pay a onetime charge (for licence, medium and documentation) and a monthly charge (for update service). The level is dependent on the processor model.
PSI for Monthly charge Onetime charge VAX 11/730 DM 244 DM 9923 VAX 11/78x DM 244 DM 12218 VAX 86x0 DM 358 DM 17820 VAX 8800 DM 455 DM 21195
The discount for education and research establishments of 10% is included.
Prices for the connection of Siemens systems under BS 2000 are:
Siemens offers for Siemens systems 7.5xx under BS 200 a software package for education and research establishments for a onetime charge, which contains all necessary components for X.25 connection. Most universities in Germany have such a contract so that no additional license costs accrue. Only the maintenance of the software products X.25-Port, VTSU-X.29, and SWPAD-X.28 is charged at a level dependent on the processor.
SW-PAD, X.25, X.29 Monthly charge 7.530 DM 294 7.560F/H DM 346 7.590 DM 427
There is no discount on maintenance costs.
The conclusion of this comparison is that the prices for the IBM components required to run OSI services are prohibitive. Therefore negotiation with IBM is required.
The option requires the provision of an X.25 infrastructure at an early stage.
The X.25 infrastructure may be provided by the public data network or by the use of leased lines or by a combination of the two.
The use of the public network requires no equipment but will attract the normal X.25 volume charge on traffic. Currently, the carriage of EARN traffic by this method is not economically possible. Currently all the European public networks provide X.25 (1980). The date for the provision of X.25 (1984) on the public networks is slowly becoming available and indicates that for a reasonable cover of Europe a four year period should be expected. The provision of ISO high level protocols requires the provision of X.25 (1984) as the ISO network service cannot be provided without the X.25 extended address facility. It is unclear when X.25 (1984) will be commonly available throughout Europe. It is possible to provide the ISO services with the use of convergence protocol but this is not recommended as it will demand a further migration stage with the attendant requirement for gateways at network level.
There are possibilities of utilizing X.25 equipment which already exists. This would present a number of problems. All X.25 equipment in the community offers X.25 (1980) and not (1984). The use of (1984) is not expected in the near future. Networks have established addressing structures and it would be difficult for EARN to harmonize with more than one network, even then it would be difficult as, for example, JANET has made very full use of the addressing space. This leads to the view that EARN will have to provide network level gateways between itself and any other X.25 networks. The more positive result is that EARN will have freedom to construct its own address scheme.
Leaving aside political considerations the main concerns are tariffs and performance.
The public X.25 networks will continue to attract a volume tariff in the foreseeable future. The tariffs are likely to remain relatively high since X.25 networks are not very profitable. A private X.25 network is cheaper since it does not have the same level of availability (25 hour staffing). In a private network many of the costs are hidden since the operation, maintenance, and management of the network can be undertaken by computing centres at marginal cost. The principle draw back of a volume tariff is the inescapable conclusion that the costs have to be returned to the end user to avoid a given user bankrupting the organization. The management of such accounting and control mechanisms is difficult and expensive.
Temporary note- this needs some expansion.
The public X.25 networks were expected to provide low volume interactive facilities rather than the bulk traffic which characterizes EARN. In particular the international connections provide point to point performance of about 2000 bits per second. However a DTE can support a large number of such connections. Experience with private networks shows that an X.25 network can be as performant as EARN. A problem with the international links is that they are in general 9.6 K bits per second and few of then. It is understood that these links will be upgraded to 64K digital links as these become available.
The expectation is that public networks should be able to provide the performance required at some future date. A private network with about the same number of international leased lines should be able to provide a performance similar to the current EARN network.
If a private network is provided then some reorganization of lines would be needed which would depend where switches are located and how many there should be. In some cases use could be made of current X.25 equipment. Some study would be needed to decide how EARN would interface with other X.25 networks as it is unlikely that an international academic X.25 DTE numbering scheme will be developed. It will also be vital to choose the correct NSAP and X.400 naming and addressing.
There are some indications that private networks such as EARN may have more freedom to exist in the future with the further liberalization of the European PTTs.
The working party concluded that.........
The CEN/CENELEC CEPT functional standards are:-
PrENV 41 104 T/31 Transport service over X.25
PrENV 41 201 A/3211 MHS-UA+MTA: PRMD-PRMD (P2+P1)
A/323 MHS-(Intra-PRMD) (P2+P1*)
A/325 Mailbox Service Access (P7)
A/111 Simple File Transfer
A/112 Positional File Transfer
A/113 Full File Transfer
A/122 Positional File Access
A/13 File Store Management
PrENV 41 901 Y/11 Y/12 X.3
Note- Items with no PeENV numbers are not available but are currently of secondary interest.
Transition to ISO- This is a document defining how JANET will migrate to use ISO protocols and provides a check list of many of the factors which need to be taken into account.
RFC 987 (Steve Kille) - This gives a definition of how an RFC822 to X.400 gateway could operate.
There are a number of RARE documents from their working groups but these are not yet stable.
List of ISO documents to be supplied.
List of IBM documents to be supplied.
BOD The EARN Board of Directors CCITT Comite Consultatif International Telegraphique Telephonique CEN/CENELEC Comite Europeen de Normalisation/ Comite Europeen de Normalisation Electrotechnique CEPT Conference Europeenne des Administrations des Postes et Telecommunications DTE Data Terminal Equipment EARN European Academic Research Network FTAM File Transfer and Management IBM International Business Machines ISO International Standards Organization JTP Job Transfer Protocol MHS Message Handling Service NSAP Network Service Access Point OSI Open Systems Interconnection PRMD Private Mail Domain PTT Posts, Telegraphs and Telephones ? RARE Reseaux Associes por la Recherche Europeenne RFC Request For Comment RSCS Remote Spooling and Communications System SNA Systems Network Architecture VAX VM/CMS Virtual Machine/Conversational Monitor System VTP Virtual Terminal Protocol
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 (in the USA), NORTHNET (in Canada), and GULFNET (in the Middle East) 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 until the end of 1987.
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 services are connected. There are gateways to the public X.25 network, to ARPA, to UUCP, to EAN, and to EARN.
JANET 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 X.25 and 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. It does not allow interactive traffic.
In JANET files may be sent to EARN nodes from machines offering 'Blue Book' file transfer. Files can not be 'fetched' from EARN nodes. The transfer of binary files is allowed but 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 systems such as the Columbia Mailer and its associated user interface under VM/CMS. This is not essential. The JANET node must offer a 'Grey Book' mail service.
Message transfer, as provided in EARN, is not possible within JANET. It is possible to the Rutherford EARN node from other EARN 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.
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 a message and the information file is then returned.
If a message is used then from a VM/CMS node the command is:-
TELL NETSERV GET fn ft
or if it is not on the local computer:-
TELL NETSERV AT earnnode GET fn ft
'fn ft' is the CMS filename and filetype of the required file. 'earnnode' is the names of the EARN node where the NETSERV is offered.
If a file is used to request information it must be sent to NETSERV at a node offering NETSERV and must contain:-
GET fn ft
Useful files are:-
NETSERV HELPFILE details of NETSERV NETSERV FILELIST an index to the available files ? NODELIST files with filetype NODELIST contain lists of node names for a country
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.IB with user id NETSERV//discnumber. 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 'disks' and the '//discnumber' defines the disc. Files on the 'default' disc, which has a discnumber of 193, need no '//discnumber'.
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 ? $
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 sort out how an entity on one network can be accessed from another network. Unfortunately this often means that additional addressing information has to be supplied by the users to enable the gateways to operate. 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' to provide a stable 'name' for the user.
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 (assuming the use of the ARPA RFC822 standard). It is fortunate that RFC822 is used in EARN and JANET which allows the mail gateway to be fairly convenient.
A full list of EARN, BITNET and NORTHNET node names can be obtained from NETSERV. These have a CMS 'filetype' of NODELIST.
A name is normally associated with a computer. The names have no hierarchical structure. Names often 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. The names can be used for file transfer and often for mail although mail can often have more complex names not related directly with node names but able to traverse gateways.
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. The components of a name are separated by '.'. A name has 'contexts' associated with it which define which services it applies to.
Note that other networks also have a similar scheme but in all other cases the most significant or top level element comes last. In JANET it comes first. You are warned that this causes unending confusion.
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 MAIL contexts if mail is to be sent from JANET to EARN. It must be available in FTP (file transfer) context for file transfer purposes although 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.
File transfer is only possible if the JANET node offers 'Blue Book' file transfer and the NETSERV file NRS DATABASE gives this information. Look for the entries marked 'FTP'.
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.
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. It 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. This restriction is hopefully temporary.
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, and filemode. 'remfile' is the remote file name on the JANET node and it must be a valid on that 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 operation of the gateway is controlled by a number of '*FILE' records which should be as near to the front of the file as possible, as their content must be determined before the file transfer through the gateway can start. Files can only be sent from EARN to JANET and may not be fetched. There are no reports of the progress of a transfer once it has reached the gateway.
The file, containing the '*FILE' records is sent to EARN node UKACRL and user id JANET either as 'punch' files of up to 80 characters per record, or as 'print' files of up to 132 characters per record plus carriage control.
There may be several '*FILE' records which must be adjacent. Only the first set of such records is recognized. The 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. A 'key=value' pair may not span two records. 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. 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. The 'key' is a keyword and the possible 'values' are defined below:-
SITE (Mandatory)
Normally the registered name of the destination such as
UK.AC.OXFORD.PHYSICS.VAX1 or its short form UK.AC.OX.PH.V1 .
Exceptionally it may be an X.25 DTE address with 'Yellow Book'
subaddress (normally .FTP). Advice should be sought before
using this form.
USER (Optional)
The user id on the remote entity.
PSWD (Optional)
The password associated with the user id on the remote entity.
DEV (Optional, default is LP)
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 (Optional)
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 (Optional)
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 (Optional, default is YES)
If the value is 'NO' all control characters are translated to
nulls. If the value is 'YES' no translation takes place.
MAIL (Optional)
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 (Optional, default is YES)
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 (Optional, default is YES)
If the value is 'NO' all the '*FILE' recognized will be
removed from the file. That is the first batch.
PSIZE (Optional, default is 256)
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 (Optional, default is not BINARY)
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.
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.
Files can only be sent from JANET to EARN and cannot be fetched.
The file transfer parameters should be set as follows:-
SITE (Mandatory)
UK.AC.RL.EARN
Note that the JANET X25 DTE number is 000000000002 and the
'Yellow Book' sub-address is FTP.
FILENAME (Mandatory)
This must be any CMS file id consisting of a filename, a
filetype, and optionally a filemode although this is ignored.
The parts may be separated by space or '.'. The gateway makes
no use of this name.
USER ID (Mandatory)
'VNET/earnnode.userid' or 'VNETP/earnnode.userid'
'earnnode' is the name of the EARN node which is a string of 1
to 8 characters. 'user id' is a logging in identifier on the
relevant node and is between 1 and 8 characters. Files are
delivered in DISK DUMP format unless the
'VNETP/earnnode.userid' form is used, in which case they are
delivered in card image format but the logical record lengths
must not exceed 80 characters.
ACCESS MODE (Mandatory)
The access mode must be one of the following:-
Make only, Replace only, Append only, Make or Replace, Make or
Append. These are all equivalent. Take job input. (For
delivery of 80 column punch format). Take job output. (For
delivery of printing format).
FILESIZE (Optional)
Files must be less than the 'filesize' if supplied. If no
'filesize' is given a file must be less than 8 M Bytes.
CODE (Optional)
EBCDIC, IA5 or BINARY are supported. BINARY is only meaningful
between IBM computers. The effect of BINARY is mostly to
ensure that no translations are carried out en route. The
default code used between IBM systems is EBCDIC to avoid
inconsistent conversion tables.
PFCONTROL (Optional)
ANSI paper-feed control should be specified for files destined
for a CMS file of filetype LISTING.
MAXIMUM RECORD SIZE (Optional)
The maximum record size is 1024 bytes. Files of arbitrary
record size can transferred between IBM systems by means of
DISK DUMP format.
BINARY WORD SIZE (Optional)
For the transfer of binary files the word size must be 8.
All other file transfer parameters are optional and are ignored.
Once a file has entered the gateway no further diagnostics or indications of success or failure are returned.
Examples for popular machines transferring a file named FRED to SID at EARN node DEARN are:-
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:-
FTP SEND FRED DAT AS XX XX TO VNET/DEARN.SID AT UK.AC.RL.EARN
Note that the Rutherford IBM machines are connected directly to EARN and thus the CMS command SENDFILE or similar should be used.
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 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 less desirably
receiver%nrsname@AC.UK
'receiver' is 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.
A mail file may be constructed with an editor in which case it must contain as a minimum:-
From: userid@earnnode
To: receiver@revnrsname
Date: day, date time timezone (this is not checked)
a blank line - very important
The text of the mail.
The file must be sent as a PUNCH file to user MAILER at EARN node UKACRL with class M.
Example of a mail file:-
From: Fred@CERNVM To: Harry@VAX1.PHYSICS.OXFORD.AC.UK Date: Wed, 8 Oct 1986 22:26 GVA This is the text of the message.
Detail of the mail protocol may be obtained from the relevant RFC822 document.
The JANET system must offer 'Grey Book' mail and the receiving system should offer an RFC822 mail system. Its absence will only cause inconvenience by not providing error reports to the sender.
The 'To:' field must contain:-
receiver@EARN.revearnnode
or less desirably
receiver%earnnode@UK.AC.RL.EARN
'receiver' is the 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. In most cases EARN node names are only one component so there is no problem. 'earnnode' may refer to a node outside of EARN which can be accessed via a gateway.
Examples of the content of the To: field 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. A very frequent diagnostic states that the name is too long. At many EARN sites there is no mail system and in these cases names are limited to 8 characters and longer names cause this diagnostic.
Line lengths in mail must be less than 80 characters as lines are truncated before reaching the gateway. This is a temporary restriction.
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.
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 in files with 'filetype' NODELIST.
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@UK.AC.RL.EARN
Where 'domain' is the address of the recipient on the remote network.
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 precede 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.
No changes to file transfer are planned.
BSMTP is accepted but not used.
BSMTP is not generated.
Reply-to: and Acknowledge-to: fields is not manipulated in the gateway.
To: and From: fields are converted in the gateway by the use of 'source routing' techniques which will be replaced by the more acceptable manipulation of the 'domain' address.
Lines in mail from JANET to EARN are truncated to 80 characters before reaching the gateway.
No access to EARN directory service
No access to EARN conferencing service GRAND
Use of VM/CMS FTP exec
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
Use of *FILE records. Insert one or more records at the top of the file
//* *FILE SITE=nrsname,USER=userid,PSWD=pswd,DEV=FILE
//* *FILE FILE=remfile,KEEP=NO
The file is sent to JANET at UKACRL
Use 'Blue Book' FTP to send file with parameters:-
to NRS destination UK.AC.RL.EARN
user id VNET/earnnode.userid (disc dump)
or VNETP/earnnode.userid (80 char punch)
remote file name any valid CMS file name (MAX8CHAR.MAX8MORE
password not required
Send the mail
To: userid@revnrsname or To: userid%nrsname@AC.UK
Use 'Grey Book' mail.
To: userid@EARN.earnnode or To: userid%domain@UK.AC.RL.EARN
Use 'Blue Book' file transfer of selected file from userid NETSERV//disc from NRS name UK.AC.RL.IB . The list of files and the 'disc' can be found from the index. Useful files are:-
NETSERV.FILELIST disc 193 index to files
JANET.EARNGATE disc 193 this file
NRS.DATABASE disc 193 the NRS database
NETSERV.HELPFILE disc 193 details of NETSERV
?.NODELIST disc 193 lists of EARN nodes
JANETFTP.PACKAGE disc 193 the FTP exec, no use in JANET
File$.LIST$ another index to files
At the Group Leaders meeting it was decided that PACX should be phased out over a number of years.
The reasons for removal are:-
An investigation is in progress to decide what type pf local area network should be provided on the Rutherford site.
The details of this exercise will be available by the end of the first quarter 1987 with a view to installation during the subsequent financial year. Although this document is not yet available this proposal is based on the current thinking and indication are that this will not change except in detail.
'Villages' are defined which are sets of closely related machines not necessarily within a single division.
Within a village terminals will predominantly access the village machines and will therefore be connected to the village machines as effectively as possible. How this is achieved is determined by the local management.
The machines within a village will normally be on a high speed local area network.
The site will provide a backbone high speed network to which the local networks will connect by means of bridges. Thus the local traffic will not use the backbone.
Access from terminals to remote facilities outside the village will be via PADs within the village machines.
In some cases terminals will be spread over a large geographical area and PADs will be provided which will normally be connected to the village network or unusually to the backbone to service these PADs.
The backbone and village networks will also carry file transfer, mail, and other services.
The backbone is currently under investigation and is likely to be based on the ISO ethernet.
The networks within the villages may also be ethernet but this is the responsibility of the village management. If it is not ethernet then it will be the villages responsibility to match the interface provided by the bridges to their technology.
The ultimate objective will be to operate the backbone with ISO protocols as specified in the JNT Pink Book.
In the short term the absence of ISO protocol implementations will be made up for by the use of:
These protocols and the ISO protocols can coexist on a single network.
An investigation has taken place which will result in a recommendation to install a backbone network based on ethernet. A number of suppliers have been invited to suggest how Rutherford should proceed and the various meetings have been attended by members of most divisions. The study has established that all the required hardware is available. The view of the technical experts is unanimous. (To be confirmed).
The DECNET, TCP/IP, or TP4 protocols are available on the village machines which wish to use them.
CCD and HEP are developing an experimental ISO connection between a VAX and the IBM machine. This will initially use coloured book high level protocols but will follow 'Pink Book' at the lower levels. Results of this experiment should be available by the middle of the year. The work is in conjunction with ULCC and is encouraged by DEC. The development will provide interactive services.
The Spider ethernet PAD will be evaluated using the experimental connections into the IBM and VAX computers.
RL is evaluating imminent developments which will allow IBM PCs to connect to an ethernet. This work is based on products from various sources (BICC, Exeter University, and Edinburgh University). The work is supported by IBM and should provide services towards the end of the year. CCD may implement the async 3270 protocol within this scheme.
Although the network hardware could be in place by the middle of the year, the protocol situation will not provide uniform services for a number of years. Exact time scales depend of manufacturers plans and the transition exercise of JNT.
This will preclude open systems interactive services across the local area network in many cases but the current services will still be available as long as needed.
Currently the activity should be to reduce the load on PACX but in line with developments which lead towards the ultimate objectives. These activities are:
Ideally 3270 services should be carried over the network. This is currently no way in which this can be done. It would certainly be possible to operate async 3270 or SSMP although the performance would not be likely to rival a terminal on a coaxial connection. Whilst it may be possible to replace real 3270 it would be more difficult to put secretarial workstations on an ethernet as these connections are becoming increasingly sophisticated and would need a range of ISO protocols to be available in a convenient and well integrated form and this will take a long time.
A number of other sites and a number of manufacturers will be using and providing the products required and it will be important to have close relations with them. For example - Edinburgh University and Spider.
A gateway between JANET and the backbone network is required. For interactive traffic this can be via any computer with an access to both networks. The other protocols are more difficult to deal with particularly with the migration from coloured books to ISO in the offering.
As long as coloured books are run over the local area gatewaying will be simple. Where a translation between ISO and coloured books is needed converters will be needed. For file transfer the GIFT project may provide a solution if the project to make FTAM part of the system are successful. For mail UCL have developed a converter. If the EARN X.400 project is successful the IBM could be used as a Gateway. It must be remembered that this is a subject of great interest to the migration of JANET and there is some confidence that suitable products will emerge. This topic will be considered in detail in a future paper.
Les Clyne is producing a report on this meeting and so only a few comments are given here.
The meeting first gave each contributor an opportunity to present their comments.
The afternoon considered the changes to be made to M-IT-02 and its supplement. This discussion only covered about half of the topics. The meeting was mostly in the form of a discussion and on many points no firm decisions were taken but the editor will take all the comments into account.
The UK comments were not particularly well received. The principle problem is that the UK appears to be alone in worrying over the formalities of the functional standards activity. The BSI comments on ODA were challenged on the grounds that the protocols would not have unacceptable overheads and, in fact, were already being implemented on PCs. Unfortunately the UK had no expert on this topic present.
15 members were present - a good turn out. There was no formal agenda as the editing of M-IT-02 was expected to be the major topic.
The Commission, being present and interested in screen mode terminals, put forward a case for action in this area. They suggest that ISO 446 (a character set) over ISO session should be a Q profile. The adoption of a profile based on VTP was not encouraged as the current version would provide little more than triple X and would probably not be used. It was suggested that further views should be sought by questionnaire.
ODA was accepted although any action may take time to start because of the effort needed.
There will be a LAN voting meeting on 5 ENVs later this year.
FTAM is off to a good start. A/111 will be done first.
Triple X will have one further technical meeting in February which will again be a joint CEN/CENELEC CEPT one. The previous one was a success. ITEAGS confirmed that Y/11 Y/12 should be applicable to a PAD. They also allowed Y/11 Y/12 to be applicable to the combined PAD/DCE. The lack of a Q profile for the character codes should be noted in a footnote. The question of triple X over a CO LAN was raised but no action taken. Some thought was given to triple X over CL LAN but no action is expected due to the lack of protocol standards.
There is a problem of what happens when conformant implementations 'meet' which have different character sets and there is no opportunity to negotiate. Here groups are encouraged to describe the difficulties.
The afternoon was dedicated to considering M-IT-02.
The ISDN entries were considered but I have the feeling that we will see some difficulties and a slow start. I had the feeling that (as with ODA) the meeting was not familiar with the subject.
Unfortunately there was little time to consider M-IT-02 in the detail it deserved and it will be edited on the basis of the comments received.
I established that the formal route to insert new activities is from a member body to ITSTC. Presumably any comments on the programme should also take this route as well as by the ITAEGS open meeting route.
The principle comments I would make are:-
I am some what surprised that this ancient paper of James's had surfaced since it is completely out of date. It was written when we were just getting going, James was somewhat anti EARN, and we were developing fast. It is totally out of date since its content were put together with all the other input and dealt with as appropriate. It was discussed at the EARN users meeting and the views taken account of. The date at the top of his paper of April 21 1986 is curious since the version I have is dated February 12 1986 which was also the date of the meeting.
To comment on the points:-
1. The JNT recommended mail names POSTMASTER, SUPPORT, OPERATOR, and ADMIN are supported on the IBM, VAX, and GEC. I cannot speak for PRIME, NORD or other machines over which we have no control. We do have a problem as to what POSTMASTER@UK.AC.RL (as opposed to UK.AC.RL.IB) refers. In principle I would like them to go to service line. However for historic reasons POSTMASTER goes to Shirley, OPERATOR goes to Liz, SUPPORT goes to ICF and I am not sure about ADMIN. I am getting Shirley to redirect UK.AC.RL to service line. Unfortunately due to limitations of the GEC mail this means that such mail to RL.GB will also go to service line. This may effect ICF - or its remnant.
The above is nothing to do with EARN.
EARN uses the mail names POSTMAST and INFO. These are supported in the MAILER. Unfortunately mail that avoids using the MAILER (IBM NOTE, PROFS, or a direct RSCS transfer to POSTMAST) will fail giving rise to some irritation from the user.
Therefore- another good reason for attempting to get all mail to go via the MAILER.
2. There is absolutely no hope of obtaining an IBM 4361 for the gateway. I do not believe that one is needed. It would be one more piece of equipment to look after and pay maintenance for. I do not know the load on our IBM and perhaps we should find out. I would prefer a gift of disks.
3. EARN has a failure reporting service called LINKFAIL. This is a distribution list and our operators are on that list. It is for them to decide what to do with information coming in and for them to decide what to submit. Much of the incoming information is not relevant. Thus they decide if information is to go to NETSTATUS or JANET.NEWS. In reality I do not think they do either as these facilities are not of much interest to users. Certainly few people know JANET.NEWS exists and NETSTATUS is not used much by the man in the street. The system we have does allow service line to know the state of EARN and respond to any inquiries.
4. The procedure for UK academic sites becoming members of EARN is NOT cumbersome. All they do is to fill in a simple form and send it to me. It is difficult to conceive of a simpler system. All I really want is a signature to ensure they have read the condition of use. I object to the comment that EARN is interested in 'site counting'. The object of membership is to ensure that rules of EARN are known and observed, to provide a list of sites who determine how UK EARN is managed, to advise the EARN management, and also to bring us into line with all other countries which also have EARN membership. Representations to EARN to allow all JANET sites to automatically be members failed. In addition suggestions that EARN should be dealt with by the JANET user groups failed. EARN does have an interest in maximum publicity for the service and maximum number of accessible computers from the point of view of providing a service to its customers.
James was not happy that HEP did not have EARN membership of some sort and pointed out, as others have, that often the communication between the EARN site representative was poor. Apart from a lot more effort going into publicity this is a real problem.
5. Traffic may well take this route or that depending on circumstances. It may be James's view of what is wrong but he doesn't have to operate the network and had only partial knowledge of what goes on. Any way, it is history and the network is continually changing to meet requirements. For example, a satellite link between Montpelier and the states is going in, the Rome/CUNY line has been relocated to Pisa, and so on.
6. The refusal to accept UK CERN traffic was because CERN did not know what tariff would be charged. This has been resolved and the line is used for this traffic. James's irritation with CERN had some substance.
7. What documentation? NETSERV is stuff full of documentation and we have produced documentation. Whilst it could be improved I am not sure what extra documentation is required which would also be useful. Our principle documentation problem is that sites are members and not people and thus documentation goes to site representatives and not the end users. It would be difficult to maintain a list of users as the population is ever changing and there is no user registration mechanism.
Mind you, the quality of German, French, Italian, and Spanish EARN documentation leaves us with some shame. Theirs is on glossy paper and in colour while ours is xeroxed, in line with the rest of our documentation. Others have screwed more cash out of IBM.
8. MAIL is available and of a good quality so this comment is out of date.
9. Software is available for VAX/VMS and IBM/MVS and most other machines. Incidentally, there are more VAXes in EARN than any other machine.
10. The treatment of mail is deficient in the way it deals with acknowledgments and work is in hand to improve this.
11. Errors do occur such as looping. Each error has its own manifestation and a list of possible errors and their symptoms would contain many errors that never occur and would not contain the errors that you do not know about which will occur. We have a similar problem with JANET and there is no similar list of symptoms for that network and none seem to be needed.
12. There is no way of knowing what a remote system will do with mail for which there is no recipient. Therefore it is impossible to inform users on JANET if mail goes astray. It would be possible in some circumstances but would require considerable effort to implement since records would have to kept of all mail going through the gateway to enable messages returned to be interpreted. Work in this area is right at the bottom of the list.
13. RLVM370 has been removed.
14. The RAL system is setting class M on mail.
Note- outstanding questions are enclosed in //...//
5.1.1. Provision of an X29-like Service over the OSI NS
The OSI NS as specified over ISO 8208 in DP 8878 cannot support X29 as:
- DP 8878 does not support the X25 Q bit which is demanded by X29.
- The N-EXPEDITED of DP 8878 is required but is optional. Thus only a subset of NS implementations would support X29.
There are two possible solutions:-
- Extend DP 8878 to allow the Q bit to be passed to the ISO 8208 packet service. Demand the provision of N-EXPEDITED in procurement.
- Define a protocol to allow an X29 like service over DP 8878. This would be similar to TS29 and is named NS29 in this document.
The first option deviates from DP 8878 and may attract opposition from a standards point of view and it may be difficult to demand suitable extensions to DP8878 implementations. The demand for N-EXPEDITED should not attract opposition. Suppliers may be reluctant to provide versions of X29 to operate over DP 8878. The remote entity would have the advantage of being unaware as to whether the local end was operating X29 over a network service or over a packet service. //Is this true? The point is important and not explicit in the original text.//
The second option requires no additions to DP 8878 nor does it demand N-EXPEDITE. The definition of NS29 would be similar to TS29 and be straightforward. It may be difficult to encourage manufacturers to supply products. Relays would be required between X29 and NS29.
In both options requirements will be placed on implementations which are specific to the UK academic community. It is unclear whether other customers would support the developments of these products.
It is recommended that the first option should be adopted.
Although OSI protocols being developed, in particular VTP, may make the requirement for X29 obsolete the expectation is that this will take ten years.
5.1.2 Choice of Protocol
Most JANET services run a close approximation to the (80) revision of X29 as a result of the Green Book requirements and PSS compatibility.
The (84) revision of X29 is a superset of the (80) one. The extensions are:
- A further four additional (optional) parameters are defined and a number of further optional parameter values for parameters 5 6 7 9. Parameters 16 and 17 now have mandatory values.
- There is a reselection PAD message.
- Explicit D-bit behavior is defined.
- Parameter Indication PAD messages carry error codes for invalid attempts to adjust parameters (always 0 in (80)).
- Additional error codes are defined for PAD error messages.
- There are many changes which are clarifications of the (80) Recommendations or Recommendations where (80) indicates areas of further study.
Successful interworking between equipment aligning with (80) and (84) Recommendations depends on:
- Whether a (84) packet mode DTE demands the use of the new parameters or new parameter values not available in a (80) PAD.
- Whether a (80) packet mode DTE will tolerate the existence of the new parameters and parameter values on a PAD which can be detected.
- Whether a (80) packet mode DTE will tolerate the non zero error codes received as a result on invalid attempts to set a parameter.
It is believed that since the new parameters are optional and also because they are of greatest interest to the operation of the PAD rather than the packet mode DTE they will not be used by the packet mode DTE and even less likely that their use will be demanded. Apart from parameter 7 and 11 the new parameter values and re-classification of values have no interworking implications. The extra optional value of parameter 7 (5) is unlikely to cause a problem. The relegation of the value of 8 (200 bps) of parameter 11 from mandatory to optional will not cause a problem. The toleration of existing (80) packet mode DTEs to the existence of the new parameters and new parameter values as well as non zero error codes is under study. //This will need amendment in the light of the study.//
Leaving aside the interworking between X25 (80) and X25 (84) equipment it is possible to operate X29 (80) or (84) over an X25 (80) or (84) network. //I believe this is true.// //What about the NSAP?//
Indications are that networks will not be offering D-bit facilities. The PAD Reselection PAD message does not effect interworking.
The conclusion is that as long as a packet mode DTE does not demand the use of any of the new parameters or new parameter values then interworking between (80) and (84) implementations of X29 is a question of how the protocol is used rather than which version is used.
There are two ways of using X29 defined:
- Green Book.
- CEN/CENELEC functional standard Y/11.
With respect to interworking the difference is that:
- A packet mode DTE following Green Book expects the PAD to have adopted a specific set of parameter values at call set up and it is encouraged not to alter this set.
- A packet mode DTE conforming to Y/11 is expected to set the PAD parameters to specific values at call set up.
It is thought that no packet mode DTEs follow Green Book in this respect but an investigation is under way. This approach has been taken because many PADs do not follow Green Book and this caused interworking problems. If a packet mode DTE does follow Green Book strictly then the user of a Y/11 conformant PAD (or non Green Book conformant PAD) may be forced to set parameters explicitly. //May need amendment after the investigation.//
A PAD conforming to Y/11 offering basic conformance but not option 1 (i.e following X29 (80) need only offer the essential parameters and mandatory parameter values and may have problems interworking with packet mode DTEs of any type.
Neither Green Book or Y/11 require the use of the new parameters or new parameter values.
The conclusion is that as long as conformance to Y/11 without option 1 (i.e X29(84)) is demanded there should be no interworking problems with existing equipment.
5.1.2 Conclusions and Recommendations
It is MANDATORY to provide X29(80) following Green Book or X29(84) conforming to Y/11 (not offering option 1 and basic conformance) and Y/12 for both packet mode DTEs and PADs. //Dangerous! If we demand Green Book according to the strict letter of the Book it all fails!//
The development of NS29 is NOT RECOMMENDED.
For calls from a Yellow Book network to an OSI Network Service network:
- X29 (80) must enter an interactive dialogue with a relay in order to initiate a further call on the OSI network. //But only if the networks do not share the DTE number space, if they do and if you can gateway between X25(80) and X25(84) the relay is not needed.//
- TS29 is converted to X29(80) or X29(84) over X25(84).
For calls from an OSI network to a Yellow Book network:
- X29(80) or X29(84) is mapped on to X29(80) or TS29, depending upon the number of subsequent hops required.
//I have removed the text on it being desirable for hosts to accept X29(84) since subject to the investigation hosts will accept X29(84). Also I can see no reason why PADs should not generate X29(84) again subject to the investigation giving a positive result.//
//The rewrite goes rather father than I had intended and is the text that I would like to see subject to Y/11 succeeding and the investigations proving that there are no problems.//
//We still have the X28 problem of how you input an NSAP.//
A PAD service signal may optionally be followed by a "-" and an explanatory message which is on the same line. The total number of characters excluding the terminating formatting characters shall be less than 80. The character set shall be all printable characters and space. Versions in alternative languages may be provided.
The changes are in section 3.5 and subsequent subsections. The explanatory text could also be put in TABLE A-2 and TABLE A-3. The X.25 reset codes have not been turned into explanatory text as they would probably not be understandable to the average user. This is debatable.
Add to end of section 3.5
Some PAD service signals may include 'optional explanatory text' as indicated in subsequent subsections. Optional explanatory text shall be preceded by 2/0(SP) 2/13(-) 2/0(SP). The optional explanatory text may only include characters from columns 2 to 7 of the International Alphabet No. 5, excluding the characters 7/15(DEL).
The English versions of the optional explanatory text is defined below. Text in alternative languages may be provided with the restriction that the complete line containing it shall be less than 80 characters excluding any formatting character. Parameter 6 shall control the language used. The language shall be defined using the bits represented by decimal 128, 64, 32, and 16 as follows:
+-------------------------------------+ |Decimal 128 64 32 16 | +-------------------------------------+ |English 0 0 0 0 | |French 0 0 0 1 | |Spanish 0 0 1 0 | |German 0 0 1 1 | |Other encodings are for further study| +-------------------------------------+
The optional explanatory text is enclosed by double quotes (") in this text.
Replace section 3.5.7
3.5.7 Standard format of the reset PAD service signal
The characters 5/2(R) 4/5(E) 5/3(S) 4/5(E) 5/4(T) 2/0(SP), will be sent, followed by one of the following:
a) the characters 4/4(D) 5/4(T) 4/5(E)<code> optional explanatory text " - Reset by remote system, data may be lost" b) the characters 4/5(E) 5/2(R) 5/2(R)<code> optional explanatory text " - Reset by network detected local error, data may be lost" c) the characters 4/14(N) 4/3(C)<code> optional explanatory text " - Reset due to network congestion, data may be lost" d) the characters 5/2(R) 5/0(P) 4/5(E)<code> optional explanatory text " - Reset by network detected remote error, data may be lost" Note - type d is defined in table A-2 but not in 3.5.7 - why? <code> is 1, 2 or 3 characters which may be sent which represent the decimal value of the diagnostic code as specified in Recommendation X.25. Replace 5th line of 3.5.9 by - <CLR CONF> <optional explanatory text> <formatting characters>
Add before TABLE 4/X.28
The optional explanatory text is
" - The call has been closed as you requested"
Insert after 2nd line of 3.5.11
This may be followed on the same line by the optional explanatory text
" - There is an existing call to <called DTE address block>"
This may be followed by an <optional facility block> (see ~ 3.5.8).
Add to end of 3.5.11
This may be followed on the same line by the optional explanatory text
" - There is no existing call"
Replace line 7 of 3.5.17 by
<called DTE address block (see ~ 3.5.17.2)> <optional explanatory text (see ~ 3.5.17.2)> <formatting character>
Replace 3.5.17.1 by
3.5.17.1 Standard format of the mandatory field:
The characters 4/3(C) 4/12(L) 5/2(R) 2/0(SP) will be sent, followed by one of the following character sequences and optionally by an optional explanatory text:
a) the characters 4/15(O) 4/3(C) 4/3(C) optional explanatory text " - The remote system is busy, try later" b) the characters 4/14(N) 4/3(C) optional explanatory text " - Network congested or temporary fault, try later" c) the characters 4/9(I) 4/14(N) 5/6(V) optional explanatory text " - Invalid facilities requested, amend and try again" d) the characters 4/14(N) 4/1(A) optional explanatory text " - Access to this system barred, consult its administration" e) the characters 4/5(E) 5/2(R) 5/2(R) optional explanatory text " - Error detected in remote system, report to its management" f) the characters 5/2(R) 5/0(P) 4/5(E) optional explanatory text " - Error detected error in remote system, report to its management" g) the characters 4/14(N) 5/0(P) optional explanatory text " - The remote system does not exist, consult the directory" h) the characters 4/4(D) 4/5(E) 5/2(R) optional explanatory text " - The called system is out of order, try later" i) the characters 5/0(P) 4/1(A) 4/4(D) optional explanatory text " - Call cleared by remote system as requested" j) The characters 4/4(D) 5/4(T) 4/5(E) optional explanatory text " - Call cleared by remote system" k) The characters 5/2(R) 4/14(N) 4/1(A) optional explanatory text " - Remote system will not accept reverse charging"
Replace 3.5.19 by
3.5.19 Standard format of the error PAD service signal
The characters 4/5(E) 5/2(R) 5/2(R) will be sent, optionally followed by the explanatory text
" - Invalid command, type HELP for assistance, amend and try again"
Add section 3.5.30
3.5.30 Standard format of the no call command reject PAD service signal
The characters 4/5(E) 5/2(R) 5/2(R) will be sent, optionally followed by the explanatory text
" - Command rejected, no call established"
3.5.31 Standard format of the call established command reject PAD service signal
The characters 4/5(E) 5/2(R) 5/2(R) will be sent, optionally followed by the explanatory text
" - Command rejected, call established"
3.5.32 Standard format of the logon failure service signal
The characters 4/5(E) 5/2(R) 5/2(R) will be sent, optionally followed by the explanatory text
" - Logon invalid"
3.5.33 Standard format of the logon reject service signal
The characters 4/5(E) 5/2(R) 5/2(R) will be sent, optionally followed by the explanatory text
" - You are already logged on"
3.5.34 Standard format of the reject profile identifiers PAD service signal
" - No profiles defined"
3.5.35 Standard format of the logoff PAD service signal
" - Logoff complete"
Replace line 5 of 3.5.21 by
- <character 4/3(C) 4/15(O) 4/13(M)> <optional explanatory text> <formatting characters>
Add to end of 3.5.21
The optional explanatory text is
" - The outgoing call is established"
Replace line 6 of 3.5.22 by
- <character 4/3(C) 4/15(O) 4/13(M)> <optional explanatory text> <formatting characters>
Add to end of 3.5.22
The optional explanatory text is
" - An incoming call is established"
Add to end of 3.5.27
this may be followed by the optional explanatory text
" - Input X-ON to continue"
Add to end of 3.5.29
this may be followed by the optional explanatory text
" - The call has been transferred to <reselected DTE address block>"
It has become clear that CCD, and as far as can be seen Rutherford, now have no long term interest in GEC 4000 series computers (except as X.25 switches). This is because:-
These comments do not apply to the use of the GEC 4000 series as X.25 switches.
In view of the declining interest the GEC 4000 machines should be phased out as soon as possible.
Alternative services must be offered which have a long term future.
The level of support provided is small at about 1 man year per year. Most of this effort is for operational effort. The amount of skilled system effort is 10% of a person and dropping. Thus any developments are impossible. Thus the machines are vulnerable. Whilst the software is robust and a tribute to its authors it can only survive as long as current network technology exists. It would not be possible to migrate the machines to the expected ISO protocols or ethernet technology expected in the coming years.
The first stage is a freeze on any system development. Due to staff losses and moves this is a de facto situation and one which must be fully appreciated by the users.
A set of machines have now been acquired from SERC by the sites. In the case of 930(Herriot-Watt, 983(Glasgow), ???(Bradford), and 538(Loughborough) Informatics Division has promised support until 1988. These machines are the responsibility of Informatics Division.
The future of the Swindon machine is not yet known.
A number of workstations have cartridge disks. When RL.GK is phased out there would be an advantage in not transferring its cartridge disk to RL.GB. This would reduce the equipment and therefore the maintenance costs plus the support of the device. This implies that 513(R3), 225(Southampton), 294(Durham), 569(Imperial), 643(CERN), and 644(DESY) must be phased out by end June. Firm plans exist for all but 225 and 569.
Leaving aside RL.GB and RL.GM all machines which are supported or in which there is an interest are due to be phased out by Dec 1987.
RL.GB is mainly used for mail relaying but has a small number of users. This machine is an Informatics Division responsibility.
The remaining CCD users should be offered alternative resources. User support should identify these users and make every attempt to persuade them to migrate with least pain.
The RL.GB provides mail distribution lists and allows mail to be sent to 'real' names at Rutherford. The current developments with the MAILER on RL.IB should provide similar facilities. These are being developed by a student. Currently the code is complete but it will take two months to complete the debugging. It must be realized that the GEC mail systems is probably the best version of Grey Book available and it is unlikely that the new system will be as good. None the less it is hoped that it will provide an acceptable service and one which should be capable of improvement. Allowing for a six month field trial it should be possible to phase out RL.GB by the end of 1987.
RL.GM provides mail for Alvey for both the academic and industrial community. In principle it should be possible to move this community to the IBM. Some care will be needed not to disadvantage the community by increasing the cost of their service. There are special considerations which are examined below.
RL.GE provides a PAD printer service. There are two options. The first is to move the service to the IBM. This would involve IBM network software development and an estimate of this effort is needed. The second option is to move the service to a VAX which is having suitable code developed. Ideally the IBM solution is preferable as this would economize on network activity and reduce the use of hardware. CCD do not have a VAX which operates a guaranteed service on which the PAD printer software could operate.
As an aside it should be mentioned that the use of PAD printers is not well suited to remote printers particularly if large amounts of output are required. The basic problem is that the protocol is badly suited to the task which gives very poor control of the printer. Alternative means of printing should be sought, for example, via other computers located near by.
The current CCD effort is :-
Shirley Wood - Spends a nominal 10% of her time on OS4000 support. This is currently an underestimate but the involvement is reducing.
Nero Knowles - Nero is responsible for putting new users on RL.GM. He is not particularly familiar with this process and so it tends to take about 4 hours a week to put up the 10 or so new users.
Heather Teal - Heather is learning about the GEC to provide some level of support. It is unclear exactly what she will be doing.
Liz Krauesslar + 1 - These operators look after 3 GEC and 5 PRIMES. Thus something under a man year is devoted to GEC operation. Liz also retrieves lost files at the rate of one operation per month which may take a couple of hours.
Operators - Some effort is used for operation in the evenings.
Keith Benn - So far a small involvement.
Roland Brandwood - Small involvement.
Philip Overy - 3% of his time is concerned with GEC mail problems. It is difficult to differentiate between GEC mail problems and mail problems in general.
Note that there seems to be a number of meetings with high CCD involvement which is probably one of the highest expenditures!
In total it seems that it is difficult to identify more than a quarter of a man year going into support and a year into operation.
This machine presents special problems.
There used to be an Alvey mail machine for the academics located at CCD (RL.GM) and one for commercial users operated by BT. The commercial service was moved to RL.GM because of the high cost of support from BT. Unfortunately the machine ran under the GEC unmodified operating system.
The service to commercial users has attracted considerable adverse comment. Investigation has not resulted in any confirmed detail of the criticism which has all been filtered through several levels of management. Alvey appears to have rejected offers of help by, for example, not allowing CCD manuals to be distributed to users and by not providing facilities for CCD to investigate the complaints.
It must be added that the active users have been asked for comment and the result was that there was only a minor level of criticism. Of course the real complainers may now not be using the service. There appears to be some 700 users of which 350 are active.
It would appear that Alvey would be happy if CCD ran a service identical to the BT service. This would involve mounting unfamiliar software and running an unfamiliar service. This would be impossible with current staff.
The recommendation is that fresh attempts be made to access the sources of complaint and attempt to resolve any problems as long as this can be done at modest cost.
In the longer term an attempt should be made to move Alvey mail to RL.IB when its mail service is sufficiently developed and stable. The main arguments to Alvey should be the greater level of support they will receive, the equivalent level of service, the unlikely provision of X.400 on the GEC, and no increase in cost.
The target phasing out of RL.GM should be the end of 1987 but some slippage should be expected.
The Network Executive have confirmed that they have no need for any GEC services as their own equipment is sufficient for their needs.
Decide whether to use a VAX PAD printer server of develop an IBM version Now Declare removal of all support by end 1987 Now Discuss move of Alvey mail to IBM with Alvey Now Closure of cartridge disks machines 1st July 1987. Closure of RL.GK 1st July 1987. Closure of remaining machines 31st December 1987.
Adopt the targets and timescales in section 6 for phasing out the GEC machines for which CCD is responsible.
Increase CCD's commitment and allocation of effort to provide an X.400 mail service under CMS, preceeded by an improved Grey Book service.
Serial Name Location SO Use Future CCD's Responsibility 513 RL.GF R3(Cart) KB HEP wkstn Replace by RL.DE 597 RL.GE CCD KB PAD print serv Replace by RL.IB? 225 SN.GA Soton(Cart) KB wkstn (1) PAD printer offered 294 DU.GA Durham(Cart) KB wkstn PAD printer installed 569 ZI.GA Imperi(Cart) KB wkstn PAD printer offered 643 CP.GA CERN(Cart) JH wkstn PAD printer planned 644 DY.GA DESY(Cart) JH wkstn PAD printer installed 354 SH.GA Sheffield GL wkstn No plans 681 RL.GM CCD KB Alvey mail No plans CCD Interest (not necessarily CCD responsibility) 273 ZU.GA UCL JH HEP wkstn Close Sep. 87 501 MA.GA Manchester JH HEP wkstn Close Feb. 87 515 RL.GB CCD GL Mail/ICF No plans 520 RE.GA ROE ? wkstn No plans 425 RL.GK R1 GL Experimental Close Jun. 87 409 CA.GA Cambridge GL ICF Close Dec. 87 514 BR.GA Bristol GL ICF Close Mar. 87 658 PA.GA Swindon BR wkstn No plans No CCD Interest 537 RL.GD R68 JB Experimental Close this year 930 HW.GA H-Watt(supp) wkstn No plans 938 GW.GA Glasgow(supp) wkstn No plans 516 CF.GA Cardiff ICF Close Dec. 88 ??? BD.GA Bradf'd(supp) wkstn No plans 538 LU.GA L'boro(supp) ICF No plans (1) Southampton have a plotter which is still needed.
GL Geoff Lambert KB Keith Benn JB John Burren BR Bill Robertson JH James Hutton
This document is being sent to EARNTECH and the BOD only.
The next EARNTECH meeting will be held in Crete by the kind invitation of the University of Heraklion.
The final timings are not yet available but it is expected to start at 9.00 on the 26th and finish in the afternoon on the 27th. IBM has kindly offered to host a dinner. We hope to arrange a trip round the antiquities in the area.
Hotel accommodation should be booked through Hara Tomara-Deliyanni (TOMARA@GREARN). The cost of accommodation will be 33 dollars for a single room or 43 dollars for a double.
Hara comments that the weather in Crete should be pleasant and suggests folks may like to stay longer as the northern hordes will not have descended on the Island.
The EARN Executive has considered the meeting and has agreed the following:
Delegates must have the agreement of their BOD member to attend. I will assume that any delegates will have obtained this when they apply. Delegates from other networks (BITNET for example) and companies will be by invitation from myself. BITNET (Arti Ecock) and our IBM colleagues are invited as usual.
Regretfully there is no financial support from EARN.
The Executive has agreed the agenda as detailed below. This time we will be concentrating on a small number of important topics which have been of concern to the executive. It would be of great value if delegates would study any relevant document and get the views of their countries.
1. Minutes of last meeting and matters arising.
2. Migration strategy. A document is under production defining a number of migration paths. A draft version should be distributed before the meeting and the views of delegates will be welcome.
3. Network systems. A clear definition of the EARN networking systems is requested. The object is:-
The object will be the provision of documentation which gives a accurate definition of the basic services expected on all nodes and within all countries. (This does not preclude the provision of additional services).
4. Report on the EARN/DFN connection (Michael Hebgen)
5. Report on SNA-NJE over X.25 with SVCs (Peter Sylvester)
6. Use of Queens X.400 over RSCS (Michael Walsh)
7. Report on BITNET (Arti Ecock/ Peter Sylvester)
8. N.I.C.E. report (Peter Sylvester)
9. Next Meeting
10 Any other business.
Dear Lyn,
I enclose the new ENV for Y/11 Y/12 for you to check with your records. I have had to take a few liberties with A12 as the section has become very repetitive over its reincarnations so I have done some further editing. In most other cases the text stood up to mature study quite well.
I have not done the revision bars yet as these have to be tediously done by hand and I would rather do that on the final copy.
It would probably be easiest if you were to return the document to me marked up and I will then send you a fair copy for distribution.
In the minutes there are a number of points that I think we must make.
1. ITAEGS has agreed that Y/11 may be developed to be applicable to the so called integrated PAD and DCT. They have endorsed the view that it should not be applicable for use over other than X.25 lower layers. It is recognized that the two statements are to some extent contradictory.
2. ITAEGS has again confirmed that Y/11 and Y/12 are applicable to a PAD.
3. Agreement was reached on the integrated PAD and DCE. Unfortunately this has led to two notes being added to the "Definition and description for the profiles" which must be brought to ITAEGS attention.
4. The question of a number of optional features (PAD reselection, D-bit) were raised and new text was agreed.
5. The text concerned with X.25 was reviewed and an attempt was made to align this with T/31. This was mostly successful and the remaining differences are either (a) because of possible faults in T/31 (b) different requirements of Y/11 (c) different document style. The meeting believed that the differences would not effect acceptance of the ENV. It was not found possible to accept the BSI request for a reference to T/31 due to ITAEGS restrictions. After careful study it was not found possible to meet the BSI request for the requirements on X.25 to be minimal. The meeting felt that in the interests of alignment with T/31 and the desire to incorporate popular facilities a small number of non essential facilities should be demanded.
6. Some development of the text in the Annex on interworking was under taken as it was felt that the consequences of conformance should be carefully defined.
7. In a straw poll it was determined that there appeared to be no obstacles to the ENV receiving a positive vote. In addition CEPT felt that there would be no need for a CEPT cover sheet.
I would be grateful if you could wind in something like the above comments which I hope were your appraisal of the meeting.
Thank you for your help.
Yours sincerely
Paul Bryant.
It is proposed to relocate the UK-CERN EARN link to Montpelier as this will reduce the PTT tariff from 29454 UKL to 19625 UKL pounds per year. The change should take place about mid 1987.
UK-CERN 7960 UKL CERN-UK 25530 SF ~ 21499 UKL Total 29454 UKL UK-Montpelier 6224 UKL Montpelier-UK 126000 FF ~ 13401 UKL Total 19625 UKL
There will therefore be a saving of approximately 8K UKL in the first year and approximately 9.8K UKL in subsequent years
There will be a UK 750 UKL installation charge and probably a similar French charge.
All costs are ex VAT.
The UK-Montpelier line has a 13 week delivery from order.
In 1988 the EARN funding model envisages the UK paying the complete cost of the link to CERN (or Montpelier).
There is considerable benefit in reducing to a minimum the cost of the connection as this will make central funding more likely. Central funding has the advantage that finance will not have to be raised from the users or the members. If finance is required from the users Rutherford will have to organize recovery, accounting, and policing mechanisms which will be expensive and beyond the current effort available. The cost of recovery would no doubt have to be reflected to the users which would a regrettable change.
The current data volume is about 800 Mbytes/month and is likely to rise. A graph of the traffic growth is appended. About half of the traffic is between the UK and CERN. There is expected to be some movement of traffic to the CERN X.25 route. The main growth will be to other than CERN.
A connection to Montpelier has the benefit that the principle line to the USA is expected to be via a satellite link from there.
Assuming that the line move takes place before the end of 1987 then CERN would have to transfer finance to Montpelier for the remainder of 1987. After that date the complete cost of the line would be met by the UK.
The CERN modem would be moved to Montpelier or a Modem would be moved from Rutherford.
There may be some further minor financial arrangements for items such as the maintenance of modems maintenance of modems.
The above proposal is being submitted to:
A decision will hopefully be taken by the end of April.
The CEN/CENELEC Y/11 Y/12 functional standard deals with the CCITT X.3, X.28, and X.29 Recommendations.
These Recommendations define how a keyboard terminal (start-stop mode DTE) access a host (packet mode DTE) over an X.25 network. The start-stop mode DTEs are connected to a packet assembler disassembler which controls the terminal. The PAD is connected to the packet mode DTE via the X.25 network.
The operation of a start-stop mode DTE is controlled by 22 parameters which define, for example, how 'break in' works, how local editing works, and when characters are forwarded to the packet mode DTE.
X.3 defines the 22 parameters and their various values.
X.29 defines commands which may be sent from the packet mode DTE to the PAD and the responses to them. These commands may be used for examining the parameters and setting them as well as for indicating an interrupt.
X.28 defines the interface between the PAD and start-stop DTE. This includes the user interface which defines how a call is set up and how a user may change parameter values.
The recommendations are not very well thought out and have led to a number of irritating rather than disastrous problems. For example, a break in may not work or may permanently turn off echoing, double or no line feeds are common. Fortunately the knowledgeable user can usually manipulate the parameters to obtain a satisfactory connection.
The implementations of the Recommendations have often been poor. Suppliers have had no guidance and have often used considerable imagination.
A basic problem has been that several of the parameters are optional and some of the parameter values. Thus a PAD which only provides the essential parameters may well be unable to interwork effectively with a packet mode DTE which demands their use.
A secondary problem has been that there are no recommendations as to how the parameters should be used.
Y/11 Y/12 attempts to make the best use of the Recommendations. Thus a number of sets of parameter values have been defined which are designed to cover most common uses. These are called sub-options. In fact there are five such sub-options:
There are also two other sub-options are defined which correspond to the CCITT defined sets. These are included for interworking with existing equipment.
A PAD is recommended to implement all the parameters and all the parameter values. This is 'full' conformance. Such PADs will be capable of interworking with any reasonable packet mode DTE. 'Basic' conformance only demands that sufficient parameters and parameter values are implement to interwork with packet mode DTEs which operate in one of the defined modes.
This is relevant for implementations aligning with the 1984 implementations. The 1980 full implementation is different in that it only requires sufficient parameters and their values to interwork with packet mode DTEs in all modes. Basic conformance only demands the essential parameters and mandatory parameter values which will only guarantee interworking with packet mode DTEs capable of using the two CCITT parameter sets. Basic conformance has been introduced to allow existing PADs which align with the 1980 recommendations to be conformant.
The parameters fall into two main groups. Those which the packet mode DTE should look after and those it should not. For example, how break in is dealt with is a problem for the packet mode DTE whilst local flow control is a problem between the PAD and start-stop mode DTE. Some parameters change there dependence from sub-option to sub-option.
There are problems in dynamically moving between sub-options and therefore rules are laid down. The philosophy is that the five sub-options are essentially independent and when re-entering some sub-option the parameter settings should be as they where when it was left. Thus if echo was on when the mode was left it will be set on when returned to regardless of what happened in between times.
Rules are also defined for what happens at call set up. The PAD will adopt the CCITT simple profile on the assumption that this provides the best possibility of interworking with any packet mode DTE. The packet mode DTE will then force the PAD into the sub-option required.
It is recognized that many PADs and packet mode DTEs will not be conformant. Thus care has been taken to ensure that conformance will not prejudice interworking with such equipment. In fact, the annex gives some advice on such interworking. An important advice is that when all else fails, leave it up to the user to try and sort things out rather than closing the call. This is recommended on the basis that any communication is better than none. In addition, a little human heuristics is known to be most effective.
The functional standard demands the implementation of X.28 user interface. This interface is not well liked. On the other hand it is the only standard in this area. Several suppliers have attempted to redefine this interface but their efforts have been confusing and largely not very successful. The functional standard does allow the interface to be extended to provide some useful additions. Thus help systems and useful explanatory text on errors are allowed.
The functional standard attempts to make the best of the CCITT recommendations. This is in contrast to many of the other functional standards which provide some basic level of interworking. The interactive CCITT recommendations are somewhat different in that its usefulness is much more dependent on the quality of the service.
Present: P Bryant RAL (Word Smith) W Black Oxford/NPNCG L Clyne JNT R Cooper JNT A Dransfield LNT J Powers ULCC A Dand SWURCC (PM only) P Linington UKC (Chair) Apologies: D Gray Salford D Jackson ULCC B Gilmore ERCC
Integration of the German EARN into DFN. Transition to OSI standards - management summary. Transition to OSI standards - section three - the higher layers.
No corrections.
List of papers still to be circulated for 87. RC EARN DFN paper circulated by WB. Experiments with XXX continue. MG/RC The latest version of Y/11 Y/12 (V9) will be circulated. PB 8 sites have been asked for further statistics by 10 April. These are RL, Cambridge, SWURCC, UMRCC, Keyworth, Bristol, Exeter, and Salford.LC X.400 action on JC dropped as the subject will be raised again. ORN-4 is still expected. Some additional text has been received. AD ORN-5 is still expected. SK/JC ORN-3 is still expected. LC File transfer text still expected. AD/PL RC has produced paragraphs for Management summary. BG is having difficulty in counting failed calls. Continues. BG WG is still collecting VAX statistics. WB WB has reminded the NRS Steering Committee about NSAPs. PL has revised the XXX text supplied by PB. LC has revised the transport text. PB and WB noted that the VAX computers under VMS 4.1 have been running X.25, X,3, X.29 but not X.28 since September. So far indications are that there are no interworking problems. It was thought that the York Boxes would be most likely to cause trouble and this would be investigated. Indications are that SSMP will have no problems in using equipment conforming to Y/11 and Y/12.
It was noted that SSMP will in principle operate over a variety of terminal services and not only X.29.
Redrafts were agreed.
Binary transfers again received attention.
Such transfers are to be expected between heterogeneous systems.
If manufacturers have special binary forms and document types then their incorporation into converters will be considered.
There was a long but inconclusive discussion on user interfaces. So far there is little indication of the form these will take. This is an area where there may be some advantage in influencing manufacturers to adopt some common interface.
There is no point in implementing restarts as they are never signalled from the transport service.
Red Book over FTAM came in for an airing. The worry is that as JTP will be a long time coming it will cause JTMP to continue for a long time together with Blue Book. It was agreed that it would not be ruled out at this time and would be reconsidered in the light of developments.
The issue was whether X.400 (84) would be used or whether to wait for X.400 (88). It appears (contrary to some pundits) that the two are not compatible and would lead to a migration exercise. This could delay the whole migration process. There was a wide divergence of views and no consensus. The group seemed none to clear on the technical details of the subject.
It was agreed to keep the current text with some warnings. Certainly X.400 (88) would be the target.
The diagram has reached the stage where it attracts constant comment! But- the diagram will be redrawn in minor ways.
Discussion was on the automatic updating of local NRS tables. It was important that they be updated in a timely fashion.
15 April 10.30 at Elizabeth House. 13 May 10.30 at Elizabeth House.
EARN has now agreed a provisional migration plan. A full proposal in the form of a discussion document will be circulated RARE Valencia meeting. The outline of the proposal is:
Initially only a few international sites will be connected. And this should start towards the end of 1987.
EARN intends to carry on using leased lines for the time being. Negotiations are starting with CEPT. This is because the PTTs cannot offer X.25 (1984) or international PVCs which are needed to run NJE over X.25.
In order to run NJE over X.25 VTAM must be offered. Since Rutherford will have VTAM soon this should not be a problem. The existing gateways to JANET should still operate although RSCS release 2 will be needed.
A switch has not yet been selected but the Telefile switch is high on the list. Perhaps two switches will be needed at two major sites (Darmstadt and Montpellier) - but see below.
A study has been carried out on the cost of traffic and current topology. Also note that Germany is intending to put a volume charge on traffic.
As a result of the study it is suggested that EARN could operate a lot more cheaply if there were some reconfiguration. This includes connecting the Nordic countries and Montpellier to the UK as well as Ireland.
The implication on the UK is that more traffic will be carried. The equipment donated by IBM is sufficient for the change.
If the UK does become a major centre of EARN then it may be appropriate to have an EARN switch at Rutherford. Rutherford should consider whether they would wish to take this position. Since Rutherford has more expertise on X.25 than any other EARN site they could take a major part in the EARN migration and could operate the management centre.
As yet, it is unclear how EARN intends to finance the network after migration.
Rutherford will have to seek an extension to the licence. Since it is next to impossible to mount ISO protocols to provide a service equivalent to the current EARN ones the licence should not be refused (according to the licence).
Finance for 1988 was discussed and a paper is now available. A number of models are proposed ranging from UK paying just for the CERN leased line (32K pounds) to adding all cots and allocating according to GNP which lands the UK with 126K pounds! A document laying out the facts and options is now available for discussion.
The funding document will be put to the UK EARN membership meeting.
The gateway has provided a stable and, we like to think, useful service to the community. Certainly if the traffic figures are a guide the service is proving very popular. In February the traffic exceeded 1000 Mbytes.
Some statistics are now collected and a number of analysis of use will be at the meeting.
The main development has been the increase in the traffic levels. These have shown a sustained increase although they could double before there would be capacity problems. The performance figures are appended.
There have been no large changes to the gateway. A number of bug fixes and minor improvements have been made to the mail gateway and none at all to the file transfer system.
User support is now provided by Philip Overy who has recently been recruited. He spends a large proportion of his time on EARN. Rutherford is currently attempting to recruit a second network support expert who will also spend time on EARN user problems. IBM is generously donating two man years of support over a two year period which will be provided by these two staff. We hope and believe that the improved support is a great help to those who are having difficulties.
A report on support is appended.
There are a number of improvements to the mail gateway which are reaching fruition.
The developments include:
EARN has continues to grow and now contains about 500 nodes. The whole of EARN and BITNET is over 1700 machines. About 40% of the machines are from DEC, 50% from IBM (or clones) and the rest from a variety of manufacturers. There are 50 gateways from EARN and BITNET to other networks which are known and many which are not known about usually because they are not of general interest.
The expected 56K link between Montpellier and City University New York will be operational in two months. The Pisa to City University link will probably be dropped when the Montpellier link is established.
An ARPA link has been established to Pisa. A copy of the Wisconsin gateway software is running at Pisa and a service to EARN users will be established as soon as tests are complete.
A study of the EARN traffic and the cost of lines has revealed that a 10% saving could be made by a reconfiguration of the the network. The tariffs in Germany and Switzerland are high while those of the UK and some other countries are low. It is very likely that the UK link will be re-routed to Montpellier giving a one third reduction in the cost of this link. For similar reasons there is a less firm proposal that the Nordic countries should connect to the UK. There are several other proposals which do not effect the UK.
EARN has now produced a draft proposal for migration to use ISO protocols. This document is available on request. A summary paper, which was presented at the RARE Valencia meeting, is appended.
The draft contains the following proposals:
The migration will start towards the end of this year but its termination is unclear as this depends on the emergence of products from manufacturers.
Every effort will be taken to preserve the quality of the EARN service.
IBM support ceases at the end of 1987. The EARN Executive has now produced a funding document for discussion. This is appended.
The UK has to decide on how it is to raise funds and this is the subject of a separate paper.
The request for membership from South Africa was rejected.
A request from the Ivory Coast has been accepted.
Interest has been expressed from Hungary and Yugoslavia. Indications from the EARN Executive are that applications would be accepted subject to such connections not damaging the interests of current members.
At the EARN Board of Directors meeting in Berlin (October 1986) Dennis Jennings of Trinity College Dublin was elected the EARN president as David Lord's (CERN) term of office had come to an end. Dennis had just returned from a year in the USA setting up the network for the academic super computers for the National Science Foundation.
Michael Hebgen (Heidelberg) became the new secretary.
Stephano Trumpy (Pisa) is in charge of CEPT liaison.
Jean-Claude Ipollito remains as treasurer and Birgitta Carlson as Membership.
I retain my appointment as Technical Director.
There will be a further Board meeting in Nice 21/22 May. The two principle topics will be to agree the financial arrangements for 1988 and to consider the proposal for migration. I will give a summary of this meeting at the UK meeting.
There has been an EARN executive meeting in Brussels followed by two in Paris. The principle topics have been finance, the EARN office, and migration.
Some time ago IBM offered to finance an EARN office and an attempt is now being made to recruit a suitable manager and secretary. Although suitable staff have been found there are still some difficulties with the financial arrangements which will hopefully soon be solved.
This was held in Crete by kind invitation of the University in Heiraklion. Again migration was high on the list of topics and major technical progress was made.
There was a report on the EARN X.400 project which is reaching maturity. Current studies suggest that it will be a useful tool in the EARN migration and some extensive developments are being made to it.
Other discussions ranged over a wide area.
There were some 30 participants.
The costs of EARN for 1988 (calendar) are divided into two groups - unavoidable and avoidable.
Unavoidable costs.
Line to CERN or 30,000
Line to Montpellier 20,000
Contribution to US line, probably zero 0
Contribution to EARN management, probably zero 0
1/2 man year for maintenance of software (A Burraston) 12,500
1/2 man year user support (financed by IBM until mid 89)
(P Overy) 0
1/2 man year organizing user meetings documentation etc.
(financed by IBM until mid 89) (P Overy) 0
Note- P Overy is not spending 100% of his time on EARN but
RAL is expecting to recruit an additional member of
staff and the support of EARN will be divided between them.
1 man month- EARN BOD- UK meetings- publicity etc.
(P Bryant) 4,000
Equipment maintenance (3725 and modem) 2,500
1 man week operations. Token amount as operation effort is
very small. 500
Avoidable costs
4 man months for support of EARN executive. This includes
work as EARN technical director and work on the migration
studies. 16,000
Note that all the above costs are rough estimates.
For costing reasons the UK has an opportunity to become a major European node with the possible connection of the Nordic sites to the UK. This will involve marginal extra costs which will not be recoverable.
If, as is planned, EARN migrates to use X.25 at about the turn of 1987/88 then the above costings will be inaccurate. If the UK is not a central EARN site then costs will not be substantially different since the hardware exists already and the software (VTAM) is being provided for other purposes. The main difference will be some retraining of A Burraston and of operations staff. These costs are small and difficult to quantify.
If the UK is a major site, that is with an EARN X.25 switch, then the switch will have to be managed (like any other JANET switch is). This will incur marginal costs as Rutherford is already getting a campus switch of a similar type (Telefile - I hope). Since the EARN network will be relatively small at no more than 20 connections) about a man month seems a best estimate.
As the UK has considerable expertise in X.25 it would seem sensible if Rutherford bid for the EARN network control centre. Again this could be run on marginal costs and would absorb an estimated man year.
As yet it is unclear where the cost of the switches or the man power is to come from although I shall be putting forward some preliminary proposal in the migration document.
I am opposed to putting large resources into the current EARN software on the grounds that it has a short like expectancy and it may not even be possible to put into place accounting and control mechanisms before new software for migration is introduced. In fact, as soon as the current gateway improvements are made it is my intention to freeze development.
I am keen that Rutherford takes a leading part in the migration of EARN as we have a lot of experience of X.25 and have access to rich human resources such as transition group. I firmly believe that we have already (that is me) prevented a pure SNA network which was advocated by the Germans. EARN in Italy is showing only modest interest in migration and have contributed little. France has taken no interest. Thus the main thrust is from the UK and I hope to maintain this.
Like you, by private view is that EARN should develop into a European X.25 backbone.
It is not appropriate to attempt to get RARE to control EARN. The reasons are that EARN is suspicions of RARE and would bitterly oppose any attempt to reduce the EARN service in the pursuit of a religious ISO thrust from RARE. Remarks by the James, Nick Newman, Keith Bartlett, and Horst Hunka (my gripe in that he censored my article on EARN) have led the EARN board to believe that they have little interest in the provision of a service now. Until such time as there is full confidence between the two organizations they should live side by side.
I am opposed to controlling EARN traffic like one controls ARPA and UUCP traffic just because they happen to have certain modes of operation. Volume related charges are inappropriate as we have to recover fixed charges. If we have a volume charge there is no guarantee that we could recover the costs and we may make a large profit. Taken on this basis you should put a volume charge on JANET.
I hope these notes will help to determine a policy.
Some comments on section 3.3 of the HEP report.
3.3.2 Upgrade of CERN and DESY links to 64K. I see no justification for the upgrade of these links which will cost quite a bit. However, it is their money!
3.3.3 ECFA subgroup on links and networks, which I go to on rare occasions, has been very useful. However, this has been driven very actively by James Hutton. I have doubts as to whether it will survive in an active state without him. I see no 'active' successor. We shall see.
3.3.5 Setting up a UK DECNET has certain attractions. I assume this is across JANET. If not I am dead against it as this will fragment the community and give me reason to drive EARN into parts of the UK other networks do not reach! As an ISO supporter I am against the idea as it may divert resources from ISO developments. On the other hand ISO looks to be a long time coming. Certainly DECNET will still have a fragmenting effect even though it would use the same lines as JANET. Since EARN intends to allow DECNET over its international links there is considerable benefit in DECNET in the UK since the HEP community would be able to set up some Europe wide DECNET empire. Pragmatists says let them do it. Moves to ISO dictates they should not.
I do not understand what the £200K to upgrade links to HEP UK sites is. Is this lines, hardware, or software? Is it wide or local area? If wide area, why are they paying rather than JANET. There appears to be no justification for this item.
3.3.6 Documentation etc.
After having attended some meetings on user support I have concluded that only fairly extensive funding will aid the 'help' and 'documentation' issues. Just providing a JANET help machine and letting matters take their course is insufficient. I do not think that SERC alone can solve this problem. There is also the on going task of keeping information up to date. I gather from the IUCC network support meeting that gateway support is the most pressing problem - particularly of those in the USA.
I fail to understand the comment on 'optimal network parameters'. It is already studied from time to time by the network experts. What extra effort and by who is being proposed?
Checkpoint/restart options are outside our control and for Blue Book not worth doing considering the difficulty of the task and the expected life time of the products. Where FTAM is concerned it is an important aspect and must get into the CEN/CENELEC functional standard so that manufacturers can be pressured into providing the feature. I fully agree that it is needed.
The EARN gateway has not developed as I had hoped. (Even though it appears to be better than many other I could mention).
Philip Overy is giving considerable help and I hope that the exercise to recruit further support staff will strengthen Paul's team.
I hope these comments are of help.
Present: I F Brackenbury IBM
P Bryant RAL
A Burraston RAL
P Overy RAL
B Robinson IBM
C Setford IBM
Apologies: R Cooper JNT
B L Marks has now moved to another area of IBM.
All matters are progressed below.
Philip Overy is now using a large percentage of his time on EARN user support. Most problems are with mail and concern traversing gateways outside of the UK. In particular the gateways in the USA are numerous and documentation is sparse. The gateway of greatest concern is the Wisconsin ARPA gateway but the introduction of the gateway at Pisa may alleviate the problems.
A further support staff member is hopefully being recruited and will spend half of his time on EARN matters.
Publicity has been a continuing problem as there is no sure way to reach the users or potential users. Such publicity as there is come from documents sent to the members, articles in various publications such as Network News, and talks at meetings and conferences.
P Bryant will find out whether invoices have been raised to IBM for the support being provided. Action: P Bryant
Raw figures have been collected for all of 1987. Some samples have been analyzed but not to the extent of providing anything useful. The analysis programs are now almost complete. The figures are needed for the next UK membership meeting and for the purpose of funding.
P Bryant outlined the current moves.
The JANET national user group were continually considering gateways. As a result there was now a suggestion that all the gateways from JANET should be controlled and funded by the JANET executive. So far no firm proposals have been produced by JANET but some preliminary discussions have taken place. There are some suggestions that JANET may wish to put authorization and accounting on the gateway and to recover the costs from the users. The user view is that they would prefer EARN to be funded by a block grant.
In any case, any proposals will have to be put to the membership who will have the last say in what happens. It is vital that some proposals be put to the membership meeting.
P Bryant is to attempt to extend the EARN license beyond 1987. (Note- it now transpires that the license expires in mid 1989 so no action is yet required).
EARN has now reached provisional agreement of the strategy for migration to ISO protocols as a result of the EARNTECH meeting in Crete. An X.25 (1984) infrastructure will be set up connecting the EARN international nodes. Initially and for an interim period NJE protocols will operate over this infrastructure in order to preserve current services. ISO services will be built up alongside NJE. Migration within a country is at the discretion of the local EARN management in conjunction with any other national network activities.
A full proposal is expected to be put to the EARN BOD at their nest meeting in Nice.
9 July 1987 at 10am at Rutherford. Rutherford to produce agenda and IBM to minute.
1. Minutes of 7th RCCC meeting held 19 December 1986.
2. Matters arising.
3. Network and communications strategy (RCCC/P28/87, RCCC/P29/87).
4. LAN progress (RCCC/P30/87).
5. Any other business.
6. Date of next meeting.
EARN is determined to migrate to use ISO protocols as soon as possible.
It is vital that during this migration there is no significant loss of service to the users.
Until recently there have not been the products available to start a migration. There are now a number of developments which suggest that the first stages of a migration could now be undertaken. The completion of the process will take several years.
The EARN Board of Directors set up a working party to define the migration path which is just concluding its work. This paper is a summary of their report. The full report is now under discussion.
There are three reasons for EARN wishing to use ISO protocols:
The CCITT X.25 protocol is widely available but only in its 1980 version. The 1984 version is required for the support of ISO protocols. The PTT's planed dates for the 1984 version are not yet clear. Various private switch suppliers now provide it.
The X.400 mail protocol is available in a number of experimental or pilot versions. The use of this protocol is likely to expand rapidly as the PTTs provide services based on it in the near future. >
FTAM (the ISO file transfer protocol) is only now becoming stable and implementations are not expected for some time.
VTP (virtual terminal protocol) and JTP (job transfer protocol) are both unstable and implementations are not expected for a long time.
EARN can be regarded as two parts - the national parts and the international ones.
The migration of EARN within a country must be undertaken in close cooperation with other national activities and will therefore not be directed centrally.
The migration of the international parts will be directed by the EARN Board. All the international EARN nodes are IBM ones. This is the principle subject of this paper.
It is essential that the international and national migrations are carefully coordinated.
The only ISO protocol that can currently be adopted is X.25.
The strategy is to operate the IBM NJE protocol over X.25. This can be achieved using IBM products. The users will not need to be aware of the change since the strategy will not alter the services provides or the interface to the user.
The use of NJE over X.25 demands the use of X.25 permanent virtual circuits. These cannot be provided internationally by the PTTs and therefore EARN will have to provide an interim private X.25 network. This has the secondary advantage that X.25 (1984) can be used which is not currently available from the PTTs and this is needed to support the higher level ISO protocols.
A survey has shown that private switches which provide permanent virtual circuits and X.25 1984 are available.
The number of switches and their location depend on the cost of switches and the cost of lines. An incomplete study suggests that initially there should be two switches- one serving the north of Europe and one the south. There will need to be some relocation of lines but this is expected to be done over a fairly long period of a year.
It is intended to use the X.121 address scheme. This defines the first four digits of an address. Eight digits will remain for use within a country which will be allocated according to national needs although it is suggested that four digits define a site and four for use within a site. A two digit subaddress will not be policed by the network.
Initially only a few sites with good networking expertise will be connected. The rest of the international sites will be migrated at a later date and in some cases when lines are relocated.
A few sites will need additional software which may also cause a slight delay.
The EARN services will be enhanced by the addition of the X.3, X.28, and X.29 services on some sites. This will not be very useful until the national parts of EARN have migrated to X.25 or gateways are provided to other X.25 networks.
The tactics within a country will be the responsibility of the country. Some countries will want to migrate in step with the international parts of EARN. Others will want to wait. Others may want to provide gateways and relays to existing or proposed national networks.
The use of Coloured Book protocols and DECNET will be allowed for an interim period to meet the needs of some specific groups of users. This will allow good connectivity between Ireland, the UK, and some other sites who use Coloured Books. DECNET is popular with the astronomy, space physics and high energy physics communities.
The first higher level ISO protocol to be promoted will be X.400 mail protocol.
Some countries are expected to migrate with the international part of EARN. They will be installing switches for this purpose. These switches may be used to enhance the international parts of EARN and require some change to the EARN topology.
There are a number of X.400 systems now available.
In particular the IBM Heidelberg system will operate on IBM VM systems and so it will be mounted on many of the international nodes. This system has the property that parts of the system can be located remotely over the NJE network thus allowing greater penetration of EARN by X.400 than the extent of the X.25 network would suggest.
Other X.400 systems, such as EAN, are expected to interwork with the Heidelberg one and recent tests are encouraging. These will be of greatest interest within a country.
Some countries are expected to be part of the EARN address space as they migrate. Other will have different schemes and gateways and relays will be provided to maintain a service. Various promising products are in existence or being produced.
The most important relay will be between X.400 and RSCS mail systems. A suitable product is being produced in Germany.
The use of NJE, DECNET, and Coloured Book protocols will be phased out leaving a pure ISO network. At this stage it will be possible to use the public networks.
The removal of these protocols depends on the provision of FTAM (the ISO file transfer protocols) which should be available in a year or two.
Currently there are no suitable versions of FTAM available and no firm indication of dates. EARN will wait for suitable products and promote them as soon as possible.
The fourth stage will require further study. It is unlikely to be concluded before 1989.
The international switches plus a few connections could be provided by the end of 1987. The complete migration of the international part of EARN to X.25 will take to the middle or end of 1988. NJE services must be provided immediately.
X.400 can be provided on some nodes by early in 1988 with all international nodes operating it at the end of 1988.
The use of Coloured Book and DECNET protocols will only be provided where needed. Planning will be on a bilateral basis.
The migration of countries has not yet been studied in detail. There will be gateways and relays to some existing X.25 national networks at the end of 1987. a small number of national networks within the EARN address scheme are expected towards the end of 1988.
Implementations of FTAM are expected in 1988 or 1989.
NJE will be phased out as soon as FTAM is proved to be able to offer a comparable service. Manufacturers plans and timescales are not available.
EARN will follow the emerging functional standards being elaborated by CEN/CENELEC. EARN is also following the activities of RARE. This is important to ensure that EARN can interwork with other academic networks which are all expected to follow the same standards and functional standards.
It must be noted that EARN is a service provider and does not intend to take part in standards activities as a primary activity. In addition, EARN does not intend to develop products but to use those provided by others.
EARN is moving towards the use of ISO protocols as fast as possible. The main delay is caused by the lack of implementations of protocols which is not surprising considering the unstable nature of some of them.
EARN is dedicated and will remain dedicated to providing the best possible service to the European academic and research community.
Present: B Davies R27 F16 CCD (Chair) P Bryant R30 8 CCD CSS (Sec) B Jones R1 2.02 ADMSCI C Reasons R1 1.76 LAS ENG J Sherman R68 1.30 BNS DPR R E Thomas R1 2.78 INF INF Apologies: C Chaloner R25 1.30 AG SPL R Cooper R31 F55 CCD SJN M Hapgood R25 1.37 AG SPL W Turner R1 2.07 ADM T Daniels R27 F12 CCD CSO
C Reasons was present.
R E Thomas noted that in 3.1 he had asked whether CCD were interested in such (servers) provisions. CCD felt that they would be interested in such services if their users required them. As yet no demand was apparent.
M5.5.1 Provide 'NRS site responsibility paper' - retain Action: R Cooper
M5.2.1 The PAD guide had been looked at and did not seem to offer anything. The so called PAD problems had gone away with the advent of the 4705. In the absence of T Daniels the action is retained. Action: T Daniels
M6.4.1 Provision of a TELEX Grey Book service via the Systel code. Action retained. Action: T Daniels
M6.7.1 Discuss mail addresses in printed documents with K Jeffrey. Action moved to B Jones. Action: B Jones
M7.3.1 Provide document on 'new science driven requirements' for networks to T Daniels. J Sherman thought that M Hapgood had started such a document but that its production had been overtaken by the activity to study a SPAN/JANET gateway. It was noted that the paper was expected to address the wide requirements for networking and not specific problems of the day. action retained. Action: M Johnson, M Hapgood
M7.3.2 provide paper on state of implementation of SSMP on various machines. Action retained. Action: R Cooper
The principal comments were on P2.
R E Thomas was a little disappointed that the paper had not developed as he had expected. He felt that there was confusion in several places as to whether the local or wide areas were being considered.
In 'b' (top of page 2) the responsibility for transfers between 'all' machines was questioned. It was felt that transfers between many machines, for example SUN to SUN within ID, was not a CCD responsibility. It was suggested that CCDs network responsibilities should extend to problems of inter village traffic and protocol issues.
Access to JANET and Coordination of naming should be added to the list of CCD responsibilities.
J Sherman wanted guidance in the paper to indicate who and where he should go for advice and services and who would pay. Where should these issues be raised? CCD felt that these matters should be raised with CCD.
Although a topic of the LAN proposal, the village concept was generally welcome. It was emphasised that a village was an assembly of related equipment which was not restricted by division or building boundaries although this may be the case in a number of instances.
The above points will be clarified in the next versions of the papers.
The proposal was welcomed from the technical and strategic points of view.
It was agreed that a proposal for DHC should be prepared setting out the fully costed proposal and covering the benefits and savings to RAL that would result and how the facility would be managed. There were different views about the minimum number of villages that would constitute a critical mass for the project to be viable. P Bryant believed this to be four and would not wish to proceed with the project at all if this level of commitment could not be achieved from the outset. J Sherman felt that one could start with a smaller number and allow villages to join later if they thought it worthwhile. the general view was that in practice it was likely that an initial commitment of four would be obtained
The project will provide services from installation but the full effect would only become apparent as further protocols and protocol implementations were developed to allow archaic network methods to be phased out. These methods would not be removed before adequate alternatives were in place.
It was agreed to redraft the document in the light of the comments and to submit it to DHS.
It was agreed that NDM could discuss Cray networking. This would depend on suitable topics being raised by the participants and participation by relevant experts.
October 7th 14.00 hours.
This document is an outline proposal for the installation of a backbone high speed network on the Rutherford site.
The total cost is estimated to be less than 10,800 pounds per 'village' plus 5000 pounds plus manpower.
At this stage an outline is described to determine whether further work should be undertaken in view of the cost and the support by the Divisions of the project.
The project envisages the installation of an ethernet based on fibre optic technology. Groups of machines or 'villages' will be connected to the backbone by 'bridges'.
The benefits will include:
Computing on the Rutherford site has developed in a distributed fashion with groups of machines being installed on various parts of the site. The Central Computing Division now provides specialist services (Cray) or services of a general lab wide interest (PROFS). They also provide some infrastructure such as networking.
Thus, there are groups of related machines that are termed 'villages', for example, the astronomy VAXes. There is high traffic between the village machines and little traffic between villages. A village is not constrained by geographic or division boundaries. For example, the village associated with the IBM computer would cover the whole site and include users from all divisions.
The conclusions drawn is that a village should have its own local network to which their machines and terminals link. This network should be connected to a backbone which will provide access to other services both on and off site.
The use of 'bridges' between the village networks and the backbone will only allow inter village traffic to be on the backbone thus preventing it from becoming overloaded.
Equipment is now available to introduce such a system at low risk.
Over the last six months an ad hoc study group drawn from all divisions has examined the possibility of such a backbone.
Various manufacturers have outlined how they would envisage introducing such a system.
DEC and BICC Data Networks both outlined a base-band ethernet with bridges to the villages.
ITL advocated a broad-band system.
Broad-band is expensive but has the advantage of being able to carry many services such as television and surveillance. It appears that the site has no need of these services, or at least there is no interest from Photographic section in wanting to contribute in order to take advantage of a site wide television service. Broad-Band has the disadvantage that only 10 M bit can be accommodated so that should a higher speed network be desired at a later date the system would become obsolete.
No manufacturers were found who advocated token ring, token bus, slotted ring or other technology.
The unanimous advice from the ad hoc group was that at this time a 10 M bit ethernet backbone was the best option.
Now that the technical decision is firm an accurate proposal can be formulated and this is underway.
A 'multi port repeater' (hub) will be installed, probably in Central Computing Division. From this hub a fibre optic will go to each village. At the end of each fibre there will be a bridge. A bridge has the useful property of only transmitting packets destined for another network. This will prevent village data from overloading the backbone. It will prevent some malfunctions from affecting the backbone.
The 'star' topology provides a more robust network as malfunctions which are damaging the whole network can be dealt with by isolating that village from the network until repaired.
The type of network and its management within a village is the business of the village. The only requirement is to convince the backbone management that the village network will not damage the backbone or the service it provides.
It would have been possible to have a network going from village to village either in fibre or copper. This was rejected as it would be more difficult to manage and less reliable as vital equipment would be distributed across the site.
Four protocols are of interest:
All four sets can co exist on the network. Although it would be desirable to only use ISO protocols (Pink Book) this is not possible at this time due to lack of software. Also, Pink Book is not able to provide the functionality required by Informatics Division.
The project will only provide the backbone and the bridges.
Initially there will be six villages (subject of confirmation):
Other villages - EBL etc may wish to join later.
The equipment required and its estimated costs are:
Multi port repeater 5000 pounds Bridge, one per village 8000 pound Fibre link, one per village 2000 pounds Ancillary equipment, per village 800 pounds Total for (say) six villages 69800 pounds + VAT
Effort required for installation, which will be include defining the exact topology and organizing cable laying is estimated at 6 man months.
Management of the resultant network will be 6 man months/year but this is a rough estimate and an accurate figure will only be available after some experience.
There will be expenditure within the villages and this will be the responsibility of the village although it may be possible to arrange some bulk purchase agreements. In the case of CCD a lot of equipment already exists, such as the Auscom, and heavy expenditure is not expected. This is true of some other divisions
There already exists test equipment and little further expenditure is expected in this area.
For capital and installation costs it is proposed that:
For operating costs it is proposed that:
As has been mentioned, the project envisages terminals being connected to the village machines or village PADs. This will allow the best possible service to those machines. The users accessing a number of villages or remote facilities will have to decide which village they should connect to for optimum results.
Whether a user is connected to a PAD or directly to a village machine depends on circumstances and costs. The village management will decide such matters.
Gateway(s) will be required between the local and wide area networks. There are a number of ad hoc ways of providing these via various computers. For example, GIFT could provide the DECNET/Blue Book service. This area needs further study and in the case of ISO further products are required. This leads to the conclusion that the current X.25 site network will have to exist for some time.
Certain users normally use remote machines. Initially these users can use current services. Eventually they would use either ether-PADs (a suitable product from Spider exists and will shortly be evaluated) or PADs incorporated into the village machines.
The backbone will not carry 3270 traffic (at least initially) and the coaxial service will have to continue. However the service via async 3270 and IBM PCs will be possible via the backbone as a result of the CCD HEP ethernet ISO project but it is too early to plan a service on this product.
At this stage a decision is required on the basis of this document as to whether the project should be undertaken considering the costs, manpower, and resultant benefits as well as the risks.
A decision to proceed will depend on whether there is sufficient interest and enthusiasm in the villages. It is suggested that at least four villages should commit themselves to the project before it should proceed.
There will be a further break point when a fully costed proposal is available in two months.
Dear Birgitta,
I have received the attached request for connection to EARN. Please could the membership committee rule as to whether they may join EARN and whether they would be a full or associate member.
I have no objections to their proposal.
I guess we shall be meeting in sunny Valencia next.
Best wishes
Paul Bryant.
Dear Mr. Geerd-R. Hoffmann,
Thank you for your recent letter requesting a connection to EARN.
I have now sent your application to our membership committee since you are not an academic institute. I think that in your case this will be a formality as I can see no possible objections to your membership.
I have also requested DTI to extend the EARN licence to allow you to connect. I have asked them for a speedy response.
IBM's funding of the network ceases at the end of this year. I am currently attempting to get agreements for alternative funding. There are a number of models but no firm decisions have yet been made. It is therefore likely that some form of charge will be necessary in 1988. I estimate this charge at around the 1000 UKL per year level.
An alternative access path to EARN is via JANET and, since this does not require any variation of the EARN licence, it could be implemented more quickly. This would require you to use the Coloured Book protocols rather than NJE and to gain access to EARN via the gateway at Rutherford. Access to JANET would of course have additional advantages and I believe that ECMRWF is entitled to connect directly to JANET, although this would need to be clarified with JANET management. All UK users currently access EARN via JANET.
I would add that I am most anxious for you to have access to EARN and will take all necessary steps as quickly as possible to secure a connection.
Regardless of which path you take you will need a suitable connection to Rutherford and I suggest we obtain this as soon as possible. It will be more convenient if you order the line since you will be paying and this will remove the nightmare problems we have with recharging. We are happy for this line to be a 9.6K Kilostream link as Peter Gray suggested. May I ask your network experts to arrange the fine detail of the line with our Roland Brandwood (0235) 21900 who is aware of this project.
I look forward to a rapid and successful conclusion to your connection. Please do not hesitate to contact me if you require any further information or clarification.
I enclose a copy of the rules and regulations concerning the use of EARN and a membership form which I would ask you sign and return to signify that you agree with the EARN Charter. You should also select a name for your machine and this should be of the form UK...... I would suggest UKECMRWF (you are limited to 8 characters).
Yours sincerely
Paul Bryant.
You are invited to the EARN UK Membership Meeting or to send a representative. Please fill in the form below if you intend coming so that the domestic arrangements can be made. Alternatively send a message to Philip Overy - PO2@RL.IB.
This meeting is particularly important since we will be considering the future financing of EARN. Since the last meeting there has been some progress. The papers attached give details.
I look forward to seeing you.
Paul Bryant (UK EARN Director)
1 Minutes of previous meeting (previously distributed)
2 Matters arising
3 Directors report (paper 1)
4 Finance and the future (paper 2 and paper 3)
5 Support (paper 4)
6 Migration (paper 5)
7 The EARN Code of Conduct (paper 6)
The EARN Board has asked that the EARN Code of Conduct should be brought to the attention of Members and Users
8 User problems
An open forum for questions and comments
9 Any other business
10 Date of next meeting.
Attached is the agenda for the EARN UK meeting.
I attach papers 1, 2, 3, and 5.
Please find the EARN graph of performance which Mary can probable find for you. It is up to date. A redraw may be sensible. Please annotate it. The top section is non CERN traffic, the middle section Irish traffic and the bottom section CERN traffic. This should be appended to Paper 1.
Please would you find and add the EARN code of conduct which you will find in NETSERV. This should be provided as paper 6.
Paper 4 is your paper on your support activities. Please let Graham Robinson look at it. Also if you have any other problems see Graham for help.
Please would you organise the distribution. It should go to all the EARN members, people who attended the last meeting or gave apologies, the IBMers (Colin Setford, Robinson, Brackenbury, Marks), to JNT (Bob Cooper), Willy Black, James Hutton, Dennis Jennings (Ireland) and any others I have forgotten.
Please use Mary for any secretarial services you need. The papers should now go out as soon as possible.
Sorry but other pressures prevented me getting this to you earlier.
Paul.