Computer Network Architecture

 k

To help deal with complexity, network designers have developed general blueprints—usually called a network architecture—that guide the design and implementation of networks. Here we introducing the central ideas that are common to all network architectures. It also introduces two of the most widely referenced architectures— the OSI architecture and the Internet architecture.

Layering and Protocols
When the system gets complex, the system designer introduces another level of abstraction.

The idea of an abstraction is to define a unifying model that can capture some important aspect of the system, encapsulate this model in an object that provides an interface that can be manipulated by other components of the system, and hide the details of how the object is implemented from the users of the object. 

The challenge is:

1. to identify abstractions that simultaneously provide a service that proves useful in a large number of situations and 
2. that can be efficiently implemented in the underlying system.

This is exactly what we were doing when we introduced the idea of a channel.

We were providing an abstraction for applications that hides the complexity of the network from application writers.

Abstractions naturally lead to layering, especially in network systems.

The general idea is that you start with the services offered by the underlying hardware, and then add a sequence of layers, each providing a higher (more abstract) level of service.

The services provided at the high layers are implemented in terms of the services provided by the low layers. 

Drawing on the discussion of requirements given in a previous post, for example, we might imagine a network as having two layers of abstraction sandwiched between the application program and the underlying hardware, as illustrated in Figure 1.8.

1. The layer immediately above the hardware in this case might provide host-to-host connectivity, abstracting away the fact that there may be an arbitrarily complex network topology between any two hosts. 
2. The next layer up builds on the available host-to-host communication service and provides support for process-to-process channels, abstracting away the fact that the network occasionally loses messages, for example.

Layering provides two nice features:

1. First, it decomposes the problem of building a network into more manageable components. 
1. Rather than implementing a monolithic piece of software that does everything you will ever want, you can implement several layers, each of which solves one part of the problem. 
2. Second, it provides a more modular design. 
1. If you decide that you want to add some new service, you may only need to modify the functionality at one layer, reusing the functions provided at all the other layers.

Thinking of a system as a linear sequence of layers is an oversimplification, however.

Many times there are multiple abstractions provided at any given level of the system, each providing a different service to the higher layers but building on the same low-level abstractions. 

To see this, consider the two types of channels:

1. One provides a request/reply service, and one 
2. supports a message stream service.

These two channels might be alternative offerings at some level of a multilevel networking system, as illustrated in Figure 1.9. Using this discussion of layering as a foundation, we are now ready to discuss the architecture of a network more precisely.

For starters, the abstract objects that make up the layers of a network system are called protocols.

That is, a protocol provides a communication service that higher-level objects (such as application processes, or perhaps higher-level protocols) use to exchange messages. 

For example, we could imagine a network that supports a request/reply protocol and a message stream protocol, corresponding to the request/reply and message stream channels discussed above.

Each protocol defines two different interfaces.

1. First, it defines a service interface to the other objects on the same computer that want to use its communication services. 
1. This service interface defines the operations that local objects can perform on the protocol. For example, a request/reply protocol would support operations by which an application can send and receive messages. 
2. Second, a protocol defines a peer interface to its counterpart (peer) on another machine. 
1. This second interface defines the form and meaning of messages exchanged between protocol peers to implement the communication service. This would determine the way in which a request/reply protocol on one machine communicates with its peer on another machine.

In other words, a protocol defines a communication service that it exports locally, along with a set of rules governing the messages that the protocol exchanges with its peer(s) to implement this service. This situation is illustrated in Figure 1.10.

Except at the hardware level where peers directly communicate with each other over a link, peer-to-peer communication is indirect—each protocol communicates with its peer by passing messages to some lower-level protocol, which in turn delivers the message to its peer.

In addition, there are potentially multiple protocols at any given level, each providing a different communication service. 

We therefore represent the suite of protocols (that make up a network system) with a protocol graph. The nodes of the graph correspond to protocols, and the edges represent a depends-on relation.

For example, Figure 1.11 illustrates a protocol graph for the hypothetical layered system we have been discussing—protocols RRP (Request/Reply Protocol) and MSP (Message Stream Protocol) implement two different types of process-to-process channels, and both depend on HHP (Host-to-Host Protocol), which provides a host-to-host connectivity service.

