Communication Protocols

1.2 Communication Protocols

Some of the communication protocols and their overview are presented here so that we understand how to use the protocols, and to provide references to more detailed descriptions of the actual design and imple­mentation of the protocols.

Following protocol suites are presented in this document.

• the TCP/IP protocol suite (the Internet protocols),

• Xerox Networking Systems (Xerox NS or XNS),

• IBM's Systems Network Architecture (SNA),

• IBM's NetBIOS,

• the OSI protocols,

• Unix-to-Unix Copy (UUCP).

For each protocol suite an overview is presented, and the relevant portions for the protocol's layers are discussed. The description starts from the bottom layer and work our way up. Some of the protocols like XNS and OSI are just presented in brief.

XNS, SNA, are actually rarely used these days because of the popularity of the TCP/IP. NetBIOS is still in use in PC world and UUCP is used with the Unix systems only.

1.2.1 TCP/IP—the Internet Protocols

During the late 1960s and the 1970s the Advanced Research Projects Agency (ARPA) of the Department of Defense (DoD) sponsored the development of the ARPANET. The ARPANET included military, university, and research sites, and was used to support computer science and military research projects. (ARPA is now called DARPA, with the first letter of the acronym standing for "Defense.") In 1984 the DoD split the ARPANET into two networks—the ARPANET for experimental research, and the MILNET for military use. In the early 1980s a new family of protocols was specified as the standard for the ARPANET and associated DoD networks. Although the accurate name for this family of protocols is the "DARPA Internet protocol suite," it is com­monly referred to as the TCP/IP protocol suite, or just TCP/IP.

In 1987 the National Science Foundation (NSF) funded a network that connects the six national supercomputer centers together. This network is called the NSFNET. Physi­cally this network connects 13 sites using high-speed leased phone lines and this is called the NSFNET backbone. About eight more backbone nodes are currently planned. Addi­tionally the NSF has funded about a dozen regional networks that span almost every state. These regional networks are connected to the NSFNET backbone, and the NSFNET backbone is also connected to the DARPA Internet. The NSFNET backbone and the regional networks all use the TCP/IP protocol suite.

There are several interesting points about TCP/IP.

• It is not vendor-specific.

• It has been implemented on everything from personal computers to the largest supercomputers.

• It is used for both LANs and WANs.

• It is used by many different government agencies and commercial sites, not just DARPA-funded research projects.

The DARPA-funded research has led to the interconnection of many different individual networks into what appears as a single large network—an internet, as described in the previous chapter. We refer to this internet as just the Internet (capitalized).

It is important to realize that while sites on the Internet use the TCP/IP protocols, many other organizations (with no government affiliation whatsoever) have established their own internets using the same TCP/IP protocols. At one extreme we have the Inter­net using TCP/IP to connect more than 150,000 computers throughout the United States, Europe and Asia, and at the other extreme we could have a network consisting of only two personal computers in the same room connected by an Ethernet using the same TCP/IP protocols.

To avoid having to qualify everything with "the TCP/IP protocol suite" or "the DARPA Internet protocol suite," we use the capitalized word Internet, as in "an Internet address," or "the Internet protocols," to refer to the TCP/IP protocol suite. This is to avoid confusion with internets that use protocols other than TCP/IP.

One reason for the increased use of the TCP/IP protocols during the 1980s was their inclusion in the BSD Unix system around 1982. This, along with the use of BSD Unix in technical workstations, allowed many organizations and university departments to estab­lish their own LANs.

1.2.1.1 Overview

Although the protocol family is referred to as TCP/IP, there are more members of this family than TCP and IP. Figure 4 shows the relationship of the protocols in the proto­col suite along with their approximate mapping into the OSI model.

Figure 4. Layering in the Internet protocol suite

TCP Transmission Control Protocol. A connection-oriented protocol that provides a reliable, full-duplex, byte stream for a user process. Most Internet application programs use TCP. Since TCP uses IP (as shown in Figure 4) the entire Internet protocol suite is often called the TCP/IP protocol family.

