EARN BOD 01 84

EARN Document

Title:      Minutes of Board of Directors meeting February 20, 1984

Author(s):  O H Martin

Date:       1984/3/14

Committee:  Board of Directors

Document:   BOD1 84 EARN-MIN – LISTSERV@UKACRL

Revision:   0

Supersedes:

Status:     Final

Maintainer: Board of Directors

Access:     Board of Directors

————————————————————————

INTRODUCTION

Welcome (D. Lord)

On  behalf of Cern D. Lord welcomed the participants to this  first  EARN meeting.

EARN Objectives (H. Budd/IBM)

1. Budd briefly reminded the meeting what the IBM goals were, namely  to help   the   European  Academic  and  Research  Community   establish   a communications  network  similar  to  BITNET in  the  United  States  and therefore  to  facilitate the information flow between the  two  academic communications.   The aim of IBM is to give the initial push and the hope is  that  this  will allow EARN to get off the ground  much  faster  than BITNET. IBM’s involvement in EARN is to make the Backbone Network and  to bear the cost of the communications equipment.

EARN Status (A. Auroux/IBM)

Status of EARN Backbone:

1. EARN phase 1 now complete:

City University of New York (CUNY) <—> IBM Scientific Center (Rome)

2. EARN phase 2, completion expected end march 84:

* ROME <———> IBM Scientific Center (HAIFA):

* ROME <———> CERN (Geneva):

* Geneva <——-> GSI (Darmstadt):

* Geneva <——-> HEC (Paris):

3. EARN phase 3, completion expected April-May 84:

* Geneva <———> Rutherford Appleton Laboratory (RAL-London):

* RAL <————> University College (Dublin):

* Paris <———-> Stockholm University (QZ):

* ROME <———–> IBM Scientific Center (Madrid):

* Geneva <———> RAL (London) *** completion date unknown ***:

EARN Status by country:

1. Switzerland:  Dial-up terminal connections initially, for  the  Swiss Universities  but a number of leased lines connection will  exist  before end 84.

2. Germany: 24 Universities connected to GSI (Darmstadt).

3. Israel: 5 Nodes planned in Haifa and Tel Aviv.

4. France: 3 Nodes in Paris. University of Montpellier and the  existing French University Network to be connected later this year.

5. Great  Britain:  The  RAL Node will act as a  gateway  to  the  Joint Academic Network (JANET), a private X25 network, with over 200 computers, running  over  leased  lines.   RAL will also act as a  transit  node  to University College Dublin and from there to University of Cork.

6. Sweden: The University of Stockholm node will also act as a gateway to the Swedish University Network (SUNET), an X25 based Network running over the Public Packet Switched Network and connecting the 60 or so  computers belonging to the 6 University regions.

7. Spain: 3 Universities (2 in Madrid, 1 in Barcelona).

Most  European  Countries  are expected to be connected  before  end  84, meaning  that  by  then several hundred computers  will  have  direct  or indirect access to EARN and hence to BITNET in the US.

BITNET (IRA FUCHS/CUNY)

BITNET STATUS

BITNET  which was started in May 1981 by the City University of  New  York (CUNY)  has now grown into a 150 Nodes Network located at some 50  sites. BITNET  is  an  RSCS  based Network providing  Mail,  File  Transfer  and interactive  message  facilities.    Given the choice  of  higher  level protocols  which  users may use, the capabilities to  send  and  receive messages  interactively is considered to be a very essential feature  of such  an heterogeneous network.   A sizeable fraction of  the  computers connected  to  BITNET are non-IBM computers some of which  running  full RSCS emulation software.

Please  refer  to  Appendix  A for more  information  on  RSCS  emulation software.

With  the  existing  US topology the maximum  number  of  “hops”  between farthest  apart  nodes is between 8 and 10.   BITNET does not  cater  for interactive  Terminal  Traffic  although this  is  possible  between  IBM mainframes  using the Passthru Program Product also known as  PVM.    The use of Passthru implies the existence of either dedicated leased lines or multiport  modems  up  to the computer the user  wishes  to  establish  a session on.

The  University  of Maine has, however, developed code  which  eliminates most  of the above requirements by making use of the Interactive  Message facility  to carry the terminal traffic over the RSCS line.    With  that code the only requirement is to have PVM installed on both ends.   Doubts regarding  this  approach were expressed, as Full  Screen  Terminals  may generate  lot  of  traffic,  which  may  in  turn  seriously  impact  the performance of the RSCS line as Interactive Messages are pre-empting File Transfers;  also the users expectations are obviously somewhat  different with respect to File Transfer or Interactive response times.

