Unit 1 Intro To TCPIP

IP - The Internet Protocol
1
Orientation
IP (Internet Protocol) is a Network Layer Protocol.
IPs Version 4 (IPv4). It is specified in RFC 891.

Internet Group Management Protocol (IGMP)
Internet Control Message Protocol (ICMP)
Please refer this link for more detailed explanation of header formats:
http://www.quepublishing.com/articles/article.aspx?p=29578&seqNum=4
2
Internet Protocol
IP as a Routed Protocol
IP is a connectionless,
unreliable, best-effort
delivery protocol.
IP accepts whatever data
is passed down to it from
the upper layers and
forwards the data in the
form of IP Packets.
All the nodes are
identified using an IP
address.
Packets are delivered
from the source to the
destination using IP
address
Internet Protocol
Packet Propagation
IP: The waist of the
hourglass
IP is the waist of the
hourglass of the Applications
Internet protocol
HTTP FTP SMTP
architecture
TCP UDP
Multiple higher-layer
IP
protocols
Multiple lower-layer
Data link layer
protocols protocols
Physical layer
Only one protocol at the protocols
network layer.
5
Application protocol
IP is the highest layer protocol which
is implemented at both routers and
hosts
6
IP Service
Delivery service of IP is minimal
IP provide provides an unreliable connectionless best effort

service (also called: datagram service).
Unreliable: IP does not make an attempt to recover lost
packets
Connectionless: Each packet (datagram) is handled
independently. IP is not aware that packets between hosts
may be sent in a logical sequence
Best effort: IP does not make guarantees on the service (no
throughput guarantee, no delay guarantee,)
Consequences:
Higher layer protocols have to deal with losses or with duplicate
packets
Packets may be delivered out-of-sequence
9
IP Service
IP supports the following services:
one-to-one (unicast)
one-to-all (broadcast)
one-to-several (multicast)
unicast
broadcast multicast
IP multicast also supports a many-to-many service.

IP multicast requires support of other protocols (IGMP, multicast routing)
10
DATAGRAM
A packet in the IP layer is called a datagram,
a variable-length packet
Consisting of two parts: header and data.
The header is 20 to 60 bytes in length and
contains information essential to routing and
delivery.
11
IP datagram
12
IP Datagram Format
bit # 0 7 8 15 16 23 24 31
header
version DS ECN total length (in bytes)
length
D M
Identification 0 Fragment offset
F F
time-to-live (TTL) protocol header checksum
source IP address
destination IP address
options (0 to 40 bytes)
payload
4 bytes
20 bytes Header Size < 24 x 4 bytes = 60 bytes

20 bytes Total Length < 216 bytes = 65536 bytes
13
IP Datagram Format
Question: In which order are the bytes of
an IP datagram transmitted?
Answer:
Transmission is row by row
For each row:
1. First transmit bits 0-7
2. Then transmit bits 8-15
This is called network byte order or big
endian byte ordering.
Note: Many computers (incl. Intel processors) store 32-bit words in
little endian format. Others (incl. Motorola processors) use big endian.
14
Big endian vs. small endian
Conventions to store a multibyte work
Example: a 4 byte Long Integer Byte3 Byte2 Byte1 Byte0
Big Endian
Little Endian Stores the high-order byte at
Stores the low-order byte at the lowest address, and the
the lowest address and the low-order byte at the highest
highest order byte in the address.
highest address. Base Address+0 Byte3
Base Address+0 Byte0 Base Address+1 Byte2
Base Address+3 Byte3
Motorola processors use big endian.
Intel processors use this order
15
Fields of the IP Header
Version (4 bits): current version is 4, next version
will be 6.
-This field specifies the version of IP used for
transferring data. The size of the Version field is 4
bits. Both the sender and the receiver must use
the same version of IP to ensure proper
interpretation of the fields in the datagram.
Header length (4 bits): length of IP header, in
multiples of 4 bytes.
-You must multiply the value in this field by
four to get the length of the IP header. For
example, if the value in this field is 3, the length
of the header is 3*4, which is 12 bytes.
TOTAL LENGTH: Total Length field specifies the
total length of the datagram. The size of the field
is 16 bits. The Total Length
16 field can be calculated
DS/ECN field (1 byte)
This field was previously called as Type-of-
Service (TOS) field. The role of this field
has been re-defined, but is backwards
compatible to TOS interpretation
Differentiated Service (DS) (6 bits):
Used to specify service level (currently
not supported in the Internet)
Explicit Congestion Notification (ECN) (2
bits):
New feedback mechanism used by TCP
Identification (16 bits): Unique
identification of a datagram from a host.
Incremented whenever a datagram is
transmitted
Flags (3 bits):
First bit always set to 0
DF bit (Do not fragment)
MF bit (More fragments)
Will be explained later Fragmentation
18
Time To Live (TTL) (1 byte):
Specifies longest paths before datagram is
dropped
Role of TTL field: Ensure that packet is
eventually dropped when a routing loop occurs
Used as follows:
Sender sets the value (e.g., 64)
Each router decrements the value by 1
When the value reaches 0, the datagram is
dropped
19
Protocol (1 byte):
Specifies the higher-layer protocol.
Used for demultiplexing to higher layers.
20
Value Protocol
(Decim
al)
1 Internet Control Message Protocol (ICMP)

2 Internet Group Management Protocol (IGMP)
3 Gateway-to-Gateway Protocol (GGP)
4 Internet Protocol (IP)
6 Transmission Control Protocol (TCP)
8 Exterior Gateway Protocol (EGP)
9 Interior Gateway Protocol (IGP)
17 User Datagram Protocol (UDP)
41 Internet Protocol Version 6 (IPv6)
86 Dissimilar Gateway Protocol (DGP)
88 Interior Gateway Routing Protocol (IGRP)
89 Open Shortest Path First (OSPF)
Header checksum (2 bytes): A simple 16-bit long checksum
which is computed from the header of the datagram.
The Header Checksum field contains the checksum, which is used
by the destination to check for the integrity of the transmitted
data by applying an algorithm on the IP header.
The size of this field is 16 bits. The Header Checksum value is
calculated by the sender and is sent along with the IP header.
The sender uses a specific algorithm for arriving at the
checksum value. When the datagram reaches the
destination, the checksum is calculated by the destination
by using the same algorithm.
If the value that is calculated is not equal to the specified Header
Checksum value in the header of the datagram, the packet is
discarded.
The Header Checksum value is calculated only with the
header values and not by using the data. Every intermediate
device that receives the data must calculate the Header Checksum
value before forwarding it.
The Header Checksum value is not calculated based on the data
because
Reduce the efficiency of the network because the datagrams will be held by
the intermediate device for a long time.
Requires more time
Options:
Security restrictions
Record Route: each router that processes the packet adds its IP
address to the header.
Timestamp: each router that processes the packet adds its IP
address and time to the header.
(loose) Source Routing: specifies a list of routers that must be
traversed.
(strict) Source Routing: specifies a list of the only routers that
can be traversed.
Padding: Padding bytes are added to ensure

