path: root/doc/rfc/rfc1210.txt

Network Working Group                                            V. Cerf
Request for Comments: 1210                                          CNRI
                                                             P. Kirstein
                                                                     UCL
                                                              B. Randell
                                                       Newcastle on Tyne
                                                                 Editors
                                                              March 1991


            Network and Infrastructure User Requirements for
                  Transatlantic Research Collaboration
         Brussels, July 16-18, and Washington July 24-25, 1990

Status of this Memo

   This report complements a shorter printed version which appeared in a
   summary report of all the committees which met in Brussels and
   Washington last July, 1990.  This memo provides information for the
   Internet community.  It does not specify an Internet standard.
   Distribution of this memo is unlimited.

Abstract

   This report summarises user requirements for networking and related
   infrastructure facilities needed to enable effective cooperation
   between US and European research teams participating in the planned
   ESPRIT-DARPA/NSF programme of collaborative research in Information
   Science and Technology.  It analyses the problems and disparities of
   the current facilities, and suggests appropriate one and three year
   targets for improvements.  It proposes a number of initial actions
   aimed at achieving these targets.  Finally, the workshop has
   identified a non-exhaustive set of important issues upon which
   support of future research will depend.  These issues could be
   studied in the short term, with the aim of initiating a programme of
   joint research in collaboration technology within the next year.

SUMMARY OF PRINCIPAL RECOMMENDATIONS AND TARGETS

   EMAIL (6.1) Initiate an intercontinental email operations forum
   involving email service providers in the US and Europe to define and
   implement operational procedures leading to high reliability.  The
   forum should be tasked with analysing interoperability problems in
   the existing email systems, and with developing functional and
   performance specifications for email gateways (relays).  In addition
   an international email user support group should be organized.  The
   target would be to achieve, within one year, routine expectation of
   proper and timely (less than one hour campus to campus) delivery of



Cerf, Kirstein, & Randell                                       [Page 1]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   messages.  The three year target would be to provide global directory
   services, a return/receipt facility, and support for privacy and
   authenticity.

   COMPOUND DOCUMENTS (6.2) Hold a workshop to review the ongoing
   compound document research and development programmes in the two
   regions.  One aim would be to recommend services, based on
   proprietary compound document email for groups using specific
   conforming products, for deployment within the first year.  Another
   would be to propose work items in the NSF/DARPA and ESPRIT programmes
   to ensure a timely collaborative programme could start in mid-1991,
   with a three year target of supporting open system compound document
   email.

   DIRECTORY SERVICES (6.3) Initiate a formal collaboration between
   ongoing US and European efforts to implement and maintain the
   relevant directory databases.  Within the first year provide
   effective access to existing directory services, and coverage of
   relevant NSF/DARPA and ESPRIT communities.  Within three years
   provide database maintenance tools, knowledge-based navigation
   software, and authentication and capability-based access control
   facilities.

   INTERACTIVE LOGIN (6.4) Identify for which protocol suites
   interactive login will be supported including the provision of
   protocol translation facilities.  Within one year identify and
   install the best available interactive software at all interested
   sites.  Develop a cooperative effort on authentication and privacy
   support, to provide such facilities within three years, together with
   support for "type of service", and remote X-windows even through
   different protocol suites.

   FILE SERVICES (6.5) Identify and deploy within one year the best
   available products for double-hop (staged) multi-megabyte file
   transfer.  Within three years define and obtain or develop multi-
   protocol facilities with automated staging, security and management
   facilities; develop access control models, policies and mechanisms to
   support collaborative file access by ad hoc groups.

   GROUP COMMUNICATIONS SERVICES (6.6) Form a support/working group on
   the use of tools, standards and facilities for group communication
   services; set up a working group to harmonize current development
   activities in group communications with the aim of early deployment;
   hold a workshop to propose a harmonized programme of work in the
   future programmes of ESPRIT and DARPA/NSF.  The one year target is to
   provide administrative support for maintaining email mailing lists,
   bulletin boards and shared databases, and to deploy facilities for
   multi-site interactive blackboards.  The main three year target is to



Cerf, Kirstein, & Randell                                       [Page 2]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   provide intercontinental services based on mature "advanced
   groupware" facilities.

   VIDEO CONFERENCING (6.7) Within a year install existing technology at
   a limited number of sites in both regions; within three years extend
   these, probably according to international standards, to have enough
   sites to be available without undue travel; organize a workshop on
   packet/ISDN/ATM video conferencing.

   COMPUTER SUPPORTED COLLABORATIVE GROUP WORKING (6.8 and 7) Set up a
   workshop to study the needs of a collaborative effort to provide
   intercontinental packet video, multimedia conferencing and computer
   supported collaborative group technology facilities.  The workshop
   should, within a year, propose actions which could be made the basis
   of a future harmonized ESPRIT and DARPA/NSF work program.  Within
   three years set up a transatlantic testbed facility to support
   collaborative research programs.

   ACCESS TO UNIQUE RESOURCES (6.9) Organize a workshop dedicated to
   analysing the needs, and defining the steps required, to provide
   pilot access to one or more specific such resources - with due
   attention to networking needs, security provisions, documentation and
   advisory requirements, and usage policies.  This is to be done within
   a year - within three years one or more significant transatlantic
   pilots should be set up demonstrating remote secured access.

   DISTRIBUTED VISUALIZATION (6.10) A working group should be set up to
   select which current development efforts in distributed visualization
   to support, identify required standards and begin to distribute
   techniques and software, all within a year.  Its year 3 target should
   be to establish mutually agreed upon standards and demonstrate
   transatlantic distributed visualization applications.

   NETWORK MANAGEMENT (6.11) Convene an international research network
   operations, planning and management team to develop and apply
   procedural and technical recommendations for international network
   management; organize a set of international network operations
   centers devoted to configuration management, fault detection,
   isolation and repair of network problems; form one or more
   intercontinental Computer Emergency Response Teams to coordinate
   response to attacks against hosts and networks and to develop
   procedures for collecting actionable evidence.  Within one year put
   in place an administrative structure to coordinate existing
   facilities manually and to plan technical solutions; within three
   years technology for automating international network management
   should have been developed and deployed.





Cerf, Kirstein, & Randell                                       [Page 3]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   MULTI-PROTOCOL SUPPORT (6.12) Validate current multi-protocol
   solutions, with a one year target of supporting campus-to-campus
   communication for a subset of coexisting protocol suites (at least
   OSI and TCP/IP), and of deploying internationally supported versions
   of existing application level (protocol-translating) gateways;
   collaborate on research and experimentation with multi-protocol
   routing and resource allocation; make recommendations, to funders and
   national research network service providers, on technical solutions
   and standards for multi-protocol support.  Within three years deploy
   improved management and resource allocation facilities for multi-
   protocol routers in order to provide service guarantees.

   CLIENT-SERVER FACILITIES (6.13) Within one year provide limited
   bandwidth intercontinental X-windows, and convene workshops to
   achieve agreements on Remote Procedure Call and Intercontinental
   Distributed File System protocols; form a working group on support
   for X-Windows in OSI and to validate performance through TCP/TPn
   protocol translating gateways; initiate collaboration on
   implementation and test of intercontinental RPC and distributed file
   systems.  The main three year target is to achieve support for
   intercontinental RPC and Distributed File Systems.

   ARCHIVAL STORAGE FOR DISTRIBUTED COMPUTING ENVIRONMENTS (6.14)
   Convene an international workshop whose goals are to ascertain the
   relevance to this group of the data storage reference model that is
   nearly ready to be declared an official standard guide; to carry out
   an on-going discussion of the system issues that have to be developed
   as a result of this model; to arrive at solutions to be proposed by
   vendors and users for implementations of Data Systems Storage
   Solutions which are modular, interconnectable, and standard.

   DATA REPRESENTATION AND EXCHANGE (6.15) It is proposed that an
   international working group be established to recommend a standard
   collection of software encompassing a variety of data
   representations.  This working group should address the issue of data
   identification embedded in the data stream to allow for later
   extensions.  After an initial planning meeting, the group would
   schedule subsequent meetings annually to finalise the current data
   exchange standard recommendation, and to define new work scopes.  The
   working group would also make their recommendation known to other
   standards bodies.

   TRANSATLANTIC AND CONTINENTAL DISTRIBUTION FACILITIES (6.16) This
   item is put last only because it is a corollary of the preceding
   recommendations.  Use existing joint US/European coordination
   mechanisms (e.g., CCIRN) for planning of higher speed, transatlantic
   links; convene a special CEC/DARPA/NSF task force to consider much
   higher speed transatlantic capacity sharing options; ensure that