Criteria  for  Joining BITNET:  Install and pay for a leased  line  to  a convenient node, allow at least one other leased line to another node, to allow traffic to transit at no charge;  agreement to not use the  network for commercial purposes.

Obviously the actual commitment made by some of the major switching nodes like  CUNY,  University of Berkeley or Pennsylvania State  University  is more significant as it implies more 3705 ports, adequate amount of  Spool Space, CPU cycles, etc.

Statistics  on the usage of the Network are collected by  the  individual nodes  and  sent  to  the University of YALE who  has  developed  a  data reduction  program.   As it standards today the average line  utilisation is still fairly low (ie between 10 and 20%), other details are not  known (e.g. peak values, file size, etc.).

Protocols:

In  addition to the standard IBM facilities available under VM  for  Mail and  File  transfer,  there are a number of other Mail  systems  in  use, originating from various places (e.g. Cornell, Harvard, Stanford, etc).

The  recommended  standard for use over BITNET is  the  ARPANET  standard RFC822.    The ‘Netdata’ format used by standard IBM facilities does  not conform  with  the  RFC 822 standard and is hence not  usable  over  most Gateways.

Columbia University has developed and is distributing the ‘MAILER’, a  VM only  product,  which understands the RFC822  headers,  the  distribution lists and the topology of the network such that there is never more  than one copy of a Mail File leaving a Node on a given link.

BITNET Gateways

BITNET  <—>  VNET  Gateway:   VNET,  the  internal  IBM  Network,  with approximately 1200 nodes on it, is still growing at the rate of one  node a  week.    The  gateway  software which  should  enable  some  level  of communication  between  the BITNET  and VNET user  communities  has  been designed and written at CUNY and is now undergoing certification by  IBM.   H  Budd pointed out that the decision of having a VNET gateway on  BITNET had  not  been taken by IBM yet, should such a decision be taken  it  was however likely that there would also be a VNET gateway on EARN.

The  Gateway  software has been tested between CUNYVM and  the  Cambridge Scientific Enter, the main design aspects are the follows:

1. Gateway Nodes control the communication path between VNET and BITNET.

2. Each Network controls access-security.

3. No modifications required to other than the Gateway Nodes.

4. Two level addressing, since no change required to routing  tables  in other than the Gateway Nodes.

The communication is asymmetrical, although it does not have to be,  with the  VNET  user  having to initiate the call;  this  decision  was  taken primarily  because of the different nature of the two  user  communities, there  are  thousands of students on BITNET!   Prior  to  establishing  a communication a ‘path’ or ‘virtual circuit’ has to be set-up, there are a number  of  commands  available  to set-up,  one  time,  fixed  time  or permanent circuits.   Finally it was also pointed out that the  existing IBM  nodes on BITNET (e.g. Yorktown Heights) were not using the  gateway software and that access to BITNET was restricted to a very small number of users.

BITNET  <—>  ARPANET Gateway:  The University of  Berkeley  gateway  to ARPANET is difficult to use but by the time EARN comes up, the University of  Wisconsin  gateway  to  ARPANET, which is  easier  to  use  and  well documented,  in  addition  to being only one ‘hop’  away  from  CUNY,  is expected to be operational.

Gateways  to  other Networks:  The interface between BITNET and  CSNET  a network  linking  the  Computer  Science  Departments  of  the  major  US Universities and a few other Universities abroad caters for File and Mail transfer  but there is no provision for interactive messages  because  of protocol incompatibilities.

A  large  DECNET network, called CCNET, is  accessible  through  Columbia University  same status as above with no interactive capabilities  except ‘FINGER’ a QUERY type facility.

There are also gateways to USENET giving access to a very large number of Unix  UUCP  Systems  (ie  over 1000), and  MAILNET  (same  technology  as PHONENET with dial-up connection).

BITNET ORGANISATION AND ADMINISTRATION

Organisation:

One  representative  per site, Two meetings a year  hosted  by  members, decisions  are taken by consensus not by majority.   There is an  agreed set  of rules (e.g. max. file size, etc) and several months  notice  are required should a node decide to leave BITNET, a situation which has not occurred so far.

Administration:

1. The  Executive  Committee is a body of six  people  talking  together frequently in order to agree on ways to resolve problems.

2. Systems  Group,  meeting  twice a  year,  concerned  with  protocols, gateways, etc.

