draft-iab-principles-02.txt   rfc1958.txt 
IAB B. Carpenter
Internet Draft (editor)
April 1996
Architectural Principles of the Internet
Abstract
draft-iab-principles-02.txt Network Working Group B. Carpenter, Editor
Request for Comments: 1958 IAB
The Internet and its architecture have grown in evolutionary fashion from Category: Informational June 1996
modest beginnings, rather than from a Grand Plan. While this process of
evolution is one of the main reasons for the technology's success, it
nevertheless seems useful to record a snapshot of the current
principles of the Internet architecture. This is intended for general
guidance and general interest, and is in no way intended to be a
formal or invariant reference model.
Discussion of this draft should take place on the ietf@ietf.org list Architectural Principles of the Internet
Status of this Memo Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working This memo provides information for the Internet community. This memo
documents of the Internet Engineering Task Force (IETF), its areas, does not specify an Internet standard of any kind. Distribution of
and its working groups. Note that other groups may also distribute this memo is unlimited.
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Abstract
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the The Internet and its architecture have grown in evolutionary fashion
``1id-abstracts.txt'' listing contained in the Internet- Drafts from modest beginnings, rather than from a Grand Plan. While this
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net process of evolution is one of the main reasons for the technology's
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific success, it nevertheless seems useful to record a snapshot of the
Rim). current principles of the Internet architecture. This is intended for
general guidance and general interest, and is in no way intended to
be a formal or invariant reference model.
Table of Contents: Table of Contents
Status of this Memo.............................................1 1. Constant Change..............................................1
1. Constant Change..............................................2
2. Is there an Internet Architecture?...........................2 2. Is there an Internet Architecture?...........................2
3. General Design Issues........................................5 3. General Design Issues........................................4
4. Name and address issues......................................6 4. Name and address issues......................................5
5. External Issues..............................................6 5. External Issues..............................................6
6. Related to Confidentiality and Authentication................7 6. Related to Confidentiality and Authentication................6
Acknowledgements................................................7 Acknowledgements................................................7
References......................................................8 References......................................................7
Security Considerations.........................................8
Editor's Address................................................8 Editor's Address................................................8
1. Constant Change 1. Constant Change
In searching for Internet architectural principles, we must remember In searching for Internet architectural principles, we must remember
that technical change is continuous in the information technology that technical change is continuous in the information technology
industry. The Internet reflects this. Over the 25 years since the industry. The Internet reflects this. Over the 25 years since the
ARPANET started, various measures of the size of the Internet have ARPANET started, various measures of the size of the Internet have
increased by factors between 1000 (backbone speed) and 1000000 increased by factors between 1000 (backbone speed) and 1000000
(number of hosts). In this environment, some architectural principles (number of hosts). In this environment, some architectural principles
skipping to change at page 3, line 34 skipping to change at page 3, line 26
Internet to be the easy way to interconect fundamentally different Internet to be the easy way to interconect fundamentally different
transmission media, and to offer a single platform for a wide variety transmission media, and to offer a single platform for a wide variety
of Information Infrastructure applications and services. There is a of Information Infrastructure applications and services. There is a
good exposition of this model, and other important fundemental good exposition of this model, and other important fundemental
issues, in [Clark]. issues, in [Clark].
2.3 It is also generally felt that end-to-end functions can best be 2.3 It is also generally felt that end-to-end functions can best be
realised by end-to-end protocols. realised by end-to-end protocols.
The end-to-end argument is discussed in depth in [Saltzer]. The The end-to-end argument is discussed in depth in [Saltzer]. The
basic argument is that, as a first principle, certain required end- basic argument is that, as a first principle, certain required end-
to-end functions can only be performed correctly by the end-systems to-end functions can only be performed correctly by the end-systems
themselves. A specific case is that any network, however carefully themselves. A specific case is that any network, however carefully
designed, will be subject to failures of transmission at some designed, will be subject to failures of transmission at some
statistically determined rate. The best way to cope with this is to statistically determined rate. The best way to cope with this is to
accept it, and give responsibility for the integrity of communication accept it, and give responsibility for the integrity of communication
to the end systems. Another specific case is end-to-end security. to the end systems. Another specific case is end-to-end security.
To quote from [Saltzer], "The function in question can completely and To quote from [Saltzer], "The function in question can completely and
correctly be implemented only with the knowledge and help of the correctly be implemented only with the knowledge and help of the
application standing at the endpoints of the communication system. application standing at the endpoints of the communication system.
Therefore, providing that questioned function as a feature of the Therefore, providing that questioned function as a feature of the
communication system itself is not possible. (Sometimes an incomplete communication system itself is not possible. (Sometimes an incomplete
version of the function provided by the communication system may be version of the function provided by the communication system may be
useful as a performance enhancement.)" useful as a performance enhancement.")
This principle has important consequences if we require applications This principle has important consequences if we require applications
to survive partial network failures. An end-to-end protocol design to survive partial network failures. An end-to-end protocol design
should not rely on the maintenance of state (i.e. information about should not rely on the maintenance of state (i.e. information about
the state of the end-to-end communication) inside the network. Such the state of the end-to-end communication) inside the network. Such
state should be maintained only in the endpoints, in such a way that state should be maintained only in the endpoints, in such a way that
the state can only be destroyed when the endpoint itself breaks the state can only be destroyed when the endpoint itself breaks
(known as fate-sharing). An immediate consequence of this is that (known as fate-sharing). An immediate consequence of this is that
datagrams are better than classical virtual circuits. The network's datagrams are better than classical virtual circuits. The network's
job is to route datagrams as efficiently and flexibly as possible. job is to transmit datagrams as efficiently and flexibly as possible.
Everything else should be done at the fringes. Everything else should be done at the fringes.
To perform its services, the network maintains some state To perform its services, the network maintains some state
information: routes, QoS guarantees that it makes, session information: routes, QoS guarantees that it makes, session
information where that is used in header compression, compression information where that is used in header compression, compression
histories for data compression, and the like. This state must be histories for data compression, and the like. This state must be
self-healing; adaptive procedures or protocols must exist to derive self-healing; adaptive procedures or protocols must exist to derive
and maintain that state, and change it when the topology or activity and maintain that state, and change it when the topology or activity
of the network changes. The volume of this state must be minimized, of the network changes. The volume of this state must be minimized,
skipping to change at page 5, line 51 skipping to change at page 5, line 23
Implementations must follow specifications precisely when sending to Implementations must follow specifications precisely when sending to
the network, and tolerate faulty input from the network. When in the network, and tolerate faulty input from the network. When in
doubt, discard faulty input silently, without returning an error doubt, discard faulty input silently, without returning an error
message unless this is required by the specification. message unless this is required by the specification.
3.10 Be parsimonious with unsolicited packets, especially multicasts 3.10 Be parsimonious with unsolicited packets, especially multicasts
and broadcasts. and broadcasts.
3.11 Circular dependencies must be avoided. 3.11 Circular dependencies must be avoided.
For example, routing must not depend on look-ups in the For example, routing must not depend on look-ups in the Domain
Domain Name System (DNS), since the updating of DNS servers Name System (DNS), since the updating of DNS servers depends on
depends on successful routing. successful routing.
3.12 Objects should be self decribing (include type and size), within 3.12 Objects should be self decribing (include type and size), within
reasonable limits. Only type codes and other magic numbers assigned reasonable limits. Only type codes and other magic numbers assigned
by the Internet Assigned Numbers Authority (IANA) may be used. by the Internet Assigned Numbers Authority (IANA) may be used.
3.13 All specifications should use the same terminology and notation, 3.13 All specifications should use the same terminology and notation,
and the same bit- and byte-order convention. and the same bit- and byte-order convention.
3.14 And perhaps most important: Nothing gets standardised until 3.14 And perhaps most important: Nothing gets standardised until
there are multiple instances of running code. there are multiple instances of running code.
skipping to change at page 8, line 12 skipping to change at page 7, line 30
Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, Neal Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, Neal
McBurnett, Masataka Ohta, Jeff Schiller and Lansing Sloan. McBurnett, Masataka Ohta, Jeff Schiller and Lansing Sloan.
References References
Note that the references have been deliberately limited to two Note that the references have been deliberately limited to two
fundamental papers on the Internet architecture. fundamental papers on the Internet architecture.
[Clark] The Design Philosophy of the DARPA Internet Protocols, [Clark] The Design Philosophy of the DARPA Internet Protocols,
D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988,
pages 106-114 (reprinted in ACM CCR Vol 25, 1995, pages 102-111). pages 106-114 (reprinted in ACM CCR Vol 25, Number 1, January 1995,
pages 102-111).
[Saltzer] End-To-End Arguments in System Design, J.H. Saltzer, [Saltzer] End-To-End Arguments in System Design, J.H. Saltzer,
D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp
277-288. 277-288.
Security Considerations
Security issues are discussed throughout this memo.
Editor's Address Editor's Address
Brian E. Carpenter Brian E. Carpenter
Group Leader, Communications Systems Phone: +41 22 767-4967 Group Leader, Communications Systems
Computing and Networks Division Fax: +41 22 767-7155 Computing and Networks Division
CERN CERN
European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch European Laboratory for Particle Physics
1211 Geneva 23, Switzerland 1211 Geneva 23, Switzerland
Phone: +41 22 767-4967
Fax: +41 22 767-7155
EMail: brian@dxcoms.cern.ch
 End of changes. 19 change blocks. 
45 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/