Figure 3.2-1: Source and destination port number fields in a transport layer segment.
Although the multiplexing/demultiplexing service is not among the most exciting services that can be provided by a transport layer protocol, it is an absolutely critical one. To understand why it so critical, consider the fact that IP delivers data between two end systems, with each end system identified with a unique IP address. IP does not deliver data between the application processes that run on these end systems. Extending host-to-host delivery to a process-to-process delivery is the job of the transport layer's application multiplexing and demultiplexing service.
At the destination host, the transport layer receives segments (i.e., transport-layer PDUs) from the network layer just below. The transport layer has the responsibility of delivering the data in these segments to the appropriate application process running in the host. Let's take a look at an example. Suppose you are sitting in front of your computer, and you are downloading Web pages while running one FTP session and two Telnet sessions. You therefore have four network application processes running -- two Telnet processes, one FTP process, and one HTTP process. When the transport layer in your computer receives data from the network layer below, it needs to direct the received data to one of these four processes. Let's now examine how this is done.
Each transport-layer segment has a field that contains information that is used to determine the process to which the segment's data is to be delivered. At the receiving end, the transport layer can then examine this field to determine the receiving process, and then direct the segment to that process. This job of delivering the data in a transport-layer segment to the correct application process is called demultiplexing. The job of gathering data at the source host from different application processes, enveloping the data with header information (which will later be used in demultiplexing) to create segments, and passing the segments to the network layer is called multiplexing.
To illustrate the demultiplexing job, let us return to the household saga in the previous section. Each of the kids is distinguished by his or her name. When Bob receives a batch of mail from the mail person, he performs a demultiplexing operation by observing to whom the letters are addressed and then hand delivering the mail to his brothers and sisters. Alice performs a multiplexing operation when she collects letters from her brothers and sisters and gives the collected mail to the mail person.
UDP and TCP perform the demultiplexing and multiplexing jobs by including two special fields in the segment headers: the source port number field and the destination port number field. These two fields are illustrated in Figure 3.2-1. When taken together, the fields uniquely identify an application process running on the destination host. (The UDP and TCP segments have other fields as well, and they will be addressed in the subsequent sections of this chapter.)
The notion of port numbers was briefly introduced in Sections 2.6-2.7, in which we studied application development and socket programming. The port number is a 16-bit number, ranging from from 0 to 65535. The port numbers ranging from 0 - 1023 are called well-known port numbers and are restricted, which means that they are reserved for use by well-known application protocols such as HTTP and FTP. HTTP uses port number 80; FTP uses port number 21. The list of well-known port numbers is given in [RFC 1700]. When we develop a new application (such as one of the applications developed in Sections 2.6-2.8), we must assign the application a port number.
Given that each type of application running on an end system has a unique port number, then why is it that the transport-layer segment has fields for two port numbers, a source port number and a destination port number? The answer is simple: An end system may be running two processes of same type at the same time, and thus the port number of an application may not suffice to identify a specific process. For example, many Web servers spawn a new HTTP process for every request it receives; whenever such a Web server is servicing more than one request (which is by no means uncommon), the server is running more than one process with port number 80. Therefore, in order to uniquely identify processes, a second port number is needed.
How is this second port number created? Which port number goes in the source port number field of a segment? Which goes in the destination port number field of a segment? To answer these questions, recall from Section 2.1 that networked applications are organized around the client-server model. Typically, the host that initiates the application is the client and the other host is the server. Now let's look at a specific example. Suppose the application has port number 23 (the port number for Telnet). Consider a transport layer segment leaving the client (i.e., the host that initiated the Telnet session) and destined for the server. What are the destination and source port numbers for this segment? For the destination port number, this segment has the port number of the application, namely, 23. For the source port number, the client uses a number that is not being used by any of its other processes. (This is can be done automatically by the transport-layer software running on the client and is transparent to the application developer. An application can also explicitly request a specific port number using the bind() system call on many Unix-like systems.) Let's say the client chooses port number x. Then each segment that this process sends will have its source port number set to x and destination port number set to 23. When the segment arrives at the server, the source and destination port numbers in the segment enable the server host to pass the data of the segment to the correct application process: the destination port number 23 identifies a Telnet process and the source port number x identifies the specific Telnet process.
The situation is reversed for the segments flowing from the server to the client. The source port number is now the application port number, 23. The destination port number is now x. (The same x used for the source port number for the segments sent from client to server.) When a segment arrives at the client, the source and destination port numbers in the segment will enable the client host to pass the data of the segment to the correct application process, which is identified by the port number pair. Figure 3.2-2 summarizes the discussion:
Now you may be wondering, what happens if two different clients establish a Telnet session to a server, and each of these clients choose the same source port number x? How will the server be able to demultiplex the segments when the two sessions have exactly the same port number pair? The answer to this question is that server also uses the IP addresses in the IP datagrams carrying these segments. (We will discuss IP datagrams and addressing in detail in Chapter 4.) The situation is illustrated in Figure 3.2-3, in which host A initiates two Telnet sessions to host C, and host A initiates one Telnet session to host C. Hosts A, B and C each have their own unique IP address; host A has IP address A, host B has IP address B, and host C has IP address C. Host A assigns two different source port (SP) numbers (x and y) to the two Telnet connections emanating from host A. But because host B is choosing source port numbers independently from A, it can also assign SP=x to its Telnet connection. Nevertheless, host C is still able to demultiplex the two connections since the two connections have different source IP addresses. In summary, we see that when a destination host receives data from the network layer, the triplet [source IP address, source port number, destination port number] is used to forward the data to the appropriate process.
Now that we understand how the transport layer can multiplex and demultiplex
messages from/to network applications, let's move on and discuss one of
the Internet's transport protocols, UDP. In the next section we shall see
that UDP adds little more to the network layer protocol than multiplexing/demultiplexing
service.
References
[RFC 1700] J. Reynolds and J. Postel, "Assigned
Numbers," RFC 1700,
October 1994.