User Datagram Protocol

nullpitNetworking and Communications

Oct 23, 2013 (3 years and 9 months ago)

63 views



Mälardalen University

Department of Computer Science and Electronics

Västerås









User Datagram Protocol




HW/SW System Design of Embedded Systems,

CT3800, Västerås, 2006
-
02
-
13


Johan Åkerberg





















Abstract
:
This paper presents the User

Datagram Protocol, UDP, and a brief introduction to
the Internet Protocol Suite. Since many types of application don’t need all features as the full
fledged TCP protocol has, UDP is a good candidate in such applications, like distributed
systems, soft rea
l
-
time systems and embedded systems. The introduction of Ethernet based
communication with embedded systems are a fact today, but how to implement it in an
embedded system with limited resources and computational power? With the ease of today’s
tools for F
PGA’s and One Chip Systems, alternative solutions are feasible compared to
traditional software implementations. Embedded systems implement protocol stacks
completely or partially in hardware today to achieve the same as throughput as more powerful
compute
rs.



Contents

BACKGROUND
................................
................................
................................
................................
................................
......

1

UDP PROTOCOL
................................
................................
................................
................................
................................
...

1

O
PEN
S
YSTEM
I
NTERCONNECTION
R
EFERENCE
M
ODEL
................................
................................
................................
.

1

C
ONNECTION AND
C
ONNECTIONLESS
C
OMMUNICATION

................................
................................
...............................

2

M
ESSAGE AND
S
TREAM ORIENTED
C
OMMUNICATION

................................
................................
................................
....

2

TCP/IP

STACK

................................
................................
................................
................................
................................
.......

2

UDP

P
ROTOCOL

................................
................................
................................
................................
................................
....

3

UDP Segment Structure
................................
................................
................................
................................
.................

4

UDP Checksum calculation

................................
................................
................................
................................
..........

5

CONCLUSIONS
................................
................................
................................
................................
................................
......

6

REFERENCES

................................
................................
................................
................................
................................
........

6



1

BACKGR
OUND

Most of today’s embedded systems need to communicate with other equipment to solve a
bigger task, or only to display information at a single remote node’s user interface. The
requirements are very different depending on the applications, from distribu
ted soft real
-
time
systems to a non real
-
time node with an inbuilt web
-
server for configuration and monitoring.
In this report an overview of the Open System Interconnection reference model and the
Internet Protocol Suite will be presented, also know as th
e TCP/IP Protocol Suite. The User
Datagram Protocol, UDP, will be presented and where it’s located in the protocol stack and
what purposes it serves.


The commercial use of Ethernet based communication in embedded systems is a fact today.
So how can such a
n embedded system with limited resources and computational power be
implemented to achieve desired throughput? Some solutions will be introduced to increase the
communication throughput by means of moving software to hardware.

UDP PROTOCOL

Open System Int
erconnection Reference Model

The OSI model is based on a proposal by the International Standards Organization (ISO) as a
first step towards international standardization of protocols. However, this is not how the OSI
model is used today, it is used as a mo
del to compare and describe protocols and even a good
design structure for implementation. Note that the OSI model itself is not a network
architecture because it doesn’t specify the exact services and protocols to be used in each
layer. The common name “p
rotocol stack” is derived from this model, where the layers are
“stacked” upon each other’s.



Figure
1
, The OSI model


Each layer should

perform a well
-
defined function and the layer boundaries should be chosen
to minimize the information flow between the interfaces. The number of layers should be
large enough so that two distinct functions are not thrown together in the same layer and the
re
shall not be too many layers, making the design a mess. Each layer defines a protocol, a set of
rules, to be able to communicate with the corresponding layer on another node. The
communication between corresponding layers is done by using interfaces fro
m adjacent
layers.



2


Figure
2
, Communication amongst the layers.


Since the topic of this report is not a complete protocol stack, but on
ly a simple protocol
inside a layer we will not discuss the OSI model any further. We have now the background
necessary to continue study the TCP/IP (Transmission Control Protocol/Internet Protocol)
stacks and finally the UDP protocol in detail.

Connection

and Connectionless Communication

The connection
-
oriented service is modeled after the telephone system. To be able to talk to
someone you must pick up the phone, dial the number, and wait for the receiver to answer,
talk and hang up. Connection oriented c
ommunication works in the same way; establish
connection, use the connection and finally release the connection. In most cases the order is
preserved so that the bits are received just as they were sent.


