Sie sind auf Seite 1von 90

The Transport Layer & Appendix

The Transport Layer & Appendix

Contents
1 Transport layer protocols 3
1.1 Introduction to the transport layer protocols 4
1.2 Ports and sockets 6
1.3 Client-server model 11
2 Transmission Control Protocol (TCP) 15
2.1 TCP properties 16
2.2 TCP header and segment format 20
2.3 TCP connections 24
2.4 Three-way handshake 28
2.5 Exchanging Data 32
2.6 The Window Principle Applied to TCP 36
2.7 Closing a virtual circuit 42
2.8 TCP options 46
3 User Datagram Protocol (UDP) 48
3.1 UDP properties 48
3.2 UDP header and datagram format 56
4 Exercises 59
5 Solutions 71
1 Appendix 83
1.1 Abbreviations 83

TG70115EN02GLA2
2010 Nokia Siemens Networks
1
The Transport Layer & Appendix

TG70115EN02GLA2
2 2010 Nokia Siemens Networks
The Transport Layer & Appendix

1 Transport layer protocols

Fig. 1 Layer 4

TG70115EN02GLA2
2010 Nokia Siemens Networks
3
The Transport Layer & Appendix

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.

TG70115EN02GLA2
4 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Transport Layer Protocols


Por
Ports
ts are
are
used
used to
to ad dress
address
an
an ap plicati on
applicati on

Mechanisms
Mechanisms for for
addressi
addressing
ng hi
higher
gher
llayer
ayer pr otocolls
protoco s
TCP: connecti on or iented
and r el iable
UDP: n ot con nection oriented,
not r eliable

unreli abl e, best effort

ser vice assumed

Fig. 2 Transport Layer Protocols

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

TG70115EN02GLA2
2010 Nokia Siemens Networks
5
The Transport Layer & Appendix

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
67/68 and the FTP (File Transfer Protocol) server, which uses 20/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.
Next to the Well Known Ports, there are Registered Ports and the Dynamic and/or
Private Ports. The User (Registered) Ports are those from 1024 through 49151.
The Dynamic and/or Private Ports are those from 49152 through 65535.
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 TCP segments/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 SCTP 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 SCTP.
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.

TG70115EN02GLA2
6 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Port Numbers

Ser ver Client

HTTP Server HTTP Clien t


Port N umber 80 Port Nu mber r an domly selected

SCTP UDP TCP SCTP UDP TCP

IP IP

Data Link D ata Link

Physical Physical
S D

D S

Fig. 3 Port Numbers

Some Well Known Port Numbers


TC P/IP
Lay ers
R LOGIN

BOOTP/
RLOGIN

BOOTP/
S MTP

CP

MP

M3UA
lnet

LDAP

DHCP

SNMP
POP3

M3UA
SMTP

HTTP

LDAP

TFTP
Telnet

POP3

IMAP

HTTP

TFTP
FTP
FTP

IMA

DH

SN
Te

44

Port Num be rs
(dec im al)
20/21 23 51 3 2 5 1 10 1 43 8 0 3 89 69 6 7/68 161 /1 62 29 05

33 TCP
TCP UD
UDPP SC
SCTP
TP

B
BGP
GP IC
ICMPv4
MPv4 OSPF
OSPF
17
06 Protocol
17 9 89 13 2
22 01 Numbe rs
AR (decim al)
ARPP IPv
IPv44 IPv6
IPv6 RA
RARP
RP

08 06 080 0 86dd 80 35 Type Codes or


11 Pac ket Types
Ether
Etherne
nett IEEE
IEEE 80
802.3
2.3 (hexa de cimal)

Fig. 4 Some Well Known Port Numbers

TG70115EN02GLA2
2010 Nokia Siemens Networks
7
The Transport Layer & Appendix

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-port_number>
For example, in the TCP/IP suite: <tcp, 193.44.234.3, 12345>
Conversation Communication link between two processes. (Interprocess
Communication)
Association The 5-tuple that completely specifies the two processes that
comprise a connection: <protocol, local-address, local-
port_number, foreign-address, foreign-port_number>
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-port_number> or
association <protocol, foreign-address, foreign-port_number> 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.

TG70115EN02GLA2
8 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Connection and Socket Pairs

Client A HT TP Server Client B


IP Addr .:10.27.51.3 IP Addr.:10.27.51.1 IP Addr.:10.27.51.2
Port Num ber : 1127 Port N umber: 80 Por t number: 1084

TCP TCP
10.27.51.3:1127 10.27.51.2:1084
10.27.51.1:80 10.27.51.1:80

Fig. 5 Connection and Socket Pairs

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

TG70115EN02GLA2
2010 Nokia Siemens Networks
9
The Transport Layer & Appendix

TG70115EN02GLA2
10 2010 Nokia Siemens Networks
The Transport Layer & Appendix

1.3 Client-server model


1.3.1 Overview of the client/server model
To understand how the Internet operates, it is important to understand the concept of
client/server computing. The client/server model is a form of distributed computing
where one program (the client) communicates with another program (the server) for
the purpose of exchanging information.
A server is an application that offers a service to users; a client is a requester of a
service. An application consists of both a server and a client part, which can run on
the same or on different systems. Users usually invoke the client part of the
application, which builds a request for a particular service and sends it to the server
part of the application using TCP/IP as a transport vehicle. The server receives this
request, performs the required service, and sends back the results in a reply. A
server can usually deal with multiple requests (multiple clients) at the same time.

Functions of the clients and the server


The client's responsibility is usually to:
1. Handle the user interface.
2. Translate the user's request into the desired protocol.
3. Send the request to the server and wait for the server's response.
4. Translate the response into "human-readable" results.
5. Present the results to the user.
The server's functions include:
1. Listen for a client's query.
2. Process that query.
3. Return the results back to the client.
A typical client/server interaction goes like this:
1. The user runs client software to create a query.
2. The client connects to the server.
3. The client sends the query to the server.
4. The server analyzes the query.
5. The server computes the results of the query.
6. The server sends the results to the client.
7. The client presents the results to the user.
8. Repeat as necessary.

TG70115EN02GLA2
2010 Nokia Siemens Networks
11
The Transport Layer & Appendix

1.3.2 How are the clients/server addressed?


The answer will be: Ports -the connection between the client/server and the TCP/IP.
Applications communicate with the transport protocols through the use of "ports",
which are unique I/O identifiers used by the transport protocols and the specific
instance of the application protocol.