that header ends on a 4-byte boundary
23
Maximum Transmission Unit
Maximum size of IP datagram is 65535, but the data link layer
protocol generally imposes a limit that is much smaller.
Example:
Ethernet frames have a maximum payload of 1500 bytes
IP datagrams encapsulated in Ethernet frame cannot be
longer than 1500 bytes
The limit on the maximum IP datagram size, imposed by the data

link protocol is called maximum transmission unit (MTU)
MTUs for various data link protocols:

Ethernet: 1500 FDDI: 4352
802.3: 1492 ATM AAL5: 9180
802.5: 4464 PPP: negotiated
24
MTU
The amount of data that can be
transmitted in a single frame is
calledMaximum Transfer Unit(MTU)
and varies with the network
technology that is used.
MTU size is measured in bytes.
For example, the MTU for Ethernet is
1,500 bytes, whereas it is 4,352 bytes
for FDDI.
IP Fragmentation
What if the size of an IP datagram exceeds the MTU?
IP datagram is fragmented into smaller units.
What if the route contains networks with different MTUs?
Ethernet
FDDI
Ring
Host A Router Host B
MTUs: FDDI: 4352 Ethernet: 1500
Fragmentation:
IP router splits the datagram into several datagram
Fragments are reassembled at receiver
26
IP Fragmentation
If a datagram can be accommodated in a
frame, data transmission becomes very
simple
However, if the size of the datagram is more
than the value that can be accommodated
in the frame, the datagram must be divided
into logical groups called fragments.
If a datagram cannot be accommodated in a
single frame, it is divided or fragmented and sent
in multiple frames. The process of dividing a
datagram into multiple groups called
fragments is called fragmentation.
Where is Fragmentation
done?
Fragmentation can be done at the sender or
at intermediate routers
The same datagram can be fragmented
several times.
Reassembly of original datagram is only
done at destination hosts !!
IP datagram H Fragment 2 H2 Fragment 1 H1
Router
28
Whats involved in
Fragmentation?
The following fields in the IP header are involved:
Identification When a datagram is fragmented, the identification is the same in

all fragments
Flags
DF bit is set: Datagram cannot be fragmented and must be
discarded if MTU is too small
MF bit set: This datagram is part of a fragment and an
additional fragment follows this one.
The last bit in this field is used to indicate whether there are any fragments following
the current one. If the value of this field is set to 0, it indicates that the current
fragment is the last fragment in the datagram. 29
Whats involved in
Fragmentation?
The following fields in the IP header are involved:
Fragment offset Offset of the payload of the current

fragment in the original datagram
The Fragmentation Offset field is used to indicate the relative position of a

fragment with respect to the other fragments of a datagram. The position of the
datagram is not represented in terms of the exact position. It contains the number of
octets that the fragment contains. The Fragmentation Offset is numbered starting
from zero.
Total length Total length of the current fragment 30

