05 TG7020XEN02GLA1 App Transport Layer

Appendix - The Transport Layer
Contents
1 Transport Layer Protocols 3
1.1 Introduction to the Transport Layer Protocols 4
1.2 Ports and Sockets 6
2 Transmission Control Protocol (TCP) 11
2.1 TCP Properties 12
2.2 TCP Header and Segment Format 16
2.3 TCP Connections 20
2.4 TCP Options 42
3 User Datagram Protocol (UDP) 45
3.1 UDP Properties 46
3.2 UDP Header and Datagram Format 56
4 Exercises 59
5 Solutions 75
TG7020XEN02GLA1
2009 Nokia Siemens Networks
1
TG7020XEN02GLA1
2 2009 Nokia Siemens Networks
1 Transport Layer Protocols
Fig. 1
TG7020XEN02GLA1
3
1.1 Introduction to the Transport Layer Protocols

General
Application protocols do not communicate with IP directly, but instead talk to one of
two transport protocols: Transmission Control Protocol (TCP) or User Datagram
Protocol (UDP). In turn these transport protocols pass data to IP, which encapsulates
the data into IP packets that get sent over the network. In essence the transport
protocols hide the network from the application protocols so that they do not have to
deal with packet sizing and other issues, while also shielding the network from having
to multiplex the application protocol traffic (a task that IP can leave to the transport
protocols).
Multiplexing Services
For example, both UDP and TCP provide a multiplexing service to application
protocols by way of application-specific port numbers. Essentially, port numbers act
as virtual post office boxes for messages to be delivered to within a single host,
allowing multiple applications to run on a single host concurrently. When packets
arrive at destination system, they are handed off to the transport protocol specified in
the packet, which then delivers the transport-specific message data to the port
number specified in the header of the message. In this manner, many different
applications can run on the same host, using different port numbers to identify
themselves to the transport protocols.
TCP and UDP Properties

The transport protocol that an application protocol uses is determined by the kinds of
network and application-management services that are required. TCP is a reliable,
connection-oriented transport protocol, providing error-correction and flow control
services that can compensate for IP's unreliable services. Conversely, UDP is an
unreliable, message-centric transport protocol that offers little functionality over IP
alone. There are many applications that need to use one of these models or the
other, and only a few applications that use both of them.
Both, TCP and UDP provide functionality that is above that offered by IP alone, and
both protocols are required to build an effective set of network applications.
TG7020XEN02GLA1
Transport Layer Protocols

Ports
Ports are
are
used
used to
to address
address
an
an application
application
Mechanisms
Mechanisms for
for
addressing
addressing higher
higher layer
layer
protocols
protocols
TCP: connection oriented

and reliable
UDP: not connection oriented, not
reliable
unreliable, best effort
service assumed
Fig. 2 Transport layer protocols
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
5
1.2 Ports and Sockets

The concepts of port and socket are needed to determine which local process at a
given host actually communicates with which process, at which remote host, using
which transport layer protocol. These concepts provide a way to uniformly and
uniquely identify connections and the programs and hosts that are engaged in them,
irrespective of specific process IDs.
Ports
Each process that wants to communicate with another process identifies itself to the
TCP/IP protocol suite by one or more ports. A port is a 16-bit number, used by the
host-to-host protocol to identify to which higher-level protocol or application program
(process) it must deliver incoming messages. There are two types of port:
Well-known: Well-known ports belong to standard servers, for example Telnet
uses port 23. Well-known port numbers range between 1 and 1023. Well-known
port numbers are typically odd, because early systems using the port concept
required an odd/even pair of ports for duplex operations. Most servers require
only a single port. Exceptions are the BOOTP (Bootstrap protocol) server, which
uses two: 67 and 68 and the FTP (File Transfer Protocol) server, which uses
two: 20 and 21.
The well-known ports are controlled and assigned by the Internet Assigned
Number Authority (IANA) and on many systems can only be used by system
processes or by programs executed by privileged users. The reason for well-
known ports is to allow clients to be able to find servers without configuration
information.
Ephemeral (Short lived): Clients do not need well-known port numbers
because they initiate communication with servers and the port number they are
using is contained in the TCPsegments/UDP datagrams sent to the server.
Each client process is allocated a port number for as long as it needs it by the
host it is running on. Ephemeral port numbers have values greater than 1023,
normally in the range 1024 to 65535. A client can use any number allocated to
it, as long as the combination of <transport protocol, IP address, port
number> is unique. Ephemeral ports are not controlled by IANA and can be
used by ordinary user-developed programs on most systems.
Confusion, due to two different applications trying to use the same port numbers on
one host, is avoided by writing those applications to request an available port from
TCP/IP. Because this port number is dynamically assigned, it may differ from one
invocation of an application to the next.
UDP, TCP and ISO TP-4 all use the same port principle. To the best possible extent,
the same port numbers are used for the same services on top of UDP, TCP, and ISO
TP-4.Normally, a server will use either TCP or UDP, but there are exceptions. For
example, domain name (DNS) servers use both UDP port 53 and TCP port 53.
TG7020XEN02GLA1
Port Numbers
Server Client
HTTP Server HTTP Client

Port Number 80 Port Number randomly selected
UDP TCP TCP UDP TCP
IP IP
Data Link Data Link
Physical Physical
S D
D S
Fig. 3 Port numbers
Some Well Known Port Numbers
TCP/IP
BOOTP
BOOTP
Telnet
SNMP
WWW
SMTP
Telnet
SNMP
TFTP
WWW
SMTP
Layers
TFTP
DNS
FTP
DNS
FTP
44
20/21 23 25 80 53 69 67/68 161/162 Port Numbers
33 TCP
TCP UDP
UDP
EGP
EGP ICMP
ICMP OSPF
OSPF
Protocol Numbers
22 08 06 01 17 89
ARP
ARP IP
IP RARP
RARP
0806 0800 8035

11 Type Codes or
Ethernet
Ethernet 802.3
802.3 Token
Token Ring
Ring Packet Types
Fig. 4 Some well-known port numbers
TG7020XEN02GLA1
7
Sockets
The socket interface is one of several application programming interfaces (APIs) to
the communication protocols. Designed to be a generic communication-programming
interface, APIs were first introduced by 4.2 BSD (Berkeley Software Distribution).
Although it has not been standardized, it has become a de facto industry standard.
Let us consider the following terminologies:
Term Description
Socket Special type of file handle, which is used by a process to request
network services from the operating system.
Socket Address The triple: <protocol, local-address, local-process>
For example, in the TCP/IP suite: <tcp, 193.44.234.3, 12345>
Conversation Communication link between two processes.
Association The 5-tuple that completely specifies the two processes that
comprise a connection: <protocol, local-address, local-process,
foreign-address, foreign-process>
In the TCP/IP suite, the following could be a valid association:
<tcp, 193.44.234.3, 1500, 193.44.234.5, 21>
Half- Either <protocol, local-address, local-process> or
association <protocol, foreign-address, foreign-process> which specify
each half of a connection.
The half-association is also called a socket or a transport address. That is, a socket
is an endpoint for communication that can be named and addressed in a network.
Two processes communicate via TCP sockets. The socket model provides a process
with a full-duplex byte stream connection to another process. The application need
not concern itself with the management of this stream; these facilities are provided by
TCP.
SUMMARY
TCP uses the same port principle as UDP to provide multiplexing. Like UDP, TCP
uses well-known and ephemeral ports. Each side of a TCP connection has a socket
that can be identified by the triple <TCP, IP address, port number>. If two processes
are communicating over TCP, they have a logical connection that is uniquely
identifiable by the two sockets involved, that is, by the combination <TCP, local IP
address, local port, remote IP address, remote port>. Server processes are able to
manage multiple conversations through a single port.
TG7020XEN02GLA1
Sockets


For example, in the TCP/IP suite: <tcp, 193.44.234.3, 12345>
Association The 5-tuple that completely specifies the two processes that comprise
a connection: <protocol, local-address, local-process, foreign-
address, foreign-process>
In the TCP/IP suite, the following could be a valid association: <tcp,
193.44.234.3, 1500, 193.44.234.5, 21>
Half-association Either <protocol, local-address, local-process> or

<protocol, foreign-address, foreign-process> which specify each
half of a connection.
Fig. 5 Sockets
Connection and Socket Pairs
Client
Client A
A HTTP
HTTP Server
Server Client
Client B
B
IP
IP Addr.:10.27.51.3
Addr.:10.27.51.3 IP
IP Addr.:10.27.51.1
Addr.:10.27.51.1 IP
IP Addr.:10.27.51.2
Addr.:10.27.51.2
Port
Port Number:
Number: 1127
1127 Port
Port Number:
Number: 80
80 Port
Port number:
number: 1084
1084
10.27.51.3:1127
10.27.51.3:1127 10.27.51.3:1084
10.27.51.3:1084
10.27.51.1:80
10.27.51.1:80 10.27.51.1:80
10.27.51.1:80
Fig. 6 Connection and socket pairs
TG7020XEN02GLA1
9
TG7020XEN02GLA1
2 Transmission Control Protocol (TCP)
TG7020XEN02GLA1
11
2.1 TCP Properties

2.1.1 Introduction
TCP is a connection-oriented, end-to-end reliable protocol designed to fit into a
layered hierarchy of protocols, which support multi-network applications. The
Transmission Control Protocol provides for reliable inter-process communication
between pairs of processes in host computers attached to distinct but interconnected
computer communication networks.
Very few assumptions are made as to the reliability of the communication protocols
below the TCP layer. The Transmission Control Protocol assumes it can obtain a
simple, potentially unreliable datagram service from the lower level protocols. In
principle, the TCP is able to operate above a wide spectrum of communication
systems ranging from leased line connections to packet-switched or circuit-switched
networks.
TCP is based on concepts first described by Cerf and Kahn ["A Protocol for Packet
Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22,
No. 5, pp 637-648, May 1974]. The Transmission Control Protocol fits into layered
protocol architecture just above a basic Internet Protocol, which provides a way for
the TCP to send and receive variable-length segments of information enclosed in IP
packets. The IP packet provides a means for addressing source and destination
TCPs in different networks.
The IP protocol also deals with any fragmentation or reassembly of the TCP
segments required to achieve transport and delivery through multiple networks and
interconnecting gateways. The Internet protocol also carries information on the
precedence, security classification and compartmentation of the TCP segments, so
this information can be communicated end-to-end across multiple networks.
TIP
TCP is used by many of the popular applications, such as web browsing (HTTP),
electronic mail (SMTP), Telnet, FTP, etc., which require the reliability offered by TCP.
TG7020XEN02GLA1
TCP in the Layered Protocol Architecture
Campus WAN Campus