In contrast, the connectionless communication is mo
deled after the postal system. Each
message (letter) carries the full destination address and is routed through the system
independent of all others. As with the postal system, there is no guarantee that the first
message sent will reach its destination fi
rst.

Message and Stream oriented Communication

In message oriented communication the message boundaries are preserved. If two messages
with 1024 bytes each are send, there is no way one message of 2048 bytes could be received,
they always arrive as two dis
tinct 1024 bytes messages.


When a 2048 bytes arrive at the receiver when stream oriented communication is used, there
is no way to find out if it was send as one 2048 byte message, two 1024 bytes message or
even 2048 one byte messages. Simply message boun
daries are not preserved.

TCP/IP stack

There are many names for the TCP/IP stack, basically since it’s built of many parallel paths
through the stack. The name TCP/IP is derived due to the fact that TCP and IP are the most
common protocols used in the TCP/
IP protocol suite or Internet protocol suite for that matter.


We will only study the Network and Transport layer in this section, since the Data Link and
Physical layer are dependent of the communication media/standard, for example modem or
Ethernet and i
s not important when presenting UDP.


The Network layer is responsible of delivering messages from the source address to the
destination address. In the TCP/IP suite it’s the Internet Protocol (IP) that is responsible for
this. The IP protocol will find a
possible path to the receiving node, even if the node is not

3

directly connected to the sending node. The messages will be routed through as many nodes
as needed to find a routing path to the receiving node.


At the Transport Layer, there are two protocols
, TCP and UDP. Those two protocols are used
independent of each other. The TCP protocol is connection
-

and stream oriented, you have to
establish communication before any data can be sent and received. The TCP protocol
preserves the order of data as it was

sent and also makes sure that all data send are reached at
the destination node. TCP also handles flow control and error handling. This is useful for
sending large files, but not very good if you send data that has a limited time before it’s
useless. Then

you want the newly produced data to be sent and used before the old one will be
received. For example web cameras sending images periodically, then you don’t want to wait
for a lost image to arrive, which can take quite long time, just take the next one i
nstead. To
handle such applications, the TCP/IP protocol suite provides the UDP protocol.


See figure below for a complete overview of the Internet Protocol suite. It’s added for
information and will not be studied anymore in this paper.



Figure
3
, the TCP/IP stack and applications

UDP Protocol

In contrast to the TCP protocol, which handles all possible scenarios in the communication,
the TCP/
IP stack provides the lightweight protocol UDP. The UDP protocol gives the
application a higher degree of freedom, since it’s up to the application to handle all possible
scenarios in a suitable way.


The UDP protocol is connectionless and message oriented

and assumes that the IP protocol is
used as the underlying protocol. UDP provides a way for applications to send messages to
other applications with a minimum of protocol mechanism. The protocol is transaction
(message) oriented and delivery and protectio
n are not guaranteed. Applications requiring
reliable delivery of streams of data should use TCP. To be able to only pass messages those
are of interest to an application, the Transport layer needs something to identify what
messages should be delivered to

what application. In UDP, and in TCP for that matter, ports
are introduced. Then the transport layer can (de)multiplex all messages between the network
layer and the correct application. There are many “well
-
known ports”, that should not be used
for any o
ther purpose (FTP = 20, HTTP = 80 and SSH = 22). When designing own

4

applications make sure you don’t use these well
-
known ports. Normally very high port
numbers can be used for own applications.



Figure
4
, Demultiplexing based on ports.


Now you might wonder why an application developer would ever choose to build an
application over UDP rather than over TCP. Isn't TCP always preferable to UDP since T
CP
provides a reliable data transfer service and UDP does not? The answer is no, as many
applications are better suited for UDP for the following reasons:




No connection establishment.

TCP uses a three
-
way handshake before it starts to
transfer data. UDP j
ust goes ahead and sends data, thus UDP doesn’t introduce any
delay to establish a connection. This is probably the principle reason why DNS runs
over UDP rather than TCP. DNS would be much slower if it ran over TCP.



No connection state.

TCP maintains conn
ection state in the end systems. This state
includes receive and send buffers, congestion control parameters, and sequence and
acknowledgement number parameters. UDP does not maintain connection state and
doesn’t have such parameters. For this reason, a se
rver devoted to a particular
application can typically support many more active clients when the application runs
over UDP rather than TCP.



Small segment header overhead.