Example of Fragmentation
A datagram with size 2400 bytes must be fragmented
according to an MTU limit of 1000 bytes
31
Determining the length of
fragments
To determine the size of the fragments we recall that,
since there are only 13 bits available for the fragment
offset, the offset is given as a multiple of eight bytes.
As a result, the first and second fragment have a size
of 996 bytes (and not 1000 bytes).
This number is chosen since 976 is the largest
number smaller than 100020= 980 that is divisible
by eight.
The payload for the first and second fragments is 976
bytes long, with bytes 0 through 975 of the original
IP payload in the first fragment, and bytes 976
through 1951 in the second fragment.
The payload of the third fragment has the remaining
428 (448-20) bytes, from byte 1952 through 2379.
With these considerations, we can determine the
values of the fragment offset, which are 0, 976 / 8 =
122, and 1952 / 8 = 244, 32 respectively, for the first,
Why the fragment offset should be in
integral of 8 bytes?
-Maximum IP packet size, in bytes, fits in
16 bits (so it's 2^16), and the maximum
fragment offset is 13 bits (so it's 2^13,
so it's 2^16/2^13, which is 2^(16-13), or
2^3, or 8.
The More Fragments field is set to 1 for
all fragments but the last, to let the
recipient know when it has received all
the fragments.
ARP and RARP
TCP/IP Protocol Suite 34

Position of ARP and RARP in TCP/IP protocol suite

ARP
ARP associates an IP address with its physical address. On a typical
physical network, such as a LAN, each device on a link is identified by a
physical or station address that is usually imprinted on the NIC.
The topics discussed in this section include:

Packet Format
Encapsulation
Operation
Proxy ARP

ARP operation

ARP packet

The fields are as follows:
o Hardware type. This is a 16-bit field defining the
type of the network on which ARP is running.
Each LAN has been assigned an integer based on its
type. For example, Ethernet is given type 1. ARP
can be used on any physical network.
o Protocol type. This is a 16-bit field defining the
protocol. For example, the value of this field for the
IPv4 protocol is 0800H, ARP can be used with any
higher-level protocol.
o Hardware length. This is an 8-bit field defining the
length of the physical address in bytes. For
example, for Ethernet the value is 6.
o Protocol length. This is an 8-bit field defining the
length of the logical address in bytes. For
example, for the IPv4 protocol the value is 4.
o Operation. This is a 16-bit field defining the type of
packet. Two packet types are defined: ARP request
o Sender hardware address. This is a variable-
length field defining the physical address of
the sender. For example, for Ethernet this field
is 6 bytes long.
o Sender protocol address. This is a variable-
length field defining the logical (for example,
IP) address of the sender. For the IP protocol,
this field is 4 bytes long.
o Target hardware address. This is a variable-
length field defining the physical address of
the target. For example, for Ethernet this field is
6 bytes long. For an ARP request message, this
field is alI Os because the sender does not know
the physical address of the target.
o Target protocol address. This is a variable-
length field defining the logical (for example,
IP) address of the target. For the IPv4 protocol,
Encapsulation of ARP packet

Four cases using ARP

Note:
An ARP request is broadcast;

an ARP reply is unicast.

Example
A host with IP address 130.23.43.20 and

physical address B2:34:55: 10:22: 10 has
a packet to send to another host with IP
address 130.23.43.25 and physical
address A4:6E:F4:59:83:AB (which is
unknown to the first host). The two hosts
are on the same Ethernet network. Show
the ARP request and reply packets
encapsulated in Ethernet frames.
Example 1

Proxy ARP
A technique called proxy ARP is used to create a
subnetting effect.
A proxy ARP is an ARP that acts on behalf of a set
of hosts.
Whenever a router running a proxy ARP receives
an ARP request looking for the IP address of one of
these hosts, the router sends an ARP reply
announcing its own hardware (physical)
address.
After the router receives the actual IP packet, it
sends the packet to the appropriate host or router.
Proxy ARP

RARP
RARP finds the logical address for a machine that only knows its physical
address.

Packet Format
Encapsulation
RARP Server
Alternative Solutions to RARP

Note:
The RARP request packets are broadcast;

the RARP reply packets are unicast.

RARP operation

RARP packet

Encapsulation of RARP packet

ICMP
Internet Control
Message Protocol
WhyICMP
What it Does
I
C
M
P
ICMPEncapsulation
ICMP
TYPESOFMESSAGES
MESSAGEFORMAT
ERRORREPORTINGMSG
QUERYMSG
ICMPPACKAGE
ICMP
TYPESOFMESSAGES
ICMP MESSAGE TYPES
The error-reporting messages
report problems that a router or a host (destination)
may encounter when it processes an IP packet.
The query messages,
which occur in pairs, help a host or a network
manager get specific information from a router or
another host.
For example,
1) Nodes can discover their neighbours.
2)Hosts can discover and learn about routers on
their network, and
3) Routers can help a node redirect its messages.
Error-reporting message
Types
Category Type Message
Error 3 Destination
Reporting Unreachable
Messages
4 Source Quench
11 Time Exceed
12 Parameter Problem
5 Redirection
Query 8/0 Echo Req / Rep
Messages
13 / 14 Timestamp Req /
Rep
ICMP
MESSAGEFORMAT
ERRORREPORTINGMSG
QUERYMSG
GeneralformatofICMPmessages
ICMP
MESSAGEFORMAT
ERRORREPORTINGMSG
QUERYMSG
Error Reporting Messages
ICMP always reports error messages to the original
source
The following are important points about ICMP error messages:

No ICMP error message will be generated in response
to a datagram carrying an ICMP error message.
No ICMP error message will be generated for a
fragmented datagram that is not the first fragment.
datagram having a multicast address.
datagram having a special address such as 127.0.0.0
or 0.0.0.0.
Destination Unreachable
CODE 0 : Network Unreachable
CODE 1 : Host unreachable
CODE 2 : Protocol Unreachable
CODE 3 : Port Unreachable
CODE 4 : Fragmentation is required, but DF (do not Frag) is
enabled
CODE 5 : Source routing enabled, but couldnt accomplish
CODE 6 : Dest N/W is unknown
CODE 7 : Dest Host is unknown
CODE 8 : Source Host Isolated
CODE 9 : Dest N/W is administratively Prohibited
CODE 10 : Dest Host is administratively Prohibited
CODE 11 : Network Unreachable for a specified type of service
CODE 12 : Host Unreachable for a specified type of service
CODE 13 : Communication administratively prohibited
(administrative filtering prevents packet from being forwarded)
CODE 14 : Host precedence violation (permission denied for the
combination of host or network and port)
CODE 15 : Precedence cutoff in effect
(precedence of datagram is below the level set by the network
administrators)
CODE 11 : Network Unreachable for a specified type of service
CODE 12 : Host Unreachable for a specified type of service
CODE 13 : Communication administratively prohibited
(administrative filtering prevents packet from being forwarded)
CODE 14 : Host precedence violation (permission denied for the
combination of host or network and port)
CODE 15 : Precedence cutoff in effect
(precedence of datagram is below the level set by the network
administrators)
Types
Source Quench
Source Quench
A source-quench message informs the
source that a datagram has been
discarded due to congestion in a router or
the destination host.
The source must slow down the sending of
datagrams until the congestion is relieved.
One source-quench message is sent for

each datagram that is discarded due to
congestion.
Types
Time Exceeded
Time Exceeded Two cases
Whenever a router decrements a datagram
with a time-to-live value to zero, it discards
the datagram and sends a time-exceeded
message to the original source. (Code 0)
When the final destination does not receive all

of the fragments in a set time, it discards the
received fragments and sends a time-
exceeded message to the original source.
(code 1)
Types
Parameter-problem
message
Code 0 : Error on Header (Value of
pointer points to the byte with
problem)
Code 1 : Options missing
Code 0. There is an error or
ambiguity in one of the header fields. In
this case, the value in the pointer field
points to the byte with the problem.
- For example, if the value is zero, then
the first byte is not a valid field.
Code 1. The required part of an
option is missing. In this case, the
pointer is not used.
Types
Redirection Message
de 0. Redirection for a network-specific route.

de 1. Redirection for a host-specific route.
de 2. Redirection for a network-specific route based on a specified type
ce.
de 3. Redirection for a host-specific route based on a specified type of se
Redirection Concept
Redirection Message
When a router needs to send a packet
destined for another network, it must know
the IP address of the next appropriate router.
The same is true if the sender is a host. Both
routers and hosts, then, must have a routing
table to find the address of the router or the
next router.
Routers take part in the routing update
process, and are supposed to be updated
constantly. Routing is dynamic.
However, for efficiency, hosts do not take part in the
routing update process because there are many
more hosts in an internet than routerS.
Updating the routing tables of hosts dynamically
produces unacceptable traffic.
The hosts usually use static routing.
When a host comes up, its routing table has a limited
number of entries. It usually knows the IP address
of only one router, the default router.
For this reason, the host may send a datagram, which
is destined for another network, to the wrong router.
In this case, the router that receives the datagram
will forward the datagram to the correct router.
However, to update the routing table of the host, it
sends a redirection message to the host.
Query message Types
Echo Request Reply
Message
Echo Request Reply
An echo-request message can be sent by a host or
router. An echo-reply message is sent by the host
or router which receives an echo-request message.
Echo-request and echo-reply messages can be