In this example, suppose that

1. the file access program on host 1 wants to send a message to its peer on host 2 using the communication service offered by protocol RRP. 
2. In this case, the file application asks RRP to send the message on its behalf.
3. To communicate with its peer, RRP then invokes the services of HHP,
4. which in turn transmits the message to its peer on the other machine. 
5. Once the message has arrived at protocol HHP on host 2, HHP passes the message up to RRP, which in turn delivers the message to the file application.

In this particular case, the application is said to employ the services of the protocol stack RRP/HHP.

Note that the term protocol is used in two different ways. Sometimes it refers to the abstract interfaces—that is, the operations defined by the service interface and the form and meaning of messages exchanged between peers—and sometimes it refers to the module that actually implements these two interfaces.

To distinguish between the interfaces and the module that implements these interfaces, we generally refer to the former as a protocol specification. Specifications are generally expressed using a combination of prose, pseudocode, state transition diagrams, pictures of packet formats, and other abstract notations.

It should be the case that a given protocol can be implemented in different ways by different programmers, as long as each adheres to the specification.

The challenge is ensuring that two different implementations of the same specification can successfully exchange messages. Two or more protocol modules that do accurately implement a protocol specification are said to interoperate with each other.

We can imagine many different protocols and protocol graphs that satisfy the
communication requirements of a collection of applications. Fortunately, there exist standardization bodies, such as the International Standards Organization (ISO) and the Internet Engineering Task Force (IETF), that establish policies for a particular protocol graph.

We call the set of rules governing the form and content of a protocol graph a network architecture.

Standardization bodies such as the ISO and the IETF have established well-defined procedures for introducing, validating, and finally approving protocols in their respective architectures. We briefly describe the architectures defined by the ISO and the IETF shortly, but first there are two additional things we need to explain about the mechanics of a protocol graph.

Encapsulation
Consider what happens in Figure 1.11 when

1. one of the application programs sends a message to its peer by passing the message to protocol RRP. 
2. From RRP’s perspective, the message it is given by the application is an uninterpreted string of bytes. RRP does not care that these bytes represent an array of integers, an email message, a digital image, or whatever; it is simply charged with sending them to its peer. However, RRP must communicate control information to its peer, instructing it how to handle the message when it is received. RRP does this by attaching a header to the message.
3. Generally speaking, a header is a small data structure—from a few bytes to a few dozen bytes—that is used among peers to communicate with each other. As the name suggests, headers are usually attached to the front of a message. In some cases, however, this peer-to-peer control information is sent at the end of the message, in which case it is called a trailer. The exact format for the header attached by RRP is defined by its protocol specification. 
4. The rest of the message—that is, the data being transmitted on behalf of the application—is called the message’s body or payload. We say that the application’s data is encapsulated in the new message created by protocol RRP.

This process of encapsulation is then repeated at each level of the protocol graph;
for example, HHP encapsulates RRP’s message by attaching a header of its own.

If we now assume that HHP sends the message to its peer over some network, then when the message arrives at the destination host, it is processed in the opposite order:

1. HHP first strips its header off the front of the message, interprets it (i.e., takes whatever action is appropriate given the contents of the header), and 
2. passes the body of the message up to RRP, which removes the header that its peer attached, takes whatever action is indicated by that header, and 
3. passes the body of the message up to the application program.

The message passed up from RRP to the application on host 2 is exactly the same message as the application passed down to RRP on host 1;

the application does not see any of the headers that have been attached to it to implement the  lower-level communication services. 

This whole process is illustrated in Figure 1.12. Note that in this example, nodes in the network (e.g., switches and routers) may inspect the HHP header at the front of the message.

Note that when we say a low-level protocol does not interpret the message it is given by some high-level protocol, we mean that it does not know how to extract any meaning from the data contained in the message. 

It is sometimes the case, however, that the low-level protocol applies some simple transformation to the data it is given, such as to compress or encrypt it. In this case, the protocol is transforming the entire body of the message, including both the original application’s data and all the headers attached to that data by higher-level protocols.

