UDP

UDP
• The Internet protocol suite supports a connectionless transport
protocol, UDP (User Datagram Protocol).
• UDP is located in transport layer, and serves as the intermediary
between the application programs and the network operations.
• UDP provides a way for applications to send encapsulated IP
datagrams and send them without having to establish a connection.
• UDP is a connectionless, unreliable transport protocol.
• UDP is described in RFC 768.
UDP
UDP
• Services Provided by Transport Layer:
• Process-to-Process Communication
• Ordered Packet Delivery
• Flow Control
• Error Control
• Congestion Control
• From the above tasks, UDP performs only the responsibility of Process-to-Process
Communication. UDP, however, does provide error control to some extent
• 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 using UDP takes much less interaction between the sender and receiver than
using TCP.
UDP
UDP
• 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, in most
cases, 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, in
most cases, is a well-known port number.
UDP
• 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.
UDP
• 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.
• However, the total length needs to be much less because a UDP user datagram is
stored in an IP datagram with the 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.
• Checksum
• This field is used to detect errors over the entire user datagram (header plus data).
UDP
• The following is a dump of a UDP header in hexadecimal format.
CB84000D001C001C
a) What is the source port number?
b) What is the destination port number?
c) What is the total length of the user datagram?
d) What is the length of the data?
e) Is the packet directed from a client to a server or vice versa?
f) What is the client process?
UDP
a) The source port number is the first four hexadecimal digits (CB84)16, which
means that the source port number is 52100.
b) The destination port number is the second four hexadecimal digits (000D) 16,
which means that the destination port number is 13.
c) The third four hexadecimal digits (001C)16 define the length of the whole UDP
packet as 28 bytes.
d) The length of the data is the length of the whole packet minus the length of the
header, or 28 – 8 = 20 bytes.
e) Since the destination port number is 13 (well-known port), the packet is from
the client to the server.
f) The client process is the Daytime
Process-to-Process Communication
• The transport-layer is responsible to provide process-to-process communication.
• A process is an application-layer entity (running program) that uses the services of
the transport layer.
• The network layer is responsible for communication at the computer level (host-
to-host communication).
• A network layer protocol can deliver the message only to the destination computer.
However, this is an incomplete delivery.
• The message still needs to be handed to the correct process.
• This is where a transport layer protocol takes over. A transport layer protocol is
responsible for delivery of the message to the appropriate process.
Process-to-Process Communication
Process-to-Process Communication
• UDP provides process-to-process communication using sockets, a combination of
IP addresses and port numbers.
Process-to-Process Communication
• The combination of an IP address and a port number is called a socket address.
• The client socket address defines the client process uniquely just as the server
socket address defines the server process uniquely.
• To use the services of transport layer in the Internet, we need a pair of socket
addresses: the client socket address and the server socket address.
• These four pieces of information are part of the network-layer packet header and
the transport-layer packet header.
• The first header contains the IP addresses; the second header contains the port
numbers.
Process-to-Process Communication:
Encapsulation
• When a process has a message to send through UDP, it passes the message
to UDP along with a pair of socket addresses and the length of data.
• UDP receives the data and adds the UDP header.
• UDP then passes the user datagram to IP with the socket addresses.
• IP adds its own header, using the value 17 in the protocol field, indicating
that the data has come from the UDP protocol.
• The IP datagram is then passed to the data link layer.
• The data link layer receives the IP datagram, adds its own header (and
possibly a trailer), and passes it to the physical layer.
• The physical layer encodes the bits into electrical or optical signals and
sends it to the remote machine.
Process-to-Process Communication:
Decapsulation
• When the message arrives at the destination host, the physical layer decodes the
signals into bits and passes it to the data link layer.
• The data link layer uses the header (and the trailer) to check the data.
• If there is no error, the header and trailer are dropped and the datagram is passed
to IP.
• The IP does its own checking.
• If there is no error, the header is dropped and the user datagram is passed to UDP
with the sender and receiver IP addresses.
• UDP uses the checksum to check the entire user datagram.
• If there is no error, the header is dropped and the application data along with the
sender socket address is passed to the process.
• The sender socket address is passed to the process in case it needs to respond to
the message received.
Process-to-Process Communication:
Encapsulation & Decapsulation
Process-to-Process Communication: Queuing
(at client site)
• When a process starts, it requests a port number from the operating system.
• 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.
• UDP removes the messages one by one from the queue, 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.
Process-to-Process Communication: Queuing
(at client site)
• 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 of the incoming messages for one particular client program, whether coming
from the same or a different server, are sent to the same queue.
• An incoming queue can overflow. If this happens, UDP drops the user datagram
and asks for a port unreachable message to be sent to the server.
Process-to-Process Communication: Queuing
Process-to-Process Communication: Queuing
(At the server site)
• The mechanism of creating queues is simple. A 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 of the incoming messages for one particular server, whether coming from the
same or a different client, are sent to the same queue.
Process-to-Process Communication: Queuing
(At the server site)
• An incoming queue can overflow. If this happens, 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.
• An outgoing queue can overflow. If this happens, the operating system asks the
server to wait before sending any more messages.
Connectionless Services
• 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.
Connectionless Services
• The source process (application program) needs to divide its message into chunks
of data of the size acceptable by the transport layer and deliver them to the
transport layer one by one.
• The transport layer treats each chunk as a single unit without any relation between
the chunks.
• When a chunk arrives from the application layer, the transport layer encapsulates
it in a packet and sends it.
• To show the independency of packets, assume that a client process has three
chunks of messages to send a server process (see figure on next slide).
• The chunks are handed over to the connectionless transport protocol in order.
However, since there is no dependency between the packets at the transport layer,
the packets may arrive out of order at the destination and will be delivered out of
order to the server process.
 Connectionless Services