Cerf, Kirstein, & Randell                                       [Page 4]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   there is an infrastructure in Europe paralleling the US one of
   providing the majority of relevant campuses access at speeds
   approaching 1.5 Mb/s; encourage European user groups with high data
   transmission requirements to aggregate their data transmission
   facilities; attempt to integrate European application projects (like
   the RACE Applications Pilots) to assist in providing an appropriate
   European distribution network with 10-500 Mb/s access to appropriate
   campuses.  The one year targets are to install 2 Mb/s multi-protocol
   distribution facilities in Europe, and 1.5 Mb/s (or higher)
   transatlantic capacity.  The three year targets are to install 2
   additional 1.5 Mb/s (or higher) transatlantic links, and to determine
   the feasibility of sharing much higher bandwidth transatlantic links.

1.  INTRODUCTION

   The Networks and Infrastructure Working Group (NIWG) attempted to
   synthesize requirements and identify potential cooperative
   development efforts for network-based capabilities both by internal
   discussion within the working group and through interaction with the
   other working groups in the workshop.

   It is essential for the facilities supporting DARPA/NSF-ESPRIT
   collaboration to be consistent with services being used by the US and
   European projects for their own internal collaboration.  We have,
   therefore, had to consider both what facilities must be available in
   the two regions separately and then what must be done to facilitate
   US-European collaboration.

   Between the US and Europe, the Coordinating Committee for
   Intercontinental Research Networks (CCIRN) is addressing the
   improvement of coordination of network services.  To support US
   DARPA/NSF and ESPRIT collaboration, it will be necessary to extend
   the use of network services in each region as well as to improve the
   quality of services linking the regions.

   The NIWG met both in Brussels and in Washington.  It was led by Ira
   Richer (DARPA) and Rolf Speth (CEC) in Brussels, and Tom Weber (NSF)
   and Rosalie Zobel (CEC) in Washington.  The participants were largely
   different in the two meetings, but it was agreed that there would be
   a common set of minutes.  It is a commentary on the quality of the
   infrastructure available to some of the participants that nine
   people, from both sides of the Atlantic, contributed to these minutes
   over five days - all by email.  The participants are listed in
   Appendix A; a complete set of addresses (including telephone,
   facsimile and email) are given in Appendix B.  Because many of the
   abbreviations used here may not be familiar to all the readers, a
   Glossary of Terms is given in Appendix C.




Cerf, Kirstein, & Randell                                       [Page 5]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


2.  SCOPE AND OBJECTIVES

   The scope of the working group was to concentrate on generic,
   network-based user services considered helpful for a wide range of
   collaborative work between US and European groups.  We distinguished
   between the capabilities which would benefit from immediate attention
   or were required in the short term (e.g., within a year), and those
   which required longer term development.  While the prescribed scope
   was to act only in support of the other groups by making use of
   available technology, we identified one area where we felt more
   research and development was an important adjunct to our scope.

   The working group agreed that the major objectives, based on
   instructions given in the opening plenary sessions, were to identify
   the following:

   (i)   user requirements which must be satisfied to support
         cooperative US/European research;

   (ii)  technical and other infrastructure requirements which must be
         satisfied to support cooperative US/European research;

   (iii) opportunities and potential means for satisfying these
         requirements;

   (iv)  potential obstacles to achieving the desired support;

   (v)   mutual benefits which would accrue to the participants in
         recommended cooperative projects;

   (vi)  promising collaborative development activities needed for
         a better infrastructure.

3.  MOTIVATION FOR COLLABORATION ON NETWORKING AND INFRASTRUCTURE

   Computer networking, by its very nature, requires cooperation and
   collaboration among the participants developing, implementing,
   deploying and operating the hardware and software comprising the
   system.  The long-term vision is the creation of an infrastructure
   which provides the user (rather than the network) with a distributed
   multi-vendor heterogeneous computing environment - with transatlantic
   facilities approaching those available locally.

   A major element of successful networking is the agreement on
   standards which are to be met by all systems included in the network.
   Beyond technical agreements, there must also be concurrence on
   operational procedures, performance objectives, support for the users
   of the network and ability to plan for enhancement and growth of



Cerf, Kirstein, & Randell                                       [Page 6]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   network services.

   A consequence of these observations is that virtually any effort to
   provide network service support to ESPRIT-DARPA/NSF collaboration
   should be carried out cooperatively between the US and European
   network research, design, development, engineering and operations
   communities.

4.  CURRENT STATE OF NETWORKING IN THE US AND EUROPE

   In the DARPA/NSF communities, there is heavy use of electronic mail
   and computer networking to support a wide range of scientific
   research.  There is heavy use of the TCP/IP and DECNET protocols as
   well as special electronic mail protocols in the BITNET and Unix
   users networks (e.g., UUNET).  Email use varies in intensity among
   different research disciplines.

   There is an emerging interest in and use of OSI-based protocols,
   particularly for email (X.400) and directory services (X.500).  Most
   of the backbone networks making up the Internet use 1.5 Mb/s
   telecommunications facilities although the NSFNET will be installing
   a high speed, 45 Mb/s subnetwork during 1990.  There are many Local
   Area Networks (LANs).  Plans are in place to support both IP (as in
   TCP/IP) and CLNP (as in OSI) datagram protocols in backbone and
   regional networks.  Most of these protocols are already supported on
   LANs.  On a selective research basis, a set of 1000 Mb/s research
   testbeds are being installed during 1990-1993.

   In Europe, especially amongst the ESPRIT collaborators, there is more
   limited use of computer networking, with the primary emphasis on the
   use of electronic mail and bulletin boards.  There is a strong focus
   on OSI protocols in European wide-area networks, but there is a
   considerably amount of TCP/IP use on LANs, and growing use of TCP/IP
   in Wide Area Networks (WANs) in some countries.  Most of the national
   wide-area networks are based on the CCITT X.25 protocols with access
   speeds up to 64 Kb/s, though higher access speeds in the 2 Mb/s range
   are planned for many countries, and just becoming available in some.
   An X.25 international backbone (IXI) has just become operational,
   which connects in the National Research Networks and/or the Public
   Packet Data Networks in each Western Europe country at 64 Kb/s.  The
   funding of this network has only been agreed for a further short
   period, and plans to upgrade it to higher speed access are not
   agreed.  There are many LANs in place.  The OSI connection-oriented
   network service (CONS) is layered above X.25, but there is growing
   interest in supporting the connectionless service (CLNS) concurrently
   with the Internet IP in national and international backbone networks.
   Application testbeds at higher speeds are planned under the CEC RACE
   programme.  Many of its higher level user services have not been