Example
"Ports" are conceptually similar to the mailboxes used at your local post office. When
a letter comes in for recipient, it is placed into a known mailbox reserved for that
specific recipient. Whenever the recipient comes by, he will pick up any messages in
that mailbox and process the data at his convenience.

Reality
Similarly, ports provide TCP and UDP with a way to deliver data to higher-layer
application protocols. Every time an application protocol opens a connection to one of
the transport protocols, it will allocate a port from the transport protocol, and then use
that port for all network I/O. Any traffic that is destined for that particular application
will be routed to the appropriate port for the application to deal with.
Some servers wait for requests at a well-known port so their clients know to which
end point (IP socket, see chapter "The Transport Layer") to direct their requests. The
client uses an arbitrary port for its communication.
Some applications can open many simultaneous network connections, and in this
case, each instance would get its own port number.

TIP
For example an HTTP (Hypertext Transfer Protocol) server uses the well-known port
number 80. An HTTP client can choose the next available port number e.g. 1084
(another client e.g. 1127). Another client on another physical device can choose also
1084. These clients with the same port number are then distinguished with the help
of there different IP addresses.

TG70115EN02GLA2
12 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Client Client Client Server


A B C

Port Port Port Port

TCP/IP TCP/IP TCP/IP

IP Network
an arbitrary port well-known port

Fig. 6 Clients/server addressing

p p

HTTP- HTTP- HTTP-


HTTP-
Client Client Client
Server
A B C
Port Port Port Port
1084 1127 1084 80

TCP/IP TCP/IP TCP/IP

IP Network

an arbitrary port well-known port


of HTTP is 80

Fig. 7 HTTP client/server

TG70115EN02GLA2
2010 Nokia Siemens Networks
13
The Transport Layer & Appendix

TG70115EN02GLA2
14 2010 Nokia Siemens Networks
The Transport Layer & Appendix

2 Transmission Control Protocol (TCP)

TG70115EN02GLA2
2010 Nokia Siemens Networks
15
The Transport Layer & Appendix

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.
Standards:
RFC 793 - TCP
RFC 1122 - some error-corrections
RFC 1323 - TCP-Extensions
RFC 2581 - TCP Congestion Control

TG70115EN02GLA2
16 2010 Nokia Siemens Networks
The Transport Layer & Appendix

TCP in the Layered Protocol Architecture

WAN

C lient
Server
Rou ter Ro uter
Switch Switch Switch

App licatio n Ap plication


TTran
ransmission
smissio n Con troll Protoco
Co ntro Pro to coll (T
(TCP)
CP)
TTransp
ran sport
ort TTransp ortrt
ran spo
Netwo rk Netwo rk Netwo rk Network
Data Lin k Data L ink Data L ink Data L ink Data Link Data Link Data L ink
Ph ysical Physical Physical Physical Ph ysical Physical Physical

TCP is a co nnection -o rien ted , e nd-to -end reliable p ro to col d es igned to fit into a layered
hierarch y of protoco ls, wh ich su ppo rt m ulti-netwo rk app lication s.
The T CP pro vides fo r reliab le inter-pro ce ss c omm unication between pairs of pro cesses in
host com puters attach ed to d istinct bu t in tercon necte d com pu ter com mun icatio n netwo rks

Fig. 8 TCP in the Layered Protocol Architecture

TCP Connection between Processes

Host A Host B
Inter - Process
Comm unication
Process x Process y

. Port m . Rel iab le . Port n .


TCP Connecti on
TCP TCP

Unr el iable
IP Packets
IP IP

Fig. 9 TCP - Connection between Processes

TG70115EN02GLA2
2010 Nokia Siemens Networks
17
The Transport Layer & Appendix

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 Transfer
The TCP is able to 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. 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 and Security
The users of TCP may indicate the security and precedence of their
communication. Provision is made for default values to be used when these
features are not needed.

TG70115EN02GLA2
18 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Transmission Control Protocol (TCP)

Basic
Basic Data Transfer
(Full Duplex)

Reliability
TCP
TCP recovers
recovers from
from data that
that is
is damaged, lost,
lost,
duplicated,
duplicated, or
or delivered
delivered out ofof order
order

Flow
Flow control
by
by window
window size information
information

Multiplexing
Multiplexing / TCP Ports
Ports
(e.g.
(e.g. TELNET
TELNET -- port number
number 23)
23)

Connections
uniquely specified by
by a pair
pair of
of sockets
sockets

Optional Indication of
of Precedence and Security

Fig. 10 Transmission Control Protocol

Self adjusting Traffic Flows

New TCP Flow


TCP Flow 4

TCP Flow 3

TCP Flow 2

TCP Flow 1

Existing flows share the As a new flow joins into


available resources an existing flow set, a
new balance is found

Fig. 11 Self adjusting Traffic Flows

TG70115EN02GLA2
2010 Nokia Siemens Networks
19
The Transport Layer & Appendix

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.

TG70115EN02GLA2
20 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Encapsulation of a TCP Segment

20 bytes 20 bytes variable length

IIP
P HHeader
eader TCP
TCP Header
Head er TCP
T CP Data
D ata

TCP Segment

I P Packet

Fig. 12 Encapsulation of a TCP Segment in an IP Packet

Encapsulation of a TCP Segment


32 B its

0 16 31

1 Version IHL T yp e of Service To tal L ength

2 Id entificatio n F lags F rag men t Offset


IP
3 Tim e to L ive Protoco l = 6 (T CP) Head er Checksu m Head er
4 Source Ad dress
5 Destin atio n Add ress
1 Sou rce Po rt Destin atio n Port

2 Seque nce Num ber


3 Ackn owledg ement Num ber T CP
4 D ata Off. Reserved F lags Win do w Head er

5 C hecksum U rg ent Po inter

Op tio ns an d Padd ing

Data

Fig. 13 Encapsulation of a TCP Segment in more Detail

TG70115EN02GLA2
2010 Nokia Siemens Networks
21
The Transport Layer & Appendix

TCP header fields

Field Name Field Field Description


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.

TG70115EN02GLA2
22 2010 Nokia Siemens Networks
The Transport Layer & Appendix

TCP Header Fields


32 Bits

0 16 31

Sou rce Po rt Destination Po rt

Se quen ce Num ber

T CP Ackno wled gem ent Numb er


H eader
U A P R S F
Data
Re served R C S S Y I Windo w
Offset
G K H T N N

C hecksum Urgen t Poin ter

Option s and Pad din g

Data

Fig. 14 TCP Header Fields

TCP Trace Example

Fig. 15 TCP Capture

TG70115EN02GLA2
2010 Nokia Siemens Networks
23
The Transport Layer & Appendix

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.

