- Dont do header information of UDP

UNIT 7
Transport Layer
Process-to-Process Delivery:
UDP TCP, SCTP

23.1
 23-1 PROCESS-TO-PROCESS DELIVERY

The transport layer is responsible for process-to-

process delivery—the delivery of a packet, part of a
message, from one process to another. Two processes
communicate in a client/server relationship, as we will
see later.
Topics discussed in this section:
Client/Server Paradigm
Multiplexing and Demultiplexing
Connectionless Versus Connection-Oriented Service
Reliable Versus Unreliable
Three Protocols
23.2
 PROCESS TO PROCESS DELIVERY
Node-to-node delivery-
• The data link layer is responsible for delivery of frames between two
neighboring nodes over a link. This is called node-to-node delivery.
Host-to-host delivery -
• The network layer is responsible for delivery of datagrams between two hosts.
This is called host-to-host delivery.
Process-to-process delivery –
• Communication on the Internet is not defined as the exchange of data between
two nodes or between two hosts. Real communication takes place between
two processes (application programs). This is called process-to-process
delivery.
• However, at any moment, several processes may be running on the source host
and several on the destination host. To complete the delivery, we need a
mechanism to deliver data from one of these processes running on the source
host to the corresponding process running on the destination host.
• The transport layer is responsible for process-to-process delivery, the delivery
of a packet, part of a message, from one process to another.
• Two processes communicate in a client/server relationship
• Figure 23.1 shows these three types of deliveries and their domains.
20.3
 Figure 23.1 Types of data deliveries

23.4
 Note

The transport layer is responsible for

process-to-process delivery.

23.5
 Client/Server Paradigm
• There are several ways to achieve process-to-process communication
• The most common one is through the client/server paradigm.
• A process on the local host, called a client, needs services from a process
usually on the remote host, called a server.
• Both processes (client and server) have the same name. For example, to get
the day and time from a remote machine, we need a Daytime client process
running on the local host and a Daytime server process running on a remote
machine.
• Operating systems today support both multiuser and multiprogramming
environments.
• A remote computer can run several server programs at the same time, just as
local computers can run one or more client programs at the same time.
For communication, we must define the following:
1. Local host
2. Local process
3. Remote host
4. Remote process

20.6
 Figure 23.2 Port numbers

23.7
 Addressing – Port Numbers
• Port number -
• At the transport layer, we need a transport layer address, called a port number,
to choose among multiple processes running on the destination host.
• The destination port number is needed for delivery;
• The source port number is needed for the reply.
• In the Internet model, the port numbers are 16-bit integers between 0 and
65,535.
• Ephemeral port number - The client program defines itself with a port
number, chosen randomly by the transport layer software running on the client
host. This is the ephemeral port number.
• Well-known port numbers - The server process must also define itself with a
port number. This port number cannot be chosen randomly.
• If the computer at the server site runs a server process and assigns a random
number as the port number, the process at the client site that wants to access
that server and use its services will not know the port number.
• So the Internet has decided to use universal port numbers for servers; these are
called well-known port numbers.

20.8
 Addressing – Port Numbers

• There are some exceptions to this rule; for example, there are clients that
are assigned well-known port numbers.
• Every client process knows the well-known port number of the
corresponding server process.
• For example, while the Daytime client process, discussed here, can use an
ephemeral (temporary) port number 52,000 to identify itself, the Daytime
server process must use the well-known (permanent) port number 13.
• Figure 23.2 shows this concept.

20.9
 Connectionless Versus Connection-Oriented Service
A transport layer protocol can either be connectionless or connection-oriented.

Connectionless Service and Unreliable Service – UDP (User Datagram

Protocol)
• In a connectionless service, the packets are sent from one party to another with
no need for connection establishment or connection release.
• The packets are not numbered
• They may be delayed or lost or may arrive out of sequence.
• There is no acknowledgment either.
• Ex: UDP

Connection-Oriented Service – TCP (Transmission Control Protocol), SCTP

• In a connection-oriented service, a connection is first established between the
sender and the receiver. Data are transferred. At the end, the connection is
released.
• Ex: TCP and SCTP (Stream Control Transmission Protocol)