Client Server
Router Switch/ Switch/ Switch/ Router

Router Router Router
Server Client
Application Application
Transport Transmission
Transmission Control
Control Protocol
Protocol TCP
TCP Transport
Transport Transport
Network Network Network Network
Data Link Data Link Data Link Data Link Data Link Data Link Data Link
Physical Physical Physical Physical Physical Physical Physical
TCP is a connection-oriented, end-to-end reliable protocol designed to fit into

a layered hierarchy of protocols, which support multi-network applications.
The TCP provides for reliable inter-process communication between pairs of
processes in host computers attached to distinct but interconnected computer
communication networks
Fig. 7 TCP in the layered protocol architecture
TCP Connection between Processes

Host A Inter - Process Host B
Communication
Process x Process y
. Port m . Reliable . Port n .

TCP Connection
TCP TCP
Unreliable
IP Packets
IP IP
Fig. 8 TCP - connection between processes
TG7020XEN02GLA1
13
2.1.2 Services provided by TCP

As noted above, TCP is a connection-oriented, full duplex, end-to-end reliable
transport protocol layered above IP protocols, which support multi-network
applications between a pair of host systems. To provide this service on top of a less
reliable IP network, the TCP protocol requires facilities in the following areas:
Basic Data The TCP is able to transfer a continuous stream of octets in each
Transfer: direction between its users by packaging some number of octets into
segments for transmission through the IP network. In general, the
TCPs decide when to block and forward data at their own
convenience.
Reliability: The TCP must recover from data that is damaged, lost, duplicated,
or delivered out of order by the IP network. This is achieved by
assigning a sequence number to each octet transmitted, and
requiring a positive acknowledgment (ACK) from the receiving TCP.
If the ACK is not received within a timeout interval, the data is
retransmitted. At the receiver, the sequence numbers are used to
correctly order segments that may be received out of order and to
eliminate duplicates. Damage is handled by adding a checksum to
each segment transmitted, checking it at the receiver, and
discarding damaged segments.
Flow Control: TCP provides a means for the receiver to control the amount of data
sent by the sender. This is achieved by returning a "window" with
every ACK indicating a range of acceptable sequence numbers
beyond the last segment successfully received. The window
indicates an allowed number of octets that the sender may transmit
before receiving further permission.
Multiplexing: To allow for many processes within a single host system to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the IP
addresses, this forms a socket. A pair of sockets uniquely identifies
each connection.
Connections: The reliability and flow control mechanisms require that TCPs
maintain certain status information for each data stream. The
combination of this information, including sockets, sequence
numbers, and window sizes, is called a connection. A pair of sockets
identifying its two sides uniquely specifies each connection. When
two processes wish to communicate, their TCP's must first establish
a connection. When their communication is complete, the
connection is closed to free the resources for other uses.
Precedence The users of TCP may indicate the security and precedence of their
and Security: communication. Provision is made for default values to be used
when these features are not needed.
TG7020XEN02GLA1
Transmission Control Protocol TCP
Basic
Basic Data
Data Transfer
Transfer
(Full
(Full Duplex)
Duplex)
Reliability
Reliability
-- TCP
TCP recovers
recovers from
from data
data that
that is
is damaged,
damaged, lost,
lost,
duplicated,
duplicated, or
or delivered
delivered out
out of
of order
order
Flow
Flow control
control
-- by
by window
window size
size information
information
Multiplexing
Multiplexing // TCP
TCP Ports
Ports
(e.g.
(e.g. TELNET
TELNET -- port
port number
number 23)
23)
Connections
Connections
-- uniquely
uniquely specified
specified by
by aa pair
pair of
of sockets
sockets
Optional
Optional Indication
Indication of
of Precedence
Precedence and
and Security
Security
Fig. 9 Transmission control protocol
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
15
2.2 TCP Header and Segment Format

TCP segments are sent as IP packets. The Internet Protocol header carries several
information fields, including the source and destination host addresses. A TCP
header follows the IP header, supplying information specific to the TCP protocol. This
division allows for the existence of host level protocols other than TCP.
Field Name Field Field Description

Length
Source Port 16 bits The source port number identifies the application that
generated the segment, as referenced by the TCP
port number in use by the application.
Destination Port 16 bits The destination port number identifies the application
that this segment is intended for, as referenced by
the 16 bit TCP port number in use by the application
on the destination system.
Sequence Number 32 bits The sequence number of the first data octet in this
segment (except when SYN is present). If SYN is
present the sequence number is the initial sequence
number (ISN) and the first data octet is ISN+1.
Acknowledgment 32 bits If the ACK control bit is set this field contains the
Number value of the next sequence number the sender of the
segment is expecting to receive. Once a connection
is established this is always sent.
Data Offset 4 bits The number of 32 bit words in the TCP Header. This
indicates where the data begins. The TCP header
(even one including options) is an integral number of
32 bits long.
Reserved 6 bits Reserved for future use. Must be zero.
Control Bits 6 bits URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Window 16 bits The number of data octets beginning with the one
indicated in the acknowledgment field, which the
sender of this segment is willing to accept.
TG7020XEN02GLA1
Encapsulation of a TCP Segment
20 bytes 20 bytes variable length
IP
IP Header
Header TCP
TCP Header
Header TCP
TCP Data
Data
TCP Segment
IP Packet
Fig. 10 Encapsulation of a TCP segment in an IP packet
Encapsulation of a TCP Segment

32 Bits
0 16 31
1 Version IHL Type of Service Total Length
2 Identification Flags Fragment Offset

IP
3 Time to Live Protocol = 6 (TCP) Header Checksum Header
4 Source Address
5 Destination Address
1 Source Port Destination Port
2 Sequence Number
3 Acknowledgement Number TCP
4 Data Off. Reserved Flags Window Header
5 Checksum Urgent Pointer
Options and Padding
Data
Fig. 11 Encapsulation of a TCP segment in more detail
TG7020XEN02GLA1
17

Length
Checksum 16 bits The checksum field is the 16 bit one's complement of the
one's complement sum of all 16 bit words in the header and
text. If a segment contains an odd number of header and text
octets to be checksummed, the last octet is padded on the
right with zeros to form a 16 bit word for checksum purposes.
The pad is not transmitted as part of the segment. While
computing the checksum, the checksum field itself is replaced
with zeros.
Urgent 16 bits This field communicates the current value of the urgent
Pointer pointer as a positive offset from the sequence number in this
segment. The urgent pointer points to the sequence number
of the last octet in a sequence of urgent data. This field is
only to be interpreted in segments with the URG control bit
set.
Options variable Options may occupy space at the end of the TCP header and
are a multiple of 8 bits in length. All options are included in
the checksum. An option may begin on any octet boundary.
Note that the list of options may be shorter than the data
offset field might imply. The content of the header beyond the
End-of-Option option must be header padding (i.e., zero).
TCP Data variable The data portion in a TCP segment is optional. That means,
there are TCP segments exchanged between hosts, which
contain only the TCP header and possible options but no
data.
TG7020XEN02GLA1
TCP Header Fields

32 Bits
0 16 31
Source Port Destination Port
Sequence Number
TCP Acknowledgement Number

Header
U A P R S F
Data
Reserved R C S S Y I Window
Offset
G K H T N N
Checksum Urgent Pointer
Options and Padding
Data
Fig. 12 TCP header fields
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
19
2.3 TCP Connections

2.3.1 Opening a Virtual Circuit
General
Applications communicate with each other using the virtual circuits provided by TCP.
These circuits are established on an as-needed basis, getting set up and torn down
as requested by the applications in use. Whenever an application needs to
communicate with another application somewhere on the network, it will ask the local
TCP module to establish a virtual circuit on its behalf.
There are two methods for requesting a virtual circuit to be opened: either an client
will request an "OPEN" so that data can be sent immediately, or a server will "OPEN"
a port in "listen" mode, waiting for a connection request to arrive from a client.
Passive OPEN
The most simple of the two methods is the passive "OPEN", which is the form used
by servers that want to listen for incoming connections. A passive "OPEN" indicates
that the server is willing to accept incoming connection requests from other systems,
and that it does not want to initiate an outbound connection. Typically a passive
"OPEN" is "unqualified", meaning the server can accept an incoming connection from
anybody. However, some security sensitive applications will accept connections from
predefined entities, a condition known as qualified passive "OPEN".
When a publicly accessible server first gets started, it will request that TCP to
"OPEN" a well-known port in passive mode, offering connectivity to any node that
sends in a connection request. Any TCP connection requests that come into that
system destined for that port number would result in a new virtual circuit being
established.
TG7020XEN02GLA1
Opening a Virtual Circuit in Passive Mode

Client Server
Telnet Telnet
OPEN (local port, foreign socket, passive, etc.) local
connection name
local port = 23
. . . Port 23 .
. foreign socket =
unspecified/specified LISTEN
TCB
TCP Send Buffer Receive Buffer TCP
Unreliable
IP Packets
IP IP
Fig. 13 Opening a virtual circuit in passive mode
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
21
Active OPEN
Client applications (e.g. a web browser) use active "OPEN" when making these
connection requests. An active "OPEN" is the opposite of an passive "OPEN" , in that
it is a specific request to establish a virtual circuit with a specific destination socket
(typically this will be the well known port number of the server that is associated with
the specific client). On an active "OPEN" command, the TCP will begin the procedure
to synchronize (i.e., establish) the connection at once.
Local Connection Name