2.3.1.1 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 will result in a new virtual circuit being
established.

TG70115EN02GLA2
24 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Opening a Virtual Circuit in Passive Mode


Cl ient Server

Telnet Telnet
OPEN (local por t, foreign socket, passive, etc. ) local
connectio n name
l ocal port = 23
. . . foreig n socket =
. Port 23 .
unq ual ified/quali fi ed LISTEN
TCB

TCP Recei ve B uffer TCP

Unr el iable
IP Packets
IP IP

Fig. 16 Opening a Virtual Circuit in Passive Mode

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

TG70115EN02GLA2
2010 Nokia Siemens Networks
25
The Transport Layer & Appendix

2.3.2 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.

2.3.2.1 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.

TG70115EN02GLA2
26 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Opening a Virtual Circuit in Active Mode

Client Server
Inter - Process
Comm unication
Telnet Telnet
local
O PEN (local port, for eign socket, active, etc.)
connection nam e
local port = 1038
. Por t 1038 . foreig n socket = . Port 23 .
SYN _SENT qualified (IP:23) LISTEN
TCB TCB
Set up reliable
TCP Send Buffer TCP Connection Receive B uffer TCP
SYN Segment

Unr eliable
IP Packets
IP IP

Fig. 17 Opening a Virtual Circuit in Active Mode

Transmission Control Block (TCB)

TCB contains
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. 18 Transmission Control Block TCB

TG70115EN02GLA2
2010 Nokia Siemens Networks
27
The Transport Layer & Appendix

2.4 Three-way handshake


Connection Establishment
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.

TG70115EN02GLA2
28 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Important Fields for Virtual Circuit Set-up

32 Bits

0 16 31

Sour ce Por t Destinatio n Port

Sequence Numb er

Acknowledg em ent Num ber

U A P R S F
Data
Reserved R C S S Y I Windo w
Offset
G K H T N N

Checksum Urgent Poin ter

Options and Pad ding

Fig. 19 Important TCP Header Fields for Virtual Circuit Set-up

TCP Connection Establishment


Three-way handshake
Telnet Client Telnet Server

Telnet
Telnet Connect
Connect

IP: 192.168.109.143 IP: 192.168.109.142

SYN SN=50627, ACK=0

SYN,ACK SN=1690412290 , ACK= 50628


Three-way Handshake"

ACK SN=50628 , ACK=1690412291

Fig. 20 Connection Establishment Protocol

TG70115EN02GLA2
2010 Nokia Siemens Networks
29
The Transport Layer & Appendix

Capture Sample: First Segment


