Part 2.

UDP Principles (Chapter 24)

(User Datagram Protocol)
UDP: User Datagram Protocol
 In TCP/IP protocol suite, using IP to transport
datagram (similar to IP datagram).
 Allows a application to send datagram to
other application on the remote machine.
 Delivery and duplicate detection are not
guaranteed.
 Low overhead: faster than TCP
UDP Characteristics
 End-to-End: an application sends/receives data to/from
another application.
 Connectionless: Application does not need to preestablish
communication before sending data; application does not
need to terminate communication when finished.
 Message-oriented: application sends/receives individual
messages (UDP datagram), not packets.
 Best-effort: same best-effort delivery semantics as IP. I.e.
message can be lost, duplicated, and corrupted.
 Arbitrary interaction: application communicates with many
or one other applications.
 Operating system independent: identifying application
does not depend on O/S.
Identifying An Application
 UDP cannot extend IP address
 No unused bits
 Cannot use OS-dependent quantity
 Process ID, Task number, Job name
 Must work on all computer systems
 Technique
 Each application assigned unique integer
 Called protocol port number
Protocol Port Number
 UDP uses Port Number to identify an application
as an endpoint.
 UDP messages are delivered to the port specified
in the message by the sending application
 In general, a port can be used for any datagram,
as long as the sender and the receiver agrees
 In practice, a collection of well-known ports are
used for special purposes such as telnet, ftp, and
email. E.g. port 7 for Echo application.
 Local operating system provides an interface for
processes to specify and access a port.
Well-known Port Numbers
 list of UDP ports copied from /etc/services on Solaris
2.5:
UDP Multiplexing & Demultiplexing

 Sender: multiplexing of UDP datagrams.

 UDP datagrams are received from multiple application programs.

 A single sequence of UDP datagrams is passed to IP layer.

 Receiver: demultiplexing of UDP datagrams.

 Single sequence of UDP datagrams received from IP layer.

 UDP datagram received is passed to appropriate application.

UDP Datagram Format

 Source Port - 16 bit port number

 Destination Port - This is the port number used by the process running
on the destination host. It is also 16 bits long.
 Length (of UDP header + data) - 16 bit count of octets
 UDP checksum - 16 bit field. if 0, then there is no checksum, else it is a
checksum over a pseudo header + UDP data area
UDP Datagram Format

 Source Port - 16 bit port number

 Destination Port - 16 bit port number
 Length (of UDP header + data) - 16 bit count of octets
 UDP checksum - 16 bit field. if 0, then there is no checksum, else it is a
checksum over a pseudo header + UDP data area
Checksum and Pseudo 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.
 UDP uses a pseudo-header to verify that the UDP message has
arrived at both the correct machine and the correct port.

Proto : IP protocol type code. The protocol field is added to ensure that
the packet belongs to UDP(17), and not to other transport-layer protocols.
• Length : Length of the UDP datagram.
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.
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.
 The lack of flow control and error control means that the process using
UDP should provide these mechanisms.
Encapsulation and Layering

 UDP message is encapsulated into an IP datagram.

 IP datagram in turn is encapsulated into a physical
frame for actually delivery.
UDP Operation
 Queuing
 In UDP, queues are associated with ports.
 At the client site, when a process starts, it requests a port number from
the operating system.
 Some implementations create both an incoming and an outgoing
queue associated with each process.
 Note that 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 function as long as the process is running. When the
process terminates, the queues are destroyed.
UDP Operation
 Queuing
 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 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.
UDP Operation
 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.
 At the server site, the mechanism of creating queues is different.
 In its simplest form, 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.
RTP Protocol
 "Real-Time Transport Protocol“, it is situated in the session and presentation
layers of the OSI network model.
 It is typically used for real-time applications like internet radio, music-on-
demand, video-on-demand, and video conferencing where VOIP is employed.
 It uses the UDP protocol rather than TCP. As a result, it does not guarantee