UDP User Datagram Protocol. A connectionless protocol for user processes. Unlike TCP, which is a reliable protocol, there is no guarantee that UDP datagrams ever reach their intended destination.

ICMP Internet Control Message Protocol. The protocol to handle error and control information between gateways and hosts. While ICMP messages are transmitted using IP datagrams, these messages are normally generated by and processed by the TCP/IP networking software itself, not user processes.

IP Internet Protocol. IP is the protocol that provides the packet delivery service for TCP, UDP, and ICMP. Note from the Figure 4 that user processes nor­mally do not need to be involved with the IP layer.

ARP Address Resolution Protocol. The protocol that maps an Internet address into a hardware address. This protocol and the next, RARP, are not used on all networks. Only some networks need it.

RARP Reverse Address Resolution Protocol. The protocol that maps a hardware address into an Internet address.

There are other protocols in the Internet protocol suite that we do not consider here—GGP (Gateway-to-Gateway Protocol) and VMTP (Versatile Message Transaction Protocol), for example.

1.2.1.2 Data-Link Layer

The ARPANET consists of about 50 special purpose computers that are connected together using leased telephone lines at 57.6 Kbps. The host computers and gateways on the ARPANET are then connected to these special purpose computers. The 13 backbone sites of the NSFNET are connected with Tl leased phone lines, which operate at 1.544 Mbps. Most 4.3BSD systems using the TCP/IP suite for a LAN use Ethernet tech­nology. Products also exist that use a token ring for a LAN using TCP/IP. There also exist implementations using an RS-232 serial line protocol (at speeds from 1200 bps to 19.2 Kbps) called the Serial Line Internet Protocol (SLIP). There are a variety of other data-link connections in use by TCP/IP networks: satellite links and packet radio, for example.

1.2.1.3 Network Layer—IP

IP Datagrams

The IP layer provides a connectionless and unreliable delivery system. It is connection­less because it considers each IP datagram independent of all others. Any association between datagrams must be provided by the upper layers. Every IP datagram contains the source address and the destination address (described below) so that each datagram can be delivered and routed independently. The IP layer is unreliable because it does not guarantee that IP datagrams ever get delivered or that they are delivered correctly. Reli­ability must also be provided by the upper layers. The IP layer computes and verifies a checksum that covers its own 20-byte header (that contains, for example, the source and destination addresses). This allows it to verify the fields that it needs to examine and pro­cess. But if an IP header is found in error, it is discarded, with the assumption that a higher layer protocol will retransmit the packet.

As we saw in the gateway examples from the previous chapter, it is the IP layer that handles routing through an Internet. The IP layer is also responsible for fragmentation, as described in the previous chapter. For example, if a gateway receives an IP datagram that is too large to transmit across the next network, the IP module breaks up the data­gram into fragments and sends each fragment as an IP packet. (Technically, the protocol unit exchanged by the end-to-end IP layers is an IP datagram. An IP datagram can be fragmented into smaller IP packets. When fragmentation does occur, the IP layer dupli­cates the source address and destination address into each IP packet, so the resulting IP packets can be delivered independently of each other.) The fragments are reassembled into an IP datagram only when they reach their final destination. If any of the fragments are lost or discarded, the entire datagram is discarded by the destination host.

The IP layer provides an elementary form of flow control. When IP packets arrive at a host or gateway so fast that they are discarded, the IP module sends an ICMP source quench message to the original source informing that system that the data is arriving too fast. With 4.3BSD, for example, the ICMP source quench is passed to the TCP module (assuming it was a TCP message that caused the source quench), which then decreases the amount of data being sent on that connection.

Internet Addresses

Every protocol suite defines some type of addressing that identifies networks and com­puters. An Internet address occupies 32 bits and encodes both a network ID and a host ID. The host ID is relative to the network ID. Every host on a TCP/IP internet must have a unique 32-bit address. TCP/IP addresses on the Internet are assigned by a central authority—Internet Assigned Number Authority (IANA).

A 32-bit Internet address has one of the four formats shown in Figure 5

Figure 5 Internet address formats.

