Although the multiplexing/demultiplexing service is not among the most ex citing services that can be provided by a transport-layer protocol, it is absolutely critical. To understand why it is 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 process-to-process delivery is the job of application multiplexing and demultiplexing. 

At the destination host, the transport layer receives segments (that is, 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 set of fields that determine the process to which the segment's data is to be delivered. At the receiving end, the transport layer can then examine these fields 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 (that will later be used in demultiplexing) to create segments, and passing the segments to the network layer is called multiplexing. Multiplexing and demultiplexing are illustrated in Figure 3.2. 

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 Bill 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. Ann 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.3. 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 0 to 65535. The port numbers ranging from 0 to 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 the same type at the same time, and thus the port destination number of an application may not suffice to identify a specific process. For example, a Web server may spawn a new HTTP process for every request it processes; 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 the process to which data is destined, 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 networking 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 us 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 (that is, 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 other host processes. (This is done automatically by the transport-layer software running on the client and is transparent to the application developer.) Let's say the client chooses port number x. Then each segment that this process sends to the Telnet server 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 segment's data 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.4 summarizes the discussion. 

Now you may be wondering, what happens if two different clients establish a session to a server and each of these clients choose the same source port number x? This might well happen with a busy www server that handles many Web clients simultaneously. 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 the 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.5, in which host C initiates two HTTP sessions to server B, and host A initiates one HTTP session to B. Hosts A, C, and server B each have their own unique IP address, A, C, and B, respectively. Host C assigns two different source port (SP) numbers (x and y) to the two HTTP connections emanating from host A. But because host A is choosing source port numbers independently from C, it can also assign SP = x to its HTTP connection. Nevertheless, server B is still able to correctly 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've shown how the transport layer can multiplex and demultiplex network applications, let's move on and discuss one of the Internet's transport protocols, UDP. In the next section we'll see that UDP adds little more to the network-layer protocol than a multiplexing/demultiplexing service.