used by network managers to check the
operation of the IP protocol.
Echo-request and echo-reply messages can test

the reachability of a host. This is usually done
by invoking the ping command.
Timestamp Request Reply
Message
Timestamp Request Reply
Message
Timestamp-request and timestamp-reply
messages can be used to calculate the
round-trip time between a source and a
destination machine even if their clocks are
not synchronized.
sending time = receive timestamp original
timestamp
receiving time = returned time transmit
timestamp
round-trip time = sending time + receiving time
Example
For eg, given the following information,
original timestamp: 46 receive timestamp:
59
transmit timestamp: 60 return time: 67
sending time= 59- 46= 13 milliseconds
receiving time= 67 60= 7 milliseconds
round-trip time= 13+ 7= 20 milliseconds
The timestamp-request and timestamp-
reply messages can be used to
synchronize two clocks in two
machines if the exact one-way time
duration is known, as per the formula
given below.
Time difference = receive timestamp
(original timestamp field + one-way
time duration)
Time difference= 59 (46+ 10)= 3
Checksum
In ICMP the checksum is calculated over the entire
message (header and data).
Lets have an example of checksum calculation for a
simple echo-request message. We randomly chose
the identifier to be 1 and the sequence number to be
9. The message is divided into 16-bit (2-byte) words.
The words are added together and the sum is
complemented. Now the sender can put this value in
Checksum Calculation
The sender follows these steps using ones complement arithmetic:
1. The checksum field is set to zero.
2. The sum of all the 16-bit words (header and data) is calculated.
3. The sum is complemented to get the checksum.
4. The checksum is stored in the checksum field.
Checksum Testing
The receiver follows these steps using ones complement
arithmetic:
1. The sum of all words (header and data) is calculated.
2. The sum is complemented.
3. If the result obtained in step 2 is 16 0s, the message is accepted;
otherwise, it is rejected.
DEBUGGING TOOLS
Ping
Traceroute
Ping Shows how long it takes for packets

to reach host
Traceroute Traces the route of packets to
destination host from our server
PING - Packet InterNet Groper
The ping program sets the identifier field in the echo-request and
echo-reply message and stans the sequence number from 0; this
number is incremented by 1 each time a new message is sent.
The ping program to test the server fhda.edu. The result is shown
below
$ ping fhda.edu
PING fhda.edu (153.18.8.1) 56 (84) bytes of data.
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=0 ttl=62 time=1.91 ms
PING

64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=10 ttl=62 time=1.98
ms
--- fhda.edu ping statistics ---

11 packets transmitted, 11 received, 0% packet loss, time 10103ms
rtt min/avg/max = 1.899/1.955/2.041 ms
Traceroute
We use the traceroute program to find the route from the

computer voyager.deanza.edu to the server fhda.edu :
Round-trip time (RTT), also called round-trip
delay, is the time required for a packet to
travel from a specific source to a specific
destination and back again.
$ traceroute fhda.edu
traceroute to fhda.edu (153.18.8.1), 30 hops max, 38 byte packets
1 Dcore.fhda.edu (153.18.31.254) 0.995 ms 0.899 ms 0.878 ms
2 Dbackup.fhda.edu (153.18.251.4) 1.039 ms 1.064 ms 1.083 ms
3 tiptoe.fhda.edu (153.18.8.1) 1.797 ms 1.642 ms 1.757 ms
Position of UDP in the TCP/IP protocol suite
USER DATAGRAM
UDP packets are called user datagrams and have a fixed-size header of 8
bytes.

User datagram format

Source port number. This is the port number used by the process running on the
source host. It is 16 bits long, which means that the port number can range from
0 to
65,535. If the source host is the client (a client sending a request), the port number, in
most cases, is an ephemeral port number requested by the process and chosen by the
UDP software running on the source host. If the source host is the server (a server
sending a response), the port number, in most cases, is a well-known port number.
Destination port number. This is the port number used by the process running
on
the destination host. It is also 16 bits long. If the destination host is the server (a
client sending a request), the port number, in most cases, is a well-known port
number. If the destination host is the client (a server sending a response), the port
number, in most cases, is an ephemeral port number. In this case, the server copies
the ephemeral port number it has received in the request packet.

Length. This is a 16-bit field that defines the total length of the user
datagram ,header plus data.
The 16 bits can define a total length of 0 to 65,535 bytes.
A user datagram is encapsulated in an IP datagram.
There is a field in the IP datagram that defines the total length.
There is another field in the IP datagram that defines the length of
the header.
So if we subtract the value of the second field from the first, we
can deduce the length of the UDP datagram that is encapsulated
in an IP datagram.
Checksum. This field is used to detect errors over the entire user
datagram UDP length =

IP length IP headers length
IP datagram
109
CHECKSUM
UDP checksum calculation is different from the one for IP and ICMP. Here
the checksum includes three sections: a pseudoheader, the UDP header,
and the data coming from the application layer.
Checksum Calculation at Sender

Checksum Calculation at Receiver
Optional Use of the Checksum

Pseudoheader for checksum calculation

Checksum calculation of a simple UDP user datagram

A 01000001 N 01001110
B 01000010 O 01001111
C 01000011 P 01010000
D 01000100 Q 01010001
E 01000101 R 01010010
F 01000110 S 01010011
G 01000111 T 01010100
H 01001000 U 01010101
I 01001001 V 01010110
J 01001010 W 01010111
K 01001011 X 01011000
L 01001100 Y 01011001
M 01001101 Z 01011010
Optional inclusion of
checksum
The sender of UDP packet can
choose not to calculate the
checksum
Field filled with 0s
Sender calculates checksum but

result is all 0s
Compliments the result ( all 1s)
Does not create confusion because
checksum value can never be all 1s.
UDP OPERATION
UDP uses concepts common to the transport layer. These concepts will be
discussed here briefly
1. Connectionless Service
2. Flow and Error Control
3. Encapsulation and Decapsulation
4. Queues in UDP

