GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc: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 [Page 1] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1210.txt · Last modified: 1991/03/21 23:59 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki