Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
INFORMATIONAL
Network Working Group V. CerfRequest for Comments: 1210 CNRI P. Kirstein UCL B. Randell Newcastle on Tyne Editors March 1991Network and Infrastructure User Requirements forTransatlantic Research CollaborationBrussels, July 16-18, and Washington July 24-25, 1990Status 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 ofCerf, 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 toCerf, 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 thatCerf, 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 inAppendix A; a complete set of addresses (including telephone, facsimile and email) are given inAppendix B. Because many of the abbreviations used here may not be familiar to all the readers, a Glossary of Terms is given inAppendix C.Cerf, Kirstein, & Randell [Page 5]
RFC 1210 Network and Infrastructure User Requirements March 19912. 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 ofCerf, 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 beenCerf, 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 inSection 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, remoteCerf, 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 19916.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 seriousCerf, 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 beCerf, 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 19916.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, ifCerf, 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 theCerf, 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 toCerf, 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 1991UNDERLYING 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 internationalCerf, 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 19916.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 MassCerf, 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 dataCerf, 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 19916.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 theCerf, 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 1991APPENDIX A NIWG PARTICIPANTS(1) and (2) indicate the Brussels and Washington meetings respectivelyCo-chairmen:Ira Richer (1),(2) Rolf Speth (1) Tom Weber (2) Rosalie Zobel (1),(2)DARPA CEC NSF CECRapporteurs:Vint Cerf (1) Peter Kirstein (1), (2) Mike Levine (2)CNRI UCL PSCOther 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.milCerf, 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.itCerf, 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.ukCerf, 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.milCerf, 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.deCerf, 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.ieCerf, Kirstein, & Randell [Page 33]
RFC 1210 Network and Infrastructure User Requirements March 1991APPENDIX 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 partCerf, 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 Sections6.5,6.9, and6.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.ukCerf, 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.ukCerf, Kirstein, & Randell [Page 36]
[8]ページ先頭