Internet
Intern et Protoco l
Prot ocol (IP) :
( IP):
Source
Source Ad dress:: 192.168.1
Address 09.1433
192.1 68.109.14
Destinati on Addr
Destina tion ess: 192.
Ad dress: 168.109
192.168.1 .142
09.142
Transmis sion Con
Transm ission trol Pro
Control tocol
Protocol (TCP):
(TCP ):
Source
Source Po rt: 103
Port: 8
1 038
Destinati on Port
Destina tion : 23
Po rt: 23 (T elnet))
(Telnet
Sequence
Sequenc e Number:
Numbe r: 50627
5062 7
Acknowled gementt Number:
Acknowl edgemen Numbe r: 00
Header
Header Le ngth: 00x60
Length: x60
0110
0110 .. ..
.... 24
24 bytes
byte s -- Header
Heade r Length
Lengt h
....
.... 00 00
0000 No
Nott Used
Use d
Flags:
Flags: 0x 02
0x02
00..
00.. .. ..
.... No
Nott Used
Use d
..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. Sy nchronize
Synchro nize
....
.... .. .0
...0 No
No FIN
FIN
Window
Window Si ze: 819
Size: 2
8 192
CheckSum:
CheckSu m: 0x51CF
0x51 CF (Corre ct)
(C orrect)
Urgent
Urgent Po inter:: 00
Pointer
Options
Options PPresen
resent:t:
Kind:
Kind: 22 (Maxim um Segmen
(Max imum Se gment t Size)
Siz e)
Length:
Length: 44 bytes
byte s
Maximum
Maximum SSegmen
egmentt Size:
Size: 146
14600
[0
[0 bytes
byte s oof
f data]
dat a]

Fig. 21 Capture Sample: First Segment from Client to Server

Capture Sample: Second Segment


Inte rnet Pr
Internet otocoll
Protoco (IP):
(IP):
Sourc e Addre
S ource ss: 192.1
Add ress: 68.109.
1 92.168.10 142
9.142
Desti nationn Address:
D estinatio Addre ss: 192.168 .109.143
192.1 68.109. 143
Tran smissio
Transmiss ionn Control
Con trol Protoc ol
Prot ocol (TC P):
( TCP):
Sourc e Port:
S ource Por t: 23
23 (Te lnet)
(Telnet)
Desti nationn Port:
D estinatio Port: 103
10388
Seque nce Num
S equence ber: 1690
N umber: 4122900
169041229
Ackno wledgem
A cknowledg ent Numbe
ement r: 5062
N umber: 8
50 628
Heade r Lengt
H eader h: 0x60
Len gth: 0x 60
011
01100 ....
... . 24
24 byt es -- Hea
bytes der Leng
Header th
Length
...
..... 0000
000 0 Not
Not Us ed
Used
Flags : 0x12
F lags: 0x1 2
00.
00... ....
... . Not
Not Us ed
Used
..0
..0.. ....
... . No
No URG
URG
...
...11 ....
... . Acknow ledgemen
Ack nowledge t
ment
...
..... 0...
0.. . No
No PSH
PSH
...
..... .0..
.0. . No
No RST
RST
...
..... ..1.
..1 . Synchr onize
Syn chronize
...
..... ...0
... 0 No
No FIN
FIN
Windo w Size:
W indow Siz e: 4128
4128
Check Sum: 0x
C heckSum: 57DA
0x57DA (C orrect)
(Correc t)
Urgen t Point
U rgent er: 00
Poi nter:
Optio ns Pres
O ptions ent:
Pr esent:
Kind:
K ind: 22 (M aximumm Se
(Maximu gment SSize)
Segment ize)
Lengt h: 44 by
L ength: tes
bytes
Maxim um Segm
M aximum ent Size:
Se gment S ize: 1460
1460
[0
[0 byt es of
bytes of ddata]
ata]

Fig. 22 Capture Sample: Second Segment from Server to Client

TG70115EN02GLA2
30 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Capture Sample: Third Segment

Inte rnet Pr
Internet otocoll
Protoco (IP):
(IP):
Sourc e Addre
S ource ss: 192.1
Add ress: 68.109.
1 92.168.10 143
9.143
Desti nationn Address:
D estinatio Addre ss: 192.168 .109.142
192.1 68.109. 142
Tran smissio
Transmiss ionn Control
Con trol Protoc ol
Prot ocol (TC P):
( TCP):
Sourc e Port:
S ource Por t: 1038
1038
Desti nationn Port:
D estinatio Port: 2323 (Teln et)
(Te lnet)
Seque nce Num
S equence ber: 5062
N umber: 506288
Ackno wledgem
A cknowledg ent Numbe
ement r: 1690
N umber: 4122911
16 9041229
Heade r Lengt
H eader h: 0x50
Len gth: 0x 50
010
01011 ....
... . 20
20 byt es -- Hea
bytes der Leng
Header th
Length
...
..... 0000
000 0 Not
Not Us ed
Used
Flags : 0x10
F lags: 0x1 0
00.
00... ....
... . Not
Not Us ed
Used
..0
..0.. ....
... . No
No URG
URG
...
...11 ....
... . Acknow ledgemen
Ack nowledge t
ment
...
..... 0...
0.. . No
No PSH
PSH
...
..... .0..
.0. . No
No RST
RST
...
..... ..0.
..0 . No
No SYN
SYN
...
..... ...0
... 0 No
No FIN
FIN
Windo w Size:
W indow Siz e: 8760
8760
Check Sum: 0x
C heckSum: 5D7F
0x5D7F (C orrect)
(Correc t)
Urgen t Point
U rgent er: 00
Poi nter:
[0
[0 byt es of
bytes of ddata]
ata]

Fig. 23 Capture Sample: Third Segment from Client to Server

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

TG70115EN02GLA2
2010 Nokia Siemens Networks
31
The Transport Layer & Appendix

2.5 Exchanging Data


2.5.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.
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.

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 Send Buffer Receive Buffer TCP


TCP Segment

Unreliable
IP Packets
IP IP

Fig. 24 Application SEND

TG70115EN02GLA2
32 2010 Nokia Siemens Networks
The Transport Layer & Appendix

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 Send Buffer Receive Buffer TCP
TCP Segment

Unreliable
IP Packets
IP IP

Fig. 25 Application RECEIVE

Exchanging Data

Te lnet Cl ient Te lnet S erv er

Receive Buffer

14144
SN=14144, DATA 100 byte 100 bytes

? 14244
ACK, ACK= 14244 100 bytes

100 bytes 14344


14244 SN=14244 , DAT A 100 byte

14144 100 bytes

Send Buffer

Fig. 26.Exchanging Data

TG70115EN02GLA2
2010 Nokia Siemens Networks
33
The Transport Layer & Appendix

2.5.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.
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 the figure below.
At the moment the sender receives ACK 1 (acknowledgment for packet 1), it can
slide its window one packet to the right.
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. 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.

TG70115EN02GLA2
34 2010 Nokia Siemens Networks
The Transport Layer & Appendix

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. 27 The Window Principle

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. 28 The Window Principle (cont.)

TG70115EN02GLA2
2010 Nokia Siemens Networks
35
The Transport Layer & Appendix

2.6 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 the figure below.

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.

TG70115EN02GLA2
36 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Fields for Flow Control


32 Bits

0 16 31

So urce Port Destination Por t

Sequence Num ber

TCP Acknowledgement N umber


Header
U A P R S F
Data
Reser ved R C S S Y I Wind ow
Offset
G K H T N N

Ch ecksum Urg ent Po inter

Optio ns and Padding

Data

Fig. 29 TCP Header Fields for Flow Control

The Window Principle applied to TCP

Total Window size is minimum of senders buffer size and advertised r eceiver window size

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 .. bytes

A B
B C
C 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. 30 The Window Principle applied to TCP

TG70115EN02GLA2
2010 Nokia Siemens Networks
37
The Transport Layer & Appendix

2.6.1 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.
The figures below illustrate 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.

TG70115EN02GLA2
38 2010 Nokia Siemens Networks
The Transport Layer & Appendix

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
Segment 3 (Seq. Nr. 2500)
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

RT O. . . R etransmission Timeout

Fig. 31 Acknowledgement and Retransmission: Case 1

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
Segment 3 (Seq. Nr. 2500)
Receives ACK 2000 and Segment 2 gets lost
slides window
Segment 4 (Seq. Nr. 3000) Segment 3 gets lost
Window size reached, Receives Segment 4
waiting for ACK R and replies with ACK 2000
Receives ACK 2000, T
which does not slide O
the window

Timeout for Segment 2


Retransmission

RTO. . . Retransmission Timeout

Fig. 32 Acknowledgement and Retransmission: Case 2

TG70115EN02GLA2
2010 Nokia Siemens Networks
39
The Transport Layer & Appendix

2.6.2 Round Trip Time

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.

TG70115EN02GLA2
40 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Round Trip Time (RTT)

Sender Receiver
Retransmission
Timer

Segment 1 (Seq. Nr. 1500)


Segment 2 (Seq. Nr. 2000)
Receives Segment 1
Segment 3 (Seq. Nr. 2500) (Seq. Nr. 1500), sends ACK 2000
Receives ACK 2000 and Receives Segment 2
slides window and replies with ACK 2500
Segment 4 (Seq. Nr. 3000)
Receives ACK 2500 and
slides window
RTT -> calculate new RTO
RTT -> calculate new RTO

Fig. 33 Round Trip Time RTT

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

TG70115EN02GLA2
2010 Nokia Siemens Networks
41
The Transport Layer & Appendix

2.7 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 bi-directional 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
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.

TG70115EN02GLA2
42 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Connection Termination

Telnet Client Telnet Server

Telnet
Telnet Disconnect
Disconnect

IP: 192.168.109.143 IP: 192.168.109.142

ACK,FIN SN=1690413347, ACK= 50691

ACK SN=50691, ACK=1690413348 Closing the Connection

ACK,FIN SN=50691, ACK=1690413348

ACK SN=1690413348, ACK= 50692

Fig. 34 Connection Termination

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

TG70115EN02GLA2
2010 Nokia Siemens Networks
43
The Transport Layer & Appendix

2.7.1 Capture Sample: Telnet Disconnect First Segment


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

2.7.2 Capture Sample: Telnet Disconnect Second Segment


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

TG70115EN02GLA2
44 2010 Nokia Siemens Networks
The Transport Layer & Appendix

2.7.3 Capture Sample: Telnet Disconnect Third Segment


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

2.7.4 Capture Sample: Telnet Disconnect Fourth Segment


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

TG70115EN02GLA2
2010 Nokia Siemens Networks
45
The Transport Layer & Appendix

2.8 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 a 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 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).

