Internet Engineering Task Force IESG
INTERNET-DRAFT
July, 1991
An Internet Evolution Plan For The IETF
1 Status of the Memo
This document is a working paper by the IESG to guide future work in
the Internet. It will be submitted to the RFC Editor as an
Informational document. Please send comments to
IESG-FYP@nri.reston.va.us.
Contents
1 Status of the Memo 1
2 Introduction 7
3 Description of IAB and IETF/IESG organization 9
4 Setting the Goals and Overall Agenda for Internet Evolution 10
4.1 Goals -- One (arguably arguable) vision of the future 10
4.1.1 ``Integration'' 10
4.1.2 The Ubiquitous Internet 10
4.1.3 New Technology 11
4.1.4 Diversity 12
4.1.5 New Service Providers 12
4.1.6 Transition from ``Old'' to ``New'' 13
4.1.7 New Uses of the Internet 14
4.1.8 How to Get to the Future 15
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
4.2 Agenda -- Categories for focus in IESG Planning 15
4.2.1 Planning for Coordinated Global Operations 16
4.2.2 Enhanced Protocol Infrastructure 17
4.2.3 Enhanced Applications and Services 17
4.3 Multi-protocol Integration 18
5 Technical Planning for Applications 19
5.1 Area Overview 19
5.2 Goals 19
5.3 Specific Work 20
5.3.1 Information Representation 20
5.3.2 Information Applications 21
5.3.3 Directory Services 21
5.3.4 Information Retrieval 22
5.3.5 Personal Communication Applications 23
5.3.6 Person-to-group communication 23
5.3.7 Group scheduling 24
5.3.8 Operational Applications 24
6 Internet Area Plan 26
6.1 Area Description 26
6.2 Area Technical Goals 27
6.2.1 Routing and Addressing 28
6.2.2 Congestion Control and Resource Management 29
6.2.3 Configuration 30
6.2.4 A New IP Packet Format 31
6.3 Specific Actions 32
IESG [Page 2]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
6.3.1 Addressing 32
6.3.2 Congestion and Resource Allocation 32
6.3.3 Configuration 32
6.3.4 Security 33
6.3.5 High Speed Switch Architectures 33
6.3.6 IP Encapsulation 33
6.3.7 Media Support 33
6.3.8 Router Requirements 34
6.4 Host Requirements 34
6.4.1 IP Specification 34
6.4.2 ICMP Specification 34
7 Network Management 35
7.1 Area Goals 35
7.2 Specific Work 36
7.2.1 Comprehensive Instrumentation 36
7.2.2 Maturity and Deployment 36
7.2.3 Multi-Protocol Context 37
7.2.4 Cooperative Foundation 37
7.2.5 Product Range 38
7.2.6 Scope 38
7.2.7 Secure Operation and Administration 38
7.2.8 Architectural Effectiveness 39
7.2.9 Enriched Management Applications 39
8 OSI Integration 41
8.1 Area Overview 41
IESG [Page 3]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
8.1.1 OSI in Internet in 1995 41
8.1.2 Physical & Link Layer 41
8.1.3 Network layer 41
8.1.4 Transport 42
8.1.5 Applications 43
8.2 Specific Work 44
8.2.1 Physical and Link Layers 45
8.2.2 Transport 47
8.2.3 Applications 48
8.2.4 Network Management 51
8.3 An Infrastructure for OSI 51
9 Operational Requirements 53
9.1 Description 54
9.1.1 Provide a forum for coordination between operational
groups 54
9.1.2 Development of operational methods, practices, and
policies 55
9.1.3 Guidance to other IETF technical development efforts 55
9.2 Technical Goals For The Operational Requirements Area 57
9.3 Specific Actions For The Operational Requirements Area 58
10 Routing Area Plan 60
10.1 Description of Routing Area 60
10.2 Technical Goals for the Routing Area 61
10.2.1Internet Growth - Routing should not be the limit to
growth 61
10.2.2Provide Routing Protocols for Future Environments 61
10.2.3Provide for Multivendor Interoperation 62
IESG [Page 4]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
10.3 Specific Actions Required 62
10.3.1Standardize on one Interior Routing Protocol 62
10.3.2Define Requirements to Advance Internet Routing Protocols
to Draft Standard and Full Standard| 62
10.3.3Deploy BGP to Replace EGP 63
10.4 Develop Routing Protocols for Large Data Networks 63
10.4.1Authentication of Internet Routing 63
10.4.2Routing and Addressing Architecture 64
11 Security Area Plan 65
11.1 Objectives and Overview 65
11.2 Objectives 65
11.2.1Arenas of activity 65
11.3 Specific Work) 66
11.3.1Protocols 66
11.3.2 Policies 69
11.3.3 Standards and Development 70
11.4 Organization 70
11.4.1SAAG 70
11.4.2PSRG 70
12 Transport and Services Area 72
12.1 Description 72
12.2 Technical goals 72
12.3 Current and future actions 72
13 User Services 74
13.1 Area Overview 74
IESG [Page 5]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
13.2 Goals 75
13.2.1 User Information 75
13.2.2 Network Information Services Infrastructure 76
13.2.3 Network Operational Management 76
13.2.4Education 77
13.2.5 Documentation and Distribution 77
13.2.6Interaction with IESG Areas 77
13.2.7 Interaction with other User Services Organizations 78
13.3 Goals 78
13.3.1User Information 78
13.3.2 Network Information Services Infrastructure 81
13.3.3 Network Operational Management 82
13.3.4 Education 84
13.3.5Documentation and Distribution 86
IESG [Page 6]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
2 Introduction
This document is an initial draft of an Internet evolution plan for
the IETF. It is submitted for comment and review by the Internet
Engineering Steering Group (IESG) of the IETF.
The motivation for developing this document is to give specific shape
and form to the general directions for IETF guidance that have
developed in the IESG over the last 1-2 years. It is also intended to
make this available for widespread review and comment by the IAB and
broader community. It is assumed that IAB and community feedback will
play a large role in shaping the final document. The IETF has always
been a completely open organization. Submitting this document for
open review and comment is in keeping with the IAB/IETF goal of a
completely open process.
The IESG is currently composed of the following technical ``Areas''
and Area Directors:
IETF and IESG Chair: Phill Gross/CNRI
Applications: Russ Hobby/UC-Davis
Internet and Noel Chiappa/Consultant
Philip Almquist/Consultant
Network Management: James Davin/ MIT
OSI Integration: Rob Hagens/UWisc and
Ross Callon/DEC
Operational Requirements: Phill Gross/CNRI
Bernard Stockman/Nordunet
Susan Estrada/CERFnet
Routing: Robert Hinden/BBN
Security: Steve Crocker/TIS
Transport and Services Dave Borman/Cray
User Services Joyce Reynolds/ISI
Standards Management: Dave Crocker/DEC
IESG Secretary: Greg Vaudreuil/CNRI
In sections 3 through 10 of this document, Area Director(s) have
individually contributed ``Area Plans'' for each IETF area. Each
``Area Plan'' follows the same general outline.
o Description of Area (eg, topics covered, topics not covered,
relation to other areas)
o Technical goals for the Area (ie, Description of what
advancements are needed in this area to work toward overall goal
of Internet evolution
o List of specific actions required to accomplish goals in section
IESG [Page 7]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
(b). Some actions may already in progress in IETF WGs. For any
action not currently in progress, the intent is to include a
short description, timeframe, and priority for each action,
suitable for broadening into a prioritized list of WG charters.
Section 1 of this document is meant to provide an overview of the
history, organization, practices, procedures of the IAB and IETF/IESG.
This may be useful for those not already familiar with the IAB and its
structure. It may also help justify the IAB as an Internet-wide (ie,
international) organization. (This section has not yet been written.)
Section 2 discusses the overall goals for Internet Evolution. In a
subsection, we discuss one (arguably arguable) vision of the future
Internet. The intent was to motivate and guide the ``technical
goals'' sections in each of the individual Area plans. In another
subsection, we lay out broad categories for focus in IETF Planning.
This is meant to act as a broad ``technical agenda'' for the IETF --
that is, these are the broad categories for IETF activity taken from a
slightly different point of view than the strict ``Area'' breakdown.
I'd like to thank the entire IESG for the work involved in developing
this initial draft. I'd also like to thank IESG Secreatary Greg
Vaudreuil for his important contributions to this and other IESG
activity. This is a great start -- with feedback from the Internet
community, the next draft should be even better.
Phill Gross
IETF Chair
IESG [Page 8]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
3 Description of IAB and IETF/IESG organization
To Be Provided
IESG [Page 9]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
4 Setting the Goals and Overall Agenda for Internet Evolution
4.1 Goals -- One (arguably arguable) vision of the future
In this section, we discuss one vision of the future Internet. The
intent was to motivate and guide the ``technical goals'' sections in
each of the individual Area plans in sections 3 through 10.
4.1.1 ``Integration''
We can expect the future Internet to be ``integrated'' into the fabric
of normal society in several ways. The Internet will be
``geographically integrated'', by which we mean that it will be
physically ubiquitous. The Internet will be ``socially integrated'',
meaning the Internet will become a ``commodity''. It will be commonly
used by people everyday without a great deal of thought to the
underlying infrastructure. It will be accessed by commercially
available equipment and through commercially provided services. It
will be used by commercial concerns and individuals as commonly as it
is used for research and education today. Finally, the Internet will
be ``technologically integrated'', meaning it will accomodate older
and newer style technologies and multiple services and protocols.
4.1.2 The Ubiquitous Internet
Currently, wherever you go, telephones are an integral part of the
modern world-wide infrastructure. Moreover, the most powerful thing
about telephones is that most can directly contact any other
telephone, not just telephones in the same organization or site.
The Internet will be everything that phone service is now, but far
more powerful and flexible, and even more integral to daily life in
every way. In basic terms, this means that in the year 2010 there
might be 100 million networks and 1,000 million end users in a
worldwide interconnected service featuring bandwidths up to 100's of
gigabits per second.
The Internet will change the way that society communicates and
relates. People will talk to each other because of common interests
without the restriction of geographic location. Unlike the phone,
which is used primarily for one-to-one conversations, the Internet
allows global group discussions and sharing amoung all those
interested in a subject. The Internet makes the whole world your
neighborhood. Perhaps, the most noteable aspect of the future
Internet is that, like the phone system today, no one will ``notice
it'' unless it breaks, that is, no one will give much thought to the
IESG [Page 10]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
underlying infrastructure unless it stops providing the expected
routine service.
4.1.3 New Technology
Network connections and typical end user machines will be quite
different. Within 10 years, the current difference between PC and
workstation capabilities will be eliminated. The typical ``PC'' at
that time (ie, found in many homes and most offices) will be a 100
MIPS workstation, with 1 gigabyte disk, 100 megabyte memory, and
high-resolution color graphics screen. On the otherhand,
preoccupation with speed and storage size will become less important.
For example, who cares how many MIPS and bits are in your TV or Phone.
It just does the job.
The most important part of this future ``PC'' will be the input and
output devices. High-definition video and stereo sound will be
commonplace. In fact, the network will become both an important input
and output device to the ``PC''. The network may also be a storage
device for the ``PC''.
Most industrial network connections will be a gigabit/second or
greater to accomodate the bandwidth requirements of advanced
applications. In the home environment, T1 connections (or whatever it
takes to allow some reasonable form of compressed video images) will
be common.
As the community served by the Internet grows, there may come a
decreased emphasis on computing and traditional data communications as
the primary use of the network. Although traditional computer
applications like electronic mail will continue to be an important use
of the network, integrated network services bearing voice and video
information are likely to dominate bandwidth consumption. The future
internet will commonly carry both compressed and uncompressed audio
and video, because the relative economy of compression and
transmission technologies will vary with location, time, and
application.
To support this integration of services, the future Internet will
incorporate fairly elaborate facilities for articulating and realizing
service guarantees (e.g., bandwidth, latency) and resource allocation
policies. Moreover, these guarantees and policies will be effected in
the network by efficient mechanisms that exploit statistical
economies.
Users will be able to select the level of service that they expect
from the Internet. They will be able to select the network service
provider they want to use to carry their traffic for specific
applications. For example, One carrier may be used for business
IESG [Page 11]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
communication, another for entertainment, and yet another for bulk
data retrieval.
4.1.4 Diversity
Just as relevant as the tremendous growth in Internet transmission
speeds will be the tremendous growth in the *range* of transmission
speeds and technologies that a truly ubiquitous Internet must
accommodate. This technological heterogeneity is not only inevitable:
it is desirable. Although it complicates the technological
integration of the Internet, only by broad technological variety can
Internet users properly balance their service requirements against the
cost of their participation. As the Internet grows increasingly
commercial in both its operation and use, technological variety will
be central to its social value.
The underlying network might be based on new and different hardware
technologies but that will unimportant to most users because the
actual underlying technology will be transparent to them. In 10
years, network management will work! The MTBF and MTTR for average
service will be the same as telephone service. There will be no
intermittent lapses in service due to ``routing loops'' or ``black
holes''. The routing problem will be ``solved'', and it will be
invisible to the user.
4.1.5 New Service Providers
Part of the reason for this ``invisibility'' of the network is that
major telephone companies will have entered the networking market in a
big way. Networking will be a ``commodity'' service like telephone
service or PC's today. Prices will be affordable to home users for
what would be considered very high-end services today. However, in
line with the trends of decentralization in the telephone system, we
will contine to see large portions of the network run by non-carriers,
especially at the fringes, or where a large user can economically
provide his own service over leased physical assets. The greater
flexibility of the Internet will help drive this trend. Legal
limitations on the character of services provided by common carriers
may contribute to this diversity of administration in the future
Internet.
Security will no longer be an issue because it will have integrated
into every facet of the technology and service. People will not have
to think about it. All applications will be secure (exchanges will be
authenticated and private), and all network services will have
authentication and access control. Not only will security services
mediate the use of network resources, they will enable the network as
IESG [Page 12]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
a medium for commerce --- the network will be a market both for
familiar tangible products and for innovative information services
that are themselves delivered via the network.
4.1.6 Transition from ``Old'' to ``New''
It is likely that the system will still be in some stages of
transition at this point, particularly in the less developed regions
of the world. This means there is also likely to continue to be a
wide mixture of environments within this new system. Old lower speed
connections (eg, 9600 baud dial-in modems and 56 Kbits/second) may
still be in service in places in the system. And remnants of the
current networking hierarchy are likely to still be in place (eg,
local campus ethernets connected by old style routers, and regional or
campus-based networks based on IP routers as switches).
Higher speeds (for reasons apparently based on the usual laws of
physics, thermodynamics and economics) will continue to cost more than
lesser speeds. Although bandwidth is likely to decrease in cost,
deliberate over-provisioning will continue to be an unattractive
solution to resource allocation and performance problems. For reasons
which include the broad user base, the wider range of more demanding
applications, and the increasingly commercial character of the future
Internet, the system will accomodate a wide dynamic range of
capabilities and will still have to worry about backward compatibility
with old-style systems. This, in addition to the need for robustness
and reliability, will place a premium on features that can isolate bad
behavior (eg, non-conforming hosts, pockets with low security, lower
quality network management,etc). The new systems will have to be
fault tolerant of non-conforming systems.
The local environments will auto-configure themselves as part of a
higher level network management scheme. All local configuration
parameters will either be assigned by the network or, for a basic ID,
burned into ROM. The network will ``remember'' each host, so that it
will boot up into the same configuration whereever the host is
located. This will allow ``mobile hosts'' like palmtop and notebook
computers to be used anywhere with the same environment as at the
local home or office. In particular, the cellular telephone network
will be one component of the future Internet infrastructure, and, in
general, relatively low-bandwidth devices (e.g., telephones, PCs,
personal locators) may often enjoy ``wireless'' connections to the
Internet.
IESG [Page 13]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
4.1.7 New Uses of the Internet
In the future Internet, phone answering machines and Faxes will have
had their day. Such services will be provided to each desktop in the
home and office environment by the ``PC''.
There will be a wider range of high-capability applications available
on the network. The Internet will look like a combination of the
phone company, the post office, the cable TV company and others.
Commercial applications and services will be routinely available.
Desktop video conferencing will be common service (and may pose a
rival to normal phone service in office, if not home environments).
Transaction processing will experience an enormous growth as the
network gains the ability to handle these with reliability and
securely, and as the network spreads ubiquitously. Electronic mail
will continue to grow and play an increasingly important role in
everyday life (home and office). Because of the large volume, we will
need vastly different paradigms and user interfaces to be usable. Of
course, electronic mail will be fully multi-media, with voice, video,
and graphics-prepared documents common. Actual storage of most data
will be handled by a replicated, centrally backed up distributed file
system, access to which is over the network from most ``PC''s.
Entertainment will consume a growing prortion of the bandwidth of the
internet. This will range form conventional video's to interactive
multi-party simulation games.
Some potentially serious issues relating to ``information explosion'',
eg, electronic junk mail and electronic mail overload, will be solved
in innovative ways.
To the extent that a ubiquitous Internet may enable anonymous product
discovery and advertisement, it may help avoid the potential erosion
of personal privacy due to electronic junk mail. The compilation and
use of consumer profiles to support directed marketing may decline
when consumer choices can be shaped as much by pro-active
interrogations of online product databases as by reactive responses to
unsolicited advertising.
For old-fashion physical mail, it takes much longer to send mail than
to receive it. For Email, it is much faster to send one message to
2000 recipients (or, in the Internet of the future, 100,000,000
recipients!) than to receive 2000 messages. Plus, the very nature of
the Internet is to increase the ``community'' with which you normally
interact. In the past, you might interact with your office or your
department. With the Internet, you interact with a larger and more
geographically dispersed community. This results in chronic email
overload. Although email has become the staple for interacting in
this large diverse environment, it is not uncommon for current
Internet users to be behind in reading email. It is also not uncommon
IESG [Page 14]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
for important pieces of email to quickly become ``lost'' in large
online ``folders'' of email.
In the future, new paragigms, tools, and applications, including
sophisticated database management methods, will have to become
available to manage this inevitable ``information explosion''.
4.1.8 How to Get to the Future
To reach this environment will require us to solve many thorny
technical problems that we've known about for years but are only now
beginning to fully understand.
These problems include -- scaling, deployment, coordinated management
and problem resolution, high speed transport, congestion control,
advanced routing, auto-configuration, connection and transaction
oriented support for applications that need it, issues resulting from
scaling (such as consumption of addresses and increased address size),
directory services (white and yellow), and work on high-capability
applications (like multi-media electronic mail).
Providing performance guarantees appropriate to new applications will
be necessary to support technological integration of services in the
future Internet. Support for a broad range of resource allocation
policies will be necessary to the technological integration of
multiple services and to the social integration of multiple
administrations in the future Internet. Support for a broad range of
security policies will be necessary to the social integration of
multiple administrations in the future Internet.
Perhaps the biggest issue of all, however, will be the transition from
the old regime to the new! We will not have the luxury of leaping to
the new regime. We will have the problem of dealing with the old
installed base. (We can term this the ``MS-DOS problem''!) Plus,
until the bright new day of networking arrives, we will have to worry
about the installing and deployment of the new technologies as they
arrive.
4.2 Agenda -- Categories for focus in IESG Planning
In this section, we lay out broad categories for focus in IESG
Planning. This is meant to act as a broad ``technical agenda'' for
the IETF -- that is, these are the broad categories for IETF activity
taken from a slightly different point of view than the strict ``Area''
breakdown.
IESG [Page 15]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
4.2.1 Planning for Coordinated Global Operations
This category covers issues in the Operational Requirements and User
Services Areas.
o Higher-level Operational Issues
We need to develop ``plans'', ``policies'', and multi-lateral
agreements to coordinate the following issues on a global scale.
These involve issues that require coordination and planning
between high-level organizations. Topics include:
- Coordination and planning of network interconnections
- (eg, international links )
- Coordination and planning of Global routing
- Coordination and planning of Global DNS operations
- Coordination and planning of Global IP address and DNS name
registration issues
o Lower-level Operational Issues
These issues involve coordination and interaction at a local
level. Issues in this category might include implementation of
policies/procedures/technology agreed upon in the above
``Higher-level'' category. Topics include:
- NOC coordination
* liaison
* end-end trouble reporting/resolution
* common methodologies
* shared information
* well defined interaction and division of responsibilities
with NICs
* etc.
- NIC coordination
* liaison
* common terminology
* common user interfaces
* wide availability of common information shared across
boundaries
* well defined interaction and division of responsibilities
with NOCs
* etc.
- Definition of common methodologies and procedures (common
mapping formats; set of common performance metrics, common
measurement tools/methods and common display formats; etc)
IESG [Page 16]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
4.2.2 Enhanced Protocol Infrastructure
This category covers issues in the Internet, Routing, Network
Management, and Security Areas.
The issues in this category involve the basic protocol architecture.
Topics in this category include the usual suspects:
o expansion of address space
o advanced inter-domain routing
o Relation between addressing and routing
o general attention to scaling
o high speed transport for new network services (eg, SONET speeds)
o congestion control
o connection-oriented support for application that need it
o etc, etc
Topics in this category have traditionally been those dealt with best
by the Internet research community. For example, the upcoming IAB
Workshop on Internet Architecture should shed considerable light on
topics in this area.
4.2.3 Enhanced Applications and Services
This category covers issues in the Applications and Security Areas.
(Also, perhaps, issues in the Operational Requirements and User
Services Area.)
These include the development of enhanced network services. Some
examples are below. Many others exist and should be added!
o Email
- multimedia support
- national character set support
- better configuration/operational/problem-resolution support
- etc
o Security
- need security support for at least the ``core'' services on a
case-by-case basis, (eg, routing, net mgmt, email, remote
login)
- need more comprehensive infrastructural support for broader
security capabilities (eg, access control, privacy,
authentication, etc)
IESG [Page 17]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
4.3 Multi-protocol Integration
We should concentrate on ways of allowing all technologies to utilize
the common plant. Interoperation has always been a key goal in the
Internet. We should stress the non-denominational goal of ubiquitous
interoperation.
The Internet is primarily based on TCP/IP services. However, the
installed base of connections and equipment opens up the possibility
of even wider interconnection between other protocol technologies.
OSI is the obvious example.
Topics in Multi-protocol Integration include:
o General non-Internet protocol integration and interworking
- SNMP MIB development for non-Internet protocols
- IP-over-Foo-net-technology
- Foo-protocol-family-over-IP
- For some cases: Foo-protocol-family-over-Foo-net-technology,
(eg, Decnet-over-PPP)
- Non-Internet applications over IP (eg, NNTP, FAX over IP, OSI
applications over TCP/IP)
- Application gateways between IP applications and similar
applications in other protocol families (eg, any of the
various email gateways)
- etc.
o OSI integration and interworking -- in each case below, these
topics are meant to be considered solely in the context of the
Internet. The IAB/IETF do not have direct change control over
OSI standards, so any OSI topics considered in the Internet must
be constrained to the area of profile development and deployment
planning.
- Overall, integrated, planning for OSI integration
- into the Internet
- CLNS deployment planning
- NSAP/addressing formats
- IS-IS routing development/deployment
- X.400/X.500 definition/development/deployment
- Connection-oriented/Connection-less interworking
- Application gateways between OSI and Internet applications
- etc.
IESG [Page 18]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
5 Technical Planning for Applications
5.1 Area Overview
We, as the engineers of the Internet, have had a tendency to look at
the network from the bottom of the protocol stacks looking up. We
have mainly focused on how we get the bits across the network and not
so much how they are used. We have now created a large network with
many users. It is time for some of us to look at it form their point
of view.
In planning for the future of applications on the Internet, we need to
answer a few questions. What do the users want to do with the
network? What resources are available on the network today? Do they
meet the needs and expectations of the users? If not, what do we do
next?
Let's look at the network from the users view point. There are at
least three, and probably more, types of applications. First there
are applications for the searching, retrieval, and distribution of
information. Next there are applications for personal communications
and finally there are operational applications for use in the general
computing environment.
To bring these applications to life, we need to agree on formats for
information, such as character sets, graphics format, file structures
and command syntax. Most of these formats do not have a standard
definition for the Internet. Worse yet, there are many groups
claiming to be developing the standards but there is no coordination
among these groups. Thus, we are being faced with choosing one of
several overlapping standards.
We also need the tools to create network applications. Many
applications have lower level functions in common, such as
authentication, remote procedure calls, and remote file operations.
These are functions that the Transport and Services Area and Security
Area need to provide for a base on which to build the new Internet
applications.
5.2 Goals
One of the first things that we need for the Internet is to define the
common set of information formats. Without these, we will have no way
to use the information that we are exchanging. Once we have defined
what the information will look like, then we can figure out what we
really want to do with it.
After we have defined the information formats, we can then define the
applications to locate, move, manipulate, and display that information
in a wide variety of ways built on the lower layer tools provided by
IESG [Page 19]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
the other areas.
5.3 Specific Work
5.3.1 Information Representation
For information exchange between systems to be useful, it must be in a
format that is understood by the system so that it can be presented to
the user. This enters into the world of multimedia where the user
wants to have text, image, sound and video on the desktop.
Function What's Needed
Text Information in the form of text is compact and can be
edited after retrieval. However, the ASCII character
set is not the only one used on the Internet any more.
The use of multiple character sets needs to be defined.
Image We need to standardize a format for the presentation of
images on the Internet. The format should be flexible
for various resolution and color combinations and have
compression capabilities. Several organizations are
working on this problem but we don't need multiple
standards confusing users and leading to
noninteroperability.
Graphics We need to standardize a graphics format for vector
graphics. Vector graphics can represent graphs and
drawings in a concise, editable manner, but there needs
to be agreement on format. With such a format, one
could imagine things like architectural blueprints being
transported over the network.
Video A standard video format is also needed. Unlike Image
and Graphic formats, the video format has to worry about
real-time delivery. Compression of the data will also
be important to keep the data streams to a minimum
bandwidth.
Audio/Analog We need to standardize a format for sound
representation or for analog signals to be sent on the
Internet. Although audio will be the primary use for
this format, all types of analog signals could be
transported this way. The format should be flexible for
various bandwidth capabilities and allow compression.
Display We will need a standard display format so that
applications can have a uniform screen environment for
information presentation to the user. X-windows is a
IESG [Page 20]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
good example and may indeed be the standard that we
need.
Data Objects While most computer languages and operating systems
have standard data objects, such as integers, floating
points, strings, etc, we need a standard form of
exchange on the network for these items. These will be
especially important for the inter-process functions
such as remote procedure calls.
5.3.2 Information Applications
There is already a vast amount of information on the Internet, but it
is not easy to find or access. We need applications to help search
for and retrieve information, and standard formats for that
information so that something can be done with it after we retrieve
it.
5.3.3 Directory Services
First let's look into finding the information or directory services.
People using the network want to find information on other people,
services and information bases on the Internet. They also want to
find it without having to know where it is in the first place. In
other words, to do a global search. Probably the best directory
service that we have on the Internet today is the Domain Name System.
Although DNS still has some problems, it shows that a system that is
globally managed but locally maintained does work. It is also well
integrated into the system such that the user never really knows that
they are using it.
Function What's Needed
People Lookup We need a globally coordinated locally maintained
people directory. WHOIS and FINGER are used some but
the data is not well coordinated. We need to determine
if X.500 meets the immediate need.
Resource Lookup We need a system to find a variety of resources
such as databases, software, super- computers, or
specialized devices. The FTP site list just isn't good
enough.
Document Lookup Many libraries have card catalogs on line, but the
systems are usually incompatible with each other. We
IESG [Page 21]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
need a global system. We particularly need to be able
to locate documents that are on line. Some groups are
looking into Z39.50 as a solution.
5.3.4 Information Retrieval
Once you locate the information, you would like to retrieve it.
Currently you can TELNET to the information source and view it there;
or FTP the information to your location and process it locally. In
many cases, what is desired is more of the client- server model where
just the information needed is retrieved and is processed locally.
Function What's Needed
File Resources People want not only to transfer files, but also to
do software archiving and distribution. FTP needs some
updates to allow for transfer of file attributes and
archive creation and retrieval functionality.
Remote Database People want access to all types of databases on the
Internet. We need to standardize the client/server
protocols used over the network. Work will continue on
the standardization of SQL over TCP/IP.
Info Server Sites want to setup client/server information systems.
With client/server systems each entity providing the
service can also be responsible for the resources to
store and provide the information. Likewise, those
wishing to retrieve the information (clients) provide
the equipment. Standardization of this service will
allow development of different user interfaces in the
clients to suit the users and allow access to any
information server.
Windowing We need to standardize a method for establishing screen
window connections for the presentation of the
information. We spoke of the window format above, but
we also need a way to establish the connection across
the network for a window. Currently TELNET is the only
standard in this class of functions. However, it is
suitable for text only and is missing many functions
desired by todays users. X- windows again may answer
this problem.
IESG [Page 22]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
5.3.5 Personal Communication Applications
Three types of personal communications that people seem to want are
person-to-person, person-to-group, and calendar/scheduling.
Person-to-person is communications to one person or a small known
group of people and include functions such as electronic mail,
talk/chat, video conference and, of course, the telephone.
Function What's Needed
Email SMTP and RFC822 need updating to completely separate the
message delivery and message format functions. Delivery
needs to make sure that a block of data is delivered.
Message format needs to be updated to allow for various
body parts such as text with other character sets,
binary data files, images, and sound.
Email Maintenance Email lists on the Internet are, for the most
part, maintained manually. There is a desire for
automatic maintenance and distributed delivery systems
for email lists. The BITNET LISTSERV function has done
this quite well for many years. It is time to have this
functionality on the Internet.
Message Handlers Currently most email users receive and store their
message on a single host that is on the network all the
time. Message systems need to be standardized to allow
store and forward of messages for computers that are
connected to the network part-time. There is also a
desire for multiple host mail message systems that allow
users to maintain their mail on several computers. POP,
PCMAIL and IMAP are starts in this area.
Conference System Interactive text conference systems seem to have
limited functionality. Most people just can't type fast
enough. More work needs to be done on
text/voice/image/video conference systems and standards
for the Internet. Standards for image and voice formats
mentioned above will help in this work.
5.3.6 Person-to-group communication
Person-to-group is a broadcast type of communication where you are
communicating with a large unknown group. This includes services such
as forums and bulletin boards. USENET is probably the most popular
type of this service currently available.
IESG [Page 23]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Function What's Needed
BBS/Forums USENET/NNTP have done quite well in this area. However,
it is not now a standard and the system needs to be
updated to consider efficiency and the current size of
the Internet.
5.3.7 Group scheduling
For the third type, imagine that you could maintain your personal
calendar on your own computer. Now imagine that your calendar could
talk to all other calendars on computers all over the Internet and
schedule people, rooms and other resources. This is the type of
functionality that people want of network calendar/scheduling.
Function What's Needed
Scheduling The whole system needs to be defined, and standardized.
5.3.8 Operational Applications
There are network functions that are associated more with distributed
computing rather than communications. These generally have to do with
resource sharing of devices such as printers, disks, backup storage
and to some extent, CPUs. Back in the ``old days'' of computers and
mainframes, users had to know where each peripheral was and how to
access it. Operating systems have now made that invisible to the user
on individual computers.
When it comes to network resources, however, we have jumped back
twenty years. You still need to know where each resource is on the
network and how to access it. We need to use what we have learned in
operating systems and apply it to networks. Think of the network as a
computer buss with lots of CPUs and peripherals hung on it. The
network is the computer. Now we just need to write a user friendly
operating system for this new computer.
The real problem, of course, is that with single computers it has been
just one vendor that has had to coordinate within itself. With
networks, we are operating in a multi-vendor environment and
coordination means that we need standards.
Function What's Needed
IESG [Page 24]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Network Printer We need the ability to plug a printer into the
network and allow controlled access from anywhere on the
network.
Network FAX Network FAX is like a printer but uses a FAX machine
instead. We also need to be able to connect to FAX
machines that are not on the network.
Backups We need to define a way to do disk backups over the
network. Modifying FTP for archiving may solve this
problem too.
Remote Programs We need to define and standardize a means to run a
program on a remote computer but have it look like it is
running locally. REXEC for UNIX does this but is too
centered on UNIX. The window standard and information
formats above are important aspects of this function.
IESG [Page 25]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
6 Internet Area Plan
6.1 Area Description
The Internet Area covers, broadly speaking, that portion of the
architecture which is responsible for delivering packets from one host
to another. Thus, this area covers such topics as operation of IP on
all local media, the functions of routers, and low-level inter-network
control mechanisms such as ICMP.
The Internet Area does not include routing, which is its own area due
to its complexity. Addressing is technically a part of the Internet
Area, but because of the close ties between addressing and routing, it
is and must continue to be coordinated closely with the Routing Area.
Because the distinction between the Internet Area and the Routing Area
can be constraining, it is hardly surprising that the Area with the
closest relation to this one is the Routing Area. Router Requirements
(in this Area) and IP over Large Public Data Networks (in the Routing
Area) are good examples of current projects where the two Areas
overlap, and this overlap can only be expected to increase as we seek
new solutions to the very difficult problems of addressing and routing
in a very large network.
However, the Internet Area also has significant interactions with most
of the other IETF areas. Work here is obviously of some interest to
both the Applications Area and the Transport and Services Area, since
they utilize the services of the Internet Layer, particulary to the
latter as we start to tackle the issues of resource allocation, and
congestion control.
Both the Network Management Area and the Operations Area have focused
much of their attention on the management of services which fall
within the Internet Area. Security is of course a major concern of
this Area, as of most Areas, and one which has received too little
attention in the past. This area will be working closely with the
Security Area to ensure that security is designed into new services
and, when possible, retrofitted into the existing ones.
There are several other areas of inter-Area cooperation which would be
worth pursuing, but where collaboration in the past has been hampered
by difficulties in finding volunteers with the time, expertise, and
energy to pursue them. For example, the Internet Area (in conjunction
with the Operations Area) probably ought to provide more technical
support than it has in the past to efforts within the User Services
Area to demystify the procurement, installation, and management of IP
hosts and routers. Likewise, the Internet Area probably needs to work
more closely with the OSI Integration Area as the latter works to
transform the fabric of the Internet from a (predominantly) IP-only
network to truly multi-protocol network. Collaboration with the OSI
Transition Area should also try to ensure that efforts in the Internet
IESG [Page 26]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Area can benefit from the ideas, and when appropriate even the
protocols, developed in forums such as ISO, ANSI, and the CCITT.
6.2 Area Technical Goals
The general goal for this Area are to provide ubiquitous packet level
service at high speeds throughout the world. The existing
architecture at the packet level is fairly successful, and the system
in the future should present much the same appearance the the average
user, although much larger and (in most places) much faster. To the
users, the only noticeable changes will be that more controls are
available for implementing policies, both in controlling where traffic
flows, and how resources are allocated when contention for them
exists. These tools will aid the transition of the data
communications system to a commercially viable and available
infrastructure.
The system as it stands has three main places where work is needed in
the medium term. The first is in addressing and routing; this work is
mostly in the Routing Area, but has some overlap into the Internet
Area. The second is in congestion control and resource allocation;
service guarantees are part of this issue. It was felt that these
conditions are too dynamic to handle with routing in a system this
large; separate mechanisms are needed. Some work has been done on
this, but further research is needed. The third is in the area of
configuration; the system at the moment is far too dependant on
complex configuration by skilled personnel. The system simply cannot
continue to grow if this continues; the system should be
self-configuring where possible, and where not, the configuration
should be both simple and strongly resistant to faulty configuration.
These are the three largest problems, since they have substantial
technical components of some difficulty. The other area needing work
is of a different nature; security needs to be added (where
appropriate) throughout the architecture, and this Area is no
exception. Little can be done until Routing is i) secure and ii)
provides better tools, but at that point it should be possible for
users with security needs to obtain the level of service they need
from the system. The system should also become better prepared to
handle denial-of-service attacks, although this will probably depend
in part on the congestion control work above. Clearly, service
guarantees cannot be met if the system is not secure!
Other than these points, the system appears to have handled past
growth quite well, and while many new technologies have been deployed,
and the system has grown quite a bit, it has all fit in fairly
smoothly. Some minor points which were left unhandled in the original
architecture are being dealt with, such as Router Discovery and MTU
Discovery, but handling these has not required a major effort. In
general, most existing unhandled small issues are being handled by
IESG [Page 27]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
recently created efforts.
Additional areas needing work in the medium term time frame are wider
deployment of multicast capabilities, development of high speed
switches, rationalization of the various network level support
functions (primarily those currently in ICMP), and specifications for
wrapping various other network protocols in IP and vice versa
(principally CLNP) but these topics do not appear to present any
fundamental challenges and should happen in short order.
A number of additional standards documentation efforts are also
needed. Further codification, in clear and complete fashion, is
needed on the running and demultiplexing of network layer protocols
(with obvious emphasis on IP) on various media. Particular attention
needs to be paid to clearly addressing framing methods, address
mapping techniques, access methods, and detection of and recovery from
hardware faults. We anticipate starting an effort to address these
issues once Router Requirements has been completed. This effort will
produce a Link Layer Layer Requirements document, which will be
applicable to both hosts and routers. This effort will also codify
what needs to be included in future IP over XXX RFCs.
A new version of the Host Requirements document set will also need to
be produced (in cooperation with the relevant Areas), though this is
not a pressing issue in the short term. Because of the substantial
manpower requirements of such an effort, it probably cannot be started
until after the completion the Link Layer Requirements effort.
6.2.1 Routing and Addressing
Routing is mostly in the Routing Area, but is of interest to the
Internet Area in two ways. First, it is quite likely that the next
Internet routing architecture will explicitly recognize the fact that
data usually passed through the Internet in identifable collections,
which are being called 'flows'. Taking cognizance of this (although
without storing any critical state in the network, merely 'hints')
allows very effective mechanisms that meet certain problems to be
deployed, not only in the routing area, but in others such as access
control and resource allocation.
For example, access control can be an expensive operation to implement
if every packet must be considered individually: individual switches
often have complex access control policies, and checking each packet
aginst these policies can be expensive. Flow identification allows
considerable efficiencies in this, by making the check only once, when
the flow is set up. Following packets are only checked for their
membership in the flow, not against the complete access control
policy.
IESG [Page 28]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
In addition, the routing of packets through the system, which is
currently done on a hop by hop basis, will quite likely in the future
be more completely controlled by the source, to allow the users more
policy control over the flow of their packets through the system.
Second, it appears that the existing IP address architecture is
unsuitable for long-range growth, and needs to be redone. The
existing addresses are both too small, and lack enough structure to be
useful in a really large network. A new address structure will have
to be designed and deployed. A final scheme has not yet been picked,
but the are good arguments that the address design should be an
integral (and dependant) part of the design of a new routing protocol
(i.e. the addresses should be whatever makes the job of the routing
protocol easiest), so the primary technical content for this work will
come from the Routing Area.
As a side effect of some of the schemes, the IP model may be enriched
by the concept of a host identifier (separate from the concept of
network attachment address), which would allow work to meet some
longstanding goals of the architecture, such as moving hosts.
6.2.2 Congestion Control and Resource Management
Another area in which flows can perhaps usefully help is in the are of
congestion control and resource allocation. When congestion happens,
having a history of past behaviour can be useful in identifying which
host needs to be told to decrease its resource usage. Also, if
guarantees of available resources in the future are to be made, the
system needs some way of identifying the entity that 'owns' those
resources.
Some very good work has been done in handling congestion with respect
to long-lasting flows at fairly constant rate, but new applications,
such as remote file access (as opposed to, say, file transfer) will
subject the system to demand patterns which are more variable, and it
is clear that the system is not prepared to deal with this.
The most serious point to be recognized here is that almost anything
done in the way of handling congestion control will require
cooperation from all the hosts in the Internet, which means that all
the hosts in the system will have to be modified. Since this is a
lengthy and laborious process, for practical logistical reasons, this
work needs to be commenced as soon as possible; the longer the delay,
the more painful putting it into service will be.
However, unlike the routing problem, a lot of full time research in
the congestion control area remains to be done before the outline of
the correct solution is avaiable. The spectrum of control mechanisms
ranges from a pure feedback system (in which information about
IESG [Page 29]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
conditions in the network is sent back to the source of the traffic)
to a pure reservation system (in which resources must be reserved
before any traffic can be sent). Proposed solutions to the problem
range along this spectrum, and there are good theoretical arguments
for each proposal.
Some work has been done in this area by various researchers, but
things are not yet at the state where only engineering remains. These
researchers have come together under the umbrella of the End-to-End
Task Force of the IAB, and are making good progress in their work, but
a definitive answer is not yet clear. Probably large-scale
experimental experience will be necessary before it is possible to
make a single recommendation as to the architecture to be followed in
this area.
6.2.3 Configuration
As the Internet becomes more ubiquitous, it becomes increasingly
important to simplify the addition of new nodes to the network. Hosts
and routers often require extensive manual configuration by a person
with a fair amount of technical knowledge before they can communicate
on the Internet. Although this is perhaps not as immediate a
constraint on Internet growth as are the addressing and routing
problems described earlier, we do need to make an effort to reduce the
number of knobs and switches that have to be correctly set in order to
communicate. To the extent which we are not successful in that goal,
we need to further refine our practical knowledge of how to make the
system be tolerant of misconfigured hosts and routers.
The exact steps that we ought to take to make configuration simpler
are far from obvious, though some have suggested that the Appletalk
protocol family might have some approaches which we could usefully
adapt. And some progress is already being made: Router Discovery
will eliminate the need for one particularly mystical bit of host
configuration, and Dynamic Host Configuration will make it much easier
for organizations to centralize host configuration, making it less
necessary for individual system managers (or even work station users,
in an extreme but very common case) to be fluent in the configuration
of host networking software.
Configuration complexity is something that we need to give increased
weight to when we evaluate future protocols and changes. This is also
an area where we need to work with the other IETF areas, since
configuration complexity is a problem which is hardly limited to the
lower layers of the protocol stack (in particular, the bulk of the
configuration of the lower layers is involved with routing and
addressing, the domain of the Rouing Area). Probably the lead in this
area should be in the hands of either the Operations Area or the User
Services Area.
IESG [Page 30]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
6.2.4 A New IP Packet Format
There is some feeling that the new address format, together with
changes in such areas as resource allocation and policy routing, will
make the existing IP packet format obsolescent, and that an effort
should be started now to design a replacement. This idea has merit,
but at the moment it appears that this should be delayed.
The counter-argument goes that the world of data communications is
above to receive a substantial upheaval based on the deployment of new
technologies such as ATM fabrics, and that as a result of that, ten
years down the road, the environment will be fundamentally different,
and any protocol designed at this point will be incorrect for it. For
instance, if the ATM fabric is the ubiquitous data transport
mechanism, a classical layer 3 might not be needed at all.
It is not clear whether this is in fact the path we face. There are
arguments that physics and economics will continue to mandate a range
of data transmission technologies, much as these forces have kept a
range of storage media, from RAM through disk, in existence over a far
longer period than was expected.
In any case, it seems wise to delay action on this matter until a
clearer view of the future is available, but only if no pressing need
is being supressed. Clearly, if some major problem needs a new IP
packet format to be solved, then this decision will have to be
revisited, but at the moment it does not appear that this is the case.
Solutions are available for the two major problems listed above which
do not mandate the immediate deployment of a new IP packet format.
(This has the obvious side benefit of saving valuable resources, both
in protocol design effort as well as deployment.)
A number of new addressing and routing architectures have been
proposed which do not require a new packet format. Among these are at
least one which proposes a very agressive new architecture, the full
benfit of which would not be available until a new packet format is
available, but which can be deployed in its (effectively) final form
without changing the format. The benfit of this is obvious; when and
if a new packet format is deployed, it will not be crippled by an
addressing and routing architecture which was unable to target all the
goals it should have since it had to work with the old packet format.
The situation is less clear in the resource allocation and congestion
control area, since the work there is somewhat less advanced, but from
early indications it appears that the same is effectively true there
as well.
IESG [Page 31]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
6.3 Specific Actions
In reviewing these actions for priority, it is clear that the new
addressing/routing work must be given a high priority, as the lead
time is substantial, and the work difficult.
An equally high priority must be given to the work on resource
allocation, since the changes to the hosts need to be undertaken as
soon as possible. Since both are likely to use the 'flow' mechanism,
there does need to be coordination between the two efforts.
6.3.1 Addressing
Very short term solutions to the address space depletion problem will
be investigated by a working group convened for that purpose. The
likelihood is that we will experience problems with the address space
before a full solution is available, and this group will investigate
simple, easily deployable patches to extend the life of the existing
addressing architecture to allow a good job to be done on the
replacement. That group will be formed shortly, and we will be paying
close attention to it in order to ensure that that group reaches a
conclusion in fairly short order.
Development of a longer term solution will be left to the Routing
Area, since it is critical that the solution also address the problem
of the explosion in the amount of routing information. Because we
view this as critical to the long term success of the Internet, we
expect to make substantial contributions to that effort.
6.3.2 Congestion and Resource Allocation
It appears that is not yet quite time to start developing the effort
in this area, since until a clearer idea of the congestion control and
resource allocation architectures (which probably are not the same,
although they will probably be closely related) is available the
effort will be slightly groping in the dark. It is slightly premature
to say what WG structure will be needed since it is unclear to what
degree the transport protocols, etc will have to be modified, if at
all.
6.3.3 Configuration
Short term, we will be working on two projects. First, we will
attempt to wind up and then progress through the standards process the
IESG [Page 32]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Router Discovery effort. Second, we will work with the Dynamic Host
Configuration to brind that effort to fruition in a timely manner.
There are currently no longer term plans in this area, though we will
continue to look for attractive avenues to pursue.
6.3.4 Security
The security problems will need WG's set up to address individual
areas of concern, but the main security problem at the packet layer is
in the routing, and once again this must wait on the new routing
architecture.
There are existing efforts to define IP options for security labelling
in both the U.S. military and the commercial domains. These efforts
are outside of the Internet Area.
6.3.5 High Speed Switch Architectures
It does not appear that the Area needs to sponsor work on high speed
switches, since a number of commercial entities are doing this.
6.3.6 IP Encapsulation
A working group to specify the encapsulation of IP in CLNP and vice
versa needs to be spun up, in conjunction with the ISO Area. This is
not expected to be difficult, but mayh not be done in the short term
because of an apparent lack of personnel to carry this effort through.
6.3.7 Media Support
A number of working groups to specify the support of IP on various
media are currently operational, and no major media are unspeccified.
Some of the early efforts could use revisiting, a problem we will be
addressing through the Link Layer Requirements effort. We intend to
defer that effort until Router Requirements is complete, since we
don't think that adequate manpower will be available until then.
We will continue to start up groups as necessary to specify IP over
new media types that are developed.
IESG [Page 33]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
6.3.8 Router Requirements
The current Router Requirements effort is expected to complete in the
Fall. Long term another revision will be needed, but not for several
years and not until the Link Layer Requirements and the revision of
the Host Requirements are completed.
There have been a few suggestions that Router Requirements will need
an addendum to cover non-IP protocols, most notably CLNP. We have no
plans to pursue that at this time.
6.4 Host Requirements
Once the Router Requirements and Link Layer Requirements are complete
and their authors have had a short rest to recoup energies, the Host
Requirements update can be undertaken in cooperation with the
Transport and Application Areas.
6.4.1 IP Specification
There are a number of areas where the architecture has evolved but the
specifications have not. Short term, we will be beginning an effort
to specify the use of variable width subnets and another effort to
study the use of multiple logical networks or subnets on a single
physical network. We don't expect that either of these efforts will
be terribly difficult, but they do need to be done.
We would also like to produce a modern specification of subnetting,
since this seems to be an area of considerable mystery to many network
managers. At this point, we don't know whether the manpower which
would be necessary to do this can be found.
6.4.2 ICMP Specification
The ICMP Protocol currently is documented though a basic document, and
then tangentially in a number of more recent documents. Also, the
protocol contains some obsolescent feaures which have been replaced by
more powerful equivalents. A clear document needs to be created, and
obsolescent mechanisms removed. This effort will also be low priority
due to the lack of manpower.
IESG [Page 34]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
7 Network Management
This chapter outlines a plan for Internet network management in the
next five years. It includes an overview of the current state of
internet network management, a description of relevant goals, and a
plan for realizing those goals.
The Network Management Area of the IETF engages in discussion,
definition, and evolution of common mechanisms for the management of
host systems, gateways, bridges, modems, terminal servers --- in
short, all of the devices that may be present in a managed internet.
Owing to the management need to instrument all relevant functions in
each network element, the network management activity has a natural
overlap with IETF areas that focus on those functions (e.g., Internet,
Routing, Applications).
The NM Area comprises all activity that pertains to the management of
network elements that implement the TCP/IP protocol suite. This
definition includes the activities of numerous IETF Working Groups
that are based on the SNMP network management framework as well as the
use of OSI management mechanisms in the context of the TCP/IP protocol
suite. The management of pure OSI devices deployed within the
internet is a concern of the OSI Area of the IETF.
The NM technology currently deployed in the internet is the SNMP
network management framework. It is widely deployed and supports the
operation of production networks on a daily basis. The SNMP framework
currently comprises a common methodology for defining management
information (RFC 1155), a common management protocol (RFC 1157), and
common instrumentation for core aspects of the TCP/IP protocol suite
(RFC 1215). In addition, management instrumentation has been
developed for a wide range of device types and functions. While a
certain portion of the deployed instrumentation is of proprietary
origin, the use and value of such instrumentation in this framework is
often comparable to that based on common definitions.
The evolution of network management technology must address the
challenges of ubiquity, reliability, and both technological and
administrative heterogeneity posed by the future internet; at the same
time, it must not compromise those aspects of existing mechanisms that
are ultimately of greatest value to network operators and users alike
--- their operational robustness and capacity for broad deployment.
7.1 Area Goals
The overall goal of the network management activity is to provide a
robust and ubiquitous infrastructure that assists network
administrators in assuring the operational availability of network
services --- both in the short-term (e.g., by fault isolation,
configuration, or security functions) and in the long-term (e.g., by
IESG [Page 35]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
performance analysis or accounting functions). Implicit in this
overall goal are a number of aspirations for the future NM
infrastructure in the internet.
1. To address the issue of reliability in the future internet, it
should realize common management services consistently with the
robustness, ubiquity, and cost requirements that distinguish
network management systems from other network applications.
2. To address the issues of reliability, ubiquity, and technological
heterogeneity in the future internet, it should afford common,
integrated instrumentation for monitoring and control that is
comprehensive both in scope and deployment.
3. To address the issue of administrative heterogeneity in the
future internet, it should provide for secure monitoring and
control of network devices or functions by appropriately
authorized parties.
4. To address issues of reliability, ubiquity, and administrative
heterogeneity in the future internet, it should provide for
``end-to-end'' management --- potential management of any managed
node by any management station --- subject to relevant
topological and administrative constraints.
5. To address issues of scale and ubiquity in the future internet,
it should provide a common framework and mechanisms for
administrators to distribute management function among network
elements in ways that are consistent both with the robustness
requirement and with local topologies or administrative policies.
6. To address issues of reliability, scale, and ubiquity, it should
provide frameworks and mechanisms to support powerful management
applications in ways that neither constrain application internals
nor impose burdens on managed nodes.
7.2 Specific Work
7.2.1 Comprehensive Instrumentation
7.2.2 Maturity and Deployment
Realizing instrumentation that is comprehensive in its deployment will
require maturation and wide implementation of currently defined MIB
specifications. Although implementation of the latest core MIB
(MIB-II) is heartening, it represents but a relatively small fraction
of the more than 1000 MIB objects defined in recent times. While
further MIB development in certain areas is required to complete the
picture of MIB work already begun, in other areas, deployment and
operational experience lag behind the specification process.
Accordingly, timely closure, review, and advancement of outstanding
IESG [Page 36]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
MIB definitions should be sought. Implementation of these MIBs in
relevant products should be sought informally by providing
opportunities for discussing such implementations and issues related
thereto. Where appropriate, working groups could be chartered for
modest, well-focused MIB development that directly complements or
rounds out current MIB efforts.
7.2.3 Multi-Protocol Context
In a multi-protocol internet, comprehensive instrumentation means that
MIBs are defined as needed to provide for management of multi-protocol
devices via whatever management protocol community need and interest
demand. It is absurd to require implementors to realize multiple
mangement protocols in a single device merely for want of MIB
definitions that support comprehensive management of that device via a
single management protocol. Common MIB definitions to support
management of multiprotocol devices via the SNMP are currently of
limited scope and should be developed as community need and interest
demand.
7.2.4 Cooperative Foundation
Realizing comprehensive instrumentation can also be facilitated by
seeking ways of enlarging the cooperation between the IETF and other
standards bodies in the development of SNMP MIB specifications,
particularly in those functional areas where such bodies can provide
specialized expertise. This sort of cooperation may be facilitated by
extensions to the management framework, mechanisms for liaison,
clarification of techniques and process, or other strategies.
The addition of a small number of SMI types could possibly facilitate
the incorporation of MIBs produced in other standards forums into the
internet context, and adoption of more formalized schema for defining
SNMP MIB objects could foster internet MIB development within other
standards organizations.
Clarifying the process by which MIBs developed in other IETF areas and
in other standards bodies are incorporated into the internet context
could also facilitate productive cooperation in MIB development.
Consistent with the goal of a robust, ubiquitous, and cost-effective
management infrastructure, future MIB development should always
minimize the amount of instrumentation required in multi-protocol
implementations by aligning the definitions of MIB objects as much as
possible with similar objects in other MIBs or with descriptions of
management or protocol functions published by other standards
organizations.
IESG [Page 37]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
7.2.5 Product Range
Comprehensively instrumenting internet devices in a coherent, useful
way will require a framework for representing relationships among
various components of individual devices. As the range and
composition of vendor products becomes broader and more various, it
becomes increasingly difficult to capture the structure of many
products (e.g., brouters, ``wiring centers,'' hubs, repeaters, and
multiplexors of various sorts) via static, traditional models of
networking. Such a framework should be formulated, and, if it entails
definition of common mechanisms, these should be developed in
appropriate working groups.
7.2.6 Scope
Comprehensive instrumentation entails the development of MIB support
for management of all relevant aspects of the internet. In
particular, MIB support for the mangement of hosts and applications
will be needed. Achieving this goal requires architecturally
acceptable solutions to some rather daunting technical problems, and
it requires definition of common mechanisms that can accommodate the
overwhelming heterogeneity of host systems. In this context, initial
work towards this goal is likely to be specialized, fragmentary, and
experimental.
Owing to the many technical unknowns, exploratory work should be
pursued as experimental efforts. For example, exploratory definition
of instrumentation for a standard TCP/IP application (e.g., FTP, SMTP)
may clarify the issues of realizing that instrumentation in a
heterogeneous environment. Another possible exploratory course to
exploit the work of other organizations (e.g., IEEE 1003.7) to realize
richer host management in an internet context.
Practical success in host and application management for at least the
near-term may depend directly upon the quality of common mechanisms
for distributing management function (e.g., ``proxy'' configurations).
7.2.7 Secure Operation and Administration
The goals of secure network monitoring and control, properly mediated
``end-to-end'' management, and more flexible distribution of
management function and responsibility all depend in large part on
realizing a properly secured management infrastructure. Accordingly,
the administrative model set forth in RFC 1157 should be elaborated
into common mechanisms for both secure network management and
so-called ``proxy'' management relationships.
IESG [Page 38]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
To this end, the formulation of any new protocol mechanisms required
to properly secure the management function should be considered. Any
such solution should be realized in a way that supports transparent
interplay with so-called proxied network elements. To foster
interoperability the proper function of proxy devices in the internet
context should be clarified and delimited as part of an integrated
administrative model.
7.2.8 Architectural Effectiveness
It is critical that the insights on which effective management is
based today not be forgotten or diluted as the network management
infrastructure evolves to meet the growing demands upon the internet.
The lessons learned by the community about the proper relegation of
management burden to achieve ubiquity or the proper distribution of
management function to achieve robustness should not be abandoned and
should shape the design of new MIBs and new management mechanisms in
general. For example, mechanisms whose value depends on the
assumption that failing network elements will reliably and correctly
report their own failures to a responsible management station are
inappropriate to an efficient, effective management system. Similarly
suspect are management mechanisms that require extensive control
apparatus to mitigate the potential ill-effects of their own
operation.
The common management infrastructure of the future internet should
rest on a sound foundation. It would be irresponsible for the
community to foster and encourage the definition of common network
mangement mechanisms that do not contribute to (and even detract from)
the overall goal of the management task --- which has more to do with
the needs of internet users and operators than with the needs of
product developers.
Realizing the goal of an effective management infrastructure requires
an attention to the principles of effective management in the
development of MIBs and in the formulation of new management
mechanisms. It is facilitated by an awareness of the central
technical issues by participants in the standards process. These
needs should be addressed by the ongoing custodial and educational
activity of the SNMP Network Management Directorate and the community
leadership.
7.2.9 Enriched Management Applications
One aspect of the future management infrastructure is a rich set of
management applications and management station functions. Much as the
success of a RISC system depends upon the power of its compiler, the
IESG [Page 39]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
efficacy of SNMP management systems depends on the power of management
stations and applications. But also like a RISC system, the
effectiveness of the management infrastructure will depend enormously
upon the correct partitioning of function among its components.
In this context, the enrichment of management applications must be
predicated upon a deeper cleavage in the SNMP information model
between the abstractions realized by managers and those realized by
managed nodes. In this way, the design principles that assure
ubiquitous, effective management can be preserved while the
infrastructure is augmented to provide richer support for management
applications. The community should consider qualifications to the
SNMP information model that may be required to support further growth
of management applications without compromising the technical
principles from which the management system as a whole derives its
success.
Once an appropriate architectural model is in place, support for
common application support mechanisms should be pursued along at least
two paths.
One path has to do with defining common notations for exchanging
information about managed elements and networks among managers. This
sort of information is comparable to that currently captured by
templates in MIB specifications, but it is information that, while of
mosest value to the manager software, is not strictly necessary to the
unambiguous operation of the management protocol. For example, the
tabular abstractions currently implicit in today's MIB notation have
no relevance to the operation of managed nodes: inclusion of such
information in MIB documents is an artifact of historical IAB
policies, it is confusing to readers who lack that historical
perspective, and it is not an adequate foundation for the abstractions
required by future management applications. Development of an
appropriately bifurcated notation requires, first, some definition of
its form and appropriate architectural role and, second, the
specification of its substance.
The other path has to do with MIB objects for representing
aggregations or distillations of management information for use by
managers. This work is predicated on the assumptions that (a) prudent
distribution of management responsibility can be useful in certain
circumstances and (b) network devices whose sole function is
aggregation of management information are increasingly common.
In addition to these two areas of activity, informal discussion that
fosters enrichment of MS technology (e.g., improved configuration
management or interfaces with databases) should be encouraged within
the NM Area. Standardization of higher-level functions in management
tools (including user interfaces) is not likely to be valuable in the
foreseeable future.
IESG [Page 40]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
8 OSI Integration
8.1 Area Overview
The goal of the OSI area of the IETF is to facilitiate incorporation
of the OSI protocol suite into the Internet. The plan has two main
parts. The first part defines the goal; it provides a summary (by
layer) of the deployment of OSI protocols envisioned by 1995. The
second part presents a snapshot of the current state of OSI
deployment, and enumerates the major tasks that must be accomplished
in order to reach the goal.
8.1.1 OSI in Internet in 1995
This sections presents a layer-by-layer view of the integration of OSI
into the Internet. It is a goal to achieve this degree of integration
by 1995.
8.1.2 Physical & Link Layer
It should be possible to operate OSI and TCP/IP (as well as selected
other protocol suites) over all appropriate physical and link layers.
8.1.3 Network layer
There are two main OSI approaches at the network layer:
connectionless service and connection oriented service. The OSI
connectionless network layer protocol (CLNP -- OSI 8473) is very
similar to IP, and can essentially be thought of as IP (including
features from ICMP) with the addresses made larger and more flexible.
As such, CLNP is the logical OSI protocol for use alongside of IP in
those parts of the Internet which are currently based on IP.
Note: for the remainder of this chapter, the term ``IP'' will be used
to refer to the Internet Protocol component of the TCP/IP Protocol
Suite. CLNP is the term used for the OSI Connectionless Network
Protocol -- the OSI counterpart to IP. The term ``CONS'' is used to
refer to the OSI Connectionless Network Service (for example, as
provided by X.25).
In practice, it is not clear whether either CLNP or IP will be
ubiquitous in the Internet in 1995. However, it would be highly
desireable to provide a ubiquitous network layer service. The
availability of a ubiquitous IP service has been a major reason for
the success of the TCP/IP protocol suite. Thus, ubiquitous
IESG [Page 41]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
availability of CLNP service, at least in all major Internet
backbones, is seen as an important goal of the OSI Integration area of
the IETF.
The major Internet backbones will be dual protocol: they will support
IP and CLNP. CLNP is supported by the following protocols (which will
be widely available as part of any commercial vendor's network product
set):
o ISO 8473: (Connectionless Network Layer Protocol -- CLNP)
o ISO 9542: (ES-IS protocol)
o ISO 10589: (IS-IS protocol, for routing within a domain)
o ISO xxxxx: Inter domain protocol
The Internet will continue to be divided into routing domains. Most
of these domains will be dual. However, some will operate only the
OSI network service and others will operate only the IP network
service.
We anticipate that both integrated routing and ``ships in the night''
will be used. Most likely, Integrated IS-IS will be common in those
routing domains where IP and OSI CLNP topology and routing policy are
similar. Other domains that have different topologies for IP and OSI
will use the ships in the night approach.
There will be (at least) two different inter-domain routing protocols
in use, one for OSI traffic and one for IP traffic. Technically, one
protocol could be used (development of a single inter-domain routing
protocol to support both IP and CLNP is technically very simple).
However the political difficulties in standardizing one common
inter-domain protocol make this unlikely. Also, there is less need
for a single inter-domain protocol (as compared to a single
intra-domain protocol).
OSI connection-oriented network service (CONS) may also be common,
particularly outside of the USA. This may imply that there will be no
single ubiquitous network service. OSI CLNP, CONS and IP will be
deployed in various combinations.
8.1.4 Transport
The following combinations of network service and transport protocol
are expected to be in common use with OSI applications:
o TP4/CLNP
o TP0/CONS
IESG [Page 42]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
o RFC 1006/TCP/IP
There is some chance that other OSI transport protocols may also be in
use over CONS (X.25) in some countries.
It is hoped that as CLNP availability becomes more ubiquitous, the use
of RFC 1006 will fade. However, both CLNP and CONS are expected to
remain in common use.
Interoperation between common applications running over different
transport and network protocols will therefore be important. In some
places, careful placement of application relays that support more than
one network service/transport protocol combination will be used to
bridge the different communities. In other situations, transport
service bridges will be deployed. It is an important goal to allow
interoperation between OSI applications over different transport and
network protocols, as well as to minimize the complexity, as seen by
the user, of such interoperation techniques.
8.1.5 Applications
Many applications will be in use: some OSI, some TCP-based, and some
of other origin. The applications which are expected to be most
common (and most important) are listed below.
X.500 Directory Services
By 1995, X.500 will be widely deployed in the Internet. This will be
used by other OSI applications (e.g., to find the destination
corresponding to known user name). In addition, X.500 is important
for aiding in interoperability with other protocol suites such as
TCP/IP (e.g., to determine which protocol suite can be used to contact
a known user, to locate application gateways, etc..). Also, X.500 may
be used to offer extended directory services in otherwise pure-IP
environments
X.400 & RFC 822 based mail
RFC 822 mail may still be in widespread use. However, many 822 users
may have switched over to X.400.
Important goals, necesary for the adoption of X.400 in the Internet,
include: (i) Availability of publically-available software providing
a high quality user agent for X.400; (ii) Availability of multi-body-
part X.400 services, possibly including convenient handling of
Postscript, FAX, ODA, and image data; (iii) Widespread availability of
X.500 directory services; and (iv) Agreement on a user-freindly naming
scheme, which can be available in the X.400 user agents through use of
IESG [Page 43]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
the X.500 directory service; (v) Availability of Email gateways,
allowing SMTP users and X.400 users to interoperate.
Many users may also be using ``integrated'' user agents, in which the
user deals with only one electronic mail user interface, but which is
capable of sending and receiving mail in a variety of mail formats
(including SMTP and X.400)
FTAM & FTP
<this section needs completion>
VTP & Telnet, or ???
It is very difficult to anticipate the degree to which VTP is likely
to displace Telnet, and/or other protocols may be important for future
terminal access. For example, special forms protocols (for low end
terminals) and X-windows (for high end workstations) may become
important.
ODA
The Office Document Architecture allows documents to be exchanged
between dissimilar text/document processing systems. This is of
importance, for example, in order to facilitate cooperation in
document preparation between people with different worstations or word
processing systems. It is therefore an important goal to ensure the
widespread availability of ODA in the Internet.
Network management
Both SNMP and CMIP will be widely deployed. Of greater importance,
however, is the development of more powerful and more convenient
network management applications, which rely on development and
widespread availability of standard MIBs.
8.2 Specific Work
This section describes the status of OSI integration in 1991, and
additional work that is needed in order to meet the goals stated above
for OSI service in five years. This section is organized by layer.
We can expect that introduction of OSI into the Internet will be
gradual. Some services (Electronic mail, directory services,
connectionless network service) are likely to be introduced at an
early stage. Other services will be introduced later.
There are some places where the existing OSI protocols are incomplete,
or require subsetting or ``profiling''. Thus there may be places
where we either need to introduce interim solutions, come up with
IESG [Page 44]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Internet-specific profiles, and/or work with other standards
committees to fill in ``holes'' in the OSI protocol suite.
8.2.1 Physical and Link Layers
Choice of Point to Point Protocol
PPP is the Internet standard point to point protocol. HDLC is the
International standard point to point protocol. Both protocols can,
at least in principle, be used to support both IP and CLNP service.
However, some work is needed to standardize how to do this (see
below).
It is unlikely that PPP will be adopted by ISO, and it is therefore
likely that there will be two different standard point to point
protocols. The protocol to use over any particular link will in
general be a configuration option (in the sense that any particular
link will use one protocol or the other, and the choice will either be
a function of what equipment is placed on the link, or of the
configuration of the equipment).
OSI over HDLC and X.25
There is no specification for the multiplexing of OSI and IP packets
on an HDLC link, nor over a single X.25 virtual circuit (it is
possible to mutiplex CLNP and IP packets by using two X.25 virtual
circuits, but this in undesireable in some cases when using equipment
that limits the number of virtual circuits that can be open at one
time).
We need a specification which defines a standard method for the
operation of OSI and TCP/IP over HDLC. This would allow OSI and IP
packets to be distinguished on an HDLC link (or a single X.25 virtual
circuit) by examining the Network Layer Protocol ID (NLPID) field of
the HDLC or X.25 header. NLPIDs have been assigned for IP and CLNP.
Technically this is a very simple task, but there is a need to
identify an individual to push this in standards forum, and there is
an issue as to which standards forum would be appropriate.
OSI over PPP
There is currently an Internet Draft which specifies operation of CLNP
over PPP. This needs to be reviewed and progressed as an RFC.
OSI over 802 networks
CLNP and IP packets may be distinguished on 802.2 links by examining
the Destination Service Access Point (DSAP) field in the 802.2 header.
DSAP values have been assigned for OSI packets as well as IP packets.
IESG [Page 45]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Network Layer
The OSI connectionless network service is important for early
introduction in the Internet because (i) it forms a base for other OSI
protocols to run on; (ii) Products are available, or are expected to
be available soon; and (iii) Given the increasing address limitations
of IP, ISO offers a solution which is needed in the Internet (or will
be needed within two to five years).
The connectionless Network Layer Protocol (CLNP -- ISO 8473) is
complete, as is the End-System to Intermediate-System Protocol (ES-IS,
ISO 9542). A CLNP pilot project is currently underway in both the US
and Europe.
The IS-IS intra-domain dynamic routing protocol is currently a DIS in
the ISO/IEC standards organizations. IS-IS for CLNP is being
progressed rapidly, and is anticipated to become an International
Standard in 1991. Some products are in field test, a public domain
implementation of IS-IS is nearing completion. CLNP routers will be
widely available in late 1991.
There is a draft specification of an Inter-Domain Routing Protocol
(IDRP). This specification is being progressed through ANSI. We need
to work in conjunction with ANSI X3S3.3 and/or associated ISO groups
to ensure the rapid development of (i) An ISO standard for
inter-domain routing; and/or (ii) an interim solution (based on the
draft work in ANSI) for inter-domain routing.
Large scale CLNP pilots have begun in Europe (centered on Nordunet)
and the US (centered on the NSFNET backbone). These pilots are
interconnected. It is expected that these pilots will grow into an
operational service.
The US GOSIP NSAP format is complete (given GOSIP Version 2.0 final
release -- GOSIP Version 1.0 has an errata that specifies use of the
GOSIP Version 2.0 NSAP address format). The lower portion of the
address has a structure that ensures compatibility with the IS-IS
intra-domain routing protocol. The GOSIP Version 2.0 format should be
used for those administrations which are getting their address
assignments from the US government address space.
ANSI also assigns NSAPS with a format that currently has no structure
imposed on the DSP (the lower order part of the address). These
addresses will be used by U.S. non-government networks. A common DSP
structure similar to that defined in GOSIP Version 2.0 is being
progressed in ANSI
Other NSAP formats will be used in other countries. These may in some
cases be different from the formats used in the US. This should not
prevent interoperation (since routing to destinations outside of any
particular routing domain is based on address prefixes, and does not
IESG [Page 46]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
require any particular low order part of the address). However, this
may be awkward for vendors, by requiring that products support
multiple formats.
The NSAP working group in the IETF is working on guidelines regarding
OSI addressing. Of particular concern is NSAP administration, and
assurance that the manner inwhich NSAPs are assigned will support
routing in a very large Internet (several orders of magnitude larger
than the current Internet). An Internet Draft has been released (and
upgraded based on comments received), and an RFC is expected soon.
Finalization of a scheme for multi-level hierarchical address
assignment, particularly in a large Internet whose topology does not
follow a strictly hierarchical model, is a difficult task. There are
fundamental tradeoffs required between routing quality and
flexibility, and the amount of information required to achieve
routing. We expect that as CLNP is deployed in the Internet, we will
continue to learn more about the use of hierarchical addressing in a
large Internet. The current NSAP guidelines document represents the
best knowledge available for assignment of NSAP addresses. However,
these guidelines may be upgraded in the future as additional
operational experience is achieved with CLNP.
We are not aware of any Internet-specific work that is needed for
introduction of OSI connection-oriented network service (based on
X.25) into the Internet environment. However, assuming that CONS will
be common use (probably outside of the US), the interoperation of
TP4/CLNP and TP0/CONS (CO/CL) is an important OSI problem. A set of
Internet Drafts has been released (and are being actively reviewed)
which specify a proposed solution to this problem.
8.2.2 Transport
The OSI Transport Layer protocols (TP0 through TP4) are finished, and
have been available in products for several years. Not all current
TP4 implementations have incorporated enhancements similar to the
recent improvements in TCP.
There is an urgent need for development of solutions which allow
interworking between stations using common OSI applications over
dissimilar network and transport services. Specifically, work is
needed on transport relays between (i) Systems running RFC 1006 (OSI
applications over TCP over IP); (ii) systems running OSI applications
over TP4 over CLNP; and (iii) systems running OSI applications over
TP0 over X25. Due to the complexities involved in use of such relays,
it is desireable to faze out the use of RFC 1006 over time, as well as
to attempt to move towards a single ubiquitous OSI network layer
service.
IESG [Page 47]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
8.2.3 Applications
Introduction of OSI applications in the Internet may be expected to
take place on a gradual basis (with additional applications introduced
over a period of time). Pilot projects are currently underway for
X.400, X.500, and ODA.
It is highly desirable that future Internet applications work be
coordinated with OSI applications standards. For example, in those
specific cases where a new application is needed for the Internet,
where an existing OSI standards exists, and where the OSI standards is
found to be acceptable, then it would be unfortunate for the Internet
to develop an separate independent protocol for the same application.
This presents an opportunity for international standardization of
common applications for use with both OSI and TCP/IP protocol suites.
In the short term, it is also useful to run OSI applications over
TCP/IP, using the approach outlined in RFC 1006. In order to
facilitate eventual transition to pure OSI service, it is highly
desireable that all end systems which are deployed with the ability to
run in a mixed-stack mode (OSI applications over TCP/IP) also have the
ability to run in a pure-OSI mode (OSI applications over TP4 over
CLNP).
Directory Services / X.500
<this section needs completion>
Electronic Mail / X.400
An Internet X.400 pilot project was started in September 1990. The
goal of this pilot project is to operate a production quality
management domain in the Internet and document the information that is
learned from such an operation.
A working group in the IETF has been formed to produce a document that
specifies the requirements of a X.400 management domain in the
Internet. This group's task is to insure that the various management
domains in the Internet can interoperate with each other.
A requirement of X.400 naming in the US is that a central authority
take charge of administering X.400 management domain names. One of
the important tasks of this group is to insure that management domain
names are unique. An initiative with the US State Department (Study
Groups A-D) has been formed to oversee the creation of such an
administration in the U.S. We are not aware of the status of similar
efforts in other countries.
The interoperation of X.400 and RFC 822 has been specified by RFCs 987
and 1148.
IESG [Page 48]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Operation of an 987/1148 gateway requires the global distribution of
static address mapping information. The current practice of manual
distribution will not scale. An experimental use of the DNS to store
the mapping information has been undertaken at the University of
Wisconsin. Storage of the mapping information in the DNS allows the
information to be stored in a distributed manner. An internet draft
produced by the IETF-X.400 working group defines the method of storing
mapping information in the DNS.
The widespread acceptance and use of X.400 will largely depend upon
the availability of suitable user agents, and on the availability of
extended ``body parts'', which provide service beyond ASCII text. Of
particular importance are Postscript, ODA, and FAX (although other
extended body parts such as image may become important as well).
Development of a public domain user-friendly user agent for X.400,
offering extended services, is therefore of very high priority.
X.400 Security
There is considerable work in both the Internet (RFC 822) community
and the ISO (X.400) community on security for electronic mail. It
does not appear that there has been any serious study of how a mail
gateway affects the two security models. Other types of application
layer gateways and transport layer bridges may also effect security.
Virtual Terminal Protocol
The Virtual Terminal Protocol VTP is the OSI version of remote login.
There has been a VTP profile written, that is similar to the Internet
TELNET protocol. There currently is an implementation of this, where
both the OSI VTP and the Internet TELNET can run in the same host.
This results in an application relay running directly in the host,
thereby by-passing the added complication of determining where the
application gateway is located. A user can login to the host via
either VTP or TELNET and from there perform additional remote logins
to other machines with either TELNET or VTP.
There is also another profile which is more in tune with the
International Telegraph and Telephone Consultative Committee (CCITT)
recommendation for the terminal standard X.3, X.28, and X.29. The
functionality is very similar to TELNET. In addition, there is a third
generic VTP profile.
In regards to the user locating the application gateway, one solution
is to require a two step login. The user explicitly logs into the
application gateway via VTP or TELNET and from there uses TELNET or
VTP to get to another destination.
More work is needed on virtual terminal protocols for use in the
Internet. This may, for example, include work on VTP support for
forms and X Windows, and might possibly include use of Telnet directly
IESG [Page 49]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
over the OSI Transport Service.
File Transfer
An experimental application gateway between the OSI File Transfer,
Access and Management (FTAM) and the Internet File Transfer Protocol
(FTP) has been written. There is an internet draft that specifies the
operation of an FTAM FTP gateway.
As in the VTP and TELNET scenario, it is feasible for a user to use a
two step approach. For file transfer it is a burden since multiple
file transfers may be executed in a login session as well as in
application software. It would be greatly preferable to make use of
gateway functions which were transparent to the user (although the
means to provide this service, such as automatic application gateway
discovery through use of directory services, have not been specified).
Remote Database Access (RDA)
This standard has two parts (Part 1: Generic Model, Service, and
Protocol; and Part 2: SQL Specialization. Both parts are expected to
progress to DIS status in October, 1991. It would therefore be a good
time to start thinking about a possible RDA pilot effort in the
Internet.
Office Document Architecture (ODA)
There is currently an ODA pilot project in the Internet, coordinated
by the IETF ODA working group. There is also ODA software (backend
converters, editors) available for public use.
Information Retrieval -- Z39.50
Z39.50 is an US ANSI standard protocol that specified how information
retrieval systems search and retrieve information from each other. It
is specified in ISO DP 10162 and DP 10163.
In the US there are a group of implementations either currently
underway or in the planning stages. An implementors workshop has been
formed.
There are two basic camps involved in the implementation. One groups
is planning on doing an implementation as a straight OSI protocol
stack using all seven layers. The other plans on running the protocol
on TCP networks and will implement session, presentation, and ACSE
directly on top of TCP.
IESG [Page 50]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
8.2.4 Network Management
SNMP is widely in use for management of TCP/IP systems. Pursuit of
the use of CMOT for management of pure TCP/IP systems does not seem
fruitful at this time. There is some work (both inside and outside of
the Internet community) on the use of CMIP for management of pure OSI
systems.
The use of both CMIP and SNMP to manage pure OSI networks should be
explored. An attempt should be made to coordinate SNMP-based OSI MIB
development and CMIP-based OSI MIB development.
MIBs should be defined for (i) management of IP using SNMP (in
progress, outside of the scope of this area); (ii) management of OSI
using CMIP; (iii) management of dual IP and OSI systems using SNMP;
and (iv) management of dual IP and OSI systems using CMIP. Note that
operation of two management protocols (SNMP and CMIP) in a single
management station is not as much of a problem as the potential for
different MIBs using the two suites. In addition, the experience
gained in management of current IP systems may be of use in management
of OSI systems. Thus the development of OSI MIBs should be
coordinated with the current efforts for development of IP MIBs.
8.3 An Infrastructure for OSI
TCP/IP has been very successful for a number of reasons, including the
existence of an intrastructure for facilitating TCP/IP operation. In
order to make OSI successful, it is similarly necessary to create an
OSI infrastructure. The TCP/IP infrastructure can serve as a model of
what an OSI infrastructure will need. In addition, some specific
parts of the TCP/IP infrastructure may be used directly for support of
OSI.
The necessary elements of a infrastructure may include:
o Means for creating base standards; and
o A timely means for ``fixing errors'' in the base standards
o Means for document distribution (including protocol standards,
related proposals, general ``how to'' information, etc); and
o Means for controlling which documents are distributed
o Method for address and name allocation / Registration.
o Access to software and intellectual property.
o Backbone and Regional networks
o etc..
It is clear that many parts of the OSI infrastructure already exist,
but the infrastructure is incomplete (or in some cases ineffective).
IESG [Page 51]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Also, it is clear that an infrastructure for OSI must be distributed
(i.e., there is no one central organization which can take control of
the process). This makes coordination difficult and liaison
essential. In general, the development of an OSI infrastructure must
be handled on an item-by-item and case-by-case basis.
There are a large number of organizations and committees which must
play a role in the definition and use of OSI. Naturally, this includes
OSI-related standards committees and related activities (including,
but not limited to, ISO, ANSI, CCITT, etc). Also, as OSI becomes more
common in the Internet, the activities of other areas of the IETF will
become increasingly OSI-related. Thus we can expect that extensive
liaison will always be part of the function of the OSI-area of the
IETF.
Much of the OSI-related work in the IETF will increasingly be of
interest to other areas as well. For example, much of the OSI
Applications work is of interest to both the OSI and Applications
areas. As OSI is further introduced into the Internet, we can expect
that the distinction between the OSI and TCP/IP protocol suites may
become less clear. We should therefore be expecting that the
OSI-related work in the IETF will gradually be integrated with other
work, thereby eventually eliminating the need for a distinct OSI
Integration area.
There is another important issue relating to both the OSI and the
TCP/IP infrastructures. In particular, it is clear that both OSI and
the Internet protocol suite will continue to be developed and enhanced
in years to come. For example, there is a project in ANSI to develop
a next generation network protocol. Similarly, there is a proposal
for a project in the IETF to develop a successor to IP. It would be
highly unfortunate if these efforts were to take place independently.
Coordination is important for two reasons: (i) To allow sharing of
ideas and results, in order to cause both solutions to be as good as
possible and to reduce redundancy in the research efforts; (ii) If
possible, to allow convergence of the two protocol suites.
IESG [Page 52]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
9 Operational Requirements
The IETF has traditionally been a technology development group. Its
original constituency was protocol developers and researchers. During
the earliest period (including prior to the formal formation of the
IETF), there were no ``operational'' networks. All networking
activity was ``research and development''. Therefore, the protocol
developers and researchers were often also the same people who
administered the local networks.
Over time, as the number of networks comprising the Internet
increased, non-networking specialists began to use the Internet and to
rely on it as a necessary tool of every day business. This signaled a
significant change in the character of the Internet, as networks
evolved from testbed to more fully operational.
This also signaled a change in the constituency of the IETF. In
addition to the protocol developers and researchers, network
administrators began to participate regularly in IETF. Perhaps in a
more turn-key environment, this would not have been the case, and the
mixed audience of developers and operators would not have seemed so
natural. However, it is fair to say that the evolution from research
vehicle to fully operational entity has not been completely smooth.
In some respects, it is still going on today.
The TCP/IP protocol suite originated as non-vendor specific products.
Instead of vendors delivering fully supported products, researchers
often released to the public domain what amounted to beta versions of
software packages. Although this resulted in very quick distribution
of new software capabilities, it also resulted in labor intensive
maintainence of the resulting capabilities. The early breed of
Internet network administrator was indeed a hearty soul, who fit in
very nicely with the protocol development community at IETF -- largely
out of necessity.
Therefore, from the beginning of the emergence of the Internet as an
operational facility, the IETF has seen network operators and
administrators as a natural part of its constituency.
When the IETF Steering Group (IESG) was originally formed, it did not
have a distinct ``Operational Requirements'' Area. There was never
any question that about whether the IETF (or any other centralized
authority) could actually administer Internet operations on a global
scale from a single central vantage point. Of course, it could not.
Further, it was felt that operational requirements cut across all the
other IESG Areas, and therefore operational concerns could be
addressed separately in each area as required. Therefore, it was
initially felt that no separate operational area was required.
However, the audience of network operators in the IETF voiced a need
for a specific forum for operational requirements. In time, a firm
IESG [Page 53]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
``charter'' for the IETF Operational Requirements Area emerged. This
``charter'' will be discussed in the next section.
The goal of organizing an ``IETF Operational Requirements Area'' has
been an elusive goal, in part because the early vision was not as firm
as that of the other areas. However, the charter and mandate has
taken shape, and the organization of the IETF Operational Requirements
Area is now in progress.
9.1 Description
This section provides a description of the Operational Requirements
Area. This section will discuss the topics covered, topics not
covered, and the relation of the Operational Requirements Areas to
other IETF areas.
The IETF Operational Requirements Area has following mandates:
o Provide a forum for coordination between operational groups.
This includes encouraging and assisting deployment of new
technoloy and techniques.
o Development of operational methods, practices, and policies.
(eg, end-end trouble resolution)
o Guidance to other IETF technical development efforts.
9.1.1 Provide a forum for coordination between operational groups
The Internet is now an international communications inter-network
which has grown beyond its original TCP/IP beginnings. As recently
reported, the Internet has directly IP-reachable hosts in 25 countries
over 5 continents. There are many hundreds of administrative domains,
thousands of networks, and hundreds of thousands of hosts. There are
now also numerous other interconnected networks using other protocol
families (e.g., Appletalk, DECnet, OSI).
It is clearly not possible for a single group to act as the main focus
for managing the operations of this global enterprise. However,
coordination and liaison between network managers and operators is not
only possible, it is crucial for maintaining smooth operations.
It is the goal of the Operations Area to encourage coordination and
liaison between the various national and international network
operators and operational groups, and with this liasion to encourage
the usage of commonly agreed methods and practices. This should
include coordinated routing, DNS, and other network management
services to minimize problems, and the utilization of coordinated
trouble reporting and resolution policies for when problems do occur.
IESG [Page 54]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
To serve this mandate, the IETF Operational Requirements Area will
need to interact with other groups formed for operational purposes.
Such groups include RARE/RIPE, CCIRN/IEPG, FNC/FEPG, FARNET, and
network service providers. Forging this interaction and determining
the right level of interaction for the IETF will be challenging. In
some cases, the IETF should take direction from and serve as agent of
other higher-level policy-setting groups. In other cases, IETF may be
able to serve as the forum for bringing together operational groups
that otherwise may not have productively interacted.
9.1.2 Development of operational methods, practices, and policies
The first bullet charts the mandate for liasion between network
operators to implement coordinated operations. This is only possible
to the extent that common methods and policies exist. In cases where
such methods or practices do not exist, the Operational Requirements
Area will take an active role in developing guidelines and practices
for internet operations, management, and interconnection.
This could include attempting to reach consensus upon common joint
management methods for common links. It could include specifying
common managment tools, common minimum collection metrics, common data
storage formats for interchange of information, common display and
reporting formats (e.g., performance data or topology maps).
It is hoped that such consensus guidelines would then be applied in
the coordinated network management activities of the first bullet.
9.1.3 Guidance to other IETF technical development efforts
The IETF was formed as a technical development body in support of
operational networks. Many IETF activities are still motivated by the
goal of improving the operations of real networks.
Several of the other IETF Areas have development activities that
affect network operations (e.g. Network Management, Routing, User
Services, DNS in the Applications Area, etc.). It will be a goal of
the Operational Requirements Area to help define operational
requirments and set priorities for development in these other IESG
technical areas.
This demonstrates one of the main strengths of the IETF as a technical
development body. The developers of the technology and the users of
the technology work closely together with a common focus. This
mixture of developers and knowleable users sets the IETF apart from
other technology development bodies, and it shows the importance of
raising Operational Requirements to the level of an equal Area.
IESG [Page 55]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
It is this special focus which gives the Operational Requirements Area
its title.
Examples
To show how this threefold charter works in the formation of working
groups, recent working groups in the Operational Requirements Area are
discussed in relation to the above stated goals.
o Provide a forum for coordination between operational groups.
Under this bullet, standing WGs generally serve the purpose of
liaison. These group are different from other WGs in that they
may never produce written documents (other than meeting notes).
They are standing groups with less specific goals and milestones
than typical WGs in other technology development areas.
- DDN Interconnectivity WG
Liasion group between DDN and its clients, and between DDN
and its peer networks. This group meets on an as-needed
basis.
- Network Joint Management WG
Liaison group between regional mid-level networks and
national backbones. This started as a group between regional
networks and the NSFnet backbone, has since broadened it
focus somewhat.
- Topology Engineering WG
o Development of operational methods, practices, and policies.
WGs under this bullet develop technology, but in general are more
concerned with development of technical methodology rather than
protocols. For example, in the Operational Statistics WG,
methodology and tools are being developed, but the underlying
network management techniques are taken as defined by the NM
Area.
- Benchmarking Methodology (bmwg)
Developing benchmarking and testing methodology routers,
bridges, and other network components.
- Operational Statistics (opstats)
Developing commonly agreed metrics and tools for network
managment
- User Connectivity (ucp)
Developing methods for problem resolution across
administrative domain boundries.
o Guidance to other IETF technical development efforts.
There are no specific WGs under this bullet. This function of
the Operational Requirements Area is discharged simply by
bringing together network operators to develop methodology that
is then made available to technology developers in other areas.
IESG [Page 56]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
These network operators also naturally participate in the
technical developments of other areas by virtue of being at the
same IETF meetings.
Organization
The Operational Requirements Area of the IETF will have a board of
advisors (the ``Operational Requirements Directorate'', ORD) comprised
of national and international network operators. Participation on the
ORD will be invited from various sectors, e.g research, government,
industry, and private.
The Operational Requirements Area Director(s) will serve as the
Chair(s) of the ORD. It will be the responsibility of the Operational
Requirements Area Director(s) to establish the ORD and arrange for the
appropriate membership.
The Operational Requirements Area Director(s) will serve on the
Internet Engineering Steering Group (IESG), which functions as the
executive board and steering group of the IETF.
9.2 Technical Goals For The Operational Requirements Area
The Operational Requirements Area (ORA) is fundamentally different
than all other IETF Areas, with the possible exception of User
Services. The ORA is not primarily a technology development Area. It
serves the function of liasion and requirements definition (although
there are also some aspects of technology development, too).
Therefore, this section doesn't quite apply the way it does for a
technology development area.
We need to examine the issue of what basic services should be provided
by any network before it joins the Internet. That is, what services
should a network provide to be considered a good neighbor network? In
the same way, what services should a network operations center provide
in order to be able to function as a full member of good standing in
the Internet?
As many small enterprises join the Internet community, it would be
very useful to have a document, or set of documents, that define basic
services, and the methods of implementation of those services, that
are typically expected in Internet good neighbor networks.
Such requirements definition could be used for both network planners
and protocol developers. It could also be used by network
administrators to develop bi-lateral and multi-lateral operational
relationships on a coordinated basis.
As the outline below shows, some services are obvious. However, the
IESG [Page 57]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
exercise of defining these services are likely to enumerate more
details.
o Definition of network infrastructure services
- a network operations center
- a user services and assistance facility
- Coordinated network interconnections (eg, FIX's, CIX's)
- Coordinated Dynamic Routing
- Coordinated Domain Name System (DNS)
- Network time
- Directory Services
o Definition of minimum operations center capabilities
- Statistics gathering using common metrics and tools
- Problem resolution methods
- automatic network mapping
With the definition of basic service requirements, it will be a major
goal of the Operational Requirements Area to encourage the
implementation of the minimum required operations center capabilities
and infrastructure services in all Internet networks.
The Operational requirements Area will also encourage the definition
of procedures and methodology to coordinate infrastructure services
across administrative domain boundaries.
9.3 Specific Actions For The Operational Requirements Area
In the section, we will identify actions required to fulfill the broad
goals of the last section.
o Establish clear relationships with other organizations with
operational concerns and responsibilities. Determine the right
level of interaction with these groups (e.g., establish in each
case whether the IETF should take direction from, or provide a
forum for liaison with, these other groups). A partial listing
of such groups includes CCIRN/IEPG, FARNET, FNC/FEPG, RARE/RIPE,
and commercial network service providers.
o Network Operations Center Coordination
- Establish up-to-date online database of contact information
for problem resolution
- Establish up-to-date online database of link and map
information
- Establish and utilize common problem escalation procedures
- Establish and utilize security incident handling
IESG [Page 58]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
o Statistics and Monitoring
- Define common minimal set of metrics necessary for network
operations. Propose for MIB if not already in.
- Define common storage formats
- Define common presentation formats
- Define new collection and presention tools based on common
metrics.
- Propose old tools be retrofitted to utilize new paradigm.
o Explore legal implications of shared data and joint management
o Routing
- Design Intercontinental multiprotocol BACKBONE routing
structure based on a defined Administrative-Domain hierarchy.
The IEPG of the CCIRN has set a course of direction for this
topic.
o Global DNS Service
- Design and utilize true global DNS service
o Security
- Assist Security Area in defining security requirements for
network operations
- Utilize secure techniques for all the above activities as
soon as available
IESG [Page 59]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
10 Routing Area Plan
10.1 Description of Routing Area
This chapter outlines a plan for Internet routing in the next five
years. It includes an overview of the current state of internet
routing, a description of what needs to be done, and a plan for
implementing the work.
The Routing Area of the IETF is responsible for the TCP/IP family of
routing protocols which are used in the Internet. It is not
responsible for routing protocols of other protocol suites. It is
responsible for extensions of other routing protocols to support
TCP/IP routing (e.g. Dual IS-IS).
Routing protocols as well as internet addressing are the key elements
in the both the current operation and sustaining the growth of the
Internet. The success of the IETF in providing standard routing
protocols which meet the needs of the Internet will determine how far
the Internet will grow and evolve.
Internet routing protocols are divided into two classes: Interior
Routing Protocols and Exterior Routing Protocols. Interior routing
protocol run inside an autonomous domain (AD). Exterior routing
protocols run between autonomous domains. These are sometime referred
to as Inter-AD and Intra-AD routing protocols.
The current Interior protocols in use in the Internet are: Routing
Information Protocol (RIP), Vendor Proprietary (CISCO IGRP, IBM IS-IS,
BBN SPF, etc.), Open Shortest Path First Protocol (OSPF)
In addition, there is the recently released Dual IS-IS routing
protocol, but at the time this report was written it is not running as
part of the Internet.
The current Exterior protocols in use in the Internet are: Exterior
Gateway Protocol (EGP), Border Gateway Protocol (BGP)
There is also currently under development in the IETF an Exterior
protocol called the Inter-Domain Policy Routing Protocol (IDPR). This
protocol supports policy based Inter-AD routing.
The routing in the Internet is currently based on routing on a flat
address space. The one exception to this is sub-networks. All
routing protocols are required to carry information about all routes.
There is no hierarchical structure. It is doubtful whether this model
for routing can be sustained if the current exponential growth rate of
the internet is to continue.
Currently there is not one standard common interior routing protocol
for the Internet. The two likely candidates are OSPF and Dual IS-IS.
IESG [Page 60]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
The RIP protocol is out dated and does not provide for adequate
Inter-AD routing. This protocol needs to be replaced by a more modern
routing protocol such as OSPF or Dual IS-IS.
The EGP protocol is the most widely used Inter-AD protocol, but it has
been stretched well beyond its limits and needs to be replaced. The
IETF has recommended that the BGP protocol be used as a replacement
for the EGP protocol.
There are several potential services that the current Internet Routing
protocols to not support. These are: Multiple Routing Policies,
Multicast Services, Authentication of Routing Protocols, and Routing
on Large Networks
10.2 Technical Goals for the Routing Area
There are several high level goals for the routing area. These are:
10.2.1 Internet Growth - Routing should not be the limit to growth
The overall goal for routing in the internet is that routing protocols
should not be the limit to the continued growth of the Internet. This
is key. Internet routing needs to support growth in both size and
complexity. Size in terms of number of hosts, networks, autonomous
systems. Complexity in terms of topology, diversity of network types,
and policy restrictions.
10.2.2 Provide Routing Protocols for Future Environments
There are a number of new types of public networks being developed,
including Switched Multimegabit Data Service (SMDS), Frame Relay,
Integrated Services Data Networks (ISDN), Asynchronous Transfer Mode
(ATM), and Gigabit networks. Routing protocols will need to evolve to
meet the routing requirements of these new environments.
In addition to new types of network topology being introduced, there
are trends to provide different classes of networks. These include
Commercial, Public, Private, Government, and University Research
networks. Routing will need to perform to provide routes for and
control access to these classes of networks in line with the users
requirements.
IESG [Page 61]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
10.2.3 Provide for Multivendor Interoperation
Routing protocols need to be able to be implemented and run in systems
made up of an arbitrary collection of vendors equipment.
To meet these goals the following five year routing protocol evolution
plan is proposed:
1-2 Years Modern IGP's (IS-IS, OSPF) deployed widely, EGP Replaced
by BGP
3 Years Routing Protocols available for New Environments (SMDS,
FR, ISDN, ...)
Support for Commercial / Public / Private Classes of
Networks
5 Years Transition to New Addressing and Routing Model
10.3 Specific Actions Required
The issues in the routing area as to what work should be done in the
next five years fall into the short term and the long term issues.
Generally, the short term issues deal with modernization of the
current protocols to provide better routing service today and provide
for internet growth in the next few years. The long term issues cover
how far the internet can grow and the type of routing that will be
supported.
10.3.1 Standardize on one Interior Routing Protocol
The first issue is to pick a standard Interior Routing Protocol for
the Internet. The two serious contenders are the OSPF and the Dual
IS-IS protocols. This is important because the most common protocol
in use (RIP) works poorly and the vendor proprietary protocols do not
allow multiple vendor routers in a single AD. Both of the contenders
promise improved operation and multi-vendor operation. This issue has
been active for about a year, and needs to be resolved quickly.
10.3.2 Define Requirements to Advance Internet Routing Protocols to
Draft Standard and Full Standard|
An issue that relates to picking a standard inter-AD routing protocol
is the need for a standard procedure to evaluate the operational
IESG [Page 62]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
experience of a new routing protocol. Routing protocols are complex,
distributed, real-time algorithms. They are difficult to implement
and to test. Even though a protocol may work in one environment with
one implementation, that does not ensure that it will work in a
different environment with multiple vendors. A routing protocol may
work well with a range of number of networks and routers , but fail
when an unforeseen limit is reached. The result is the even with
considerable operational experience, it is hard to guarantee that the
protocol is mature enough for widespread deployment. A procedure
needs to be developed to evaluate the operational experience that a
routing protocol has before making it a Draft Standard.
10.3.3 Deploy BGP to Replace EGP
The current Intra-AD protocol, EGP, is in need of replacement. With
the size of the current Internet, it provides at best marginal
service. The BGP is being developed to replace it. BGP needs to
advanced in the standardization process and then be deployed.
10.4 Develop Routing Protocols for Large Data Networks
The last short term issue is routing on large data networks. The
current routing protocols (Inter-AD and Intra-AD) do not work well on
large networks where they may be hundreds to many thousands of
routers. All of the protocols require full information exchanges.
The inter-AD protocols require order N**2 routing exchanges where N is
the number of routers. This will consume excessive resources in the
network and the routers. There is a need for a new protocol(s) to
provide for routing on this type of networks.
10.4.1 Authentication of Internet Routing
Currently none of the current routing protocols have viable
authentication mechanisms. In theory, it is possible that internet
routing could be attacked (accidently or maliciously) and the routing
in a AD or perhaps across large portions of the Internet could be
adversely affected. Also, as commercial pay for service routes are
added to the internet it will become even more important that there be
a high assurance that routers are who they say they are. As a result,
it is important the general authentication mechanisms be added to the
routing protocols.
IESG [Page 63]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
10.4.2 Routing and Addressing Architecture
The most important long term driver in Internet Routing is growth in
size and diversity. A number of factors are at play. The Internet is
growing in size at an exponential rate. There are signs that there
will be many a variety of public, commercial, and governmental
backbones networks built which will have different policies/terms for
the traffic that they carry. While it is impossible to predict the
details of the future, it is clear that in the long term the Internet
will be much larger and much more complex than today's Internet.
As a result of increased size and diversity, Internet Routing and
Internet Addressing will have to evolve to meet these expanding
requirements. There are currently a number of efforts underway that
are working to addressing some or all of these issues. These include:
o The Open Routing work, IDPR, which concentrates on a link state
system to do policy routing in an AS topology, led by Martha
Steenstrup of BBN;
o A combination of the above and BGP which has desirable 'common
case optimization' characteristics, put forward by Deborah Estrin
at USC;
o A proposed new combined routing and addressing architecture, put
forward by Noel Chiappa.
o An address mapping scheme proposed by Van Jacobsen of LBL and
being worked on by Paul Tsuchiya of Bellcore.
There is currently no plan to determine how these efforts relate to
each other and which are the most promising to pursue.
The following two actions are proposed in this area:
The IDPR protocol appears to be a promising solution to handling
Internet growth in size and diversity. It is using a number of
techniques which are gaining some consensus as appropriate solutions
to growth issues. It's development should be completed and it should
be deployed to allow operational experience to be gained in order to
understand how will it can help meet internet growth.
A new effort be started to develop an overall Routing architecture
which can meet the long term requirements of Internet routing. The
result of this effort should be a framework where specific protocols
and mechanisms can be developed. It will develop a timetable for
routing protocol evolution as well as a plan for migration of the
Internet to new protocols. Due to the overall success of the
Internet, the problems associated with migration may be the hardest to
solve and have the most effect on the solutions chosen.
IESG [Page 64]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
11 Security Area Plan
11.1 Objectives and Overview
Security has become a major concern within the Internet. Users, site
administrators, network administrators and vendors are all increasing
their attention to security matters. Security services are being
added to existing protocols, and new protocols specific to security
are being defined. In addition, more attention is being given to
security in the implementation and operation of sites and networks.
11.2 Objectives
The overall objective of the security area is to develop a combination
of protocols, polices and practices that provide:
o protection of the network infrastructure against unauthorized
tampering,
o protection to network users against compromise of confidentiality
and integrity, and
o support for protecting network services against unauthorized use.
These objectives are general in nature. There are numerous aspects of
each, some of which are spelled out below. This plan does not attempt
to provide all possible forms of protection. For example, an obvious
aspect of confidentiality is protection of the contents of electornic
mail messages from disclosure to unaddressed parties. A more subtle
aspect of confidentiality is protection of the knowledge of which
people are communicating with each; this is often called traffic
security. This plan does include a path for attaining confidentiality
of electronic mail messages, but does not contain a plan for attaining
traffic flow confidentiality.
11.2.1 Arenas of activity
Although the main work in the IETF is the development of protocols,
the work in the security area encompasses other activities as well.
Security area work takes place in four arenas, protocols, policies,
assessment and process.
o Protocols
What changes need to be made to existing protocols? What new
protocols should be defined and designed?
o Policies
IESG [Page 65]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
What policies need to be developed or promulgated? Who needs to
be involved in the policy efforts?
o Assessment
What are the actual security issues in the Internet today and in
the future? How effective are the security controls and
practices? What changes in protocol designs, protocol
implementations or system administration are needed to improve
security in the Internet?
o Standards and Development
What changes, if any, are needed or are desirable in the
development process? What changes are needed, if any, in the
standards process?
o Organization
How is the work in the security area to be organized? How will
it be coordinated with other groups, e.g. the PSRG.
Because security has become a major focus of attention, a large number
of people are involved. Not all of these have the same perception of
what security servides are needed or desired, and not all of them have
the same priorities. This diversity is healthy, but it increases the
need for an explicit statement of each party's goals and for
coordination among the different parties. This document is a
statement of the objectives and plans for the IETF security area. As
with any plan, the actual details will tend to vary over time.
11.3 Specific Work)
11.3.1 Protocols
The first part of this list is the set of active protocol activities.
The second part is the set of protocols or protocol groups which do
not have security revisions or extensions in progress, but which have
been discussed as needing such changes in the future.
SNMP Authentication
An encapsulation layer for SNMP is being defined. It provides
authentication and privacy services for remotely managed agents.
The work is being done by Davin, Galvin and McCloghrie in the IP
Authentication Working Group. Four documents exist and have been
reviewed extensively. The PSRG has taken exception to some of the
details, and these are being negotiated now. It is hoped that this
protocol will advance to Proposed Standard at the IETF meeting in
Boulder, though its progress is uncertain at the moment.
This work is taking place within the Authentication Working Group. In
principle, this group is working on both IP authentication and SNMP
IESG [Page 66]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
authentication, but only the SNMP authentication work is progressing.
This group should be renamed, rechartered and a new chair named.
Schedule: Forward to IAB with recommendaiton to advance to Proposed
Std at or immediately after Boulder IETF meeting.
Privacy Enhanced Mail
Specifications for privacy enhanced mail have been developed by the
PSRG. These provide for sender authentication, message integrity and
optional confidentiality. A combination of DES, RSA and either MD2 or
MD4 algorithms are used. User identities are matched to public RSA
keys using certificates. Certificates are signed by issuing
authorities, and a hierarchy of issuing authorities must come into
existence.
The oroginal specs for PEM are published as RFCs 1113, 1114 and 1115
and are marked Draft Std. In principle, these should be considered to
be Proposed Stds under the current guidelines. Revisions of these
three documents and a new document will be forthcoming later this
year.
PEM will cause a major change in the Internet, and a number of
logistic and policy issues need to be addressed.
The schedule for initial deployment of PEM on the Internet now looks
like April 1991. There is a PERT chart showing the activities of
RSADSI, BBN and TIS, but, as Fermat said, the margins are too small to
contain it here. Part of the schedule involves the reissue of RFCs
1113, 1114, and 1115, and the issuance of a new RFC. These contain the
revisions. Not all of the changes are widely accepted, and we will
need to figure out the procedures for reviewing and approving
specifications arising from a closed group like the PSRG.
IP security options (DoD and commercial)
There are two main versions of the IP security option, a DoD version
and a commercial version. The DoD version is currently documented in
RFC 1108, and is being reviewed and revised. It contains a basic
security option and an extended security option. The latter is only
partly specified because some aspects are classified. Work on this
protocol has been dormant for more than a year, but work on it has
been restarted, principally under Vint's direction.
Some sort of working group or the equivalent needs to be created to
follow through with this effort. At the moment, the ad hoc group
consists of Steve Kent, Jon Postel, Hans-Werner Braun, and Steve
Crocker.
Schedule: Revised RFC by 12/31/90. Some questions as to when and how
it enters the standards track. The default assumption is it becomes a
IESG [Page 67]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Proposed Std then.
The commercial IP security option is being developed by the Trusted
Systems Interoperability Group (TSIG). I believe they've agreed to act
as an IETF WG and go through the process of preparing their specs for
review and publicaiton via the IETF/IAB standards track. There is
some confusion at the moment as to how this work relates to the DoD IP
security option, and this will be sorted out.
I'd guess this group will be ready to present its work for IETF review
at either the St. Louis or the Atlanta IETF meeting.
Security services in Telnet, etc.
The Telnet folks have asked for help in designing an authentication
and an encryption option for Telnet. This is more complicated than it
first seems, and no real progress has been made.
Jeff Schiller is now assigned as the SAAG representative on this WG.
(I have not yet communicated this fact to Borman.)
Security services at the IP layer
This area has been dormant. I am folding down the working group. We
will revisit this topic when it's clear what needs to be done. There
is substantial resistance from various quarters because there is
similar work in the SDNS arena.
Routing protocols
In principle, the routing protocols should be augmented to be
protected against maliciously supplied routing updates that are
intended to undermine the integrity of the network. Similar
requirements are appearing in more than one protocol, e.g. OSPF and
BGP. No explicit work on this subject has been organized, but it's a
topic that will be put before the SAAG to see if we can find someone
with the relevant expertise to work with the routing protocol folks.
Login security
Poor password selection and configuration errors have been identified
as the primary vulnerabilities among network hosts. DARPA has
requested that we look into this situation and recommend improvements.
A related but somewhat different matter is transmission of passwords
in the clear over the network. It's possible to improve the security
of password transmission by using either one time passwords or
encrypted authentication exchanges.
Ken Van Wyck has been leading an effort on one time passwords, and I'm
exploring turning his activity into an IETF WG. I also asked Jeff
Schiller to take the SAAG role of forming the necessary working
IESG [Page 68]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
group(s) and/or working with existing groups.
MD4
A distinguished panel is needed to review MD4. Steve Kent and I are
cooperating on trying to set up the panel. We have had trouble
finding a chair, and we are attempting to populate the panel and
deferring the question of a chair until later. If need be, Steve K or
I will chair the panel.
11.3.2 Policies
Internet security policy
The draft Internet security policy now exists. I expect substantial
comment, discussion and interpretaton during the next IETF meeting,
and then we'll assess where we stand on it. This exercise opens up
new territory because it's not a protocol. I recommend we bring up in
the IESG and IAB what is intended for this work.
One key question to resolve is whether to quit with the publication of
this document or whether to press on and develop interpretations and
implementation guidelines for networks, vendors, etc.
Security impact statements
We have begun asking for security impact statements in all RFCs. This
is a useful process, but the groundrules are not yet clear to
everyone. This is a matter to be taken up in the SAAG and developed
further.
Database accuracy and privacy
There is an opportunity to set forth a policy on accuracy and privacy
of databases containing information on persons and organizations,
particularly NICs and other directory services. I do not think there
is widespread agreement that this is an area that requires attention,
so we need to discuss the issues before plunging forward. It is an
area I feel is important, so I'm inclined to press the matter.
Export of security related implementations
Export restrictions currently prevent the general shipment outside the
U.S. of software or hardware which contains DES or RSA based
encryption technology. This is awkward. It's not clear what, if
anything, can be done about it. We can try to pyut together an
interest group and cooperate with other efforts to get clarification
and relaxation of the restrictions, but I'm not convinced this will be
effective.
IESG [Page 69]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Assessment
How effective are the security measures now in place? What problems
actually exist? These questions are important if we want to formulate
the right plans. I have begun to explore this question. No specific
plans are visible at this time.
11.3.3 Standards and Development
Security impact statements
As noted above, we are beginning to require these in RFCs. The
process is not spelled out completely yet.
Security review of RFCs
My intent is that every RFC will be reviewed. This will become a SAAG
responsibility.
Improvement in development, testing and documentation
I would like to seem some move toward the use of reasonable formal
specifications, tools, etc. This is somewhat of a swamp draining
exercise, inhibited by the presence of a very large and viable
alligator population.
11.4 Organization
11.4.1 SAAG
Current members include:
John Linn, DEC
Dave Balenson, TIS
Jim Galvin, TIS
Jeff Schiller, MIT
Paul Holbrook, CERT
Rich Pethia, CERT
Joel Jacobs, MITRE
11.4.2 PSRG
Strong attempts to coordinate our related activities. Some
differences in tradition, point of view and style, but I believe there
IESG [Page 70]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
is a shared commitment to work together.
IESG [Page 71]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
12 Transport and Services Area
12.1 Description
The topics covered in the Transport and Services Area can be divided
into there sections. The first section is that part of the protocol
stack above the network layer, and below the application layer. This
includes the various existing and proposed transport protocols, such
as TCP, UDP, VMTP and NETBLT.
The second section involves low level protocols, protocols that
logically sit above one of the transport protocols, but are not tied
to a specific application. A simple view would be that if a protocol
would typically have more than one application protocol built on top
of it, then it belongs in this area. Some of the topics that this
would cover are remote procedure calls, and data representation, or
presentation services.
The third section involves the grey area between transport and
applications. These are the applications that the user normally does
not directly interact with, and that are not covered in other Areas.
For example, routing protocols could fit this description, but they
are covered in a seperate Area devoted specifically to routing.
applications, but the user does not normally see or use the
applications directly. Currently, this section involves topics such
as distributed file systems, and the Domain Name System.
12.2 Technical goals
Currently the Internet is growing in size and speed, gigabit cross
country links will soon be a reality. New applications are being
developed, some with characteristics and network demands quite
different from the current established set of applications.
The main technical goal of the Transport and Services Area is to make
sure that the current transport protocols can support new
applications, and continue to support the existing applications as the
Internet continues to expand.
12.3 Current and future actions
The main Internet transport protocol, TCP, has not changed much in the
recent past. Currently, RFC 1072 proposes three new TCP options for
dealing with high-speed, long delay networks. These changes will
allow TCP well into the gigabit rates.
There are several things that will probably be needed within the next
five years, but are currently still research topics. Rate based
protocols will probably be needed to support things such as real-time
IESG [Page 72]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
video. Many UDP based applications implement a protocol on top of UDP
to make it reliable; a reliable datagram protocol would be useful for
these applications.
The area of multicast transport protocols is one that is very
interesting, but still very much in the domain of the research
community. The general question of whether or not multicast is a good
idea has not yet been answered; but assuming that it is decided as a
good thing, there will need to be transport protocols to make
effecient and easy use of this mechanism.
IESG [Page 73]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
13 User Services
13.1 Area Overview
As the Internet has rapidly developed to encompass a large number of
internationally dispersed networks in academic and research fields,
many new users of different backgrounds are added to the community.
This growth has placed the user services provider in the difficult
position of trying to provide much needed user support, while at the
same time restructuring the user services' system to accommodate
continued expansion. Recent changes include the establishment of a
User Services Area within the Internet Engineering Task Force (IETF).
This area provides an international forum for people interested in all
levels of user services, to identify and initiate projects designed to
improve the quality of the information available to users of the
Internet.
The IETF does not view itself as making standards for user services.
Instead, it provides a forum where the user services community can
meet, both to discuss internal coordination problems and to share its
views with and explain its needs to the technical community. In
addition, the IETF encourages collaboration among the various
organizations that also have an interest in user services. When the
Internet Engineering Steering Group (IESG) was first established, it
did not immediately create a distinct User Services Area. As of 1991,
this area has grown to take its place with other IESG areas as the
importance of a user services forum has increased globally.
The actual projects of the User Services Area are handled by the
creation of IETF Working Groups. Included in these groups are user
services that are addressed in other areas of the IESG. For example,
the Security Area and the User Services Area combined their efforts to
create a Site Security Policy Handbook Working Group. Overlapping of
efforts within the IESG are not uncommon, and actually increase the
quality of end-products produced by the IETF. Other organizations such
as SIGUCCs, CERFnet, RIPE, RARE, etc., regularly attend the IETFs and
contribute to the user services efforts.
A User Services Area Council (USAC) has been established to promote
and encourage creative exchange of international user service needs
and concepts. Constructive input from various national and
international user services organizations for the purpose of not
duplicating each organization's efforts is also encouraged. USAC will
be responsible for researching and defining short term and long term
user services needs and coordinating developments in finding
solutions.
The primary responsibilities of USAC members are to actively provide
input for the current and future developments of user services
concerns. This forum will conduct meetings in conjunction with the
IETF plenaries. Additional communication will take place via
IESG [Page 74]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
electronic mail. The User Services Area Director of the IESG chairs
the USAC.
13.2 Goals
A survey was conducted throughout the Internet from 17 October 1990 -
18 January 1991. IETF User Services members, technical and commercial
users, user services national organizations, and NICs and NOCs were
polled on what goals and objectives the Internet community should be
aiming for. An international survey will be conducted in the near
future via USAC. From this survey, seven types of user services
objectives and goals emerged. Additional types will be added as
warranted:
o User Information
o Network Information Services Infrastructure
o Network Operational Management
o Education
o Documentation and Distribution
o Interaction with IESG Areas
o Interaction with other international user services entities.
13.2.1 User Information
The Internet community requires up-to-date, basic Internet knowledge
and experience. These can be achieved by publication of handbooks,
bibliographies, directories, and glossaries. Yet, how does the IETF
``get the word out'' beyond the normal distribution and announcement
via the RFC series?? Identification and research on various existing
distribution resources, and consideration of possible long term
distribution methods are required.
A continuing goal of the User Services Area is to create and develop
helpful, high quality, and up-to-date information easily available to
Internet users of all levels. Researching pertinent user information
for the Internet community involves many processes:
o Addressing user information that needs to be provided.
o Define target audiences (What level of audience?? New user,
intermediate, or advanced??)
o Identify and categorize current useful documents to avoid
duplications and redundancies.
o Creation and publication of documents, and distribution.
o Development and implementation of procedures to maintain and
update the materials.
o Identify organization or individuals who will accept the
IESG [Page 75]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
responsibility for maintenance.
o Identification of future projects via the USAC.
Publicizing the Internet requires an activity to make sure users know
that the Internet is available for their use. There are a
considerable number of sites which are connected to the Internet which
have many users still unaware of the resource that is available to
them. The Internet must also focus on helping commercial
organizations make their users aware of what Internet offers, and make
Internet users aware of the valuable commercial services which are
available to them. The User Services Area has specific objectives
targeted for development and implementation (see specific work
section).
13.2.2 Network Information Services Infrastructure
A global infrastructure for common, shared Internet-wide network
information services is needed. Research and development for what is
required to implement an information services ``infrastructure'' for
the Internet community is in progress in the User Services Area.
Documentation needs to be developed that suggests methods to improve
the interaction and cooperation among NICs. This includes Internet
Administrator's guides, file retrieval programs, user liaison guides,
and white and yellow pages services. We intend to coordinate closely
with other efforts in the international networking community via the
USAC.
13.2.3 Network Operational Management
This topic overlaps with other areas such as network management,
operations, and applications. Yet, development of general information
to users is essential. For example, there is a critical need for the
development, implementation, and standardization of applications for
the user services community. Many Internet applications still have
user unfriendly interfaces. There needs to be a ``user'' perspective
developed and added to interfaces.
The User Services Area intends to contribute by providing
documentation. This documentation should be developed in tandem with
technical specifications as the demand for general information
regarding ``user-friendly'' descriptions on Internet protocols
increase. This may be in the form of catalogs, checklists, site
policy handbooks, and network services information documentation for
all levels on how to utilize the Internet.
IESG [Page 76]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
13.2.4 Education
The educating of new network users is mandatory. The future goal of
User Services is to provide organized Internet tutorials, ``hands on''
training programs, active participation in the K-12 education
initiative, and Internet specific documentation.
13.2.5 Documentation and Distribution
One continuing goal of the User Services Area is to coordinate the
development of user information services by clearly and concisely
providing documentation information and distribution for the Internet
community. FYI RFCs are introductory and overview documents for
network users. Their purpose is to make available general
information, rather than the protocol specifications or standards that
is typical of other RFCs. FYIs are allied to the RFC series of notes,
but provides information about who does what on the Internet. The FYI
RFC series has proved a success since its initiation, and its goal is
to continue to do so.
13.2.6 Interaction with IESG Areas
The interaction with other areas so not to have duplications or
redundancies is imperative to the global success of the Internet
community. The IESG teams up together for the same purpose, as
overlaps do exists. Proposed combined goals include:
Applications
Documentation of ``user-friendly'' information about how and why the
technical specification is supposed to work.
Internet Services
Host Requirements/Required Site Policies
Operations
Internet Installation Checklist Internet Statistics
OSI Integration
Facilitate the deployment in the Internet of Directory Services based
on implementations of the X.500 standards by producing FYI RFCs
intended to serve as a Directory Services ``Administrator's Guide''.
IESG [Page 77]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Security
Site Security Policy Handbook
13.2.7 Interaction with other User Services Organizations
Interaction with other national and international user services
entities has begun in 1991 with the creation of USAC. Currently,
USAC's membership includes representation nationally by BBN/NNSC,
Merit, CERFnet, SIGUCCS, FARNET, and CICNet. International membership
representation includes Europe, Japan, Australia, Canada, and Israel.
USAC's goals will be ongoing as the Internet evolves globally.
13.3 Goals
The User Services Area encompasses numerous projects. We have divided
these projects into 5 sections: User Information, Network Information
Services Infrastructure, Network Operational Management, Education,
Documentation and Distribution
13.3.1 User Information
Internet Q&A
``If I see that SAME question about how to obtain RFCs via anonymous
FTP on the TCP-IP mailing list ONE MORE TIME, I'm going to start
screaming!!!'' Users joining the Internet community for the first
time have had the same questions as did everyone else who has ever
joined. The Internet community requires up-to-date, basic Internet
knowledge and experience, while moving redundancies away from
electronic mailing lists such as TCP-IP, Header-People, etc., so that
the lists' subscribers do not have to read the same queries and
answers over and over again. To eleviate these redundancies, two
Questions and Answers FYI RFCs (QUAIL) are produced and updated on a
regular basis by the User Services Working Group. One targets the
``New Internet User'' and the other targets the ``Intermediate
Internet User''.
Common User Interfaces and User Perspectives
Graphics interfaces are now common, yet many Internet applications
still have user unfriendly interfaces. There needs to be a ``user''
perspective developed and added to interfaces. The User Services Area
should work with the other IESG areas to make this happen.
Copyright & Intellectual Property
IESG [Page 78]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Development of documentation on copyright policies for electronic
information transferral is a topic being discussed within the Internet
community and the User Services Area. One thought is to have some way
to have electronic libraries installed where the authors could be
compensated for their work. This would be considered a long-range
project for the IETF.
Distribution & Announcement of IETF products
The immediate role of the IETF in broadly distributing information to
the international Internet community is to make use of communication
avenues already developed by other organizations. How does IESG Area
Directors and IETF WG Chairs ``get the word out'' beyond the normal
distribution and announcement via RFC series?? Identification and
research on various existing distribution resources, and consideration
of possible long term distribution methods are required. The User
Services Working Group is examining distribution resources for an IETF
internal publication, ``Distribution and Announcement Handbook'', to
get information out by using existing methods and begin to address
long term global distribution methods.
Historical Documentation
Historical documentation that the ``old boys'' may write.
Interface with Commercial Networks
The Internet is increasingly being linked up to commercial services.
If both the Internet and commercial services are to get the most out
of this connectivity, we need focus on helping commercial
organizations make their users aware of what Internet offers, and make
Internet users aware of the valuable commercial services which are
available to them. This is an activity where the combined efforts of
the IESG should be utilized.
Network Service Guide
A ``Network Service Guide'' for the Internet community was proposed by
an IETF member. This would entail research, development, and creation
of a template setting the criteria for the selection of a network to
connect to (e.g., membership and its cost, services provided,
acceptable use, etc.) is a start. There is a continuing need for
more types of these kinds of documents. The User Services Working
Group is chartered to develop documents such as this.
``Public Relations'' for the Internet
Publicity for the Internet requires an activity to make sure users
know that the Internet is available for their use. There are a
considerable number of sites which are connected to the Internet which
have many users still unaware of the resource that is available to
IESG [Page 79]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
them. Articles in journals, magazines, and newsletters, posters,
direct mailings, etc., can help make sure that potential users become
actual users. With the expansion of the Internet internationally,
much of the future potential Internet user community will not be from
the U.S. scientific community. As such, new users may not be reached
unless assertive public relations efforts are made to contact them.
This is an area in which the IETF can contribute, by coordinating
publicity activities among various networks, NICs, or NOCs, and by
organizing groups of people to speak at various conferences or write
for publications. User Services is interested in this endeavor, and
we expect this activity to be one of the priorities for our area.
For example, we will be conducting a ``User Services'' session at
Interop '91. The session will describe our Internet user services
community. Specifically, we will present a 1-2 hour session that
describes the IETF user services group, including three or four ``user
services'' representatives (e.g., the BBN/NNSC, Merit, etc.). Each
representative will speak for approximately 20 minutes or so on what
our organizations/sites provide to the Internet population.
User Bibliography
A basic Internet bibliography containing general networking terms and
pointers on how and where to obtain these sources requires a document
that provides to the new Internet user a place to start. The User
Documents Working Group has produced a FYI RFC, ``Where to Start - A
Bibliography of Internetworking Information''. The User Services
Working Group is responsible for maintaining procedures for the
periodic review of this work and updating of this document.
User Directory
There is a critical need for a directory that can provide help to
users who want to find out who else is on the network. Once the
appropriate technology for supporting a user directory is found and
standardized, it will still take a multi-year effort to get all users
appropriately registered in the directory system. Based on experience
converting to the Domain Name System, registration will be an
intensive effort, requiring extensive technical support and work to
encourage sites get their data on-line. This is an activity in which
the IETF has the potential to be the forerunner, via regular progress
reporting on the users in the directory and finding ways to gently
nudge sites to enter and maintain user information.
The BBN/NNSC recently published an ``Internet Manager's Phonebook'',
at the request of the IETF. It attempts to list everyone who is
responsible for a domain name or IP network number as of 1 August
1990. This phonebook could be taken as a model for a User Directory.
User Glossary
IESG [Page 80]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
There are many on-line and hardcopy computer glossaries in existence,
but not one of them is an Internet specific glossary. A glossary of
this type needs to be a publication of Internet terms and acronyms.
The User Glossary Working Group is in process of this task. Upon
publication of a glossary, the User Services Working Group will be
responsible for maintaining procedures for periodic review of this
work and updating of this document.
13.3.2 Network Information Services Infrastructure
Interaction & Cooperation among NICs
Documentation needs to be developed that suggests methods to improve
the network information infrastructure which consists of Internet NICs
on all levels. The NISI Working Group of the User Services Area is
chartered to research and develop this documentation.
Internet Administrator's Guide
Documentation is needed that would provide Internet administrators
with guidance. This would be a separate endeavor from the Internet
Installation Checklist. This topic was briefly discussed at the IETF
in Vancouver. USAC should pursue this subject.
Network Services
Collecting, editing, and publishing information about available
network services and presenting the information in a form which is
useful to the Internet community is an on-going dilemma. Many
Internet members are suffering from information overload. Their
``real work'' does not allow them to spend hours each week going
through mail or making numerous phone calls to locate new services or
data. The user services community has made exceptional progress in
this area over the past few years, but it is still true that alot of
information is not available to users. The IETF has a good track
record of assisting people engaged to this sort of work and expects to
continue to do so. (The IETF has encouraged its members to help these
projects and an inspection of the acknowledgement sections of several
of the recent networking books show we've had success). However,
these editing and collection activities are extremely labor intensive
and expensive, and while users will certainly be willing to pay for
the packaged information produced, they probably cannot be expected to
cover all costs.
New Applications to make NICs Work More Efficiently.
SIGUCCS has a concept about a NETHELP command, which when entered into
any system, would would search a distributed database which contains
information on HELP desks, or who to go to from help about networking.
IESG [Page 81]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
SIGUCCS is looking into further development of this idea. USAC should
work in tandem with SIGUCCS to achieve this concept.
User Liaison Guide
CERFnet is developing a guide that they intend to provide to their
customer sites which would assist them with educating their user
community and their job in general. While strong technical support
systems exist, what about a similar system for the user liaison group?
This would be different from a user's guide, as it is specifically for
those who run the NICs and interface with end users. A template for
this kind of guide could be developed for the Internet community via
NISI.
White Pages Services
There are a number of White Pages directories on the Internet;
however, all of them are far from complete. The two largest
directories available are the WHOIS database at the DDN NIC and the
PSInet White Pages. Generally, it is still necessary to ask the
person for his or her electronic mail address. A task for the User
Services Area is to develop a comprehensive White Pages Service for
the Internet.
X.400, X.500 Services
The question of what will be offered through X.500 services and how
they are to be offered and to whom has significant implications for
the NICs. The Directory Information Services (pilot) Infrastructure
Working Group is chartered to facilitate the deployment in the
Internet of Directory Services based on implementations of the X.500
standards.
Yellow Pages Services
There is a need to develop a Yellow Pages Service. This would include
information about what services are currently available on the
Internet and who the points of contact are for them. System
administration staff have users who want to know, ``Now that we are on
the Internet, what's out there??'' The User Services Area has this on
their priority list.
13.3.3 Network Operational Management
Applications
There is a need for general information regarding ``user-friendly''
descriptions on DNS, DFS, mail, etc., and explanations on how they
work. This type of documentation should be developed in tandem with
IESG [Page 82]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
technical specifications. The User Services Working Group has this on
its priority list. It is also timely to add documentation on how
applications are supposed to work. For example, protocol comparisons
like, ``TCP or UDP: What's Your Application?''
Catalogs
Providing current and practical information to site administrators and
network managers of the Internet requires the development of a catalog
containing descriptions of several tools available to assist network
managers in debugging and maintaining TCP/IP internets and
interconnected communications resources. A NOCTools Working Group was
established to develop a catalog, ``A Network Management Tool Catalog:
Tools for Monitoring and Debugging TCP/IP Internets and Interconnected
Devices''. Entries in the catalog include: what a tool does, how it
works, and how it can be obtained. The NOC-Tool Catalogue Revisions
Working Group is responsible for maintaining procedures for periodic
review of this work and updating of this document.
There are also numerous information servers on the Internet. It would
be an asset to have a comprehensive catalogue of servers for the
Internet community.
Ethics and Etiquette
There is a substantial amount of work going on in all user services
organizations on this topic, yet the thoughts are not to develop an
``official usage'' statement, but rather a template of issues which a
new site (or old) could use as guide for creation of their own site
specific rules. The User Services Area could collaborate with other
outside organizations on this subject. This effort can be coordinated
through the USAC.
``How to Utilize the Internet''
There's been quite a bit of clamoring from the User Services trenches
regarding network services information documentation for all levels on
``How to Use the Internet''. Many users don't know how to obtain
information about network contacts via, for example, the WHOIS
database or electronic mail to: info-nis@site.edu. An application
needs to be developed where a user could send electronic mail to a
netnews group requesting ``How do I obtain contact information about
net xxx.yyy? A representative document on how to utilize the Internet
also needs to evolve from this effort. This is a long overdue task
for the IETF.
Internet Installation Checklist
A qualitative checklist for the Internet Community is long overdue.
It should require a new user to have only a minimum knowledge of the
subject at hand. This should include identification and sources of
IESG [Page 83]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
Internet registrations, routing in the Internet, other parallel
networks, additional Internet services, and worksheets. This
checklist should also be comprehensive enough so that it may also be
used as an important reference tool for those intermediate and
advanced users desiring to expand their knowledge of currently
available Internet sources, points of contact, and documentation. The
User Services Working Group is in process of writing documentation for
this purpose.
Internet Introduction Packages
There is a need for ''Intro Packages`` for all levels of new Internet
users. Such as, ''How to join the Internet``, or documentation
describing existing (implemented) network services (i.e., a new
Internet user thinks, ''I just connected to the Internet, what
services does it offer me??.`` A compiled list of all network services
available is required. Specifically, NTP, FINGER, WHOIS, domain name
service, SMTP, file transfer capability, network terminal,
TCP/UDP/ICMP Echo services, etc. For example, using the list of
assigned TCP and UDP ports can quickly reference these services. A
notation can be cited, stating if each service is in widely
distributed use. This information may be easily obtained based on the
IAB's ''Official Protocol Standards`` publication on the state of
standardization of protocols used in the Internet (e.g., recommended
standard, historical, etc.). This could also bring out those services
which aren't as widely discussed as electronic mail, TELNET and FTP.
The User Services Working Group has this topic on its priority list.
Site Policy Handbooks
Internet specific handbooks should act as a guide to setting computer
policies and procedures for sites that have systems on the Internet.
They should list issues and factors that a site must consider when
setting their own policies, and suggest recommendations and give
discussions of relevant areas. In this context, a handbook should
provide only a framework for setting site policies and procedures. In
order to have an effective set of policies and procedures, a site will
have to make many decisions, gain agreement, and then communicate and
implement the policies.
13.3.4 Education
Education of Special User Groups
The Internet community has been encouraging new groups of users to
consider using the Internet. Examples of such users are supercomputer
users, ecologists and astronomers. As we invite these user groups to
participate in the Internet, we also need to make sure user services
is prepared to assist them. Specifically, new users with specialized
IESG [Page 84]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
interests need to be able to obtain information on what the Internet
can offer them. For example, supercomputer centers must show their
users how to best utilize the network to perform supercomputing;
mechanisms for informing scientists about where to find special data
repositories and archives need to be established. So far, the user
services community has dealt with this problem reasonably well, but
this task is a continuing need, as new users appear in the Internet
community.
IETF Tutorials
There has been an increase in new participants at the IETF plenaries,
and they are detracting from the other activities. There is a need to
conduct IETF ''intro`` sessions (e.g., how to mail to the world,
etc.). Introductory sessions like these can be coordinated by the
User Services area, in partnership with other IESG areas. The IETF
will be experimenting with this concept.
K-12 Education Initiative
The National Science Foundation has identified K-12 networking as an
important mission and is preparing solicitation in this area. Merit
is currently researching initiatives in their state. They have
discovered that people working in the K-12 educational system perceive
many obstacles to using computer technology (e.g., financial and
equipment limitations, and a sense that network use will not be
supported within school systems).
The IETF should look into the K-12 Education Initiative and provide
assistance in identifying existing applications in the Internet that
may be targeted for K-12, research and develop new applications, and
establish a consistent way to access those applications. Providing
significant user support for using the applications should also be
targeted, as well as assisting in the establishment of a reliable and
easy-to-use network service for school systems globally.
``Standard Curriculum'' Training Programs and Improving Training
Material for Local Instructors
Not all users are able to go to commercial tutorials on how to use the
Internet, due to exorbitant costs. Yet, the educating of new network
users is mandatory. Hence, teaching will need to be conducted at
local sites. It can be ascertained that the teachers of new users
have attended courses and have have become ``certified'' to teach
students on how to use the network, but there is a need to pay
attention to the quality of training materials and supplies these
teachers will have in hand and use when they go back to their sites.
This goes beyond the ``Conventional'' hardcopy textbook sources.
Instructional videos illustrating how to use the network, ``hands-on''
demo programs, such as a program that acclimates new users through
IESG [Page 85]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
sending their first e-mail message, and quality course notes from
which local courses could be taught is needed. Clear, concise, and
up-to-date documentation has been produced by the User Services Area
via the FYI RFC series of notes, and has been applauded in the user
services community, but there is an acute need for more materials to
be developed.
TCP/IP Tutorials
New members to the Internet community experience some frustration on
the lack of one Internet specific tutorial. There are MANY tutorials
in existence, but a representative Internet TCP/IP Tutorial needs to
evolve, perhaps entitled, ``A Tutorial on the TCP/IP Protocol Suite''.
13.3.5 Documentation and Distribution
One of the tasks of the User Services Area is to coordinate the
development of user information services by clearly and concisely
providing documentation information and distribution for the Internet
community. The FYI RFC series provides information about who does
what on the Internet.
Current list of publications related to user services:
``FYI on Questions and Answers - Answers to Commonly asked
`Experienced Internet User' Questions'', FYI 7, RFC 1207, March 1991.
``FYI on Questions and Answers - Answers to Commonly asked `New
Internet User' Questions'', FYI 4, RFC 1206, March 1991.
``FYI on the X Window System'', FYI 6, RFC 1198, January 1991.
``FYI on Where to Start - A Bibliography of Internetworking
Information'', FYI 3, RFC 1175, August 1990.
``FYI on a Network Management Tool Catalog: Tools for Monitoring and
Debugging TCP/IP Internets and Interconnected Devices'', FYI 2, RFC
1147, April 1990.
Soon to be published:
``Internet Site Security Policy Handbook''.
``Internet User Glossary''.
``FYI on a Network Management Tool Catalog: Tools for Monitoring and
Debugging TCP/IP Internets and Interconnected Devices, Revised''.
``FYI on Directory Services Administrator's Guide''.
IESG [Page 86]
INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991
``FYI on Where to Start - A Bibliography of Internetworking
Information, Revised''.
IESG [Page 87]