Sat, 3 Oct 87 23:49:45 EDT
The Internet Architecture Task Force (INARC) studies technical issues in the
evolution of the Internet from its present architectural model to new models
appropriate for very large, very fast internets of the future. It is organized
as a recurring workshop where researchers, designers and implementors can
discuss novel ideas and experiences without limitation to the architecture and
engineering of the present Internet. The output of this effort represents
advance planning for a next-generation internet, as well as fresh insights
into the problems of the current one.
The INARC is planning a two-day retreat/workshop for 17-18 November at BBN to
discuss a fresh start on advanced internet concepts and issues. The agenda for
this meeting will be to explore architecture and engineering issues in the
design of a next-generation internet system. The format will consist of
invited presentations on selected topics followed by a general discussion on
related issues. Written contributions of suitable format and content will
be submitted for publication in the ACM Computer Communication Review.
In order to have the most stimulating discussion possible, the INARC is
expanding the list of invitees to include those researchers with agenda to
plow, axe to grind, sword to wield or any other useful instrument for that
matter. Contributors are invited to submit concise summaries of presentations
of from fifteen to forty minutes in electronic form to firstname.lastname@example.org or in
hardcopy form to
Dr. David L. Mills
Electrical Engineering Department
University of Delaware
Newark, DE 19716
Up to forty participants will be selected on the basis of quality, relevance
and interest. Following is a list of possible areas and issues of interest
to the community. Readers are invited to submit additions, deletions and
1. How should the next-generation internet be structured, as a network of
internets, an internet of internets or both or neither? Do we need a
hierarchy of internets? Can/must the present Internet become a component of
2. What routing paradigms will be appropriate for the new internet? Will the
use of thinly populated routing agents be preferred over pervasive routing
data distribution? Can innovative object-oriented source routing mechanisms
help in reducing the impact of huge, rapidly changing data bases?
3. Can we get a handle on the issues involved in policy-based routing? Can a
set of standard route restrictions (socioecononic, technopolitic or
bogonmetric) be developed at reasonable cost that fit an acceptable
administrational framework (with help from the Autonomous Networks Task
Force)? How can we rationalize these issues with network control and
4. How do we handle the expected profusion of routing data? Should it be
hierarchical or flat? Should it be partitioned on the basis of use, service
or administrative organization? Can it be made very dynamic, at least for
some fraction of clients, to support mobile hosts? Can it be made very
robust in the face of hackers, earthquakes and martians?
5. Should we make a new effort to erase intrinsic route-binding in the
existing addressing mechanism of the Internet IP address and ISO NSAP
address? Can we evolve extrinsic binding mechanisms that are fast enough,
cheap enough and large enough to be useful on an internet basis?
6. Must constraints on the size and speed of the next-generation internet be
imposed? What assumptions scale on the delay, bandwidth and cost of the
network components (networks and gateways) and what assumptions do not?
7. What kind of techniques will be necessary to accellerate reliable transport
service from present speeds in the low megabit range to speeds in the
FDDI range (low hundreds of megabits)? Can present checksum, window and
backward-correction (ARQ) schemes be evolved for this service, or should we
shift emphasis to forward-correction (FEC) and streaming schemes.
8. What will the internet switch architecture be like? Where will the
performance bottlenecks likely be? What constraints on physical, link
and network-layer protocols will be advisable in order to support the
fastest speeds? Is it possible to build a range of switches running
from low-cost, low-performance to high-cost, high-performance?
9. What form should a comprehensive congestion-control mechanism take? Should
it be based on explicit or implicit resource binding? Should it be global
in scope? Should it operate on flows, volumes or some other traffic
10. Do we understand the technical issues involved with service-oriented
routing, such as schedule-to-deadline, multiple access/multiple
destination, delay/throughput reservation and resource binding? How can
these issues be coupled with effective congestion-control mechanisms?
11. What will be the relative importance of delay-based versus flow-based
service specifications to the client population? How will this affect the
architecture and design? Can the design be made flexible enough to provide
a range of services at acceptable cost? If so, can the internet operation
setpoint be varied, automatically or manually, to adapt to different
regimes quickly and with acceptable thrashing?
12. What should the next-generation internet header look like? Should it have
a variable-length format or fixed-length format? How should options,
fragmentation and lifetime be structured? Should source routing or
encapsulation be an intrinsic or derived feature of the architecture?
13. What advice can we give to other task forces on the impact of the
next-generation internet in their areas of study? What research agenda,
if any, should we propose to the various NSF, DARPA and other agencies?
What advice can we give these agencies on the importance, level of effort
and probablity of success of the agenda to their current missions?
David L. Mills, Chairman INARC
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:34 GMT