Connectionless Services
UDP provides a connectionless service.
This means that each user datagram sent by UDP is an
independent datagram.
There is no relationship between the different
user datagrams even if they are coming from
the same source process and going to the same
destination program.
The user datagrams are not numbered.
Also, there is no connection establishment and no
connection termination, as is the case for TCP.
This means that each user datagram can travel on a
different path.
One of the ramifications of being connectionless is
that the process that uses UDP cannot send a stream
of data to UDP and expect UDP to chop them into
different related user datagrams.
Instead each request must be small enough to fit into
Flow and Error Control
UDP is a very simple, unreliable transport protocol.

There is no flow control and hence no window
mechanism. The receiver may overflow with incoming
messages.
There is no error control mechanism in UDP except for
the checksum.
The sender does not know if a message has
been lost or duplicated.
When the receiver detects an error through the
checksum, the user datagram is silently
discarded.
The lack of flow control and error control means that the
process using UDP should provide these mechanisms.
Encapsulation and decapsulation

Queues in UDP

lANA Ranges
The lANA (Internet Assigned Number Authority) has divided
the port numbers into three ranges: well known, registered,
and dynamic (or private), as shown in Figure 23.4.
o Well-known ports. The ports ranging from 0 to 1023
are assigned and controlled by lANA. These are the well-
known ports.
o Registered ports. The ports ranging from 1024 to
49,151 are not assigned or controlled by lANA. They can
only be registered with lANA to prevent duplication.
o Dynamic ports. The ports ranging from 49,152 to
65,535 are neither controlled nor registered. They can be
used by any process. These are the ephemeral ports.
Use of UDP
The following lists some uses of the UDP protocol:
o UDP is suitable for a process that requires simple
request-response communication with little
concern for flow and error control. It is not usually
used for a process that needs to send bulk data
o UDP is suitable for a process with internal flow
and error control mechanisms. For example,
the Trivial File Transfer Protocol (TFTP) process
includes flow and error control. It can easily use
UDP.
o UDP is a suitable transport protocol for
multicasting. Multicasting capability is
embedded in the UDP software but not in the TCP
software.
o UDP is used for management processes such
TCP/IP protocol suite
TCP
TCP is one of the main protocols in TCP/IP
networks.
Whereas the IP protocol deals only with
packets, TCP enables two hosts to
establish a connection and exchange
streams of data.
TCP guarantees
Delivery of Packets
Packets will be delivered in the same order in
which they were sent.
SEGMENT
A packet in TCP is called a segment
Format
Encapsulation

TCP segment format

Source port address. This is a 16-bit field that defines the
port number of the application program in the host that
is sending the segment.
Destination port address. This is a 16-bit field that defines
the port number of the application program in the host
that is receiving the segment.
Sequence number. This 32-bit field defines the number
assigned to the first byte of data contained in this segment.
TCP is a stream transport protocol. To ensure connectivity, each
byte to be transmitted is numbered. The sequence number
tells the destination which byte in this sequence is the
first byte in the segment.
Acknowledgment number. This 32-bit field defines the byte
number that the receiver of the segment is expecting to
receive from the other party. If the receiver of the segment
has successfully received byte number x from the other party,
it returns x + 1 as the acknowledgment number.
Acknowledgment and data can be piggybacked together.
Header length. This 4-bit field indicates the number of
4-byte words in the TCP header. The length of the header
can be between 20 and 60 bytes. Therefore, the value of
this field is always between 5 (5 4 = 20) and 15 (15 4
= 60).
Reserved. This is a 6-bit field reserved for future use.
Control. This field defines 6 different control bits or flags
One or more of these bits can be set at a time.
These bits enable flow control, connection establishment
and termination, connection abortion, and the mode of
data transfer in TCP. A brief description of each bit.
Control field

Description of flags in the control field

Window size. This field defines the window size
of the sending TCP in bytes. the maximum size
of the window is 65,535 bytes.
Checksum. This 16-bit field contains the

checksum.
However, the use of the checksum in the UDP

datagram is optional, whereas the use of the
checksum for TCP is mandatory. The same
pseudoheader, serving the same purpose, is
Pseudoheader added to the TCP datagram

Urgent pointer. This 16-bit field, which is valid
only if the urgent flag is set, is used when the
segment contains urgent data.
- It defines a value that must be added to the

sequence number to obtain the number of the last
urgent byte in the data section of the segment.
Options. There can be up to 40 bytes of optional

information in the TCP header.
Note:
The inclusion of the checksum in TCP is

mandatory.

Encapsulation and decapsulation
A TCP segment encapsulates the

data received from the application
layer. The TCP segment is
encapsulated in an IP datagram,
which in turn is encapsulated in a
frame at the data-link layer

TCP features
Numbering system
Byte number
Numbering is independent in both direction
When TCP receives data from a process it stores
in buffer and numbers them
Does not necessarily starts from 0
Chooses any number from 0 to 232-1
For example, if the number happens to be 1,057
and the total data to be sent is 6,000 bytes, the
bytes are numbered from 1,057 to 7,056
139
Sequence number
The sequence number for each segment is the number of
the first byte of data carried in that segment.
When a segment carries a combination of data and
control information (piggybacking), it uses a sequence
number.
If a segment does not carry user data, it does not logically
define a sequence number.
However, some segments, when carrying only control
information, need a sequence number to allow an
acknowledgment from the receiver.
These segments are used for connection establishment,
termination, or abortion.

Acknowledgment Number
The sequence number in each direction shows the
number of the first byte carried by the segment.
Each party also uses an acknowledgment number to
confirm the bytes it has received.
However, the acknowledgment number defines the
number of the next byte that the party expects to
receive.
In addition, the acknowledgment number is cumulative,
The term cumulative here means that if a party uses
5,643 as an acknowledgment number, it has received all
bytes from the beginning up to 5,642.
Note that this does not mean that the party has received
5,642 bytes because the first byte number does not have
to start from 0.
Flow Control
TCP, unlike UDP, provides flow control.
The sending TCP controls how much data can
be accepted from the sending process;
The receiving TCP controls how much data to
be sent by the sending TCP
This is done to prevent the receiver from being
overwhelmed with data.
The numbering system allows TCP to use a byte
oriented flow control.