20.10
 Reliable Versus Unreliable Transmission
Reliable Service
• The transport layer service can be reliable or unreliable.
• If the application layer program needs reliability, we use a reliable transport
layer protocol by implementing flow and error control at the transport layer.
• This means a slower and more complex service.

Unreliable Service
• If the application program does not need reliability because
• it uses its own flow and error control mechanism
• or it needs fast service
• or the nature of the service does not demand flow and error control (real-time
applications), then an unreliable protocol can be used.

20.11
 Error Control at Transport Layer
• If the data link layer is reliable and has flow and error control, do we need this at
the transport layer, too?
• The answer is yes.
• Reliability at the data link layer is between two nodes;
• We need reliability between two ends.
• Because the network layer in the Internet is unreliable (best-effort delivery), we
need to implement reliability at the transport layer.
• To understand that, error control at the data link layer does not guarantee error
control at the transport layer, let us look at Figure 23.7.

20.12
 Figure 23.7 Error control

23.13
 Three Protocols
• The original TCP/IP protocol suite specifies two protocols for the transport
layer:
• UDP and TCP.
• We first focus on UDP, the simpler of the two, before discussing TCP.
• A new transport layer protocol, SCTP, has also been designed.
• Figure 23.8 shows the position of these protocols in the TCP/IP protocol
suite.

20.14
 Figure 23.8 Position of UDP, TCP, and SCTP in TCP/IP suite

23.15
 23-2 USER DATAGRAM PROTOCOL (UDP)

The User Datagram Protocol (UDP) is called a

connectionless, unreliable transport protocol. It does
not add anything to the services of IP except to provide
process-to-process communication instead of host-to-
host communication.
Topics discussed in this section:
Well-Known Ports for UDP
User Datagram
UDP Operation
Use of UDP

23.16
 User Datagram Protocol
• The User Datagram Protocol (UDP) is called a connectionless, unreliable
transport protocol.
• It does not add anything to the services of IP except to provide process-to-
process communication instead of host-to-host communication.
• It performs very limited error checking.
• If UDP is so powerless, why would a process want to use it?
• UDP is a very simple protocol using a minimum of overhead.
• If a process wants to send a small message and does not care much about
reliability, it can use UDP.
• Sending a small message by using UDP takes much less interaction between
the sender and receiver than using TCP (Transmission control protocol)
or SCTP (Stream control transmission protocol).

20.17
 Table 23.1 Well-known ports used with UDP

23.18
 Figure 23.9 User datagram format

23.19
 User Datagram Format

UDP packets, called user datagrams, have a fixed-size header of 8 bytes.

The fields are as follows:

Source port number:

• This is the port number used by the process running on the source host.
• It is 16 bits long, which means that the port number can range from 0 to
• 65,535.
• If the source host is the client (a client sending a request), the port number
is an ephemeral port number requested by the process and chosen by the
UDP software running on the source host.
• If the source host is the server (a server sending a response), the port
number, is a well-known port number.

20.20
 User Datagram Format
Destination port number:
• This is the port number used by the process running on the destination
host.
• It is also 16 bits long.
• If the destination host is the server (a client sending a request), the port
number, in most cases, is a well-known port number.
• If the destination host is the client (a server sending a response), the port
• number, in most cases, is an ephemeral port number.
• In this case, the server copies the ephemeral port number it has received
in the request packet.

20.21
 User Datagram Format
Length:
• This is a 16-bit field that defines the total length of the user datagram,
header plus data.
• The 16 bits can define a total length of 0 to 65,535 bytes.
• The total length needs to be much less because a UDP user datagram is
stored in an IP datagram with a total length of 65,535 bytes.
• The length field in a UDP user datagram is actually not necessary. A user
datagram is encapsulated in an IP datagram.
• There is a field in the IP datagram that defines the total length.
• There is another field in the IP datagram that defines the length of the
header.
• So if we subtract the value of the second field from the
• first, we can deduce the length of a UDP datagram that is encapsulated in
an IP datagram.

Checksum:
• This field is used to detect errors over the entire user datagram.

20.22
 Note

UDP length
= IP length – IP header’s length