A local connection name will be returned to the application by the TCP as a response
to an active or passive "OPEN". The local connection name can then be used as a
short hand term for the connection defined by the <local socket, foreign socket> pair.
Transmission Control Block (TCB)

A transmission control block (TCB) is created and partially filled in with data from the
"OPEN" command parameters. There are several things that must be remembered
about a connection. To store this information a data structure called a Transmission
Control Block (TCB) is used to record the state of a connection. Among the variables
stored in the TCB are the local and remote socket numbers, the security and
precedence of the connection, pointers to the user's send and receive buffers,
pointers to the retransmit queue and to the current segment. In addition several
variables relating to the send and receive sequence numbers are stored in the TCB.
TG7020XEN02GLA1
Opening a Virtual Circuit in Active Mode

Client Inter - Process Server
Communication
Telnet Telnet
local OPEN (local port, foreign socket, active, etc.)
connection name
local port = 1038
. Port 1038 . foreign socket = . Port 23 .
SYN_SENT specified (IP:23) LISTEN
TCB TCB
Set up reliable
TCP Send Buffer TCP Connection Receive Buffer TCP
SYN Segment
Unreliable
IP Packets
IP IP
Fig. 14 Opening a virtual circuit in active mode
Transmission Control Block TCB
TCB
Local socket number
Remote socket number
Security and precedence of the connection
Pointers to the user's send and receive buffers
Pointer to the retransmit queue
Pointer to the current segment
Variables relating to the send and receive sequence numbers
Fig. 15 Transmission Control Block TCB
TG7020XEN02GLA1
23
Connection Establishment Protocol

The "three-way handshake" is the procedure used to establish a connection. This
procedure normally is initiated by one TCP and responded to by another TCP. The
three-way handshake reduces the possibility of false connections.
The segments used for the handshake process do not normally contain data, but
instead are zero-length "command segments" that have special connection
management flags in their headers, signifying that a new virtual circuit is being
established. In this context, the most important of these flags is the Synchronize
(SYN) flag, which is used by the two ends to signify that a virtual circuit is being
established.
The detailed segment flow to establish a TCP connection:
1. The requesting side (normally the client) sends a SYN segment specifying the
port number of the server that the client wants to connect to, and the clients initial
sequence number. This is the first segment.
2. The server responds with its own SYN segment containing the servers initial
sequence number. The server also acknowledges the clients SYN by ACKing the
clients ISN plus one. A SYN consumes one sequence number. This is the
second segment.
3. The client must acknowledge this SYN from the server by ACKing the servers
ISN plus one. This is the third segment.
These three segments complete the connection establishment. The virtual circuit is
now considered up and operational, with both systems now being able to exchange
data as needed.
TG7020XEN02GLA1
Important Fields for Virtual Circuit Set-up

32 Bits
0 16 31
Sequence Number
Acknowledgement Number
U A P R S F
Data
Offset
G K H T N N
Options and Padding
Fig. 16 Important TCP header fields for virtual circuit set-up
Telnet Client Telnet Server
Telnet
Telnet Connect
Connect
IP: 192.168.109.143 IP: 192.168.109.142
SYN SN=50627, ACK=0
Three-way Handshake"
SYN SN=1690412290 , ACK= 50628
ACK SN=50628 , ACK=1690412291
Fig. 17 Connection establishment protocol
TG7020XEN02GLA1
25
Capture Sample: First Segment

Internet
Internet Protocol
Protocol (IP):
(IP):
Source
Source Address:
Address: 192.168.109.143
192.168.109.143
Destination
Destination Address:
Address: 192.168.109.142
192.168.109.142
Transmission
Control Protocol
Protocol (TCP):
(TCP):
Source
Source Port:
Port: 1038
1038
Destination
Destination Port:
Port: 23
23 (Telnet)
(Telnet)
Sequence
Sequence Number:
Number: 50627
50627
Acknowledgement
Acknowledgement Number:
Number: 00
Header
Header Length:
Length: 0x60
0x60
0110
0110 ....
.... 24
24 bytes
bytes -- Header
Header Length
Length
....
.... 0000
0000 Not
Not Used
Used
Flags:
Flags: 0x02
0x02
00..
00.. ....
.... Not
Not Used
Used
..0.
..0. ....
.... No
No URG
URG
...0
...0 ....
.... No
No ACK
ACK
....
.... 0...
0... No
No PSH
PSH
....
.... .0..
.0.. No
No RST
RST
....
.... ..1.
..1. Synchronize
Synchronize
....
.... ...0
...0 No
No FIN
FIN
Window
Window Size:
Size: 8192
8192
CheckSum:
CheckSum: 0x51CF
0x51CF (Correct)
(Correct)
Urgent
Urgent Pointer:
Pointer: 00
Options
Options Present:
Present:
Kind:
Kind: 22 (Maximum
(Maximum Segment
Segment Size)
Size)
Length:
Length: 44 bytes
bytes
Maximum
Maximum Segment
Segment Size:
Size: 1460
1460
[0
[0 bytes
bytes of
of data]
data]
Fig. 18 Capture sample: First segment from client to server
TG7020XEN02GLA1
Capture Sample: Second Segment

Internet
Internet Protocol
Protocol (IP):
(IP):
Source
Source Address:
Address: 192.168.109.142
192.168.109.142
Destination
Address: 192.168.109.143
192.168.109.143
Transmission
Control Protocol
Protocol (TCP):
(TCP):
Source
Source Port:
Port: 23
23 (Telnet)
(Telnet)
Destination
Destination Port:
Port: 1038
1038
Sequence
Sequence Number:
Number: 1690412290
1690412290
Acknowledgement
Number: 50628
50628
Header
Header Length:
Length: 0x60
0x60
0110
0110 ....
.... 24
24 bytes
bytes -- Header
Header Length
Length
....
.... 0000
0000 Not
Not Used
Used
Flags:
Flags: 0x12
0x12
00..
00.. ....
.... Not
Not Used
Used
..0.
..0. ....
.... No
No URG
URG
...1
...1 ....
.... Acknowledgement
Acknowledgement
....
.... 0...
0... No
No PSH
PSH
....
.... .0..
.0.. No
No RST
RST
....
.... ..1.
..1. Synchronize
Synchronize
....
.... ...0
...0 No
No FIN
FIN
Window
Window Size:
Size: 4128
4128
CheckSum:
CheckSum: 0x57DA
0x57DA (Correct)
(Correct)
Urgent
Urgent Pointer:
Pointer: 00
Options
Options Present:
Present:
Kind:
Kind: 22 (Maximum
(Maximum Segment
Segment Size)
Size)
Length:
Length: 44 bytes
bytes
Maximum
Maximum Segment
Segment Size:
Size: 1460
1460
[0
[0 bytes
bytes of
of data]
data]
Fig. 19 Capture sample: Second segment from server to client
Capture Sample: Third Segment

Internet
Internet Protocol
Protocol (IP):
(IP):
Source
Source Address:
Address: 192.168.109.143
192.168.109.143
Destination
Address: 192.168.109.142
192.168.109.142
Transmission
Control Protocol
Protocol (TCP):
(TCP):
Source
Source Port:
Port: 1038
1038
Destination
Destination Port:
Port: 23
23 (Telnet)
(Telnet)
Sequence
Sequence Number:
Number: 50628
50628
Acknowledgement
Number: 1690412291
1690412291
Header
Header Length:
Length: 0x50
0x50
0101
0101 ....
.... 20
20 bytes
bytes -- Header
Header Length
Length
....
.... 0000
0000 Not
Not Used
Used
Flags:
Flags: 0x10
0x10
00..
00.. ....
.... Not
Not Used
Used
..0.
..0. ....
.... No
No URG
URG
...1
...1 ....
Acknowledgement
....
.... 0...
0... No
No PSH
PSH
....
.... .0..
.0.. No
No RST
RST
....
.... ..0.
..0. No
No SYN
SYN
....
.... ...0
...0 No
No FIN
FIN
Window
Window Size:
Size: 8760
8760
CheckSum:
CheckSum: 0x5D7F
0x5D7F (Correct)
(Correct)
Urgent
Urgent Pointer:
Pointer: 00
[0
[0 bytes
bytes of
of data]
data]
Fig. 20 Capture sample: Third segment from client to server
TG7020XEN02GLA1
27
2.3.2 Exchanging Data
2.3.2.1 General
Once a virtual circuit has been established, the applications in use can begin
exchanging data with each other. However, as we know, the applications do not
exchange data directly. Rather, each application hands data to its local TCP module,
identifying the specific destination socket that the data is for and TCP does the rest.
Applications can pass data to TCP in chunks or as contiguous byte stream. Most
TCP implementations provide a "write" service that is restricted in size, forcing
applications to write data in blocks, just as if they were writing data to file on the local
hard drive. However, TCPs buffering design also supports application writes that are
contiguous, and this design is used in a handful of implementations.
TCP stores the data that it receives into a local send buffer. Periodically, a chunk of
data will get sent to the destination system. The recipient TCP software will then
store this data into a receive buffer, where it will be eventually passed to the
destination application.
TIP
The important thing to remember here is that application data is transmitted as
independent TCP segments, each of which requires acknowledgements. It is at this
layer that TCP's reliability and flow control services become most visible.
TG7020XEN02GLA1
Application SEND
Client Inter Process Server
Communication
Telnet Telnet
SEND (local connection name, buffer address, byte

count, PUSH flag, URGENT flag)
. Port 1038 . . Port 23 .

Reliable
ESTABLISHED TCP Connection ESTABLISHED
TCB TCB

TCP Segment
Unreliable
IP Packets
IP IP
Fig. 21 Application SEND
Application RECEIVE
Client Inter Process Server
Communication
Telnet Telnet
RECEIVE (local connection name, buffer address, byte

count) -> byte count, urgent flag, push flag
. Port 1038 . . Port 23 .