Class A addresses are used for those networks that have a lot of hosts on a single net­work, while Class C addresses allow for more networks but fewer hosts per network. For network addresses assigned by the NIC, only the type of address (Class A, B, or C) and the network ID is assigned. The requesting organization then has responsibility for assigning individual host addresses on that network. We won't consider multicast addresses (Class D) any further.

Internet addresses are usually written as four decimal numbers, separated by decimal points. Each decimal digit encodes one byte of the 32-bit Internet address. For example, the 32-bit hexadecimal value 0x0102FF04 is written as 1.2.255.4. This example is a Class A address with a network ID of 1 and a host ID of 0x02FF04. A sample Class B address is 128.3.0.5, and a sample class C address is 192.43.235.6.

Every IP datagram contains the 32-bit Internet address of the source host and the 32-bit Internet address of the destination host, in every 20-byte IP header. Since an Inter­net address is comprised of a network ID and a host ID, gateways can easily extract the network ID field from a 32-bit address and route IP datagrams based solely on the net­work ID. This is an important concept for routing, as it means that a gateway needs only to know the location of other networks, and does not to need to know the location of every host on an Internet.

Recall that a multihomed host is connected to two or more networks. This implies that it must have two or more Internet addresses, one for each network that it is con­nected to. This means that every Internet address specifies a unique host, but each host does not have a unique address.

Subnet Addresses

Any organization with an Internet address of any class can subdivide the available host address space in any way it desires, to provide subnetworks. For example, if you have a Class B address, there are 16 bits allocated for the host ID. If your organization wants to assign host IDs to its 150 hosts, that are in turn organized into 10 physical networks, there are two different ways to do this.

• You can allocate host IDs of 1 through 150, ignoring the physical network struc­

ture. This requires that all the gateway systems among the 150 hosts know where

each individual host is located, for routing purposes. Adding a new host requires

that each gateway's routing table be updated.

• You can allocate some of the high-order bits from the host ID, say the high-order

8 bits, for the network ID within your subnetwork. These 8 bits are independent

of the Class B network ID. The remaining 8 bits of the Class B host ID you then

use to identify the individual hosts on each internal network. Using this tech­

nique, your gateway systems can extract the 8-bit internal network ID and use it

for routing, instead of having to know where each of the 150 hosts are located.

Adding a new host on an existing internal network doesn't require any changes to

the internal gateways.

A picture of what the second option is doing is given in Figure 6.

Figure 6. Class B Internet address with subnetting

This feature adds another level to the Internet address hierarchy.

• network ID

• subnet ID within network

• host ID within subnet

Address Resolution

If we have an Ethernet LAN consisting of hosts using the TCP/IP protocols, we have two types of addresses: 32-bit Internet addresses and 48-bit Ethernet addresses. Recall from the previous chapter that the 48-bit Ethernet addresses are typically assigned by the manufacturer of the interface board and are all unique. We have the following address resolution problems:

• If we know the Internet address of the other host that we want to communicate

with, how does the IP layer determine which Ethernet address corresponds to that

host? This is the address resolution problem.

• When a diskless workstation is initialized (bootstrapped), the operating system

can usually determine its own 48-bit Ethernet address from its interface hardware.

But we do not want to embed the workstation's 32-bit Internet address into the

operating system image, as this prevents us from using the same image for multi­

ple workstations. How can the diskless workstation determine its Internet address

at bootstrap time? This is the reverse address resolution problem.

The first problem is solved using the Internet Address Resolution Protocol (ARP), and the second uses the Internet Reverse Address Resolution Protocol (RARP).

The ARP allows a host to broadcast a special packet on the Ethernet that asks the host with a specified Internet address to respond with its Ethernet address. Every host on the Ethernet receives this broadcast packet, but only the specified host should respond. Once the requesting host receives the response it can maintain the mapping between the Internet address and the Ethernet address for all future packets destined for the same Internet address.

The RARP is intended for a LAN with diskless workstations. One or more systems on the LAN are the RARP servers and contain the 32-bit Internet address and its corresponding 48-bit Ethernet address for each workstation. This allows the operating system for each workstation to be generated without having to have its Internet address as part of its configuration. When the workstation is initialized, it obtains its 48-bit Ethernet address from the interface hardware and broadcasts an Ethernet RARP packet containing its Ethernet address and asking for its Internet address. Every host on the Ethernet LAN receives this broadcast, but only the RARP servers should respond.