• three chunks of messages are
delivered to the client
transport layer in order (1, 2,
and 3).
• Because of the extra delay in
transportation of the second
packet, the delivery of
messages at the server is not
in order (1, 3, 2).
• If these three chunks of data
belong to the same message,
the server process may have
received a strange message.
Connectionless Services
• The situation would be worse if one of the packets were lost.
• Since there is no numbering on the packets, the receiving transport layer has no
idea that one of the messages has been lost.
• It just delivers two chunks of data to the server process.
• The above two problems arise from the fact that the two transport layers do not
coordinate with each other.
• The receiving transport layer does not know when the first packet will come nor
when all of the packets have arrived.
Connectionless Services
• One of the ramifications of being connectionless is that the process that uses UDP
cannot send a stream of data to UDP and expect UDP to chop them into different
related user datagrams.
• Instead each request must be small enough to fit into one user datagram.
• Only those processes sending short messages, messages less than 65,507 bytes
(65,535 minus 8 bytes for the UDP header and minus 20 bytes for the IP header),
can use UDP.
Checksum
• The checksum in UDP is an optional error-detection mechanism.
• It ensures that the data within the UDP segment (header + payload) hasn't been
corrupted during transmission.
• The checksum value is computed by taking the 16-bit one's complement of the
one's complement sum of the UDP header, data, and a pseudo-header (which
includes fields from the IP header).
• The pseudoheader is the part of the header of the IP packet in which the user
datagram is to be encapsulated with some fields filled with 0s.
• If the checksum does not include the pseudoheader, a user datagram may arrive
safe and sound.
Checksum
Checksum
• UDP checksum for a message from a sender (192.168.1.1) to a receiver
(192.168.1.2).
• Suppose the following header and data are transmitted:
• Source IP: 192.168.1.1
• Destination IP: 192.168.1.2
• Source Port: 54321 (0xD431)
• Destination Port: 80 (0x0050)
• UDP Length: 8 bytes (header) + 4 bytes (data) = 12 bytes (0x000C)
Checksum
• UDP Header (before checksum):
• Source Port: D431
• Destination Port: 0050
• Length: 000C
• Checksum: 0000 (to be computed)
• UDP Data (message): 48656C6C
• Pseudo-header:
• Source IP Address: C0A80101 (192.168.1.1)
• Destination IP Address: C0A80102 (192.168.1.2)
• Protocol: 0011 (UDP's protocol number is 17, 0x11 in hex)
• UDP Length: 000C
Checksum
• Step 1:
• Pseudo-header:
• Source IP: C0A8 0101
• Destination IP: C0A8 0102
• Protocol: 0011
• Length: 000C
• Summing these 16-bit words gives: C0A8 + 0101 + C0A8 + 0102 + 0011 + 000C
= 18370
• Handle the carry: 8370+1=8371
Checksum
• Step 2:
• UDP Header and Data:
• Source Port: D431
• Destination Port: 0050
• Length: 000C
• Checksum: 0000 (ignore for now)
• Data (in hex): 4865 6C6C
• Summing these 16-bit words gives: D431 + 0050 + 000C + 4865 + 6C6C = 1895E
• Handle the Carry: 895E+1=895F
Checksum
• Step 3: Total Sum= Summation of both headers= 8371+895F=10CD0
• Handle the carry: 0CD0+1=0CD1 (0000 1100 1101 0001)
• Step 4: 1’s Complement of 0CD1= F32E (computed Checksum)
• The computed is inserted in the UDP header and sent along with the segment.
• Upon the receipt, the receiver calculates the checksum over the same fields
(including transmitted Checksum)
• If the result is 0xFFFF,the datagram is considered valid
Checksum
• Verification of Datagram on receiver side
• Summation of Pseudo-header: 8371
• Summation of UDP Header and Data :
• Source Port: D431
• Destination Port: 0050
• Length: 000C
• Checksum: F32E
• Data (in hex): 4865 6C6C
• Summing these 16-bit words gives: D431 + 0050 + 000C + F32E + 4865 + 6C6C
= 27C8C= 7C8C+2= 7C8E
• Total Sum= Summation of both headers= 8371+7C8E=FFFF (No error in
Transmission)