When communication among computers from different vendors is desired, the software development effort can be a nightmare. Different vendors use different data formats and data exchange protocols. Even within one vendor’s product line, different model computers may communicate in unique ways.
As the use of computer communications and computer networking proliferates, a one-at-a-time, special-purpose approach to communications software development is too costly to be acceptable. The only alternative is for computer vendors to adopt and implement a common set of conventions. For this to happen, standards are needed. Such standards would have two benefits:
i. Vendors feel encouraged to implement the standards because of an expectation that, because of wide usage of the standards, their products would be less marketable without them.
ii. Customers are in a position to require that the standards be implemented by any vendor wishing to propose equipment to them.
However, no single standard will suffice. Any distributed application, such as electronic mail or client/server interaction, requires a complex set of communications
functions for proper operation. Many of these functions, such as reliability mechanisms, are common across many or even all applications. Thus, the communications task is best viewed as consisting of a modular architecture, in which the various elements of the architecture perform the various required functions. Hence, before standards can be developed, there should be a structure, or protocol architecture, that defines the communications tasks.
Two protocol architectures have served as the basis for the development of interoperable communications standards: the TCP/IP protocol suite and the Open Systems Interconnection (OSI) reference model. TCP/IP is the most widely used interoperable architecture, and has won the “protocol wars.” Although some useful standards have been developed in the context of OSI, TCP/IP is now the universal interoperable protocol architecture. No product should be considered as part of a business information system that does not support TCP/IP.
TCP/IP is a result of protocol research and development conducted on the experimental packet-switched network, ARPANET, funded by the Defence Advanced Research Projects Agency (DARPA), and is generally referred to as the TCP/IP protocol suite. This protocol suite consists of a large collection of protocols that have been issued as Internet standards by the Internet Activities Board (IAB).
There is no official TCP/IP protocol model, as there is in the case of OSI. However, based on the protocol standards that have been developed, we can organize the communication task for TCP/IP into five relatively independent layers:
· Application layer
· Host-to-host, or transport layer
· Internet layer
· Network access layer
· Physical layer
The physical layer covers the physical interface between a data transmission device (such as a workstation or computer) and a transmission medium or network. This layer is concerned with specifying the characteristics of the transmission medium, the nature of the signals, the data rate, and related matters.
The network access layer is concerned with the exchange of data between an end system and the network to which it’s attached. The sending computer must provide the network with the address of the destination computer, so that the network can route the data to the appropriate destination. The sending computer may need to invoke certain services, such as priority, that might be provided by the network.
The specific software used at this layer depends on the type of network to be used; different standards have been developed for circuit-switching, packet-switching (for example, frame relay), local area networks (such as Ethernet), and others. Thus, it makes sense to separate those functions having to do with network access into a separate layer. By doing this, the remainder of the communications software, above the network access layer, need not be concerned about the specifics of the network to be used. The same higher-layer software should function properly regardless of the particular network to which the computer is attached.
The network access layer is concerned with access to and routing data across a network for two end systems attached to the same network. In those cases where two devices are attached to different networks, procedures are needed to allow data to traverse multiple interconnected networks. This is the function of the Internet layer. The Internet protocol (IP) is used at this layer to provide the routing function across multiple networks. This protocol is implement not only in the end systems but also in routers. A router is a processor that connects two networks; its primary function is to relay data from one network to the other on its route from the source to the destination end system.
Regardless of the nature of the applications that are exchanging data, there is usually a requirement that data be exchanged reliably. That is, we want to be assured that all of the data arrives at the destination application, in the order in which it was sent. The mechanisms for providing reliability are essentially independent of the nature of the applications. Thus, it makes sense to collect those mechanisms in a common layer shared by all applications; this is referred to as the host-to-host or transport layer. The transmission control protocol (TCP) is the most commonly used protocol to provide this functionality.
Finally, the application layer contains the logic needed to support the various user applications. For each type of application, such as file transfer, a separate module is needed that’s peculiar to that application.
The Application Layer
The application layer defines how certain services operate and how they can be used. Examples are the FTP service for transferring files, HTTP for serving Web pages and SMTP for e-mail.
These services are defined in a rather abstract manner. Two parties, called the client and the server, set up a connection over which they exchange messages in accordance with a specific protocol. The client starts the protocol by requesting the service. Often the next step is for the server to authenticate the client, for example by asking for a password or by executing a public-key based protocol.
Taking e-mail as an example, the protocol in question is called the Simple Mail Transfer Protocol (SMTP). The client and the server set up an SMTP connection over which they exchange identifying information. The client then tells who the message is from and who the intended recipient is. The server then indicates whether it accepts or refuses the message (for example if it’s spam or the intended recipient is unknown). If the message is accepted, the client sends the actual content of the message and the server stores it in the right mailbox.
The Transport Layer
On the Internet, the transport layer is realized by two protocols. The first is the Transmission Control Protocol (TCP) and the second is the User Datagram Protocol (UDP). Both break up a message that an application wants to send into packets and attempt to deliver those packets to the intended recipient. At the recipient’s side, both take the payload from the received packets and pass those to the application layer.
The main difference between TCP and UDP is that TCP is reliable and UDP is not. TCP will collect incoming packets, put them in the right order and thereby reassemble the original message. If necessary, TCP requests retransmission of lost or damaged packets. UDP merely takes each incoming packet and delivers the payload (the original message) to the application layer. Any errors or out-of-order data should be taken care of by the application.
UDP is much faster than TCP, and so is mainly used for applications like audio and video streaming, where the occasional error is less important than getting all the data there at the right time. More generally, UDP is designed for applications that do not require the packets to be in any specific order. Because of this, UDP is sometimes called a “connection-less” protocol.
Taking the example of e-mail again, the e-mail client and server communicate over a reliable TCP connection. The server listens on a certain port (port 25) until a connection request arrives from the client. The server acknowledges the request, and a TCP connection is established. Using this connection the client and server can exchange data.
The content of this data is not really relevant at this level: that’s the responsibility of the application layer. The e-mail message and all the other information exchanged at that SMTP application layer are merely payload, data that needs to be transported. Hence the name transport layer.
The Network Layer
The network layer is responsible for transmitting and routing data packets over the network. The Internet uses the Internet Protocol or IP as its network layer. Each node on the network has an address, which of course is called the IP address. Data is sent as IP packets.
A transport layer connection is made up up of a large number of IP packets exchanged by the client and server. The Internet Protocol (IP) is very simple: a packet has a source, a destination and a payload, and it’s passed from one node in the network to another until it gets to the destination. The IP does not notice that a packet gets lost. It just never gets to the destination. If a particular node cannot pass the packet to the next node along the normal route, it will do its best to find an alternative path. That’s why IP is sometimes called a “best-effort” protocol.
When the client sends its TCP connection request, the network layer puts the request in a number of packets and transmits each of them to the server. Each packet can take a different route, and some of the packets may get lost along the way. If they all make it, the transport layer at the server is able to reconstruct the request, and it will prepare a response confirming that a TCP connection has been set up. This response is sent back again in a number of IP packets that will hopefully make it to the client.
The Link Layer
The Internet Protocol basically assumes all computers are part of one very large “web” of nodes that can all pass packets to other nodes. There’s always a route from one node to another, even if sometimes a very large number of intermediate nodes get involved. The link layer is what makes this assumption true.
The link layer provides a network connection between hosts on a particular local network, as well as interconnection between such local networks. The e-mail client runs on a personal computer in someone’s home network, which is set up using the Ethernet protocol. The link layer now is that Ethernet network. The IP packets that this computer transmits, are added as payload to Ethernet packets (called “frames”) that are transmitted over the local network to the ADSL modem that connects the local network to the provider.
A different kind of link layer protocol is used to transmit the payload taken from the Ethernet frames from the ADSL modem to the provider. At the provider this payload is again passed forward using yet another link level protocol. The “web of nodes” that the Internet Protocol relies on thus actually is made up of a large number of local networks, each with their own link layer protocol, that each forward the IP packet by putting it into their own kind of message that is then sent over the local network.
The Physical Layer
The lowest layer is the physical layer, which defines how the cables, network cards, wireless transmitters and other hardware connect computers to networks and networks to the rest of the Internet. Examples of physical layer networks are Ethernet, WiFi, Token Ring and Fiber Data Distributed Interface (FDDI). Note that many of these technologies also have their own link layer protocol. Often link and physical layer are closely related.
The physical layer provides the means to transfer the actual bits from one computer to another. In an Ethernet network (a link layer protocol), a computer is connected by plugging a network cable into its Ethernet card, and then plugging the other end of that cable into a router or switch. The physical layer specifies how bits of data are sent over that cable: how do the electrical currents or the pulses the card sends get turned back into the data for the higher level layers. For wireless networks, this works exactly the same, except of course there is no cable.