As per Relevance of the word security, we have this rfc below:
Network Working Group D.
Request for Comments: 1287
L.
V.
R.
R.
UC
December 1991
Towards the Future Internet
Status of this
This informational RFC discusses important directions for
future evolution of the Internet architecture, and suggests
towards the desired goals. It is offered to the Internet
for discussion and comment. This memo provides information for
Internet community. It does not specify an Internet standard
Distribution of this memo is unlimited
Table of
1. INTRODUCTION ................................................. 2
2. ROUTING AND ADDRESSING ....................................... 5
3. MULTI-PROTOCOL ARCHITECTURES ................................. 9
4. SECURITY ARCHITECTURE ........................................ 13
5 TRAFFIC CONTROL AND STATE .................................... 16
6. ADVANCED APPLICATIONS ........................................ 18
7. REFERENCES ................................................... 21
APPENDIX A. Setting the Stage .................................... 22
APPENDIX B. Group Membership ..................................... 28
Security Considerations .......................................... 29
Authors' Addresses ............................................... 29
Clark, Chapin, Cerf, Braden, & Hobby [Page 1]
RFC 1287 Future of Internet Architecture December 1991
1.
1.1 The Internet
The Internet architecture, the grand plan behind the TCP/
protocol suite, was developed and tested in the late 1970s by
small group of network researchers [1-4]. Several
features were added to the architecture during the early 1980's --
subnetting, autonomous systems, and the domain name system [5,6].
More recently, IP multicasting has been added [7].
Within this architectural framework, the Internet Engineering
Force (IETF) has been working with great energy and
to engineer, define, extend, test, and standardize protocols
the Internet. Three areas of particular importance have
routing protocols, TCP performance, and network management
Meanwhile, the Internet infrastructure has continued to grow at
astonishing rate. Since January 1983 when the ARPANET
switched from NCP to TCP/IP, the vendors, managers, wizards,
researchers of the Internet have all been laboring mightily
survive their success
A set of the researchers who had defined the Internet
formed the original membership of the Internet Activities
(IAB). The IAB evolved from a technical advisory group set up
1981 by DARPA to become the general technical and policy
body for the Internet. IAB membership has changed over the
to better represent the changing needs and issues in the
community, and more recently, to reflect the
of the Internet, but it has retained an institutional concern
the protocol architecture
The IAB created the Internet Engineering Task Force (IETF)
carry out protocol development and engineering for the Internet
To manage the burgeoning IETF activities, the IETF chair set
the Internet Engineering Steering Group (IESG) within the IETF
The IAB and IESG work closely together in ratifying
standards developed within the IETF
Over the past few years, there have been increasing signs
strains on the fundamental architecture, mostly stemming
continued Internet growth. Discussions of these
reverberate constantly on many of the major mailing lists
1.2
The priority for solving the problems with the current
architecture depends upon one's view of the future relevance
Clark, Chapin, Cerf, Braden, & Hobby [Page 2]
RFC 1287 Future of Internet Architecture December 1991
TCP/IP with respect to the OSI protocol suite. One view has
that we should just let the TCP/IP suite strangle in its success
and switch to OSI protocols. However, many of those who
worked hard and successfully on Internet protocols, products,
service are anxious to try to solve the new problems within
existing framework. Furthermore, some believe that OSI
will suffer from versions of many of the same problems
To begin to attack these issues, the IAB and the IESG held a one
day joint discussion of Internet architectural issues in
1991. The framework for this meeting was set by Dave Clark (
Appendix A for his slides). The discussion was spirited
provocative, and at times controversial, with a lot of soul
searching over questions of relevance and future direction.
major result was to reach a consensus on the following four
assumptions regarding the networking world of the next 5-10 years
(1) The TCP/IP and OSI suites will coexist for a long time
There are powerful political and market forces as well
some technical advantages behind the introduction of the
suite. However, the entrenched market position of the TCP/
protocols means they are very likely to continue in
for the foreseeable future
(2) The Internet will continue to include diverse networks
services, and will never be comprised of a single
technology
Indeed, the range of network technologies and
that are connected into the Internet will increase over
next decade
(3) Commercial and private networks will be incorporated, but
cannot expect the common carriers to provide the
service. There will be mix of public and private networks
common carriers and private lines
(4) The Internet architecture needs to be able to scale to 10**9
networks
The historic exponential growth in the size of the
will presumably saturate some time in the future,
forecasting when is about as easy as forecasting the
economy. In any case, responsible engineering requires
architecture that is CAPABLE of expanding to a worst-
size. The exponent "9" is rather fuzzy; estimates
varied from 7 to 10.
Clark, Chapin, Cerf, Braden, & Hobby [Page 3]
RFC 1287 Future of Internet Architecture December 1991
1.3 Beginning a Planning
Another result of the IAB and IESG meeting was the following
of the five most important areas for architectural evolution
(1) Routing and
This is the most urgent architectural problem, as it
directly involved in the ability of the Internet to
to grow successfully
(2) Multi-Protocol
The Internet is moving towards widespread support of both
TCP/IP and the OSI protocol suites. Supporting both
raises difficult technical issues, and a plan -- i.e.,
architecture -- is required to increase the chances
success. This area was facetiously dubbed "making
problem harder for the good of mankind."
Clark had observed that translation gateways (e.g.,
gateways) are very much a fact of life in Internet
but are not part of the architecture or planning. The
discussed the possibility of building the architecture
the partial connectivity that such gateways imply
(3) Security
Although military security was considered when the
architecture was designed, the modern security issues
much broader, encompassing commercial requirements as well
Furthermore, experience has shown that it is difficult to
security to a protocol suite unless it is built into
architecture from the beginning
(4) Traffic Control and
The Internet should be extended to support "real-time
applications like voice and video. This will require
packet queueing mechanisms in gateways -- "traffic control
-- and additional gateway state
(5) Advanced
As the underlying Internet communication mechanism matures
there is an increasing need for innovation
standardization in building new kinds of applications
Clark, Chapin, Cerf, Braden, & Hobby [Page 4]
RFC 1287 Future of Internet Architecture December 1991
The IAB and IESG met again in June 1991 at SDSC and devoted
full days to a discussion of these five topics. This meeting
which was called somewhat perversely the "Architecture Retreat",
was convened with a strong resolve to take initial steps
planning evolution of the architecture. Besides the IAB and IESG
the group of 32 people included the members of the
Steering Group (IRSG) and a few special guests. On the
day, the Retreat broke into groups, one for each of the
areas. The group membership is listed in Appendix B
This document was assembled from the reports by the chairs
these groups. This material was presented at the Atlanta
meeting, and appears in the minutes of that meeting [8].
2. ROUTING AND
Changes are required in the addressing and routing structure of IP
deal with the anticipated growth and functional evolution of
Internet. We expect that
o The Internet will run out of certain classes of IP
addresses, e.g., B addresses
o The Internet will run out of the 32-bit IP address
altogether, as the space is currently subdivided and managed
o The total number of IP network numbers will grow to the
where reasonable routing algorithms will not be able to
routing based upon network numbers
o There will be a need for more than one route from a source to
destination, to permit variation in TOS and policy conformance
This need will be driven both by new applications and by
transit services. The source, or an agent acting for
source, must control the selection of the route options
2.1 Suggested
There is general agreement on the approach needed to deal
these facts
(a) We must move to an addressing scheme in which network
are aggregated into larger units as the basis for routing
An example of an aggregate is the Autonomous System, or
Administrative Domain (AD).
Aggregation will accomplish several goals: define
where policy is applied, control the number of
Clark, Chapin, Cerf, Braden, & Hobby [Page 5]
RFC 1287 Future of Internet Architecture December 1991
elements, and provide elements for network management.
believe that it must be possible to further
aggregates, as in a nesting of ADs
(b) We must provide some efficient means to compute
routes, and some general means to compute "special" routes
The general approach to special routes will be some form
route setup specified by a "source route".
There is not full agreement on how ADs may be expected to
aggregated, or how routing protocols should be organized to
with the aggregation boundaries. A very general scheme may
used [ref. Chiappa], but some prefer a scheme that more
and defines the expected network model
To deal with the address space exhaustion, we must either
the address space or else reuse the 32 bit field ("32bf")
different parts of the net. There are several possible
formats that might make sense, as described in the next section
Perhaps more important is the question of how to migrate to
new scheme. All migration plans will require that some
(or other components inside the Internet) be able to
headers to accommodate hosts that handle only the old or format
only the new format. Unless the need for such format
can be inferred algorithmically, migration by itself will
some sort of setup of state in the conversion element
We should not plan a series of "small" changes to
architecture. We should embark now on a plan that will take
past the exhaustion of the address space. This is a more long
range act of planning than the Internet community has
recently, but the problems of migration will require a long
time, and it is hard to see an effective way of dealing with
of the more immediate problems, such as class B exhaustion, in
way that does not by itself take a long time. So, once we
on a plan of change, it should take us all the way to
the current 32-bit global address space. (This conclusion
subject to revision if, as is always possible, some very
idea surfaces that is quick to deploy and gives us some
room. We do not mean to discourage creative thinking
short-term actions. We just want to point out that even
changes take a long time to deploy.)
Conversion of the address space by itself is not enough. We
at the same time provide a more scalable routing architecture,
tools to better manage the Internet. The proposed approach is
Clark, Chapin, Cerf, Braden, & Hobby [Page 6]
RFC 1287 Future of Internet Architecture December 1991
ADs as the unit of aggregation for routing. We already
partial means to do this. IDPR does this. The OSI version of
(IDRP) does this. BGP could evolve to do this. The
facility needed is a global table that maps network numbers
ADs
For several reasons (special routes and address conversion,
well as accounting and resource allocation), we are moving from
"stateless" gateway model, where only precomputed routes
stored in the gateway, to a model where at least some of
gateways have per-connection state
2.2 Extended IP Address
There are three reasonable choices for the extended IP
format
A) Replace the 32 bit field (32bf) with a field of the same
but with different meaning. Instead of being
unique, it would now be unique only within some
region (an AD or an aggregate of ADs). Gateways on
boundary would rewrite the address as the packet crossed
boundary
Issues: (1) addresses in the body of packets must be
and rewritten; (2) the host software need not be changed; (3)
some method (perhaps a hack to the DNS) must set up
address mappings
This scheme is due to Van Jacobson. See also the work
Paul Tsuchiya on NAT
B) Expand the 32bf to a 64 bit field (or some other new size),
and use the field to hold a global host address and an AD
that host
This choice would provide a trivial mapping from the host
the value (the AD) that is the basis of routing.
routes (those selected on the basis of destination
without taking into account the source address as well)
be selected directly from the packet address, as is
today, without any prior setup
3) Expand the 32bf to a 64 bit field (or some other new size),
and use the field as a "flat" host identifier.
connection setup to provide routers with the mapping
host id to AD, as needed
Clark, Chapin, Cerf, Braden, & Hobby [Page 7]
RFC 1287 Future of Internet Architecture December 1991
The 64 bits can now be used to simplify the problem
allocating host ids, as in Ethernet addresses
Each of these choices would require an address re-writing
as a part of migration. The second and third require a change
the IP header, so host software must change
2.3 Proposed
The following actions are proposed
A) Time
Construct a specific set of estimates for the time at
the various problems above will arise, and construct
corresponding time-line for development and deployment of
new addressing/routing architecture. Use this time line as
basis for evaluating specific proposals for changes. This
a matter for the IETF
B) New Address
Explore the options for a next generation address format
develop a plan for migration. Specifically, construct
prototype gateway that does address mapping. Understand
complexity of this task, to guide our thinking
migration options
C) Routing on
Take steps to make network aggregates (ADs) the basis
routing. In particular, explore the several options for
global table that maps network numbers to ADs. This is
matter for the IETF
D) Policy-Based
Continue the current work on policy based routing. There
several specific objectives
- Seek ways to control the complexity of setting
(this is a human interface issue, not an
complexity issue).
- Understand better the issues of maintaining
state in gateways
- Understand better the issues of connection state setup
Clark, Chapin, Cerf, Braden, & Hobby [Page 8]
RFC 1287 Future of Internet Architecture December 1991
E) Research on Further
Explore, as a research activity, how ADs should be
into still larger routing elements
- Consider whether the architecture should define
"role" of an AD or an aggregate
- Consider whether one universal routing method
distinct methods should be used inside and outside
and aggregates
Existing projects planned for DARTnet will help resolve several
these issues: state in gateways, state setup, address mapping
accounting and so on. Other experiments in the R&D community
bear on this area
3. MULTI-PROTOCOL
Changing the Internet to support multiple protocol suites leads
three specific architectural questions
o How exactly will we define "the Internet"?
o How would we architect an Internet with n>1 protocol suites
regardless of what the suites are
o Should we architect for partial or filtered connectivity
o How to add explicit support for application gateways into
architecture
3.1 What is the "Internet"?
It is very difficult to deal constructively with the issue of "
multi-protocol Internet" without first determining what we
"the Internet" is (or should be). We distinguish "the Internet",
a set of communicating systems, from "the Internet community",
set of people and organizations. Most people would accept a
definition of the latter as "the set of people who
themselves to be part of the Internet community". However,
such "sociological" definition of the Internet itself is likely
be useful
Not too long ago, the Internet was defined by IP connectivity (
and ICMP were - and still are - the only "required"
protocols). If I could PING you, and you could PING me, then
were both on the Internet, and a satisfying working definition
Clark, Chapin, Cerf, Braden, & Hobby [Page 9]
RFC 1287 Future of Internet Architecture December 1991
the Internet could be constructed as a roughly transitive
of IP-speaking systems. This model of the Internet was simple
uniform, and - perhaps most important - testable. The IP
connectivity model clearly distinguished systems that were "on
Internet" from those that were not
As the Internet has grown and the technology on which it is
has gained widespread commercial acceptance, the sense of what
means for a system to be "on the Internet" has changed,
include
* Any system that has partial IP connectivity, restricted
policy filters
* Any system that runs the TCP/IP protocol suite, whether
not it is actually accessible from other parts of
Internet
* Any system that can exchange RFC-822 mail, without
intervention of mail gateways or the transformation of
objects
* Any system with e-mail connectivity to the Internet,
or not a mail gateway or mail object transformation
required
These definitions of "the Internet", are still based on
original concept of connectivity, just "moving up the stack".
We propose instead a new definition of the Internet, based on
different unifying concept
* "Old" Internet concept: IP-based
The organizing principle is the IP address, i.e., a
network address space
* "New" Internet concept: Application-based
The organizing principle is the domain name system
directories, i.e., a common - albeit necessarily multiform -
application name space
This suggests that the idea of "connected status", which
traditionally been tied to the IP address(via network numbers
should instead be coupled to the names and related
information contained in the distributed Internet directory
Clark, Chapin, Cerf, Braden, & Hobby [Page 10]
RFC 1287 Future of Internet Architecture December 1991
A naming-based definition of "the Internet" implies a much
Internet community, and a much more dynamic (and unpredictable
operational Internet. This argues for an Internet
based on adaptability (to a broad spectrum of possible
developments) rather than anticipation
3.2 A Process-Based Model of the Multiprotocol
Rather than specify a particular "multi-protocol Internet",
embracing a pre-determined number of specific
architectures, we propose instead a process-oriented model of
Internet, which accommodates different protocol
according to the traditional "things that work" principle
A process-oriented Internet model includes, as a basic postulate
the assertion that there is no *steady-state* "multi-
Internet". The most basic forces driving the evolution of
Internet are pushing it not toward multi-protocol diversity,
toward the original state of protocol-stack uniformity (
it is unlikely that it will ever actually get there). We
represent this tendency of the Internet to evolve
homogeneity as the most "thermodynamically stable" state
describing four components of a new process-based
architecture
Part 1: The core Internet
This is the traditional TCP/IP-based architecture. It is
"magnetic center" of Internet evolution, recognizing that (a
homogeneity is still the best way to deal with diversity
an internetwork, and (b) IP connectivity is still the
basic model of the Internet (whether or not the actual
of IP ubiquity can be achieved in practice in a
operational Internet).
"In the beginning", the Internet architecture consisted only
this first part. The success of the Internet, however,
carried it beyond its uniform origins; ubiquity and
have been sacrificed in order to greatly enrich the Internet "
pool".
Two additional parts of the new Internet architecture express
ways in which the scope and extent of the Internet have
expanded
Part 2: Link
Here physical resources -- transmission media,
Clark, Chapin, Cerf, Braden, & Hobby [Page 11]
RFC 1287 Future of Internet Architecture December 1991
interfaces, perhaps some low-level (link) protocols --
shared by multiple, non-interacting protocol suites.
part of the architecture recognizes the necessity
convenience of coexistence, but is not concerned
interoperability; it has been called "ships in the night"
"S.I.N.".
Coexisting protocol suites are not, of course,
isolated in practice; the ships passing in the night
issues of management, non-interference, coordination,
fairness in real Internet systems
Part 3: Application
Absent ubiquity of interconnection (i.e., interoperability
the "underlying stacks"), it is still possible to
ubiquitous application functionality by arranging for
essential semantics of applications to be conveyed
disjoint communities of Internet systems. This can
accomplished by application relays, or by user agents
present a uniform virtual access method to
application services by expressing only the shared semantics
This part of the architecture emphasizes the ultimate role
the Internet as a basis for communication among applications
rather than as an end in itself. To the extent that
enables a population of applications and their users to
from one underlying protocol suite to another
unacceptable loss of functionality, it is also a "
enabler".
Adding parts 2 and 3 to the original Internet architecture is
best a mixed blessing. Although they greatly increase the
of the Internet and the size of the Internet community, they
introduce significant problems of complexity, cost,
management, and they usually represent a loss of
(particularly with respect to part 3). Parts 2 and 3
unavoidable, but essentially undesirable, departures from
homogeneity represented by part 1. Some functionality is lost
and additional system complexity and cost is endured, in order
expand the scope of the Internet. In a perfect world, however
the Internet would evolve and expand without these penalties
There is a tendency, therefore, for the Internet to evolve
favor of the homogeneous architecture represented by part 1,
away from the compromised architectures of parts 2 and 3. Part 4
expresses this tendency
Clark, Chapin, Cerf, Braden, & Hobby [Page 12]
RFC 1287 Future of Internet Architecture December 1991
Part 4: Hybridization/Integration
Part 4 recognizes the desirability of integrating
elements from different Internet protocol architectures
form hybrids that reduce the variability and complexity
the Internet system. It also recognizes the desirability
leveraging the existing Internet infrastructure to
the absorption of "new stuff" into the Internet, applying
"new stuff" the established Internet practice of test
evaluate, adopt
This part expresses the tendency of the Internet, as
system, to attempt to return to the original "state of grace
represented by the uniform architecture of part 1. It is
force acting on the evolution of the Internet, although
Internet will never actually return to a uniform state at
point in the future
According to this dynamic process model, running X.400 mail
RFC 1006 on a TCP/IP stack, integrated IS-IS routing,
gateways, and the development of a single common successor to
IP and CLNP protocols are all examples of "good things".
represent movement away from the non-uniformity of parts 2 and 3
towards greater homogeneity, under the influence of the "
field" asserted by part 1, following the hybridization dynamic
part 4.
4. SECURITY
4.1 Philosophical
The principal themes for development of an Internet
architecture are simplicity, testability, trust, technology
security perimeter identification
* There is more to security than protocols and
methods
* The security architecture and policies should be
enough to be readily understood. Complexity
misunderstanding and poor implementation
* The implementations should be testable to determine if
policies are met
* We are forced to trust hardware, software and people to
any security architecture function. We assume that
technical instruments of security policy enforcement are
Clark, Chapin, Cerf, Braden, & Hobby [Page 13]
RFC 1287 Future of Internet Architecture December 1991
least as powerful as modern personal computers and
stations; we do not require less capable components to
self-protecting (but might apply external remedies such
link level encryption devices).
* Finally, it is essential to identify security perimeters
which protection is to be effective
4.2 Security
There were four possible security perimeters: link level
net/subnet level, host level, and process/application level.
imposes different requirements, can admit different techniques
and makes different assumptions about what components of
system must be trusted to be effective
Privacy Enhanced Mail is an example of a process level
system; providing authentication and confidentiality for SNMP
another example. Host level security typically means applying
external security mechanism on the communication ports of a
computer. Network or subnetwork security means applying
external security capability at the gateway/router(s) leading
the subnetwork to the "outside". Link-level security is
traditional point-to-point or media-level (e.g., Ethernet
encryption mechanism
There are many open questions about network/subnetwork
protection, not the least of which is a potential mismatch
host level (end/end) security methods and methods at
network/subnetwork level. Moreover, network level protection
not deal with threats arising within the security perimeter
Applying protection at the process level assumes that
underlying scheduling and operating system mechanisms can
trusted not to prevent the application from applying security
appropriate. As the security perimeter moves downward in
system architecture towards the link level, one must make
assumptions about the security threat to make an argument
enforcement at a particular perimeter is effective. For example
if only link-level encryption is used, one must assume
attacks come only from the outside via communications lines,
hosts, switches and gateways are physically protected, and
people and software in all these components are to be trusted
4.3 Desired Security
We need authenticatable distinguished names if we are to
discretionary and non-discretionary access control at
Clark, Chapin, Cerf, Braden, & Hobby [Page 14]
RFC 1287 Future of Internet Architecture December 1991
and lower levels in the system. In addition, we need
for integrity (anti-modification, anti-spoof and anti-
defenses), confidentiality, and prevention of denial-of-service
For some situations, we may also need to prevent repudiation
message transmission or to prevent covert channels
We have some building blocks with which to build the
security system. Cryptographic algorithms are available (e.g.,
Data Encryption Standard, RSA, El Gamal, and possibly other
key and symmetric key algorithms), as are hash functions such
MD2 and MD5.
We need Distinguished Names (in the OSI sense) and are very
in need of an infrastructure for the assignment of
identifiers, together with widespread directory services
making them known. Certificate concepts binding
names to public keys and binding distinguished names
capabilities and permissions may be applied to good advantage
At the router/gateway level, we can apply address and
filters and other configuration controls to help fashion
security system. The proposed OSI Security Protocol 3 (SP3)
Security Protocol 4 (SP4) should be given serious consideration
possible elements of an Internet security architecture
Finally, it must be observed that we have no good solutions
safely storing secret information (such as the secret component
a public key pair) on systems like PCs or laptop computers
are not designed to enforce secure storage
4.4 Proposed
The following actions are proposed
A) Security Reference
A Security Reference Model for the Internet is needed, and
should be developed expeditiously. This model
establish the target perimeters and document the
of the security architecture
B) Privacy-Enhanced Mail (PEM
For Privacy Enhanced Mail, the most critical steps seem to
the installation of (1) a certificate generation
management infrastructure, and (2) X.500 directory
to provide access to public keys via distinguished names
Serious attention also needs to be placed on any
Clark, Chapin, Cerf, Braden, & Hobby [Page 15]
RFC 1287 Future of Internet Architecture December 1991
imposed by patent and export restrictions on the
of this system
C) Distributed System
We should examine security methods for distributed
applications, in both simple (client/server) and
(distributed computing environment) cases. For example,
utility of certificates granting permissions/capabilities
objects bound to distinguished names should be examined
D) Host-Level
SP4 should be evaluated for host-oriented security, but SP
should also be considered for this purpose
E) Application-Level
We should implement application-level security services,
for their immediate utility (e.g., PEM, SNMP authentication
and also to gain valuable practical experience that
inform the refinement of the Internet security architecture
5. TRAFFIC CONTROL AND
In the present Internet, all IP datagrams are treated equally.
datagram is forwarded independently, regardless of any
it has to other packets for the same connection, for the
application, for the same class of applications, or for the same
class. Although Type-of-Service and Precedence bits are defined
the IP header, these are not generally implemented, and in fact it
not clear how to implement them
It is now widely accepted that the future Internet will need
support important applications for which best-effort is
sufficient -- e.g., packet video and voice for teleconferencing
This will require some "traffic control" mechanism in routers
controlled by additional state, to handle "real-time" traffic
5.1 Assumptions and
o ASSUMPTION: The Internet will need to support
guarantees for particular subsets of the traffic
Unfortunately, we are far from being able to give precise
to the terms "performance", "guarantees", or "subsets" in
statement. Research is still needed to answer these questions
Clark, Chapin, Cerf, Braden, & Hobby [Page 16]
RFC 1287 Future of Internet Architecture December 1991
o The default service will continue to be the current "best
effort" datagram delivery, with no service guarantees
o The mechanism of a router can be separated into (1)
forwarding path and (2) the control computations (e.g.,
routing) which take place in the background
The forwarding path must be highly optimized, sometimes
hardware-assist, and it is therefore relatively costly
difficult to change. The traffic control mechanism
in the forwarding path, under the control of state created
routing and resource control computations that take place
background. We will have at most one shot at changing
forwarding paths of routers, so we had better get it
the first time
o The new extensions must operate in a highly
environment, in which some parts will never
guarantees. For some hops of a path (e.g., a high-
LAN), "over-provisioning" (i.e., excess capacity) will
adequate service for real-time traffic, even when
resource reservation is unavailable
o Multicast distribution is probably essential
5.2 Technical
There are a number of technical issues to be resolved, including
o Resource
To support real-time traffic, resources need to be
in each router along the path from source to destination
Should this new router state be "hard" (as in connections)
"soft" (i.e., cached state)?
o Resource binding vs. route
Choosing a path from source to destination is
performed using a dynamic routing protocol. The
binding and the routing might be folded into a single
process, or they might be performed
independently. There is a tradeoff between complexity
efficiency
o Alternative multicast
IP multicasting uses a model of logical addressing in
Clark, Chapin, Cerf, Braden, & Hobby [Page 17]
RFC 1287 Future of Internet Architecture December 1991
targets attach themselves to a group. In ST-2, each host
a multicast session includes in its setup packet an
list of target addresses. Each of these approaches
advantages and drawbacks; it is not currently clear
will prevail for n-way teleconferences
o Resource Setup vs. Inter-AD
Resource guarantees of whatever flavor must hold across
arbitrary end-to-end path, including multiple ADs. Hence
any resource setup mechanism needs to mesh smoothly with
path setup mechanism incorporated into IDPR
o
The resource guarantee subsets ("classes") may be
units for accounting
5.3 Proposed
The actions called for here are further research on the
issues listed above, followed by development and
of appropriate protocols. DARTnet, the DARPA Research
network, will play an important role in this research
6. ADVANCED
One may ask: "What network-based applications do we want, and
don't we have them now?" It is easy to develop a large list
potential applications, many of which would be based on
client/server model. However, the more interesting part of
question is: "Why haven't people done them already?" We believe
answer to be that the tools to make application writing easy just
not exist
To begin, we need a set of common interchange formats for a number
data items that will be used across the network. Once these
data formats have been defined, we need to develop tools that
applications can use to move the data easily
6.1 Common Interchange
The applications have to know the format of information that
are exchanging, for the information to have any meaning.
following format types are to concern
(1) Text - Of the formats in this list, text is the most stable
but today's international Internet has to address the
Clark, Chapin, Cerf, Braden, & Hobby [Page 18]
RFC 1287 Future of Internet Architecture December 1991
of character sets other than USASCII
(2) Image - As we enter the "Multimedia Age", images will
increasingly important, but we need to agree on how
represent them in packets
(3) Graphics - Like images, vector graphic information needs
common definition. With such a format we could
things like architectural blueprints
(4) Video - Before we can have a video window running on
workstation, we need to know the format of that
information coming over the network
(5) Audio/Analog - Of course, we also need the audio to go
the video, but such a format would be used for
of all types of analog signals
(6) Display - Now that we are opening windows on our workstation
we want to open a window on another person's workstation
show her some data pertinent to the research project, so
we need a common window display format
(7) Data Objects - For inter-process communications we need
agree on the formats of things like integers, reals, strings
etc
Many of these formats are being defined by other, often
other, standards organizations. We need to agree on one
per category for the Internet
6.2 Data Exchange
Applications will require the following methods of data exchange
(1) Store and
Not everyone is on the network all the time. We need
standard means of providing an information flow
sometimes-connected hosts, i.e., we need a common store-and
forward service. Multicasting should be included in such
service
(2) Global File
Much of the data access over the network can be broken
to simple file access. If you had a real global file
where you access any file on the Internet (assuming you
Clark, Chapin, Cerf, Braden, & Hobby [Page 19]
RFC 1287 Future of Internet Architecture December 1991
permission), would you ever need FTP
(3) Inter-process
For a true distributed computing environment, we need
means to allow processes to exchange data in a
method over the network. This requirement encompasses RPC
APIs, etc
(4) Data
Many applications need to send the same information to
other hosts. A standard and efficient method is needed
accomplish this
(5) Database
For good information exchange, we need to have a
means for accessing databases. The Global File System can
you to the data, but the database access methods will
you about its structure and content
Many of these items are being addressed by other organizations
but for Internet interoperability, we need to agree on the
for the Internet
Finally, advanced applications need solutions to the problems
two earlier areas in this document. From the Traffic Control
State area, applications need the ability to transmit real-
data. This means some sort of expectation level for data
within a certain time frame. Applications also require
authentication and access control systems from the Security area
Much of the usefulness of today's Internet applications is
due to the lack of trust and security. This needs to be
for tomorrow's applications
Clark, Chapin, Cerf, Braden, & Hobby [Page 20]
RFC 1287 Future of Internet Architecture December 1991
7.
[1] Cerf, V. and R. Kahn, "A Protocol for Packet
Intercommunication," IEEE Transactions on Communication,
1974.
[2] Postel, J., Sunshine, C., and D. Cohen, "The ARPA
Protocol," Computer Networks, Vol. 5, No. 4, July 1981.
[3] Leiner, B., Postel, J., Cole, R., and D. Mills, "The
Internet Protocol Suite," Proceedings INFOCOM 85, IEEE
Washington DC, March 1985. Also in: IEEE
Magazine, March 1985.
[4] Clark, D., "The Design Philosophy of the DARPA
Protocols", Proceedings ACM SIGCOMM '88, Stanford, California
August 1988.
[5] Mogul, J., and J. Postel, "Internet Standard
Procedure", RFC 950, USC/Information Sciences Institute,
1985.
[6] Mockapetris, P., "Domain Names - Concepts and Facilities",
1034, USC/Information Sciences Institute, November 1987.
[7] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[8] "Proceedings of the Twenty-First Internet Engineering
Force", Bell-South, Atlanta, July 29 - August 2, 1991.
Clark, Chapin, Cerf, Braden, & Hobby [Page 21]
RFC 1287 Future of Internet Architecture December 1991
APPENDIX A: Setting the
Slide 1
WHITHER THE INTERNET
OPTIONS FOR
IAB/IESG -- Jan 1990
David D.
__________________________________________________________________
Slide 2
SETTING THE TOPIC OF
Goals
o Establish a common frame of understanding
IAB, IESG and the Internet community
o Understand the set of problems to be solved
o Understand the range of solutions open to us
o Draw some conclusions, or
"meta-conclusions".
Clark, Chapin, Cerf, Braden, & Hobby [Page 22]
RFC 1287 Future of Internet Architecture December 1991
__________________________________________________________________
Slide 3
SOME CLAIMS -- MY
We have two different goals
o Make it possible to build "The Internet
o Define a protocol suite called
Claim: These goals have very different implications
The protocols are but a means, though a powerful one
Claim: If "The Internet" is to succeed and grow, it
require specific design efforts. This need will
for at least another 10 years
Claim: Uncontrolled growth could lead to chaos
Claim: A grass-roots solution seems to be the
means to success. Top-down mandates are powerless
__________________________________________________________________
Slide 4
OUTLINE OF
1) The problem space and the solution space
2) A set of specific questions -- discussion
3) Return to top-level questions -- discussion
4) Plan for action -- meta discussion
Try to separate functional requirements from technical approach
Understand how we are bounded by our problem space and
solution space
Is architecture anything but protocols
Clark, Chapin, Cerf, Braden, & Hobby [Page 23]
RFC 1287 Future of Internet Architecture December 1991
__________________________________________________________________
Slide 5
WHAT IS THE PROBLEM SPACE
Routing and addressing
How big, what topology, and what routing model
Getting big
User services, what technology for host and nets
Divestiture of the Internet
Accounting, controlling usage and fixing faults
New services
Video? Transactions? Distributed computing
Security
End node or network? Routers or relays
__________________________________________________________________
Slide 6
BOUNDING THE SOLUTION
How far can we migrate from the current state
o Can we change the IP header (except to OSI)?
o Can we change host requirements in mandatory ways
o Can we manage a long-term migration objective
- Consistent direction vs. diverse goals, funding
Can we assume network-level connectivity
o Relays are the wave of the future (?)
o Security a key issue; along with conversion
o Do we need a new "relay-based" architecture
How "managed" can/must "The Internet" be
o Can we manage or constrain connectivity
What protocols are we working with? One or many
Clark, Chapin, Cerf, Braden, & Hobby [Page 24]
RFC 1287 Future of Internet Architecture December 1991
__________________________________________________________________
Slide 7
THE MULTI-PROTOCOL
"Making the problem harder for the good of mankind."
Are we migrating, interoperating, or tolerating multiple protocols
o Not all protocol suites will have same range of
at the same time
o "The Internet" will require specific functions
Claim: Fundamental conflict (not religion or spite):
o Meeting aggressive requirements for the
o Dealing with OSI migration
Conclusion: One protocol must "lead", and the others must follow
When do we "switch" to OSI
Consider every following slide in this context
__________________________________________________________________
Slide 8
ROUTING and
What is the target size of "The Internet"?
o How do addresses and routes relate
o What is the model of topology
o What solutions are possible
What range of policy routing is required
o BGP and IDRP are two answers. What is the question
o Fixed classes, or variable paths
o Source controlled routing is a minimum
How seamless is the needed support for mobile hosts
o New address class, rebind to local address, use DNS
Shall we push for Internet multicast
Clark, Chapin, Cerf, Braden, & Hobby [Page 25]
RFC 1287 Future of Internet Architecture December 1991
__________________________________________________________________
Slide 9
GETTING BIG -- AN OLD
(Addressing and routing was on previous slide...)
What user services will be needed in the next 10 years
o Can we construct a plan
o Do we need architectural changes
Is there a requirement for dealing better with ranges
speed, packet sizes, etc
o Policy to phase out fragmentation
What range of hosts (things != Unix) will we support
_________________________________________________________________
Slide 10
DEALING WITH
The Internet is composed of parts separately managed
controlled
What support is needed for network charging
o No architecture implies bulk charges and re-billing,
for lost packets
o Do we need controls to supply billing id or routing
Requirement: we must support links with controlled sharing
(Simple form is classes based on link id.)
o How general
Is there an increased need for fault isolation? (I vote yes!)
o How can we find managers to talk to
o Do we need services in hosts
Clark, Chapin, Cerf, Braden, & Hobby [Page 26]
RFC 1287 Future of Internet Architecture December 1991
_________________________________________________________________
Slide 11
NEW
Shall we support video and audio? Real time? What %?
o Need to plan for input from research. What quality
o Target date for heads-up to vendors
Shall we "better" support transactions
o Will TCP do? VMTP? Presentation? Locking
What application support veneers are coming
o Distributed computing -- will it actually happen
o Information networking
__________________________________________________________________
Slide 12
Can we persist in claiming the end-node is the only line of defense
o What can we do inside the network
o What can ask the host to do
Do we tolerate relays, or architect them
Can find a better way to construct security boundaries
Do we need global authentication
Do we need new host requirements
o Logging
o Authentication
o Management interfaces
- Phone number or point of reference
__________________________________________________________________
Clark, Chapin, Cerf, Braden, & Hobby [Page 27]
RFC 1287 Future of Internet Architecture December 1991
APPENDIX B: Group
Group 1: ROUTING AND
Dave Clark, MIT [Chair
Hans-Werner Braun,
Noel Chiappa,
Deborah Estrin,
Phill Gross,
Bob Hinden,
Van Jacobson,
Tony Lauck, DEC
Group 2: MULTI-PROTOCOL
Lyman Chapin, BBN [Chair
Ross Callon,
Dave Crocker,
Christian Huitema,
Barry Leiner
Jon Postel,
Group 3: SECURITY
Vint Cerf, CNRI [Chair
Steve Crocker,
Steve Kent,
Paul Mockapetris,
Group 4: TRAFFIC CONTROL AND
Robert Braden, ISI [Chair
Chuck Davin,
Dave Mills, University of
Claudio Topolcic,
Group 5: ADVANCED
Russ Hobby, UCDavis [Chair
Dave Borman, Cray
Cliff Lynch, University of
Joyce K. Reynolds,
Bruce Schatz, University of
Mike Schwartz, University of
Greg Vaudreuil, CNRI
Clark, Chapin, Cerf, Braden, & Hobby [Page 28]
RFC 1287 Future of Internet Architecture December 1991
Security
Security issues are discussed in Section 4.
Authors'
David D.
Massachusetts Institute of
Laboratory for Computer
545 Main
Cambridge, MA 02139
Phone: (617) 253-6003
EMail: ddc@LCS.MIT.
Vinton G.
Corporation for National Research
1895 Preston White Drive, Suite 100
Reston, VA 22091
Phone: (703) 620-8990
EMail: vcerf@nri.reston.va.
Lyman A.
Bolt, Beranek &
Mail Stop 20/5
150 Cambridge Park
Cambridge, MA 02140
Phone: (617) 873-3133
EMail: lyman@BBN.
Robert
USC/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: braden@isi.
Russell
University of
Computing
Davis, CA 95616
Phone: (916) 752-0236
EMail: rdhobby@ucdavis.
Clark, Chapin, Cerf, Braden, & Hobby [Page 29]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