quick data delivery and lacks delivery mechanisms such as multicasting and
port numbers.
 It provides support for various file types, such as MPEG and MJPEG.
Working of RTP Protocol
 The RTP protocol prioritizes the concatenation and merging of audio and video
over the integrity of the data being transmitted, which is based on several
actual protocols.
 The TCP/IP architecture utilizes the UDP protocol as one of these. There are a
number of restrictions when utilizing the UDP protocol to encapsulate RTP
packets, most significantly in error correction.
 As a result, any damaged or missing package is simply discarded.
 The UDP packets are transmitted to the IP, which sends them across the
Ethernet link.
 This entire procedure occurs at the sender's end, whereas the opposite
process occurs at the receiver's end. In the end, the multimedia app finally
obtains multimedia information from the RTP library.
RTP Header Format
RTP Header Format
 Version field: It defines the protocol version.
 Padded bits: The P bit specifies the padded bit that is utilized for the packet in
multiples of 4 bytes.
 Extension header: The length of this field is also 1 bit. If the value of this field
is 1, it indicates that there is an extra extension header between the data and
basic headers, and if the value is 0, there is no extra extension.
 Contributor Count : This 4-bit value represents the number of contributors.
Because a 4-bit field can accept numbers ranging from 0 to 15, the maximum
number of contributors is 15.
 Marker bit : M in the header defines the marker bit, which is utilized to indicate
a frame's start and end.
RTP Header Format
 Payload types: This field is 7 bits long and shows the type of payload. You
may present some popular sorts of payload applications.
 Sequence Number: It indicates the quantity of RTP packets transmitted and
grows by one value each time a packet is transmitted.
 Timestamp: It has a length of 32 bits. It is utilized to determine the relationship
between the timings of various RTP packets. The timestamp for the first packet
is chosen at random, and the time stamp for subsequent packets is determined
by adding the previous timestamp to the time required to produce the first byte
of the current packet.
RTP Header Format
 Synchronization Source Identifier : It describes the packet and the stream
with which it is related.
 Contributing Source Identifier: It is also a 32-bit variable that is utilized for :
source identification when many sources are present in the session.
 The mixer source is identified by the Synchronization source identity, while the
Contributor identification identifies the remaining sources (up to 15).
RTCP
 RTCP is an abbreviation for "Real-time Transport Control Protocol". It is the
counterpart protocol of the RTP protocol and is described alongside RTP.
 It is an essential component of the RTP protocol that provides RTP with control
features, including synchronization, feedback, and user interface (UI).
 The RTCP protocol allows senders and receivers to exchange a series of
reports, including additional detail about the data being sent and the network's
performance.
 RTCP messages are also contained inside a UDP packet for transmission and
are transmitted with a protocol number which is higher than the RTP streamed
port number with which they are linked.
RTCP Packet Types
1. SR (Sender Report)
 At a predetermined interval, the active sender in a conference delivers a
sender report to report transmission and reception statistics for all RTP packets
transmitted during the time period.
 The sender's report includes an absolute time stamp, which indicates how
many seconds have passed since midnight on January 1, 1970. When the
receiver receives RTP packets, this information about absolute timestamps
aids the synchronization process. It is complex in audio-video transmission for
determining the relative timestamp.
RTCP Packet Types
2. RR (Receiver Report)

Non-active senders are in charge of creating receiver reports, which contain data
delivery reception quality comments. It stores information such as the greatest
packet number received, inter-arrival jitter, number of dropped packets, and
round-trip delay between sender and receiver using timestamps.

3. SDES (Source Description Items)

 The source sends a source description message at a predetermined period to
provide further information about itself. It includes information such as the
source's identity, email address, phone number, and source controller.

4. Bye Message
 To terminate a stream, a source sends a message known as a Bye message.
The source uses it to announce his intention to leave the conference. This
message informs other sources directly of the absence of a source.
RTCP Packet Types
5. APP (Application-Specific Message)
 It is just to be used for experimental purposes and newly emerging features
and functions.
Differences between RTP & RTCP