Reliable
ESTABLISHED TCP Connection ESTABLISHED
TCB TCB

TCP Segment
Unreliable
IP Packets
IP IP
Fig. 22 Application RECEIVE
TG7020XEN02GLA1
29
2.3.2.2 TCP Flow Control

A simple transport protocol might use the following principle: send a packet and then
wait for an acknowledgment from the receiver before sending the next packet. If the
ACK is not received within a certain amount of time, retransmit the packet.
TIP
While this mechanism ensures reliability, it only uses a part of the available network
bandwidth.
Consider now a protocol where the sender groups its packets to be transmitted as in
the figure below and uses the following rules:
The sender can send all packets within the window without receiving an ACK, but
must start a timeout timer for each of them.
The receiver must acknowledge each packet received, indicating the sequence
number of the last well-received packet.
The sender slides the window on each ACK received.
The sender can transmit packets 1 to 5 without waiting for any acknowledgment as
shown in figure 23.
At the moment the sender receives ACK 1 (acknowledgment for packet 1), it can
slide its window one packet to the right (see figure 24).
At this point, the sender may also transmit packet 6.
Packet 2 gets lost
The sender will not receive ACK 2, so its window will remain in position 1 (as in
Figure 23). In fact, since the receiver did not receive packet 2, it will acknowledge
packets 3, 4 and 5 with an ACK 1, since packet 1 was the last one received in
sequence. At the sender's side, eventually a timeout will occur for packet 2 and it will
be retransmitted. Note that reception of this packet by the receiver will generate ACK
5, since it has now successfully received all packets 1 to 5, and the sender's window
will slide four positions upon receiving this ACK 5.
Packet 2 did arrive, but the acknowledgment gets lost:
The sender does not receive ACK 2, but will receive ACK 3. ACK 3 is an
acknowledgment for all packets up to 3 (including packet 2) and the sender can now
slide its window to packet 4.
This window mechanism ensures:
Reliable transmission.
Better use of the network bandwidth (better throughput).
Flow-control, since the receiver may delay replying to a packet with an
acknowledgment, knowing its free buffers available and the window-size of the
communication.
TG7020XEN02GLA1
Fields for Flow Control

32 Bits
0 16 31
Sequence Number

Header
U A P R S F
Data
Offset
G K H T N N
Options and Padding
Data
Fig. 23 TCP header fields for flow control
The Window Principle

Sender Receiver
Send packet 1
Receive packet 1 and
reply with an ACK 1
Receive ACK
Send packet 2
1 2 3 4 5 6 7 8 9 .. packets
window
Fig. 24 The window principle
TG7020XEN02GLA1
31
The Window Principle Applied to TCP

The above window principle is used in TCP, but with a few differences:
Since TCP provides a byte-stream connection, sequence numbers are assigned to
each byte in the stream. TCP divides this contiguous byte stream into TCP
segments to transmit them. The window principle is used at the byte level; that is,
the segments sent and ACKs received will carry byte-sequence numbers and the
window size is expressed as a number of bytes, rather than a number of packets.
The receiver determines the window size when the connection is established, and
is variable during the data transfer. Each ACK message will include the window
size that the receiver is ready to deal with at that particular time.
The sender's data stream can be seen in figure 25.
TIP
Remember that TCP will block bytes into segments, and a TCP segment only carries
the sequence number of the first byte in the segment.
TG7020XEN02GLA1
The Window Principle (cont.)

Sender Receiver
Send packet 1
Send packet 2
Send packet 3
Send packet 4
Receive ACK for packet 1 ACK 1
Send packet 5
1 2 3 4 5 6 7 8 9 .. packets
Window slides after

receiving ACK
Fig. 25 The window principle (cont.)
The Window Principle applied to TCP

Total Window size is minimum of senders buffer size and advertised receiver window size
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 .. bytes
A
A B
B C
C D
D
Received ACK advances Local host advances Receivers advertised

the trailing edge of the this marker as data window advances the
window is transmitted into leading edge of the
the network sliding window
Where: A = Bytes that are transmitted and have been acknowledged.
B = Bytes that are sent but not yet acknowledged.
C = Bytes allowed to be sent without receiving further ACKs
D = Bytes that cannot yet be sent.
Fig. 26 The window principle applied to TCP
TG7020XEN02GLA1
33
Acknowledgments and retransmissions

TCP sends data in variable length segments. Sequence numbers are based on a
byte count. Acknowledgments specify the sequence number of the next byte that the
receiver expects to receive.
Consider that a segment gets lost or corrupted. In this case, the receiver will
acknowledge all further well-received segments with an acknowledgment referring to
the first byte of the missing packet. The sender will stop transmitting when it has sent
all the bytes in the window. Eventually, a retransmission timeout will occur and the
missing segment will be retransmitted.
Figure 26 illustrates an example where a window size of 1500 bytes and segments of
500 bytes are used. A problem now arises, since the sender does know that segment
2 is lost or corrupted, but does not know anything about segments 3 and 4. The
sender should at least retransmit segment 2, but it could also retransmit segments 3
and 4 (since they are within the current window). It is possible that:
Case 1:Segment 3 has been received, and we do not know about segment 4. It
could be received, but ACK did not reach us yet, or it could be lost.
Case 2:Segment 3 was lost, and we received the ACK 1500 upon the reception of
segment 4.
Each TCP implementation is free to react to a timeout as the implementing wish. It
could retransmit only segment 2, but in case 2, we will be waiting again until segment
3 times out. In this case, we lose all of the throughput advantages of the window
mechanism. Or TCP might immediately retransmit all of the segments in the current
window.
Whatever the choice, maximal throughput is lost. This is because the ACK does not
contain a second acknowledgment sequence number indicating the actual frame
received.
TG7020XEN02GLA1
Acknowledgement and Retransmission

Sender Receiver
Retransmission
Timer
Segment 1 (Seq. Nr. 1500)

Receives Segment 1
Segment 2 (Seq. Nr. 2000) (Seq. Nr. 1500), sends ACK 2000
Receives ACK 2000 and Segment 2 gets lost
slides window
Segment 4 (Seq. Nr. 3000) Receives Segment 3
Window size reached, R and replies with ACK 2000
waiting for ACK T
Receives ACK 2000, O
which does not slide
the window
Timeout for Segment 2

Retransmission
RTO. . . Retransmission Timeout
Fig. 27 Acknowledgement and retransmission: Case 1
Acknowledgement and Retransmission

Sender Receiver
Retransmission
Timer

Receives Segment 1
Receives ACK 2000 and Segment 2 gets lost
slides window
Segment 4 (Seq. Nr. 3000) Segment 3 gets lost
Window size reached, R
T Receives Segment 4
waiting for ACK and replies with ACK 2000
O
Receives ACK 2000,
which does not slide
the window
Timeout for Segment 2

Retransmission
RTO. . . Retransmission Timeout
Fig. 28 Acknowledgement and retransmission: Case 2
TG7020XEN02GLA1
35
Variable timeout intervals

Each TCP should implement an algorithm to adapt the timeout values to be used for
the round trip time of the segments. To do this, TCP records the time at which a
segment was sent, and the time at which the ACK is received. A weighted average is
calculated over several of these round trip times, to be used as a timeout value for
the next segment(s) to be sent.
TIP
This is an important feature, because delays can vary in IP network, depending on
multiple factors, such as the load of an intermediate low-speed network or the
saturation of an intermediate IP router.
TG7020XEN02GLA1
Round Trip Time (RTT)

Sender Receiver
Retransmission
Timer

Receives Segment 1
Receives ACK 2000 and Receives Segment 2
slides window and replies with ACK 2500
Receives ACK 2500 and
slides window
RTT -> calculate new RTO
RTT -> calculate new RTO
Fig. 29 Round Trip Time RTT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
37
2.3.3 Closing a Virtual Circuit
General
Once the applications have exchanged all of their data, the circuit can be closed.
Closing the circuit is similar to opening one, in that an application must request the
action (except in those cases where the connection has collapsed, and TCP is forced
to terminate it). Either end of the connection may close the circuit at any time, using a
variety of different means. The two common ways to close are "active closes" that
initiate a shutdown sequence and "passive closes" that respond to an active close
request.
Just as building a circuit requires a bidirectional exchange of special command
segments, so does closing it. One end of the connection requests that the circuit be
closed (the active close at work). The remote system then acknowledges the
termination request and responds with its own termination request (the passive
close). The terminating system then acknowledges the acknowledgement, and both
endpoints drop the circuit. At this point, neither system is able to send any more data
over the virtual circuit.
Connection Termination Protocol

There are essentially three cases closing a virtual circuit:
Local application initiates the close
In this case, a Finish (FIN) segment can be constructed and placed on the
outgoing segment queue. No further data from the application will be accepted by
the TCP. Receiving data from the remote TCP is still allowed in this state. All
segments preceding and including FIN will be retransmitted until acknowledged.
When the other TCP has both acknowledged the FIN and sent a FIN of its own,
the local TCP can ACK this FIN. Note that a TCP receiving a FIN will ACK but not
send its own FIN until its application has closed the connection also.
Local TCP receives a FIN from the network
If an unsolicited FIN arrives from the network, the receiving TCP can ACK it and
tell the application that the connection is closing. The application will respond with
a "close", upon which the local TCP module can send a FIN to the other TCP after
sending any remaining data. The TCP then waits until its own FIN is
acknowledged whereupon it deletes the connection. If an ACK is not forthcoming,
after the user timeout the connection is aborted and the application gets informed.
Both users close simultaneously
A simultaneous "close" by users at both ends of a connection causes FIN
segments to be exchanged. When all segments preceding the FINs have been
processed and acknowledged, each TCP can ACK the FIN it has received. Both
will, upon receiving these ACKs, delete the connection.
TG7020XEN02GLA1
Connection Termination Protocol
Telnet
Telnet Disconnect
Disconnect
IP: 192.168.109.143 IP: 192.168.109.142
FIN SN=1690413347, ACK= 50691