Cerf, Kirstein, & Randell                                       [Page 7]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   specified collaboratively - as would be required for wide deployment.
   These points are explained further in Section 6.

   Thus although provisions or plans regarding National networks in some
   CEC member states are not so far behind the American facilities, one
   must note that in effect, because of continental backbone
   limitations, Pan-European facilities are at least a generation
   behind.  Specifically, both with respect to existing and planned
   backbone provisions, there is a factor of 25 difference between
   Europe and the USA.  In addition, this approximate comparison
   flatters the European scene, since it compares facilities that are
   just coming into existence, and plans that are not yet agreed or
   funded, on the European side with facilities that have been available
   for some time, and plans that will be realised before the end of this
   year, in the USA.

5.  POLLS OF THE OTHER WORKING GROUPS

   The NIWG polled the other seven working groups meeting in Brussels
   and Washington to find out what networking and infrastructure support
   their collaborations might require.  In general, a strong emphasis
   was placed on the provision of reliable and timely email, easier
   accessibility of email service, user support and information on
   existence and use of available services.  There was serious concern
   about privacy, and great interest in transparency (i.e., hiding the
   details of intercontinental networking).

   Some users mentioned that FAX was easier to use and apparently more
   ubiquitous than email for their communities (there are over 12 M
   facsimile machines installed world-wide).  Interest in integrating
   FAX and email was noticeable.  Most users recognised the many
   advantages of email for multiple addressees, subsequent reprocessing,
   relaying and cost.

   The requirement for large file transfer was patchy.  Many did not
   require such facilities, but several groups required transfer of 100
   MB files and some even 1 GB.  Many groups desired remote log-in, but
   found present performance - even on the Internet - inadequate.
   Several wanted global file services and file sharing.

   Many groups wished to use video conferencing - but only if they did
   not have to travel more than two hours to a suitable facility.  Some
   groups were interested in computer supported group collaboration -
   but most did not understand this term.

   One group (Vision) desired real time transfer at 300 Mb/s, but most
   had much more modest user-user needs.  The needs for less visible
   features like network management, client-user technology, remote



Cerf, Kirstein, & Randell                                       [Page 8]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   visualization standards and data representation and exchange formats
   were not voiced explicitly.  However they could be deduced from the
   services which the users did request.

6. USER SERVICES NEEDED IN THE SHORT AND MEDIUM TERM

   To support collaboration between the research workers, we need a
   number of services between the end users.  These require provisions
   which impinge on many management domains: inside individual campuses;
   campus-wide area gateways; national distribution; regional-
   intercontinental gateways; intercontinental distribution.  However,
   from the users' viewpoint, this set of services should constitute a
   system whose internal details are not, or at least should not, be of
   concern.  It is the overall performance and reliability exhibited,
   and the facilities made available to the user (and their cost), which
   matter.  Inadequacies of bandwidth, protocols, or administrative
   support anywhere in the chain between the end users are, to them,
   inadequacies in the system as a whole.

   To some extent more funding from DARPA/NSF and the CEC can alleviate
   the current difficulties.  However it is likely that such funding
   will impact only the international and intercontinental components.
   It is essential that the end-user distribution be strengthened also.
   In the US this requires both Regional and Campus Networks.  In
   Europe, it requires activity by the National network authorities
   (usually represented in RARE and/or COSINE), and by the Campus
   network providers.  Moreover, not only must the transmission
   facilities be strengthened, but also the appropriate protocol suites
   must be supported; this may require policy decisions as well as
   technical measures.

   We indicate below the services which are required immediately, and
   are visible to the end-users.  They often have implications to the
   service providers which have far-reaching consequences.  Some of the
   services are urgent user services; some are underpinning requirements
   needed to assure the user services; some are longer term needs.
   There is clearly a strong interaction between the user services and
   the underpinning ones; there is also some between the user services
   themselves.  Partly as a result of our own deliberations, and partly
   as a result of our polls of the other working groups, we have
   identified needs in the areas below.

USER SERVICES

   In most cases these are services which are available in local or
   homogeneous environments.  For the proposed collaborations they must
   be available on an intercontinental basis between heterogeneous
   systems.



Cerf, Kirstein, & Randell                                       [Page 9]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


6.1  Electronic Mail

   The current email services between the US and Europe suffer from gaps
   in connectivity, lack of reliability and poor responsiveness.  These
   problems stem, in part, from the multiplicity of protocols used (and
   requiring translation) and in part from an inadequate operations and
   maintenance infrastructure.  There are few user and directory support
   services available; access to, and use of, email service varies
   dramatically.  However, some initial cooperative work has started
   already between RARE Working Group 1 and participants in the Internet
   Engineering Task Force in the area of email.

6.1.1  One Year Targets

   (i)  Provide management structure to support user assistance and
        reliable operation of email relays;

   (ii) Achieve routine expectation of proper and timely (less than
        1 hour campus-campus) delivery.

6.1.2  Three Year Targets

   (i)   Provide global, email directory services;

   (ii)  Develop and deploy a return/receipt facility;

   (iii) Provide support for privacy and authenticity.

6.1.3  Recommended Actions

   (i)   Initiate an intercontinental email operations forum involving
         email service providers in the US and Europe to define and
         implement operational procedures leading to high reliability;

   (ii)  Task the email operations forum to develop functional and
         performance specifications for email gateways (relays);

   (iii) Organize an international email user support group;

   (iv)  Organize a collaborative working group to analyse email
         interoperability problems (X.400, UUCP, SMTP, EARN, EUROKOM,
         BITNET) and make recommendations for specific developments to
         improve interoperability.

   Included in the terms of reference should be requirements for
   cryptographic support for privacy, authenticity and integrity of
   email.  This work could include specific collaboration on X.400 and
   SMTP privacy enhancement methods.  (Note there are serious



Cerf, Kirstein, & Randell                                      [Page 10]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   international obstacles to achieving progress in areas involving
   cryptographic technology.)

   See Directory Services section for further possible actions.

6.2  Compound Document Electronic Mail

   While proprietary solutions for compound documents (text, font
   support, geometric graphics, bit-map graphic, spread-sheets, voice
   annotation, etc.) exist, these are limited to products of single
   manufacturers.  While international standards for compound documents
   exist, these are still evolving, and few real commercial products
   based on the standards exist.  Nevertheless, both proprietary and
   open systems compound document mail services could be made available
   reasonably quickly.

6.2.1  One Year Targets

   (i)  Support proprietary compound document email for groups
        interested in using specific conforming products;

   (ii) Provide experimental services to groups with open systems
        offerings using several products.  Support interoperation
        for multi-font text, bit-mapped and geometric graphics.  The
        software could be provided from that arising from the
        combination of a previous NSF and an ESPRIT proposal.

6.2.2  Three Year Targets

   Provide support for open system compound document email and document
   exchange including the following facilities: spreadsheets; integrity,
   authentication and non-repudiation of origin of document parts;
   confidentiality of document parts.

6.2.3  Recommended Actions

   Hold a workshop to review the ongoing compound document research and
   development programmes in the two regions.  One aim would be to
   recommend services for deployment in the short term.  Another would
   be to propose work items in the NSF/DARPA and ESPRIT programmes to
   ensure a timely collaborative programme could start in mid-1991.

6.3  Directory Services

   White pages services to assist network users to find email addresses,
   computer services and other on-line facilities are, at best, only
   lightly deployed in both the US and Europe.  If networked services
   are to become infrastructural in nature, directory services must be



Cerf, Kirstein, & Randell                                      [Page 11]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   widely implemented, deployed and easily accessible.  In addition to
   working with international standards such as CCITT X.500, access to
   the installed base of white pages services (such as the US WHOIS
   service and the UK NRS service) is essential.  These facilities are
   also needed to support key management for cryptographic services
   required for authenticity, integrity and confidentiality of email and
   other communications.  Because there are different legal and
   organizational views of directory service information, it will also
   be critical to address organizational and international differences
   in the sensitivity of such data and its accessibility.

   It is essential that directory service databases be built and
   maintained throughout the US and European research communities.