TG70115EN02GLA2
46 2010 Nokia Siemens Networks
The Transport Layer & Appendix

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 a
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 maximu m allowed
by the Window field of the T CP header.

4 Select. Acknowledg ement Used to allow the use of selective


Permitted acknowledgemen ts on virtual circuits.

5 Selective The selective acknow ledgement, if permitted by


Acknowle dgement option kind 4 .

8 Timestamp Used to determin e the round-trip delivery time for


a segment, allowing the two end points to
determine reasonable acknowledgement timers.

Fig. 35 TCP Options

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

TG70115EN02GLA2
2010 Nokia Siemens Networks
47
The Transport Layer & Appendix

3 User Datagram Protocol (UDP)


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.

RFC 768 User Datagram Protocol (UDP), 28 Aug 1980

TIP
RFC 3828 The Lightweight User Datagram Protocol (UDP-Lite), July 2004
UDP-Lite is similar to the UDP (RFC 768), but can also serve applications in error-
prone network environments that prefer to have partially damaged payloads delivered
rather than discarded. If this feature is not used, UDP-Lite is semantically identical to
UDP.
UDP-Lite has been allocated a separate IP protocol identifier: 136 (UDPLite), that
allows a receiver to identify whether UDP or UDP-Lite is used.

TG70115EN02GLA2
48 2010 Nokia Siemens Networks
The Transport Layer & Appendix

UDP in the Layered Protocol Architecture

WAN

Server
Cl ient Rou ter Ro uter
Switch Switch Switch

A ppl icatio n App licatio n


UUser
ser Datag
Datagram
ram Pro
Proto
toco
coll (U DP)
(UDP)
Transp ortrt
T ranspo TTrans
ranspo rt
port
Netwo rk Network Network N etwork
Data Lin k D ata L ink D ata L ink Da ta Li nk Data L ink D ata L ink D ata L ink
Ph ysical Physical Physical Physical Physica l Physical Physical

UDP is a con necti onless, en d-to -end unreliab le protoco l desig ned to fit in to a layered
hierarch y of protoco ls, wh ich su ppo rt m ulti-netwo rk app lication s.

Fig. 36 UDP in the Layered Protocol Architecture

Communication between Processes

Host A Host B
Inter - Process
Comm unication
Process x Process y

. Port m . Unr eliable . Port n .


UDP Com munication
UDP UDP
Unr eliable
IP Packets
IP IP

Fig. 37 Communication between Processes

TG70115EN02GLA2
2010 Nokia Siemens Networks
49
The Transport Layer & Appendix

3.1.2 Lightweight Protocol


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.

3.1.3 Broadcast and Multicast Capability


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.

3.1.4 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.

TG70115EN02GLA2
50 2010 Nokia Siemens Networks
The Transport Layer & Appendix

User Datagram Protocol (UDP)

Lightweight-Protocol
Low Overhead
Limited Reliability
UDP does not recover from data that is damaged,
lost, duplicated, or delivered out of order
Message-centric
Multiplexing / UDP Ports
(e.g. TFTP - port number 69)
Connectionless
Broadcast and Multicast Capability

Fig. 38 User Datagram Protocol UDP

Datagram-centric Transport

Clien t Server

App licatio n
Ap plication Data
Data DData
ata Appl icatio nn
App licatio

UDP
UD P UDP Datagram UDP Data gram UDP
UDP

IP Packet IP Packet
IP
IP IP
IP

DData
ata LLink Fragm ented IP Pac kets F ragme nted IP Packets Data
ink Data Lin
Linkk

Physical
Physical Ph
Physical
ysical

Fig. 39 Datagram-centric Transport

TG70115EN02GLA2
2010 Nokia Siemens Networks
51
The Transport Layer & Appendix

TG70115EN02GLA2
52 2010 Nokia Siemens Networks
The Transport Layer & Appendix

3.1.5 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.

TG70115EN02GLA2
2010 Nokia Siemens Networks
53
The Transport Layer & Appendix

3.1.6 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.

TG70115EN02GLA2
54 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Port Numbers

Ser ver Client

DNS Server DNS Clien t


Port N umber 53 Port Nu mber r an domly selected

UDP UDP UD P

IP IP

Data Link D ata Link

Physical Physical
S D

D S

Fig. 40 Port Numbers

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

TG70115EN02GLA2
2010 Nokia Siemens Networks
55
The Transport Layer & Appendix

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:

Field Name Field Field Description


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.

TG70115EN02GLA2
56 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Encapsulation of a UDP Datagram

20 b ytes 8 bytes var iable length

UDP
UDP
IP
IP Head er
Header UDP
UDP Data
Data
Head er
Header

UDP Datagram

IP Packet

Fig. 41 Encapsulation of a UDP Datagram

Encapsulation of a UDP Datagram

32 Bits

0 16 31

1 Versio n IHL T ype o f Service T otal Leng th

2 Identification Flag s Fragm ent Offset


IP
3 T ime to Live Protoco l = 17 (U DP) Header Ch ecksum Header
4 So urce Add ress
5 Destination Ad dress
1 So urce Port Destination Po rt UDP
2 Len gth Checksu m Header

Data

Fig. 42 Encapsulation of a UDP Datagram in more Detail

TG70115EN02GLA2
2010 Nokia Siemens Networks
57
The Transport Layer & Appendix

UDP Checksum Calculation

32 Bits

0 16 31

Sou rce Address UDP


Pseu do
Destin atio n Ad dress
Header
Zero Pro to col = 17 (UDP) UDP L ength

Sou rc e Po rt Destin atio n Port U DP


UDP L ength Checksu m Head er

Data

Pad din g (0)

Fig. 43 UDP Checksum Calculatio

UDP Trace Example

Fig. 44 UDP trace example

TG70115EN02GLA2
58 2010 Nokia Siemens Networks
The Transport Layer & Appendix

4 Exercises

Fig. 45

TG70115EN02GLA2
2010 Nokia Siemens Networks
59
The Transport Layer & Appendix

Exercise 1
Title: Transport Layer Protocols

Objectives: Delegates are able to explain the basic concepts of the


Transport Layer Protocols
Pre-requisite: None

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:
a) Transmission Control Protocol (TCP)
b) Internet Control Message Protocol (ICMP)
c) 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:
a) remote process
b) remote host
c) using which network layer protocol
d) using which transport layer protocol