1.2.1.4 Transport Layer—UDP and TCP

User processes interact with the TCP/IP protocol suite by sending and receiving either TCP data or UDP data. The relationship of TCP and UDP to our simplified 4-layer model shown in Figure 7.

Figure 7. 4-layer model showing UDP, TCP, and IP.

These two protocols are sometimes referred to as TCP/IP or UDP/IP, to indicate that both use IP also.

TCP provides a connection-oriented, reliable, full-duplex, byte-stream service to an application program. UDP, on the other hand, provides a connectionless, unreliable data­gram service. Figure 8 compares IP, UDP, and TCP against the modes of service.

Figure 8. Comparison of protocol features for IP, UDP, and TCP.

Notice that we list IP as not having flow control, since the source quench feature described earlier is not an end-to-end flow control technique.

Since the IP layer provides an unreliable, connectionless delivery service for TCP, it is the TCP module that contains the logic necessary to provide a reliable, virtual circuit for a user process. TCP handles the establishment and termination of connections between processes, the sequencing of data that might be received out of order, the end-to-end reliability (checksums, positive acknowledgments, timeouts), and the end-to-end flow control.

UDP provides only two features that are not provided by IP: port numbers (described below) and an optional checksum to verify the contents of the UDP datagram. But these two features are enough reason for a user process to use UDP instead of trying to use IP directly, when a connectionless datagram protocol is required.

Port Numbers

It is possible for more than one user process at a time to be using either TCP or UDP. This requires some method for identifying the data associated with each user process. Both TCP and UDP use 16-bit integer port numbers for this identifi­cation.

When a client process wants to contact a server, the client must have a way of identi­fying the server that it wants. If the client knows the 32-bit Internet address of the host on which the server resides it can contact that host, but how does the client identify the particular server process? To solve this problem, both TCP and UDP have defined a group of well-known ports. (These are the Internet-specific well-known addresses) For example, every TCP/IP implementation that supports FTP, the File Transfer Protocol, assigns the well-known port of 21 (decimal) to it. TFTP, the Trivial File Transfer Protocol, is assigned the UDP port of 69.

Let's take this client-server interaction to the next step and assume that a client sends a message to the FTP server on some host by sending a message to port 21 on that host. How does the FTP server know where to send its response? First, the server can obtain the 32-bit Internet address of the client from the IP datagram, since these data­grams contain the source and destination Internet addresses in the 20-byte IP header. The client process also requests an unused port number from the TCP module on its local host. The server can obtain the 16-bit port number from the TCP header. As long as the client's TCP module does not reassign this port number to some other process before the first client is finished, there won't be any conflict. When TCP or UDP assign unique port numbers for user processes, they are called ephemeral port numbers (short lived). The process that receives the ephemeral port number (the client process in this example) doesn't care what value it is. It is the other end of the communication link (the server) that needs it. TCP and UDP port numbers in the range 1 through 255 are reserved. All the well-known ports are in this range. Some operating systems reserve additional ports for privileged programs (4.3BSD reserves the ports 1-1023 for superuser processes), and the ephemeral ports are above these reserved ports. A hierarchical addressing scheme that involves multiple layers is described.

• The IP datagram contains the source and destination Internet addresses in its IP

header. These two 32-bit values uniquely identify the two host systems that are

communicating.

• Also contained in the IP header is a protocol identifier, so that the IP module can

determine if an IP datagram is for TCP, UDP, or some other protocol module that

uses IP, which isn't discussed in this text.

• The UDP header and the TCP header both contain the source port number and the

destination port number. These two 16-bit integer values are used by the protocol

modules to identify a particular user process. Note that the TCP ports are

independent of the UDP ports, since the IP header specifies the protocol. TCP

port 1035, for example, is independent of UDP port 1035.