6.3.1  One Year Targets

   (i)  Get effective access to existing directory services
        (X.500 and others);

   (ii) Put in data for relevant NSF/DARPA and ESPRIT communities.

6.3.2  Three Year Targets

   (i)   Provide tools to support database maintenance;

   (ii)  Provide good knowledge-based navigation software;

   (iii) Provide strong authentication facilities;

   (iv)  Provide capability-based access restrictions.

6.3.3  Recommended Actions

   Initiate a formal collaboration between ongoing US and European
   (e.g., RARE WG3) efforts to implement and maintain the relevant
   directory databases.

6.4  Interactive Login

   Interactive access to service systems in the US and Europe is, at
   present, only partly feasible.  One inhibiting factor is incompatible
   protocol suites in use in the provision of such services.  The
   implementation and deployment of common protocols, and the provision
   of protocol translation gateways, are needed to improve this
   situation.






Cerf, Kirstein, & Randell                                      [Page 12]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


6.4.1  One Year Target

   Identify and install the best available interactive login software
   (using staging gateways, if necessary) on all interested sites.

6.4.2  Three Year Targets

   Improve interactive login performance to include support for:

   (i)   "type of service" (quality or grade-of-service);

   (ii)  support for privacy;

   (iii) support for authentication;

   (iv)  support for remote X-windows even through different protocol
         suites.

6.4.3  Recommended Actions

   (i)   Identify for which protocol suites interactive login will be
         supported;

   (ii)  Determine mechanisms for good performance in staged facilities
         (i.e., in which it is necessary to login and then open
         manually new connections from the intermediate gateways);

   (iii) Develop a cooperative effort on authentication and privacy
         support.

6.5  File Services

   File transfers are not easily achieved in the multi-protocol
   environment, and long files cannot be transferred reliably.  Manual
   movement of files through staged, protocol-translating gateways is
   awkward and often unreliable.  Performance of file transfer software
   varies substantially.  Improvements in file transfer facilities are
   needed, but there should also be other forms of file service based on
   shared file systems.

6.5.1  One Year Targets

   Develop or identify and install the best available file transfer
   software (providing staging gateways, if necessary) to support:

   (i)   Multi-megabyte file transfers;

   (ii)  Translation between distinct file transfer protocols;



Cerf, Kirstein, & Randell                                      [Page 13]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   (iii) High performance and robustness;

   (iv)  Use of wide-area file systems, e.g., Andrew;

   (v)   Ad hoc sharing of sections of file systems across two machines.

6.5.2  Three Year Targets

   Develop (or obtain) and deploy file transfer services with:

   (i)   support for privacy, authentication and integrity;

   (ii)  support for automatic staging through several file transfer
         relays;

   (iii) support for multi-party access of selected portions of file
         systems across multiple machines.

6.5.3  Recommended Actions

   (i)   In conjunction with RARE WG4 and IETF, identify best available
         products for multi-hop (staged) file transfer;

   (ii)  Define and carry out comparative performance tests to select
         best available file transfer software, including checkpointing;

   (iii) Define and implement fuller multi-hop, multi-protocol
         facilities with automated staging, security and management
         facilities;

   (iv)  Develop access control models, policies and mechanisms to
         support collaborative file access by ad hoc groups.

6.6  Group Communication Services

   Coordination of collaborative efforts can be substantially enhanced
   through provision of mailing lists, bulletin boards and shared
   databases.  Setting up and managing such facilities, however,
   typically requires special knowledge and privileges.  Making it
   possible to set up and operate such facilities easily and without
   special privileges would enhance the infrastructure of support for
   collaborative activities between the US and Europe (and within each
   region as well).

   More advanced group communication services such as shared screens
   with voice teleconferencing, distributed publishing through
   electronic libraries, and various forms of teleconferencing, might
   relieve some of the necessity for face-to-face meetings, if



Cerf, Kirstein, & Randell                                      [Page 14]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   sufficiently reliable and easy to use.  The prior use of such
   facilities make subsequent face-to-face meetings much more productive
   also.  Of course, time zone differences are a challenge to any real-
   time conferencing schemes, and are often the primary rationale for
   arranging face-to-face conferences which "force" participants to
   enter the same time zone for the duration of the meeting.

6.6.1  One Year Targets

   (i)  Provide administrative support for setting up and maintaining
        email mailing lists, bulletin boards and shared databases;

   (ii) Provide facilities for multi-site interactive blackboards
        including text, graphics, spreadsheets and program access.

6.6.2  Three Year Targets

   (i)  Provide intercontinental services based on more mature "advanced
        groupware" facilities including shared screens and voice
        services;

   (ii) Extend interactive blackboard to include slow scan video, voice,
        animation, and using international standards where feasible.

6.6.3  Recommended Actions

   (i)  Form a support/working group on the use of tools, standards and
        facilities for group communication services;

   (ii) Initiate collaboration on advanced group communications (e.g.,
        shared screens, distributed electronic publishing, etc.).

6.7  Video Conferencing

   Facilities for low bandwidth (under 1 Mb/s) interactive video/voice
   conferencing (e.g., packet-based) are, at present, unavailable for
   support of intercontinental collaboration.  Even two-party
   videoconferencing could be beneficial initially.  The comments from
   the other seven working groups showed a strong interest in the use of
   videoconferencing, provided the travel to the relevant facilities did
   not exceed two hours.  This should impact the eventual deployment
   plans for the facilities.

   Minimum facilities needed for video conferencing include at least 256
   Kb/s across the Atlantic for each concurrent conferencing channel.  A
   video codec, two cameras and three monitors are needed at each site
   along with suitable packetizing equipment if a packet-mode system is
   to be deployed.  There exists at least one such system in use in the



Cerf, Kirstein, & Randell                                      [Page 15]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   US, developed by DARPA and used regularly for transcontinental
   working group meetings.  Another such system is just being
   commissioned (at University College London).

6.7.1  One Year Target

   Deploy two-party videoconferencing facilities in at least four sites
   on each continent.

6.7.2  Three Year Target

   Develop and deploy multi-party conferencing capability on a larger
   scale on both continents, to make the facilities accessible more
   widely to the collaborators with less travel penalty.

6.7.3  Recommended Actions

   (i)  Install existing technology at a limited number of sites in
        both regions, in line with the desire to limit travel
        mentioned above;

   (ii) Organize a workshop on packet/ISDN/ATM videoconferencing.

6.8  Multimedia Computer Supported Group Working

   The NSF has initiated an effort on collaboration technology
   development and experimentation under the rubric: Collaboratory.
   Similar research is in progress under the ESPRIT programme.  While
   the subject of the NIWG's discussions was designated as
   infrastructure support for the other research collaborations, we
   believe it is very appropriate to mount a collaborative programme
   among US and European researchers, which would enhance Collaboratory
   efforts and force both groups to come to grips with problems of
   supporting collaboration techniques across intercontinental
   distances.

6.8.1  One Year Target

   Harmonise the ESPRIT and NSF Collaboratory research programmes.

6.8.2  Three Year Target

   Set up a common, transatlantic testbed facility to support
   collaborative research programmes.

6.8.3  Recommended Actions

   Set up a workshop to study the needs of a collaborative effort to



Cerf, Kirstein, & Randell                                      [Page 16]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   provide intercontinental packet video, multimedia conferencing and
   computer supported collaborative group technology facilities.  The
   workshop should propose actions which could be made the basis of a
   future harmonised ESPRIT and DARPA/NSF work programme.

