From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1210.txt | 2019 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2019 insertions(+) create mode 100644 doc/rfc/rfc1210.txt (limited to 'doc/rfc/rfc1210.txt') 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 -- cgit v1.2.3