The addition of this control information by the dif­ferent protocol modules is encapsulation. The combination of information from different sources using identifiers such as port numbers, protocol types, and Internet addresses is called multiplexing.

The 5-tuple that defines an association in the Internet suite consists of

• the protocol (TCP or UDP),

• the local host's Internet address (a 32-bit value),

• the local port number (a 16-bit value),

• the foreign host's Internet address (a 32-bit value),

• the foreign port number (a 16-bit value).

An example could be

(tcp, 128.10.0.3, 1500, 128.10.0.7, 21}

Figure 9 diagrams the encapsulation that takes place with UDP data on an Ethernet.

If the length of the IP datagram (the data, plus the UDP header, plus the IP header) is greater than the MTU of the network access layer, then the IP layer has to fragment the datagram before it is passed to the network access layer. If this happens, the receiving IP layer has to reassemble the fragments into a single datagram before it is passed to the upper layers (e.g., UDP). Whether fragmentation takes place or not, the size of the data message (the datagram) exchanged by the two UDP layers is the same.

Figure 9. Encapsulation of UDP data on an Ethernet

Similarly, the encapsulation that takes place with TCP data is shown in Figure 10.

Figure 10. Encapsulation of TCP data on an Ethernet

As with UDP, it is also possible for the TCP layer to pass messages to the IP layer that exceed the underlying network's MTU. If this happens, the sending IP layer does frag­mentation and the receiving IP layer does reassembly. For performance reasons, how­ever, most TCP implementations try to prevent IP fragmentation.

Concurrent Servers

With a concurrent server, what happens if the child process that is spawned by the main server continues to use its well-known port number while servicing a long request? Let's examine a typical sequence. First, the server is started on the host orange and it does a passive open using its well-known port number (21, for this example). It is now waiting for a client request.

The notation {tcp, *, 21} is used to indicate that the server is waiting for a TCP connection on any connected network (i.e., interface), on port 21. If the host on which the server is running is connected to more than one TCP/IP network, the server can specify that it only wants to accept a connection from a client on one specific network. Our asterisk notation indicates that a connection will be accepted on any network.

At some later time a client starts up and executes an active open to the server. The client has an ephemeral port number assigned to it by the protocol module (TCP, in this example). Assume the ephemeral port number is 1500 for this example, and assume that the name of the client's host is apple. This is shown in Figure 11.

Figure 11. Connection from client to server

The notation {tcp, apple, 1500} is the client's half association or socket. Here we are designating the Internet address as apple, using the name of the host instead of its 4-digit notation. When the server receives the client's connection request, it forks a copy of itself, passing the connection to the child process, as shown in Figure 12.

Figure 12. Concurrent server passes connection to child

The association is {tcp, orange, 21, apple, 1500 }. The server process that was waiting for the client connection now returns to its wait loop, letting the child pro­cess handle the client's request.

Assume that another client process on the host apple requests a connection to the same server. The client's TCP module assigns it a new ephemeral port number, say 1501, so that the half association {tcp, apple, 1501} is unique on the host apple. This gives us the picture shown in Figure 13.

Figure 13. Second client connection passed to another child

Note that even though there are two identical half associations on the orange host, {tcp, orange, 21}, the two complete associations are unique.

{tcp, orange, 21, apple, 1500}

{tcp, orange, 21, apple, 1501}

The TCP module on the orange system is able to determine which server child process is to receive a given data message, based on the source Internet address and the source TCP port number.

It is assumed in the examples above that the TCP module assigns a unique ephemeral port number to a process (e.g., a client) if the process does not need to assign a well-known port to itself (e.g., a server). This is what normally happens. There are instances, however, when a process can request that a specific port be used. The Internet FTP has this requirement, and it is interesting to examine this as another example of Internet addressing and port assignment.