3. User  Services, meeting twice a year, concerned  with  Documentation, User Interfaces, Feedback from End Users, etc.

Billing:

There is no billing between BITNET  and both CSNET and ARPANET.   In  the case of MAILNET, the User Community has found it so profitable to have  a connection  to  BITNET  that  it has accepted to bear  the  cost  of  all communications  both  ways, whether this policy will be  maintained  when EARN is connected to BITNET is still not decided.

BITNET SERVICES

A  VM  Service  Machine  called ‘BITSERVE’  is  providing  the  following services to the BITNET community:

1. Name Server

2. Services Directory

3. File Server

4. Bulletin Board (Community Bulletin Board System – CBBS)

The BITSERVE machine uses VSAM to perform keyword searches in the various subdirectories and was said to be both fast and efficient.   It was  also indicated  that answer to queries were normally sent back as  Interactive Message(s) up to a predefined threshold, which when reached triggers  the sending  of a short message recommending the use of the Sendfile  command instead.

Although  ‘BITSERVE’ will also run at ROME, Ira Fuchs expressed the  view that the directories would preferably be kept at CUNY until such time  as adequate  mechanisms are implemented to allow the ROME and  CUNY  Service Machines to automate the exchange of information.   There is for  example a project to get the BITNET and CSNET Name Servers to talk together.

Restrictions  on Usage:  The limitations on file size which  were  agreed when  BITNET  was  set-up are no longer deemed  adequate  (ie  <300MBytes between 8am and 8pm Local Time, and 3MBytes outside) and the problem will be  redressed  at next Director’s meeting.   This problem  is  especially critical  on the transatlantic line, hence a tentative solution to it  is being  developed jointly by ROME and CUNY (ie breaking large  files  into pieces or RSCS enhancements to support multiple Output Streams).

Commercial Traffic (e.g. Administrative Use is not commercial, but fixes to Software Products cannot be distributed over BITNET).

Once  a  new connection has been established there is no control  of  the actual usage which is made out of it.   I Fuchs admitted that things were becoming rather more complex as the fourth generation of BITNET users was not emerging.

Future Objectives

1. Investigate the use of protocols other than RSCS/NJE (e.g. TCPIP or     other Full Duplex protocols), X25 not considered at this point     because of the packetisation overhead!).

2. Provide adequate Conferencing Facilities (e.g. use of the GILT     protocol).

EARN

EARN User Group

The proposal to set up a User Group in order to co-ordinate the necessary effort  to  get EARN off the ground was immediately accepted by  all  the participants.    Dr  Hultsch  mentioned that the  SEAS  organisation  was willing  to allocate some effort to EARN, for example as a SEAS  project.   Although all participants were grateful to SEAS, it was in general agreed that  it was preferable not to set up any privileged  relationships  with other  User  Groups.    H  Budd stated  that  IBM  would  feel  extremely uncomfortable  about  it,  I Fuchs explained that  BITNET  had  carefully avoided special relations with the SHARE organisation, even though out of convenience some meetings had taken place art the same location and  time as SHARE meetings.   Finally P Bryant reminded the participants that  if EARN  was  to encompass the existing subnetworks (e.g. JANET  or  SUNET) then there would be a vast majority of non-IBM systems connected to what one  might  then  call  a  ‘virtual network’  and  hence  that  a  close association with SEAS could do more harm than good.

The following organisational structure was then adopted:

1. EARN Association, de facto members being the Nodes with one  vote  at the General Assembly to be held once a year.

2. Board  of Directors (EARN-BOD) with one  representative  per  country either  elected  or nominated by their country, will meet twice  a  year.   Country  representatives to say for a minimum of one year.    This  board will deal with:

–  Authorisation:

–  Contacts with the PTT’s:

–  Legal aspects:

–  Usage restrictions:

–  Gateways to other Networks:

Because of the international status of CERN it was agreed to treat it  as a  country,  and  that the same rule would also apply in  the  future  to similar organisations.

The  request  made  by IBM to be invited to  the  EARN-BOD  meetings  was accepted and it was also agreed to exchange invitations between the  EARN and BITNET BOD’s.

3. EARN  Technical  Meeting,  with  no  limitation  of  the  number   of participants  from  a  particular node or  country.    The  criteria  for membership is interest and willingness to make active contribution.   The Technical  Meeting  which  is  responsible to  the  EARN-BOD,  will  also interact closely with it.   The meeting will have a project structure and will initially concern itself with the following subjects:

–  Protocols:

–  Reliability:

