2. What is the case—a fact—is the existence of states of affairs.
3. A logical picture of facts is a thought.
4. A thought is a proposition with a sense.
5. A proposition is a truth-function of elementary propositions.
6. The general form of a truth function is (ρ, ξ Ν(ξ)). This is the general form of a proposition.
And so on, concluding with perhaps the most revolutionary and devastating statement ever made in philosophy, mathematics, or science:
7. That of which we cannot speak we must pass over in silence.
In one straightforward sentence, the Tractatus destroyed any hopes of put-ting what was then called moral philosophy (ethics, morals, and religion) on any kind of formal base. Because the terms could not be precisely defined and the value judgments were always cultural or relative, nothing could be said.
Proper civilized behavior could not be argued from first principles, as many from Plato to Kant had tried to do. The Tractatus was immediately embraced by mathematics and science as holding out a Holy Grail that all of science and mathematics could be described by a precise logical system as complete as Euclid’s Geometry, Newton’s Principia, or Maxwell’s Treatise. Attempts were made to create logical models of various branches of science, and when comput-ers came along, the Tractatus was used as not only the basis for logic and pro-gramming languages, but also as the basis for artificial intelligence and database systems. The database field coined the phrase conceptual schema to describe the collection of logical statements that would define a domain, an enterprise. Later, artificial intelligence called the same concept a knowledge base and developed expert systems. Both of these are implementations of what Wittgenstein meant when he wrote 1.1. In both, “the world is all that is the case,” and the world is represented by a collection of logical propositions.
The same approach was applied to distributed systems. For two parties to communicate, they must have a shared conceptual schema; they must have a common language or protocol and some common understanding about what strings in the language stand for. Without this, communication is impossible, whether between machines or between people. The important things to a proto-col are the things it understands. This approach provided a very nice model for communications, even in the more mundane error-control protocols. The shared conceptual schema of protocol state machines was the information exchanged about flow control, acknowledgments, addresses, and so on. The
BEGINNING AT THEBEGINNING 5
user’s data was outside their shared conceptual schema and was ignored (or passed to another protocol machine). Data is this incomprehensible stuff that shows up every so often and is ignored and passed on.
But beyond this, the usefulness of this approach finds its limits, although we will have use for it when we come to applications. Like any good engineer (and He had studied earlier as an aeronautical engineer), Wittgenstein, had taken the easy way out and provided an existence proof but did not tell us how to con-struct these logical worlds (or to know when we had all the necessary facts).
Although there is much to be gained by understanding the Tractatus, we are pri-marily interested in what it teaches us about reducing problems to their bare bones to see what is really going on (but also to take a lesson from the penulti-mate statement of the Tractatus):
6.54 My propositions serve as elucidations in the following way: anyone who understands me eventually recognizes them as nonsensical, when he has used them—as steps—to climb up beyond them. (He must, so to speak, throw away the ladder after he has climbed up it.)
At several points in what follows, we will find it necessary to throw away the ladder. Concepts and constructs that have helped us to get where we are will be discarded so that we may get beyond them. It is not so much that these concepts are wrong (after all, we might never have reached our new insights without them) but more that they have done their job and now it is time to move beyond them. At these points, the reader may have to work a little harder to reinterpret familiar concepts from a new perspective. I try to warn the reader when this is necessary.
Let us start by first considering two meta-level topics that will be important to us as we proceed:
1. The abstract method by which we will proceed (the “nature of the algebra,” if you will)
2. The role of formal methods in network architectures But we will always want to keep in mind some sage advice:
In the practical arts, the theoretical leaves and blossoms must not be allowed to grow too high, but must be kept close to experience, their proper soil.
—Clausewitz
CHAPTER1 FOUNDATIONS FORNETWORKARCHITECTURE 6
If we have a correct theory but merely prate about it, pigeonhole it and do not put it into practice, then that theory, however good, is of no
significance. Knowledge begins with practice, and theoretical knowledge is acquired through practice and must return to practice.
—Mao Zhe Dong
I have referred to these quotes as a philosophical triangulation. When two important voices of the right and the left say the same thing, it is probably right.
In the course of this journey, we will have reason to delve into what might seem like some fairly esoteric topics for the practical task of engineering networks.
The insights here have been gained from practice. These forays into theory will allow us to do the algebra, simplify the arithmetic, and thereby simplify the practice. The first of these uses of theory is applying levels of abstraction to the problem.
Levels of Abstraction
Levels of abstraction represent an important tool for managing the complexity of a system or architecture. There is a common misconception that top-down design starts at the user interface and goes down to the hardware. This is not the case. This confuses the levels of abstraction in the design process with the layers of the system being designed.
Top-down design starts at a high level of abstraction, which is refined through successive levels, each level less abstract than the one above, to the implementation. Even though the implementation may itself create objects, which hide complexity and therefore are considered more abstract (and possibly layered), from the design perspective the entire implementation is all at the same level of abstraction.
This is important because it allows the designer to ensure that the use of
“first-order effectors” across all layers of the system being designed is consis-tent, before moving the design to a lower level of abstraction and lesser-order effects. Two orthogonal forms of abstraction have been found useful in architec-tures: levels of design and specification, and the layering of the architecture.
Because there will be much more to say about layering in Chapter 6, “Divining Layers,”our discussion here is brief.
The concept of layering evolved in the late 1960s and early 1970s in the design of operating systems and software in general. Layering is an expansion of
LEVELS OFABSTRACTION 7
the “black box” concept developed by Norbert Weiner. A user of a black box can only observe what the box does (that is, the service it provides), not how it does it; the mechanisms that implement its external behavior are hidden. In fact, there may be many mechanisms to generate the same external behavior. In soft-ware, layering was used to build up layers of abstraction so that the specifics of the hardware (processor and peripherals) could be masked from the applica-tions and to allow more efficient resource management by the operating system and provide a portable, more user-friendly environment for programming.3
For operating systems, layering tends to represent a collection of black boxes that take a class of different mechanisms (for example, device drivers) at one level of abstraction and present an interface with a higher level of abstraction (for example, device independent) to the layer above. Each layer added a level of functionality that created a greater abstraction with the hardware as the bottom layer and the user as the top layer. Similarly in networks, layering provided abstraction from the specifics of a network hardware technology.4For example, the network layer creates an abstract service that is independent of the underly-ing media. This was seen as very similar to what operatunderly-ing systems did to make all terminals and storage devices look the same to programs.
Although the use of layers has evolved in operating systems from Dijkstra’s THE, and even as innovative developments in operating systems continue, the layering of microkernel, kernel, user is fairly well accepted. Why are layers in networks still controversial? To a large extent, it is due to the effects of the war alluded to earlier. By the time the industry settled on designs based on Multics/UNIX or DEC’s VMS and a few others for specialized environments, there had probably been 20 to 30 major operating systems (probably more) of radically different architectures developed and thoroughly tested over a period of about 10 years. In contrast, for networks, we settled on the current approach after considering just three or four networks over three or four years. We simply did not explore the problem space as much. It is a much greater effort to create a new kind of network than a new kind of operating system. Further, the effect of the “war” tended to push thinking into one camp or another.
Recently in networking, there has been a flight from layers by some, although it is unclear to what (a response to the perception that the traditional layered approach was interfering with solving the problems). But we must be careful. As CHAPTER1 FOUNDATIONS FORNETWORKARCHITECTURE
8
3 The concepts for creating portable operating systems and other software applications derive from the same source: The system is layered with a canonical interface at one of the middle layers and the hardware specific layers below that.
4 The seven-layer OSI model was the creation of Charles Bachman based on his experience at Honeywell with database systems and with Multics.
noted earlier, communications requires a set of objects with a shared conceptual schema. Given that we may want to hide some of the complexity of that shared schema, so that we can build other objects with different shared schemas that use it, would seem to indicate that these collections of objects with the common shared schemas have a structure something like a “layer.” The concept of layer seems inherent in the problem. The question is what constitutes the “right”
schema for these “layers.”
For design and specification of network architecture, four levels of abstrac-tion have proved useful: the model, the service, the protocol and interface, and the implementation. We start with a model or architecture, and each lower level of specification refines the abstraction of the level above to add more detail.
This step-wise refinement is a method of exposition and specification, not nec-essarily one of design. While the design process makes use of these levels of abstraction, the process must move up and down successively approximating the final solution. However, this approach does allow components of lower lev-els of abstraction to be modified with no effect on higher-level components and little or no effect on components at the same level of abstraction. A good archi-tecture will both specify constraints and allow sufficient flexibility for a wide range of implementations.
The aphorisms at the beginning of this chapter attempt to characterize what constitutes a good architecture.5The more formal definition I have used is close to the common dictionary definition of architecture:
A set of rules and constraints that characterize a particular style of construction
Like the weather, it is not possible to have no architecture (although some have tried hard not to); at worst, one has the Karnack or accidental architec-ture—that is, given the system, what is the architecture?6 One must distinguish, for example, between Victorian architecture and a Victorian building built to that architecture: type versus instance. Most activity in the field of architecture consists of creating buildings to an existing architecture (that is, creating instances of a class). In this case, we are developing a new architecture. Not a radically new architecture, but one definitely based on our experience and using many components of previous architectures. However, it is our belief that this
LEVELS OFABSTRACTION 9
5 This word is much abused in our field. I have seen papers where “architecture” was used as synonymous with hardware.
6 For those too young to remember, this is an allusion to a recurring skit on U.S. television by Johnny Carson on The Tonight Show, where The Great Karnak divines the answer to ques-tions before they are posed to him.
new architecture avoids many of the ornate and cumbersome constructions required in the past and will generate much simpler, more powerful constructs and few special cases. Many capabilities that have required explicit functionality will be found to be degenerate cases in this model. Many capabilities that were difficult to accommodate are included easily. And most important, it is a model that inherently scales. At the same time, however, we are also trying to identify architectural principles that are invariant with respect to media and implementa-tion. (And where we do make choices, I make them as explicit as possible.)
Model
The definition of the model of a layer, service, protocol, or distributed applica-tion is one of the more important aspects in the process of design and specifica-tion. The model, in essence, defines the shared conceptual schema of the communication. It defines the objects in the universe of discourse, their attrib-utes, the operations that can be performed on them, how they relate to each other, the communication of information among them, and so on.
Models exist for all protocols, but they are most important for distributed application protocols. Because the models for the lower-layer protocols are con-cerned with ensuring the integrity and resource management of the communica-tion, they are essentially similar, self-contained, and require little or no interaction with the entities outside the protocol itself. Here the model is prima-rily of use as an explanatory tool to facilitate the description of the protocol’s behavior. Application protocols differ qualitatively from the lower-layer proto-cols. Application protocols are concerned with modifying state on objects exter-nal to the protocol itself, while data transfer protocols modify state interexter-nal to the protocol. For example, a file transfer protocol modifies the state of the oper-ating system’s file system (external), where TCP modifies its state vector internal to the protocol. Unfortunately, there are a wide variety of file systems with widely varying properties. Although the corresponding systems may have differ-ent models, the application layer protocol must establish a common model for the communicating systems. In effect, the model describes the semantics of the distributed application. In recent years, this degree of rigor has been replaced by the implementation.
There will be much more to say about this when we discuss upper-layer architecture. Keep in mind that specifications are required for four levels of abstraction: the model, which we are primarily concerned here; the service and the protocol, as described in the following sections; and the implementation, which at least in source code is still an abstraction. Most of what is discussed in this book is at the model or architecture level. Our focus will be on the models CHAPTER1 FOUNDATIONS FORNETWORKARCHITECTURE
10
for protocols and layers and how they all fit together to create a working system. We try to identify the properties that allow them to fit together well and, in some cases, directions that lead to a less-than-good fit. We also consider specific protocols and architectures to illustrate various points.
Service
Using techniques to hide mechanism has always been important to the design and implementation of complex systems. Hiding mechanisms has been used through-out computer science: the concept of procedure in most programming languages, layers of an operating system, the object-oriented model, and so on. All of these techniques use the concept of hiding mechanisms behind an abstract view to man-age complexity. This has the effect that the interactions with the object are simpli-fied and allow the mechanisms by which the object provides its function to be modified without affecting the user. This greatly enhances its utility.
In communications, we embodied this idea of hiding mech-anisms in the construct of layering. The concept of layer was essentially the concept of a process or object recast in what was thought to be a less-rich environment with only a few types of “objects” and very limited forms of interactions among them. The layer boundaries hid the mechanisms of a layer from the layer above and below. The crucial difference from operating systems was that a layer was a “distributed black box” whose internal mechanisms were coordinated by the exchange of information, forming a loosely coupled shared state.
The concept of service is one of the more important con-cepts in the development of communication architectures.
The definition of service as used here is an abstraction of the interface between layers that is system independent.
Service is a level of abstraction higher than protocol and interface and a level of abstraction lower than the architecture or model. It is from this abstraction that the importance of the concept is derived. On one hand, the concept of service allows one to hide the mechanisms of a protocol from its user, thereby simplifying the user’s interactions with the protocol.
At the same time, it allows the behavior of one protocol to be decoupled from another, thereby allowing the protocol some flexibility in responding to its users by not tying its behavior
LEVELS OFABSTRACTION 11
Words Mean What We Want Them To
TheInternational Telecommuni-cation Union (ITU) and others with a telephony background use the concept of service and interface as a boundary between systems or boxes.
Therefore, when most ITU docu-ments use the terms service or interface, they are really talking about properties of a protocol;
for instance, X.25 is an interface specification between a Data Terminal Equipment (DTE) and aData Communication Equip-ment (DCE). This is how some were deluded into believing that they could automatically gener-ate a protocol from an abstract service definition, such as X.407. It is, in fact, easy to gen-erate a protocol from a protocol specification. However, it is only possible to generate a protocol from a service specification for a very small tightly constrained class of protocols and impossi-ble for the vast majority.
too tightly to its interactions with its users. Providing this decoupling at critical junctures is crucial to the successful design of complex systems such as these.
too tightly to its interactions with its users. Providing this decoupling at critical junctures is crucial to the successful design of complex systems such as these.