|
|
|
|
|
|
IETF RFC 1210
Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990
Last modified on Friday, March 22nd, 1991
 Permanent link to RFC 1210
 Search GitHub Wiki for RFC 1210
 Show other RFCs mentioning RFC 1210
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
Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990
RFC TOTAL SIZE: 77030 bytes
PUBLICATION DATE: Friday, March 22nd, 1991
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|
