User Datagram Protocol (UDP)

The User Datagram Protocol (UDP) is a connectionless protocol on the Transport layer of the
OSI model. The overall structure of UDP is simpler than TCP, because UDP is connectionless
and therefore does not have overhead to maintain connection information. UDP is commonly used for real-time applications such as video and voice. In these time-sensitive applications,
when a packet is lost or corrupted there is not enough time for the applications to recognize that
a packet is missing and request that it be resent, and for this retransmitted packet to arrive.
Therefore, the overhead that comes with TCP is not warranted for this type of data transfer.
The following frame snippet was taken using EtherPeek and is of a DNS request:
UDP - User Datagram Protocol
Source Port: 1213
Destination Port: 53 domain
Length: 38
Checksum: 0xBFBA
As you can see, all of the overhead that is associated with the connection-oriented nature of
the TCP frame, such as sequence and acknowledgment number, has been removed in UDP. As
a result, the UDP packet is condensed down to four fields.
The first two of these fields, Source Port and Destination Port, are both 16 bits long. The
Destination Port field must be filled in with the destination port of the service that is being
requested; however, the Source Port field only needs a value when the sending station needs
a reply from the receiver. When the conversation is unidirectional and the source port is not
used, this field should be set to 0. When a reply is needed, the receiving station will reply to the
sender on the port indicated in the original packet’s source field.
The last two fields in a UDP header are Length and Checksum. Like the source and destination
port information, the length and checksum are both 16 bits long. The Length field shows the total
number of bytes in the UDP packet, including the UDP header and user data. Checksum, though
optional, allows the receiving station to verify the integrity of the UDP header as well as the data
that is contained in the packet. If Checksum is not used, it should be set to a value of 0.


A great deal of information is covered in this chapter, with the focus on Network and Data Link
layer protocols. It is important to understand this information in order to facilitate your troubleshooting
efforts. If you do not sufficiently understand the protocols present in layers 2 and 3 of
the OSI model, you should study them in depth. The majority of networking problems occur in
these two layers.
Many encapsulation types are available at the second layer of the OSI model. The ones
discussed in this chapter were Ethernet, PPP, SDLC, Frame Relay, and ISDN. Each has its
own strengths and weaknesses that make it better suited for a particular installation.
There are two major protocol classifications: connection-oriented and connectionless.
Connection-oriented protocols allow for sequenced data transfer, flow control, and error
control. Examples of connection-oriented protocols include ATM and TCP. Connectionless
protocols require less overhead; however, they do so at the expense of the sequenced data
transfer and the error and flow control offered by connection-oriented protocols. The connectionless
protocol discussed in this chapter is UDP.


Know the differences between connectionless and connection-oriented protocols. Connectionoriented
protocols have flow-control and error-checking methodologies that are not present in
connectionless protocols. Connectionless protocols offer better performance characteristics for
real-time voice and video applications.
Know the Data Link protocols and technologies. The major technologies covered in this
section include Ethernet, PPP, SDLC (HDLC), Frame Relay, and ISDN.
Know how to calculate subnet masks. Understand how VLSM functions, and know how to
determine an appropriate address and subnet mask combination. 1122

Transmission Control Protocol (TCP)

The Transmission Control Protocol (TCP), a connection-oriented protocol on the Transport
layer that provides reliable delivery of data, is an integral part of the IP suite. Look at the structure
of the TCP packet. The following EtherPeek frame was taken during a POP3 transaction:
TCP - Transmission Control Protocol
Source Port: 110 POP3
Destination Port: 1097
Sequence Number: 997270908
Ack Number: 7149472
Offset: 5
Reserved: 0000
Code: %010000
Ack is valid
Window: 8760
Checksum: 0x8064
Urgent Pointer: 0
No TCP Options
No More POP Command or Reply Data
Extra bytes (Padding):
UUUUUU 55 55 55 55 55 55
Frame Check Sequence: 0x04020000

This structure is similar to the IP packet structure. The TCP header is 32 bits long and has a
minimum length of five fields, but can be six fields deep when options are specified. The first layer
starts with the Source Port and Destination Port fields. Each of these fields is 16 bits long.
A Sequence Number field occupies the entire second layer, meaning that it is 32 bits long.
TCP is a connection-oriented protocol, and this field is used to keep track of the various requests
that have been sent.
The third layer is a 32-bit length field containing the acknowledgment sequence number that
is used to track responses.
The fourth layer begins with the Offset field, which is four bits and specifies the number of
32-bit words present in the header. Six bits are reserved for future use (this is called the Reserved
field). This field follows the Offset field.
The next field, called the Flag or Code field, is also a six-bit field, and it contains control
information. Look at Table 36.6 for an explanation of the six bits within the Flag field.
The Window field specifies the buffer size for incoming data. Once the buffer is filled, the
sending system must wait for a response from the receiving system. This field is 16 bits long.
Layer 5 of the TCP header begins with the Checksum parameter, which also occupies 16 bits.
It is used to verify the integrity of the transmitted data.
The Urgent Pointer field references the last byte of data, so the receiver knows how much
urgent data it will receive. This is also a 16-bit field.
Finally, there is the Option field, which must also be 32 bits long. If the options do not
occupy 32 bits, padding is added to reach the correct length.

Internet Control Message Protocol (ICMP)

The Internet Control Message Protocol (ICMP) is used throughout IP networks. ICMP was
designed to provide routing-failure information to the source system. This protocol provides
four types of feedback that are used to make the IP routing environment more efficient:
Reachability This is determined by using ICMP echo and reply messages.
Redirects These messages tell hosts to redirect traffic or choose alternative routes.
Timeouts These messages indicate that a packet’s designated TTL is expired.
Router Discovery These messages discover directly connected routers’ IP addresses. Router
discovery actually uses the ICMP Router Discovery Protocol to do this. This passive method
gathers directly connected IP addresses without having to understand specific routing protocols.
Here is a look at a couple of ICMP packets (echo request and reply):
ICMP - Internet Control Messages Protocol
ICMP Type: 8 Echo Request
Code: 0
Checksum: 0x495c
Identifier: 0x0200

Sequence Number: 512
ICMP Data Area:
abcdefghijklmnop 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
qrstuvwabcdefghi 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
Frame Check Sequence: 0x342e3235
ICMP - Internet Control Messages Protocol
ICMP Type: 0 Echo Reply
Code: 0
Checksum: 0x515c
Identifier: 0x0200
Sequence Number: 512
ICMP Data Area:
abcdefghijklmnop 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
qrstuvwabcdefghi 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
Frame Check Sequence: 0x342e3235
The ICMP structure is similar to the IP structure in that it has a type, checksum, identifier,
and sequence number. The field names differ a little but have the same functionality.