3. Mark the correct statements below.


a) Servers require only a single port, but there are exceptions
b) Servers require only a single port

4. Mark the correct statement below. 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.
a) True
b) False

TG70115EN02GLA2
60 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Exercise 2
Title: TCP Properties

Objectives: Delegates are able to name the properties of the Transmission


Control Protocol TCP
Pre-requisite: None

Please follow the instructions below.


Query
1. Mark the characteristics listed below, which you associate with the Transmission
Control Protocol:
a) connection-oriented
b) full duplex
c) end-to-end reliable
d) connectionless
e) multi-network application support
f) simplex
g) single-network application support

2. Mark the characteristics listed below, which you associate with the Basic Data
Transfer capability of the Transmission Control Protocol:
a) 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
b) 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
c) TCP decides when to block and forward data
d) Application programs decide when to block and forward data

TG70115EN02GLA2
2010 Nokia Siemens Networks
61
The Transport Layer & Appendix

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:
a) the receiver controls the amount of data sent by the sender
b) the sender controls the amount of data sent
c) 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:
a) TCP Multiplex Identification Number
b) Ports and Sockets
c) Application Multiplex Identification

6. How does TCP uniquely specify a virtual connection?

___________________________________________________________________

___________________________________________________________________

TG70115EN02GLA2
62 2010 Nokia Siemens Networks
The Transport Layer & Appendix

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

Complete the table and figure below:


Query
Table: TCP Header fields
Field Name Field Length Field Description

TG70115EN02GLA2
2010 Nokia Siemens Networks
63
The Transport Layer & Appendix

Field Name Field Field Description


Length

TCP Header Fields

Fig. 46 TCP Header Fields

TG70115EN02GLA2
64 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Exercise 4
Title: TCP Virtual Connections

Objectives: Delegates are able to explain the basic concept of TCP virtual
connections
Pre-requisite: None

Please follow the instructions below.


Query
1. Describe the detailed segment flow to establish a TCP connection:
_________________________________________________________________

___________________________________________________________________

_________________________________________________________________

___________________________________________________________________

_________________________________________________________________

___________________________________________________________________

TG70115EN02GLA2
2010 Nokia Siemens Networks
65
The Transport Layer & Appendix

2. Complete the figure below:

Connection Establishment Protocol

Telnet Client Telnet Server

Telnet
Telnet Connect
Connect

IP: 192.168.109.143 IP: 192.168.109.142

Three-way Handshake"

Fig. 47 Connection Establishment Protocol

3. Mark the correct statements below:


a) TCP maps fixed sized packets received from an application into TCP
segments to transmit them.
b) TCP divides the byte stream received from an application into TCP segments
to transmit them.
c) The window size is expressed as a number of bytes.
d) The window size is expressed as a number of packets.
e) The receiver determines the window size when the connection is established,
and it stays fixed for the connections lifetime.
f) The receiver determines the window size when the connection is established,
and is variable during the data transfer.
g) ACK messages do not include any window size information.
h) Each ACK message will include the window size that the receiver is ready to
deal with at that particular time.
i) A TCP segment only carries the sequence number of the first byte in the
segment.
j) A TCP segment only carries the sequence number of the first packet in the
segment.

TG70115EN02GLA2
66 2010 Nokia Siemens Networks
The Transport Layer & Appendix

4. Analyze the diagram below and answer the relevant questions:

The Window Principle applied to TCP

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 .. bytes

A B
B C
C D

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. 48 The Window Principle applied to TCP

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!

_______________________________ ______________________________

_______________________________

TG70115EN02GLA2
2010 Nokia Siemens Networks
67
The Transport Layer & Appendix

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

Please follow the instructions below.


Query
1. Mark the characteristics listed below, which you associate with the User
Datagram Protocol:
a) connection-oriented
b) unreliable
c) end-to-end reliable
d) connectionless
e) multi-network application support
f) message-centric
g) single-network application support

2. Complete the table and figure below:


Table: UDP Datagram Fields
Field Name Field Field Description
Length

TG70115EN02GLA2
68 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Field Name Field Field Description


Length

UDP Datagram Format

32 Bits

0 16 31

1
UDP
2 Header

Fig. 49 UDP Datagram Format

TG70115EN02GLA2
2010 Nokia Siemens Networks
69
The Transport Layer & Appendix

TG70115EN02GLA2
70 2010 Nokia Siemens Networks
The Transport Layer & Appendix

5 Solutions

Fig. 50

TG70115EN02GLA2
2010 Nokia Siemens Networks
71
The Transport Layer & Appendix

Solution 1
Title: Transport Layer Protocols

Objectives: Delegates are able to explain the basic concepts of the


Transport Layer Protocols
Pre-requisite: None

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:
a) Transmission Control Protocol (TCP)
b) Internet Control Message Protocol (ICMP)
c) 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:
a) remote process
b) remote host
c) using which network layer protocol
d) using which transport layer protocol

3. Mark the correct statements below.


a) Servers require only a single port, but there are exceptions
b) Servers require only a single port

4. Mark the correct statement below. 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.
a) True
b) False

TG70115EN02GLA2
72 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Solution 2
Title: TCP Properties

Objectives: Delegates are able to name the properties of the Transmission


Control Protocol TCP
Pre-requisite: None

Please follow the instructions below.


Query
1. Mark the characteristics listed below, which you associate with the Transmission
Control Protocol:
a) connection-oriented
b) full duplex
c) end-to-end reliable
d) connectionless
e) multi-network application support
f) simplex
g) single-network application support

2. Mark the characteristics listed below, which you associate with the Basic Data
Transfer capability of the Transmission Control Protocol:
a) 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
b) 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
c) TCP decides when to block and forward data
d) Application programs decide when to block and forward data

TG70115EN02GLA2
2010 Nokia Siemens Networks
73
The Transport Layer & Appendix

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:
a) the receiver controls the amount of data sent by the sender
b) the sender controls the amount of data sent
c) 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:
a) TCP Multiplex Identification Number
b) Ports and Sockets
c) Application Multiplex Identification

6. How does TCP uniquely specify a virtual connection?


A pair of sockets identifying its two sides uniquely specifies each
connection.

TG70115EN02GLA2
74 2010 Nokia Siemens Networks
The Transport Layer & Appendix

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

Complete the table and figure below:


Query
Table: TCP Header fields
Field Name Field Field Description
Length
Source Port 16 bits The source port number identifies the application that
generated the segment,
Destination Port 16 bits The destination port number identifies the application
that this segment is intended for,
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.
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.
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.