Closing the Connection
ACK SN=50691, ACK=1690413348
FIN SN=50691, ACK=1690413348
ACK SN=1690413348, ACK= 50692
Fig. 30 Connection termination protocol
Capture Sample: First Segment

Internet
Internet Protocol
Protocol (IP):
(IP):
Source
Source Address:
Address: 192.168.109.142
192.168.109.142
Destination
Address: 192.168.109.143
192.168.109.143
Transmission
Control Protocol
Protocol (TCP):
(TCP):
Source
Source Port:
Port: 23
23 (Telnet)
(Telnet)
Destination
Destination Port:
Port: 1038
1038
Sequence
Sequence Number:
Number: 1690413347
1690413347
Acknowledgement
Number: 50691
50691
Header
Header Length:
Length: 0x50
0x50
0101
0101 ....
.... 20
20 bytes
bytes -- Header
Header Length
Length
....
.... 0000
0000 Not
Not Used
Used
Flags:
Flags: 0x19
0x19
00..
00.. ....
.... Not
Not Used
Used
..0.
..0. ....
.... No
No URG
URG
...1
...1 ....
Acknowledgement
....
.... 1...
1... Push
Push
....
.... .0..
.0.. No
No RST
RST
....
.... ..0.
..0. No
No SYN
SYN
....
.... ...1
...1 Finished
Finished
Window
Window Size:
Size: 4065
4065
CheckSum:
CheckSum: 0x6B6E
0x6B6E (Correct)
(Correct)
Urgent
Urgent Pointer:
Pointer: 00
[0
[0 bytes
bytes of
of data]
data]
Fig. 31 Capture sample: Telnet disconnect first segment
TG7020XEN02GLA1
39
Capture Sample: Second Segment

Internet
Internet Protocol
Protocol (IP):
(IP):
Source
Source Address:
Address: 192.168.109.143
192.168.109.143
Destination
Address: 192.168.109.142
192.168.109.142
Transmission
Control Protocol
Protocol (TCP):
(TCP):
Source
Source Port:
Port: 1038
1038
Destination
Destination Port:
Port: 23
23 (Telnet)
(Telnet)
Sequence
Sequence Number:
Number: 50691
50691
Acknowledgement
Number: 1690413348
1690413348
Header
Header Length:
Length: 0x50
0x50
0101
0101 ....
.... 20
20 bytes
bytes -- Header
Header
Length
Length
....
.... 0000
0000 Not
Not Used
Used
Flags:
Flags: 0x10
0x10
00..
00.. ....
.... Not
Not Used
Used
..0.
..0. ....
.... No
No URG
URG
...1
...1 ....
Acknowledgement
....
.... 0...
0... No
No PSH
PSH
....
.... .0..
.0.. No
No RST
RST
....
.... ..0.
..0. No
No SYN
SYN
....
.... ...0
...0 No
No FIN
FIN
Window
Window Size:
Size: 7704
7704
CheckSum:
CheckSum: 0x5D3F
0x5D3F (Correct)
(Correct)
Urgent
Urgent Pointer:
Pointer: 00
[0
[0 bytes
bytes of
of data]
data]
Fig. 32 Capture sample: Telnet disconnect second segment
Capture Sample: Third Segment

Internet
Internet Protocol
Protocol (IP):
(IP):
Source
Source Address:
Address: 192.168.109.143
192.168.109.143
Destination
Address: 192.168.109.142
192.168.109.142
Transmission
Control Protocol
Protocol (TCP):
(TCP):
Source
Source Port:
Port: 1038
1038
Destination
Destination Port:
Port: 23
23 (Telnet)
(Telnet)
Sequence
Sequence Number:
Number: 50691
50691
Acknowledgement
Number: 1690413348
1690413348
Header
Header Length:
Length: 0x50
0x50
0101
0101 ....
.... 20
20 bytes
bytes -- Header
Header Length
Length
....
.... 0000
0000 Not
Not Used
Used
Flags:
Flags: 0x11
0x11
00..
00.. ....
.... Not
Not Used
Used
..0.
..0. ....
.... No
No URG
URG
...1
...1 ....
Acknowledgement
....
.... 0...
0... No
No PSH
PSH
....
.... .0..
.0.. No
No RST
RST
....
.... ..0.
..0. No
No SYN
SYN
....
.... ...1
...1 Finished
Finished
Window
Window Size:
Size: 7704
7704
CheckSum:
CheckSum: 0x5D3E
0x5D3E (Correct)
(Correct)
Urgent
Urgent Pointer:
Pointer: 00
[0
[0 bytes
bytes of
of data]
data]
Fig. 33 Capture sample: Telnet disconnect third segment
TG7020XEN02GLA1
Capture Sample: Fourth Segment

Internet
Internet Protocol
Protocol (IP):
(IP):
Source
Source Address:
Address: 192.168.109.142
192.168.109.142
Destination
Address: 192.168.109.143
192.168.109.143
Transmission
Control Protocol
Protocol (TCP):
(TCP):
Source
Source Port:
Port: 23
23 (Telnet)
(Telnet)
Destination
Destination Port:
Port: 1038
1038
Sequence
Sequence Number:
Number: 1690413348
1690413348
Acknowledgement
Number: 50692
50692
Header
Header Length:
Length: 0x50
0x50
0101
0101 ....
.... 20
20 bytes
bytes -- Header
Header
Length
Length
....
.... 0000
0000 Not
Not Used
Used
Flags:
Flags: 0x10
0x10
00..
00.. ....
.... Not
Not Used
Used
..0.
..0. ....
.... No
No URG
URG
...1
...1 ....
Acknowledgement
....
.... 0...
0... No
No PSH
PSH
....
.... .0..
.0.. No
No RST
RST
....
.... ..0.
..0. No
No SYN
SYN
....
.... ...0
...0 No
No FIN
FIN
Window
Window Size:
Size: 4065
4065
CheckSum:
CheckSum: 0x6B75
0x6B75 (Correct)
(Correct)
Urgent
Urgent Pointer:
Pointer: 00
[0
[0 bytes
bytes of
of data]
data]
Fig. 34 Capture sample: Telnet disconnect fourth segment
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
41
2.4 TCP Options

The TCP header provides everything needed for two endpoint systems to establish a
connection, to exchange data, and tear down a virtual circuit. However some
additional functionality beyond what is provided for in the TCP header is needed at
times. When this is the case, TCP options must be used.
The table below lists the current options that are commonly used.
Kind Name Description

0 End of Option List Used to mark the end of all the options.
1 No Operation Used for internal padding, when multiple
options are present, or when an option needs to
start at an32 bit boundary.
2 Maximum Segment Size Used to exchange Maximum Receive Unit sizes
during the circuit setup handshake.
3 Window Scale Allows TCP to use and publish window sizes
that are larger than the 64 kilobytes maximum
allowed by the Window field of the TCP header.
4 Selective Acknowledgement Used to allow the use of selective
Permitted acknowledgements on virtual circuits.
5 Selective Acknowledgement The selective acknowledgement, if permitted by
option kind 4.
8 Timestamp Used to determine the round-trip delivery time
for a segment, allowing the two endpoints to
determine reasonable acknowledgement timers.
Options may occupy space at the end of the TCP header and are a multiple of 8 bits
in length. All options are included in the checksum. An option may begin on any octet
boundary. There are two cases for the format of an option:
Case 1: A single octet of option-kind.
Case 2: An octet of option-kind, an octet of option-length, and the actual option-
data octets.
TIP
The option-length counts the two octets of option-kind and option-length as well as
the option-data octets. The list of options may be shorter than the data offset field
might imply. The content of the header beyond the End-of-Option option must be
header padding (i.e., zero).
TG7020XEN02GLA1
TCP Options
Kind Name Description
0 End of Option List Used to mark the end of all the options.
1 No Operation Used for internal padding, when multiple options

are present, or when an option needs to start at
an 32 bit boundary.
2 Maximum Segment Size Used to exchange Maximum Receive Unit sizes

during the circuit setup handshake.
3 Window Scale Allows TCP to use and publish window sizes

that are larger than the 64 kilobytes maximum
allowed by the Window field of the TCP header.
4 Selective Used to allow the use of selective

Acknowledgement acknowledgements on virtual circuits.
Permitted
5 Selective The selective acknowledgement, if permitted by
Acknowledgement option kind 4.
8 Timestamp Used to determine the round-trip delivery time

for a segment, allowing the two endpoints to
determine reasonable acknowledgement timers.
Fig. 35 TCP options
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
43
TG7020XEN02GLA1
3 User Datagram Protocol (UDP)
TG7020XEN02GLA1
45
3.1 UDP Properties

3.1.1 Introduction
Not every application requires guaranteed delivery, and these applications typically
use the User Datagram Protocol (UDP) for transport services. Unlike TCP, UDP send
only the data it has received from the application, and makes no pretence towards
guaranteed delivery or flow control or anything else. As such, UDP is much like IP,
but is the protocol that applications use to communicate with each other, rather than
using IP directly.
UDP Services
One may wonder why a UDP protocol exists, when it would seem that IP could serve
the same function. The reason is simple: IP doesn't do anything but get packets from
one host to another. IP doesn't provide any application interfaces or management
services. UDP does provide these services, and it provides a consistent environment
for developers to use when writing low-overhead network applications. UDP also
provides application-multiplexing services through the use of port numbers, allowing
many application protocols to be used on a single host.
Message-centric Model
Another benefit of UDP is that it offers a message-centric model, allowing chunks of
data to be sent as single IP packets. For example, a UDP based application protocol
can write a four-kilobyte block of data to UDP, and that block will be handed to IP
directly. IP will then create an IP packet that contains the entire four kilobytes, and
send this data as a series of fragmented IP packets to the destination system. Once
all of the data arrives, the original IP packet is reassembled and the entire four-
kilobyte UDP message will be handed to UDP for processing. In this model, it is very
easy for applications to exchange record-oriented data (e.g. database records), since
the entire record can be read by a single operation.
Lightweight Protocol
Also, applications that need fast response times or that already have their own
internal error-correction routines can make good use of UDP because of its low
overhead. Some database software packages can be configured to use UDP, and
some file transfer protocols also use UDP because it is a light, fast, and message
centric protocol that is easier and faster than TCP, and that does not require the
overhead of TCP's virtual circuit model.
Broadcast and Multicast Capability