Error Control
To provide reliable service, TCP implements
an error control mechanism.
Although error control considers a segment
as the unit of data for error detection (loss or
corrupted segments).
Error control is byte-oriented
The value in the sequence number field of a
segment defines the number assigned to the
first data byte contained in that segment.
The value of the acknowledgment field in a
segment defines the number of the next
byte

Congestion Control
TCP, unlike UDP, takes into account congestion
in the network.
The amount of data sent by a sender is not only
controlled by the receiver (flow control), but is
also determined by the level of congestion, if
any, in the network.

FLOW CONTROL
Flow control regulates the amount of data a source can send before
receiving an acknowledgment from the destination. TCP defines a window
that is imposed on the buffer of data delivered from the application
program.
Sliding Window Protocol

Silly Window Syndrome

Sliding window

The window is opened, closed, or shrunk.
These three activities are in the control of the
receiver (and depend on congestion in the
network), not the sender.
The sender must obey the commands of the
receiver in this matter.
Shrinking Strictly not recommended
Bz its revoking the eligibility of some bytes for
sending.
This is a problem if the sender has already sent
these bytes.
The size of the window at one end is
determined by the lesser of two values:
receiver window (rwnd) or congestion
window (cwnd).
The receiver window is the value advertised
by the opposite end in a segment containing
acknowledgment.
It is the number of bytes the other end can accept
before its buffer overflows and data are discarded.
congestion window is a value determined by
the network to avoid congestion.
SLIDING WINDOWS IN TCP
TCP uses two windows (send window and

receive window) for each direction of data
transfer, which means four windows for a
bidirectional communication.
Unrealistic assumption that communication is

only unidirectional (say from client to server);
the bidirectional communication can be
inferred using two unidirectional
communications with piggybacking
Send Window

The send window in TCP is similar to one used with the
Selective Repeat protocol but with some differences:
The window in SR numbers pockets, but the window in

the TCP numbers bytes. Although actual transmission in
TCP occurs segment by segment, the variables that
control the window are expressed in bytes.
The second difference is that, in some implementations,

TCP can store data received from the process and send
them later, but we assume that the sending TCP is
capable of sending segments of data as soon as it
receives them from its process.

The theoretical Selective Repeat protocol may use several
timers for each packet sent, but the TCP protocol uses
only one timer.

Receive Window

There are two differences between the receive window in
TCP and the one we used for SR
rwnd = buffer size number of waiting bytes to be
pulled
The second difference is the way acknowledgments are

used in the TCP protocol
acknowledgement in SR is selective, defining the
uncorrupted packets that have been received
TCP is a cumulative acknowledgment announcing
the next expected byte to receive

Note:
A sliding window is used to make

transmission more efficient as well as to
control the flow of data so that the
destination does not become
overwhelmed with data.
TCPs sliding windows are byte
oriented.

Note:
To avoid shrinking the sender window,

the receiver must wait until more space
is available in its buffer.

Note:
FLOW CONTROL

Opening and Closing Windows
To achieve flow control, TCP forces the sender and the
receiver to adjust their window sizes
Size of the buffer for both parties is fixed when the

connection is established.
The receive window closes (moves its left wall to the right) when
more bytes arrive from the sender.
It opens (moves its right wall to the right) when more bytes are
pulled by the process.
We assume that it does not shrink (the right wall does not
move to the left).
160
The opening, closing, and shrinking of the send window is
controlled by the receiver.
The send window closes (moves its left wall to the right) when a
new acknowledgement allows it to do so.
The send window opens (its right wall moves to the right) when
the receive window size (rwnd) advertised by the receiver allows
it to do so.
The send window shrinks on occasion. We assume that this

situation does not occur.

Example of a Sliding Window Protocol (W =
7)
Shrinking of Windows
The receive window cannot shrink.
But the send window can shrink if the receiver defines a

value for rwnd that results in shrinking the window.
Some implementations do not allow the shrinking of the

send window.
The limitation does not allow the right wall of the send
window to move to the left.

Scenario

Example
What is the value of the receiver window (rwnd) for host A if the
receiver, host B, has a buffer size of 5,000 bytes and 1,000 bytes
of received and unprocessed data?
Solution
The value of rwnd = 5,000 1,000 = 4,000. Host B can receive
only 4,000 bytes of data before overflowing its buffer. Host B
advertises this value in its next segment to A.

Example
What is the size of the window for host A if the value of rwnd is
3,000 bytes and the value of cwnd is 3,500 bytes?
Solution
The size of the window is the smaller of rwnd and cwnd, which is
3,000 bytes.

Window Shutdown
We said that shrinking the send window by moving its right

wall to the left is strongly discouraged.
However, there is one exception:

The receiver can temporarily shut down the window by sending a
rwnd of 0.
In this case, the sender does not actually shrink the size of the
window, but stops sending data until a new advertisement has
arrived.
the sender can always send a segment with 1 byte of data. This is
called probing and is used to prevent a deadlock.

Sliding Window Enhancements in
Implementation
Receiver can acknowledge frames without
permitting further transmission (Receive
Not Ready)
Must send a normal acknowledgement to
resume
If the link is duplex, use piggybacking
Send data and ack together in one frame
frame has both data and ack fields
If no data to send, use acknowledgement frame
If data but no acknowledgement to send, send
last acknowledgement number again
Silly Window Syndrome
A serious problem can arise in the sliding window operation when
either the sending application program creates data slowly or the
receiving application program consumes data slowly, or both.
Example:
If TCP sends segments containing only 1 byte of data, it means that
a 41-byte datagram (20 bytes of TCP header and 20 bytes of IP
header) transfers only 1 byte of user data.
Here the overhead is 41/1, which indicates that we are using the
capacity of the network very inefficiently.
The inefficiency is even worse after accounting for the data link
layer and physical layer overhead.
This problem is called the silly

170window syndrome.
Syndrome Created by the Sender
The sending TCP may create a silly window syndrome if it
is serving an application program that creates data slowly,
for example, 1 byte at a time.
The application program writes 1 byte at a time into the

buffer of the sending TCP.
If the sending TCP does not have any specific instructions,

it may create segments containing 1 byte of data.
The result is a lot of 41-byte segments that are traveling

through an internet.
171
The solution is to prevent the sending TCP from sending the
data byte by byte.
The sending TCP must be forced to wait and collect data to