TG70115EN02GLA2
2010 Nokia Siemens Networks
75
The Transport Layer & Appendix

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 variable The data portion in a TCP segment is optional. That means,
Data there are TCP segments exchanged between hosts, which
contain only the TCP header and possible options but no data.

TCP Header Fields


32 Bits

0 16 31

Sou rce Po rt Destinatio n Port

Sequence Numb er

T CP Ackno wled gement Num ber


Header
U A P R S F
Data
Reserved R C S S Y I Wind ow
Offset
G K H T N N

Ch ecksum Urgent Poi nter

Optio ns and Padding

Data

Fig. 51 TCP Header Fields

TG70115EN02GLA2
76 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Solution 4
Title: TCP Virtual Connections

Objectives: Delegates are able to explain the basic concept of TCP virtual
connections
Pre-requisite: None

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.

TG70115EN02GLA2
2010 Nokia Siemens Networks
77
The Transport Layer & Appendix

2. Complete the figure below:

Connection Establishment Protocol

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"

ACK,SYN SN=1690412290 , ACK= 50628

ACK SN=50628 , ACK=1690412291

Fig. 52 Connection Establishment Protocol

3. Mark the correct statements below:


a) TCP maps fixed sized packets received from an application into TCP
segments to transmit them.
b) TCP divides the byte stream received from an application into TCP segments
to transmit them.
c) The window size is expressed as a number of bytes.
d) The window size is expressed as a number of packets.
e) The receiver determines the window size when the connection is established,
and it stays fixed for the connections lifetime.
f) The receiver determines the window size when the connection is established,
and is variable during the data transfer.
g) ACK messages do not include any window size information.
h) Each ACK message will include the window size that the receiver is ready to
deal with at that particular time.
i) A TCP segment only carries the sequence number of the first byte in the
segment.
j) A TCP segment only carries the sequence number of the first packet in the
segment.

TG70115EN02GLA2
78 2010 Nokia Siemens Networks
The Transport Layer & Appendix

4. Analyze the diagram below and answer the relevant questions:

The Window Principle applied to TCP

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 .. bytes

A B
B C
C D

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. 53 The Window Principle applied to TCP

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

TG70115EN02GLA2
2010 Nokia Siemens Networks
79
The Transport Layer & Appendix

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

Please follow the instructions below.


Query
1. Mark the characteristics listed below, which you associate with the User
Datagram Protocol:
a) connection-oriented
b) unreliable
c) end-to-end reliable
d) connectionless
e) multi-network application support
f) message-centric
g) single-network application support

Complete the table and figure below:

Field Name Field Field Description


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.

TG70115EN02GLA2
80 2010 Nokia Siemens Networks
The Transport Layer & Appendix

Field Name Field Field Description


Length

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 So urce Po rt D estinatio n Port UDP


2 Length Checksum Header

Data

Fig. 54 UDP Datagram Format

TG70115EN02GLA2
2010 Nokia Siemens Networks
81
The Transport Layer & Appendix

TG70115EN02GLA2
82 2010 Nokia Siemens Networks
The Transport Layer & Appendix

6 Appendix
o

6.1 Abbreviations

A
AAL5 ATM Adaptation Layer 5
AES Advanced Encryption Standard
AH Authentication Header
ALG Application Layer Gateway
Anycast Address A special IPv6 address.
is a special type of unicast address that is assigned to interfaces
on multiple hosts. Packets sent to such an address will be
delivered to the nearest interface with that address. Routers
determine the nearest interface based upon their definition of
distance.
AP Access point
API Application Programming Interface
ARP Address Resolution Protocol
AS Autonomous System
ASN.1 Abstract Syntax Notation 1
ATM Asynchronous Transfer Mode
B
BGP Border Gateway Protocol
BOOTP Boot Protocol
BPDU Bridge Protocol Data Unit
broadcast Broadcast is a special case of multicast, and is the group of all
stations.
broadcast domain A broadcast domain is a domain in which a broadcast will be
forwarded.
A broadcast domain is limited with a router port. A broadcast
domain can consist of a lot of collision domains.
C
CCP Compression Control Protocol

TG70115EN02GLA2
2010 Nokia Siemens Networks
83
The Transport Layer & Appendix

CHAP Challenge Handshake Authentication Protocol


PPP contains protocols to authenticate subscribers, e.g. PAP,
CHAP or MSCHAP. These are optional.
CIDR Classless Inter Domain Routing
client A client is a requester of a service.
client/server model The client/server model is a form of distributed computing where
one program (the client) communicates with another program
(the server) for the purpose of exchanging information.
collision domain A collision domain is formally defined as a single Carrier Sense
Multiple Access with Collision Detect (CSMA/CD) network in
which there will be a collision if two stations attached to the
system transmit at the same time.
CSMA/CA Carrier Sense Multiple Access / Collision Avoidance
CSMA/CD Carrier Sense Multiple Access with Collision Detection
This access method is used in Ethernet.
cut-through With the cut-through switching method, the LAN switch copies
only the destination address (the first 6 bytes following the
preamble) into its onboard buffers.
D
DA Destination Address
DF Don't Fragment
DHCP Dynamic Host Configuration Protocol
DIX Manufacturers Digital, Intel and Xerox
DNS Domain Name System
DSL Digital Subscriber Line
DSSS Direct Sequence Spread Spectrum
DVR Distance Vector Routing
E
EAP Extensible Authentication Protocol, RFC 3748
ECP Encryption Control Protocol
EGP Exterior Gateway Protocol
ESP Encapsulating Security Payload
ESSID Access points are defined by Extended Service Set Identification
(ESSID), which is part of the IEEE 802.11 standard. Clients need
to be configured with the access point's ESSID in order to
communicate. Multiple access points on the same subnet should
have the same ESSID and allow for roaming

TG70115EN02GLA2
84 2010 Nokia Siemens Networks
The Transport Layer & Appendix

F
FHSS Frequency Hopping Spread Spectrum
FIB Forwarding Information Base (FIB)
flooding all ports The forwarding operation to all ports except the source port is
called flooding all ports.
FTP File Transfer Protocol
G
GPRS General Packet Radio Service
H
HDLC High-Level Data Link Control Protocol
HTML Hypertext Makeup Language
HTTP Hypertext Transfer Protocol
I
I/O Input/Output
IANA Internet Assigned Numbers Authority
ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineers
IEEE 802.1D The operation of bridges and switches is specified in the IEEE
802.1D standard, which provides rules for forwarding (switching)
an Ethernet frame from one port to another, based on the
destination address of the frame.
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IGP Interior Gateway Protocol
IHL Internet header length
IMAP Internet Message Access Protocol
INAP Intelligent Network Application Part
IP Internet Protocol
IPCP IP Network Control Protocol
IPng IP next Generation
IPSec IP Security Protocol
IPv4 IP version 4
IPv6 IP version 6
ISM Industrial Scientific Medical

