RFC1210

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: [email protected]

Cerf, Kirstein, & Randell

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 [email protected]

  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: [email protected]

  Robert Cooper (1)
  Rutherford and Appleton Laboratories
  Didcot, Oxon, 0x11 0QX
  UK
    Tel: +44 23544 5459
    Fax: +44 23544 5808
  Email: [email protected]

  Steve Crocker (2)
  Trusted Information Systems
  3060 Washington Road
  Glenwood, MD 21738
  USA
    Tel: +1 301 854 6889
    Fax: +1 301 854 5363
  Email:  [email protected]

  Adriano Endrizzi (1), (2)
  JRC
  21020 ISPRA
  ITALY
    Tel: +39 332 789213
    Fax: +39 332 789098
  Email: [email protected]

Cerf, Kirstein, & Randell

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:  [email protected]

  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: [email protected]

  Steve Goldstein (1)
  NSF
  18th & G Street, NW
  Washington, DC 20550
  USA
    Tel: +1 202 357 9717
    Fax: +1 202 357 0320
  Email:  [email protected]

  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: [email protected]

  Peter Kirstein (1) (2)
  University College London
  Gower Street
  London
  WCIE GBT
  UK
    Tel: +44 71 380 7286
    Fax: +44 71 387 1397
  Email: [email protected]

Cerf, Kirstein, & Randell

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: [email protected]

  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: [email protected]

  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: [email protected]

  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: [email protected]

Cerf, Kirstein, & Randell

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: [email protected]

  Rolf Speth (1)
  CEC
  Rue de la Loi 2000
  B-1049
  Brussels
  BELGIUM
    Tel: +32 2 236 0416
    Fax: +32 2 235 0655
  Email: [email protected]

  Jack Thorpe (1)
  Defense Advanced Research Projects Agency - Europe (DARPA-E)
  GERMANY
    Tel: +49 711 715 5418
    Fax: +49 711 715 5448
  Email: [email protected]

  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: [email protected]

Cerf, Kirstein, & Randell

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: [email protected]

  Thomas A.  Weber (2)
  NSF
  18th & G Street, NW
  Washington, DC 20550
  USA
    Tel: +1 202 357 7558
    Fax: +1 202 357 0320
  Email:  [email protected]

  Paul Wilson
  Computer Sciences Company Ltd.
  Computer Sciences House, Brunel Way
  Slough, Berkshire SL1 1XL
  UK
    Tel: 0753 73232
    Fax: 0753 516178
  Email: [email protected]

  Bill Wulf (2)
  University of Virginia
  Charlottesville, VA 22903-2442
  USA
    Tel: +1 804 982 2223
    Fax: +1 804 982 2214
  Email: [email protected]

  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: [email protected]

Cerf, Kirstein, & Randell

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

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: [email protected]

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

  Phone: +44 71 380 7286

  Email: [email protected]

Cerf, Kirstein, & Randell

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: [email protected]

Cerf, Kirstein, & Randell