FTP normally runs using the standard client and concurrent-server relationship, as shown above. User commands are passed from the client to the server across the TCP connection, with the server's responses being returned on the connection. But when we request a file to be transferred between the client and server, another TCP connection is established between the two processes. This provides one connection for commands and one connection for data. The client initiates the transfer by sending a command across the existing connection to the server. The client also creates a new communication chan­nel, using the same port number that it is using for the control connection. The client does a passive open on this new channel, waiting for the server to complete the connec­tion. This is different from the previous examples, as the client now has to tell its TCP module that it is OK to use the same port number, even though the half association, {tcp, apple, 1500 }, for example, is not unique on the client's host. (This is done using the SO_REUSEADDR socket option.) To guaran­tee a unique association when the server completes the connection with this new client port, the server must use some other port. FTP dictates that the server uses the well-known port 20 for this purpose. If we assume that both the client processes in our previ­ous examples are FTP clients, and both have established a data connection with their respective servers, we have the picture shown in Figure 14. All four associations are unique, as required by the Internet protocol suite.

{tcp, orange, 20, apple, 1500}

{tcp, orange, 21, apple, 1500}

{tcp, orange, 20, apple, 1501}

{tcp, orange, 21, apple, 1501}

Figure 14. FTP example with two clients and two servers

Buffering and Out-of-Band Data

UDP is a datagram service. Every datagram written by a user process has a header encapsulated by the UDP layer, and then the datagram is passed to the IP layer for transmis­sion. There is no reason for the UDP layer to let the user's data hang around in the UDP layer. The data is transmitted as soon as the IP layer can get to it, so the concepts of buffering and out-of-band data do not apply to UDP.

TCP, however, presents a byte-stream service to the user process, and provides both of these features. In TCP terminology the flush output command is called the push flag, and out-of-band data is called urgent data. By definition, TCP supports any amount of out-of-band data, but not all implementations support more than one byte at a time of urgent data.

Buffer Sizes and Limitations

By definition the maximum size of an IP datagram is 65,536 bytes. Assuming a 20-byte IP header, this leaves up to 65,516 bytes for other data in the datagram. Realize, how­ever, that as soon as the size of an IP datagram exceeds the size of the underlying network's MTU, fragmentation occurs. Furthermore, not all TCP/IP implementations support IP fragmentation, let alone fragmentation of a 65,536-byte datagram. Every TCP/IP implementation must support a minimum IP datagram size of 576 bytes. Note that a network can have an MTU smaller than 576, but any host must be able to reassemble the fragmented IP packets into at least a 576-byte IP datagram. The actual maximum size of an IP datagram depends on the IP software on both ends, as well as the software on every gateway between the two ends.

Since UDP packets are transmitted using IP, if the result of adding the UDP header and the IP header causes the datagram to exceed the network's MTU, fragmentation occurs. This means, for example, that sending 2048-byte UDP packets on an Ethernet guarantees fragmentation.

TCP is different, since it breaks up the data into what it calls segments. The segment size used by TCP is agreed on between the two ends when a connection is established.

1.2.1.5 Application Layer

There are several application programs that are provided by almost every TCP/IP imple­mentation. One strength of the TCP/IP protocol suite is the availability of these standard applications for a variety of operating environments.

FTP—File Transfer Protocol

FTP is a program used to transfer files from one system to another. It provides a rich set of features and options, such as user authentication, data conversion, directory listings, and the like.

A typical sequence of events is for an interactive user to invoke an FTP client pro­cess on the local system. This client process establishes a connection with an FTP server process on the remote system using TCP. FTP establishes two connections between the client and server processes—one for control information (commands and responses) and the other for the data being transferred. The interactive user is prompted for access infor­mation on the remote system (login name and password, if required), and files can then be transferred in both directions. FTP handles both binary and text files.

TFTP—Trivial File Transfer Protocol

TFTP is a simpler protocol than FTP. While it provides for file transfer between a client process and a server process, it does not provide user authentication or some of the other features of FTP (listing directories, moving between directories, etc.). TFTP uses UDP, not TCP.

TELNET—Remote Login

TELNET provides a remote login facility. It allows an interactive user on a client system to start a login session on a remote system. Once a login session is established, the client process passes the user's keystrokes to the server process. As with the FTP program, TELNET uses TCP.

SMTP—Simple Mail Transfer Protocol

SMTP provides a protocol for two systems to exchange electronic mail using a TCP con­nection between the two systems.