23.23
 UDP Operation
Connectionless Services:
• As mentioned previously, UDP provides a connectionless service.
• This means that each user datagram sent by UDP is an independent
datagram.
• There is no relationship between the different user datagrams even if they
are coming from the same source process and going to the same
destination program.
• The user datagrams are not numbered.
• Also, there is no connection establishment and no connection termination,
as is the case for TCP.
• This means that each user datagram can travel on a different path.
• Only those processes sending short messages should use UDP.

20.24
 UDP Operation
Flow and Error Control:
• UDP is a very simple, unreliable transport protocol. There is no flow
control and hence no window mechanism.
• The receiver may overflow with incoming messages.
• There is no error control mechanism in UDP except for the checksum.
This means that the sender does not know if a message has been lost or
duplicated.
• When the receiver detects an error through the checksum, the user
datagram is silently discarded.

Encapsulation and Decapsulation:

• To send a message from one process to another, the UDP protocol
encapsulates and decapsulates messages in an IP datagram.

20.25
 UDP Operation

Figure 23.12 Queues in UDP

23.26
 UDP Operation
Queuing :
• Client side –
• At the client site, when a process starts, it requests a port number from the
operating system.
• It creates both an incoming and an outgoing queue associated with each
process
• Even if a process wants to communicate with multiple processes, it
obtains only one port number and eventually one outgoing and one
incoming queue.
• The queues opened by the client are, in most cases, identified by
ephemeral port numbers.
• The queues function as long as the process is running.
• When the process terminates, the queues are destroyed.
• The client process can send messages to the outgoing queue by using the
source port number specified in the request.

20.27
 UDP Operation
Queuing : Client side – ….cntd
• UDP removes the messages one by one and, after adding the UDP header,
delivers them to IP.
• An outgoing queue can overflow.
• If this happens, the operating system can ask the client process to wait
before sending any more messages.
• When a message arrives for a client, UDP checks to see if an incoming
queue has been created for the port number specified in the destination
port number field of the user datagram.
• If there is such a queue, UDP sends the received user datagram to the end
of the queue.
• If there is no such queue, UDP discards the user datagram and asks the
ICMP protocol to send a port unreachable message to the server.
• All the incoming messages for one particular client program, whether
coming from the same or a different server, are sent to the same queue.
• If an incoming queue overflows, UDP drops the user datagram and asks
for a port unreachable message to be sent to the server.

20.28
 UDP Operation
Queuing :
• Server side –
• Server asks for incoming and outgoing queues, using its well-known port,
when it starts running.
• The queues remain open as long as the server is running.
• When a message arrives for a server, UDP checks to see if an incoming
queue has been created for the port number specified in the destination
port number field of the user datagram.
• If there is such a queue, UDP sends the received user datagram to the end
of the queue.
• If there is no such queue, UDP discards the user datagram and asks the
ICMP protocol to send a port unreachable message to the client.
• All the incoming messages for one particular server, whether coming
from the same or a different client, are sent to the same queue.

20.29
 UDP Operation
Queuing :
• Server side – ….cntd
• If an incoming queue overflows, UDP drops the user datagram and asks
for a port unreachable message to be sent to the client.
• When a server wants to respond to a client, it sends messages to the
outgoing queue, using the source port number specified in the request.
• UDP removes the messages one by one and after adding the UDP header,
delivers them to IP.
• If an outgoing queue overflows, the operating system asks the server to
wait before sending any more messages.

20.30
 Use of UDP
The following lists some uses of the UDP protocol:
• UDP is suitable for a process that requires simple request-response
communication with little concern for flow and error control.
• It is not usually used for a process such as FTP that needs to send bulk
data
• UDP is suitable for a process with internal flow and error control
mechanisms.
• For example, the Trivial File Transfer Protocol (TFTP) process includes
flow and error control. It can easily use UDP.
• UDP is a suitable transport protocol for multicasting.
• Multicasting capability is embedded in the UDP software but not in the
TCP software.
• UDP is used for management processes such as SNMP (Simple Network
Management Protocol).
• UDP is used for some route updating protocols such as Routing
Information Protocol (RIP)

20.31