6.9  Access to Unique Resources

   A number of resources can be labelled unique in the scope of
   ESPRIT/DARPA/NSF or even on a worldwide basis.  Their uniqueness may
   derive from their nature (e.g., large test facilities or a focus
   point of knowledge in a discipline) or be such in a transitory phase.
   In the spirit of the future EC/US cooperation, it is clear that there
   should be agreed access to some such resources.  This will require:

   (i)   Provision of appropriate access and usage information;

   (ii)  Physical access for visitors;

   (iii) Continued non-local access.

   The third point has clear networking implication.  Appropriate remote
   access to the resources, connectivity to the users and adequate
   access speeds have to be provided, possibly together with access
   control facilities.

   The most demanding cases are those of newly developed products; their
   transitory uniqueness does not allow one to amortise costs over
   substantial periods as would be reasonable for large scale centres
   like NCAR or CERN.

6.9.1  One Year Target

   (i)   Identify appropriate unique transitory resources
         (e.g., Touchstone);

   (ii)  Specify the provisions needed to make at least one such
         resource available.

6.9.2  Three Year Target

   Set up one or more significant transatlantic pilots demonstrating
   remote, secured access.

6.9.3  Recommended Actions

   Organise a workshop dedicated to analysing the needs and defining the
   steps required to provide pilot access to one or more specific such
   resources.  The workshop may need to address networking needs,



Cerf, Kirstein, & Randell                                      [Page 17]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   security provisions, documentation and advisory requirements,
   modification of current access capabilities, and usage policies.

6.10  Distributed Visualization

   Scientific visualization applications often involve multiple
   resources.  These resources can span a complete range of
   sophistication, from simple hardcopy at one end to elaborate
   rendering at the other end.  Interactive graphics workstations,
   supercomputers and specialized scientific databases may all be
   involved in a single application.  The scientist at a workstation
   should be able to view all of these resources as a single network
   resource, although they may be physically distributed over
   considerable distances.  A typical example is a high performance
   graphics workstation, a supercomputer and a network to connect them
   together, all with appropriate software.  The workstation may be
   close to the supercomputer or distant from it.

   Currently there are efforts underway at several installations -
   including ones funded by NSF/DARPA and ESPRIT - to develop
   techniques, interfaces and software necessary to create this
   environment.  In limited instances it already exists.  Better
   coordination of these efforts on both sides of the Atlantic would be
   desirable.  Coordinating such efforts across the Atlantic will be
   necessary for effective collaboration in end-user visualization
   applications in a variety of disciplines to take place in the future.

6.10.1  One Year Targets

   Identify the significant current development efforts in these areas
   and determine which ones to support.  Identify the areas requiring
   standards.  Minimize duplication of effort and begin to distribute
   the techniques and software.

6.10.2  Three Year Targets

   Establish mutually agreed upon standards.  Demonstrate transatlantic
   distributed visualization applications.

6.10.3  Recommended Actions

   Establish a working group to further refine and to implement the one
   year and three year targets and to identify additional distributed
   visualization topics that would benefit from coordinated efforts.
   Determine the appropriate mechanisms for supporting such
   collaborations.





Cerf, Kirstein, & Randell                                      [Page 18]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


UNDERLYING SERVICES

   Most of the services described below are required to achieve the
   goals of reliability, availability and transparency of the user
   services.

6.11  Network Management

   Current network management technology and practice are not adequate
   to support large scale, international research networks.  Time-zone
   differences and lack of organizational operational network management
   agreements combine to make international network management a serious
   challenge.  To be effective, network management must operate on a
   campus-to-campus basis, since the campuses are the sources and sinks
   of traffic in the system.

6.11.1  One Year Target

   Put in place an administrative structure to coordinate existing
   facilities manually and to plan technical solutions.

6.11.2  Three Year Target

   Develop and deploy technology for automating international network
   management.

6.11.3  Recommended Actions

   (i)    Convene an international research network operations,
          planning and management team to develop and apply
          procedural and technical recommendations for international
          network management;

   (ii)   Organize a set of international network operations centres
          devoted to configuration management, fault detection,
          isolation and repair of network problems;

   (iii)  Form one or more intercontinental Computer Emergency Response
          Teams to coordinate response to attacks against hosts and
          networks and to develop procedures for collecting actionable
          evidence.

6.12 Multi-protocol Support

   Users depend on a variety of protocols to support their research.
   The international network infrastructure does not uniformly support
   the use of multiple protocols (e.g., DECNET, TCP/IP/ST, OSI) on an
   end-to-end basis.  The use of various portions of the international



Cerf, Kirstein, & Randell                                      [Page 19]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   network also may be restricted by policy, and this must be
   accommodated in implementing routing for campus-to-campus protocols.

   Support for campus-to-campus multi-protocol transmission and routing
   is needed at a minimum of 64 Kb/s end-to-end - higher for the support
   of some of the services.  Where the end-users have adopted similar
   protocols, the intervening networks should not impede the full
   exploitation of the facilities available in the chosen protocol
   suite.  Where different protocol suites are used, high quality
   application-level gateways which can translate among protocols are
   needed also; to the greatest extent possible, these should allow
   people to use their own procedures, even though they are
   communicating with services which use different ones.  For some
   services, this will lead to a requirement to upgrade access, and
   possibly even transparent access (including protocol conversion), to
   at least 1.5 Mb/s between individual campuses in the US and Europe.

6.12.1  One Year Targets

   (i)  Support campus-to-campus communication for a subset of
        coexisting protocol suites (at least OSI and TCP/IP) at a
        minimum of 64 Kb/s;

   (ii) Deploy internationally supported versions of existing
        application level (protocol-translating) gateways.

6.12.2  Three Year Targets

   (i)  Improve management and resource allocation for multi-protocol
        routers (e.g., to achieve service guarantees);

   (ii) Support campus-to-campus communication at a minimum of 1.5 Mb/s.

6.12.3  Recommended Actions

   (i)   Validate current multi-protocol solutions for intercontinental,
         and indeed campus-to-campus use;

   (ii)  Collaborate on research and experimentation with multi-protocol
         routing and resource allocation;

   (iii) Make recommendations, to funders and national research network
         service providers, on technical solutions and standards for
         multi-protocol support.







Cerf, Kirstein, & Randell                                      [Page 20]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


6.13  Client-Server Technology

   Among the more important computer communications techniques emerging
   on a widespread basis during the last decade is the client-server
   model of interprocess communication.  This notion was actually
   developed during the earliest stages of packet network exploration
   and dramatically enhanced with the invention of local area networks
   (such as Ethernet) which could support very high speed, low delay
   inter-computer exchanges.  Applications of this concept range from
   remote procedure calls to remote file access and support for remote,
   bit-mapped graphics.

   At present, these techniques work best in a high bandwidth, low delay
   environment; they are generally not well-supported in wide-area,
   intercontinental networks.  Collaborative efforts between the US and
   Europe could be enhanced substantially by support for client-server
   services on an intercontinental basis.  Such facilities would permit
   collaborative use of distributed filing systems, X-windows
   applications and other distributed computing applications.  High
   capacity, low-delay channels will be needed on an intercontinental
   basis to support serious use of this technology.  In addition,
   agreement must be reached on which protocols should be used to
   support this technology.

6.13.1  One Year Targets

   (i)   Provide limited bandwidth intercontinental X-Windows support
         for graphical user interfaces;

   (ii)  Achieve agreements on intercontinental Remote Procedure Call
         and Distributed File System protocols;

   (iii) Validate support of X-Windows under OSI and through protocol
         translating gateways.

6.13.2  Three Year Targets

   (i)  Achieve selective support for intercontinental remote
        visualization;

   (ii) Achieve support for intercontinental RPC and Distributed File
        Systems.