send in a larger block.
How long should the sending TCP wait? If it waits too long,
it may delay the process.
If it does not wait long enough, it may end up sending small

segments.

Nagles Algorithm
1. The sending TCP sends the first piece of data it receives
from the sending application program even if it is only 1
byte.
2. After sending the first segment, the sending TCP

accumulates data in the output buffer and waits until either
the receiving TCP sends an acknowledgment or until
enough data has accumulated to fill a maximum-size
segment. At this time, the sending TCP can send the
segment.
3. Step 2 is repeated for the rest of the transmission.

Segment 3 is sent immediately if an acknowledgment is
received for segment 2, or if enough data have accumulated
to fill a maximum-size segment.
173
The elegance of Nagles algorithm
simple
It takes into account the speed of the application

program that creates the data and the speed of the
network that transports the data.
If the application program is faster than the network, the

segments are larger (maximum-size segments).
If the application program is slower than the network,

the segments are smaller (less than the maximum
segment size).
Syndrome Created by the
Receiver
The receiving TCP may create a silly window syndrome if
it is serving an application program that consumes data
slowly, for example, 1 byte at a time.
Suppose that the sending application program creates data
in blocks of 1 kilobyte,
The receiving application program consumes data 1 byte at
a time.
Also suppose that the input buffer of the receiving TCP is 4
kilobytes.
The sender sends the first 4 kilobytes of data.
The receiver stores it in its buffer.
Now its buffer is full

It advertises a window size of zero, which means the sender
should stop sending data.
The receiving application reads the first byte of data from

the input buffer of the receiving TCP.
Now there is 1 byte of space in the incoming buffer.
The receiving TCP announces a window size of 1 byte,
The sending TCP, which is eagerly waiting to send data,

sends a segment carrying only 1 byte of data

The procedure will continue.
One byte of data is consumed and a segment carrying 1 byte

of data is sent.
Again we have an efficiency problem and the silly window

syndrome.
Two solutions have been proposed to prevent the silly

window syndrome created by an application program that
consumes data slower than they arrive.

Clarks Solution
1. Clarks solution
send an acknowledgment as soon as the data arrive.
But to announce a window size of zero until either there

is enough space to accommodate a segment of maximum
size or until at least half of the receive buffer is empty.

2. Delayed Acknowledgment
The second solution is to delay sending the acknowledgment.
This means that when a segment arrives, it is not

acknowledged immediately.
The receiver waits until there is a decent amount of space in

its incoming buffer before acknowledging the arrived
segments.
The delayed acknowledgment prevents the sending TCP from

sliding its window.
After the sending TCP has sent the data in the window, it
stops.
This kills the syndrome. 179
Delayed acknowledgment also has another advantage:
it reduces traffic. The receiver does not have to

acknowledge each segment.
However, there also is a disadvantage in that the

delayed acknowledgment may result in the sender
unnecessarily retransmitting the unacknowledged
segments.
TCP balances the advantages and disadvantages. It now

defines that the acknowledgment should not be delayed
by more than 500 ms.

ERROR CONTROL
TCP provides reliability using error control, which detects corrupted, lost,
out-of-order, and duplicated segments. Error control in TCP is achieved
through the use of the checksum, acknowledgment, and time-out.

Note:
ACK segments do not consume

sequence numbers and are not
acknowledged.

Note:
In modern implementations, a
retransmission occurs if the
retransmission timer expires or three
duplicate ACK segments have arrived.

Note:
No retransmission timer is set for an

ACK segment.

Note:
Data may arrive out of order and be

temporarily stored by the receiving TCP, but
TCP guarantees that no out-of-order
segment is delivered to the process.

Normal operation

Lost segment

Note:
The receiver TCP delivers only ordered

data to the process.

Fast retransmission

Lost acknowledgment

Lost acknowledgment corrected by resending a segment

Note:
Lost acknowledgments may create

deadlock if they are not properly
handled.

Silly Window
Syndrome (1)
Sending data in very small
segments
1.Syndrome created by the Sender
Sending application program creates data
slowly (e.g. 1 byte at a time)
Wait and collect data to send in a larger
block
How long should the sending TCP wait?
Solution: Nagles algorithm
Nagles algorithm takes into account (1)
the speed of the application program that
creates the data, and (2) the speed of the
network that transports the data
Silly Window
Syndrome (2)
2.Syndrome created by the Receiver
Receiving application program consumes
data slowly (e.g. 1 byte at a time)
The receiving TCP announces a window
size of 1 byte. The sending TCP sends only
1 byte
Solution 1: Clarks solution
Sending an ACK but announcing a window
size of zero until there is enough space to
accommodate a segment of max. size or
until half of the buffer is empty

Silly Window
Syndrome (3)
Solution 2: Delayed Acknowledgement
The receiver waits until there is decent
amount of space in its incoming buffer
before acknowledging the arrived
segments
The delayed acknowledgement prevents
the sending TCP from sliding its window. It
also reduces traffic.
Disadvantage: it may force the sender to
retransmit the unacknowledged segments
To balance: should not be delayed by more
than 500ms

CONGESTION CONTROL
Congestion control refers to the mechanisms and techniques to keep the load
below the capacity.
TCP uses congestion window and congestion policy that avoid congestion
and detect and alleviate congestion.
Congestion window:
In flow control the sender window size depends on the size of receiver
buffer(rwnd).
Congestion also depends on the network ,if network is slow compared to
the packets created by the sender,it must tell the sender to slow down or else
it will not be delivered.(cwnd)
Actual window size=min(rwnd,cwnd)

Congestion Control
TCP Congestion policy
Has 3 phases
slow start, congestion avoidance and
congestion detection.
Slow Start:Exponential Algorithm

Based on the idea that the size of cwnd starts
with 1 MSS.
MSS determined during the connection
establishment.
Algorithm starts slowly ,but grows exponentially.
Slow start, exponential increase

Note:
In the slow start algorithm, the size of

the congestion window increases
exponentially until it reaches a
threshold.(SSTHRESH).
When the threshold is reached it moves

to the next phase
To avoid congestion before it
happens ,we should slow down the
exponential growth,
So we go for congestion avoidance
algorithm
Congestion avoidance, additive increase

Note:
In the congestion avoidance algorithm

the size of the congestion window
increases additively until
congestion is detected.

