Scribd Logo
Upload

Welcome to Scribd!

  • 21 views

    The User Datagram Protocol: Aleksander Malinowski Bogdan M. Wilamowski

    Uploaded by

    manu2020
    THE IIT HANDBOOK CH17

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content

    The User Datagram Protocol: Aleksander Malinowski Bogdan M. Wilamowski

    Uploaded by

    manu2020
    21 views5 pages
    THE IIT HANDBOOK CH17

    Original Title

    9854_c017

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    THE IIT HANDBOOK CH17

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    Download as pdf or txt
    21 views5 pages

    The User Datagram Protocol: Aleksander Malinowski Bogdan M. Wilamowski

    Uploaded by

    manu2020
    THE IIT HANDBOOK CH17

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    Download as pdf or txt
    of 5

    17

    The User Datagram Protocol


    Aleksander Malinowski
    Bradley University

    17.1 Introduction 17.2 Protocol Operation


    UDP Datagram Port Number Assignments Connectionless Service, Flow, and Error Control

    Bogdan M. Wilamowski
    Auburn University

    17.1 Introduction
    User Datagram Protocol (UDP) is a part of TCP/IP protocol suite. It provides full transport layer services to applications. It belongs to the transport layer in the OSI model as shown in Figure 17.1. UDP provides a connection between two processes at both ends of the transmission. This connection is provided with minimal overhead, without flow control or acknowledgement of received data. The minimal error control is provided by ignoring (dropping) received packets that fail the checksum test.

    17.2 Protocol Operation


    The underlying IP protocol facilitates data transport through the network between two hosts. UDP allows addressing particular processes at each host so that incoming data are handled by a particular application. Addressing the processes is implemented by assigning each connection to the network a number that is called a port number, Figure 17.2 illustrates the concept of port numbers and shows the difference between IP and UDP addressing. UDP packets are also called datagrams. Each datagram is characterized by four parameters: the IP address and the port number at each end of the connection. Certain classes of destination IP addresses may not describe individual computers but a group of processes on multiple hosts that are to receive the same datagram. This particular case of multicasting is described in another article entitled UDP multicasting routing. Although the term connection is used here, unlike in the case of Transmission Control Protocol (TCP), there is no persistent connection between the two processes. The data exchange may follow a certain pattern or protocol; but there is no guarantee that all data may reach the destination and that the order of their receiving would be the same as the order they were sent. The clientserver approach that is usually used to describe the interaction between two processes can still be used. The process that may be identified as waiting for the data exchange is called the server. The process that may be identified as one that initializes that exchange is called the client.

    UDP Datagram
    UDP datagrams have a constant size 8-byte header prepended to the transmitted data as shown in Figure 17.3. The meaning of each header field is described below.

    2005 by CRC Press LLC

    17-2

    The Industrial Information Technology Handbook

    Application layer SMTP FTP DNS SNMP BOOTP

    Transport layer TCP Network layer IGMP ICMP IP Data link layer Underlying LAN or WAN technology Physical layer ARP RARP UDP

    FIGURE 17.1 UDP and TCP/IP in the OSI model.

    Processes (Running application program)

    Processes (Running application program)

    Internet Domain of IP protocol Domain of UDP protocol

    FIGURE 17.2 Comparison of IP and UDP addressing.

    Source Port Address this is a 16-bit field that contains a port number of the process that sends options or data in this segment. Destination Port Address this is a 16-bit field that contains a port number of the process that is supposed to receive options or data carried by this segment. Total Length this is a 16-bit field that contains the total length of the packet. Although the number could be in the range from 0 to 65,535 the minimum length is 8 bytes, which correspond to the packet with the header and no data. The maximum length is 65,507 because 20 bytes are used by the IP header and 8 bytes are used by the UDP header. Thus, this information is redundant to the packet length stored in the IP header. Checksum this 16-bit field contains the checksum. The checksum is calculated by Initially filling it with 0s. Adding a pseudoheader with information from the IP protocol as illustrated in Figure 17.4. Treating the whole segment with the pseudoheader prepended as a stream of 16-bit numbers. If the number of bytes is odd, 0 is appended at the end. Adding all 16-bit numbers using 1s complements binary arithmetic. Complementing the result. This complemented result is inserted into the checksum field.

    2005 by CRC Press LLC

    The User Datagram Protocol

    17-3

    8 bytes

    Header

    Data

    Source port number 16 bits Total length 16 bits

    Destination port number 16 bits Checksum 16 bits

    FIGURE 17.3 User datagram format.

    Pseudoheader

    32-bit source IP address 32-bit destination IP address 8-bit protocol

    ALL 0s

    16-bit UDP total length

    Header

    Source port address 16 bits UDP total length 16 bits

    Destination port address 16 bits Checksum 16 bits

    Data (padding must be added to make the data a multiple of 16 bits)

    FIGURE 17.4 Pseudoheader added to the UDP datagram.

    Checksum verification the receiver calculates the new checksum for the received packet that includes the original checksum, after adding the so-called pseudoheader (see Figure 17.4). If the new checksum is nonzero, then the datagram is corrupt and is discarded. In case of UDP, the use of checksum is optional. If it is not calculated, then the field is filled with 0s. The receiver can determine whether checksum was calculated by inspecting the field. Even in case the checksum is 0, the field does not contain 0 as the calculated checksum is complemented at the end of the process, and negative 0 (the field filled with 1s) is stored.

    Port Number Assignments


    In order to provide platform-independent process addressing on a host, each connection of the process to the network is assigned a 16-bit number. There are three categories of port numbers: well-known (01023), registered (102449,151), and ephemeral (49,1526553). Well-known ports have been historically assigned to common services. Table 17.1 shows well-known ports commonly used by UDP. Some operating systems require that processes utilizing those ports must have administrative privileges. This requirement was historically created to prevent hackers from running server imposters on multi-user systems. Well-known ports

    2005 by CRC Press LLC

    17-4
    TABLE 17.1
    Port 7 9 11 13 17 19 37 53 67 68 69 111 123 161 162

    The Industrial Information Technology Handbook


    Well-known Ports Used with UDP
    Description Echoes a received datagram back to its sender Discards any datagram that is received Active users Returns the date and the time in ASCII string format Returns a quote of the day, ASCII string up to 512 characters Returns a string of characters of random length 0 to 512 characters Returns the current time in seconds since 1/1/1900 in a 32-bit format Domain Name Service Bootstrap Protocol Server Bootstrap Protocol Client Trivial File Transfer SUN Remote Procedure Call Network Time Protocol Simple Network Management Protocol Simple Network Management Protocol (trap) RFC/STD # STD20 STD21 STD24 STD25 STD23 STD22 STD26 STD13 RFC951 RFC951 STD33 RFC1831 STD12 STD62 STD62

    Protocol Echo Discard Users Daytime Quote Chargen Time Nameserver Bootps Bootpc TFTP RPC NTP SNMP SNMP

    are registered and controlled by Internet Assigned Numbers Authority (IANA). Registered ports are also registered by IANA to avoid possible conflicts among different applications attempting to use the same port for listening to incoming connections. Ephemeral ports are also called dynamic ports. These ports are used by outgoing connections that are typically assigned the first available port above 49,151. Some operating systems may not follow IANA recommendations and treat the registered ports range as ephemeral.

    Connectionless Service, Flow, and Error Control


    As already outlined, UDP provides connectionless communication. Each datagram is not related to another datagram coming earlier or later from the same source. The datagrams are not numbered. There is no need for establishing or tearing down the connection. In the extreme case, just one datagram might be sent in the process of data exchange between the two processes. UDP does not provide any flow control. The receiving side may overflow with incoming data. Unlike in TCP, which has a windowing mechanism, there is no way to control the sender. There is no error control other than the checksum discussed above. The sender cannot be requested to resend any datagram. However, an upper-level protocol that utilizes UDP may implement some kind of control. In that case, unlike in TCP, no data are repeated by resending the same datagram. Instead, the communicating process sends a request to send some information again. Trivial File Transfer Protocol (TFTP) is a very good example of that situation. Since it has its own higher level flow and error control, it can use UDP as a transport-layer protocol instead of TCP. Other examples of UDP utilization are Simple Network Management Protocol (SNMP) or any other protocol that requires only a simple short request-response communication.

    Additional Reading
    [1] Comer, D., Internetworking with TCP/IP Vol.1: Principles, Protocols, and Architecture, 4th ed., Prentice-Hall, Upper Saddle River, NJ, 2000. [2] Comer, D. et al., Internetworking with TCP/IP, Vol. III: Client-Server Programming and Applications, Linux/Posix Sockets Version, Prentice-Hall, Upper Saddle River, NJ, 2000. [3] Forouzan, B.A., TCP/IP Protocol Suite, 2nd ed., McGraw-Hill, New York, 2003. [4] Hall, E.A., Internet Core Protocols: The Definitive Reference, OReilly, Sebastopol, CA, 2000. [5] Leon-Garcia, A. and I/ Widjaja, Communication Networks, McGraw-Hill, New York, 2000. [6] Peterson, L.L. and B.S. Davie, Computer Networks: A System Approach, 2nd ed., Morgan Kaufmann Publishers, San Francisco, CA, 2000.

    2005 by CRC Press LLC

    The User Datagram Protocol

    17-5

    [7] RFC0768/STD0006, Postel, J., User Datagram Protocol, August 1980, http://www.rfc-editor.org/ [8] RFC1791, Sung, T., TCP And UDP Over IPX Networks With Fixed Path MTU, April 1995, http:// www.rfc-editor.org/ [9] RFC2675, Borman, D. et al., IPv6 Jumbograms, August 1999, http://www.rfc-editor.org/ [10] STD2, Reynolds, J. and J. Postel, Assigned Numbers, October 1994, http://www.rfc-editor.org/ [11] Web Site for IANA - Internet Assigned Numbers Authority, http://www.iana.org/ [12] Web Site for RFC Editor, http://www.rfc-editor.org/

    2005 by CRC Press LLC

    You might also like