The Design Philosophy of the DARPA Internet …

1 ACM SIGCOMM-1-Computer Communication ReviewThe Design Philosophy of the DARPA Internet ProtocolsDavid D. Clark*Massachusetts Institute of TechnologyLaboratory for Computer ScienceCambridge, MA. 02139(Originally published in Proc. SIGCOMM 88, Computer Communication Review Vol. 18, No. 4,August 1988, pp. 106 114) *This work was supported in part by the Defense Advanced Research Projects Agency ( DARPA ) under Contract No. N00014-83-K-0125 AbstractThe Internet protocol suite, TCP/IP, was first proposedfifteen years ago. It was developed by the DefenseAdvanced Research Projects Agency ( DARPA ), andhas been used widely in military and commercialsystems. While there have been papers andspecifications that describe how the protocols work, it issometimes difficult to deduce from these why theprotocol is as it is.

2 For example, the Internet protocol isbased on a connectionless or datagram mode of motivation for this has been greatly paper attempts to capture some of the earlyreasoning which shaped the Internet IntroductionFor the last 15 years1 , the Advanced Research ProjectsAgency of the Department of Defense has beendeveloping a suite of protocols for packet switchednetworking. These protocols, which include the InternetProtocol (IP), and the Transmission Control Protocol(TCP), are now Department of Defense standardsfor internetworking, and are in wide use in thecommercial networking environment. The ideasdeveloped in this effort have also influenced otherprotocol suites, most importantly the connectionlessconfiguration of the ISO protocols2,3, specific information on the DOD protocols isfairly generally available5,6,7, it is sometimes difficult todetermine the motivation and reasoning which led to fact, the Design Philosophy has evolved considerablyfrom the first proposal to the current standards.

3 Forexample, the idea of the datagram, or connectionlessservice, does not receive particular emphasis in the firstpaper, but has come to be the defining characteristic ofthe protocol. Another example is the layering of thearchitecture into the IP and TCP layers. This seemsbasic to the Design , but was also not a part of theoriginal proposal. These changes in the Internet designarose through the repeated pattern of implementationand testing that occurred before the standards were Internet architecture is still evolving. Sometimes anew extension challenges one of the Design principles,but in any case an understanding of the history of thedesign provides a necessary context for current designextensions. The connectionless configuration of ISOprotocols has also been colored by the history of theInternet suite, so an understanding of the Internet designphilosophy may be helpful to those working with paper catalogs one view of the original objectivesof the Internet architecture, and discusses the relationbetween these goals and the important features of Fundamental GoalThe top level goal for the DARPA Internet Architecturewas to develop an effective technique for multiplexedutilization of existing interconnected networks.

4 Someelaboration is appropriate to make clear the meaning ofthat goal. The components of the Internet were networks, whichwere to be interconnected to provide some largerservice. The original goal was to connect together theoriginal ARPANET8 with the ARPA packet radionetwork9,10, in order to give users on the packet radionetwork access to the large service machines on theARPANET. At the time it was assumed that there wouldbe other sorts of networks to interconnect, although thelocal area network had not yet alternative to interconnecting existing networkswould have been to Design a unified system whichincorporated a variety of different transmission media, aACM SIGCOMM-2-Computer Communication Reviewmulti-media network.

5 While this might have permitted ahigher degree of integration, and thus betterperformance, it was felt that it was necessary toincorporate the then existing network architectures ifInternet was to be useful in a practical sense. Further,networks represent administrative boundaries ofcontrol, and it was an ambition of this project to cometo grips with the problem of integrating a number ofseparately administrated entities into a common technique selected for multiplexing was packetswitching. An alternative such as circuit switching couldhave been considered, but the applications beingsupported, such as remote login, were naturally servedby the packet switching paradigm, and the networkswhich were to be integrated together in this project werepacket switching networks.

6 So packet switching wasaccepted as a fundamental component of the final aspect of this fundamental goal was theassumption of the particular technique for inter-connecting these networks. Since the technique of storeand forward packet switching, as demonstrated in theprevious DARPA project, the ARPANET, was wellunderstood, the top level assumption was that networkswould be interconnected by a layer of Internet packetswitches, which were called these assumptions comes the fundamentalstructure of the Internet : a packet switched communica-tions facility in which a number of distinguishablenetworks are connected together using packet communi-cations processors called gateways which implement astore and forward packet forwarding Second Level GoalsThe top level goal stated in the previous sectioncontains the word "effective," without offering anydefinition of what an effective interconnection mustachieve.

7 The following list summarizes a more detailedset of goals which were established for the Internet communication must continue despite lossof networks or The Internet must support multiple types ofcommunications The Internet architecture must accommodate avariety of The Internet architecture must permit distributedmanagement of its The Internet architecture must be cost The Internet architecture must permit hostattachment with a low level of The resources used in the Internet architecture mustbe set of goals might seem to be nothing more than achecklist of all the desirable network features. It isimportant to understand that these goals are in order ofimportance, and an entirely different networkarchitecture would result if the order were changed.

8 Forexample, since this network was designed to operate ina military context, which implied the possibility of ahostile environment, survivability was put as a firstgoal, and accountability as a last goal. During wartime,one is less concerned with detailed accounting ofresources used than with mustering whatever resourcesare available and rapidly deploying them in anoperational manner. While the architects of the Internetwere mindful of accountability, the problem receivedvery little attention during the early stages of the Design ,and is only now being considered. An architectureprimarily for commercial deployment would clearlyplace these goals at the opposite end of the , the goal that the architecture be cost effectiveis clearly on the list, but below certain other goals, suchas distributed management, or support of a wide varietyof networks.

9 Other protocol suites, including some ofthe more popular commercial architectures, have beenoptimized to a particular kind of network, for example along haul store and forward network built of mediumspeed telephone lines, and deliver a very cost effectivesolution in this context, in exchange for dealingsomewhat poorly with other kinds of nets, such as localarea reader should consider carefully the above list ofgoals, and recognize that this is not a "motherhood" list,but a set of priorities which strongly colored the designdecisions within the Internet architecture. The followingsections discuss the relationship between this list andthe features of the Survivability in the Face of FailureThe most important goal on the list is that the Internetshould continue to supply communications service, eventhough networks and gateways are failing.

10 In particular,this goal was interpreted to mean that if two entities arecommunicating over the Internet , and some failurecauses the Internet to be temporarily disrupted andreconfigured to reconstitute the service, then the entitiescommunicating should be able to continue withouthaving to reestablish or reset the high level state of theirconversation. More concretely, at the service interfaceof the transport layer, this architecture provides noACM SIGCOMM-3-Computer Communication Reviewfacility to communicate to the client of the transportservice that the synchronization between the sender andthe receiver may have been lost. It was an assumption inthis architecture that synchronization would never belost unless there was no physical path over which anysort of communication could be achieved.