6.13.3  Recommended Actions

   (i)   Convene workshops to achieve agreements on intercontinental
         Remote Procedure Call and Distributed File System protocols;




Cerf, Kirstein, & Randell                                      [Page 21]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   (ii)  Form working group on support for X-Windows in OSI and to
         validate performance through TCP/TPn protocol translating
         gateways;

   (iii) Initiate collaboration on implementation and test of
         intercontinental RPC and distributed file systems.

Section 6.14   Archival Storage for Distributed Computing Environments

   There are several major issues that must be addressed by distributed
   computing environments (DCEs) containing supercomputers.  Resolution
   of these issues is likely to evolve over the next five to ten years.

   One such issue is archival storage and bitfile management for the
   complete environment.  Several problems have to be resolved to
   appropriately handle this situation.  The first problem is the
   global-naming of bitfiles that are being moved through the DCE
   to/from the archive.  Second, the file system hierarchy must be
   defined.  Third, there is the question of how the DCE knows the file
   system hierarchy for which it is responsible, and the location of the
   boundary through which the network and the archival system operate.
   Lastly, there is the question how the file system hierarchy is
   divided across a DCE and within a supercomputer.

   A second issue in the DCE is the need for all nodes obtaining or
   storing data to know the storage media differences.  For future
   systems, this requirement manifests itself both at the distributed
   nodes and at the supercomputer because of the differences in the
   physical media structure.

   The third issue is the delineation of the bitfile attributes.  This
   relates to how the data must be maintained as it migrates through the
   hierarchy, as well as through the DCE.  The bitfile carries
   attributes based upon its location in the hierarchy, or in the DCE,
   that may be different from those needed at the supercomputer level.
   Many of these attributes are related to the data content and where it
   resides in time within the DCE.  Section 6.15 discusses some of the
   possible meta-data representation methodologies that may be used but
   are not yet standardized.

   Another issue is the determination and implementation of the site
   policy that is to dictate data migration and allocation inside the
   DCE archival storage system.

   Several working committees are attacking the various problems
   delineated above, and are trying to confront the difficulties in
   these environments.  This work is progressing mostly in the United
   States.  The IEEE Computer Society Technical Committee on Mass



Cerf, Kirstein, & Randell                                      [Page 22]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   Storage Systems is in the process of developing a Computer Society
   draft standard on data storage systems.  The current working draft
   provides a consistent terminology and an object-oriented design for
   defining storage subsystem components, whether they are being built
   around a single system or in a DCE.  Other groups in the computing
   community are currently dealing with the problems of data migration
   within a distributed environment.  This distributed environment may
   or may not include a supercomputer, but it almost always includes a
   high-volume storage system of some sort delineated as a "mass storage
   system." This subject was not discussed long enough at the meeting to
   deduce one year or three year targets - indeed these may well be set
   by the relevant National working groups.

6.14.1  Recommended Actions

   Convene an international workshop whose goals are:

   1.  An understanding of the contents of the data storage reference
       model that is nearly ready to be declared an official standard
       guide;

   2.  To continue discussion of the various system issues that have
       to be developed as a result of this model;

   3.  To arrive at solutions to be proposed by vendors and users for
       implementations of Data Systems Storage Solutions which are
       modular, interconnectable, and standard.

6.15  Data Representation and Exchange

   The problem of data exchange between different computer architectures
   and operating systems has been existent since the deployment of the
   early computers.  This problem has been exacerbated by the acceptance
   of the client-server paradigm as the provider of distributed
   services.  Distributed computer services require immediate data
   exchange.  In the past, data was exchanged on some medium, such as
   tape, and could be examined at leisure.  Ad hoc data conversion
   routines were created to process the data, and were often embedded in
   the programs using the data.  Data exchange in the client-server
   paradigm does not permit this leisurely data examination.  Both the
   client and the server must be able to "call" software that is
   guaranteed to convert the exchanged data "on the spot."  This
   guarantee also implies a standard format rather than the ability to
   convert all formats because it would be impossible to maintain
   multiple architecture conversion software and, of course, the size of
   such conversion software would be enormous.

   The issue of data exchange has been addressed resulting in many data



Cerf, Kirstein, & Randell                                      [Page 23]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   exchange software packages.  A few of the currently more popular
   packages are XDR, HDF, NetCDF, PostScript and CCSDS.  Each of these
   packages addresses a specific type of data.  Some address bitmap
   data; one addresses the general encoding of "display" information.
   Some of these packages address various numerical representations in
   computers.  It is unclear whether any existing package could or
   should be extended to solve all data exchange problems.  However, a
   more realistic approach would be a collection of data exchange
   packages formed as the "standard."

   This item was discussed only briefly at the meeting, so that no one
   year or three year targets were specified.

6.15.1  Recommended Actions

   It is proposed that an international working group be established to
   recommend a standard collection of software encompassing a variety of
   data representations.  This working group should address the issue of
   embedding identification of the data representations in the data
   stream to allow for later extensions.  The working group would meet
   initially to establish a work-scope and to assign the members tasks.
   The group would schedule subsequent meetings (probably annually) to
   finalise the current data exchange standard recommendation, and to
   define new work scopes.  The working group would also make their
   recommendation known to other standards bodies such as X/OPEN, UI,
   OSF, X Consortium, NIST, IEEE, ACM, etc.

6.16  Transatlantic Links and Continental Distribution

   At present, there is inadequate transatlantic capacity to support
   research collaborations involving significant amounts of computer-
   mediated communication.  There is also considerable room for
   improvement in the distribution of capacity and enhancement of
   reliability of network service in Europe.  Moreover, the point was
   made strongly that collaboration would be very difficult unless the
   infrastructure on the two sides was broadly comparable - even if the
   transatlantic capacity was per force lower.  Moreover, it was sharply
   emphasised that there was a large requirement for transatlantic data
   flow in other fields - e.g., Space Science, Atmospheric Science and
   High Energy Physics.  In the US these needs are being aggregated in
   the National Research and Engineering Network; such aggregation is
   required also in Europe and on a transatlantic basis.

6.16.1  One Year Targets

   (i)  Install 2 Mb/s multi-protocol distribution facilities in Europe;

   (ii) Install 1.5 Mb/s (or higher) transatlantic capacity.



Cerf, Kirstein, & Randell                                      [Page 24]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


6.16.2  Three Year Targets

   (i)  Install 2 additional 1.5 Mb/s (or higher) transatlantic links
        by 1993;

   (ii) Determine feasibility of sharing much higher bandwidth
        intercontinental links (e.g., in the 51 Mb/s STS-1 range).

6.16.3  Recommended Actions

   (i)   Use existing joint US/European coordination mechanisms
         (e.g., CCIRN) for planning of higher speed, transatlantic
         links;

   (ii)  Convene a special CEC/DARPA/NSF task force to consider much
         higher speed transatlantic capacity sharing options;

   (iii) Ensure that there is an infrastructure in Europe, paralleling
         the US one, providing the majority of relevant campuses access
         at speeds approaching 1.5 Mb/s;

   (iv)  Encourage European user groups with high data transmission
         requirements to aggregate their data transmission facilities.
         Attempt to integrate European application projects (like the
         RACE Applications Pilots) to assist in providing an appropriate
         European distribution network with 10 - 500 Mb/s access to
         appropriate campuses.

7.  LONGER TERM INITIATIVES

   Although these were not discussed in any detail, for lack of time,
   the following areas emerged as of interest for longer term
   collaborative work:

   (i)   Electronic Library Services (includes an important
         intellectual property rights component);

   (ii)  Multi-media Computer Supported Collaborative Work;

   (iii) Portable Computing/Communications Environments;

   (iv)  Distributed Computing using heterogeneous machines and unique
         facilities;

   (v)   Compatible approaches to computer networks with Gb/s access
         speeds, and appropriate systems switching, transmission and
         protocols.