In addition, some applications simply cannot use TCP, since TCP's virtual circuit
design requires dedicated end-to-end connections between two (and no more than
two) endpoints. If an application needs to use broadcasts or multicasts in order to
send data to multiple hosts simultaneously, then that application will have to use UDP
to do so.
TG7020XEN02GLA1
UDP in the Layered Protocol Architecture

Campus Campus
Client WAN Server
Router Switch/ Switch/ Switch/ Router

Router Router Router
Server Client
Application Application
User
User Datagram
Datagram Protocol
Protocol UDP
UDP
Transport
Transport Transport
Transport
Network Network Network Network
Data Link Data Link Data Link Data Link Data Link Data Link Data Link
Physical Physical Physical Physical Physical Physical Physical
UDP is a connectionless, end-to-end unreliable protocol designed to fit into a

layered hierarchy of protocols, which support multi-network applications.
Fig. 36 UDP in the layered protocol architecture
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
47
Communication between Processes
Host A Inter - Process Host B

Communication
Process x Process y
. Port m . Unreliable . Port n .

UDP Communication
UDP UDP
Unreliable
IP Packets
IP IP
Fig. 37 Communication between processes
TG7020XEN02GLA1
User Datagram Protocol UDP
Lightweight-Protocol
Lightweight-Protocol
-- Low
Low Overhead
Overhead
Limited
Limited Reliability
Reliability
-- UDP
UDP does
does not
not recover
recover from
from data
data that
that is
is damaged,
damaged,
lost,
lost, duplicated,
duplicated, or
or delivered
delivered out
out of
of order
order
Message-centric
Message-centric
Multiplexing
Multiplexing // UDP
UDP Ports
Ports
(e.g.
(e.g. TFTP
TFTP -- port
port number
number 69)
69)
Connectionless
Connectionless
Broadcast
Broadcast and
and Multicast
Multicast Capability
Capability
Fig. 38 User datagram protocol
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
49
3.1.2 Limited Reliability
Error Tolerant Applications

Although applications that broadcast information on a frequent basis have to use
UDP, they do gain some benefits from doing so. Since broadcasts are sent to every
device on the local network, it would take far too long for the sender to establish
individual TCP connections with every other system on the network, exchange data
with them all, and then disconnect. Conversely, UDP's connectionless service allows
the sender to send the data to all of the devices simultaneously. If any of the systems
do not receive one of the messages, then they will likely receive one of the next
broadcasts, and as such will not be substantially harmed by missing one or the other.
Furthermore, streaming applications (such as real-time audio or video) can also
benefit from UDP's low-overhead structure. Since these applications are stream
oriented, the individual messages are not nearly as important as the overall stream of
data. The user will not notice if a single IP packet gets lost, so it is better to just
continually keep sending the next message, rather than stopping everything to
resend a single message.
Similarly, any application that needs only a lightweight query and response service
would benefit from UDP's low overhead. Some database and network-lookup
services use UDP for just this reason, allowing a client and server to exchange data
without having to spend a lot of time establishing a reliable connection when a single
query is all that's required. In case a query is lost, it will be simply repeated.
Application Specific Error Correction

It should be pointed out that many of the applications that use UDP require some
form of error correction, but that this error correction tends to be specific to the
application at hand, and is therefore embedded directly into the application logic.
Applications that use UDP must therefore incorporate any required error checking
and fault management routines internally, rather than rely on UDP to provide these
services.
Underlying Network Reliability

Another interesting point is that most of the network technologies in use today are
fairly reliable, so unreliable protocols like UDP (and IP) can exchange data without
many problems. For these reasons, UDP probably shouldn't be considered totally
unreliable, although you must always remember that UDP doesn't provide any error
correction or retransmission services within the transport itself. It just inherits any
existing reliability that is provided by the underlying network.
UDP Checksum
Furthermore, UDP also provides a checksum service that allows a receiving UDP to
verify that whatever data has arrived is probably the same as that which was sent.
The use of UDP's checksum is optional but recommended, and not all of the
applications that use UDP also use the checksum service.
TG7020XEN02GLA1
UDP Limited Reliability
Error
Error Tolerant
Tolerant Applications
Applications
Application
Application Specific
Specific Error
Error Correction
Correction
Underlying
Underlying Network
Network Reliability
Reliability
UDP
UDP Checksum
Checksum
Fig. 39 UDP limited reliability
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
51
3.1.3 Datagram-centric Transport Services

