Paul Bryant's Networking Correspondence
For 15 years communications on the Rutherford site and within the United Kingdom has been based on the familiar X.25 based Coloured Book services which have served us well. In the late 70s this gave us several years lead over other countries. So why are we looking at the so called IP communications services?
IP (Internet Protocol) is, like "Coloured Books", shorthand for a whole set of protocols providing a variety of customer services. IP is actually the lowest level of protocol. Over it there are a number of protocols such as TCP (Transmission Control Protocol) which makes sure there is a reliable data path between the two ends. Over TCP runs FTP (File Transfer Protocol), Telnet for interactive use, SMTP (Simple Mail Transfer Protocol), and X WINDOWS for advanced interactive use. NFS (Network File Server), which runs over a different transmission control protocol, provides file access. There are other protocols of less interest.
Although the objectives of Coloured Book and IP protocols are much the same they work rather differently. With X.25 a call or virtual circuit is established end to end and data is sent across this reliable connection. This is known as a "connection network". With IP each packet of data is launched into the network together with its destination and it may or may not arrive. Higher level protocols, such as TCP, sort out the mess and provide a reliable service. This is a "connectionless network". Pundits will argue the benefits and draw backs of each technology but although the way things work is different the arguments are much more to do with the popularity, quality of implementations, high level services, costs, and political issues.
A couple of years ago we put in a high speed local area network. This was very carefully designed and implemented. it has proved very reliable and traffic is growing. We want, over a few years, to get rid of the relatively slow network we have relied on and put as much traffic as we can on our new fast 10Mbs network.
We were expecting to run the current X.25 Coloured Book services over the ethernet and the standards for this had been developed by the JNT. Rutherford, together with ULCC London, and DEC ran a successful project to check that all this worked. However, we decided at an early date that we would allow any sorts of traffic to use the network as long as it did not prejudice reliability and performance.
The results were interesting. It is difficult to measure traffic accurately, since the network consists of a number of sub-networks. However, we believe the biggest use, representing 75% of traffic, has turned out to be DECNET. The reason is that DEC has developed DECNET to utilise ethernets and with the 60 or so VAXes on site the temptation to use its excellent quality between VAXes was overwhelming. The second most popular set of protocols has proved to be IP with 20%. The initial popularity has been caused by the UNIX machines for which IP is the natural choice. Most sites using UNIX worldwide use IP and as a result the implementations have become highly reliable and well matched to UNIX systems. In fact there are services such as NFS and X WINDOWS which are unavailable with other protocols. Since then, IBM PCs, IBM VM/CMS, and VAX VMS systems have been blessed with good IP implementations.
Experience has shown that IP systems are very easy to mount and use in contrast to such systems as SNA and to a lesser extent X.25 and Coloured Books where the systems are rather more complex. A further attraction is that these systems are very widely used and are therefore relatively bug free. In addition, there are often competing products with attractive bells and whistles from which to choose. Even more attractive in these hard times, we find that some products are free. Most people will be aware that the IP protocols were a development from the USA ARPA project and have thus been well supported by the mighty Dollar.
Within the site NFS is popular and the only way file access can be achieved. Also within the site X WINDOWS provides an important service as high quality terminal access from desk top workstations becomes affordable. There is also a demand for X WINDOWS from off site for access to the CRAY. These require an IP network. Although these services are freely available on site only a few pilot connections have been made off site. There are hopes that further connection will be made. Once such a service is available then users may well use other protocols, even where there are adequate Coloured Book ones, for reasons of convenience or functionality. Choice is a nice thing but it may well have a tendency to complicate networking and undermine some of the UK networking policies.
The principle network within the USA for academic traffic is now based on IP. IP has recently become popular within Europe for inter-site traffic and there are moves to try and co-ordinate this activity. With the emergence of such a large combined USA/Europe network there are great attractions for UK users to have good access to it. This can be achieved by gatewaying Coloured Book protocols to IP or by allowing IP to penetrate the UK. Gateways are well known to be a cause of loss of quality and frustration. Allowing IP to penetrate way well upset the networking strategy of the UK. A group has recently been set up to advise the JNT on this problem and they have now reported and recommended some use of IP across the JANET X.25 network.
With any network technology there are many ancillary problems. How do you manage it, directories, how do you link one site to another, how to ensure security, and many other questions. In the Department we have been looking at these questions so that we are well poised to take advantage of any opportunities that arise in this area.
I have now done some further study of the regionalisation paper. At the December meeting you will remember that we discussed the paper at length and came to an understanding based on multiple connections and not exclusively IP. As a result I wrote to Daniele with my view of what the paper should say. I attach my note. You will see that a few changes were made.
In fact an analysis of the December and February papers reveals that the introduction is new. In the subsequent text a few minor changes were made including the removal of three or four Ip references but with the inclusion of a new paragraph "We propose to exploit this available IP connectivity.....".
The revised paper was submitted to the RPG list and attracted very little comment. I wrote to Danele indicating that I found the paper unacceptable as it did not meet the understanding that I thought had been achieved at the December Executive meeting. I did not send it to the list as I did not wish to initiate the type of acrimonious discussion that my previous comments to the list attracted.
I think we agreed that the paper we saw last week was inconsistent and this led to a long discussion on what it actually said and let to us being virtually unable to agree or disagree with its content.
In short it was a poor document which should never have got as far as the Executive.
I would suggest that in future it may be a good idea if papers written by our staff are vetted my our manager to ensure that they are:
Daniele - I have done some work on how I think the first part of the RPG report should look. I have concentrated on the regionalisation aspects and not the IP ones. There are still some areas that need some attention. I hope this is of use. Paul.
The purpose of this report is to address the solution to a number of problems which are effecting the EARN network.
There are currently a number of serious bottlenecks which have arisen as a result of the increasing traffic. However there are also a number of lines and networks that could carry EARN traffic. The use of these resources requires a radical reconsideration of the structure of EARN.
Recent measurements show that some nodes are unavailable for surprisingly long periods. Use of a revised topology should reduce the effects of this unavailability.
Note - are there any other reasons that need including?
Originally EARN consisted exclusively of computers linked by dedicated lines using the NJE/BSC protocols. The lack of lines and the protocols used led to a tree structured network based on Montpellier which had the single connection to the USA.
There are now many more links available which allow the connections of nodes in a mesh. The recent announcement of RSCS 3 allows the better exploitation of a mesh network. These links can be provided by a number of technologies which support NJE. These are IP, SNA, X.25, DECNET, as well as the original BSC. The physical lines can be from a variety of sources such as EASINET, IXI, various private lines and networks. The recent policy decision of the Board of Directors permits the use of any suitable underlying technology subject to the management of change.
An exact catalogue of resources is not yet available.
There are IP, IXI, and/or SNA connections on many international sites. In particular there are IP and SNA connections to the USA.
NJE/IP, NJE/X.25, and/or NJE/SNA exists on many international sites.
Note - do we need some sort of catalogue of resources?
Leaving aside the underlying networks the best solution would be for every site to be connected to every other one. This would avoid all NJE staging and the use of intermediate computers for staging.
Note - is this true?
This is not possible in practice since NJE requires a permanent link to all the other sites which would require large computer and network resources.
Note - is the above the only reason? It is important state exactly why we want a set of core sites. Perhaps we need to have a look at the paper which BITNET produced (did they produce one and have you got it?).
The solution is to restructure the network on a regional basis not necessarily bound to country boundaries. This is based on technical considerations and the country based political structure of EARN will not be effected. The criteria for the division between regions is based on the density of nodes and need of service in the area. Each region would have a 'core' site. A core site is selected under the following criteria:
Note - I do not understand why every international site should not be a "core" site. Why 10 sites? Clearly with all international sites fully interconnected (eventually) performance should be better. So what are the problems. The number of virtual connections would not seem excessive.
The RPG suggests the following set of core sites (* means that the server is not installed at their site but topologically nearby);
The set is not final and is subject to change after a better analysis of traffic. Technical details about the core sites can be found in appendix 1.
Each core site would have an NJE link to most other core site by any appropriate means. Eventually complete interconnection is the aim. Initially a complete interconnection may not be possible and may not be appropriate depending on the physical line topology and bandwidths. This needs careful study to ensure that best use of facilities.
Note - are there any reasons why complete interconnection is not a god idea?
All other nodes in a region would connect to their regional core site. Within a region there may be sub-backbones or other local arrangements which are outside the scope of this paper. However, there may be some backup connections to maintain service should a core site fail. This needs further study to ensure that the network does not become over complex but is as reliable as possible.
There may be a number of special connections where there are heavy traffic requirements or other considerations.
NJE links between pairs of core sites will be created particularly where there is a considerable amount of traffic. However, the available lines and bandwidth will also effect interconnections.
The possible configuration is shown in the interconnection matrix below. The type of connection is indicated. It is difficult to indicate the speed available as in most cases lines are shared.
1 2 3 4 5 6 7 8 9 10
1 SEARN - IP
2 CEARNV2 - IP SNA IXI
3 ICNUCEVM - IP IP IXI
4 TAUNIVM - BSC
5 AEARN - IXI
6 FRORS12 -
7 FRMOPXX - IP IXI
8 DEARN - IXI
9 UKACRL - IXI
10 HEARN -
Note - this table needs some works and I have only put in some connection off the top of my head. Perhaps we should add the line speeds although this may not be appropriate as lines are normally shared.
This list is not complete and is subject to change after examination of the traffic data.
The final objective within Europe will be to implement the BITNET II approach with a full connectivity among the core sites. This will require further network connection within Europe.
Note - we need a reference to the document defining the BITNET II model or it needs defining here.
No change
No change
No change
In "core site guidelines":
Section 2 - The machine must run suitable network software and RSCS version 3 should be adopted as soon as possible.
Section 3 - The system must have the capacity to support the number of NJE connections needed for connectivity to other core sites. This capacity should take into account IP, X.25, SNA, DECNET, and/or BSC connectivity capacity, spool capacity and manpower requirements.
Section 4 - delete "over IP".
Section 7 - delete two occurrences of "IP".
Section 8 - I do not think this is a sensible requirement. I know of no sites with UPS and I doubt if any site would consider buying one for this project. In any case this is more a subject for RIPE to consider. I suggest this section is deleted or replaced with one that talks about attempting maintain a high availability. I cannot remember the last time this site lost power.
This is an update of possible expenditures for the forthcoming financial year. It is not expected that all the purchases will be required and other ones will no doubt arise.
Note: prices are budgetary and ex VAT.
1.1 Spares and upgrades to eventually recharged including_
large hard discs
screens and adapter cards
3000
1.2 Product technical reference manuals
150
1.3 Evaluation Hyper 386SX upgrade board or similar for IBM PS/2 50 to investigate
upgrading them to current specification
300
1.4 High resolution video adapter and large monochrome screen for evaluation and
comparison with equivalent MAC system
1700
1.5 Evaluation copies of new applications especially those for Windows 3. Including
DRDOS5 and DOS 5
1500
1.6 Evaluation model of next 386SX PC recommendation to RAL. This will release
an older machine for loan or sale
1600
1.7 Upgrade of already purchased evaluation software
750
1.8 Evaluation Notebook computer - this will be used for on-site support to test
serial ports, printers etc and download s/w
1500
1.9 Secretarial workstation printer for spare/loan
800
1.10 Cheap 24 pin dot matrix printer for evaluation/spare
250
1.11 Technical books
100
Total 11650
2.1 Possible CHEST site licences which may be recharged to users 5000 2.2 Graphics scanner - Epson XL for evaluation and CD users 1600 2.3 Colour printer - Paintjet XL for evaluation/CCD users service 1050 Total 10650
3.1 Cheap ethernet cards for evaluation and spares 1000 3.2 Ten further PC/TCP PLUS licences for selling on to users 2000 4 Longer term requirements 4.1 With the renewed interest in FDDI there may be a requirements for various pieces of equipment such as monitors and possible computer interfaces 2000 5 VAX (prices include VAT) 5.1 Ethernet device upgrade for RLVE required for DECNET phase V. This is essential when phase V arrives 800 5.2 Memory upgrade for two workstations. The quote is pessimistic as prices are dropping 2200 5.3 CBS licences for two workstations. This is to legalise current testing 700 5.4 1.2 Gb disk upgrade to RLVE. Currently the Cray front end disks are used and this will cause problems when they are required for their legitimate purpose 4700 5.5 Laserwriter Postscript printer for R30. This is for use by Graphics, VAX, PC and Comms group. Cost should be shared. For better graphics an extra 600 may be required 3105 5.6 RLVE is very slow due to the extra strain imposed by the general increase of work by VAX support, Graphics and elsewhere. In fact it is really a general purpose VAX service. An upgrade from the existing 0.9Mip Microvax 2 to a 2.7 Mip Microvax 3 would be beneficial. Alternatively the use of the machine could be limited. 20000 5.7 UNIX courses for RMW (2 system administration courses) 2000 5.8 Sun workstation for RMW (Hopefully use Arcu-2) 0 5.9 Additional DEC X25router to allow site wide use of PSI-access to use the ethernet to connect to JANET. A separate paper to NTMPC/TMPC will be produced. This will remove the need to upgrade the X.25 interfaces on VAXes with Phase 5 and should therefore be funded by all VAX users. 13000 5.10 Infoserver-100. Standalone Ethernet system that allows any number of VAXes on site to access local CD-ROMS with VMS documentation and media. This will cut the maintenance costs. A paper for TMPC will be produced. 6800 Total 51305
I have had a brief look at the new accounts and have a few points that I will raise at the Executive meeting.
I was a little disappointed to see that the 1992 budget did not include a statement of the reserves expected at the start of 1992. I believe that we can now do the calculated. The reserves at the end of 1990 taking account of committed expenditure and unpaid contributions are:-
SICAV at December 1990 value 5257190 FF Barclays Paris 34494 Barclays London 436138 Unpaid contributions 1397406 less committed expenditure 1043617 - Total 6081611 =868802 ECU (7FF=1ECU)
As the 1991 budget balances then this figure should be the reserves at the start of 1992.
This is a pessimistic figure since I expect on historic considerations an underspend and indications are that this will take place. With the abandonment of the EARN X.25 infrastructure and the withdrawal of DEC support I have difficulty believing that EARN will put significant resources into development this year or in the future. I am sure that this will be confirmed when we receive the quarterly financial statement now due. The interest shown for 1991 is 40000 and at the current interest rate of 9% in France our capital should yield 78000 or at the poor 6% that SICAV yield 52000.
I will be proposing that unless there are believable plans for believing that there will be increases in expenditure that as planned we should aim for a 700000 reserve and return 168802 ECU to the countries in terms of reduced contributions.
I would now like to turn to the accounts documents.
On the document "BILAN AU 31 DECEMBER 1990" (which I am disappointed to see is still in French) I can only detect two changes both on page 1 of COMPTE ANNUELS. The DEC contribution is now shown as 461551.00 rather than 427023.73 and the development X.25 is 601339.64 as opposed to 676045.25. Are these the only changes? What is the reason for the decrease in the X.25 expenditure? Presumably this is actual money spent on the backbone and so must represent some unexpected commitment that was not known about when the accounts were produced.
The DEC figure is a calculated one (see Financial report) and I am unhappy that it is shown this way. We should see the exact contribution from DEC in 1990 of 1058025 with expenditures of 601551 refund to DEC and 140000 payment to INET. I have difficulty accepting the given value as there is no way that this can be verified from the bank statements of EARN. This method of accounting is confusing and hides what is going on and I suspect that it is an illegal accounting practice.
On the same page the "AUTRES PDTS BACKBONE" (backbone compensation) is shown. Why isn't the contribution from SWITCH also shown as this amounted to 81122 FF. Was it that this money never passed through the EARN bank account? If it were shown there should be a corresponding expenditure presumably under DEVELOPMENT X.25 BACKBONE.
I now turn to the Financial Report.
On page 4 we see that the item "Miscellaneous income" of 149430 has been deleted. What was this and why has it been deleted? I can find no text to explain it. I suspect it may be something to do with the DEC loss in 1989 which has been carried forward. However this is shown on page 9 as 145028 which is different.
On page 5 there is still an arithmetic error. The 6735827 should be 6735825. This error perpetuates. Although the error is small it does give me cause for concern as with the error the books could not have been made to balance which makes me wonder just how thorough the accounting job was done.
On page 6 we see "Accounts payable" of 1960522. In the previous accounts this was 17752246 - a difference of 185376 - why has this changed? In the previous accounts we were referred to Annex 3 which was "Accounts payable" but this gave no clue as to how the 17752246 was arrived at. In the new accounts on page 13 we have "DETAILED ACCRUALS" which I assume are also "Accounts payable" but in this case the amount shown is 1043617. However the tables are in a radically different form and although about half the entries compare other ones differ. For example we see a payment of 60636 to Austria (what for?) which has vanished and the EXEC meeting costs have gone up.
On page 7 I have a major concern which I have mentioned before. The DEC contribution is shown as 462000. I believe that this should be the REAL DEC contribution of 1058024 put balancing expenditures. In principle ALL money that passes through the EARN organisation should be shown.
Also on page 7 note the decrease in the X.25 costs from 676000 to 601000.
On page 8 the Cash grant allowed is shown as 1960000 and yet the addition of the two contributions is shown as 1948024. I would have ether shown the grant as 1948024, or shown a currency loss. As it is it is confusing.
I do not understand how the SWITCH contribution is taken account of. This should be made clear in the calculations.
On page 9 we again see the value of 1960000 being used and we have in fact thrown money away (6000 FF) by using this mythical value instead of the real one.
At the bottom of the page we see the term "Difference loss previous year" which is confusing. I would prefer the term "carried forward from previous year". There is no "loss".
I have already touched on page 13 which should ether be in the earlier part of the document where the 6 character account codes are used or it should be in terms of the EARN codes so that there is a direct comparison with the BUDGETING CONTROL on the next page.
These accounts are an improvement on the previous set but I am still far from happy that they give a clear picture of the EARN financial position.
Paul.
Currency conversions and other calculation errors have caused the contributions received from countries to vary from that expected. "Small" variations have been ignored but it is unclear what errors should be allowed and the procedures for dealing with over and underpayment are undefined.
This proposal seeks to lay down accountancy rules for the country contributions for year 1991 onwards.
The country contribution will be converted to French Francs immediately after the Board of Directors meeting which determines the contribution level at the then ruling conversion rate (not the EARN conversion rate).
Invoices will be issued in French Francs. The invoice will note the contribution in ECUs and the conversion rate.
After the payments have been received and converted to French Francs via the banking system the received and expected contributions will be compared. Any receipts which differ by more than 2% after the final country payment from the expected contribution in French Francs will cause an invoice to be issued for the balance or a refund. Any receipts differ by less than 2% will cause the difference to be added or subtracted from the subsequent years invoice. Any reminder re-issues of invoices will be identical to the original ones and not take account of any over or under payments in previous part payments.
Use of such a mechanism will make the operation of the accounts via a computer program easier since it will be unnecessary to take account of any currency losses and accounting can be accurate. The use of the French Franc as the basic accountancy unit will be in line with the accounting practices now in use.
The document "COMPTES ANNUELS AU 31.12.1990" (BOD16 91) is the official accounts required by the French authorities. It is difficult to understand. I would not advise it be studied.
The document "FINANCIAL REPORT JANUARY1, 1990 - DECEMBER 31, 1990" (also in BOD16 91) present the same figures in a more understandable form. This document is also fairly difficult to understand.
In this report I will give an analysis of the figures.
ANNEX 4 on page 15/16 of the "FINANCIAL REPORT" shows the expenditure against the budget figures. These figures do now show a good picture of the financial activities for two reasons:-
The figures below have had the COSINE figures removed and also take account of the repayments to DEC in the interests of simplicity. The comparative 1988/9 figures are shown and have also been simplified.
budget KECU actual KECU
1990 1990 1989 1988
Expenditure 898 627 428 303
Income (countries) 840 834 599 142
Donations (IBM,DEC,NT) 160 59 30 126
Interest 29 (1) (1) (1)
Backbone compensation 34 33 - -
Surplus on year 165 299 201 35
(1) The EARN reserves are held as bonds and the interest is only realised on their sale. Thus the actual surplus is pessimistic and the real surplus can only be calculated by a valuation of the bonds and other assets and liabilities at the end of the year.
EARN reserves as of December 31 1990 taking account of bonds, bank accounts, debits and liabilities but excluding non-financial assets are 731 KECU.
The figures are translated from French Francs and so should be regarded as approximate.
The reduction in the DEC income is because of the cancellation of the X.25 backbone. Half of the saving was returned to DEC and the rest was divided between INET 91 (20 KECU) and EARN (59 KECU).
The income from countries is slightly optimistic as the Ivory coast contributions are not expected. 5% of the 1990 contributions are still outstanding and include:
Czechoslovakia 1164 Egypt 2245 France 58654 Germany 33051 Hungary 456 India 2351 Italy 54202 Ivory Coast 2788 Portugal 773
Prompt payment would be appreciated.
The budget and actual expenditure are on pages 15/16.
There has been an under expenditure on staff which is due to late recruitment.
There have been few "other meetings" and in any case members of such meetings have often paid their own expenses. In future EARN expects groups to provide budgets for their work which may increase expenditure.
The expenditure on the Dublin office is because after the examination of the expenses of the Dublin Office by the University auditors further expenditure was discovered. This was dealt with at a previous Board of Directors meeting.
The development expenditure is low due to the closure of the X.25 backbone. The other development costs are for non X.25 purposes and apart from ASTRA there have been few demands. There were outline plans for further staff to be employed on development but in the event no justification was forthcoming. However, the possibility of development expenditure has been retained in the 1991 and 1992 budgets.
The 1992 budget and forward look are based on EARN continuing with its current policies. Decisions taken as a result of the EARN Strategy paper commissioned by the Board may result in a revision.
The expenditures in 1990 have been less than expected. This follows the pattern of previous years. Your Executive is therefore recommending that the 1992 budget be based on the actual expenditures of 1990 inflated by 10% rather than the budgeted expenditures. This results in a reduced budget in which income and expenditure are likely to balance.
As a result of the underspending in 1990 and previous years, the planned 700 KECU contingency fund has been exceeded a year ahead of target. As a result your Executive is recommending that 31 KECU over and above the 700 KECU contingency is returned to countries by way of reduced contributions in 1992.
The forward look is based on the 1992 budget inflating at 5% per year. There is provision in 1993 for a possible additional Trans-Atlantic line.
Your Executive now produces quarterly financial statements. Previously statement had been as up-to-date as possible. The new procedure allows easy comparison between quarters and between years, it also removes the work needed to update the accounts at the last possible moment before a BOD meeting. The statement for the first quarter of 1991 is in BOD 17 91.
This statement shows an expenditure of 107 KECU, a commitment of 158 KECU against a budget of 972 KECU (excluding COSINE cooperation). On a historic basis expenditures tend to accumulate towards the end of the year. It should be noted that currently there are no definitive plans for spending the 90 KECU on "additional staff", such plans are currently being developed by your Executive. There has been little demand to spend the 70 KECU "other development expenses". Expenditure on "other meetings" budgeted at 33 KECU is zero in the first quarter. In the second quarter there has been significant expenditure under this heading.
The 1991 budget is based on the 1990 budget rather than on actual expenditure. On a historic basis a surplus can be expected and the first quarters financial return tends to support this expectation.
Income from contributions is budgeted at 788 KECU and is 236 KECU. This is above expenditure but is disappointingly low.
Minute 5.4 on the LAN Management Committee of 15 February 1991 actions me to prepare a statement on the Cons/Cons gateway.
The Cons/Cons gateway (currently realised by the so called Spider Gateway which is really a Yellow Book Cons gateway) provides a gateway between Pink Book and X.25 Coloured Book services. A true Cons/Cons gateway will no doubt be developed and will be a simpler system.
Pink Book services exist on most machines but their use is small. However, a number of PC and Unix machines use the service. The principle use of the Pink Book protocols is to access remote services via the Spider Gateway. Within the site IP and DECNET services are more popular. It is our policy to allow all these sets of protocols on the local area network although the level of support may differ.
An integral part of the Spider Gateway is the Campus Name Server which is required since the Spider Gateway has insufficient memory to retain the complete NRS. As an aside, the CAMTEC PAD has the same problem which is overcome by including a set of useful names in the PAD and allowing calls to be made knowing only the DTE number. It is understood that there are outline plans for allowing the CAMTEC PADs to use the Campus name Server which could save a lot of human effort but may require some investment.
The Campus name server is an IBM RT UNIX machine. The updating of the NRS table from the Manchester central database has been made automatic. the table update for the local machines obviously will still require a small amount of manual effort. From time to time new software is provided by Edinburgh University. The mounting of the new software is easy and the server is to a large extent treated as a black box.
Currently, Pink Book is the only direct method for PCs to use Coloured Book services (it is certainly possible for PCs to access other machines on site using TELNET and thence to access Coloured Book interactive services or to stage file transfers thought it).
All VAX VMS machines have access to Coloured Book services via direct X.25 connections or using PSI ACCESS. With DECNET phase V the current X.25 interfaces will not work and it is envisaged that all access will be via PSI ACCESS although this needs some expenditure. It should be noted that DECs policy is to use DECNET/OSI which aligns with Pink Book but it is too early to say how this would effect the need for the current Spider Gateway.
Many UNIX machines have X.25 connections. Thus there has been small demand for the Spider gateway.
Pink Book can be seen as a way of reducing the number of X.25 connections and increasing the use of the local area network and this has some advantages in the amount of communications equipment required.
The Cons/Cons gateway and Campus Name server form part of the JANET strategic network products which provide a common set of services to the community. In order to maintain these services it is important to support the JANET policy.
The Spider Gateway should be retained as it provides a service to some IBM PCs and UNIX systems which cannot be conveniently provided in any other way.
The Campus Name server should be retained as it is required by the Spider Gateway and may also be used by CAMTEC PADs and other machines in the future.
Both the Spider gateway and Campus Name Server should be supported by Telecoms given suitable documentation and training.
Users and machine managers should currently be given a free choice as to whether to use the Spider gateway or to use Pink Book protocols.
Ulrich - thank you for your note. We need to clarify a few points. In view of the confusion please comment if there are any points which are unclear.
In the light of the removal of the CHGBOX and NLGBOX we have to send ALL our traffic via Montpellier and this is what Mick Reid is doing with his recent registrations. This plan was put to the NOG some time ago and as it was not vetoed is agreed.
The UK FR link has been tested. It is unsatisfactory in that it only works at 7K and gives errors - but we have no option. Montpellier have indicated that they wish to use their EBOX rather than GBOX and we have agreed. We wish to use our GBOX. We thus intend to remove the UKEBOX to FREBOX link. This requires FR to send traffic via their EBOX to our GBOX and Peter Chiu is organising this.
The registrations that Mick Reid sent to you should cause these changes to happen. It may well take a little longer than the end of this month but I understand from correspondence between James Hutton of JANET and Brian Carpenter of CERN that the CHGBOX will remain until the changes are complete.
The GBGBOX to NLGBOX link has always been a pilot link and ceases when NLGBOX is removed. That is the end of that connection.
Turning to the NJE/IP link from UK to HEARN.
The project to establish a UK NL NJE/IP link is a NEW pilot project. We have only had European connectivity since Wednesday. In addition I do not have permission from the JNT to use NJE/IP except on the USA link and can only do experiments to ensure that the link is satisfactory. You will no doubt be aware that the UK IP network is in a pilot phase and does not give a guaranteed service. We also have IXI in between which also may give problems. Thus this link must be regarded as experimental for the present in much the same way as the GBGBOX to NLGBOX was.
This project IS NOT urgent. I think you may have assumed that this link was to replace the current GBOX link rather than a new project. The only reason that we wish to use Nijmegan is that you are a cooperative site and that I have spoken to Kees and Eric-Jan Boss who are happy with the proposal.
I do not think that the NOG needs to know about this experiment until we can demonstrate that a pilot service is possible and I have permission to operate it. You may disagree????
At the last Executive meeting there was a discussion on multiple links from countries and how this related to the various categories of core sites. The document from the RPG group is unclear as to the exact definition of a core site and whether non-core sites could have multiple links. The result of that discussion was that a country which was not a core site could have multiple connections. Thus I see no reason why Ireland should not have links to HEARN, UKACRL or other sites if that is what they want.
I hope this clarifies the situation.
For your information we are trying to set up pilot NJE/IXI links to Pisa and Bonn. We are also intending an experimental VMNET link to CERN. Here we have the problem that there is already an IP link to CERN across an HEP link and EARN traffic must not go across this link. Be believe that we can overcome this problem with "IP gymnastics" and we will be speaking to Olivier about this soon.
Paul.
PS. Thank you for IP number. A ping took 7.5 seconds! Getting up your login screen took 4 seconds!
Not withstanding my comments about changes we can experiment at short notice and we are putting in the VMNET changes now - BUT they will vanish at going home time and we can have another go on Monday and then meditate on the results of our findings.
Here is a first draft of a document to be given to sites wanting to join the IP network. Your comments and suggestions please.
IP (Internet Protocol) is the generic name for a whole set of protocols providing a variety of services similar to the ones provided by the Coloured Book protocols.
IP was developed and is popular in the USA. This popularity has spread to Europe and IP is now used in many UK institutions particularly with UNIX systems.
The popularity of IP has led to an IP service across JANET (JIPS) so that services such as the ARPA FTP (file transfer) and Xwindows (interactive service) can be provided conveniently and in particular to over seas sites.
The IP service is optional. The steps needed to join the service are defined below. It is assumed that the reader is familiar with IP and JANET.
The service is currently provided over the JANET X.25 network and thus no new physical off site connections are needed.
The world wide IP service consists of a set of "IP networks" (typically one or more per site). The networks are interconnected with "routers". Routers know how to get packets to any other networks, they achieve this by means of various protocols which allow routing information to be distributed.
Within JIPS there are a set of "central routers" located at the eight major JANET switch locations or NOCs (Network Operation Centres). Each institute which joins JIPS must have a router which is connected via a JANET X.25 logical channel to a central router. This topology gives an efficient use of JANET.
The central router at ULCC is connected to the USA via the so called Fat Pipe" to Fix-East. It is also connected to NIKHEF in Amsterdam via the IXI X.25 network. These connections give connectivity to IP networks outside of the UK.
The above details of the service may change in the endeavour to provide an improvements.
An "IP network" is defined by an address range. An address range is obtained from NIC.DDN.MIL and this ensures that the address range is unique. An IP address is a 32 bit number which is by convention split into four eight bit fields each one written as a decimal number. Thus a typical IP address would be written 192.130.8.9
Three types of address range can be obtained:
A class. This is for completely different networks and is not relevant.
B class. This is for a large network giving 16K addresses and has the form X.X.Y.Y where X is provided by SRI and Y is selected by the site for each host.
C class. This is for small networks giving 254 addresses and has the form X.X.X.Y
All IP networks connected in any way with JIPS must have their network addresses obtained from NIC.DDN.MIL preferably via the ULCC NOC.
See annex 1 for details of how to apply for an IP network.
A router is required and its purchase is the responsibility of the site. The router can be relatively simple since it need only have a single logical connected to a central router.
A router must have an X.25 interface and an interface to the local area network.
Router recommendations are being developed and advice should be sought from the JNT. (Temporary note - this sentence will be replaced by a reference to an appropriate documents at an appropriate time.)
It is the institutions responsibility to set up their router and convince the management of the central router this has been done correctly.
One side of the router will be connected to the site local area networks which supports IP and will require a local IP address. The other side will be an X.25 connection to JANET, probably via a local X.25 switch. It will also require an IP address for the JIPS side which must be obtained from the management of the central router to which it will be connected.
Only a single route to a single central router is permitted. This policy may be reviewed in the light of experience.
If traffic to the USA is needed then each relevant local network must be registered for NSF. This is done via ULCC
Full details are in annex 1.
If traffic to Europe is needed then each relevant IP network must be registered with RIPE. This is done via ULCC.
Full details are given in annex 1.
The set of Domain Name Servers form a service similar to the JNT Name Registration Scheme on a world wide basis. Unlike the NRS each site has one or more DNSes which it updates. The DNSes are linked in a hierarchical structure and a request to a local server may entail searches in DNSes elsewhere.
DNS systems can be mounted on many popular machines, in particular UNIX. A prescription is available for setting up a DNS on a SUN UNIX machine. See "Starter pack for setting up a DNS" SHOESTRING/91/21 .
A secondary DNS (a backup in case of DNS or network failure) will be held for every DNS at ULCC. In addition DNS must have a local secondary.
[Temporary note - do we need more text here or will an updated SHOESTRING/91/21 be sufficient. Are there any forms that need to be sent in by the site in annex 1 ???????]
Use of the network comes under the same rules as use of JANET and these rules are published in the "JANET acceptable use statement" available from the JNT.
In addition the use of IP is governed by "The use of the JANET IP Pilot" also available from the JNT or as SHOESTRING/91/23.
Both these documents should be made available to users.
A connection to JIPS gives potential access to hosts from the world wide IP network. Institutions, computer managers and users should be aware that this presents opportunities for illegal access and disruption. It is their responsibility to provide appropriate protection.
The JNT, Network Executive and the relevant committees are not responsible for any loss or damage resulting from connections to JIPS.
Security advice and guidelines are under constant review and are available on request. [Temporary note - are they? where are they?]
[Temporary note - Piete put round his comment w.r.t registration of gateway internet address to host mapping. Should this be done via ULCC or directly to HOSTMASTER@mil.DDN.NIC.]
[Temporary note - RIPE has a database template for Domains (the database itself seems conspicuous by its absence). Should we add this template to this document and collect this information for passage to RIPE???? In consultation with Kevin we are not happy with the template. it contains: domain name, names of nameservers, list of IP networks in the domain. We do not see that there is any relationship between domains and networks. Apart from every entry having an address (and it might not even be an IP address).]
The form attached to this annex must be completed for EACH IP network and is used for:
UK JIPS IP networks will be registered in the RIPE database.
RIPE (Reseaux IP Europeens) coordinates TCP/IP networking for the research community in Europe. It operates under the auspices of RARE (Reseaux Associees pour la Recherche Europeene).
One of the activities of RIPE is to maintain a database of European IP networks, DNS domains and their contact persons. This database content is public information. This supports NICs/NOCs all over Europe to perform their respective tasks. A network and its contact persons are represented by different database objects. This means that for each network there has to be a network object describing the network and one or more person entries describing the persons.
Objects are described by attributes one per line separated by empty lines. The information stored about network 192.16.192.0 consists of four objects, one network object and 3 person objects and looks like this:
inetnum: 192.16.192.0 netname: RIPE-X25 descr: RIPE X.25 net descr: Europe country: NL admin-c: Rob Blokzijl tech-c: Piet Beertema tech-c: Daniel Karrenberg connect: RIPE gateway: cwi kth cern inr udo ukc remarks: country is really Europe changed: dfk@cwi.nl 900911 source: RIPE person: Rob Blokzijl address: NIKHEF section H address: Science Park Watergraafsmeer (WCW) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 0413 fax-no: +31 20 592 5155 e-mail: k13@nikhef.nl changed: dfk@cwi.nl 900802 source: RIPE person: Piet Beertema address: CWI address: Science Park Watergraafsmeer (WCW) address: Kruislaan 413 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 5924112 fax-no: +31 20 5924199 e-mail: piet@cwi.nl nic-hdl: PB13 changed: dfk@cwi.nl 900802 source: RIPE person: Daniel Karrenberg address: CWI address: Science Park Watergraafsmeer (WCW) address: Kruislaan 413 address: NL-1098 SJ Amsterdam phone: +31 20 5924112 fax-no: +31 20 5924199 e-mail: dfk@cwi.nl nic-hdl: DK58 nic-hdl: DK85 changed: dfk@cwi.nl 900802 source: RIPE
The database is public. It can be accessed via a who is server on host nic.eu.net (tcp port 43). The whole database is also available via anonymous ftp from ftp.eu.net as file ripe.db in directory ripe/dbase. A shadow database for the European entries is held on arcu.cc.rl.ac.uk (130.246.8.3).
Database updates should be sent via electronic mail to
tony@noc.ulcc.ac.uk
Below you find three templates, one for applying for an IP network, one for network objects and one for person objects. Be sure to supply a person object for each contact person mentioned in the network objects. Of course you need not supply person objects if they are already present in the database and the information is still correct.
Before submitting please delete all indented explanatory text from the templates to save mail bandwidth. The text you submit should start in column one.
Thank you for your cooperation.
cut here----------------------------------------------------------------
newnet:
Indicates whether network exists. If it does not the following
items in this section should be provided.
Format: text - yes or no
Mandatory
Initial:
Estimated number of hosts that will be on this network initially
Mandatory
year-1:
Estimated number of hosts that will be on this network at the
end of the first year
Format: integer
Mandatory
year-2:
Estimated number of hosts that will be on this network at the
end of two years
Format: integer
Mandatory
year-5:
Estimated number of hosts that will be on this network at the
end of five years
Format: integer
Mandatory
Class:
Whether class B or C network is required. Unless a strong and
convincing reason is presented, the network will be assigned a
class C network number. If a class C network is not acceptable
for your purpose state why in the next item. (Note: If there are
plans for more than a few local networks, and more than 100
hosts, you are strongly urged to consider subnetting. [See RFC
950])
Format: text - B or C
Mandatory
Reason:
If class is B this item will contain the arguments for this
choice.
Format: text string
Mandatory, multiple if Class: B
net-type:
Networks are characterised as being either "research",
"defence", "government - non defence", or "commercial", and the
network address space is shared between these three areas.
Format: text - research, defence, government - non defence, or
commercial
Mandatory
---------------------------------------------------------------
IP network number
If the network does not yet exist leave blank.
Format: dotted quad including trailing 0s
Example:
inetnum: 192.19.2.0
Mandatory
netname:
Official network name
If the network exists and is registered then this name will have
been allocated, otherwise a suitable name should be selected.
Format: capitals, numerals and "-" only, starting with capital,
maximum of 12 characters
Example:
netname: TBIT-BUGS
Mandatory
descr:
Description of the network.
Give organisation and place.
Postal address is not needed, this can be found via the con#
tacts.
You can't send postal mail to a bunch of routers and transceiv-
ers, can you? The country is given in country:.
Format: free text, one line per entry, multiple lines in se#
quence
Example:
descr: Network Bugs Feeding Facility
descr: Terabit Labs Inc.
descr: Northtown
Mandatory
country:
Country where the network is located.
Format: ISO3166 two letter code.
We know this gives problems for networks crossing
national boundaries. Choose most appropriate country in
this case, probably the location of the admin-c. The
code for "The United Kingdom of Great Britain and
Northern Ireland" is GB.
Example:
country: GB
Mandatory
admin-c:
Name of administrative contact person.
This is someone who will be contacted about administrative
things such as network registration etc.
This must be the same string as in the corresponding
If the person name is ambiguous, use the nic handle.
Format: <firstname> <initials> <lastname>
Example:
admin-c: John E. Doe
Mandatory, Multiple
tech-c:
Name of technical contact person.
This is someone to be contacted for technical problems
such as routing, (mis)behaviour of hosts on the net etc.
See admin-c above.
connect:
Connectivity Indicators.
This attribute is used for data about routing policy
routing in general. Its values are a combination of
the strings defined below. New strings can be registered
at the database update address.
The definition of this is arbitrary and should be
replaced by something more rational as e.g. AS's that
may be traversed or some such later.
For European access add RIPE for Internet/USA access add NSF. If
you are not sure what to fill in here, put ? and we
will try to fill in something sensible.
Format: A sequence of the strings blow separated by white space.
LOCAL This means routing updates will be
blocked in RIPE routers.
RIPE European
This means RIPE routers will distribute
routes for this net.
NSF NSFnet
This means the net is (supposed to be)
in the NSFnet routing database and thus
has access to NSFnet
EU member of InterEUnet
NORDU member of NORDUnet
Example:
connect: RIPE NSF
Mandatory
aut-sys:
Autonomous system number the network belongs to.
The definition of this is not clear yet.
Format: AS number
Example:
aut-sys: 4711
Optional
nsf-in:
NSFnet routing. Inbound announcements to NSFnet.
This is used for consistency checks with the NSF routing data#
base.
Format: <order>=<AS#> <order>=<AS#>
Example:
nsf-in: 1=703 2=224 3=97
Optional
nsf-out:
NSFnet routing. Outbound announcements from NSFnet.
This is used for consistency checks with the NSF routing
database.
see nsf-in:
gateway:
RIPE gateway for this network.
This attribute was the first attempt at putting routing
information in the database. It is for local use and slated for
removal.
Optional
remark:
Remarks
Format: text string
Example:
remark: currently inoperative
remark: will be operational 01-apr-91.
Optional multiple
change:
Who and when changed this last.
Format: <email-address> YYMMDD
Example:
johndoe@terabit-labs.nn 900401
source: RIPE
Source of the information.
This is used to separate information from different sources
kept by the same database software.
Format: RIPE
Mandatory
person:
Full name.
This must be the same as the corresponding contact attributes.
Format: first names first, no commas etc.
Example:
person: John E. Doe
address:
Postal address
Include everything necessary for paper mail to be delivered.
Format: multiple lines of text
City and post code on a single line.
Country on the last line.
Example:
address: Terabit Labs Inc.
address: Industrial Estate North
address: North Perpendicular Road 12
address: NN-1234 Northtown
address: Northern Nowhere
Mandatory
phone:
Telephone
Multiple numbers in the desired order please (secretariats
etc.).
Format: International +<country-code> <city> <subscriber>
If no direct inward dialling is available,
please append "ext." and extension number.
Example:
phone: +31 20 12334676
phone: +44 123 987654 ext. 4711
Mandatory, Multiple
fax-no:
Telefax
see phone
e-mail:
Electronic mail address.
Format: Valid domain address please (if possible no !, %, ::)
Example:
e-mail: johndoe@terabit-labs.nn
nic-hd:
NIC handle. An identifier used by SRI-NIC to unambiguously refer
to Internet people.
Format: NIC format
nic-hd: JD0401
Optional but strongly suggested for those who have a NIC handle.
remark:
Remarks
Format: text string
Example:
remark: RIPE coordinator Northern Nowhere
Optional multiple
change:
Who and when changed this last.
Format: <email-address> YYMMDD
Example:
e-mail: johndoe@terabit-labs.nn
source: RIPE
Source of the information.
This is used to separate information from different sources
kept by the same database software.
Format: RIPE
Mandatory
Braden, R.T.; Postel, J.B. Requirements for Internet gateways. Marina
del Rey, CA: University of Southern California, Information Sciences
Inst.; 1987 June; RFC 1009. 55 p. (NIC.DDN.MIL RFC:RFC1009.TXT).
Mogul, J.; Postel, J.B. Internet standard subnetting procedure.
Stanford, CA: Stanford University; 1985 August; RFC 950. 18 p.
(NIC.DDN.MIL RFC:RFC950.TXT).
Postel, J.B. Internet Control Message Protocol. Marina del Rey, CA:
University of Southern California, Information Sciences Inst.; 1981
September; RFC 792. 21 p. (NIC.DDN.MIL RFC:RFC792.TXT).
Postel, J.B. Transmission Control Protocol. Marina del Rey, CA:
University of Southern California, Information Sciences Inst.; 1981
September; RFC 793. 85 p. (NIC.DDN.MIL RFC:RFC793.TXT).
Postel, J.B. Address mappings. Marina del Rey, CA: University of
Southern California, Information Sciences Inst.; 1981 September; RFC
796. 7 p. (NIC.DDN.MIL RFC:RFC796.TXT).
Obsoletes: IEN 115 (NACC 0968-79)
Postel, J.B. User Datagram Protocol. Marina del Rey, CA: University
of Southern California, Information Sciences Inst.; 1980 August 28;
RFC 768. 3 p. (NIC.DDN.MIL RFC:RFC768.TXT).
Postel, J.B. Internet Protocol. Marina del Rey, CA: University of
Southern California, Information Sciences Inst.; 1981 September; RFC
791. 45 p. (NIC.DDN.MIL RFC:RFC791.TXT).
Reynolds, J.K.; Postel, J.B. Assigned numbers. Marina del Rey, CA:
University of Southern California, Information Sciences Inst.; 1987
May; RFC 1010. 44 p. (NIC.DDN.MIL RFC:RFC1010.TXT).
Obsoletes: RFC 990 (NACC 2139-86)
Reynolds, J.K.; Postel, J.B. Official Internet protocols. Marina del
Rey, CA: University of Southern California, Information Sciences
Inst.; 1987 May; RFC 1011. 52 p. (NIC.DDN.MIL RFC:RFC1011.TXT).
Romano, S.; Stahl, M.K.; Recker, M. Internet numbers. Menlo Park, CA:
SRI International, DDN Network Information Center; 1989 August; RFC
1117. 109 p. (NIC.DDN.MIL RFC:RFC1117.TXT).
NJE can be carried over:
BSC X.25 IP (possibly over X.25) SNA (possibly over X.25) DECNET (possibly over X.25)
There are undoubtedly other carriers of less interest.
BSC is now impossible with the removal of the leased line to CERN. A channel on the HEP line can be used (unlikely). Traffic could be sent via Ireland but this would probably entail the UK taking financial or part financial responsibility for the line or part of it. Performance would degrade with the 4.8K bandwidth. The Irish may not be happy to take such a large traffic load on a relatively small machine.
X.25 was to have been the preferred method of transfer via the GBOX. This has become increasingly difficult with decisions by Sweden, Holland and CERN not to use them. France has indicated that they wish to use the EBOX even though this gives a poor performance of 7K and often breaks. A connection has just become possible to Italy who now have a GBOX. A connection to the EBOX in Germany may be possible although it is understood that Germany is not enthusiastic. Although a GBOX link is in use to Ireland, Ireland is now using IP to other countries and only run their GBOX for our convenience.
IP is now being used on a number of links within EARN. Many of the technical experts want EARN to become based on IP. It turns out that NJE/IP/X.25 is less performant than NJE/X.25 since all the NJE/IP and IP traffic goes across a single X.25 call rather than each NJE connection having an X.25 call.
SNA is not prospering in EARN and even the Germany-France link is being replaced by IP.
NJE/DECNET is not in use on any international links and there is no enthusiasm for its use.
The EARN "regionalisation proposal" is based on multiple links between "core" countries and leaf countries being connected to a core site. "B" class core countries also have links to the USA. There are no restrictions on the low level protocols used for carrying NJE. There is some confusion on the exact definition of a core country. It is unclear whether a leaf country may have more than one connection, Ireland has more than one and is not a core country. It is unclear whether a core country has to have a connection to every other core country, it may not be appropriate to have complete interconnection for topological reasons.
It was our policy to use NJE/X.25. With the changed circumstances this is becoming less attractive with only two other GBOXes (Italy and Ireland) and two EBOXes (Montpellier and possibly Bonn) to communicate with. Although Spain, Potugal, Greece and possibly East European countries may get GBOXes it is unclear whether they will use them for NJE.
JNT is now happy for an NJE/IP connection to be established to the USA via the "Fat Pipe". This could carry one third of the UK EARN traffic. Permission is being sought for this connection with the USA and EARN.
So far we do not have JNT permission to establish NJE/IP connection to other destinations. An experimental link has been set up to Nijmegan. This works well but has a performance somewhat lower than the NJE/X.25 link. Some initial discussions have been held with CERN to set up an experimental NJE/IP connection but there are some technical problems due to the existence of the HEP IP connection.
The Netherlands and CERN connections have now been removed and all traffic is going to Montpellier and Ireland.
Traffic has reduced since the Irish traffic now does not pass through the UK.
An NJE/X.25 link has been set up to Italy.
An NJE/X.25 link is being sought to Bonn.
An experimental NJE/IP link has been checked out to Netherlands.
An experimental NJE/IP link is being explored to CERN. This is difficult because of the existence of the HEP IP link which gives addressing problems. >
An NJE/IP link to Maryland (USA) via the Fat Pipe will be set up as soon as some technical details are sorted out.
Operations find that the existence of the GBOX and IBM NJE links rather complex and would find it easier if all traffic were concentrated on one or the other (preferably the IBM). With a larger number of links spool queues will be less likely to rise unless there is a severe problem with JANET or IXI.
Short term:
The IP/NJE line to the USA should be pursued.
NJE/X.25 should be exploited where possible.
IP/X.25 should be checked out and permission for its use sought.
Long term:
NJE/X.25 links are likely to be removed as a result of actions outside of the UK and will need to be replaced by NJE/IP connections.
Rutherford will shortly have an IP connection to FIX-EAST as a result of the emerging UK IP network.
We would like to open an NJE/IP connection to the USA across this 256K line for EARN traffic.
I have agreement from the UK Joint Network Team for this connection.
I have a provisional agreement with UMDD to host the USA end of the link.
About 1/3 of the UK traffic goes to the USA and this connection will therefore reduce the load on other links significantly.
As for "Core Site Guidelines" Rutherford would seem to meet all requirements except:
number 2 (It is our intention to order RSCS V3 very soon)
number 4 (Insufficient information to determine the requirement for "additional software" although in principle the requirement can be met).
number 8 (The requirements are unclear. We are putting together operating procedures for the whole UK IP network which will have central management. Rutherford is one of 8 largely interconnected central sites for this network which will ensure a high availability and reliability).
number 9 (The requirement for the router to be on UPS will not be met. The router is run by the central JANET IP management. It is on the same power supply as the X.25 switch that all the traffic flows through. The power supply to the site is highly reliable. Thus no useful gains can be achieved by UPS.)
As background, the UK IP network runs over the JANET X.25 network largely on 2Mbit connections. It is based on 8 central CISCO routers at the 8 major switch sites. Other sites are connected to one of the central routers via a static route. The Router at University of London Computer Centre is connected to the USA (FIX-EAST) via a 256K line. It is connected to Europe via IXI and Amsterdam. The pilot phase of this network is being developed and has 12 members so far and a general service is expected towards the end of the year.
I would appreciate comments from the EARN RPG group, the EARN NOG and the EARN Executive.
Paul Bryant.
The SHOESTRING project to provide a pilot UK IP service to selected sites is progressing according to plan.
Three central sites and about seven leaf sites have been operating with great success for many weeks.
Experience has now confirmed that the strategy of operating IP over the JANET network is a viable and successful scheme when allied with a careful control of the IP topology.
Whilst the number of institution connected has been small the technical and organisational progress has been swift. The network is now successfully connected to the world wide IP networks. The Domain Name Servers (the IP equivalent of the NRS) have been installed in most institutes and the theory of their organisation has been worked out and largely implemented.
The CISCO routers for the NOC sites have just been delivered and this will lead to an expansion phase during which the network of central routers will be completed and a few more institutes added. This will start to test the operational procedures which have and are being developed.
Although many issues have been raised, so far these have all had happy solutions. Indication are that this project is on course and has the hall marks of success.
FDDI Meeting
Tuesday 14.00 Think Room.
R Brandwood, P Bryant, P Chiu, B Day, K Hoadley, A Jessett, T Kidd, R Westlake.
Agenda
1 Report on ULCC/JNT FDDI Venders Day
2 FDDI proposal paper, most technical issues will come up under this item
3 Next meeting, if any.
Dear sir,
Thank you for your letter of September 4.It really is a load of Rubbish.
I am happy to continue wit the ENV 41 901 work. I am not at all sure that further work is justified but I am happy to be led by the remainder of the group that worked or will work on the topic.
Yours sincerely,
Paul Bryant.
The autumn of 1991 saw the Marco Sommani becoming Secretary General of EARN in place of Paul Bryant who became the Treasurer.
In deciding not to seek re-election Paul commented "however good or bad an officer has been a change is healthy for the organisation". During his time he concentrated in making EARN work efficiently. This has been very successful in turning EARN from being seemingly arcane and muddled into being open and well organised. That of itself does not solve the many problems EARN is faced with but it does ensure that the Executive and Board of Directors can concentrate on the real issues with the full and well researched facts before them. Paul admits that in concentrating on the organisation he neglected the publicity aspects of the job. He hopes that his successor, in inheriting a smooth running organisation, can concentrate his different but undoubted talents on these other aspects that certainly need attention.
In his report to the 1990 Autumn Board meeting, Paul paid tribute to his long suffering colleagues who had to endure his continual nagging for proposals and reports. In particular he paid tribute to Frode Greisen with whom he had developed an excellent working relationship that had been of great value and without which little would have been achieved. He was a privilege to work with in these changing and difficult times.
EARN has been faced with a much more complex environment. There have been many more organisations and network providers to work with. EARN has had to build relations with IXI, EASInet, RIPE, NT and DEC as well as maintaining good relations with its original friends such as IBM, BITNET, CEPT and RARE. It is only by being well organised with strong but appropriate policies that the best services can be provided to the customers. Undoubtedly the presence of permanent staff has been of great help in archiving EARN's objectives.
During the last two years the Executive and Board have been subjected to several hundred papers dealing with the trivial ephemeral issues such as hotel bookings to the important strategy papers. A task now under way is to extract the important papers of lasting interest as a convenience. Such papers include the Code of Conduct, Management of Change and others, which govern the day to day life of the network. Of particular note is the EARN Operational Procedures that draws together many small decisions taken over the years. Some of these have never been written down but are needed so that EARN can concentrate on important issues rather than the bureaucratic but necessary mechanisms needed to run the organisation.
Marco Sommani has already made significant changes to the way things run. With permanent staff it is now appropriate for them to carry out many duties that were performed by Paul, such as minute taking and issuing and archiving documents. This has been most successful and indeed Hans Deckers, the EARN manager, has introduced his own ideas for further improving EARN's decision making. Of particular note is the introduction of regular quarterly reporting on EARN's major activities. These cover traffic statistics, finance, and use of staff. This allows easy comparison between periods leading to the early identification of problems and a wealth of data on which to base decisions. As a result of these changes the EARN document archives have been moved from the filelist EARN-MIN at UKACRL to FRORS13. There is also a plan to move the EARN-BOD and EARNEXEC distribution lists from IRLEARN to FRORS13.
The number of documents that are stored on EARN-MIN FILELIST is large and increasing. It is difficult to select documents which treat particular subjects, since the EARN INDEX only lists just the titles that are often cryptic and have little meaning. The LISTSERV database driver has been modified by the ASTRA team (see the ASTRA report, BOD22 91) to enable more sophisticated searches in the EARN archives. An ASTRA-LISTSERV interface is also being developed that will make it possible and easy to search the LISTSERV database through the ASTRA interface.
Marco believes that the problem of providing easy access to network information should be a main concern of the Secretary General of EARN and of the Association. This is not the place to elaborate this subject further as many interesting suggestions can be found in the EARNSTRA paper (BOD10 91). Certainly Marco will develop the ideas for access to data in the EARNSTRA paper and looks forward to discussions and feedback on the ideas.
An important project is the complete revision of the EARN handbook produced originally in Germany. The EARN staff hope to have this complete during the autumn of 1991.
The document is CONFIDENTIAL since some informal discussions suggest the subject is sensitive and could prejudice current talks with countries wishing to re-negotiate their subscriptions. In addition, there is a possibility that if the use of SMTP is accepted and promoted then it could undermine or change the character of EARN.
That the use of SMTP should be allowed if not encouraged within EARN. The proposal is put forward in order to debate the issue rather than the view of the author.
Many EARN nodes have domain addresses (in the sense that the mail address they use for EARN is also in the Domain Name Server). Thus mail can either be sent via BSMTP (as now) or by SMTP.
As far as investigations have so far gone, all the mail facilities will work via SMTP. For example, mail to LISTSERV or NETSERV will get the desired result. Small scale technical investigations by the author have found no problems. Informal discussions with a few other experts have not revealed any technical problems.
Examination of DOMAIN NAMES shows 97 entries referring to SMTP systems and 112 to MAILER. One can infer that SMTP domain names are accessible via SMTP. Many names are accessible via SMTP even though DOMAIN NAMES would not indicate this. For example, all UK and Italian mail addresses are accessible via SMTP. There remain many machines that do not have such access and this is difficult to calculate.
The technical advantages of the use of SMTP are:
The disadvantages of the use of SMTP are:
It is likely that sites may (as is their right) reconfigure their mailers to use SMTP. Thus, independently of what EARN decides, the use of EARN for mail will reduce leaving EARN with running a service between IBM machines which are the ones which need NJE most.
The debate has been initiated by a low profile experimental project to use SMTP for Rutherford/Pisa traffic. This to be achieved by merely altering entries in MAILER PROFILE which defines how mail is routed.
Interestingly, at the recent RIPE meeting the Italian attendee encouraged countries to send all their Italian mail via SMTP.
I asked Michael Gettes for his opinion. He seemed to have no technical objection but considerable political misgivings.
He objects to the UK using SMTP since this would reduce the pressure on the UK to make connections to all the other core sites. This would undermine the EARN intention to be able to redirect traffic down the UK "fat pipe" in the event of failure. In fact he is rather unhappy with the UK being a core site with their current political JNT difficulty of making connections into Europe.
It must also be noted that the use of the UK to USA link has removed a lot of traffic from the Montpellier line and the intervening links which is to the benefit of users. If the line were to be closed because the UK connections into Europe made redirection unsatisfactory then such a move would be to the demonstrable disadvantage of the user for some un-demonstrated technical advantage and a political objective.
His arguments are interesting and warrant further analysis. Certainly, the UK use of SMTP would reduce by half (my gross estimate) the UK EARN/BITNET traffic. Certainly, the technical demand for further logical NJE connections into Europe would be less. Traffic analysis shows that the current four logical NJE connections into Europe now cope easily with the traffic since 66% of UK traffic goes to the USA. In addition, traffic from the UK is limited by the two IXI 64K lines and the connections out of IXI into France, Germany, Italy, and Ireland. These are of limited performance. Hence, any redirection of traffic in emergency via the "fat pipe" would probably be fairly insensitive to an increase in NJE connectivity. Least there be confusion, I firmly support greater NJE connectivity from the UK and taking a full part in the regionalisation project. We must differentiate between technical and political issues - if SMTP is useful then this use must not be prevented as a way of forcing a country to take some other desirable objective.
It could be argued that if the UK decides to divert traffic from BSMTP to SMTP then that is the prerogative of the UK and EARN has no right to object. I would comment that when a piece of mail is received at UKACRL with a domain address there is no "policy routing" information to indicate whether it should be regarded as EARN, Internet, EUnet, X.400 or any other possible route.
If the use of SMTP is encouraged then there will be a decrease in BSMTP. This would be seen as a reduction in EARN traffic and an undermining of the EARN network. With the increasing spread of IP it is likely that most machines will have an IP connection. In addition, many countries (such as Italy) will run gateways between BSMTP and SMTP. These gateways, as well as allowing EARN international traffic to be converted to SMTP for local distribution, also allow international SMTP to be converted to BSMTP for a country with a lot of NJE and little IP.
What traffic is EARN traffic is an interesting point. BSMTP would be, SMTP may not be. What about SMTP traffic using LISTEARN? What about traffic which gateways between SMTP and BSMTP?
Mail is one of the major uses of EARN and if moved to SMTP EARN would be left with the remaining NJE file transfer traffic, messaging traffic, and the organisation of LISTSERV.
Countries', such as the UK, use of EARN is almost entirely mail and it is fairly easy to move most of this to SMTP thus allowing them to leave EARN with little effect on traffic. It is unclear just how many countries are in a similar position.
A further issue is that the number of NJE hosts is fairly static whereas the number of IP machines (mainly UNIX) is increasing rapidly thus increasing the attraction of IP and SMTP.
If SMTP is encouraged and thus mail is no longer a major concern of EARN then this undermines the current objectives of EARN. This raises questions which have been addressed on many occasions as to the future of EARN. Similar questions are raised by the paper from Hank Nussbacher advocating converting all current international EARN lines to IP.
If EARN traffic does fall substantially there may well be arguments as to why this falling use requires the same or an increasing subscription level.
This issue does address the question of whether the management of NJE should be undertaken by the expected RARE Operations Unit. One could envisage that if this were to happen then the mail activities would be better served by RIPE and the LISTSERV activities would need some other home. This begs the question as to the future of the EARN staff. They may well form the nucleus of the RARE Operations Unit. There may be alternative projects with databases but these may be difficult to fund with the likely hood of countries leaving EARN or expecting a lower subscription with the removal of services to other organisations.
The purpose of this paper is not to advocate any particular action but to note that the technological changes and opportunities together with EARN's financial problems with major countries will force EARN into some radical actions in the near future. It would be better if the Executive could provide a sound development proposal to the Board of Directors.
With the current delicate negotiations between the UK and EARN on their subscription it is better that this paper remains CONFIDENTIAL to avoid prejudicing these negotiations. In addition, a discussion within the Board should await a more mature paper preferably with an Executive proposal.
Present: J Barlow, P Bryant, T Daniels, J Hutton
Noted: The recent figures were examined and the following points made:
Noted: CCD, as the operating agent to support the EARN gateway, were concerned about the unreliability of the EBOX and GBOX connections and the fact that no international EARN links other than those to the UK continued to use this technology in the future. No effort was available in the UK to debug the software, and as a product with little future, such effort would be difficult to justify. The authors of the product, IBM Germany, are aware of the problems and have been unable to cure them but they do have vague plans to rewrite it to use modern versions of the IBM ISO products. An alternative product, VMNET, was already in use supporting the trans Atlantic link and is proving to be far superior, being easy to install and operate as well as being problem free. It is in widespread use with an assured future. CCD made the strong recommendation that VMNET be used to support all the EARN links.
Agreed: J Hutton would seek advice from the JNT on the use of VMNET on all EARN links from the UK. ACTION J Hutton
Noted: The renegotiation of relations with EARN were the subject of an expected meeting between R Cooper and F Greisen. P Bryant had reminded F Greisen to pursue the matter and J Hutton had reminded R Cooper.
Noted: The next EARN Board Meeting was on November 21/22 and any proposals to put before the Board must be provided 3 weeks before the meeting. These could take the form of the results of negotiations or could be unilateral proposals from the UK. R Cooper had been reminded by P Bryant of the situation.
Noted: A German/UK line was likely early in 1992 but would not affect EARN traffic. Negotiations between France and lately Italy were continuing.
Agreed: The licence fee for VMNET ($2000 per year) would be met by JNT in financial year 1992/3 on the basis that its use was entirely concerned with EARN. This is subject to confirmation by J Hutton after discussions within JNT. ACTION J Hutton
Noted: As previously agreed the maintenance costs of the GBOX will be met by JNT.
Noted: The UK had not paid its 1991 EARN subscription. A reminder had been sent to J Hutton who had not taken action. R Cooper was responsible for EARN finances and political matters and J Hutton was responsible for EARN technical matters. Due to "mail overload" it would be better to send important mail to J Hutton by paper mail.
Agreed: The mail to J Hutton regarding the UK subscription would be resent to R Cooper. ACTION P Bryant
Noted: RAL had not received the recent letter from H Whitfield concerning EARN which went to all computing centre directors. This will be circulated to P Bryant, T Daniels, and B Davies. ACTION J Hutton
Noted: The EARN gateway was very flexible in routing mail.
Agreed: No changes would be made in the EARN gateway with respect to routing as a result of the H Whitfield letter at this time.
Noted: A Pegley (responsible for some EARN user support activities) was moving to Systems Group. Currently there are recruiting problems which make a replacement unlikely in the near future. Some support duties were being undertaken by P Bryant, G Christian, P Girard and T Kidd. Whilst this was not satisfactory it was noted that the level of complaint was quite low due to the mature nature of the mail systems. Thus RAL was unlikely to use up the full man year of effort allocated to support by the JNT.
December 3 at 0900. This date will be after the EARN Board of Directors meeting and hopefully after discussions and agreements between EARN and JNT.
From our recent meeting and on reflection I feel that you may be unaware of recent developments in EARN which form important background information for you.
You will be aware that EARN has a "regionalisation project" which has been endorsed by the Board of Directors. The Board papers are in the JNT's possession but I attach a copy in case you do not have one.
I am sure you will appreciate from the EARN paper that the regionalisation strategy will provide a far more robust and performant platform for NJE traffic. This is certainly the experience in the USA with the BITNET backbone which is already built on this basis.
The idea is that all the important international nodes are completely interconnected and that smaller sites are connected to one of the core sites. Core sites come in two flavours - ones with USA connections and those without. Initially we were not a core site because of our poor connectivity to Europe. In the light of your request for us to use the 'fat pipe' I argued for core status and promised to use my best efforts to get as much interconnectivity as I could. Initially it was expected that all the core sites would be connected by VMNET but I successfully negotiated that the interconnection could be by any suitable NJE carrier (X.25, SNA or whatever). I expected that there would be enough GBOX and EBOX sites to be able to connect to most core sites. In the event this has not come about and our connectivity to other key European sites is poor.
There is pressure from EARN and BITNET to increase the UK connectivity. In particular Michael Gettes who organises the BITNET backbone is advocating in private mail messages that the UK should no longer be a core site in the light of the difficulty of setting up adequate connectivity. Such a move would be a disappointment as having to send all our traffic via IXI to Montpellier would take us back to the dark ages and would certainly provide a poorer service to the community.
Complete interconnectivity is not essential but additional connections to CERN, SEARN, and AEARN would be a minimum to keep EARN and BITNET happy.
There are several other technical papers particularly those from the USA. You will no doubt have access to all the EARN BOD papers which also include some useful papers and also an index to all the Executive papers which contain all the various working documents which give further information you may find useful.
Paul.
The UK proposes that EARN funds should not be used for the financing of the RIPE NCC.
The reason for the UK opposition to EARN funding the RIPE NCC is that the UK funding was not provided to EARN for that purpose. UK funding was provided to implement other plans (including an X.25 network and NJE/OSI) and if the plans change EARN countries should get a rebate.
These are the arrangements for funding JANET and the UK networking programme, finance is not provided to spend as the JNT wishes but has to be spent what is agreed or funds are not provided.
It should be noted that the UK are also being asked to make a national contribution to the RIPE NCC and its contribution will be based on the RARE Key. Funding direct the UK has some control, funding through EARN it has no control hence the UK would prefer to fund directly.
EARN ended the financial year 1990 with its finances in a healthy state.
There was an underspend in a number of areas. In particular the expected expenditure with respect to the X.25 infrastructure was small as a result of the closure of the infrastructure, the termination of DEC support and subsequent repayment of part of their contribution. In other areas there had been minor differences from the budget figures which in general had been under expenditure.
The figures in the detailed accounts are in French Francs as the EARN accounts are kept in this currency. Translated into the ECU, which EARN uses for budgetary purposes, the key figures are:
budget KECU actual KECU 1990 1990 1989 Expenditure 898 623 427 Surplus and contingency 165 303 202
The surplus and contingency is on the pessimistic side as the EARN reserves are held as bonds and the interest on the bonds is only realised on their sale. The interest would add about 50 KECU to the reserves.
The EARN reserves as of December 31 1990 taking account of bonds, bank accounts, debits and credits but excluding interest and non financial assets are 680 KECU or with interest about 730 KECU.
When the accounts were closed, regretfully a number of countries had not paid their subscriptions but this situation has now been rectified in all but a few minor cases.
Full details of the EARN accounts were published at the Spring 1991 Board meeting and can be obtained from the EARN Manager.
The 1992 budget and forward look are based on EARN continuing with its current policies. In a fast moving area it is unclear whether this assumption will be correct and some revision may be needed as events unfold.
The expenditures in 1990 have been less than expected. This follows the pattern of previous years. As a result the Board has decided to base the 1992 budget on the real 1990 expenditures increase by 10% for inflation rather than the 1991 budget increased by 5% for inflation. This results in a reduced budget in which the income and expenditure are likely to balance.
As a result of the underspend in 1990 and previous years, the planned 700 KECU contingency fund has been met a year ahead of target. This led to the deletion of a contribution to the fund in the 1991 budget and no contribution in 1992.
The major change is the possible provision of a second trans-Atlantic line in 1993. Apart from that there is an assumption that expenditure will remain the same but inflated by 5%.
Quarterly financial statements are now produced rather than statements which are as up to date as possible with respect to a meeting date. The new procedure allows easy comparison between quarters and between years, it also removes the work needed to update accounts at the last possible moment before a Board meeting.
Fast connections are required between the CRAY, IBM 3090, RS6000 UNIX, the TOPAZ 2 video system and the ethernet local area network. The solution should follow standards and be capable of extension to encompass workstations and graphics facilities. Equipment must be for delivery in 1991.
The 100 MBPS FDDI token ring is the only high speed standard which can meet the requirement. For further details see technical annex.
The strategy is to provide an FDDI network connected to the existing ethernet local area network with a router.
The only product is the NSC 7000 with a PB130A board.
The only product is the NSC 7000 with a PB225 board.
The IBM 3172-2 will not be available until 1992 and would cost about £51,000.
An FDDI interface will not be available until next calendar year and there are no technical details available.
It is possible to connect an RS6000 to the NSC 7000 using the IBM optical interconnect channel. This would cost £58,587 for the minimum of 8 connections and is currently rejected on cost grounds although it could be attractive if a large number of RS6000 were purchased.
The TOPAZ would be connected to FDDI at a cost of £6,800 which is the cost of a VME FDDI board from CMC. This includes UNIX software.
The SUNs currently installed in CCD can support FDDI with a third party VME FDDI board at £6,800. Newer SPARCstations can support FDDI at a cost of £7,577. This is an option for consideration.
The current VAXes installed in CCD cannot support FDDI. Newer models can. It would be possible to connect the current VAXes to FDDI using the NSC 7000 (via the Hyperchannel mini-computer interface at £13,000). This may become a requirement for FRAM. This is an option for consideration.
No IBM PC interfaces have been identified.
A number of options have been identified but only paper evaluations have been possible.
The attraction of this solution is that it is relatively cheap being an incremental cost on the NSC equipment needed by the CRAY and IBM interfaces. It has been tested in the JNT FDDI project at two sites and is believed to be technically sound. The incremental cost of adding this routing facility to an NSC 7000 is £12,369 (list). X.25 will not be available until 1992.
This is a low cost "stand alone" router with a cost of £17,000 (list). X.25 will not be available until 1992.
The principle advantage is that CISCO equipment is well known in CCD and enjoys a high degree of confidence. It has 2 X.25 ports. The cost is high at £23,823 (discounted).
It is expected that for reliability reasons (see technical annex) end equipment would be connected via an FDDI concentrator. No survey has been undertaken by CCD. JNT recommend the DEC concentrator and a four channel upgradable model costs £5,200 (discounted).
As this equipment is central to the paper a brief commentary is given here and a more detailed one in the technical annex.
The NSC 7000 is based on a crate into which various interface cards can be plugged. For reasons of economy it is sensible to use the crate for a number of interfaces. The crate comes in three sizes.
Only with the largest crate it is possible to incorporate the CRAY, IBM, FDDI, ethernet and a router board which gives maximum economy.
If a further CRAY is to be installed then there is insufficient room in a single NSC 7000. If this is to be accommodated at this stage then either a stand alone router or two NSC 7000 boxes will be required. Two NSC boxes are rejected on cost grounds.
This is a minimum cost solution which only allows a single CRAY connection.
NSC 7000 equipment (NSC prices are list) CRAY PB130A and crate £51,263 IBM PB225 £15,693 Ethernet PCET54 £ 8,369 Router £5,000 FDDI PCDAS £16,216 DEC equipment Concentrator £5,200 Topaz CMC FDDI board £ 6,800 Total £108,541
This will permit the connection of a second CRAY and is cheaper than taking option 1 and upgrading it at a later date.
NSC 7000 equipment (NSC prices are list) CRAY PB130A and crate £51,263 IBM OB225 £15,693 FDDI PCDAS £16,216 NSC 6000 router £17,500 DEC equipment Concentrator £5,200 Topaz CMC FDDI board £6,800 Total £112,672
Other router options can be used at greater cost.
All software is already acquired or is bundled with the equipment.
IBM channel cables are already to hand.
It is unclear whether a Cray channel or cables exist. It would be possible to use the Hyperchannel interface. There are currently spare channels and cables on the bureau side of the Cray.
Fibre optic cables are a minor cost.
As all the equipment will be in the computer rooms there are no cabling problems.
There are no power supply problems.
The heat dissipation is not known yet.
The FDDI standards, being developed by ANSI, are largely complete.
A station can be single attached (SAS) or dual attached (DAS) to the ring. SAS stations connect to only one of the rings (or more often to a concentrator) and there is therefore some negligible resilience lost but the interface is sometimes cheaper.
Although FDDI is based on a logical ring, in a practical installation the physical ring is likely to connect "concentrators" and major facilities as DAS stations. Workstations would normally attach to a concentrator as a SAS station. In general, DAS stations are likely to be limited to devices that are switched on permanently since the ring will partition if more than one fails. With concentrator connections the concentrator can detect when a SAS station is switched off and will "heal" the ring automatically.
Concentrators can cascade. A network could consist of just a concentrator or set of cascaded concentrators. It may also have no concentrators. The exact configuration is flexible and depends on local circumstances.
Many manufacturers now produce FDDI equipment and, although still expensive, prices have fallen as the technology has become more popular.
The various segments of the current ethernet local area network are "bridged" together. Bridging directs traffic at the lowest addressing level, that is the Media Access Control (MAC) address level or ethernet address. To move traffic onto other technologies or networks a "router" is normally required which directs traffic at a higher address level, in particular the IP or DECNET address.
It is possible to bridge between ethernet and FDDI networks. This is relatively simple as both networks have 48 bit MAC addresses. It is unclear how one ensures that FDDI and Ethernet addresses are unique. In addition there are other technical details that are unclear as the standard does not yet seem firm.
The arguments in favour of bridging are:-
The arguments in favour of routing are:-
The decision as to which path to take is fundamental as it will have effects on the future development of the local area network as the FDDI network expands. If a routed solution is chosen then the result would eventually be an FDDI backbone network routed to local departmental FDDI networks and also routers to departmental ethernets. If a bridged path is taken then either the proposed FDDI would expand to cover the whole site with concentrators in each department or there would be a backbone FDDI bridged onto local FDDI networks. The FDDI technology is sufficiently different to ethernet and router technology has developed sufficiently to warrant a rethink.
The current local area network was based on bridges for performance and cost reasons and if the network were to be re-implemented opinion is that it would be equipped with routers.
The following routers have been considered- NSC 7000, NSC 6600, CISCO AGS+, and DECnis 600.
All provide multiple ethernet interfaces as well as an FDDI one. All provide or promise X.25 interfaces.
NSC as a single supplier would be an advantage. Manchester University did use NSC equipment in the JNT pilot and were quite impressed. On the other hand its technical merits are unclear with the small sample of users in our community.
The NSC7000 router is attractive as it would fit in the same box as the IBM and CRAY interfaces with some cost saving. The PCET54 ethernet connection takes up 3 backplane slots and 4 IO slots but this includes the router facility. It provides 4 ethernet interfaces. The cost is £8,369 (list) for 4 ethernet plus £5,000 (list) for the PDIPI router board. It also requires the crate which would be discounted across other equipment.
A less cost router, the NSC6600, is available with 2 ethernet interfaces at £17,500 (list) and with 4 ethernet interfaces at £19,750 (list). These have the disadvantage that they cannot be upgraded. Whilst less cost than a Cisco they are more expensive than putting the router into an NSC7000.
CISCO AGS+ is attractive but expensive. It could be used for other tasks such as DECNET Phase V routing.
DECnis 600 would be an attractive option since one will be required for DECnet phase V, unfortunately it is ruled out since the FDDI interface will not be available until next year and no costs are available. PPD and CCD are seeking to evaluate a DECnis 600 box in December with an aim to study the feasibility of replacing the 2 DEC X.25 Router 2000s currently used on site. It is noted that when DECnet/OSI (Phase 5) comes along in Spring 1992, the X.25 router software will support DECnet routing or PSI Access but not both concurrently as it is at present.
The NSC7000 is a series of crates which can be populated with various interfaces. There are three models. Each model has a limitation on the number of backplane slots and the number of I/O slots.
In all cases 2 backplane and 1 IO slot are needed for the "nucleus" and management port.
The boards of interest are:
Function Name Backplane slots I/O slots CRAY PB130A 4 2 IBM PB225 1 4 Ethernet PCET54 3 4 4 interfaces FDDI PCDAS 2 2 RS6000 PB290 4 3 8 interfaces Hyperch PB400 4 2 2 or 4 interfaces
An X.25 interface will be available in 1992.
Several companies provide concentrators including DEC. These are relatively simple pieces of equipment.
The DEC concentrator cost is £2400 for the crate plus £2800 for a 4 port card to use on multi-mode fibre or £3600 for a 4 port card to use on single-mode fibre.
No evaluation has taken place.
TOPAZ is based on a VME bus and thus the cost is £6800 for the FDDI card. Software for UNIX is included.
Currently SUN only provides FDDI for the following machines:
SPARCserver 370/390/330/470/490
These are all deskside machines and CCD does not own an example. The cost of an FDDI board for such a machine is £10,825 list or £7,577.50 to RAL ex VAT.
The cheapest machine currently supplied which will take an FDDI board is the SPARCserver 330 at £24,000 list or £17,360 to RAL. This will change shortly in the wake of SUN announcements, particularly their new multiprocessor machine, however this may actually increase the cost of FDDI on a SUN.
There are future plans to produce and supply a DDI SBUS version of the current VME FDDI card. This should be cheaper and will run on copper rather than fibre network. A DDI to FDDI converter will also be made available.
The DDI solution will mean that FDDI connectivity will be available for SUN's smaller machine range:
SPARCstation 1/1+/IPC/IPX/2
This is significant since CCD do not possess any of the large SPARCservers and are unlikely to do so.
The SUN FDDI offerings are available in either DAS or SAS form.
The non SUN option for FDDI is to use a VME FDDI board from a third party costing £6800.
DEC only provide interfaces for machines with XMI bus. Both CRAYFE and RLVE have no such interface. There are possibilities that other suppliers may provide FDDI interfaces.
It is possible to provide a hyperchannel mini-computer interface on the NSC7000 with the PB400 mini computer channel and thus the front end VAX could be connected. This would allow the hyperchannel itself to be removed. The case for doing this rests on a philosophy of unifying the access methods between the machines. From a user point of view it will not provide any benefits at this stage.
The cost of the Hyperchannel mini computer interface is £13,000 with 2 channels and £17,000 with 4 channels.
IBM has no FDDI interface available for the RS6000 although one is expected next year. Prices and technical details are not available.
Using the IBM optical interconnect channel on the RS6000 it is possible to connect the RS6000 to the NSC7000 with a PB290 board. The interface will take 4 backplane and 3 IO slots on the NSC7000 and provide 8 interfaces. This is clearly an overkill since 8 RS6000 are unlikely in the near future. Unfortunately single and less costly interfaces are not available. It may be worth delaying this item until the RS6000 interface from IBM become available.
The cost is £58,587.
The high cost rules out this option and it is recommended to wait for the IBM FDDI interface.
Comment.
This is the last progress report. Almost all the objectives of the project have been met and the reports have charted the triumphs and tribulations.
Whilst the progress in making services has been spectacularly successful management and performance aspects have been slower to develop. The collection of performance figures at sites was not a success but we now have figures collected centrally from the routers.
The status report is being discontinued as the information it contained is now available from the RIPE data base or the DNS.
Traffic in (bytes): > 1.5 Gb Traffic out (bytes): > 1.0 Gb
Estimated number of users: > 150
Progress and changes during the month:
Authoritative DNS. Incoming SMTP. Anonymous FTP (known to archie). 2Mbps JANET connection.
Expected progress in next month:
Outgoing SMTP.
Problems outstanding:
Telepac limits us to 1Mbps.
Some routing problems elsewhere meant we couldn't reach some places, whilst one could from the US.
Fatpipe availability.
Any other comments:
Our users are very happy.
Traffic:
No cumulative traffic records available with Sun router.
Estimated number of users: Unknown. Probably between 30 and 100.
Progress and changes during the month: Nothing major.
Expected progress in next month:
Trying X Windows to California.
Trying Ingres/NET link to Imperial.
Problems outstanding:
We are still relying on the DNS fudge that Sam dreamed up to allow SUNs to boot reliably. One day, someone will believe us.
Traffic: No stats kept
Estimated number of users: 10
Progress and changes during the month:
Now connected to Manchester router.
Expected progress in next month:
Nothing special.
Traffic:
Traffic in (bytes): 56M Traffic out (bytes): 68M Traffic in (records): 330k Traffic out (records): 460k
Estimated number of users: 25
Progress and changes during the month:
Little change. JANET outages on two occasions caused real problem locally, due to DNS timeouts (one outage coincided with a local power cut so many machines were trying to boot up and could not find their own names! This was solved by the simple expedient (BODGE!) of making all our DNS servers master for the empty ac.uk.ac.uk. domain.
Approval to join SMTP pilot, but cannot do this until DNS is fixed.
Expected progress in next month:
Still waiting for delegation of DNS domains. What must we do to get this done?
Problems outstanding:
Some concerns about security remain. Blanket port-blocking is best avoided, but we need tools to improve security by other means. In particular, a copy of the latest BSD version of rpc.mountd would be very useful as it can apparently do authentication based on rules rather than on lists of hosts. Looking at the inetd wrapper program mentioned by CERT, but in its standard form it depends on files in/etc which makes it unusable on a large site.
Any other comments:
We are getting some (unwanted) experience of NFS over 64k lines internally, as a 2M link-line to our second campus has not arrived on time. For one user at a time it is remarkably usable, but above that is ghastly!
Outbound traffic above inbound this month. This may be because I spent three days in Zurich, running X applications from Brunel!
Traffic: No figures.
Estimated number of users: > 30 and potentially lots more
Progress and changes during the month:
DNS up and running, primary name server running on dlsa.dl.ac.uk (148.79.80.2) - many thanks to Piete!
Expected progress in next month:
dl hosts converting to make use of dns
Problems outstanding:
None really, but the status of smtp after 1 November is a concern.
Traffic in (bytes): 903 M Traffic out (bytes): 803 M Traffic in (records): 9 M Traffic out (records): 10 M
Estimated number of users: Unknown - must be large
Progress and changes during the month:
A Cisco IGS was installed on the JANET link, and a 3Com Brouter on the Newcastle/Durham link. Both have performed well, with no problems. The Newcastle-Durham Brouter routes all IP traffic on that link, blocks DECNet and XNS, and bridges Pink Book.
It is intended to have full mutual backup between Newcastle and Durham across the link, but IP routing protocols seem not to be ideal even for such a simple setup.
The IP traffic is between three and five times as high as it was in May. IP and Grey Book mail are by far the biggest volumes of JANET traffic. However, when I tried to do a detailed comparison between the cisco router's view of the traffic and that of the SEEL CPSE on the same link there seemed to be absolutely no correspondence. I am investigating this further.
In the pre-shoestring era, our local Ethernet traffic was approximately 40% ip, 40% Pink-Book, 10% DECNet, and a trickle of other stuff. Now the local traffic is approximately 65% IP. We believe this is mainly due to the growth in IP rather than a diminution in other protocols.
Expected progress in next month:
Improved configuration of our routers, and some progress towards a simplified standard set of routing advice for our users.
Increased speed on our link to shoestring/JIPS.
Problems outstanding:
Even with the very simple configuration at Newcastle and Durham, the proper router configuration, and host configuration is remarkably complex.
For month of: September
Estimated number of users: 50-100
Progress and changes during the month: none
Expected progress in next month: DNS live (done, on 14/10/91)
Problems outstanding:
64K line not in service
Traffic in (bytes): S=2G7 Traffic out (bytes): S=2G5 Traffic in (records): S=27M E=29M Traffic out (records): S=15M E=17M
Estimated number of users: Even more
Progress and changes during the month: Nothing much
Expected progress in next month:
CC take over Cam
Problems outstanding:
NO JIPS MANAGED DNS !!!
Any other comments:
Cam site router due "real soon now".
Central Computing Division of the Rutherford Appleton Laboratory require high speed data network connections between a CRAY X-MP/416, an IBM 3090 600E, and an existing ethernet. Provision is required for an IBM RS6000 and a TOPAZ graphics system to be connected via FFDI at a later date.
The network connections must follow non-proprietary standards. The 100 Mbit/sec Fibre Distributed Data Interchange (FDDI) standard is the only option which meets the speed and standards requirements.
Internet Protocol (IP) must operate between the computers on the new network and to computers on the existing ethernet. There must be no restrictions on the protocols used over IP.
The FDDI network will connect to the existing ethernet network via an IP router.
Hardware and software supplied together with hardware and software already existing must run the acceptance tests specified below. Details of existing hardware and software can be obtained from Rutherford Appleton Laboratory.
The installation requirements and acceptance tests detailed below assume that NSC will provide a CRAY X-MP/416 connection, an IBM 3090 600E connection, a router connection to the existing local area ethernet network and a concentrator.
The FDDI network must conform to:
ISO 9314-3 Physical layer ISO 9314-1 Physical layer protocol ISO 9314-2 Media access control
The equipment will be expected to conform to ANSI X3T9.5/84-49 Station management when complete.
The use of IP across FDDI must conform to RFC 1188.
The router must conform to RFC 1009.
The supplier will be responsible for installing equipment in consultation with the Rutherford Laboratory.
Currently physical connection to the IBM can be at any time, initial testing can only be from 1800 to 1900 on a Thursday.
Currently physical connection and initial testing to the CRAY can only be between 1200 and 1230 on a Wednesday.
Connection and tests to the existing service ethernet can only take place on a Thursday between 0800 and 1000.
The supplier will install any required software on delivered equipment and assist in configuring existing computer hardware and software in cooperation with Rutherford Laboratory.
The equipment must pass acceptance tests as specified below.
The supplied equipment will be connected to the computers for which interfaces are provided and the router will be connected to a 'stub' ethernet with a test computer. The test computer will be an IBM PC running FTP Inc's PCTCP product. Rutherford Laboratory is prepared to provide the test computer.
If there are any failures during the acceptance tests Rutherford must be satisfied that the problem is solved and the particular test will be rerun.
The test will demonstrate IP connectivity between the IBM 3090 600E and the Cray X-MP/416 and the test IBM PC.
4.1.1 Test 1.
Terminal calls between the machines in both directions using TELNET will be demonstrated, but excluding calls to the IBM PC. Logging in and listing a file of 500Kbytes will be demonstrated between each pair of machines in each direction. There shall be no errors attributable to the network for the period of the test.
The test will be repeated with each of the four ethernet interfaces connected to the stub ethernet.
4.1.2 Test 2.
File transfers between each pair of machines in each direction using FTP will be demonstrated with files of 10Mbyte with no errors attributable to the network.
The test will be repeated with each of the four ethernet interfaces connected to the stub ethernet.
4.2 Part 2.
The Part 1 tests will be repeated with the router connected to the ethernet local area network and an IBM PC connected to the local area network. A connection to the stub ethernet with an IBM PC will remain. There will not be a requirement to test all the ethernet interfaces. The test will be extended to a PC on the ethernet local area network.
The connection of the equipment to the local area network and the tests must not adversely affect the local area network.
Members: T Amos, P Bryant, B Day, K Hoadley, T Kidd
Suggest NSC rack is put next to current NSC rack and moved if and when a second Cray arrives.
Suggest ALL NSC equipment is in same rack until acceptance tests are complete. After the tests the concentrator and router will be moved to telecoms area.
30 connection to rack is needed. Each of the three boxes appear to use 13 amp plugs into supplied distribution board in the rack.
7560 Bthu
FDDI cables for testing. FDDI cables for final position. May be same cables. Ethernet cable for testing. Ethernet cable for final position.
K Hoadley to advise.
See attached document.
If you must have the cheapest this is the router for you. So far it seems to have had little or no use in the UK.
PCROUTE is a public domain software product for an IBM PC. It only provides an IP router function and during operation no other function is possible. The code suggests that it can also be used as a bridge but there is no documentation.
Performance depends on the speed of the PC and whether code for the WD8003E ethernet board is used in preference to "packet driver" since this is not surprisingly more efficient that the more general purpose packet driver.
Reliability is excellent and in tests the system never crashed or exhibited errors that could not be attributed to external causes.
The system is written in assembly code in the interests of speed. The source is available. It is written as a set a macros and is not all that easy to understand.
Tests were only carried out with packet driver and SLIP no performance test were run and no failures were observed.
Setting up is simple with very few options, certainly there are no filtering facilities in which other products delight.
Initially a turbo 286 PC was used at 31M XT speed (12.6M AT speed). In this case using the PCTCP version of TN3270 would hang. Although this turned out to be the use of a high speed PC, the router did not show any faults. It also shows that PCTCP is more sensitive to errors than other end systems. It was unclear whether the router fault was due to the use of ancient BICC boards or some other reason.
PCROUTE is a software product for the IBM PC.
The system is written in assembler and requires recompilation to define the type of each interface. This is very straight forward and requires one well documented file to be edited. Turbo assembler is require.
Once compiled a configuration program must be run to define the IP characteristics of each port, the static routes, logging facilities and some other facilities.
The number of interfaces is limited to 6 or by the number of slots in the PC.
The number of SLIP ports is limit to 2 by the PC structure.
With some assembly code work these numbers could be raised but it seems unlikely that a PC has enough CPU power to make this worth while.
The following functions are supported:-
Ethernet (WD8003E board or packet driver), Starlan (WD8003S or SH), and SLIP are supported.
The hardware requirements are:
Any IBM PC. Any type of disk. Ethernet interface(s) Starlan interface(s) COM port(s) if SLIP is required
Keyboard and display are not required but elimination of the keyboard depends on the BIOS.
Version 2.
None known.
No support but author may be willing to help.
This is not supported. The easiest way to provide this would be with an X.25 board with a packet driver. This would be fairly easy to write.
Discussion.
Each interface is configured as follows:
Up to 265 static routes may be set up and in particular a default gateway route.
Various logging items can be sent to a BSD 4.2 system.
With SLIP large packets are fragmented with a maximum size of 1024. Unfortunately many IP packages do not reassemble packets and thus using PCROUTE for dial up will only work if the "window" is <= 996. PCROUTE will reassemble packets and hence two ethernets separated by two PCROUTEs running SLIP has no such restrictions.
PCROUTE has no facilities for modem control hence automatic dial up is not possible. Dial in is possible as long as the modem can break the call on loss of carrier.
When used with asynchronous modems it is essential to switch off any XON/XOFF flow control since IP needs a binary byte stream.
PCROUTE was tested with Tricom 48/24 MNP statistical modem at 2,400 bps line speed but with computer connections at 9,600 bps. There were no over runs observed.
Configuration is only by taking the system down and changing the tables and perhaps recompiling.
The only monitoring to the PC disc is at start up.
The only monitoring is by logging to a BSD 4.2 system.
Performance for ethernet depends on the speed of the IBM PC and whether packet driver is used. Quoted performances with WD8003E which have not been checked are:
4.77M PC .. to 1.8M depending of packet size 16M PC to 4.1M 4.77M PC SLIP will operate up to 19.2Kbps 10M PC SLIP will operate up to 56Kbps
With SLIP at 19,200 PCROUTE makes no noticeable effect on performance.
As an ethernet to ethernet router a PC connected on one side there was no noticeable effect as compared with the PC connected on the same ether net as the host. Tests were to an IBM 3090 with a 3272 (which interestingly is also a PC).
PCROUTE is excellent as a very low cost router where no sophisticated filtering is needed. The best performance of 4.1Mbps approaches the performance that can be expected from an ethernet so is likely to be satisfactory except in the most demanding situations.
PCROUTE is excellent for dial up or fixed asynchronous links between ethernets. Again where no filtering is needed.
The principal draw back with dial up is the lack of facilities for driving a dial up modem automatically. During the tests this was done with a command file which first used KERMIT to dial up and then initiate PCROUTE.
KA9Q is a set of IP facilities in a sub-operating system. In addition to providing router facility it also has server and client TELNET, FTP, and SMTP. and NNTP. Other services supported are BOOT (for automatic allocation of IP address assignment), NNTP, PING and use.
Ethernet, SLIP, AX25, nrs and ppp are supported.
Any IBM PC Any type of disk. K of memory Any type of display Keyboard.
The number of ethernet ports is limited by the number of slots in the PC. Ethernet boards 3C501 is directly supported. Packet driver is supported.
The number of SLIP ports is limit to 2 by the PC structure.
The following functions are supported:-
Configuring KA9Q is via a series of commands which may be in a file. There are a large number of commands with many subcommands. For use as a router a set of commands are required for each interface. The first (assign) to define the interface hardware, the second (IFCONFIG) to define the IP address and network mask and third (route) which allows for static routes.
Source is available but is not needed. It is written mainly in C but I did not look at it.
For reasons not stated the use of the 3c501 driver is not recommended and the use of packet driver is.
Performance is not as good as PCROUTE but there are no comparative figures. For use with SLIP this is not significant.
There are a wide range of monitoring aids. Each interface can be monitored for input, output or both. The whole packet or just the header can be examined. Statistics can be examined for each interface. The various tables can be looked at.
Proxi Arp is not supported and thus networks with complex subnetting will have problems. In simple cases this can be overcome with the "arp publish" command which allows an interface to respond to specific arp requests.
With SLIP large packets are fragmented with a maximum size of 256. Unfortunately many IP packages do not reassemble packets and thus using PK9Q for dial up will only work if the "window" is <= 212. PK9Q will reassemble packets and hence two ethernets separated by two PK9Qs running SLIP has no such restrictions.
PK9Q has facilities for modem control and autodialing.
KA9Q cannot be recommended as stand alone router in a service requirement between ethernets. It is more expensive in terms of the kit required, and has a lower performance. The lack of proxi arp could be a draw back in some network configurations.
For dial up KA9Q has the single but important advantage that it can drive autodial modems.
The product is attractive and valuable if a PC is to be used for some of the wide variety of tasks that it provides, however this would be unwise in a service environment as it would be all too easy to take out of service. Its wide range of tracing and monitoring facilities make it useful for "poking about" in a network.
Present: T Amos, P Bryant, B Day, K Hoadley, T Kidd
The NSC equipment will all be located permanently next to the existing NSC rack near the CRAY. T Amos will arrange for a suitable hole in a tile similar to the one for the existing rack. Action T Amos
There are no problems with the power supply. T Amos will arrange for 30 amp connection. Action T Amos
The dissipation of 7560 Bthu is not a problem.
Cables for testing will may be provided by NSC.
B Day is ordering 3 x 2 meter fibre pairs.
A suitable 10 meter AUI drop cable exists which will reach the existing service and development ethernets, this will be used for testing and service. B Day will retain this for the project. Action B Day
There is still some doubt as to the strategy to be adopted. There is doubt as to whether an interim address structure based on the existing C network will be used or a more radical one based on subnetting the current B network. K Hoadley will produce a proposal which will go to the IP group. Action K Hoadley
The acceptance test document will be updated as a result of discussion. Action P Bryant
This will be immediate. The optimistic target date for installation is January 1, 1992.
There will be no further meeting unless required by unforeseen disasters.
A requirements paper (attached) gives the need and specification for a high speed network.
In brief, fast connections are required between the CRAY, IBM 3090, RS6000 UNIX, the TOPAZ 2 video system and the ethernet local area network. The solution should follow standards and be capable of extension to encompass workstations and graphics facilities. Equipment must be for delivery in 1991.
The only product identified is the NSC 7000 with a PB130A board.
The only product is the NSC 7000 with a PB225 board.
The IBM 3172-2 will not be available until 1992 and would cost about £51,000 which is significantly more than for the NSC 7000 at £13,339.05. Note - all the NSC prices reflect a 15% discount so far negotiated.
An FDDI interface will not be available until next calendar year and there are no technical details available. A requisition for an RS6000 interface can be expected when details and costs are available and satisfactory.
The TOPAZ will be connected to FDDI at a cost of £6,800 which is the cost of a VME FDDI. This is the subject of a separate requisition.
A number of options have been identified. The NSC 6600 has been selected at £16,785.8. This is significantly cheaper than a CISCO AGS+ at £23,823. It would be possible to put a routing capability into the NSC 7000 at £10,136.65, but this had been rejected on the grounds that the expansion capacity in the NSC 7000 will be required for a possible second CRAY. If this expansion capacity is not retained then a second Cray interface would cost £61,803.50 since a separate NSC 7000 crate would be needed with all the attendant interfaces (this is an overestimate since a smaller crate would be possible).
There are a number of concentrator suppliers and two have been looked at in detail. The DEC concentrator costs £5,200 and the NSC concentrator costs £4,686.90. The NSC concentrator is preferred as there is advantage in having a minimum number of suppliers to ensure that there are few installation problems. There are no technical reasons for a preference.
The prices quoted by DEC and CISCO take account of the discounts we normally receive from these companies and further reductions seem unlikely.
A discount of 15% has been negotiated with NSC but there may be scope for improving on this.
Network services are vital to SERC and our users demand ever increasing speeds and facilities. On site the Internet Protocols have been introduced with success to help meet this need.
Rutherford has taken part in and supported the Joint Network Team's SHOESTRING project to provide a pilot Internet Protocol network for the UK academic community. The use of this technology has become common across the world and provides advantages particularly for international communications as well as on the Rutherford site.
SHOESTRING started in late 1990 and has lasted until late 1991 when a service (Janet IP Service or JIP) was launched. Rutherford has provided about a man year of effort divided between technical and organisational aspects of the work. In particular the evaluation and control of "routers" and performance aspects of the network have been our main contribution.
A service has now been launched after a very successful project. The service is already showing considerable benefits to the community and in particular SERC activities. Rutherford will continue to take an active part in the development of JIPS although at a rather lower level and slanted towards its exploitation by SERC.
1. The UK Information Systems Committee who fund UK academic networking have decided not to fund EARN in 1992. Its funding support was always intended to be temporary and it had funded EARN for about twice as long as it initially indicated. ISC has been consistent and generous and this should be recognised as such by the EARN Board.
2. JANET (as a network and not a country) wishes to maintain its connectivity with EARN and is negotiating with EARN to this end. The UK assume the EARN community will wish to retain its connectivity to the JANET community and will encourage a positive approach to these negotiations.
3. If the UK wishes to remain a Full Country member of the EARN Association its subscription will have too be funded from a new source.
4. The UK is in the same position as Germany and Spain (and perhaps others) and is not unique.
Dear Keith,
Thank you for explaining the JFIT Director post at our recent meeting which was most useful. It is clearly a challenging and important position. I have to say that if the job is to be done properly it would need 100% time and dedication and to mind would suffer from being led my someone dividing their time between jobs and sites.
I have been exploring the conditions under which I could undertake the job and this has been difficult as our personnel department does not seem to have met a proposition for a part time temporary grade 6 before. It is unclear what sort of salary I would get considering the half time nature of the position and that the starting point for grade 6 is below my current salary! I am also concerned that the Department would be unable replace my time with the current bars on recruitment and so damage the demanding programme of my group.
Unfortunately I am overseas until next Monday and so I am unable to complete my investigation to see if a package acceptable to yourself, my Division, and myself can be achieved. At this stage I have to say that I have doubts as to whether this could be achieved particularly as I would want to see some long term career advancement.
I am sorry that I am unable to be positive but I really do think that the task needs a full time director who will not be distracted by other tasks as I would be. I hope you will find a suitable candidate for the post.
Yours sincerely,
Paul Bryant.
I presented the UK paper on funding of RIPE which opposed the intention of EARN to fund the RIPE Network Control Centre to about 85 KECU. This proposal was only supported by the UK and opposed by all other countries. Thus EARN will fund RIPE subject to some safeguards. The funding is reported to be about 1/3 of the RIPE requirement. Any funding in subsequent years is subject to review.
I presented the UK view on the budget and had it minuted. This stated that the UK would not fund EARN in 1992 and suggested the UK EARN director should seek alternative sources of funding. On the budget vote only the UK and Germany voted against it. I understand that Germany objected to the size of the budget but intend to subscribe. The UK requested minute is appended. Surprisingly, Kees Neggers did not share the UK views and was surprised that the UK had not provided an alternative budget proposal.
The President took the view that as EARN required 6 months notice to leave EARN that the UK would subscribe to EARN up to 6 months after giving notice to leave EARN. There was a view expressed that as the UK did not intend to pay then they had a moral duty to cease using EARN on January 1, 1992.
The Board took the view that any resolution of the UK subscription issue must not undermine EARN.
There was a discussion on various papers on the future of EARN. The Executive was instructed to investigate a possible merger between RARE and EARN. This has been suggested in papers from Netherlands and from Williams and Carpenter of CERN. It was emphasised that this must result in a radically different organisation than either of the existing ones and not some form of take over. The Executive has also been instructed to investigate positively its relationship with the proposed RARE Operational Unit with a view to deciding whether EARN should subscribe to services, be a contractor or what relationship there should be.
UK comments in the EARN minutes
1. The UK Information Systems Committee who fund UK academic networking have decided not to fund EARN in 1992. Its funding support was always intended to be temporary and it had funded EARN for about twice as long as it initially indicated. ISC has been consistent and generous and this should be recognised as such by the EARN Board.
2. JANET (as a network and not a country) wishes to maintain its connectivity with EARN and is negotiating with EARN to this end. The UK assume the EARN community will wish to retain its connectivity to the JANET community and will encourage a positive approach to these negotiations.
3. If the UK wishes to remain a Full Country member of the EARN Association its subscription will have too be funded from a new source.
4. The UK is in the same position as Germany and Spain (and perhaps others) and is not unique.
James.
Rene Florizoone, the Belgium EARN deputy director approached me as he has a note from you via Paul Van-Binst which suggests an EARN connection between UKACRL and the Belgium international node using the NJE/X.25.
Unfortunately there are a number of reasons why this is not possible.
Firstly, Belgium does not intend to operate NJE/X.25.
Secondly, the EARN Regionalisation Project defines how EARN nodes are connected (which I believe I have previously drawn to your attention). This would not envisage a link between Belgium and the UK since Belgium is not in the UK Core Region. I understand Belgium is moving from the French Region to the Dutch Region. Thus, the way to improve the performance is to improve the connection between the UK Core Region and the Dutch Core Region. As Holland does not offer a NJE/X.25 connection, this can only be achieved by a VMNET link in line with the EARN Regionalisation Project. Such a link would be welcomed.
I have further investigated the connection between France and Germany. I now understand that this connection is, contrary to my previous comments, SNA and likely to remain so.
You asked whether we could set up a GBOX link to Austria. The reply is that Austria would not be willing to set up such a connection as they do not wish to run NJE/X.25 code. A VMNET link would be welcome as both countries are Core Countries.
At the recent Board of Directors meeting and Network Operations Group meeting I am afraid that the UK was alone in wishing to run E or G-BOX code.
Paul.
The detailed accounts will be in French Francs.
The accounting codes and classification of expenditures and incomes will conform to the existing codes used in the EARN budget (see sample summary accounts appended). Can this be done?
There will be a summary and simplified version of the accounts which must be easily identified with the budget. In addition it is essential that all summary figures in FF can be identified in the detailed accounts.
There will two versions of the summary accounts. The first will be entirely in French Francs, the second will be the same figures in ECUs.
The summary will include:
Expenditure and income. The table will include the budget, the expenditure/income, and the previous years expenditure/income. Unbudgeted expenditure and income will be identified. Accrued expenditure and income will be identified in the capital assets.
Assets. Assets at the start and end of the year will be summarised. There will be an estimate of accrued interest. We need to decide whether non-financial assets will be shown.
An example of the summary accounts is shown below.
The figures need checking particularly with respect to the FF/ECU conversion. SUMMARY OF EARN ACCOUNTS
Summary accounts in French Francs.
Expenditure Budget(1) Actual 1992 Actual 1991
000 FF 000 FF 000 FF
======================================================================
1 PRESIDENTIAL OFFICE
1.1.2 Salaries 112 112 107
1.2 Travels 182 182 128
TOTAL 294 294 235
======================================================================
2 EARN OFFICE
2.1 Salaries
2.1.1 Manager 679 639 690
2.1.2 Secretary 217 182 -(2)
2.2 Travel 147 105 123
2.3 Phone and postage 70 112 83
2.49 Miscellaneous 105 91 78
TOTAL 1218 1127 974
======================================================================
3 EARN STAFF
3.1.1 Salaries 1470 1421 891
3.1.3 One salary paid 308 308 -
by EARN France
3.2 Travel 294 336 238
3.49 Miscellaneous 56 28 23
TOTAL 2128 2093 1152
======================================================================
4 OTHER EXPENSES
4.52.2 RARE fee 7 7 7
4.2 Travel
4.2.1 EXEC meetings 231 231 232
4.2.2 Other meetings 231 140 45
4.10 Printing 147 133 79
4.11 Audit, insurance 112 112 101
4.20 Dublin office - - 164
4.49 Miscellaneous 56 28 23
TOTAL 784 693 651
======================================================================
5 LINES
5.7 Line to USA 560 616 540
5.8 National lines(3)(4) 9800 9800 8981
TOTAL 10360 10461 9521
======================================================================
6 DEVELOPMENT
6.1 Additional staff 630 0 -
6.6 X.25 Backbone - - 601
6.52.1 COSINE cooperation 1050 98 0
6.12 Other development costs 490 378 213
TOTALS 2170 476 817
======================================================================
UNBUDGETED EXPENSES
Ripe NCC - 609 0
Surplus - 129 2096
TOTAL - 609 2096
======================================================================
TOTAL 16954 15624 15465
======================================================================
(1) The budget is converted to FF at the rate as of 31/12/90 of 7 FF to 1 ECU ??????.
(2) This item is included in 2.1.1
(3) This item will be removed from the 1992 budget
(4) Notional.
Income Budget Actual 1991 Actual 1990
000 FF 000 FF 000 FF
======================================================================
51.51.2 DEC contribution 415
51.52.1 COSINE contribution 1050 0 0
51.54 Country contributions 5516 5516 5836
51.54.3 Staff member paid 308 308
by EARN France(4)
51.55 Backbone compensation 233
54.53.4 Interest 280 0 0
57.8 International lines(3)(4) 9800 9800 8981
UNBUDGETED INCOME
======================================================================
TOTAL 16954 15624 15465
======================================================================
EARN FINANCIAL ASSETS
1991 1990
000 FF 000 FF
SICAV investments ? 4779(1)
Barclays Paris ? 340
Barclays London ? 471
Accrued income ? 1397
Accrued expenditure ? 1914-
======================================================================
TOTAL ? 5073
======================================================================
(1) At cost. The estimated interest at 31/12/1990 is 350 KFF
The estimated interest at 31/12/1991 is ? KFF
SUMMARY OF EARN ACCOUNTS
Summary accounts in ECU.
Expenditure Budget Actual1992 Actual 1991
000 ECU 000 ECU 000 ECU
======================================================================
1 PRESIDENTIAL OFFICE
1.1.2 Salaries 16 16 15
1.2 Travels 26 26 18
TOTAL 42 42 33
======================================================================
2 EARN OFFICE
2.1 Salaries
2.1.1 Manager 97 91 99
2.1.2 Secretary 31 26 -(1)
2.2 Travel 21 15 18
2.3 Phone and postage 10 16 12
2.49 Miscellaneous 15 13 11
TOTAL 174 161 140
======================================================================
3 EARN STAFF
3.1.1 Salaries 210 203 127
3.1.3 One salary 44 44 -
paid by EARN France
3.2 Travel 42 48 34
3.49 Miscellaneous 8 4 4
TOTAL 304 299 165
======================================================================
4 OTHER EXPENSES
4.52.2 RARE fee 1 1 1
4.2 Travel
4.2.1 EXEC meetings 33 38 33
4.2.2 Other meetings 33 20 6
4.10 Printing 21 19 11
4.11 Audit, insurance 16 17 14
4.20 Dublin office - - 23
4.49 Miscellaneous 8 4 3
TOTAL 112 99 91
======================================================================
5 LINES
5.7 Line to USA 80 88 77
5.8 National lines(2) 1400 1400 1283
TOTAL 1480 1488 1360
======================================================================
6 DEVELOPMENT
6.1 Additional staff 90 0 -
6.6 X.25 Backbone - - 86
6.52.1 COSINE cooperation 150 14 0
6.12 Other development costs 70 54 31
TOTALS 310 68 117
======================================================================
UNBUDGETED EXPENSES
Ripe NCC - 87 0
Surplus - 12- 299
TOTAL - 69 299
======================================================================
TOTAL 2422 2232 2209
======================================================================
(1) This item is included in 2.1.1
(2) This item will be removed from the 1992 budget
(3) Notional.
Income Budget Actual1991Actual 1990
000 ECU 000 ECU 000 ECU
======================================================================
51.51.2 DEC contribution - - 59
51.52.1 COSINE contribution 150 0 0
51.54 Country contributions 788 788 847
51.54.3 Staff member paid 44 44 -
by EARN France(3)
51.55 Backbone compensation - - 33
54.53.4 Interest 40 0 0
57.8 International lines(2)(3) 1400 1400 1283
UNBUDGETED INCOME
======================================================================
TOTAL 2422 2232 2209
======================================================================
EARN FINANCIAL ASSETS
1991 1990
SICAV investments ? 683(1)
Barclays Paris ? 49
Barclays London ? 67
Accrued income ? 200
Accrued expenditure ? 273-
======================================================================
TOTAL ? 725
======================================================================
(1) At cost. The estimated interest at 31/12/1990 is 50 KECU
The estimated interest at 31/12/1991 is ? KECU
(2) Assets for 1990 are converted to ECU at the rate ruling on 31/12/1990 of 7 FF to 1 ECU.
(3) Assets for 1991 are converted to ECU at the rate ruling 31/12/1991 of 7 FF to 1 ECU.
Distribute: J Barlow, P Bryant, T Daniels, J Hutton
1 Minutes of meeting held 10 October 1991.
2 Matters arising
3 Recent performance
4 EARN regionalisation project
5 Current position of renegotiation of relations with EARN
6 EARN subscription for 1992
7 Date of next meeting.
I met the EARN auditors, KPMG, with Hans yesterday and we made good progress and I would like to report on the current plans and invite comment.
We decided that as before we will have two documents - the official audit and the rather more understandable version.
In the past the figures have been difficult to understand with the confusion over the FF and ECU. Thus the principle tables (income/expenditure 1991, budget 1991 and comparison with 1990 plus the assets) will be repeated - once in FF and once in ECU. Much of the detail in the official accounts will be left out and introduced into this table.
There will be a full list of the country contributions showing the expected contribution and the received contribution thus identifying any under and over payments. This is needed to fulfil our decision to carry forward any over or under payments. This table will be in FF since it will need to be accurate.
Fortunately we will not have the financial gymnastics we had last year with the DEC refund.
The figures will have a few explanations. For example the accrued expenditure will draw attention to the expected payment to INET.
The duplication of figures in ECU and FF will allow us to move to working completely in FF for 1993 but this will be the subject of a proposal and discussion at a later date.
We now understand that the accounting codes used in the previous years official accounts are standard (ISO? :-) ) at least for France. I now understand that the UK has a similar set of codes. It is unclear whether these are the same as the French ones but I am investigating. It also appears that organisations use these codes for constructing their accounting schemes and there seems to be allowances for sub-coding for the private use of the organisation. In the light of the blinding revelation it would appear that the way we have developed our EARN accounting codes is all wrong and we should have started with these "standard" codes and worked on from their. Now that this point is understood there may well be merit is reconsidering our codes in the interests of making the accounting process easier to undertake and easier to work with. I may well introduce a paper to the appropriate executive meeting when I understand the issues more clearly. The way I would do this is to give each of our income and expenditure items one of these new codes for the 1993 budget while retaining the old ones. In 1994 (if we last that long) we would drop the old codes.
In short there may be merit in moving to working completely in FF and standard codes.
Perhaps your worthy treasurer and his antecedents should apologise for not having the relevant expertise and also our worthy auditors should have drawn these issues to our attention.
We have a time table for the production of the accounts as follows. February 15. Version 1 of draft audit for consideration by the Manager and Treasurer. February 29. Version 2 of draft audit for the Executive. March 26. Consideration of version 2 by the Executive and approval to submit to the Board of Directors. May 10. Version 3 of the draft audit will be presented to the BOD for approval.
We discussed our accounting methods with the auditors. Currently we use a spread sheet and my view was that we should use an accounting package. The issue hinges on whether the use of a package will save or absorb effort. This is turn hinges on the need for training of staff to operate a package and also on the complexity of the EARN book keeping.
The EARN financial affairs are relatively simple with few entries. In addition there now exist a utility to extract the quarterly figures we require. A new system would require our staff be have some elementary knowledge on double entry book keeping and also some expertise in computing with respect to an accounting package. In my examination of the problem I came to the conclusion that although a package could be used it would not be ideal for our purposes since they are normally geared to organisation buying and selling goods rather than services but none the less there is no real problem why our countries could not be regarded in accounting terms as customers. Talking to Hans it is clear that he believes that an accounting package will absorb more effort than it saves. That may well be true. This could change if we decide to charge by the services we offer rather than by a subscription. It also assumes that our financial affairs do not become more complex - for example if our VAT status were to change or we decided not to contract out the employment details of our staff. Thus for the moment it seems we should continue with the current arrangements although I find this a little disappointing.
Paul.
Dear John,
Thank you for a copy of your most interesting paper.
My wish is that the recommendations had been adopted 15 years ago when we were setting up SERCNET which later became the academic X.25 network JANET. I have a couple of points to raise.
1. I feel that in recommendation 4 the rules for allocating a DNIC are a little restrictive and perhaps complex. I would have liked to have seen two classes of network which would be allocated DNICS -
- A network which needs or intends to connect by X.75 to one or more networks with existing DNIC class networks.
- A network which intends to form a set of networks interconnected by X.75 with other networks.
I do not see that the numbering regulations should be related to any payment considerations - that is a matter for negotiation between networks.
I envisage that there may be a case for an organisation or set of organisations to set up a set of interconnected networks which may well be disjoint from the current set. For example - the academic community or the banks. There may well be merit ensuring that the address spaces are disjoint to allow for interconnection at a latter date.
2. I am a little unclear on the need for a European or global class of DNIC. From a technical point of view, where the DNIC comes from is of no interest - to my mind the allocation of DNIC ranges to countries is just for the convenience of allocation (or should be). From a charging point of view I have difficulty understanding why, given a DNIC, an operator should levy a different charge depending on the destination country. Surely the operator should charge on the basis of the real cost which is cost of making the call to the first X.75 gateway. If the second operator wants to charge depending on the distance/country/or whatever, then he gets this information from his switches and no doubt relays it back to the originating operator for recharging.
With any supplier of DNICS, common regulations are desirable. In addition, I would not like the allocation of DNICS to become (or rather remain) a political or regulatory weapon. Political or regulatory control should be overt by denial of connection or third party traffic bans and not by restrictions on allocation of resources apart from those necessary to preserve scarce resources.
3 Although not opposed to the creation of a country code EC I think the arguments are a bit thin. There is a danger that other sets of countries or even parts of countries may wish to have country codes. This could become a growth industry - Scotland, South East Asia, where does it end? This could cause confusion. We must also remember that with only two characters a country code is a scarce resource. If you do go this way make sure there are good rules for further allocations - for example all the country codes in the new area vanish.
4 I applaud having a single space for ADMDs and even PRMDs.
I am pleased that you found the RFCs useful. It is worth noting that the European academics have been forced to follow the protocols defined in the RFCs - the so called IP protocols. This is because they have been widely available and cheaply available. This is in contrast to the rather slow to emerge ISO offerings. The decision making for IP standards has been fairly pragmatic and thus rapid. This clearly has allowed rapid progress but has led to a number of problems and limitations - for example the IP address space is exhausted. None the less the comparison is stark.
Yours sincerely,
Paul Bryant.
EARN, in BOD5 91, states the conditions under which sanctions may be taken against an EARN country. The EARN president along with the EARN Executive decide on the specific sanctions. Sanctions may be imposed in the event of a country being in default with the payment of its EARN subscription. This paper proposes sanctions for EARN to adopt.
With any sanctions it is necessary to protect the service to other countries. This may require steps to re-route traffic from non-defaulting counties. It may require EARN to be in a position to take rapid steps to remove a country from the network if the sanctions being taken are in danger of damaging services to other countries.
At any stage should a country make a full payment then sanctions will immediately be dropped.
A timetable for imposing sanctions will be determined in each case on its merits.
Other NJE networks, in particular BITNET, should be asked to support any EARN sanctions. Support should prevent the affect of sanctions being undermined by allowing the use of alternative methods of passing a country's traffic which would use these networks.
Countries which have not paid at least 90% by September 1 may be sent letters by the EARN President requesting payment and informing them that they are in default and that sanctions may be imposed. This is in fulfilment of item 2 and 3 of BOD5 91.
At the Autumn Board of Directors Meeting the list of defaulters will be presented. At this stage the Board may take account of any special circumstances and instruct the Executive to take specific actions. On November 1 the EARN president informs the country that if payment is not received then the sanctions may be imposed. This is in fulfilment of item 4 of BOD5 91.
Support services by EARN staff will be withdrawn. This would cover LISTSERV. It would not cover updating of routing tables. Advice and support would only be provided where the service to other countries is affected.
Entries in mailer tables would be removed. These are- DOMAIN NAMES, MAILER NAMES and XMAILER NAMES. The effect will be some mail to the country will be prevented. Some services provided to other countries by any LISTSERV in the country would have to be relocated. It would be not permitted for countries to include the defaulting countries in their tables.
Members from defaulting countries will be removed from LISTSERV lists.
The country will be removed from the EARN routing tables and updating NETSERV tables terminated. Traffic to the country would reduce as tables become out of date and traffic to the country would rapidly stop.
Traffic originating or terminating in the defaulting country would not be carried by EARN. The other NJE networks, in particular BITNET should be asked to take similar action.
Steps required for the formal expulsion of the country will commence as per BOD5 91 items 6 to 11.