Congestion detection:Multiplicative Decrease
If congestion detected, congestion window size should be
decreased.Sender can find congestion ,in case of re-transmission.
Retransmission can happen only in 2 cases if RTO timer times
out,or when 3 duplicate ACK has been received.
in both cases the size of threshold should be dropped to
half(multiplicative decrease)
Most implementations react differently to congestion detection:
If detection is by time-out, a new slow start phase
starts.
If detection is by three duplicate ACKs, a new congestion
avoidance phase starts.

Traffic Shaping
It is about regulating average rate of data flow.
It is a method of congestion control by providing shape to data flow before entering the packet into
the network.
At connection set-up time, the sender and carrier negotiate a traffic pattern (shape)
There are two types of Traffic shaping algorithm :-
1. Leaky Bucket Algorithm.
2. Token Bucket Algorithm
210
Leaky Bucket Algorithm
The Leaky Bucket Algorithm used to control rate in a
network.
It is implemented as a single-server queue with constant

service time.
If the bucket (buffer) overflows then packets are

discarded.
In this algorithm the input rate can vary but the output
rate remains constant.
This algorithm saves busty traffic into fixed rate traffic

by averaging the data rate.
211
The Leaky Bucket Algorithm
(a) A leaky bucket with water. (b) a leaky bucket with packets.
212
Leaky Bucket Algorithm
Algorithm
Step - 1 : Initialize the counter to n at every tick of clock.
Step - 2 : If n is greater than the size of packet in the front of

queue send the packet into the network and decrement the
counter by size of packet. Repeat the step until n is less than the
size of packet.
Step - 3 : Reset the counter and go to Step - 1.
213
Example
Let n = 1000
Packet =. 200 700 500 450 400 200
Since n > front of Queue i.e. n>200

Therefore, n= 1000-200 = 800
Packet size of 200 is sent to the network
200 700 500 450 400
Now Again n > front of queue i.e. n > 400

Therefore, n= 800-400 = 400
Packet size of 400 is sent to the network
200 700 500 450

Since n < front of queue .
There fore, the procedure is stop.
And we initialize n = 1000 on another tick of clock.
This procedure is repeated until all the packets is sent to the network.
214
Token Bucket Algorithm
The Token Bucket Algorithm compare to Leaky

Bucket Algorithm allow the output rate vary depending
on the size of burst.
In this algorithm the buckets holds token to transmit a

packet, the host must capture and destroy one token.
Tokens are generated by a clock at the rate of one token

every t sec.
Idle hosts can capture and save up tokens (up to the

max. size of the bucket) in order to send larger bursts
later.
215
5-34
(a) Before (b) After

216
Algorithm
Step - 1 : A token is added at every t time.
Step - 2 : The bucket can hold at most b-tokens. If a token arrive when
bucket is full it is discarded.
Step - 3 : When a packet of m bytes arrived m tokens are removed from the
bucket and the packet is sent to the network.
Step 4 : If less than n tokens are available no tokens are removed from the
buckets and the packet is considered to be non conformant.
The non conformant packet may be enqueued for subsequent transmission

when sufficient token have been accumulated in the bucket.
217
DIFFERENCE BETWEEN LEAKY BUCKET AND TOKEN BUCKET ALGORITHM
TOKEN BUCKET LEAKY BUCKET
Token dependent. Token independent.
If bucket is full token are discarded, but not the

If bucket is full packet or data is discarded.
packet.
Packets can only transmitted when there are

Packets are transmitted continuously.
enough token
It allows large bursts to be sent faster rate after

It sends the packet at constant rate
that constant rate
It saves token to send large bursts. It does not save token.
218

Unit 1 Intro To TCPIP

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Unit 1 Intro To TCPIP

Încărcat de

Drepturi de autor:

Formate disponibile

IP - The Internet Protocol

IPs Version 4 (IPv4). It is specified in RFC 891.

IP provide provides an unreliable connectionless best effort

IP multicast also supports a many-to-many service.

20 bytes Header Size < 24 x 4 bytes = 60 bytes

1 Internet Control Message Protocol (ICMP)

Padding: Padding bytes are added to ensure

The limit on the maximum IP datagram size, imposed by the data

MTUs for various data link protocols:

IP datagram H Fragment 2 H2 Fragment 1 H1

Identification When a datagram is fragmented, the identification is the same in

Fragment offset Offset of the payload of the current

The Fragmentation Offset field is used to indicate the relative position of a

Total length Total length of the current fragment 30

TCP/IP Protocol Suite 34

TCP/IP Protocol Suite 35

The topics discussed in this section include:

TCP/IP Protocol Suite 36

TCP/IP Protocol Suite 37

TCP/IP Protocol Suite 38

TCP/IP Protocol Suite 42

TCP/IP Protocol Suite 43

An ARP request is broadcast;

TCP/IP Protocol Suite 44

A host with IP address 130.23.43.20 and

TCP/IP Protocol Suite 46

TCP/IP Protocol Suite 50

The topics discussed in this section include:

TCP/IP Protocol Suite 52

The RARP request packets are broadcast;

TCP/IP Protocol Suite 53

TCP/IP Protocol Suite 54

TCP/IP Protocol Suite 55

TCP/IP Protocol Suite 56

The following are important points about ICMP error messages:

One source-quench message is sent for

When the final destination does not receive all

de 0. Redirection for a network-specific route.

Echo-request and echo-reply messages can be

Echo-request and echo-reply messages can test

Ping Shows how long it takes for packets

64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=5 ttl=62 time=2.00 ms

--- fhda.edu ping statistics ---

We use the traceroute program to find the route from the

TCP/IP Protocol Suite 105

TCP/IP Protocol Suite 106

the ephemeral port number it has received in the request packet.

datagram ,header plus data.

The 16 bits can define a total length of 0 to 65,535 bytes.

A user datagram is encapsulated in an IP datagram.

There is a field in the IP datagram that defines the total length.

There is another field in the IP datagram that defines the length of

So if we subtract the value of the second field from the first, we

can deduce the length of the UDP datagram that is encapsulated

datagram UDP length =

The topics discussed in this section include:

Checksum Calculation at Sender

TCP/IP Protocol Suite 110

TCP/IP Protocol Suite 111

TCP/IP Protocol Suite 112

Sender calculates checksum but

TCP/IP Protocol Suite 116

UDP is a very simple, unreliable transport protocol.