–  Operations, Reporting on network load and usage, etc:

–  End User Facilities:

–  Technical problems related to gateways with other networks:

Prior  to being approved two aspects of this structure were discussed  in detail:

–   With  one member per country and ALL European Countries  expected  to join EARN the BOD may become too large, it was however agreed that it was difficult  to  see,  at  lease  initially, how  one  could  have  a  more restricted  membership.    There was also some fear that,  for  budgetary reasons,  some  Universities may not have the necessary resources  to  be represented at every BOD meeting, what would one then do ab out it?

–   Regarding  the  participation to Technical Meetings  it  was  finally agreed  that  there was no good reason to restrict it to one  person  per node.    It  was also pointed out that because of the Network  which  was being  created very useful co-operation and contributions could  be  made even without attending the meetings.

At  that  point  the participants were reminded that EARN  will  only  be concerned  with  the  Reliability of the Network and  NOT  with  SECURITY Aspects.    Responsibility  for that remains with the  individual  nodes.   It  was also agreed that the NON-Secure side of EARN, hence the  need  to Encrypt Files whenever secure file transmission is a requirement, had  to be  very  clearly  stated to ALL EARN Users at the time  of  joining  the Network.

User Responsibilities and Procedures for Joining EARN

BITNET:   A  new BITNET member must contact the nearest  Node,  make  the necessary  arrangements with the telephone company and sign  the  ‘BITNET agreement’.   In practice the BITNET BOD is informed beforehand,  although it  does  not  have  to be, unless there are doubts  as  to  whether  the applicant  qualifies  for  BITNET membership or not.    At  present  full membership  is restricted to academic institutions, however the  National Laboratories  are  able  to join as they are run  by  Universities.    In general  this is not the case in Europe, hence a potential  problem  area when  European  organisations like CERN wish to be considered  as  having full BITNET membership.

Another  rule is that every document passing through BITNET must  benefit to  a  BITNET member, meaning that traffic via Gateways  not  originating from  or going to a BITNET node is hence prohibited.   The issue of  what would  be  the status of the various nodes of the EARN  sub-networks  was then raised (ie JANET or SUNET).

In  addition  to  the  ‘No Commercial Use’  rule  mentioned  earlier  two categories of BITNET members have been defined:

–  Fully fledged members, also called Class A Users

– Non-fully fledged members, also called Class B Users

The difference between class A and B users it that class B users are only allowed to talk with class A users.   There is, however, no mechanism  to date  to prevent class B users of talking together.   Class B  users  are non-transit nodes (e.g. IBM Research at Yorktown Heights was quoted as a     typical class B user).

P Bryant asked for a copy of the BITNET agreement for examination by  the PTT’s.

EARN:  The situation in Europe is somewhat different because of the  many national PTT’s involved and the rate at which the network is expected  to grow  during  its first year of existence.   The  presence  of  /Academic Networks in several countries makes the situation even more difficult  to manage  as demands for connections to JANET for example will continue  to be handled according to JANET rules, also connected to JANET are a number of Local Area Networks which are outside the control of the JANET Board.

The following procedure for joining EARN was suggested:

–  Contact Country BOD:

–  Find appropriate Node:

–  Sign the ‘EARN Statement of Conditions’ or Make a Statement:  that one has seen and understood the EARN rules as laid down in this document (see also below)

–  Interface to EARN:

–  Inform EARN-BOD via Country representative:

Criteria for joining EARN (tentative):

–  All academic institutions (ie Universities or similar):

–  Public funded and/or controlled non-profit research organisations:

–  Other academic/research non-profit organisations:

Note that Libraries, for example, would not quality.

At line subscription time the PTT’s usually ask what the intended use  of the  line is, hence it was felt very important that the policy for  using the  line as well as the criteria for joining EARN, be formulated in  the ‘EARN statement of conditions’ and presented to the PTT’s beforehand.

Equally  important is to define how does one tackle the problem of  users transgressing  the  rules.   If the rules for using the network  are  ill defined  and if the criteria for joining are too loose it was  also  felt that there was a genuine risk of EARN falling apart because of the  PTT’s not  renewing  some  licenses  after  the  first  year  of  operation  or introducing volume charging.