Cerf, Kirstein, & Randell                                      [Page 25]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   It was felt that some collaborative research in these areas would
   have immense medium term benefits to the other communities - and
   would integrate well with the ongoing research programmes on both
   sides of the Atlantic.

8.  OBSTACLES

   The largest single obstacle to the provision of the facilities
   outlined in this report are that development of the necessary
   facilities do not have priority to most funding agencies.  This is
   exemplified by the role of our workshops in this series.  Not only
   network provision, but also development of appropriate infrastructure
   application software and testbed activity, are essential.

   There are a number of problem areas which could benefit from official
   attention from CEC and US research funding agencies.  For example,
   there are a number of open and proprietary protocol suites which are
   candidates for use in US/European collaborative research.  However,
   there is lack of political agreement as to how to deal with these
   various suites.  It would be politically valuable if the CEC and US
   research agencies could issue a communique outlining common agreement
   on treatment of multiple protocols (e.g., expressing serious interest
   in supporting campus-to-campus communication using multiple
   protocols).  Within the OSI protocol suite, there are differences as
   to which features ought to make up the standard profile for use by
   government-sponsored groups.  Handling of connection-oriented and
   connectionless protocol elements within the suite is the subject of
   continued debate.  Agreement to support at least TCP/IP and the
   connectionless network protocol in the OSI suite on an
   intercontinental basis would be beneficial to both parties; many CEC
   members would like connection-oriented network protocols to be
   supported also.

   European international tariffs are relatively high.  This has
   inhibited the implementation of private networks and impeded progress
   on collaborative work between the US and Europe.  A CEC initiative to
   come to grips with this problem could be quite helpful.

   There are a diversity of intra-European networking organizations
   which have technical, operational and policy interests.  Planning for
   intercontinental networking infrastructure is sometimes confused by
   the variety of interested parties.  Effort towards further
   coordination and rationalization of intra-European networking
   activities could make intercontinental planning somewhat easier.

   There is a strong interest in the use of cryptographic methods to
   provide privacy, authenticity and integrity assurance for various
   forms of intercontinental communication and at various levels in the



Cerf, Kirstein, & Randell                                      [Page 26]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   protocol hierarchies.  Although there appears to be substantial
   technical activity in this area, progress is now impeded by national
   restrictions on the export of software which utilizes cryptographic
   methods.  National use policies vary and the ability to apply these
   valuable and needed techniques is uncertain.

   Some national privacy and data protection laws prohibit the creation
   of directories containing personal information (e.g., email and
   postal addresses) and other laws limit what kinds of information (and
   in what form) can be transported across national borders.

   Handling of cryptographic exchanges, import/export of supporting
   software and exchanges of keying information are all potentially
   subject to national restrictions and constraints.  The government
   agencies interested in promoting international collaboration may need
   to seek alternative international formulations of permitted practice
   to permit the required technical support.

   Finally, several organizations in the US and Europe have pointed out
   that the provision of networking infrastructure requires stable
   funding over significant periods of time.  Stability for
   infrastructure support has been shaky in the US and in Europe and
   this presents an obstacle to achieving widespread and reliable
   network services to aid collaborative efforts.

9.  CONCLUDING REMARKS

   The set of proposals contained in this report provide a realistic,
   staged approach to ameliorating the grave problems caused by the
   disparities with respect to bandwidth provision, user services and
   network protocol issues that impede widespread and close
   transatlantic collaboration at present between the ESPRIT and
   DARPA/NSF research workers.  Their implementation will require a
   considerable degree of commitment to resolve present administrative
   difficulties, but the financial resources needed would, we estimate,
   be relatively modest and fully commensurate with the benefits to be
   gained.














Cerf, Kirstein, & Randell                                      [Page 27]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


APPENDIX A  NIWG PARTICIPANTS

(1) and (2) indicate the Brussels and Washington meetings respectively

Co-chairmen:

Ira Richer (1),(2) Rolf Speth (1) Tom Weber (2) Rosalie Zobel (1),(2)
DARPA              CEC            NSF           CEC

Rapporteurs:

Vint Cerf (1)    Peter Kirstein (1), (2)     Mike Levine (2)
CNRI             UCL                         PSC

Other Participants:

Franco Bigi (1)         Adriano Endrizzi (1), (2) Juan Riera(1)
William Bostwick (1)    David Farber (1)          Jack Thorpe (1)
Bill Buzbee (2)         Steve Goldstein (1)       Jose Torcato (1), (2)
Mike Eyre (2)           Sid Karin (2)             Klaus Ullmann (1)
Robert Cooper (1)       Barry Leiner (1)          Paul Wilson (2)
Steve Crocker(2)        Jean-Pierre Peltier (2)   Bill Wulf (2)
Karel De Vriendt(1)     Brian Randell (1), (2)

APPENDIX B - NETWORKING AND INFRASTRUCTURE WORKING GROUP: TELEPHONE,
EMAIL AND FAX NUMBERS

   Franci Bigi (1)
   CEC
   Rue de la Loi 2000
   B-1049
   Brussels
   BELGIUM
     Tel: +32 2 236 3493
     Fax: +32 2 235 6937

   William Bostwick (1)
   US Dept of Energy
     Tel: +1 703 276 3533
     Fax: +1 703 276 2536
     Email: bostwick@darpa.mil










Cerf, Kirstein, & Randell                                      [Page 28]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   Bill Buzbee (2)
   National Center for Atmospheric Research
   P.O.  Box 3000
   Boulder, CO 80307
   USA
     Tel +1 303 497 120?
     Fax +1 303 497 1137
   Email buzbee@bierstadt.ucar.edu

   Vinton Cerf (1)
   Corporation for National Research Initiatives (CNRI)
   1895 Preston White Drive, Suite 100
   Reston, VA 22091
   USA
     Tel: +1 703 620 8990
     Fax: +1 703 620 0913
   Email: vcerf@nri.reston.va.us

   Robert Cooper (1)
   Rutherford and Appleton Laboratories
   Didcot, Oxon, 0x11 0QX
   UK
     Tel: +44 23544 5459
     Fax: +44 23544 5808
   Email: R.Cooper@Rutherford.AC.UK

   Steve Crocker (2)
   Trusted Information Systems
   3060 Washington Road
   Glenwood, MD 21738
   USA
     Tel: +1 301 854 6889
     Fax: +1 301 854 5363
   Email:  crocker@tis.com

   Adriano Endrizzi (1), (2)
   JRC
   21020 ISPRA
   ITALY
     Tel: +39 332 789213
     Fax: +39 332 789098
   Email: a_endrizzi@cen.jrc.it









Cerf, Kirstein, & Randell                                      [Page 29]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   Michael Eyre (2)
   Architecture Projects Management Ltd (ANSA)
   Poseidon Ho
   Castle Park
   Cambridge
   CB3ORD
   UK
     Tel: +44 223 323010
     Fax: +44 223 359779
   Email:  dme@ansa.co.uk

   David Farber (1)
   University of Pennsylvania
   200 South 33rd Street
   Philadelphia, PA 19104-6389
   USA
     Tel: +1 215 898 9508
     Fax: +1 215 274 8293
   Email: farber@cis.upenn.edu

   Steve Goldstein (1)
   NSF
   18th & G Street, NW
   Washington, DC 20550
   USA
     Tel: +1 202 357 9717
     Fax: +1 202 357 0320
   Email:  sgoldstein@note.nsf.gov

   Sid Karin (2)
   San Diego Supercomputer Center
   University of California at San Diego
   San Diego, CA 92186-9784
   USA
     Tel: +1 619 534 5075
     Fax: +1 619 534 5113
   Email: Karin@sdsc.edu

   Peter Kirstein (1) (2)
   University College London
   Gower Street
   London
   WCIE GBT
   UK
     Tel: +44 71 380 7286
     Fax: +44 71 387 1397
   Email: kirstein@cs.ucl.ac.uk




