As per Relevance of the word structure, we have this rfc below:
Network Working Group V.
Request for Comments: 1210
P.
B.
Newcastle on
March 1991
Network and Infrastructure User Requirements
Transatlantic Research
Brussels, July 16-18, and Washington July 24-25, 1990
Status of this
This report complements a shorter printed version which appeared in
summary report of all the committees which met in Brussels
Washington last July, 1990. This memo provides information for
Internet community. It does not specify an Internet standard
Distribution of this memo is unlimited
This report summarises user requirements for networking and
infrastructure facilities needed to enable effective
between US and European research teams participating in the
ESPRIT-DARPA/NSF programme of collaborative research in
Science and Technology. It analyses the problems and disparities
the current facilities, and suggests appropriate one and three
targets for improvements. It proposes a number of initial
aimed at achieving these targets. Finally, the workshop
identified a non-exhaustive set of important issues upon
support of future research will depend. These issues could
studied in the short term, with the aim of initiating a programme
joint research in collaboration technology within the next year
SUMMARY OF PRINCIPAL RECOMMENDATIONS AND
EMAIL (6.1) Initiate an intercontinental email operations
involving email service providers in the US and Europe to define
implement operational procedures leading to high reliability.
forum should be tasked with analysing interoperability problems
the existing email systems, and with developing functional
performance specifications for email gateways (relays). In
an international email user support group should be organized.
target would be to achieve, within one year, routine expectation
proper and timely (less than one hour campus to campus) delivery
Cerf, Kirstein, & Randell [Page 1]
RFC 1210 Network and Infrastructure User Requirements March 1991
messages. The three year target would be to provide global
services, a return/receipt facility, and support for privacy
authenticity
COMPOUND DOCUMENTS (6.2) Hold a workshop to review the
compound document research and development programmes in the
regions. One aim would be to recommend services, based
proprietary compound document email for groups using
conforming products, for deployment within the first year.
would be to propose work items in the NSF/DARPA and ESPRIT
to ensure a timely collaborative programme could start in mid-1991,
with a three year target of supporting open system compound
email
DIRECTORY SERVICES (6.3) Initiate a formal collaboration
ongoing US and European efforts to implement and maintain
relevant directory databases. Within the first year
effective access to existing directory services, and coverage
relevant NSF/DARPA and ESPRIT communities. Within three
provide database maintenance tools, knowledge-based
software, and authentication and capability-based access
facilities
INTERACTIVE LOGIN (6.4) Identify for which protocol
interactive login will be supported including the provision
protocol translation facilities. Within one year identify
install the best available interactive software at all
sites. Develop a cooperative effort on authentication and
support, to provide such facilities within three years, together
support for "type of service", and remote X-windows even
different protocol suites
FILE SERVICES (6.5) Identify and deploy within one year the
available products for double-hop (staged) multi-megabyte
transfer. Within three years define and obtain or develop multi
protocol facilities with automated staging, security and
facilities; develop access control models, policies and mechanisms
support collaborative file access by ad hoc groups
GROUP COMMUNICATIONS SERVICES (6.6) Form a support/working group
the use of tools, standards and facilities for group
services; set up a working group to harmonize current
activities in group communications with the aim of early deployment
hold a workshop to propose a harmonized programme of work in
future programmes of ESPRIT and DARPA/NSF. The one year target is
provide administrative support for maintaining email mailing lists
bulletin boards and shared databases, and to deploy facilities
multi-site interactive blackboards. The main three year target is
Cerf, Kirstein, & Randell [Page 2]
RFC 1210 Network and Infrastructure User Requirements March 1991
provide intercontinental services based on mature "
groupware" facilities
VIDEO CONFERENCING (6.7) Within a year install existing technology
a limited number of sites in both regions; within three years
these, probably according to international standards, to have
sites to be available without undue travel; organize a workshop
packet/ISDN/ATM video conferencing
COMPUTER SUPPORTED COLLABORATIVE GROUP WORKING (6.8 and 7) Set up
workshop to study the needs of a collaborative effort to
intercontinental packet video, multimedia conferencing and
supported collaborative group technology facilities. The
should, within a year, propose actions which could be made the
of a future harmonized ESPRIT and DARPA/NSF work program.
three years set up a transatlantic testbed facility to
collaborative research programs
ACCESS TO UNIQUE RESOURCES (6.9) Organize a workshop dedicated
analysing the needs, and defining the steps required, to
pilot access to one or more specific such resources - with
attention to networking needs, security provisions, documentation
advisory requirements, and usage policies. This is to be done
a year - within three years one or more significant
pilots should be set up demonstrating remote secured access
DISTRIBUTED VISUALIZATION (6.10) A working group should be set up
select which current development efforts in distributed
to support, identify required standards and begin to
techniques and software, all within a year. Its year 3 target
be to establish mutually agreed upon standards and
transatlantic distributed visualization applications
NETWORK MANAGEMENT (6.11) Convene an international research
operations, planning and management team to develop and
procedural and technical recommendations for international
management; organize a set of international network
centers devoted to configuration management, fault detection
isolation and repair of network problems; form one or
intercontinental Computer Emergency Response Teams to
response to attacks against hosts and networks and to
procedures for collecting actionable evidence. Within one year
in place an administrative structure to coordinate
facilities manually and to plan technical solutions; within
years technology for automating international network
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-
solutions, with a one year target of supporting campus-to-
communication for a subset of coexisting protocol suites (at
OSI and TCP/IP), and of deploying internationally supported
of existing application level (protocol-translating) gateways
collaborate on research and experimentation with multi-
routing and resource allocation; make recommendations, to funders
national research network service providers, on technical
and standards for multi-protocol support. Within three years
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
bandwidth intercontinental X-windows, and convene workshops
achieve agreements on Remote Procedure Call and
Distributed File System protocols; form a working group on
for X-Windows in OSI and to validate performance through TCP/
protocol translating gateways; initiate collaboration
implementation and test of intercontinental RPC and distributed
systems. The main three year target is to achieve support
intercontinental RPC and Distributed File Systems
ARCHIVAL STORAGE FOR DISTRIBUTED COMPUTING ENVIRONMENTS (6.14)
Convene an international workshop whose goals are to ascertain
relevance to this group of the data storage reference model that
nearly ready to be declared an official standard guide; to carry
an on-going discussion of the system issues that have to be
as a result of this model; to arrive at solutions to be proposed
vendors and users for implementations of Data Systems
Solutions which are modular, interconnectable, and standard
DATA REPRESENTATION AND EXCHANGE (6.15) It is proposed that
international working group be established to recommend a
collection of software encompassing a variety of
representations. This working group should address the issue of
identification embedded in the data stream to allow for
extensions. After an initial planning meeting, the group
schedule subsequent meetings annually to finalise the current
exchange standard recommendation, and to define new work scopes.
working group would also make their recommendation known to
standards bodies
TRANSATLANTIC AND CONTINENTAL DISTRIBUTION FACILITIES (6.16)
item is put last only because it is a corollary of the
recommendations. Use existing joint US/European
mechanisms (e.g., CCIRN) for planning of higher speed,
links; convene a special CEC/DARPA/NSF task force to consider
higher speed transatlantic capacity sharing options; ensure
Cerf, Kirstein, & Randell [Page 4]
RFC 1210 Network and Infrastructure User Requirements March 1991
there is an infrastructure in Europe paralleling the US one
providing the majority of relevant campuses access at
approaching 1.5 Mb/s; encourage European user groups with high
transmission requirements to aggregate their data
facilities; attempt to integrate European application projects (
the RACE Applications Pilots) to assist in providing an
European distribution network with 10-500 Mb/s access to
campuses. The one year targets are to install 2 Mb/s multi-
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
the feasibility of sharing much higher bandwidth transatlantic links
1.
The Networks and Infrastructure Working Group (NIWG) attempted
synthesize requirements and identify potential
development efforts for network-based capabilities both by
discussion within the working group and through interaction with
other working groups in the workshop
It is essential for the facilities supporting DARPA/NSF-
collaboration to be consistent with services being used by the US
European projects for their own internal collaboration. We have
therefore, had to consider both what facilities must be available
the two regions separately and then what must be done to
US-European collaboration
Between the US and Europe, the Coordinating Committee
Intercontinental Research Networks (CCIRN) is addressing
improvement of coordination of network services. To support
DARPA/NSF and ESPRIT collaboration, it will be necessary to
the use of network services in each region as well as to improve
quality of services linking the regions
The NIWG met both in Brussels and in Washington. It was led by
Richer (DARPA) and Rolf Speth (CEC) in Brussels, and Tom Weber (NSF
and Rosalie Zobel (CEC) in Washington. The participants were
different in the two meetings, but it was agreed that there would
a common set of minutes. It is a commentary on the quality of
infrastructure available to some of the participants that
people, from both sides of the Atlantic, contributed to these
over five days - all by email. The participants are listed
Appendix A; a complete set of addresses (including telephone
facsimile and email) are given in Appendix B. Because many of
abbreviations used here may not be familiar to all the readers,
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
The scope of the working group was to concentrate on generic
network-based user services considered helpful for a wide range
collaborative work between US and European groups. We
between the capabilities which would benefit from immediate
or were required in the short term (e.g., within a year), and
which required longer term development. While the prescribed
was to act only in support of the other groups by making use
available technology, we identified one area where we felt
research and development was an important adjunct to our scope
The working group agreed that the major objectives, based
instructions given in the opening plenary sessions, were to
the following
(i) user requirements which must be satisfied to
cooperative US/European research
(ii) technical and other infrastructure requirements which must
satisfied to support cooperative US/European research
(iii) opportunities and potential means for satisfying
requirements
(iv) potential obstacles to achieving the desired support
(v) mutual benefits which would accrue to the participants
recommended cooperative projects
(vi) promising collaborative development activities needed
a better infrastructure
3. MOTIVATION FOR COLLABORATION ON NETWORKING AND
Computer networking, by its very nature, requires cooperation
collaboration among the participants developing, implementing
deploying and operating the hardware and software comprising
system. The long-term vision is the creation of an
which provides the user (rather than the network) with a
multi-vendor heterogeneous computing environment - with
facilities approaching those available locally
A major element of successful networking is the agreement
standards which are to be met by all systems included in the network
Beyond technical agreements, there must also be concurrence
operational procedures, performance objectives, support for the
of the network and ability to plan for enhancement and growth
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
provide network service support to ESPRIT-DARPA/NSF
should be carried out cooperatively between the US and
network research, design, development, engineering and
communities
4. CURRENT STATE OF NETWORKING IN THE US AND
In the DARPA/NSF communities, there is heavy use of electronic
and computer networking to support a wide range of
research. There is heavy use of the TCP/IP and DECNET protocols
well as special electronic mail protocols in the BITNET and
users networks (e.g., UUNET). Email use varies in intensity
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).
of the backbone networks making up the Internet use 1.5 Mb/
telecommunications facilities although the NSFNET will be
a high speed, 45 Mb/s subnetwork during 1990. There are many
Area Networks (LANs). Plans are in place to support both IP (as
TCP/IP) and CLNP (as in OSI) datagram protocols in backbone
regional networks. Most of these protocols are already supported
LANs. On a selective research basis, a set of 1000 Mb/s
testbeds are being installed during 1990-1993.
In Europe, especially amongst the ESPRIT collaborators, there is
limited use of computer networking, with the primary emphasis on
use of electronic mail and bulletin boards. There is a strong
on OSI protocols in European wide-area networks, but there is
considerably amount of TCP/IP use on LANs, and growing use of TCP/
in Wide Area Networks (WANs) in some countries. Most of the
wide-area networks are based on the CCITT X.25 protocols with
speeds up to 64 Kb/s, though higher access speeds in the 2 Mb/s
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
Packet Data Networks in each Western Europe country at 64 Kb/s.
funding of this network has only been agreed for a further
period, and plans to upgrade it to higher speed access are
agreed. There are many LANs in place. The OSI connection-
network service (CONS) is layered above X.25, but there is
interest in supporting the connectionless service (CLNS)
with the Internet IP in national and international backbone networks
Application testbeds at higher speeds are planned under the CEC
programme. Many of its higher level user services have not
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
CEC member states are not so far behind the American facilities,
must note that in effect, because of continental
limitations, Pan-European facilities are at least a
behind. Specifically, both with respect to existing and
backbone provisions, there is a factor of 25 difference
Europe and the USA. In addition, this approximate
flatters the European scene, since it compares facilities that
just coming into existence, and plans that are not yet agreed
funded, on the European side with facilities that have been
for some time, and plans that will be realised before the end of
year, in the USA
5. POLLS OF THE OTHER WORKING
The NIWG polled the other seven working groups meeting in
and Washington to find out what networking and infrastructure
their collaborations might require. In general, a strong
was placed on the provision of reliable and timely email,
accessibility of email service, user support and information
existence and use of available services. There was serious
about privacy, and great interest in transparency (i.e., hiding
details of intercontinental networking).
Some users mentioned that FAX was easier to use and apparently
ubiquitous than email for their communities (there are over 12
facsimile machines installed world-wide). Interest in
FAX and email was noticeable. Most users recognised the
advantages of email for multiple addressees, subsequent reprocessing
relaying and cost
The requirement for large file transfer was patchy. Many did
require such facilities, but several groups required transfer of 100
MB files and some even 1 GB. Many groups desired remote log-in,
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
not have to travel more than two hours to a suitable facility.
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
had much more modest user-user needs. The needs for less
features like network management, client-user technology,
Cerf, Kirstein, & Randell [Page 8]
RFC 1210 Network and Infrastructure User Requirements March 1991
visualization standards and data representation and exchange
were not voiced explicitly. However they could be deduced from
services which the users did request
6. USER SERVICES NEEDED IN THE SHORT AND MEDIUM
To support collaboration between the research workers, we need
number of services between the end users. These require
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
system whose internal details are not, or at least should not, be
concern. It is the overall performance and reliability exhibited
and the facilities made available to the user (and their cost),
matter. Inadequacies of bandwidth, protocols, or
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
the current difficulties. However it is likely that such
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.
Europe, it requires activity by the National network
(usually represented in RARE and/or COSINE), and by the
network providers. Moreover, not only must the
facilities be strengthened, but also the appropriate protocol
must be supported; this may require policy decisions as well
technical measures
We indicate below the services which are required immediately,
are visible to the end-users. They often have implications to
service providers which have far-reaching consequences. Some of
services are urgent user services; some are underpinning
needed to assure the user services; some are longer term needs
There is clearly a strong interaction between the user services
the underpinning ones; there is also some between the user
themselves. Partly as a result of our own deliberations, and
as a result of our polls of the other working groups, we
identified needs in the areas below
USER
In most cases these are services which are available in local
homogeneous environments. For the proposed collaborations they
be available on an intercontinental basis between
systems
Cerf, Kirstein, & Randell [Page 9]
RFC 1210 Network and Infrastructure User Requirements March 1991
6.1 Electronic
The current email services between the US and Europe suffer from
in connectivity, lack of reliability and poor responsiveness.
problems stem, in part, from the multiplicity of protocols used (
requiring translation) and in part from an inadequate operations
maintenance infrastructure. There are few user and directory
services available; access to, and use of, email service
dramatically. However, some initial cooperative work has
already between RARE Working Group 1 and participants in the
Engineering Task Force in the area of email
6.1.1 One Year
(i) Provide management structure to support user assistance
reliable operation of email relays
(ii) Achieve routine expectation of proper and timely (less
1 hour campus-campus) delivery
6.1.2 Three Year
(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
(i) Initiate an intercontinental email operations forum
email service providers in the US and Europe to define
implement operational procedures leading to high reliability
(ii) Task the email operations forum to develop functional
performance specifications for email gateways (relays);
(iii) Organize an international email user support group
(iv) Organize a collaborative working group to analyse
interoperability problems (X.400, UUCP, SMTP, EARN, EUROKOM
BITNET) and make recommendations for specific developments
improve interoperability
Included in the terms of reference should be requirements
cryptographic support for privacy, authenticity and integrity
email. This work could include specific collaboration on X.400
SMTP privacy enhancement methods. (Note there are
Cerf, Kirstein, & Randell [Page 10]
RFC 1210 Network and Infrastructure User Requirements March 1991
international obstacles to achieving progress in areas
cryptographic technology.)
See Directory Services section for further possible actions
6.2 Compound Document Electronic
While proprietary solutions for compound documents (text,
support, geometric graphics, bit-map graphic, spread-sheets,
annotation, etc.) exist, these are limited to products of
manufacturers. While international standards for compound
exist, these are still evolving, and few real commercial
based on the standards exist. Nevertheless, both proprietary
open systems compound document mail services could be made
reasonably quickly
6.2.1 One Year
(i) Support proprietary compound document email for
interested in using specific conforming products
(ii) Provide experimental services to groups with open
offerings using several products. Support
for multi-font text, bit-mapped and geometric graphics.
software could be provided from that arising from
combination of a previous NSF and an ESPRIT proposal
6.2.2 Three Year
Provide support for open system compound document email and
exchange including the following facilities: spreadsheets; integrity
authentication and non-repudiation of origin of document parts
confidentiality of document parts
6.2.3 Recommended
Hold a workshop to review the ongoing compound document research
development programmes in the two regions. One aim would be
recommend services for deployment in the short term. Another
be to propose work items in the NSF/DARPA and ESPRIT programmes
ensure a timely collaborative programme could start in mid-1991.
6.3 Directory
White pages services to assist network users to find email addresses
computer services and other on-line facilities are, at best,
lightly deployed in both the US and Europe. If networked
are to become infrastructural in nature, directory services must
Cerf, Kirstein, & Randell [Page 11]
RFC 1210 Network and Infrastructure User Requirements March 1991
widely implemented, deployed and easily accessible. In addition
working with international standards such as CCITT X.500, access
the installed base of white pages services (such as the US
service and the UK NRS service) is essential. These facilities
also needed to support key management for cryptographic
required for authenticity, integrity and confidentiality of email
other communications. Because there are different legal
organizational views of directory service information, it will
be critical to address organizational and international
in the sensitivity of such data and its accessibility
It is essential that directory service databases be built
maintained throughout the US and European research communities
6.3.1 One Year
(i) Get effective access to existing directory
(X.500 and others);
(ii) Put in data for relevant NSF/DARPA and ESPRIT communities
6.3.2 Three Year
(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
Initiate a formal collaboration between ongoing US and
(e.g., RARE WG3) efforts to implement and maintain the
directory databases
6.4 Interactive
Interactive access to service systems in the US and Europe is,
present, only partly feasible. One inhibiting factor is
protocol suites in use in the provision of such services.
implementation and deployment of common protocols, and the
of protocol translation gateways, are needed to improve
situation
Cerf, Kirstein, & Randell [Page 12]
RFC 1210 Network and Infrastructure User Requirements March 1991
6.4.1 One Year
Identify and install the best available interactive login
(using staging gateways, if necessary) on all interested sites
6.4.2 Three Year
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
suites
6.4.3 Recommended
(i) Identify for which protocol suites interactive login will
supported
(ii) Determine mechanisms for good performance in staged
(i.e., in which it is necessary to login and then
manually new connections from the intermediate gateways);
(iii) Develop a cooperative effort on authentication and
support
6.5 File
File transfers are not easily achieved in the multi-
environment, and long files cannot be transferred reliably.
movement of files through staged, protocol-translating gateways
awkward and often unreliable. Performance of file transfer
varies substantially. Improvements in file transfer facilities
needed, but there should also be other forms of file service based
shared file systems
6.5.1 One Year
Develop or identify and install the best available file
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
Develop (or obtain) and deploy file transfer services with
(i) support for privacy, authentication and integrity
(ii) support for automatic staging through several file
relays
(iii) support for multi-party access of selected portions of
systems across multiple machines
6.5.3 Recommended
(i) In conjunction with RARE WG4 and IETF, identify best
products for multi-hop (staged) file transfer
(ii) Define and carry out comparative performance tests to
best available file transfer software, including checkpointing
(iii) Define and implement fuller multi-hop, multi-
facilities with automated staging, security and
facilities
(iv) Develop access control models, policies and mechanisms
support collaborative file access by ad hoc groups
6.6 Group Communication
Coordination of collaborative efforts can be substantially
through provision of mailing lists, bulletin boards and
databases. Setting up and managing such facilities, however
typically requires special knowledge and privileges. Making
possible to set up and operate such facilities easily and
special privileges would enhance the infrastructure of support
collaborative activities between the US and Europe (and within
region as well).
More advanced group communication services such as shared
with voice teleconferencing, distributed publishing
electronic libraries, and various forms of teleconferencing,
relieve some of the necessity for face-to-face meetings,
Cerf, Kirstein, & Randell [Page 14]
RFC 1210 Network and Infrastructure User Requirements March 1991
sufficiently reliable and easy to use. The prior use of
facilities make subsequent face-to-face meetings much more
also. Of course, time zone differences are a challenge to any real
time conferencing schemes, and are often the primary rationale
arranging face-to-face conferences which "force" participants
enter the same time zone for the duration of the meeting
6.6.1 One Year
(i) Provide administrative support for setting up and
email mailing lists, bulletin boards and shared databases
(ii) Provide facilities for multi-site interactive
including text, graphics, spreadsheets and program access
6.6.2 Three Year
(i) Provide intercontinental services based on more mature "
groupware" facilities including shared screens and
services
(ii) Extend interactive blackboard to include slow scan video, voice
animation, and using international standards where feasible
6.6.3 Recommended
(i) Form a support/working group on the use of tools, standards
facilities for group communication services
(ii) Initiate collaboration on advanced group communications (e.g.,
shared screens, distributed electronic publishing, etc.).
6.7 Video
Facilities for low bandwidth (under 1 Mb/s) interactive video/
conferencing (e.g., packet-based) are, at present, unavailable
support of intercontinental collaboration. Even two-
videoconferencing could be beneficial initially. The comments
the other seven working groups showed a strong interest in the use
videoconferencing, provided the travel to the relevant facilities
not exceed two hours. This should impact the eventual
plans for the facilities
Minimum facilities needed for video conferencing include at least 256
Kb/s across the Atlantic for each concurrent conferencing channel.
video codec, two cameras and three monitors are needed at each
along with suitable packetizing equipment if a packet-mode system
to be deployed. There exists at least one such system in use in
Cerf, Kirstein, & Randell [Page 15]
RFC 1210 Network and Infrastructure User Requirements March 1991
US, developed by DARPA and used regularly for
working group meetings. Another such system is just
commissioned (at University College London).
6.7.1 One Year
Deploy two-party videoconferencing facilities in at least four
on each continent
6.7.2 Three Year
Develop and deploy multi-party conferencing capability on a
scale on both continents, to make the facilities accessible
widely to the collaborators with less travel penalty
6.7.3 Recommended
(i) Install existing technology at a limited number of sites
both regions, in line with the desire to limit
mentioned above
(ii) Organize a workshop on packet/ISDN/ATM videoconferencing
6.8 Multimedia Computer Supported Group
The NSF has initiated an effort on collaboration
development and experimentation under the rubric: Collaboratory
Similar research is in progress under the ESPRIT programme.
the subject of the NIWG's discussions was designated
infrastructure support for the other research collaborations,
believe it is very appropriate to mount a collaborative
among US and European researchers, which would enhance
efforts and force both groups to come to grips with problems
supporting collaboration techniques across
distances
6.8.1 One Year
Harmonise the ESPRIT and NSF Collaboratory research programmes
6.8.2 Three Year
Set up a common, transatlantic testbed facility to
collaborative research programmes
6.8.3 Recommended
Set up a workshop to study the needs of a collaborative effort
Cerf, Kirstein, & Randell [Page 16]
RFC 1210 Network and Infrastructure User Requirements March 1991
provide intercontinental packet video, multimedia conferencing
computer supported collaborative group technology facilities.
workshop should propose actions which could be made the basis of
future harmonised ESPRIT and DARPA/NSF work programme
6.9 Access to Unique
A number of resources can be labelled unique in the scope
ESPRIT/DARPA/NSF or even on a worldwide basis. Their uniqueness
derive from their nature (e.g., large test facilities or a
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
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
access to the resources, connectivity to the users and
access speeds have to be provided, possibly together with
control facilities
The most demanding cases are those of newly developed products;
transitory uniqueness does not allow one to amortise costs
substantial periods as would be reasonable for large scale
like NCAR or CERN
6.9.1 One Year
(i) Identify appropriate unique transitory
(e.g., Touchstone);
(ii) Specify the provisions needed to make at least one
resource available
6.9.2 Three Year
Set up one or more significant transatlantic pilots
remote, secured access
6.9.3 Recommended
Organise a workshop dedicated to analysing the needs and defining
steps required to provide pilot access to one or more specific
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
Scientific visualization applications often involve
resources. These resources can span a complete range
sophistication, from simple hardcopy at one end to
rendering at the other end. Interactive graphics workstations
supercomputers and specialized scientific databases may all
involved in a single application. The scientist at a
should be able to view all of these resources as a single
resource, although they may be physically distributed
considerable distances. A typical example is a high
graphics workstation, a supercomputer and a network to connect
together, all with appropriate software. The workstation may
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
techniques, interfaces and software necessary to create
environment. In limited instances it already exists.
coordination of these efforts on both sides of the Atlantic would
desirable. Coordinating such efforts across the Atlantic will
necessary for effective collaboration in end-user
applications in a variety of disciplines to take place in the future
6.10.1 One Year
Identify the significant current development efforts in these
and determine which ones to support. Identify the areas
standards. Minimize duplication of effort and begin to
the techniques and software
6.10.2 Three Year
Establish mutually agreed upon standards. Demonstrate
distributed visualization applications
6.10.3 Recommended
Establish a working group to further refine and to implement the
year and three year targets and to identify additional
visualization topics that would benefit from coordinated efforts
Determine the appropriate mechanisms for supporting
collaborations
Cerf, Kirstein, & Randell [Page 18]
RFC 1210 Network and Infrastructure User Requirements March 1991
UNDERLYING
Most of the services described below are required to achieve
goals of reliability, availability and transparency of the
services
6.11 Network
Current network management technology and practice are not
to support large scale, international research networks. Time-
differences and lack of organizational operational network
agreements combine to make international network management a
challenge. To be effective, network management must operate on
campus-to-campus basis, since the campuses are the sources and
of traffic in the system
6.11.1 One Year
Put in place an administrative structure to coordinate
facilities manually and to plan technical solutions
6.11.2 Three Year
Develop and deploy technology for automating international
management
6.11.3 Recommended
(i) Convene an international research network operations
planning and management team to develop and
procedural and technical recommendations for
network management
(ii) Organize a set of international network operations
devoted to configuration management, fault detection
isolation and repair of network problems
(iii) Form one or more intercontinental Computer Emergency
Teams to coordinate response to attacks against hosts
networks and to develop procedures for collecting
evidence
6.12 Multi-protocol
Users depend on a variety of protocols to support their research
The international network infrastructure does not uniformly
the use of multiple protocols (e.g., DECNET, TCP/IP/ST, OSI) on
end-to-end basis. The use of various portions of the
Cerf, Kirstein, & Randell [Page 19]
RFC 1210 Network and Infrastructure User Requirements March 1991
network also may be restricted by policy, and this must
accommodated in implementing routing for campus-to-campus protocols
Support for campus-to-campus multi-protocol transmission and
is needed at a minimum of 64 Kb/s end-to-end - higher for the
of some of the services. Where the end-users have adopted
protocols, the intervening networks should not impede the
exploitation of the facilities available in the chosen
suite. Where different protocol suites are used, high
application-level gateways which can translate among protocols
needed also; to the greatest extent possible, these should
people to use their own procedures, even though they
communicating with services which use different ones. For
services, this will lead to a requirement to upgrade access,
possibly even transparent access (including protocol conversion),
at least 1.5 Mb/s between individual campuses in the US and Europe
6.12.1 One Year
(i) Support campus-to-campus communication for a subset
coexisting protocol suites (at least OSI and TCP/IP) at
minimum of 64 Kb/s
(ii) Deploy internationally supported versions of
application level (protocol-translating) gateways
6.12.2 Three Year
(i) Improve management and resource allocation for multi-
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
(i) Validate current multi-protocol solutions for intercontinental
and indeed campus-to-campus use
(ii) Collaborate on research and experimentation with multi-
routing and resource allocation
(iii) Make recommendations, to funders and national research
service providers, on technical solutions and standards
multi-protocol support
Cerf, Kirstein, & Randell [Page 20]
RFC 1210 Network and Infrastructure User Requirements March 1991
6.13 Client-Server
Among the more important computer communications techniques
on a widespread basis during the last decade is the client-
model of interprocess communication. This notion was
developed during the earliest stages of packet network
and dramatically enhanced with the invention of local area
(such as Ethernet) which could support very high speed, low
inter-computer exchanges. Applications of this concept range
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
environment; they are generally not well-supported in wide-area
intercontinental networks. Collaborative efforts between the US
Europe could be enhanced substantially by support for client-
services on an intercontinental basis. Such facilities would
collaborative use of distributed filing systems, X-
applications and other distributed computing applications.
capacity, low-delay channels will be needed on an
basis to support serious use of this technology. In addition
agreement must be reached on which protocols should be used
support this technology
6.13.1 One Year
(i) Provide limited bandwidth intercontinental X-Windows
for graphical user interfaces
(ii) Achieve agreements on intercontinental Remote Procedure
and Distributed File System protocols
(iii) Validate support of X-Windows under OSI and through
translating gateways
6.13.2 Three Year
(i) Achieve selective support for intercontinental
visualization
(ii) Achieve support for intercontinental RPC and Distributed
Systems
6.13.3 Recommended
(i) Convene workshops to achieve agreements on
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
validate performance through TCP/TPn protocol
gateways
(iii) Initiate collaboration on implementation and test
intercontinental RPC and distributed file systems
Section 6.14 Archival Storage for Distributed Computing
There are several major issues that must be addressed by
computing environments (DCEs) containing supercomputers.
of these issues is likely to evolve over the next five to ten years
One such issue is archival storage and bitfile management for
complete environment. Several problems have to be resolved
appropriately handle this situation. The first problem is
global-naming of bitfiles that are being moved through the
to/from the archive. Second, the file system hierarchy must
defined. Third, there is the question of how the DCE knows the
system hierarchy for which it is responsible, and the location of
boundary through which the network and the archival system operate
Lastly, there is the question how the file system hierarchy
divided across a DCE and within a supercomputer
A second issue in the DCE is the need for all nodes obtaining
storing data to know the storage media differences. For
systems, this requirement manifests itself both at the
nodes and at the supercomputer because of the differences in
physical media structure
The third issue is the delineation of the bitfile attributes.
relates to how the data must be maintained as it migrates through
hierarchy, as well as through the DCE. The bitfile
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
resides in time within the DCE. Section 6.15 discusses some of
possible meta-data representation methodologies that may be used
are not yet standardized
Another issue is the determination and implementation of the
policy that is to dictate data migration and allocation inside
DCE archival storage system
Several working committees are attacking the various
delineated above, and are trying to confront the difficulties
these environments. This work is progressing mostly in the
States. The IEEE Computer Society Technical Committee on
Cerf, Kirstein, & Randell [Page 22]
RFC 1210 Network and Infrastructure User Requirements March 1991
Storage Systems is in the process of developing a Computer
draft standard on data storage systems. The current working
provides a consistent terminology and an object-oriented design
defining storage subsystem components, whether they are being
around a single system or in a DCE. Other groups in the
community are currently dealing with the problems of data
within a distributed environment. This distributed environment
or may not include a supercomputer, but it almost always includes
high-volume storage system of some sort delineated as a "mass
system." This subject was not discussed long enough at the meeting
deduce one year or three year targets - indeed these may well be
by the relevant National working groups
6.14.1 Recommended
Convene an international workshop whose goals are
1. An understanding of the contents of the data storage
model that is nearly ready to be declared an official
guide
2. To continue discussion of the various system issues that
to be developed as a result of this model
3. To arrive at solutions to be proposed by vendors and users
implementations of Data Systems Storage Solutions which
modular, interconnectable, and standard
6.15 Data Representation and
The problem of data exchange between different computer
and operating systems has been existent since the deployment of
early computers. This problem has been exacerbated by the
of the client-server paradigm as the provider of
services. Distributed computer services require immediate
exchange. In the past, data was exchanged on some medium, such
tape, and could be examined at leisure. Ad hoc data
routines were created to process the data, and were often embedded
the programs using the data. Data exchange in the client-
paradigm does not permit this leisurely data examination. Both
client and the server must be able to "call" software that
guaranteed to convert the exchanged data "on the spot."
guarantee also implies a standard format rather than the ability
convert all formats because it would be impossible to
multiple architecture conversion software and, of course, the size
such conversion software would be enormous
The issue of data exchange has been addressed resulting in many
Cerf, Kirstein, & Randell [Page 23]
RFC 1210 Network and Infrastructure User Requirements March 1991
exchange software packages. A few of the currently more
packages are XDR, HDF, NetCDF, PostScript and CCSDS. Each of
packages addresses a specific type of data. Some address
data; one addresses the general encoding of "display" information
Some of these packages address various numerical representations
computers. It is unclear whether any existing package could
should be extended to solve all data exchange problems. However,
more realistic approach would be a collection of data
packages formed as the "standard."
This item was discussed only briefly at the meeting, so that no
year or three year targets were specified
6.15.1 Recommended
It is proposed that an international working group be established
recommend a standard collection of software encompassing a variety
data representations. This working group should address the issue
embedding identification of the data representations in the
stream to allow for later extensions. The working group would
initially to establish a work-scope and to assign the members tasks
The group would schedule subsequent meetings (probably annually)
finalise the current data exchange standard recommendation, and
define new work scopes. The working group would also make
recommendation known to other standards bodies such as X/OPEN, UI
OSF, X Consortium, NIST, IEEE, ACM, etc
6.16 Transatlantic Links and Continental
At present, there is inadequate transatlantic capacity to
research collaborations involving significant amounts of computer
mediated communication. There is also considerable room
improvement in the distribution of capacity and enhancement
reliability of network service in Europe. Moreover, the point
made strongly that collaboration would be very difficult unless
infrastructure on the two sides was broadly comparable - even if
transatlantic capacity was per force lower. Moreover, it was
emphasised that there was a large requirement for transatlantic
flow in other fields - e.g., Space Science, Atmospheric Science
High Energy Physics. In the US these needs are being aggregated
the National Research and Engineering Network; such aggregation
required also in Europe and on a transatlantic basis
6.16.1 One Year
(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
(i) Install 2 additional 1.5 Mb/s (or higher) transatlantic
by 1993;
(ii) Determine feasibility of sharing much higher
intercontinental links (e.g., in the 51 Mb/s STS-1 range).
6.16.3 Recommended
(i) Use existing joint US/European coordination
(e.g., CCIRN) for planning of higher speed,
links
(ii) Convene a special CEC/DARPA/NSF task force to consider
higher speed transatlantic capacity sharing options
(iii) Ensure that there is an infrastructure in Europe,
the US one, providing the majority of relevant campuses
at speeds approaching 1.5 Mb/s
(iv) Encourage European user groups with high data
requirements to aggregate their data transmission facilities
Attempt to integrate European application projects (like
RACE Applications Pilots) to assist in providing an
European distribution network with 10 - 500 Mb/s access
appropriate campuses
7. LONGER TERM
Although these were not discussed in any detail, for lack of time
the following areas emerged as of interest for longer
collaborative work
(i) Electronic Library Services (includes an
intellectual property rights component);
(ii) Multi-media Computer Supported Collaborative Work
(iii) Portable Computing/Communications Environments
(iv) Distributed Computing using heterogeneous machines and
facilities
(v) Compatible approaches to computer networks with Gb/s
speeds, and appropriate systems switching, transmission
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
have immense medium term benefits to the other communities -
would integrate well with the ongoing research programmes on
sides of the Atlantic
8.
The largest single obstacle to the pr