D Jennings and D Lord agreed to draft the ‘EARN Statement of  Conditions’ for presentation at next BOD meeting.   In the meantime I Fuchs will make the  ‘BITNET  agreement’ available and P Bryant will  check  whether  the JANET  regulations seem to be ‘a priori’ compatible with BITNET  or  not, the  hope is that they are more restrictive and hence that it should  not be a problem for a JANET Node to become a Node on BITNET or EARN as well.   It is not clear yet, and it also depends on the gateway  implementations, how JANET or SUNET Nodes will appear on EARN and BITNET and which  status they  will  have (ie Class A or B vis a vis BITNET, the purpose  of  EARN would obviously be defeated if the EARN rules were watch that for example JANET  and  SUNET  users  were  not allowed  to  use  EARN  in  order  to communicate together).

Relationships with other Networks:

There is a general problem of BITNET or EARNET being used as Pass-through networks,  however as long as lines are used well below  their  capacity, this  was  not  considered  to be  a  very  critical  issue.    Bilateral agreements  being  easier to reach, I Fuchs suggested  to  negotiate  the access to CSNET over BITNET with CUNY and the University of Wisconsin.

Relationships with other Groups:

It  was  agreed  not to establish special relations  with  existing  user groups like SEAS, DECUS, etc.

Operational Problems

EARN  is expected to be operational 24 hours a day, 7 days a weeks  which is  obviously,  an  objective, difficult to  reach.    To  minimise  the inconvenience  of interrupts to the service, it is recommended  to  make schedules  known  to other sites (e.g. Preventive Maintenance  or  other planned  outages),  this is especially important for the  major  transit nodes  like  ROME or CUNY.   D Lord mentioned that each  year  CERN  was officially closed during the week between Christmas and the New Year.

Node Naming

I  Fuchs recommended the use of good mnemonics with some mention  of  the Name  of  the Operating System.   Otherwise Names have to be  unique  and should  preferably not contain special characters, if a site is  planning to  have  several nodes connected it is a good practice to  ‘number’  the names.   ‘ALIAS’ code is available under VM from University of Maine  for those sites who cannot or do not want to change the name under which they are  known locally, but wish to appear on the network under  a  different name.

Germany  has already adopted its naming structure and will stick  to  it.   Given  the facilities generally available for using nicknames instead  of the actual names, this problem is of no particular importance.

A  more serious problem is the one of addressing users over the  gateways to  other  Network,  and  is a  subject  of  further  discussion  between P Bryant, D Jennings, P Hebgen and O Martin.

Network  changes are accumulated at CUNY and are available  via  BITSERVE commands,m  New Routes are distributed to everyone in BITNET and I  Fuchs kindly  proposed to continue doing it and to extend the  distribution  to All EARN nodes.

Name  and  File Servers:  Most of the request to the Name  Servers  being expected to be at the country level, it was suggested to start with a two level Name Server structure (ie Network wide at CUNY for BITNET and EARN, and Country wide in Europe).

Future Meeting:  Next meeting will take place in Paris on May 14th.

APPENDIX A (RSCS EMULATION SOFTWARE)

The VAX/VMS Software is now being marketed by:

Joiner Associates Inc

1124 Edgehill Drive

Madison

Wisconsin 53705

Tel:  (608)-238-8134

An  implementation  on PRIME computers is also believed to  be  available from the same company.

The  VAX/UNIX  Software is available from Pennsylvania  State  University Computer Science Department, Professor Robert OWENS. Tel: (814-865-1131).

 

APPENDIX B (LIST OF PARTICIPANTS)

A Auroux        –  IBM Europe

H Budd          –  IBM Europe

P Rodier        –  IBM France

B Kirchner      –  IBM Germany

P O’Connor      –  IBM Ireland

A Fusi          –  IBM Italy

M Rimon         –  IBM Israel

J Becerril      –  IBM Spain

C Heritier      –  IBM Switzerland

C Setford       –  IBM United Kingdom

J Ippolito      –  France, CNUSC

F Bush          –  Germany, GSI Darmstadt

L Hultsch       –  Germany, GSI Darmstadt

R Wolf          –  Germany, GSI Darmstadt

P Hebgen        –  Germany, Heidelberg University

D Jennings      –  Ireland, University College Dublin

A Cohen         –  Israel, Inter University Computer Center

M Sommani       –  Italy, CNUCE

L Mate          –  Spain, Universidad Politecnica de Madrid

S Eriksson      –  Sweden, Stockholm University Computer Center (QZ)

T Hatt          –  Switzerland, Zurich University

A Kundig        –  Switzerland, ETH Zurich

P Bryant        –  UK, Rutherford Appleton Laboratory (RAL)

I Fuchs         –  United States, City University of New York (CUNY)

D Lord          –  CERN

O Martin        –  CERN