Cerf, Kirstein, & Randell                                      [Page 30]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   Barry Leiner (1)
   Research Institute for Advanced Computer Science (RIACS)
   USA
     Tel: +1 415 694 6362
     Fax: +1 415 962 7772
   Email: leiner@riacs.edu

   Michael Levine (2)
   Pittsburgh Supercomputing Center
   Carnegie Mellon University
   Pittsburgh, PA 15213  USA
     Tel: +1 412 268 4960
     Fax: +1 412 268 5832
   Email: levine @a.psc.edu

   Jean-Pierre Peltier (2)
   ONERA
   Chatillon CEDEX
   BP 72
   92322
   FRANCE
     Tel: +33 1 4657 1160
     Fax: +33 1 4746 9025
   Email: Peltier@Froner81.bitnet

   Brian Randell (1), (2)
   Computing Laboratory
   University of Newcastle upon Tyne
   NE1 7RU
   UK
     Tel: +44 91 222 7923
     Fax: +44 91 222 8232
   Email: Brian.Randell@newcastle.ac.uk

   Ira Richer (1) (2)
   Defense Advanced Research Projects Agency  (DARPA)
   1400 Wilson Bld
   Arlington, VA  22209
   USA
   USA
      Tel: +1 703 614 5800
      Fax: +1 703 614 5004
   Email: richer@darpa.mil








Cerf, Kirstein, & Randell                                      [Page 31]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   Juan Riera (1)
   University of Madrid
   ETSI
   Ciudad Universitaria
   E-28040
   Madrid
   ESPAGNA
     Tel: +34 1 449 5762
     Fax: +34 1 243 2077
   Email: jriera@dit.upm.es

   Rolf Speth (1)
   CEC
   Rue de la Loi 2000
   B-1049
   Brussels
   BELGIUM
     Tel: +32 2 236 0416
     Fax: +32 2 235 0655
   Email: Rolf_speth@eurokom.ie

   Jack Thorpe (1)
   Defense Advanced Research Projects Agency - Europe (DARPA-E)
   GERMANY
     Tel: +49 711 715 5418
     Fax: +49 711 715 5448
   Email: thorpe@darpa.mil

   Jose Torcato (1), (2)
   CEC, TR 61 0/10
   Rue de la Loi 2000
   B-1049
   Brussels
   BELGIUM
      Tel: +32 2 236 3537
      Fax: +32 2 235 6937
   Email: --

   Klaus Ullmann (1)
   Deutsche Forschungsnetz
   Pariserstr. 44
   D-1000 Berlin 15
   GERMANY
      Tel: +49 30 8842 9920
      Fax: +49 30 8842 9970
   Email: ullmann@zpl.dfn.dbp.de





Cerf, Kirstein, & Randell                                      [Page 32]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   Karel De Vriendt (1)
   CEC
   Rue de la Loi 2000
   B-1049
   Brussels
   BELGIUM
      Tel:
      Fax: +32 3 235 0655
   Email: k_d_v@eurokom.ie

   Thomas A.  Weber (2)
   NSF
   18th & G Street, NW
   Washington, DC 20550
   USA
     Tel: +1 202 357 7558
     Fax: +1 202 357 0320
   Email:  tweber@note.nsf.gov

   Paul Wilson
   Computer Sciences Company Ltd.
   Computer Sciences House, Brunel Way
   Slough, Berkshire SL1 1XL
   UK
     Tel: 0753 73232
     Fax: 0753 516178
   Email: wilson@cs.nott.ac.uk

   Bill Wulf (2)
   University of Virginia
   Charlottesville, VA 22903-2442
   USA
     Tel: +1 804 982 2223
     Fax: +1 804 982 2214
   Email: wulf@virginia.edu

   Rosalie Zobel (1) (2)
   CEC
   Rue de la Loi 2000
   B-1049
   Brussels
   BELGIUM
     Tel: +32 2 236 0324
     Fax: +32 2 236 3031
   Email: R_Zobel@eurokom.ie






Cerf, Kirstein, & Randell                                      [Page 33]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


APPENDIX C GLOSSARY

   There is no attempt to provide a comprehensive glossary.  However,
   some of the participants were unfamiliar with the terms used on the
   other side of the Atlantic, so some of the more parochial technical
   terms are defined below.

   CCITT - The international body responsible for recommendations
        to the National communications authorities.

   CLNP - Connectionless Network Protocol.  A specific ISO/OSI
        protocol analgous to the IP mentioned below.

   CONS - Connection-oriented service.  Another specific ISO/OSI
        protocol more aligned to the X.25 protocol mentioned below.

   Compound Document - Documents containing different content types
        including some of the following: text (possibly with various
        fonts), geometric graphics, bit-map graphics, spreadsheets,
        tables, animation, voice  annotation.

   IAB - The Internet Activities Board.  This is the body which
        guides the evolution of the TCP/IP protocol suite and the
        general Internet architecture.  The Internet Engineering Task
        Force and Internet Research Task Force are subsidiary
        activities of the IAB.

   IETF - The Internet Engineering Task Force.  This is a working
        group responsible for the specification, development and
        discussion of the operation of facilities in the Internet
        research networks, which are the basis of US research network
        services - but also have European counterparts and
        participation.

   Internet - The concatenations of packet-switched networks which
        comprise the research networks used by most of the contractors
        of the NSF and DARPA (amonsgst other US groups).  The Internet
        also extends to other countries including some in Europe.

   IP - The Internet Protocol.  This is the lowest level protocol which
        is the basis of the current Internet.

   ISO - The International Standards Organisation.  The international
        organisation responsible for the standardisation of a broad
        range of facilities including network ones.

   IXI - The international packet switched network which has been
        installed by the European communication authorities as part



Cerf, Kirstein, & Randell                                      [Page 34]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


        of a European project to provide an international backbone
        network linking in the West European National research (and
        public) networks.

   OSI - Open Systems Interconnection.  An evolving set of ISO
        standards which should allow services on different host
        computers networks to inter-operate.

   RARE - The international committee comprising representatives of
        European National and international research networks.

   TCP/IP - The transport protocols currently used on the Internet.

   X.25 - The Network Access protocols specified by CCITT/OSI as
        standard.

   X.400 - The set of protocols for message services specified by
        CCITT/ISO.

   X.500 - The set of protocols for directory services specified by
        CCITT/ISO.

Security Considerations

   Security issues are discussed in Sections 6.5, 6.9, and 6.11.

Authors' Addresses

   Vinton G. Cerf
   Corporation for National Research Initiatives
   1895 Preston White Drive, Suite 100
   Reston, VA 22091

   Phone: +1 703 620 8990

   Email: vcerf@nri.reston.va.us


   Peter Kirstein
   University College London
   Department of Computer Science
   Gower Street
   London WCIE GBT
   UK

   Phone: +44 71 380 7286

   Email: kirstein@cs.ucl.ac.uk



Cerf, Kirstein, & Randell                                      [Page 35]
^L
RFC 1210      Network and Infrastructure User Requirements    March 1991


   Brian Randell
   Computing Laboratory
   University of Newcastle upon Tyne
   NE1 7RU
   UK

   Phone: +44 91 222 7923

   Email: Brian.Randell@newcastle.ac.uk










































Cerf, Kirstein, & Randell                                      [Page 36]
^L