The TCP segment has 20 bytes of header overhead
in every segment, whereas UDP only ha
s 8 bytes of overhead.



Unregulated send rate.

TCP has a congestion control mechanism that throttles the
sender when one or more links between sender and receiver becomes congested. This
throttling can have a severe impact on real
-
time applications, which c
an tolerate some
packet loss but require minimum send rate. On the other hand, the speed at which
UDP send data is only constrained by the rate at which the application generates data,
the capabilities of the source (CPU, clock rate, etc.) and the access b
andwidth to
network.


Also UDP is most suitable when working with distributed systems, since UDP is message
oriented which is most suitable when working with transactions, i.e. RPC’s.

UDP Segment Structure

As mentioned earlier a message oriented communicat
ion protocol should carry all information
that is needed to deliver the message at the receiver in each message. UDP is a very simple
protocol thus only source and destination ports and the length are needed. For extra safety
measure a simple checksum is a
lso added.


5

In theory you can send messages that are 65535 bytes long, but many stack implementations
has limitations as low as 1024 bytes (embedded systems). Consult you stack documentation
for details.


Figure
5
, UDP segment structure


Source Port

is an optional field, when meaningful, it indicates the port of the
sending process, and may be assumed to be the port to which a
reply should
be addressed in the absence of any other information.
If not used, a value of zero is inserted.


Destination Port

has a meaning within the context of a particular Internet
destination address.


Length

is the length in octets of this user datagram includin
g this header
and the data. (This means the minimum value of the length is
eight.)


Checksum

is the 16
-
bit one's complement of the one's complement sum of a
pseudo header of information from the IP header, the UDP header,
and the data, padded with zero oct
ets at the end (if necessary) to
make a multiple of two octets.

UDP Checksum calculation

The pseudo header is only used for calculation of the UDP checksum and contains the source
address, the destination address, the protocol and the UDP length. This info
rmation gives
protection against misrouted datagram’s. This checksum procedure is the same as is used in
TCP.



Figure
6
, Pseudo header for checksum calculation.


UDP at the sender side performs the one's complement of the sum of a
ll the 16
-
bit words in
the

pseudo header. This result is put in the checksum field of the UDP header. When the
datagram arrives (if it arrives!) at the receiving host, all 16
-
bit words are added together,

6

including the checksum. If

this sum equals 0xffff,
then the segment has no detected errors. If
one of the bits is a zero, then we know that errors have been introduced into the datagram.


This is protocol 17 when used with the Internet Protocol. Other protocol numbers are listed in
[RFC762].

CONCLUSIONS

Th
e UDP protocol is a very simple protocol that enables the application designer to almost
use the Internet Protocol directly. Since many types of application don’t need all features as
the full fledged TCP protocol has, UDP is a good candidate in such appli
cations, like
distributed systems, soft real
-
time systems and embedded systems.


When implementing TCP/IP in embedded systems that doesn’t have the CPU power as
desktops or servers have they need hardware acceleration to achieve same throughput as more
pow
erful machines. Due to the nature of the stacked architecture, many layers can be
implemented independently in hardware and in software. To start with hardware acceleration
without implementing complete layers in hardware, some computational heavy tasks li
ke
checksum calculation can be moved to hardware for a real performance boost. Later on
complete layers can be moved to hardware, like for example the UDP protocol. Since the
UDP protocol itself rely on the IP protocol, which is a very complex layer, the m
ost
performance gain would be achieved if moving the IP layer to hardware.


The TCP/IP stack is implemented on many embedded systems today both in hardware and in
software.

REFERENCES

[RFC762]

J. Postel, ”Assigned Numbers”,
http://www.ietf.org/rfc/rfc762.txt
,
1980

[RFC768]

J. Postel, “User Datagram Protocol”,
http://www.ietf.org/rfc/rfc768.txt

, 1980

[RFC1071]

R. Braden, D. Borman, C. Partridge, ”Computing The Internet
Checksum”,
http://www.ietf.org/rfc/rf
c1071.txt
, 1988

[Tanenbaum02]

Andrew S Tanenbaum, Maarten van Steen, “Distributed Systems,
Principles and Paradigms”, ISBN 0
-
13
-
121786
-
0, Prentice
-
Hall
Inc, 2002

[Tanenbaum03]

Andrew S Tanenbaum, “Computer Networks”, Fourth Edition,
ISBN 0
-
13
-
038488
-
7, Pre
ntice
-
Hall Inc, 2003