Another unique aspect of UDP is the way in which it deals with only one datagram at
a time. Rather than attempting to manage a stream of application data the way TCP
does, UDP deals with only individual blocks of data, as generated by the application
in use. For example, if an application gives UDP a four-kilobyte block of data, than
UDP will hand that data to IP as single datagram, without trying to create efficient
segment sizes (one of TCP's most significant characteristics). The data may be
fragmented by IP when it builds and sends IP packets for that four kilobyte block of
data, but UDP does not care if this happens and is not involved in that process
whatsoever.
Furthermore, since each IP packet contains a fully formed UDP datagram, the
destination system will not receive any portion of the UDP message until the entire IP
packet has been received. For example, if the underlying IP packet has been
fragmented, then UDP will not receive any portion of the message until all of the
fragments have arrived and been reassembled by IP. But once that happens, then
UDP (and the application in use with UDP) will get and read the entire four-kilobyte
message at once.
Conversely, remember that TCP does not generally cause fragmentation to occur,
since it attempts to avoid fragmentation through the use of efficiently sized segments.
In that model, TCP would send multiple TCP segments, each of which could arrive
independently and be made available to the destination application immediately.
Although there are benefits to the TCP design, record-centric applications also have
to perform more work when using it instead of UDP, since UDP provides one-shot
access to all of the data.
For all of these reasons, UDP is a more efficient protocol, although it is still
unreliable. As such, application protocols that want to leverage the low-overhead
nature of UDP must provide their own reliability services. In addition, these
applications typically have to provide their own flow control and packet ordering
services, ensuring that datagrams are not received out of order.
TG7020XEN02GLA1
Datagram-centric Transport
Client Server
Application
Application Data
Data Data
Data Application
Application
UDP
UDP UDP Datagram UDP Datagram UDP
UDP
IP Packet IP Packet
IP
IP IP
IP
Data Fragmented IP Packets Fragmented IP Packets

Data Link
Link Data
Data Link
Link
Physical
Physical Physical
Physical
Fig. 40 Datagram-centric transport
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
53
3.1.4 UDP Ports

UDP is mainly acting as an interface for applications to use when they need to send
or receive datagrams on an IP network. In order to perform this task, UDP has to
provide two basic services:
provide a way for applications to send data using IP
provide a way to get data it has received from IP back to the applications
These services are provided by a multiplexing component within the UDP software.
Applications must register with UDP, allowing it to map incoming and outgoing
messages to the appropriate applications protocols themselves.
16-bit port numbers that are assigned to specific applications by UDP provides this
multiplexing service. When an application wishes to communicate with the network, it
must request a port number from UDP. UDP will then use these port numbers for all
incoming and outgoing datagrams.
When an application wishes to send data over the network, it gives the data to UDP
through the assigned port number, also telling UDP which port on the destination
system the data should be sent to. UDP then creates a UDP datagram, marking the
source and destination port numbers, which is then passed off to IP for delivery.
Once the IP packet is received by the destination system, the IP software sees that
the data portion of the IP datagram contains a UDP message, and hands it off to
UDP for processing. The UDP software looks at the UDP header sees the destination
port number, and hands the payload portion of the datagram to whatever application
is using the specified port number.
As we have seen, a port specifies only a single instance of an application on a single
system. The term socket is used to identify the port number and IP address
concatenated together. Finally a socket pair consists of both endpoints, including the
IP addresses and port numbers of both applications on both systems. Multiple
connections between two systems must have unique socket pairs, with at least one
of the two endpoints having a different port number.
Although the concept of socket pairs with UDP is similar to TCP, there are some
fundamental differences that must be taken into consideration when looking at how
communication between processes works with UDP versus how connections work
with TCP. Most importantly, while TCP can maintain multiple virtual circuits on a
single port number through the use of socket pairs, UDP based applications do not
have this capability at all, and simply treat all data sent and received over a port
number as data for a single "connection".
For example, if a DNS server is listening for queries on port 53, then any queries that
come in to that port are treated as equal, with the DNS server handling the
multiplexing services required to distinguish between the different clients that are
issuing the distinct queries. This is the opposite of how TCP works, where the
transport protocol would create and manage virtual circuits for each of the
connections. With UDP, all data is treated as a single "connection", and the
application must manage any multiplexing services required on that port.
TG7020XEN02GLA1
Port Numbers
Server Client
DNS Server DNS Client

Port Number 53 Port Number randomly selected
TCP UDP UDP TCP UDP
IP IP
Data Link Data Link
Physical Physical
S D
D S
Fig. 41 Port numbers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
55
3.2 UDP Header and Datagram Format

Each UDP datagram is sent within a single IP datagram. Although, the IP datagram
may be fragmented during transmission, the receiving IP implementation will
reassemble it before presenting it to the UDP layer. All IP implementations are
required to accept datagrams of 576 bytes, which means that, allowing for maximum-
size IP header of 60 bytes, a UDP datagram of 516 bytes is acceptable to all
implementations. Many implementations will accept larger datagrams, but this is not
guaranteed.
The UDP datagram has an 8-byte header that is described in the table below:

Length
Source Port 16 bits Indicates the port of the sending process. It is the port to
which replies should be addressed.
Destination 16 bits Specifies the port of the destination process on the
Port destination host.
Length 16 bits The length (in bytes) of this user datagram, including the
header.
Checksum 16 bits An optional 16-bit one's complement of the one's
complement sum of a pseudo-IP header, the UDP
header, and the UDP data. The pseudo-IP header
contains the source and destination IP addresses, the
protocol, and the UDP length. By including the pseudo-
header in the calculations, the destination system is able
to validate that the sender and receiver are also correct,
in case the IP packet that delivered the UDP datagram
got mixed up en route to the final destination. If the
sender did compute a checksum and the receiver detects
a checksum error, the UDP datagram is silently
discarded. No error message is generated. If the
transmitted checksum is zero, it indicates the sender did
not compute the checksum. If the calculated checksum is
zero, it is stored as all one bits (65535), which is
equivalent in ones-complement arithmetic.
UDP Data variable The data portion in a UDP datagram. The minimum value
that is allowed in the length field is eight. That means,
there might be UDP datagrams exchanged between
hosts, which contain only the UDP header but no data.
TG7020XEN02GLA1
Encapsulation of a UDP Datagram
20 bytes 8 bytes variable length
UDP
UDP
IP
IP Header
Header UDP
UDP Data
Data
Header
Header
UDP Datagram
IP Packet
Fig. 42 Encapsulation of a UDP datagram
Encapsulation of a UDP Datagram

32 Bits
0 16 31
1 Version IHL Type of Service Total Length
2 Identification Flags Fragment Offset

IP
3 Time to Live Protocol = 17 (UDP) Header Checksum Header
4 Source Address
5 Destination Address
1 Source Port Destination Port UDP
2 Length Checksum Header
Data
Fig. 43 Encapsulation of a UDP datagram in more detail
TG7020XEN02GLA1
57
UDP Checksum Calculation

32 Bits
0 16 31
Source Address UDP

Pseudo
Destination Address
Header
Zero Protocol = 17 (UDP) UDP Length
Source Port Destination Port UDP
UDP Length Checksum Header
Data
Padding (0)
Fig. 44 UDP checksum calculation
TG7020XEN02GLA1
4 Exercises
TG7020XEN02GLA1
59
TG7020XEN02GLA1
Exercise 1
Title: Transport Layer Protocols
Objectives: Delegates are able to explain the basic concepts of the

Pre-requisite: None
Task
Please follow the instructions below.

Query
1. Mark the correct statements below. In the TCP/IP protocol suite application
protocols do not communicate with IP directly, but instead talk to one of two
transport protocols:
Transmission Control Protocol (TCP)
Internet Control Message Protocol (ICMP)
User Datagram Protocol (UDP)
2. Mark the correct statements below. The concepts of port and socket are needed
to determine which local process at a given host actually communicates with
which:
remote process
remote host
using which network layer protocol
using which transport layer protocol
3. Mark the correct statements below.

Well-known port numbers are typically even numbered
Well-known port numbers are typically odd numbered
Servers require only a single port, but there are exceptions
Servers require only a single port
TG7020XEN02GLA1
61
4. Mark the correct statement below. Clients do not need well-known port numbers
True
False
5. Complete the table below:
Term Description
Socket Special type of file handle, which is used by a process to
____________________________________________________
____________________________________________________
Socket Address
The triple: <_________________________________________>
Conversation
____________________________________________________
Association
The ____________________that completely specifies the two
processes that comprise a connection: <___________________
___________________________________________________>
Half-
association Either <___________________________________________> or
<__________________________________________________>
which specify each half of a connection.
TG7020XEN02GLA1
Exercise 2
Title: TCP Properties
Objectives: Delegates are able to name the properties of the Transmission

Control Protocol TCP
Pre-requisite: None
Task

Query
1. Mark the characteristics listed below, which you associate with the Transmission
Control Protocol:
connection-oriented
full duplex
end-to-end reliable
connectionless
multi-network application support
simplex
single-network application support
2. Mark the characteristics listed below, which you associate with the Basic Data
Transfer capability of the Transmission Control Protocol:
transfer a continuous stream of octets in each direction between its users by
packaging some number of octets into segments for transmission through the IP
network
transfer a continuous stream of octets in one direction between a sending user and
a receiving user by packaging some number of octets into segments for
transmission through the IP network
TCP decides when to block and forward data
Application programs decide when to block and forward data
TG7020XEN02GLA1
63
3. To achieve reliability, the TCP must recover from data that is damaged, lost,
duplicated, or delivered out of order by the IP network. Describe, how this is
achieved in principle.
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
4. Mark the characteristics listed below, which you associate with the Flow Control
capability of the Transmission Control Protocol:
the receiver controls the amount of data sent by the sender
the sender controls the amount of data sent
the window indicates an allowed number of octets a sender may transmit
5. Mark the correct statement(s) below:

To allow for many processes within a single host system to use TCP communication
facilities simultaneously, it supports the concept of:
TCP Multiplex Identification Number
Ports and Sockets
Application Multiplex Identification
6. How does TCP uniquely specify a virtual connection?
___________________________________________________________________
___________________________________________________________________
TG7020XEN02GLA1
Exercise 3
Title: TCP Header and Segment Format
Objectives: Delegates are able to name the TCP Header fields and
describe their tasks
Pre-requisite: None
Task
Complete the table and figure below:

Query
Table: TCP Header fields
Field Field Field Description
Name Length
TG7020XEN02GLA1
65
TG7020XEN02GLA1
TCP Header Fields
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
67
TG7020XEN02GLA1
Exercise 4
Title: TCP Virtual Connections
Objectives: Delegates are able to explain the basic concept of TCP virtual
connections
Pre-requisite: None
Task

Query
1. Describe the detailed segment flow to establish a TCP connection:
_________________________________________________________________
___________________________________________________________________
_______________________________________________________________
__
___________________________________________________________________
_______________________________________________________________
__
___________________________________________________________________
TG7020XEN02GLA1
69
2. Complete the figure below:
Telnet
Telnet Connect
Connect
IP: 192.168.109.143 IP: 192.168.109.142
3. Mark the correct statements below:

TCP maps fixed sized packets received from an application into TCP segments to
transmit them.
TCP divides the byte stream received from an application into TCP segments to
transmit them.
The window size is expressed as a number of bytes.
The window size is expressed as a number of packets.
it stays fixed for the connections lifetime.
is variable during the data transfer.
ACK messages do not include any window size information.
Each ACK message will include the window size that the receiver is ready to deal
with at that particular time.
A TCP segment only carries the sequence number of the first byte in the segment.
A TCP segment only carries the sequence number of the first packet in the
segment.
TG7020XEN02GLA1
4. Analyze the diagram below and answer the relevant questions:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 .. bytes
A
A B
B C
C D
D

Which event advances the trailing edge of the window?
_________________________________________________________________
Which event advances the leading edge of the sliding window?
_________________________________________________________________
How is the total window size determined?
_________________________________________________________________
5. There are essentially three cases closing a virtual circuit: List them!
_______________________________ ________________________
_______________________________
TG7020XEN02GLA1
71
TG7020XEN02GLA1
Exercise 5
Title: User Datagram Protocol UDP
Objectives: Delegates are able to name the properties of the User

Datagram Protocol UDP and to show the UDP header fields
and explain their use.
Pre-requisite: None
Task

Query
1. Mark the characteristics listed below, which you associate with the User
Datagram Protocol:
connection-oriented
unreliable
end-to-end reliable
connectionless
message-centric
2. Complete the table and figure below:

Table: UDP Datagram Fields
Length
TG7020XEN02GLA1
73

Length
UDP Datagram Format
32 Bits
0 16 31
1 UDP
2 Header
Fig. 48 UDP datagram format
TG7020XEN02GLA1
5 Solutions
TG7020XEN02GLA1
75
TG7020XEN02GLA1
Solution 1
Title: Transport Layer Protocols
Objectives: Delegates are able to explain the basic concepts of the

Pre-requisite: None
Task

Query
1. Mark the correct statements below. In the TCP/IP protocol suite application
protocols do not communicate with IP directly, but instead talk to one of two
transport protocols:
Transmission Control Protocol (TCP)
Internet Control Message Protocol (ICMP)
User Datagram Protocol (UDP)
2. Mark the correct statements below. The concepts of port and socket are needed
to determine which local process at a given host actually communicates with
which:
remote process
remote host
using which network layer protocol
using which transport layer protocol
3. Mark the correct statements below.

Well-known port numbers are typically even numbered
Well-known port numbers are typically odd numbered
Servers require only a single port, but there are exceptions
Servers require only a single port
TG7020XEN02GLA1
77
4. Mark the correct statement below. Clients do not need well-known port numbers
True
False
5. Complete the table below:
Term Description
Association The 5-tuple that completely specifies the two processes that
comprise a connection: <protocol, local-address, local-process,
foreign-address, foreign-process>
Half- Either <protocol, local-address, local-process> or
association <protocol, foreign-address, foreign-process> which specify
each half of a connection.
TG7020XEN02GLA1
Solution 2
Title: TCP Properties
Objectives: Delegates are able to name the properties of the Transmission
Control Protocol TCP
Pre-requisite: None
Task

Query
1. Mark the characteristics listed below, which you associate with the Transmission
Control Protocol:
connection-oriented
full duplex
end-to-end reliable
connectionless
simplex
2. Mark the characteristics listed below, which you associate with the Basic Data
Transfer capability of the Transmission Control Protocol:
transfer a continuous stream of octets in each direction between its users by
packaging some number of octets into segments for transmission through the IP
network
transfer a continuous stream of octets in one direction between a sending user and
a receiving user by packaging some number of octets into segments for
transmission through the IP network
TCP decides when to block and forward data
Application programs decide when to block and forward data
TG7020XEN02GLA1
79
3. To achieve reliability, the TCP must recover from data that is damaged, lost,
duplicated, or delivered out of order by the IP network. Describe, how this is
achieved in principle.
It is achieved by assigning a sequence number to each octet transmitted,
and requiring a positive acknowledgment (ACK) from the receiving TCP. If
the ACK is not received within a timeout interval, the data is retransmitted.
At the receiver, the sequence numbers are used to correctly order segments
that may be received out of order and to eliminate duplicates. Damage is
handled by adding a checksum to each segment transmitted, checking it at
the receiver, and discarding damaged segments.
4. Mark the characteristics listed below, which you associate with the Flow Control
capability of the Transmission Control Protocol:
the receiver controls the amount of data sent by the sender
the sender controls the amount of data sent
the window indicates an allowed number of octets a sender may transmit
5. Mark the correct statement(s) below:

To allow for many processes within a single host system to use TCP communication
facilities simultaneously, it supports the concept of:
TCP Multiplex Identification Number
Ports and Sockets
Application Multiplex Identification
6. How does TCP uniquely specify a virtual connection?

A pair of sockets identifying its two sides uniquely specifies each
connection.
TG7020XEN02GLA1
Solution 3
Title: TCP Header and Segment Format
Objectives: Delegates are able to name the TCP Header fields and
describe their tasks
Pre-requisite: None
Task

Query
Table: TCP Header fields
Length
Source Port 16 bits The source port number identifies the application that
generated the segment, as referenced by the TCP
port number in use by the application.
Destination Port 16 bits The destination port number identifies the application
that this segment is intended for, as referenced by the
16 bit TCP port number in use by the application on
the destination system.
Sequence Number 32 bits The sequence number of the first data octet in this
segment (except when SYN is present). If SYN is
present the sequence number is the initial sequence
number (ISN) and the first data octet is ISN+1.
Acknowledgment 32 bits If the ACK control bit is set this field contains the
Number value of the next sequence number the sender of the
segment is expecting to receive. Once a connection is
established this is always sent.
Data Offset 4 bits The number of 32 bit words in the TCP Header. This
indicates where the data begins. The TCP header
(even one including options) is an integral number of
32 bits long.
Reserved 6 bits Reserved for future use. Must be zero.
TG7020XEN02GLA1
81
Control Bits 6 bits URG: Urgent Pointer field significant

ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Window 16 bits The number of data octets beginning with the one
indicated in the acknowledgment field which the
sender of this segment is willing to accept.
Checksum 16 bits The checksum field is the 16 bit one's complement of
the one's complement sum of all 16 bit words in the
header and text. If a segment contains an odd
number of header and text octets to be
checksummed, the last octet is padded on the right
with zeros to form a 16 bit word for checksum
purposes. The pad is not transmitted as part of the
segment. While computing the checksum, the
checksum field itself is replaced with zeros.
Urgent Pointer 16 bits This field communicates the current value of the
urgent pointer as a positive offset from the sequence
number in this segment. The urgent pointer points to
the sequence number of the last octet in a sequence
of urgent data. This field is only to be interpreted in
segments with the URG control bit set.
Options variable Options may occupy space at the end of the TCP
header and are a multiple of 8 bits in length. All
options are included in the checksum. An option may
begin on any octet boundary.
Note that the list of options may be shorter than the
data offset field might imply. The content of the
header beyond the End-of-Option option must be
header padding (i.e., zero).
TCP Data variable The data portion in a TCP segment is optional. That
means, there are TCP segments exchanged between
hosts, which contain only the TCP header and
possible options but no data.
TG7020XEN02GLA1
TCP Header Fields

32 Bits
0 16 31
Sequence Number

Header
U A P R S F
Data
Offset
G K H T N N
Options and Padding
Data
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TG7020XEN02GLA1
83
TG7020XEN02GLA1
Solution 4
Title: TCP Virtual Connections
Objectives: Delegates are able to explain the basic concept of TCP virtual
connections
Pre-requisite: None
Task
Please answer the questions below.

Query
1. Describe the detailed segment flow to establish a TCP connection:
The requesting side (normally the client) sends a SYN segment specifying
the port number of the server that the client wants to connect to, and the
clients initial sequence number. This is the first segment.
The server responds with its own SYN segment containing the servers initial
sequence number. The server also acknowledges the clients SYN by ACKing
the clients ISN plus one. A SYN consumes one sequence number. This is the
second segment.
The client must acknowledge this SYN from the server by ACKing the
servers ISN plus one. This is the third segment.
TG7020XEN02GLA1
85
2. Complete the figure below:

Telnet
Telnet Connect
Connect
IP: 192.168.109.143 IP: 192.168.109.142
SYN SN=50627, ACK=0

SYN SN=1690412290 , ACK= 50628
ACK SN=50628 , ACK=1690412291
3. Mark the correct statements below:

TCP maps fixed sized packets received from an application into TCP segments to
transmit them.
TCP divides the byte stream received from an application into TCP segments to
transmit them.
The window size is expressed as a number of bytes.
The window size is expressed as a number of packets.
it stays fixed for the connections lifetime.
is variable during the data transfer.
ACK messages do not include any window size information.
Each ACK message will include the window size that the receiver is ready to deal
with at that particular time.
A TCP segment only carries the sequence number of the first byte in the segment.
A TCP segment only carries the sequence number of the first packet in the
segment.
TG7020XEN02GLA1
4. Analyze the diagram below and answer the relevant questions:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 .. bytes
A
A B
B C
C D
D

Which event advances the trailing edge of the window?

A received ACK advances the trailing edge of the window.
Which event advances the leading edge of the sliding window?
The receivers advertised window advances the leading edge of the sliding
window
How is the total window size determined?
Total Window size is minimum of senders buffer size and advertised
receiver window size
5. There are essentially three cases closing a virtual circuit: List them!
Local application initiates the close
Local TCP receives a FIN from the network
Both users close simultaneously
TG7020XEN02GLA1
87
TG7020XEN02GLA1
Solution 5
Title: User Datagram Protocol UDP
Objectives: Delegates are able to name the properties of the User

Datagram Protocol UDP and to show the UDP header fields
and explain their use.
Pre-requisite: None
Task

Query
1. Mark the characteristics listed below, which you associate with the User
Datagram Protocol:
connection-oriented
unreliable
end-to-end reliable
connectionless
message-centric

Length
Source Port 16 bits Indicates the port of the sending process. It is the port to
which replies should be addressed.
Destination 16 bits Specifies the port of the destination process on the
Port destination host.
Length 16 bits The length (in bytes) of this user datagram, including the
header.
TG7020XEN02GLA1
89
Checksum 16 bits An optional 16-bit one's complement of the one's

complement sum of a pseudo-IP header, the UDP
header, and the UDP data. The pseudo-IP header
contains the source and destination IP addresses, the
protocol, and the UDP length. By including the pseudo-
header in the calculations, the destination system is able
to validate that the sender and receiver are also correct,
in case the IP packet that delivered the UDP datagram
got mixed up en route to the final destination. If the
sender did compute a checksum and the receiver detects
a checksum error, the UDP datagram is silently
discarded. No error message is generated. If the
transmitted checksum is zero, it indicates the sender did
not compute the checksum. If the calculated checksum is
zero, it is stored as all one bits (65535), which is
equivalent in ones-complement arithmetic.
UDP Data variable The data portion in a UDP datagram. The minimum value
that is allowed in the length field is eight. That means,
there might be UDP datagrams exchanged between
hosts, which contain only the UDP header but no data.
UDP Datagram Format
32 Bits
0 16 31
1 Source Port Destination Port UDP

2 Length Checksum Header
Data
Fig. 52 UDP datagram format
TG7020XEN02GLA1

05 TG7020XEN02GLA1 App Transport Layer

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

05 TG7020XEN02GLA1 App Transport Layer

Încărcat de

Drepturi de autor:

Formate disponibile

Appendix - The Transport Layer

Appendix - The Transport Layer

1 Transport Layer Protocols

1.1 Introduction to the Transport Layer Protocols

TCP and UDP Properties

Transport Layer Protocols

TCP: connection oriented

unreliable, best effort

Fig. 2 Transport layer protocols

1.2 Ports and Sockets

HTTP Server HTTP Client

UDP TCP TCP UDP TCP

Data Link Data Link

Fig. 3 Port numbers

Some Well Known Port Numbers

20/21 23 25 80 53 69 67/68 161/162 Port Numbers

0806 0800 8035

Fig. 4 Some well-known port numbers

Socket Special type of file handle, which is used by a process to request

Socket Address The triple: <protocol, local-address, local-process>

Conversation Communication link between two processes.

Half-association Either <protocol, local-address, local-process> or

Connection and Socket Pairs

Fig. 6 Connection and socket pairs

2 Transmission Control Protocol (TCP)

2.1 TCP Properties

TCP in the Layered Protocol Architecture

Campus WAN Campus

Router Switch/ Switch/ Switch/ Router

TCP is a connection-oriented, end-to-end reliable protocol designed to fit into

Fig. 7 TCP in the layered protocol architecture

TCP Connection between Processes

. Port m . Reliable . Port n .

Fig. 8 TCP - connection between processes

2.1.2 Services provided by TCP

Transmission Control Protocol TCP

Fig. 9 Transmission control protocol

2.2 TCP Header and Segment Format

Field Name Field Field Description

Encapsulation of a TCP Segment

20 bytes 20 bytes variable length

Fig. 10 Encapsulation of a TCP segment in an IP packet

Encapsulation of a TCP Segment

1 Version IHL Type of Service Total Length

2 Identification Flags Fragment Offset

5 Checksum Urgent Pointer

Options and Padding

Fig. 11 Encapsulation of a TCP segment in more detail

Field Name Field Field Description

TCP Header Fields

Source Port Destination Port

TCP Acknowledgement Number

Checksum Urgent Pointer

Options and Padding

Fig. 12 TCP header fields

2.3 TCP Connections

Opening a Virtual Circuit in Passive Mode

TCP Send Buffer Receive Buffer TCP

Fig. 13 Opening a virtual circuit in passive mode

Local Connection Name

Transmission Control Block (TCB)

Opening a Virtual Circuit in Active Mode

Fig. 14 Opening a virtual circuit in active mode

Transmission Control Block TCB