Multiplexing and Demultiplexing
Recall that a fundamental idea of packet switching is to multiplex multiple flows of data over a single physical link. This same idea applies up and down the protocol graph, not just to switching nodes. In Figure 1.11, for example, we can think of RRP as implementing a logical communication channel, with messages from two different applications multiplexed over this channel at the source host and then demultiplexed back to the appropriate application at the destination host.

Practically speaking, all this means is that the header that RRP attaches to its messages contains an identifier that records the application to which the message belongs. We call this identifier RRP’s demultiplexing key, or demux key for short.
At the source host, RRP includes the appropriate demux key in its header. When the message is delivered to RRP on the destination host, it strips its header, examines the demux key, and demultiplexes the message to the correct application.

RRP is not unique in its support for multiplexing; nearly every protocol implements this mechanism. For example, HHP has its own demux key to determine which messages to pass up to RRP and which to pass up to MSP. However, there is no uniform agreement among protocols—even those within a single network architecture—on exactly what constitutes a demux key. Some protocols use an 8-bit field (meaning they can support only 256 high-level protocols), and others use 16- or 32-bit fields. Also, some protocols have a single demultiplexing field in their header, while others have a pair of demultiplexing fields. In the former case, the same demux key is used on both sides of the communication, while in the latter case, each side uses a different key to identify the high-level protocol (or application program) to which the message is to be delivered.

OSI Architecture
The ISO was one of the first organizations to formally define a common way to connect computers. Their architecture, called the Open Systems Interconnection (OSI) architecture and illustrated in Figure 1.13, defines a partitioning of network functionality into seven layers, where one or more protocols implement the functionality assigned to a given layer. 

In this sense, the schematic given in Figure 1.13 is not a protocol graph, per se, but rather a reference model for a protocol graph. 

The ISO, usually in conjunction with a second standards organization known as the International Telecommunications Union (ITU), --A subcommittee of the ITU on telecommunications (ITU-T) replaces an earlier subcommittee of the ITU, which was known by its French name, Comité Consultatif International Téléphonique et Télégraphique (CCITT).-- publishes a series of protocol specifications based on the OSI architecture. This series is sometimes called the “X dot” series since the protocols are given names like X.25, X.400, X.500, and so on. There have been several networks based on these standards, including the public X.25 network and private networks like Tymnet.

1. Starting at the bottom and working up, the physical layer handles the transmission of raw bits over a communications link. 
1. The data link layer then collects a stream of bits into a larger aggregate called a frame. 
2. Network adaptors, along with device drivers running in the node’s OS, typically implement the data link level. This means that frames, not raw bits, are actually delivered to hosts. 
2. The network layer handles routing among nodes within a packet-switched network. 
1. At this layer, the unit of data exchanged among nodes is typically called a packet rather than a frame, although they are fundamentally the same thing. 
3. The lower three layers are implemented on all network nodes, including switches within the network and hosts connected along the exterior of the network. 
4. The transport layer then implements what we have up to this point been calling a process-to-process channel. Here, the unit of data exchanged is commonly called a message rather than a packet or a frame. 
1. The transport layer and higher layers typically run only on the end hosts and not on the intermediate switches or routers.
5. There is less agreement about the definition of the top three layers. Skipping ahead to the top (seventh) layer, we find the application layer. 
1. Application layer protocols include things like the File Transfer Protocol (FTP), which defines a protocol by which file transfer applications can interoperate. 
6. Below that, the presentation layer is concerned with the format of data exchanged between peers, for example, 
1. whether an integer is 16, 32, or 64 bits long and whether the most significant bit is transmitted first or last, or how a video stream is formatted. 
7. Finally, the session layer provides a name space that is used to tie together the potentially different transport streams that are part of a single application. For example, it might manage an audio stream and a video stream that are being combined in a teleconferencing application.

Internet Architecture

The Internet architecture, which is also sometimes called the TCP/IP architecture after its two main protocols, is depicted in Figure 1.14. An alternative representation is given in Figure 1.15.

