summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1210.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1210.txt')
-rw-r--r--doc/rfc/rfc1210.txt2019
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc1210.txt b/doc/rfc/rfc1210.txt
new file mode 100644
index 0000000..de0fd24
--- /dev/null
+++ b/doc/rfc/rfc1210.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+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]
+ \ No newline at end of file