TG70115EN02GLA2
2010 Nokia Siemens Networks
85
The Transport Layer & Appendix

Unregulated 900-MHz, 2.4-GHz and 5.7-GHz bands that require


no licensing fee.
ISUP ISDN User Part
IR Industrial Scientific Medical
Unregulated 900-MHz, 2.4-GHz and 5.7-GHz bands that require
no licensing fee.
IS-IS Intermediate System to Intermediate System Protocol
ISO International Organization for Standardization
ISOC Internet Society
ITU International Telecommunication Union
L
LCP Link Control Protocol
One part of PPP for configuring the connection and negotiating
options of a point to point link. LCP serves to set up, configure
and, where necessary, test a point to point connection.
LDAP Lightweight Directory Access Protocol
Link-local A special IPv6 address.
address Addresses of this kind can be used only on the physical network
that a host's interface is attached to.
LLC Logical Link Control
logical link control sublayer of the data link layer (OSI Layer 2)
LPDU LLC protocol data unit
LSP Link State Packet
LSR Link State Routing
M
MAC Media Access Control
Media Access Control Sublayer
of the data link layer (OSI Layer 2)
MEGACO Media Gateway Control Protocol
MF more fragments (in IPv4 a flag that indicates that more IP
fragments with higher fragment offset values should follow)
MIME Multipurpose Internet Mail Extensions
MP Multilink Protocol
MPLS Multiprotocol Label Switching
MSCHAP Micro Soft challenge handshake authentication protocol

TG70115EN02GLA2
86 2010 Nokia Siemens Networks
The Transport Layer & Appendix

PPP contains protocols to authenticate subscribers, e.g. PAP,


CHAP or MSCHAP. These are optional.
MTP Message Transfer Part
MTU Maximum Transmission Unit
multicast A multicast address is a group address that multiple interfaces
can be configured to receive.
Multicast Is used as an identifier assigned to a set of interfaces on multiple
Address hosts. Packets sent to that address would be delivered to all
interfaces corresponding to that address.
N
NAPT Network Address Port Translation
NAT Network Address Translation, NAT is defined in RFC 3022
NAT-PT Network Address Translation - Protocol Translation
NCP Network Control Protocol
PPP contains a series of NCPs to support different protocols of
the network layer.
NFS Network File System
NSDU Network Service Data Unit
NVT Network Virtual Terminal
O
OSI Open Systems Interconnection
OSPF Open Shortest Path First
P
PAP Password Authentication Protocol
PPP contains protocols to authenticate subscribers, e.g. PAP,
CHAP or MSCHAP. These are optional.
PDA Personal digital assistant
PDU protocol data unit
PMTU Path MTU Discovery process (RFC 1981)
POP Post Office Protocol
PPP Point to Point Protocol
The Point-to-Point Protocol (PPP) is standardized in the RFC
1661, July 1994.
PPPoE PPP over Ethernet, RFC2516, February 1999
proxy server the device which will answer a request instead of the real server

TG70115EN02GLA2
2010 Nokia Siemens Networks
87
The Transport Layer & Appendix

(e.g. a DNS proxy server, HTTP proxy server or a proxy ARP)


R
RADIUS Remote Authentication Dial In User Service
RC4 RC4 is a symmetric encryption algorithm where the key is
generated by a random number generator. RC4 uses a secret
key, which is known only to the sender and destination. RC4
uses a variable key length of up to 2048 bits. Each character is
individually encrypted. RC4 is considered very secure, although it
is quite straightforward.
The algorithm was developed by Ron Rivest is a stream cipher,
thus suitable for encrypting continual data streams; it is far
quicker than RSA.
RF Radio frequency
RFC Requests for Comments
RIP Routing Information Protocol
RLOGIN Remote Login
RPC Remote Procedure Call
RSVP Resource reSerVation Protocol
RTP Real Time Transport Protocol
S
SAP Service Access Point
SBC Session Border Controller
SCCP Signaling Connection Control Part
SCTP Stream Control Transmission Protocol, RFC 4960
SDU Service Data Unit
server A server is an application that offers a service to users.
Site-local address A special IPv6 address.
Addresses of this kind cannot be routed into the Internet. They
are the equivalent of IPv4 Private Addresses.
SMTP Simple Mail Transfer Protocol
SNAP Sub Network Access Protocol
SNMP Simple Network Management Protocol
SOHO Small Office / Home Office
SPF Shortest Path First
SS7 Signaling System #7

TG70115EN02GLA2
88 2010 Nokia Siemens Networks
The Transport Layer & Appendix

SSID Service Set Identifier


SSL Secured Sockets Layer
STA Spanning Tree Algorithm
STP Signaling Transfer Points
store-and-forward With the switching method, the LAN switch copies the entire
frame into its onboard buffers and computes the cyclic
redundancy check (CRC).
switch A device with more than two ports of bridging became known as
a switching hub or shorter as a switch.
T
TCP Transmission Control Protocol
TCAP Transaction Capabilities Application Part
TFTP Trivial File Transfer Protocol
TKIP Temporal Key Integrity Protocol
TLD Top Level Domain
TLS Transport Layer Security
TTL Time To Life Field; a Field in the IP Header
TU ports TCP/UDP (Transmission Control Protocol/User Datagram
Protocol) ports
U
UDP User Datagram Protocol
unicast address is an identifier assigned to a single interface. Packets sent to that
address will only be delivered to that interface.
URL Uniform Resource Locator
V
VLAN Virtual Local Area Network, Refers to the IEEE 802.1q
VLSM Variable Length Subnetting Mask
VPN Virtual Private Network
VoIP Voice over IP
VRRP Virtual Router Redundancy Protocol
W
WAN Wide Area Network
WEP Wired Equivalent Privacy
Wi-Fi Wireless Fidelity

TG70115EN02GLA2
2010 Nokia Siemens Networks
89
The Transport Layer & Appendix

WiMAX Worldwide Interoperability for Microwave Access.


Refers to the IEEE 802.16
WLAN Wireless Local Area Network, Refers to the IEEE 802.11
WPA Wi-Fi Protected Access
WWW World Wide Web

TG70115EN02GLA2
90 2010 Nokia Siemens Networks

Das könnte Ihnen auch gefallen