• The Internet architecture evolved out of experiences with an earlier packet-switched network called the ARPANET. 
• Both the Internet and the ARPANET were funded by the Advanced Research Projects Agency (ARPA), one of the R&D funding agencies of the U.S. Department of Defense. 
• The Internet and ARPANET were around before the OSI architecture, and the experience gained from building them was a major influence on the OSI reference model.
• While the seven-layer OSI model can, with some imagination, be applied to the Internet, a four-layer model is often used instead. 
• At the lowest level are a wide variety of network protocols, denoted NET1 , NET2 , and so on. 
• In practice, these protocols are implemented by a combination of hardware (e.g., a network adaptor) and software (e.g., a network device driver). 
• For example, you might find Ethernet or Fiber Distributed Data Interface (FDDI) protocols at this layer. (These protocols in turn may actually involve several sublayers, but the Internet architecture does not presume anything about them.) 
• The second layer consists of a single protocol—the Internet Protocol (IP). This is the protocol that supports the interconnection of multiple networking technologies into a single, logical internetwork. 
• The third layer contains two main protocols—the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). 
• TCP and UDP provide alternative logical channels to application programs: 
• TCP provides a reliable byte-stream channel, and 
• UDP provides an unreliable datagram delivery channel (datagram may be thought of as a synonym for message). 
• In the language of the Internet, TCP and UDP are sometimes called end-to-end protocols, although it is equally correct to refer to them as transport protocols.
• Running above the transport layer are a range of application protocols, such as FTP, TFTP (Trivial File Transport Protocol), Telnet (remote login), and SMTP (Simple Mail Transfer Protocol, or electronic mail), that enable the interoperation of popular applications.

To understand the difference between an application layer protocol and an application, think of all the different World Wide Web browsers that are available (e.g., Mosaic, Netscape, Internet Explorer, Lynx, etc.). There are a similarly large number of different implementations of Web servers. The reason that you can use any one of these application programs to access a particular site on the Web is because they all conform to the same application layer protocol: HTTP (HyperText Transport Protocol).

Confusingly, the same word sometimes applies to both an application and the application layer protocol that it uses (e.g., FTP).

The Internet architecture has three features that are worth highlighting.

1. First, as best illustrated by Figure 1.15, the Internet architecture does not imply strict layering. The application is free to bypass the defined transport layers and to directly use IP or one of the underlying networks. In fact, programmers are free to define new channel abstractions or applications that run on top of any of the existing protocols.
2. Second, if you look closely at the protocol graph in Figure 1.14, you will notice an hourglass shape—wide at the top, narrow in the middle, and wide at the bottom. This shape actually reflects the central philosophy of the architecture. That is, IP serves as the focal point for the architecture—it defines a common method for exchanging packets among a wide collection of networks. Above IP can be arbitrarily many transport protocols, each offering a different channel abstraction to application programs.

Thus, the issue of delivering messages from host to host is completely separated from the issue of providing a useful process-to-process communication service. Below IP, the architecture allows for arbitrarily many different network technologies, ranging from Ethernet to FDDI to ATM to single point-to-point links.

A final attribute of the Internet architecture (or more accurately, of the IETF
culture) is that in order for someone to propose a new protocol to be included in the architecture, they must produce both a protocol specification and at least one (and preferably two) representative implementations of the specification. The existence of working implementations is required for standards to be adopted by the IETF. This cultural assumption of the design community helps to ensure that the architecture’s protocols can be efficiently implemented. Perhaps the value the Internet culture places on working software is best exemplified by a quote on T-shirts commonly worn at IETF meetings:

We reject kings, presidents, and voting. We believe in rough consensus and running code.
(Dave Clark)

Of these three attributes of the Internet architecture, the hourglass design philosophy is important enough to bear repeating. The hourglass’s narrow waist represents a minimal and carefully chosen set of global capabilities that allows both higher-level applications and lower-level communication technologies to coexist, share capabilities, and evolve rapidly. The narrow-waisted model is critical to the Internet’s ability to adapt rapidly to new user demands and changing technologies.