Course Outcome

The purpose of learning this unit is to:

• CLR-1 : Describe the importance of various
Internet protocols like ARP, RARP, ICMP,
Multicasting and multi routing, SCTP.

At the end of this unit, learners will be able to:

• CLO-1 : Identify the basics of different types of
network and transport layer protocols.
 INTERNET PROTOCOL
VERSION 4
OBJECTIVES:
• To explain the general idea behind the IP protocol and the
position of IP in TCP/IP protocol suite.
• To show the general format of an IPv4 datagram.
• To discuss fragmentation and reassembly of datagrams.
• To discuss several options that can be in an IPv4
datagram and their applications.
• To show how a checksum is calculated for the header of an
IPv4 datagram at the sending site and how the checksum
is checked at the receiver site.
3
 Introduction of IP
The Internet Protocol (IP) is the transmission mechanism used by the
TCP/IP protocols at the network layer.
IP is an unreliable and connectionless datagram protocol—a best-
effort delivery service.
The term best-effort means that IP packets can be corrupted, lost,
arrive out of order, or delayed and may create congestion for the
network.
IP is also a connectionless protocol for a packet switching network
that uses the datagram approach.
This means that each datagram is handled independently, and each
datagram can follow a different route to the destination.
This implies that datagrams sent by the same source to the same
destination could arrive out of order, some could be lost or corrupted
during transmission.
4
Figure 1.1 Position of IP in TCP/IP protocol suite

5
 IP Datagrams
Packets in the network (internet) layer are called datagrams.
A datagram is 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.

6
Figure 1.2 IP datagram

7
 Header Format
Version (VER): This 4-bit field defines the version of the IP protocol.
Currently the version is 4.
Header length (HLEN): This 4-bit field defines the total length of the
datagram header in 4-byte words. This field is needed because the
length of the header is variable (between 20 and 60 bytes).
Service type: In the original design of IP header, this field was referred
to as type of service (TOS), which defined how the datagram should be
handled. This field now defines a set of differentiated services. The new
interpretation is shown in Figure 1.3.
The codepoint subfield can be used in two different ways.
a. When the 3 right-most bits are 0s, the 3 left-most bits are interpreted
the same as the precedence bits in the service type interpretation.
b. When the 3 right-most bits are not all 0s, the 6 bits define 56 (64 − 8)
services based on the priority assignment by the Internet or local
authorities according to Table 1.1.
8
The DSCP field consists of 6 bits, which allows for 64
different possible values (2^6 = 64).

Here not all of these 64 values are used for defining

different services or priorities. In the Internet's
Differentiated Services (DiffServ) architecture, a set of 8
specific DSCP values are reserved for specific purposes,
leaving the remaining 56 (64 - 8) values available for
defining different services or priorities.

These reserved DSCP values are typically used for

network control traffic or other specific purposes and are
not meant to be used for general service differentiation.
Figure 1.3 Service type

x x x 0 0 0 x x x x x 0
Precedence x x x x 1 1
interpretation
x x x x 0 1
Differential service
interpretation
Table 1.1 Values of Codepoints

10
Header Format
Total length: This is a 16-bit field that defines the total length (header
plus data) of the IP datagram in bytes.
Length of data = total length − header length
Figure 1.4 Encapsulation of a small datagram in an Ethernet frame

Identification: This field is used in fragmentation.

Flags: This field is used in fragmentation.
Fragmentation offset: This field is used in fragmentation.
Time to live: A datagram has a limited lifetime in its travel through an
internet. This field was originally designed to hold a timestamp,
which was decremented by each visited router. The datagram was
discarded when the value became zero.
11
Header Format Cont.
Protocol: This 8-bit field defines the higher-level protocol that uses
the services of the IP layer. An IP datagram can encapsulate data
from several higher level protocols such as TCP, UDP, ICMP, and
IGMP.
The IP protocol multiplexes and demultiplexes data from different
higher-level protocols, the value of this field helps in the
demultiplexing process when the datagram arrives at its final
destination (see Figure 1.5).
Figure 1.5 Multiplexing

12
Header Format Cont.
Some of the value of this field for different higher-level protocols is
shown in Table 1.2.
Table 1.2 Protocols

Checksum: The checksum concept and its calculation.

Source address: This 32-bit field defines the IP address of the source.
Destination address: This 32-bit field defines the IP address of the
destination.
Source and Destination address field must remain unchanged during
the time the IP datagram travels from the source host to the
destination host.
13
Example 1.1
An IP packet has arrived with the first 8 bits as shown:

The receiver discards the packet. Why?

Solution
There is an error in this packet. The 4 left-most bits (0100) show the version,
which is correct. The next 4 bits (0010) show the wrong header length (2 × 4 = 8).
The minimum number of bytes in the header must be 20. The packet has been
corrupted in transmission.

Example 1.2
In an IP packet, the value of HLEN is 1000 in binary. How many bytes of
options are being carried by this packet?
Solution
The HLEN value is 8, which means the total number of bytes in the header is 8 × 4
or 32 bytes. The first 20 bytes are the base header, the next 12 bytes are the options.

14
 Example 1.3
In an IP packet, the value of HLEN is 516 and the value of the total length field is
002816. How many bytes of data are being carried by this packet?
Solution
The HLEN value is 5, which means the total number of bytes in the header is 5 × 4
or 20 bytes (no options). The total length is 40 bytes, which means the packet is
carrying 20 bytes of data (40 − 20).
Example 1.4
An IP packet has arrived with the first few hexadecimal digits as shown below:

How many hops can this packet travel before being dropped? The data belong
to what upper layer protocol?
Solution
To find the time-to-live field, we skip 8 bytes (16 hexadecimal digits). The time-to-
live field is the ninth byte, which is 01. This means the packet can travel only one
hop. The protocol field is the next byte (02), which means that the upper layer
protocol is IGMP (see Table 1.2)
15
When data is transmitted over a network using Internet
Protocol (IP), it is divided into smaller units called packets or
datagrams.

The size of these packets is limited by the Maximum

Transmission Unit (MTU) of the network, which specifies
the largest size of data that can be transmitted in a single
packet without fragmentation.
 IP Fragmentation

A datagram can travel through different networks.

Each router decapsulates the IP datagram from the frame it receives,
processes it, and then encapsulates it in another frame.
The format and size of the received frame depend on the protocol
used by the physical network through which the frame has just
traveled.
The format and size of the sent frame depend on the protocol used by
the physical network through which the frame is going to travel.
Maximum Transfer Unit (MTU)
Each data link layer protocol has its own frame format in most
protocols. One of the fields defined in the format is the maximum size
of the data field.
When a datagram is encapsulated in a frame, the total size of the
datagram must be less than this maximum size, which is defined by
17
the restrictions imposed by the hardware and software used in the
IP Fragmentation Cont.
Figure 7.6 MTU

IP datagram

Header MTU Trailer

Maximum length of data that can be encapsulated in a frame
Frame
When a datagram is fragmented, each fragment has its own header
with most of the fields repeated, but some changed.
A fragmented datagram may itself be fragmented if it encounters a
network with an even smaller MTU.
In other words, a datagram can be fragmented several times before it
reaches the final destination.
A datagram can be fragmented by the source host or any router in the
path.
18
IP Fragmentation Cont.
Fields Related to Fragmentation
The fields that are related to fragmentation and reassembly of an IP
datagram are the identification, flags, and fragmentation offset fields.
Identification: This 16-bit field identifies a datagram originating
from the source host. The combination of the identification and
source IP address must uniquely define a datagram as it leaves the
source host.
Flags: This is a three-bit field.
The first bit is reserved (not used).
The second bit is called the do not fragment bit.
The third bit is called the more fragment bit.

Figure 1.7 Flags field

19
IP Fragmentation Cont.
Fragmentation offset: This 13-bit field shows the relative position
of this fragment with respect to the whole datagram. It is the offset
of the data in the original datagram measured in units of 8 bytes.
Figure 1.8 shows a datagram with a data size of 4000 bytes
fragmented into three fragments.
Figure 1.8 Fragmentation example
Offset = 0000/8 = 0

0000 1399

Offset = 1400/8 = 175

1400 2799

Offset = 2800/8 = 350

2800 3999
20
 IP Fragmentation Cont.
Notice the value of the identification field is the same in all
fragments. Notice the value of the flags field with the more bit set for
all fragments except the last.
1420
14,567 1 000

Bytes 0000–1399 820

14,567 1 175
Fragment 1
4020
14,567 0 000
1420 Bytes 1400–2199
14,567 1 175
Fragment 2.1

Bytes 0000–3999
Bytes 1400–2799
Original datagram Fragment 2

1220
14,567 0 350

Bytes 2800–3999
Fragment 3
Figure 1.9 Detailed fragmentation example 21
Example 1.5
A packet has arrived with an M bit value of 0. Is this the first fragment, the last
fragment, or a middle fragment? Do we know if the packet was fragmented?
Solution
If the M bit is 0, it means that there are no more fragments; the fragment is the last
one. However, we cannot say if the original packet was fragmented or not. A non
fragmented packet is considered the last fragment.

Example 1.6
A packet has arrived with an M bit value of 1. Is this the first fragment, the last
fragment, or a middle fragment? Do we know if the packet was fragmented?
Solution
If the M bit is 1, it means that there is at least one more fragment. This fragment can
be the first one or a middle one, but not the last one. We don’t know if it is the first
one or a middle one; we need more information (the value of the fragmentation
offset). See also the next example.

22
Example 1.7
A packet has arrived with an M bit value of 1 and a fragmentation
offset value of zero. Is this the first fragment, the last fragment, or
a middle fragment?
Solution
Because the M bit is 1, it is either the first fragment or a middle one.
Because the offset value is 0, it is the first fragment.

Example 1.8
A packet has arrived in which the offset value is 100. What is the number of
the first byte? Do we know the number of the last byte?
Solution
To find the number of the first byte, we multiply the offset value by 8. This means
that the first byte number is 800. We cannot determine the number of the last byte
unless we know the length of the data.

23
Example 1.9
A packet has arrived in which the offset value is 100, the value of HLEN is 5
and the value of the total length field is 100. What is the number of the first byte
and the last byte?
Solution
The first byte number is 100 × 8 = 800. The total length is 100 bytes and the header
length is 20 bytes (5 × 4), which means that there are 80 bytes in this datagram. If the
first byte number is 800, the last byte number must be 879.

24
IP Fragmentation Options

The header of the IP datagram is made of two parts: a fixed part

and a variable part.
The fixed part is 20 bytes long and was discussed in the previous
section.
The variable part comprises the options, which can be a maximum
of 40 bytes.
Options, as the name implies, are not required for a datagram.
They can be used for network testing and debugging.
Although options are not a required part of the IP header, option
processing is required of the IP software.
This means that all implementations must be able to handle options
if they are present in the header.

25
 Figure 1.10 Option format

8 bits 8 bits Variable length

Type Length Value

Number

Class 00000 End of option

00001 No operation
Copy 00 Datagram control 00011 Loose source route
01 Reserved 00100 Timestamp
0 Copy only in first fragment 10 Debugging and management 00111 Record route
1 Copy into all fragments 11 Reserved 01001 Strict source route

It is composed of a 1-byte type field, a 1-byte length field, and a

variable-sized value field.
The three fields are often referred to
as type-length-value or TLV.
26
IP Fragmentation Options Cont.
Type: The type field is 8 bits long and contains three subfields: copy, class, and
number.
Copy: This 1-bit subfield controls the presence of the option in fragmentation.
value is 0, the option must be copied only to the first fragment.
value is 1, the option must be copied to all fragments.
Class: This 2-bit subfield defines the general purpose of the option.
Value is 00, option is used for datagram control.
Value is10, option is used for debugging and management.
The other two possible values (01 and 11) have not yet been defined.
Number: This 5-bit subfield defines the type of option.
Although 5 bits can define up to 32 different types, currently only 6 types are in
use.
Length: the total length of the option including the type field and the
length field itself.
This field is not present in all of the option types.
Value: the data that specific options require.
Like the length field, this field is also not present in all option types.
27
Option Types
Figure 1.11 Categories of options

No-Operation: It is a 1-byte option used as

a filler between options. For example, it can
be used to align the next option on a 16-bit
or 32-bit boundary

Figure 1.12 No operation option

28
 End-of-Option Option:
An end-of-option option is also a 1-byte option used for padding at the end of the
option field.
It can only be used as the last option.
Only one end-of-option option can be used.
After this option, the receiver looks for the payload data.

Figure 1.13 Endo-of-option option

Record-Route Option:
A record-route option is used to record the Internet routers that handle the datagram.
It can list up to nine router IP addresses since the maximum size of the header is 60
bytes, which must include 20 bytes for the base header.
This implies that only 40 bytes are left over for the option part.
The source creates placeholder fields in the 29
option to be filled by the visited routers.
 Figure 1.14 Record-route option

When the datagram is traveling, each router that processes the datagram compares
the value of the pointer with the value of the length.
If the value of the pointer is greater than the value of the length, the option is full and
no changes are made.
The pointer field is an offset integer field containing the byte number of the first
empty entry. In other words, it points to the first available entry.
the router adds the IP address of its interface from which the datagram is leaving.
The router then increments the value of the pointer by 4.
30
 Figure 1.15 Record-route concept

7 15 4 7 15 8 7 15 12 7 15 16
140.10.6.3 140.10.6.3 140.10.6.3
200.14.7.9 200.14.7.9
138.6.22.26

67.34.30.6 138.6.25.40
67.14.10.22

138.6.22.26
200.14.7.14
140.10.6.3

140.10.5.4

200.14.7.9
67.0.0.0/24 140.10.0.0/16 200.14.7.0/24 138.6.0.0/16
Network Network Network Network

Strict-source-route option:
It is used by the source to predetermine a route for the datagram as it travels through
the Internet.
Dictation of a route by the source can be useful for several purposes.
The sender can choose a route with a specific type of service, such as minimum delay
or maximum throughput.
Alternatively, it may choose a route that is safer or more reliable for the sender’s
purpose. 31
 Figure 1.16 Strict-source-route option

Figure 1.17 Strict-source-route option

Source: 67.34.30.6 Source: 67.34.30.6 Source: 67.34.30.6 Source: 67.34.30.6
Destination: 67.14.10.22 Destination:140.10.5.4 Destination:200.14.7.14 Destination:138.6.25.40
137 15 4 137 15 8 137 15 12 137 15 16
140.10.5.4 67.14.10.22 67.14.10.22 67.14.10.22
200.14.7.14 200.14.7.14 140.10.5.4 140.10.5.4
138.6.25.40 138.6.25.40 138.6.25.40 200.14.7.14

67.34.30.6 138.6.25.40
67.14.10.22

138.6.22.26
200.14.7.14
140.10.6.3

140.10.5.4

200.14.7.9

67.0.0.0/24 140.10.0.0/16 200.14.7.0/24 138.6.0.0/16

Network Network 32
Network Network
 Figure 1.18 Loose-source-route option

A loose-source-route option is similar to the strict source route, but it is more

relaxed.
Each router in the list must be visited, but the datagram can visit other routers
as well.

Timestamp: used to record the time of datagram processing by a router.

The time is expressed in milliseconds from midnight, Universal Time.
However, no privileged users of the Internet are not usually aware of the physical
topology of the Internet.

33
 Figure 1.19 Time-stamp option

The flags field specifies the visited router responsibilities. If the flag
value is 0, each router adds only the timestamp in the provided field.
If the flag value is 1, each router must add its outgoing IP address
and the timestamp. If the value is 3, the IP addresses are given, and
each router must check the given IP address with its own incoming
IP address. 34
 Figure 1.20 Use of flags in timestamp

68 28 5 0 1 68 28 13 0 1 68 28 21 0 1 68 28 29 0 1
140.10.6.3 140.10.6.3 140.10.6.3
36000000 36000000 36000000
200.14.7.9 200.14.7.9
36000012 36000012
138.6.22.26
36000020

67.34.30.6
67.14.10.22

138.6.22.26
200.14.7.14
140.10.6.3

140.10.5.4

200.14.7.9

67.0.0.0/24 140.10.0.0/16 200.14.7.0/24 138.6.0.0/16

Network Network Network Network
35
Figure 1.21 Timestamp concept
Example 1.10
Which of the six options must be copied to each fragment?
Solution
We look at the first (left-most) bit of the type for each option.
a. No operation: type is 00000001; not copied.
b. End of option: type is 00000000; not copied.
c. Record route: type is 00000111; not copied.
d. Strict source route: type is 10001001; copied.
e. Loose source route: type is 10000011; copied.
f. Timestamp: type is 01000100; not copied.
Example 1.11
Which of the six options are used for datagram control and which
for debugging and managements?
Solution
We look at the second and third (left-most) bits of the type.
a. No operation: type is 00000001; datagram control.
b. End of option: type is 00000000; datagram control.
c. Record route: type is 00000111; datagram control.
d. Strict source route: type is 10001001; datagram control.
e. Loose source route: type is 10000011; datagram control.
f. Timestamp: type is 01000100; debugging 36 and management control.
Example 1.12
One of the utilities available in UNIX to check the traveling of the IP packets is
ping. In the next chapter, we talk about the ping program in more detail. In this
example, we want to show how to use the program to see if a host is available.
We ping a server at De Anza College named fhda.edu. The result shows that the
IP address of the host is 153.18.8.1. The result also shows the number of bytes
used.

37
Example 1.13
We can also use the ping utility with the -R option to implement the record
route option. The result shows the interfaces and IP addresses.

Example 1.14
The traceroute utility can also be used to keep track of the route of a packet.
The result shows the three routers visited.

38
Example 1.15
The traceroute program can be used to implement loose source routing. The -g
option allows us to define the routers to be visited, from the source to
destination. The following shows how we can send a packet to the fhda.edu
server with the requirement that the packet visit the router 153.18.251.4.

Example 1.16
The traceroute program can also be used to implement strict source routing.
The -G option forces the packet to visit the routers defined in the command line.
The following shows how we can send a packet to the fhda.edu server and force
the packet to visit only the router 153.18.251.4.

39
CHECKSUM
The error detection method used by most TCP/IP protocols is called
the checksum.
The checksum protects against the corruption that may occur
during the transmission of a packet.
It is redundant information added to the packet.
The checksum is calculated at the sender and the value obtained is
sent with the packet.
The receiver repeats the same calculation on the whole packet
including the checksum.
If the result is satisfactory (see below), the packet is accepted;
otherwise, it is rejected.

40
Checksum Calculation at the Sender
At the sender, the packet header is divided into n-bit sections (n is
usually 16).
These sections are added together using one’s complement
arithmetic, resulting in a sum that is also n bits long.
The sum is then complemented (all 0s changed to 1s and all 1s to 0s)
to produce the checksum.

Checksum Calculation at the Receiver

The receiver divides the received packet into k sections and adds all
sections.
It then complements the result.
If the final result is 0, the packet is accepted; otherwise, it is rejected.
Figure 1.22 shows graphically what happens at the sender and the
receiver.
41
Figure 1.22 Checksum concept

Receiver
Section 1 n bits
Section 2 n bits
..............
Checksum n bits
..............
Section k n bits

Sum n bits
Complement
If the result is 0, keep;
n bits otherwise, discard.
Result

Figure 1.23 Checksum in one’s complement arithmetic

n bits
Checksum
Packet

Sum : T
T _T
Checksum : _T
Sender Datagram
42
Example 1.17
Figure 1.24 shows an example of a checksum calculation at the sender site for
an IP header without options. The header is divided into 16-bit sections. All the
sections are added and the sum is complemented. The result is inserted in the
checksum field.

Figure 1.24 Example of checksum calculation at the sender

5 0
1 0
17
10.12.14.5
12.6.7.9

43
Example 1.18
Figure 1.25 shows the checking of checksum calculation at the receiver site (or
intermediate router) assuming that no errors occurred in the header. The
header is divided into 16-bit sections. All the sections are added and the sum is
complemented. Since the result is 16 0s, the packet is accepted.
Figure 1.25 Example of checksum calculation at the receiver

44
 Address Resolution Protocol
OBJECTIVES:
• To make a distinction between logical address (IP address)
and physical address (MAC address).
• To describe how the mapping of a logical address to a
physical address can be static or dynamic.
• To show how the address resolution protocol (ARP) is used
to dynamically map a logical address to a physical address.
• To show that the proxy ARP can be used to create a
subnetting effect.
• To show that an ARP software package can be made of five
components.
 ADDRESS MAPPING
The hosts and routers are recognized at the network level by their
logical addresses.
A logical address is an internetwork address and unique universally.
It is called a logical address because it is usually implemented in
software.
Every protocol that deals with interconnecting networks requires
logical addresses.
The logical addresses in the TCP/IP protocol suite are called IP
addresses and are 32 bits long.
A physical address is a local address, because it is usually (but not
always) implemented in hardware.
Examples of physical addresses are 48-bit MAC addresses in the
Ethernet protocol, which are imprinted on the NIC installed in the
host or router.
46
ADDRESS MAPPING
Static Mapping
Static mapping means creating a table that associates a logical
address with a physical address.
This table is stored in each machine on the network.
Each machine that knows, for example, the IP address of another
machine but not its physical address can look it up in the table.
Dynamic Mapping
Each time a machine knows the logical address of another machine,
it can use a protocol to find the physical address.
Two protocols have been designed to perform dynamic mapping:
Address Resolution Protocol (ARP) and Reverse Address
Resolution Protocol (RARP).
ARP maps a logical address to a physical address;
RARP maps a physical address to a logical address.
47
Address Resolution Protocol

Anytime a host or a router has an IP datagram to send to

another host or router, it has the logical (IP) address of the
receiver.
But the IP datagram must be encapsulated in a frame to be
able to pass through the physical network.
This means that the sender needs the physical address of
the receiver.
A mapping corresponds a logical address to a physical
address.
ARP accepts a logical address from the IP protocol, maps
the address to the corresponding physical address and pass
it to the data link layer.

48
Anytime a host or a router has an IP datagram to send to another
host or router, it has the logical (IP) address of the receiver.
But the IP datagram must be encapsulated in a frame to be able to
pass through the physical network.
This means that the sender needs the physical address of the
receiver.
A mapping corresponds a logical address to a physical address.

Figure 1.25 Position of ARP in TCP/IP protocol suite

49
 Figure 1.26ARP operation

LAN

System A System B

Request

Looking for physical address of a

node with IP address 141.23.56.23

a. ARP request is broadcast

multicast

LAN

System A System B

Reply

The node physical address

is A4:6E:F4:59:83:AB

b. ARP reply is unicast

50
Figure 1.27 ARP packet

51
 ARP Packet Format
The fields are as follows:
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 the type 1. ARP can be used on any physical network.
Protocol type This is a 16-bit field defining the protocol.
For example, the value of this field for the IPv4 protocol is 080016.
ARP can be used with any higher-level protocol.
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.
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.
Operation: This is a 16-bit field defining the type of packet. Two packet
types are defined: ARP request (1), ARP reply (2).
52
ARP Packet Format Cont.
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.
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.
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 all 0s because the sender
does not know the physical address of the target.
Target protocol address: This is a variable-length field defining the
logical (for
example, IP) address of the target.
For the IPv4 protocol, this field is 4 bytes long.
53
 Figure 1.28 Encapsulation of ARP packet

Type: 0x0806

Preamble Destination Source

Type Data CRC
and SFD address address
8 bytes 6 bytes 6 bytes 2 bytes 4 bytes

Encapsulation
An ARP packet is encapsulated directly into a data link frame.
For example, an ARP packet is encapsulated in an Ethernet frame.
Note that the type field indicates that the data carried by the frame
is an ARP packet.
Operation
Let us see how ARP functions on a typical internet.
First we discuss the four cases in which a host or router needs to
use ARP.
54
Figure 1.29 Four cases using ARP

55
Example 8.1
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.
The two hosts are on the same Ethernet network. Show the ARP
request and reply packets encapsulated in Ethernet frames.

Solution
Figure 1.30 shows the ARP request and reply packets. Note that the
ARP data field in this case is 28 bytes, and that the individual
addresses do not fit in the 4-byte boundary. That is why we do not
show the regular 4-byte boundaries for these addresses. Also note
that the IP addresses are shown in hexadecimal.

56
Figure 1.30 Example 1.26

57
 Figure 1.31Proxy ARP
Added subnetwork
The proxy ARP router replies 141.23.56.21 141.23.56.22 141.23.56.23
to any ARP request received
for destinations 141.23.56.21,
141.23.56.22, and 141.23.56.23.

Request
Proxy ARP
Router or host router

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.
58
 ARP PACKAGE
we give an example of a simplified ARP software package.
The purpose is to show the components of a hypothetical ARP
package and the relationships between the components.
We can say that this ARP package involves five components:
1) a cache table
2) Queues
3) an output module
4) an input module
5) a cache-control module.

59
Figure 1.32 ARP components

60
ARP PACKAGE Cont.
Cache Table
A sender usually has more than one IP datagram to send to the same
destination.
It is inefficient to use the ARP protocol for each datagram destined
for the same host or router.
The solution is the cache table.
When a host or router receives the corresponding physical address
for an IP datagram, the address can be saved in the cache table.
The cache table is implemented as an array of entries. In our
package, each entry contains the following fields:
State: This column shows the state of the entry. It can have one of
three values: FREE, PENDING, or RESOLVED.
Hardware type
Protocol type
Hardware length. 61
ARP PACKAGE Cont.
Protocol length
Interface number: A router (or a multihomed host) can be
connected to different networks, each with a different interface
number.
Each network can have different hardware and protocol types.
Queue number: ARP uses numbered queues to enqueue the
packets waiting for address resolution.
Packets for the same destination are usually enqueued in the same
queue.
Attempts: This column shows the number of times an ARP request
is sent out for this entry.
Time-out: This column shows the lifetime of an entry in seconds.
Hardware address: This column shows the destination hardware
address. It remains empty until resolved by an ARP reply.
Protocol address
62
Output Module

63
Input Module

64
Cache Control Module

65
66
Example 8.2
The ARP output module receives an IP datagram (from the IP layer) with the
destination address 114.5.7.89. It checks the cache table and finds that an entry
exists for this destination with the RESOLVED state (R in the table). It extracts
the hardware address, which is 457342ACAE32, and sends the packet and the
address to the data link layer for transmission. The cache table remains the
same.

67
Example 8.3
Twenty seconds later, the ARP output module receives an IP datagram (from
the IP layer) with the destination address 116.1.7.22. It checks the cache table
and does not find this destination in the table. The module adds an entry to the
table with the state PENDING and the Attempt value 1. It creates a new queue
for this destination and enqueues the packet. It then sends an ARP request to
the data link layer for this destination. The new cache table is shown in Table
8.6.

68
Example 8.4
Fifteen seconds later, the ARP input module receives an ARP packet with target
protocol (IP) address 188.11.8.71. The module checks the table and finds this
address. It changes the state of the entry to RESOLVED and sets the time-out
value to 900. The module then adds the target hardware address
(E34573242ACA) to the entry. Now it accesses queue 18 and sends all the
packets in this queue, one by one, to the data link layer. The new cache table is
shown in Table 8.7.

69
Twenty-five seconds later, the cache-control module updates every entry. The
time-out values for the first three resolved entries are decremented by 60. The
time-out value for the last resolved entry is decremented by 25. The state of
the next-to-the last entry is changed to FREE because the time-out is zero.
For each of the three pending entries, the value of the attempts field is
incremented by one. After incrementing, the attempts value for one entry (the
one with IP address 201.11.56.7) is more than the maximum; the state is
changed to FREE, the queue is deleted, and an ICMP message is sent to the
original destination See Table 8.8.

70
 Reverse Address
Resolution Protocol
RARP Procedure
Steps to Achieve the IP Address from RARP Server:
1.Source Device “Generates RARP Request Message” – The
source device generates a RARP Request message. The Source puts
its own data link-layer address as both the Sender Hardware
Address and also the Target Hardware Address. It leaves both the
Sender Protocol Address and the Target Protocol Address blank.
2.Source Device “Broadcasts RARP Request Message” – The
source broadcasts the ARP Request message on the local network.
3.Local Devices “Process RARP Request Message” – The
message is received by each device on the local network and
processed. Devices that are not configured to act as RARP servers
ignore the message.

72
RARP Procedure
4. RARP Server Generates RARP Reply Message: Any device on
the network that is a RARP server responds to the broadcast from
the source device. It generates a RARP Reply and sets the Sender
Hardware Address and Sender Protocol Address to its own
hardware and IP address of course. It looks up in a table the
hardware address of the source, determines that device’s IP address
assignment, and puts it into the Target Protocol Address field.
5. RARP Server Sends RARP Reply Message: The RARP server
sends the RARP Reply message unicast to the device looking to be
configured.
6. Source Device Processes RARP Reply Message: The source
device processes the reply from the RARP server. It then configures
itself using the IP address in the Target Protocol Address supplied
by the RARP server
73
RARP Procedural Steps

74
Introduction to Internet Control Message
Protocol (ICMP)

• IP protocol has no error-reporting or error-correcting

mechanism
• When errors occur, no built-in mechanism to notify the original host
• IP protocol also lacks a mechanism for host and
management queries
• A host sometimes needs to determine if a router or another host is alive
• Network manager needs information from another host and router
Introduction to Internet Control Message
Protocol (ICMP)
• Position of ICMP in the network layer
Introduction to Internet Control Message
Protocol (ICMP)
Types of Messages
• Category of ICMP messages
ICMP MESSAGE TYPES
Types of Messages
• CMP messages
• Error reporting messages
Types of Messages
• ICMP messages
• Query messages
Message Format
• Having 8 byte header and variable-size data section
• ICMP type : defining the type of the message
• Code field : specifying the reason for the particular message type
• Checksum field (for header and message)
• Data section
• In error message, carrying information for finding
the original packet which caused the error
• In query message, carrying extra information
based on the type of the query
Message Format
Error Reporting
• Error checking and control
• Not correcting errors : it is left to the higher level
protocols
• Always reporting error messages to the original source
Error Reporting (cont’d)
• Error checking and control
• Not correcting errors : it is left to the higher level
protocols
• Always reporting error messages to the original source
Error Reporting (cont’d)
• Error-reporting messages
Error Reporting (cont’d)
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.
• No ICMP error message will be generated for a
datagram having a multicast
• address.
• No ICMP error message will be generated for a
datagram having a special address
• such as 127.0.0.0 or 0.0.0.0.
Error Reporting (cont’d)
• All error messages
• containing a data section that includes the IP header of the original datagram + the
first 8 bytes of data in that IP datagram
• 8 bytes of data : port # (UDP and TCP ) and sequence # (TCP)
• Used for informing to the protocols (TCP or
UDP) about the error situation
Error Reporting (cont’d)
• Contents of data field for the error messages
Error Reporting (cont’d)
• Destination Unreachable
• When a router cannot route a datagram or a host
cannot deliver a datagram, the datagram is discarded.
• Then, the router or the host sends a destination
unreachable message back to the source that initiated
the datagram.
• Destination unreachable format
Error Reporting (cont’d)
Code 0 : network is unreachable, due to hardware failure,
can only be generated by a router
Code 1 : host is unreachable, due to hardware failure, can
only be generated by a router
Code 2 : protocol such as UDP, TCP or OSPF is not running
at the moment.
• generated only by the destination
Code 3 : the application program (process) that the datagram
is destined for is not running at the moment
Code 4 : Fragmentation is required, but the DF (do not
fragment) field has been set
Code 5 : Source routing cannot be accomplished
Code 6 : The destination network is unknown.
• A router has no information about the destination network
Error Reporting (cont’d)
Code 7 : The destination host is unknown.
• the router is unaware of the existence of the destination
Code 8 : The source host is isolated
Code 9 : Communication with the destination network is
administratively prohibited
Code 10 : Communication with the destination host is
administratively prohibited
Code 11 : the network is unreachable for the specified type
of service
Code 12 : The host is unreachable for the specified type of
service
Error Reporting (cont’d)
Code 13 : The host is unreachable because the
administration has put a filter on it
Code 14 : The host is unreachable because the host
precedence is violated. The requested precedence is not
permitted for the destination
Code 15 : The host is unreachable because its precedence
was cut off. This message is generated when the network
operators have imposed a minimum level of precedence for
the operation of the network
Error Reporting (cont’d)
• Destination-unreachable messages with codes 2 or 3 can be
created only by the destination host. Other destination-
unreachable message can be created only by routers.
• A router can not detect all problems that prevent the
delivery of a packet.
• The case that a datagram is traveling through an Ethernet
network.
• Ethernet does not provide any acknowledgement
mechanism.
Error Reporting (cont’d)
Source Quench
• is designed to add a kind of flow control to the IP
• IP does not have a flow-control mechanism embedded in the
protocol
• when a router or host discards a datagram due to
congestion, it sends a source-quench message to the sender
of the datagram
• making slow down the sending process
Error Reporting (cont’d)
Time exceeded
• Whenever a router receives a datagram whose time-to-
live field has the value of zero, it discards the datagram
and sends a time-exceeded message to the original
source
• 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
Error Reporting (cont’d)
• In a time-exceeded message, code 0 is used only by
routers to show that the value of the time-to-live field
is zero. Code 1 is used only by the destination host to
show that not all of the fragments have arrived within a
set time
• Time-exceeded message format
Error Reporting (cont’d)
Parameter-problem
• A parameter-problem message caused by ambiguity in
the header part can be created by a router or the
destination host
Code 0 : error or ambiguity in one of the header fields
• the value in the pointer field points to the byte with the
problem
Code 1 : the required part of an option is missing. In this
case, pointer is not used
Error Reporting (cont’d)
Redirection
• A host usually starts with a small routing table that is
gradually augmented and updated. One of the tools to
accomplish this is the redirection message.
• A redirection message is sent from a router to a host on
the same local network.
Error Reporting (cont’d)
Redirection message format
Code 0 : redirection for the network-specific route
Code 1 : redirection for the host-specific route
Code 2 : redirection for network-specific route based on
specific type of service
Code 3 : redirection for the host-specific route based on
the specified type of servic
Query
• Diagnosing some network problems
• 4 different pairs of messages
Query (cont’d)
Echo Request and Reply messages
• designed for diagnostic purpose
• the combination of echo-request and echo-reply
messages determines whether 2 systems (hosts or
routers) can communicate with each other
• 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 message can be used by
network managers to check the operation of the IP
protocol
Query (cont’d)
• Echo-request and echo-reply messages can test the
reachability of a host. This is usually done by invoking
the ping command
• Identifier and sequence number fields are not formally
defined by the protocol and can be used by the sender
• Echo-request and echo-reply message
Query (cont’d)
• The identifier field The sequence number field
• defines a group of problems
• ex) process ID that originated the request
• The sequence number field
• keeps track of the particular echo request messages sent
• At the user level
• Invoking the packet Internet groper (ping) command
Query (cont’d)
Timestamp Request and Reply
• 2 machines (routers or hosts) can use the timestamp-
request and timestamp-reply messages to determine the
round-trip time needed for an IP datagram to travel
between them
• can used to synchronize the clocks in two machines
• Three timestamp fields are each 32 bits long
• holding a number representing time measured in milliseconds
from midnight in Universal Time
• Cannot exceed 86,400,000 = 24 x 60 x 60 x 1,000
Query (cont’d)
Timestamp-request and reply message format

• original timestamp field : clock at departure time

• receive timestamp field : at the time the request was received
• transmit timestamp field : at the time the reply message departs
Query (cont’d)
The formulas for computing the one-way or round-trip
time required for a datagram to go from a source to a
destination and then back again.
 Sending time = value of receive timestamp – value of original time stamp
 Receiving time = time the packet returned – value of transmit timestamp
 Round-trip time = sending time + receiving time
Query (cont’d)
Timestamp-request and timestamp reply message can be
used to measure the round-trip time between a source
and a destination machine even if their clocks are not
synchronized
Example
Value of original timestamp : 46
Value of receive timestamp : 59
Value of transmit timestamp : 60
Time the packet arrived : 67
Sending time = 13 ms
Receiving time = 7 ms
Round-trip time = 20 ms
Query (cont’d)
Synchronizing clocks between two machines
Time difference = receive timestamp – (original timestamp field
+ oneway time duration)
In previous example,
Time difference = 59 – (46+10 ) = 3
Query (cont’d)
Address Mask Request and Reply
• for differentiating among network address, subnetwork address
and host ID
• example, a host may know its 32-bit IP address as

• left 20 bits are network and subnetwork addresses and

remaining 12 bits are Host ID. In this case, following mask
Query (cont’d)
To obtain its mask,
• A host sends an address-mask-request message to a router on
the LAN. (unicast or broadcast)
• If the host knows the address of the router, it sends the request
directly to the router, if not, it broadcasts the message.
Query (cont’d)
• Masking is needed for diskless stations at start-up
time.
• When a diskless station comes up for the first time
• it may ask for its full IP address using RARP protocol
• after receiving its IP address, it may use the address mask
request and reply to find out which part of the address
defines the subnet
Query (cont’d)
Router Solicitation and Advertisement
• A host that wants to send data to a host on another network
needs to know the address of routers connected to its own
network.
• the host should know if the routers are alive and functioning
• A host can broadcast (or multicast) a router-solicitation message.
• The router or routers that receive the solicitation message
broadcast their routing information using the router-advertisement
message.
• A router can also periodically advertise router-advertisement messages even if
no host has solicited
Query (cont’d)
• Router-solicitation message format
Query (cont’d)
• Router-advertisement message format
• lifetime field : showing the number of seconds that entries are
considered to be valid
• address preference level defines the ranking of the router
• preference level 0 : default router
• preference level : the router should never be selected as the
default router
Checksum
Checksum
• calculating over the entire message (header and data)
• Checksum calculation
1. Checksum field is set to zero
2. Sum of all the 16-bit words (header and data) is calculated
3. Sum is complemented to get the checksum
4. Checksum is stored in the checksum field
Checksum (cont’d)
Checksum testing Example,
1. the sum of all words (header and data) is calculated
2. the sum is completed
3. if the result obtained in step 2 is 16 0s, the message is
accepted; otherwise, it is rejected.
Example,
ICMP– DEBUGGING TOOL
• To check whether host or router is alive and running
• To trace the route of a packet.
• Two tools that use ICMP for debugging: ping and
traceroute
Ping
• The ping program to find if a host is alive and
responding.
• Command : ping the ip of the host.(ping 152.18.1.3)
• The source host sends ICMP echo request messages
(type: 8, code: 0);
• The destination, if alive, responds with ICMP echo
reply messages.
ICMP– DEBUGGING TOOL
• Ping cont…
• Starts the sequence number from 0; this number is incremented
by one each time a
• new message is sent.
• ping can calculate the round-trip time.
• Inserts the sending time in the data section of the message.
• When packet arrives it subtracts the arrival time from the
departure time to get the
Round-Trip Time (RTT).
• The TTL (time to live) field is encapsulates an ICMP message
as 62, which means the
• packet cannot travel more than 62 hops
ICMP– DEBUGGING TOOL
Example : $ 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
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=1 ttl=62 time=2.04 ms
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=2 ttl=62 time=1.90 ms
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=3 ttl=62 time=1.97 ms
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=4 ttl=62 time=1.93 ms
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=5 ttl=62 time=2.00 ms
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=6 ttl=62 time=1.94 ms
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=7 ttl=62 time=1.94 ms
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=8 ttl=62 time=1.97 ms
64 bytes from tiptoe.fhda.edu (153.18.8.1): icmp_seq=9 ttl=62 time=1.89 ms
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 10103 ms
rtt min/avg/max = 1.899/1.955/2.041 ms
ICMP– DEBUGGING TOOL
Ping cont…
• Ping data bytes as 56 and the total number of bytes as
84.
• 8 bytes ICMP header+ 20 bytes of IP header to 56 =84
• ping defines the number of bytes as 64(56 + 8).
• Interrupts message ctrl+c.
• it prints the statistics of the probes
• number of packets sent,
• the number of packets received.
• the total time
• the RTT minimum, maximum, and average.
ICMP– DEBUGGING TOOL
• TRACE ROUTE
• The traceroute program in UNIX or tracert in
Windows.
• It is used to route the packets from source to
destination.
Example Scenario

The Traceroute Program Operation

ICMP– DEBUGGING TOOL
Trace route cont….
• In above example Given the topology, A packet from
host A to host B travels through routers R1 and R2.
• The traceroute program find the address of router R1
& RTT between host A and router R1.
• The program repeats steps a to c three times to get a
better average round-trip time.
• a. Host A sends a packet to destination B using UDP the
message is
• encapsulated in an IP packet with a TTL value of 1. The
program notes the time the packet is sent
ICMP– DEBUGGING TOOL
Trace route cont.….
b. Router R1 receives the packet and decrements the
value of TTL to 0. It then discards the packet (because
TTL is 0).
c. In receiver the ICMP messages uses the source
address of the IP packet to find the IP address of router
R1 and also makes note of the time the packet has
arrived.
• The traceroute program repeats the previous steps to
find the address of router R2 and the round-trip time
between host A and router R2.
• The round-trip time between host A and host B.
ICMP– DEBUGGING TOOL
Trace route cont.….
Example: The traceroute program to find the route from the
computer voyager.deanza.edu to the server fhda.edu. The
following shows the result.
$ traceroute fhda.edu
traceroute to fhda.edu (153.18.8.1), 30 hops max, 38 byte packets
1 Dcore.fhda.edu (153.18.31.25) 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
• In the above example the destination is 153.18.8.1.
• TTL value is 30 hops.
• The packet contains 38 bytes: 20 bytes of IP header, 8 bytes of UDP
header, and 10 bytes of application data.
ICMP– DEBUGGING TOOL
Trace route cont.….
• The router is named Dcore.fhda.edu with IP address
153.18.31.254.
• The Round Trip Time
1. 0.995 milliseconds,
2. 0.899 milliseconds
3. 0.878 milliseconds
• The router is named Dbackup.fhda.edu with IP address
153.18.251.4.
• The third line shows the destination host
ICMP DESIGN
To handle the ICMP sending and receiving messages
ICMP package made of two modules:
• input module
• output module
ICMP Design (cont’d)
Input module
• handling all received ICMP message
• invoked when an ICMP packet is delivered to it from
the IP layer
• if the received packet is a request or solicitation, the
module creates a reply or an advertisement and sends it
out
• if the received packet is a redirection message, the
module uses the information to update the routing table
• if the received packet is an error message, the module
informs the protocol about the situation that caused the
error
INPUT MODULE
Pseudocode for Input Module
ICMP DESIGN
OUTPUT MODULE
• responsible for creating request, solicitation, or error
messages requested by a higher level or the IP protocol.
• the module receives a demand from IP, UDP or TCP to
send one of the ICMP error messages
• if the demand is from IP
• check first that request is allowed
• ICMP message cannot be created for four situations;
• ICMP error message
• Fragmented IP packet
• Multicast IP packet
• IP packet having IP address or 127.X.Y.Z
• May also receive a demand from an application program to
send one of the ICMP request or solicitation messages
OUTPUT MODULE
Pseudocode for Output Module
132
 USER DATAGRAM PROTOCOL
UDP – An Introduction
 Connectionless service
 Unreliable transport protocol.
 No flow control / No Acknowledgement
 Process to Process communication
 Powerless
 It uses minimum of over heads
 No reliability is obtained using UDP
 Less interaction between sender and receiver
133
 USER DATAGRAM PROTOCOL
USER DATAGRAM

User datagram header format

 Above picture depicts user data gram format

 UDP packets are called user datagrams(messages)
 It has fixed size header of 8 bytes
134
 USER DATAGRAM PROTOCOL
UDP Datagram various fields
 Source Port Number:
• 16 bits long – port ranges from 0-65535.
• This port number will be used by the source host for identification.
 Destination Port Number:
• 16 bits long.
• Used by the process running on the Destination machine.
• Application level service on end machine

135
 USER DATAGRAM PROTOCOL
UDP Datagram various fields
 Length:
 Length field specifies the entire length of UDP
UDP length=IP length – IP headers Length
packet (including header).
 It is 16-bits field and minimum value is 8-byte,
i.e. the size of UDP header
• itself.
 A user datagram is encapsulated in an IP
datagram.
 Checksum:
plus data)
• This field is used to detect errors over the entire user 136

datagram (header
 USER DATAGRAM PROTOCOL
UDP Services
 Process to Process communication
 UDP provides process-to-process communication using sockets, a combination of IP
addresses and port numbers. Several port numbers used by UDP.

137
 USER DATAGRAM PROTOCOL
UDP Services cont…
 cannot send a stream of data to
 Connectionless services: UDP, It will chop them into
 Connectionless service. differentrelated user datagrams.
 Flow control:
 Each datagram is independent
 No Flow Control and no window
even it comes from same source
mechanism.
and delivered in same destination.
 The receiver may overflow with
 The datagrams are not numbered.
incoming messages.
 No connection establishments is
 UDP should provide for this
done
service, if needed
138
 USER DATAGRAM PROTOCOL
UDP Services cont…
 Error Control: Checksum
 Three sections: a pseudo header, the
 No Error control mechanism UDP header, and the data coming
except for checksum from the application layer.
 Sender is unknown about the loss
and duplication.
 When error detects in receiver the
datagram is discarded

Pseudoheader for checksum calculation

139
 USER DATAGRAM PROTOCOL
UDP Services cont…

Check Sum Calculation

140
 USER DATAGRAM PROTOCOL
UDP Services cont…
 UDP receives data and add UDP
 Congestion Control header then pass to IP with
 It is a connectionless protocol so socket.
congestion control not provided.  IP add its own header using value
 Encapsulation and Decapsulation
17

 Encapsulation
• in protocol filed.
 A process send message through  Indicating UDP protocol.
UDP
 The IP datagram is then passed to
 Along pair of socket address and
the length of data. the data link layer.
 The data link layer receives the IP
datagram and passes it to141 the
physical layer.
 The physical layer encodes the bits
 USER DATAGRAM PROTOCOL
UDP Services cont…

 Decapsulation:
 At the destination host:
 the physical layer decodes the
signals pass to data link layer.
 The data link layer uses the
header (and the
trailer) to check the data.
 If there is no error
 the header and trailer are
dropped , datagram is passed to
IP.
Encapsulation and Decapsul1a42tion
 USER DATAGRAM PROTOCOL
UDP Services cont…
 The header is dropped and the user datagram is passed to UDP with the sender
and receiver IP addresses.

 Checksum is to check the entire user datagram.

 the header is dropped and the application data along with the sender socket
address is passed to the process.
 The sender socket address is passed to the process in case it needs to respond to
the message received.

143
 USER DATAGRAM PROTOCOL
UDP Services cont…
Queuing in UDP

144
 USER DATAGRAM PROTOCOL
UDP Services cont…
Queuing in UDP
 At the client site, when a process starts, it requests a port number from the
operating system. Some implementations create both an incoming and an outgoing
queue associated with each process. Other implementations create only an
incoming queue associated with each process
 process wants to communicate with multiple processes, it obtains only one port
number and eventually one outgoing and one incoming queue. The queues opened
by the client are, in most cases, identified by ephemeral port numbers. The queues
function as long as the process is running. When the process terminates, the queues
are destroyed.
 The client process can send messages to the outgoing queue by using the source
port number specified in the request
145
 USER DATAGRAM PROTOCOL
UDP Services cont…
Queuing in UDP
 The client process can send messages to the outgoing queue by using the source
port number specified in the request
 UDP removes the messages one by one and, after adding the UDP header, delivers
them to IP. An outgoing queue can overflow
 It happens the operating system can ask the client process to wait before sending
any more messages

146
 USER DATAGRAM PROTOCOL
UDP Services cont…

Applications of UDP:
Used for simple request response communication when size of data is less hence there
is lesser concern about flow and error control.
It is suitable protocol for multicasting as UDP supports packet switching.
Following implementations uses UDP as a transport layer protocol:
NTP (Network Time Protocol)
DNS (Domain Name Service)
BOOTP, DHCP.
NNP (Network News Protocol)
Quote of the day protocol
TFTP, RTSP, RIP, OSPF.
UDP is null protocol if you remove checksum field.
147
 USER DATAGRAM PROTOCOL
UDP Services cont…

When to use UDP? Reduce the requirement of computer resources.

When using the Multicast or Broadcast to transfer.
The transmission of Real-time packets, mainly in multimedia applications

148
 USER DATAGRAM PROTOCOL
UDP Package

UDP design
149
 USER DATAGRAM PROTOCOL
UDP Package
 The UDP package involves five components:

 Control-Block Table

 UDP has a control-block table to keep track of the open ports.

 Each entry in this table has a minimum of four fields: the state, which can be FREE
or IN-USE, the process ID, the port number, and the corresponding queue number.

 Input Queues

 Our UDP package uses a set of input queues, one for each process. In this design, we
do not use output queues.
150
 USER DATAGRAM PROTOCOL
UDP Package
UDP_Control_Block_Module (process ID, port
 Control-Block Module number)
 The control-block module is {
responsible for the management of the Search the table for a FREE entry.
if (not found)
control-block table. Delete one entry using a predefined strategy.
 When a process starts, it asks for a port Create a new entry with the state IN-USE
number from the operating system. Enter the process ID and the port number.
Return.
 The operating system assigns well- } // End module
known port numbers to servers and
ephemeral port numbers to clients.
 The process passes the process ID and
the port number to the control-block
module to create an entry in the table
for the process.
151
USER DATAGRAM PROTOCOL
UDP_INPUT_Module (user_datagram)
{
Look for the entry in the control_block table
• UDP Package
if (found)
{
 Input Module
Check to see if a queue is allocated
 The input modulereceives
If (queue is not allocated)
allocate a queue
a user datagram from the
else
IP. It searches
enqueue the thedata
control-
block table
} //end if to find an
entry else
having the same
port number
{ as this user
Ask ICMP to send an "unreachable port" message
datagram.
Discard the user datagram
 If the entry is found, the
} //end else
moduleReturn. uses the
} // end module
information in the entry
to enqueue the data.If the
152
entry is not found, it
generates an ICMP
message..
 USER DATAGRAM PROTOCOL
UDP Package

Output Module
 The output module is responsible for creating and sending user datagrams.
UDP_OUTPUT_MODULE (Data)

{
Create a user datagram
Send the user datagram
Return.

153
 UDP Features at a Glance

• UDP is connectionless

• UDP uses ports for data transmission

• UDP guarantees fast and delay-free communication

• UDP doesn’t care about data integrity or reliability

• UDP can be vulnerable to denial of service attacks (DDOS)

 TCP Connection (A 3-way handshake)
• Handshake refers to the process to establish connection between the client and server.
Handshake is simply defined as the process to establish a communication link.

• To transmit a packet, TCP needs a three way handshake before it starts sending data.

• The reliable communication in TCP is termed as par (positive acknowledgement re-

transmission).

• When a sender sends the data to the receiver, it requires a positive acknowledgement
from the receiver confirming the arrival of data.

• If the acknowledgement has not reached the sender, it needs to resend that data.

• The positive acknowledgement from the receiver establishes a successful connection.

• Here, the server is the server and client is the receiver.
• The above diagram shows 3 steps for successful connection.
• A 3-way handshake is commonly known as SYN-SYN-ACK and requires both the client and
server response to exchange the data.
• SYN means synchronize Sequence Number and ACK means acknowledgment.
• Each step is a type of handshake between the sender and the receiver.
The three handshakes are discussed in the below steps:

Step 1: SYN
• SYN is a segment sent by the client to the server.

• It acts as a connection request between the client and server. It informs the
server that the client wants to establish a connection.

• Synchronizing sequence numbers also helps synchronize sequence numbers

sent between any two devices, where the same SYN segment asks for the
sequence number with the connection request.
Step 2: SYN-ACK
• It is an SYN-ACK segment or an SYN + ACK segment sent by the server.

• The ACK segment informs the client that the server has received the
connection request and it is ready to build the connection.

• The SYN segment informs the sequence number with which the server is
ready to start with the segments.
Step 3: ACK
• ACK (Acknowledgment) is the last step before establishing a successful TCP
connection between the client and server.

• The ACK segment is sent by the client as the response of the received ACK and
SN from the server. It results in the establishment of a reliable data
connection.

• After these three steps, the client and server are ready for the data
communication process
 TCP Header
The following diagram represents the TCP header format-
1. Source Port-
• Source Port is a 16 bit field.
• It identifies the port of the sending application.

2. Destination Port-
• Destination Port is a 16 bit field.
• It identifies the port of the receiving application.

3. Sequence Number-
• Sequence number is a 32 bit field.
• TCP assigns a unique sequence number to each byte of data contained in the
TCP segment.
• This field contains the sequence number of the first data byte.
Acknowledgement Number-
• Acknowledgment number is a 32 bit field.
• It contains sequence number of the data byte that receiver expects to receive next
from the sender.
• It is always sequence number of the last received data byte incremented by 1.

Header Length-
• Header length is a 4 bit field.
• It contains the length of TCP header.
• It helps in knowing from where the actual data begins.

Reserved Bits-
• The 6 bits are reserved.
• These bits are not used.
URG Bit-
URG bit is used to treat certain data on an urgent basis.
• When URG bit is set to 1,
• It indicates the receiver that certain amount of data within the current segment is
urgent.
• Urgent data is pointed out by evaluating the urgent pointer field.
• The urgent data has be prioritized.
• Receiver forwards urgent data to the receiving application on a separate channel.
ACK Bit-
ACK bit indicates whether acknowledgement number field is valid or not.
• When ACK bit is set to 1, it indicates that acknowledgement number contained in the
TCP header is valid.
• For all TCP segments except request segment, ACK bit is set to 1.
• Request segment is sent for connection establishment during Three Way Handshake.
PSH Bit-
PSH bit is used to push the entire buffer immediately to the receiving application.
• When PSH bit is set to 1,
• All the segments in the buffer are immediately pushed to the receiving application.
• No wait is done for filling the entire buffer.
• This makes the entire buffer to free up immediately.

RST Bit- RST bit is used to reset the TCP connection.

• When RST bit is set to 1,
• It indicates the receiver to terminate the connection immediately.
• It causes both the sides to release the connection and all its resources abnormally.
• The transfer of data ceases in both the directions.
• It may result in the loss of data that is in transit.

This is used only when-

• There are unrecoverable errors.
• There is no chance of terminating the TCP connection normally.
SYN Bit- SYN bit is used to synchronize the sequence numbers.
• When SYN bit is set to 1,
• It indicates the receiver that the sequence number contained in the TCP
header is the initial sequence number.
• Request segment sent for connection establishment during Three way
handshake contains SYN bit set to 1.

FIN Bit- FIN bit is used to terminate the TCP connection.

• When FIN bit is set to 1,
• It indicates the receiver that the sender wants to terminate the connection.
• FIN segment sent for TCP Connection Termination contains FIN bit set to 1.
Window Size-
• Window size is a 16 bit field.
• It contains the size of the receiving window of the sender.
• It advertises how much data (in bytes) the sender can receive without
acknowledgement.
• Thus, window size is used for Flow Control.

Checksum-
• Checksum is a 16 bit field used for error control.
• It verifies the integrity of data in the TCP payload.
• Sender adds CRC checksum to the checksum field before sending the data.
• Receiver rejects the data that fails the CRC check.
Urgent Pointer-
• Urgent pointer is a 16 bit field.
• It indicates how much data in the current segment counting from the first data
byte is urgent.
• Urgent pointer added to the sequence number indicates the end of urgent data
byte.
• This field is considered valid and evaluated only if the URG bit is set to 1.

Options-
• Options field is used for several purposes.
• The size of options field vary from 0 bytes to 40 bytes.
Options field is generally used for the following purposes-
• Time stamp
• Window size extension
• Parameter negotiation
• Padding

Time Stamp-
• When wrap around time is less than life time of a segment,
• Multiple segments having the same sequence number may appear at the
receiver side.
• This makes it difficult for the receiver to identify the correct segment.
• If time stamp is used, it marks the age of TCP segments.
• Based on the time stamp, receiver can identify the correct segment.
Window Size Extension-
• Options field may be used to represent a window size greater than 16 bits.
• Using window size field of TCP header, window size of only 16 bits can be represented.
• If the receiver wants to receive more data, it can advertise its greater window size using this field.
• The extra bits are then appended in Options field.

Parameter Negotiation-
• Options field is used for parameters negotiation.
• Example- During connection establishment,
• Both sender and receiver have to specify their maximum segment size.
• To specify maximum segment size, there is no special field.
• So, they specify their maximum segment size using this field and negotiates.

Padding-
• Addition of dummy data to fill up unused space in the transmission unit and make it conform to the
standard size is called as padding.
• Options field is used for padding.
 Error Control in TCP
TCP protocol has methods for finding out corrupted segments, missing segments, out-
of-order segments and duplicated segments.

Error control in TCP is mainly done through the use of three simple techniques :

• Checksum – Every segment contains a checksum field which is used to find corrupted
segments. If the segment is corrupted, then that segment is discarded by the
destination TCP and is considered lost.

• Acknowledgement – TCP has another mechanism called acknowledgement to affirm

that the data segments have been delivered. Control segments that contain no data
but have sequence numbers will be acknowledged as well but ACK segments are not
acknowledged.
Retransmission
• When a segment is missing, delayed to deliver to a receiver, corrupted when it
is checked by the receiver then that segment is retransmitted again.
• Segments are retransmitted only during two events: when the sender receives
three duplicate acknowledgements (ACK) or when a retransmission timer
expires.
Retransmission after RTO:
• TCP always preserves one retransmission time-out (RTO) timer for all sent but
not acknowledged segments.
• When the timer runs out of time, the earliest segment is retransmitted. Here
no timer is set for acknowledgement.
• In TCP, the RTO value is dynamic in nature and it is updated using the round
trip time (RTT) of segments.
• RTT is the time duration needed for a segment to reach the receiver and an
acknowledgement to be received by the sender.
Retransmission after Three duplicate ACK segments:
• RTO method works well when the value of RTO is small.
• If it is large, more time is needed to get confirmation about whether a segment has
been delivered or not.
• Sometimes one segment is lost and the receiver receives so many out-of-order
segments that they cannot be saved.
• In order to solve this situation, three duplicate acknowledgement method is used and
missing segment is retransmitted immediately instead of retransmitting already
delivered segment.
• This is a fast retransmission because it makes it possible to quickly retransmit lost
segments instead of waiting for timer to end.
TCP Flow
Control
 ( )
TCP Flow Control
 Creates a balance between rate of data production and the rate of data consumption
 Assumption: Channel between sender & receiver is error-free

Data Flow and Flow Control Feedbacks in TCP

Source: Behrouz A. Forouzan, “TCP IP Protocol Suite ” 4th edition, 2010, McGraw-Hill ISBN:
0073376043
 ( )
TCP Flow Control Contd…
1) Messages are pushed from the Sending application to TCP Client
2) Message segment from TCP Client is pushed to TCP Server
3) Messages are pulled by receiving application from TCP Server
4) Flow control feedback is sent from TCP server to TCP client
5) TCP client forwards the flow control feedback to sending application
 Opening and Closing Windows
 Buffer size of sender & receiver is fixed during connection establishment
 Window sizes of Sender / Receiver is controlled and adjusted by TCP Server
 Opening / Closing / Shrinking of client window is controlled by receiver
 ( )
TCP Flow Control Contd…
Scenario – TCP Flow Control
 Segment 1
 Connection request – (SYN) segment from client to server
 Initial Sequence Number (ISN): 100 (Next byte to Arrive : 101)
 Server allots buffer size = 800 (Assumption)
 Server allots Window size (rwnd) = 800
 Segment 2
 (ACK + SYN) segment from Server to Client
 Set ACK no = 101 & Buffer Size = 800 bytes
 Flow
Control – A
Scenario

Source: Behrouz A. Forouzan, “TCP IP Protocol Suite ” 4th edition, 2010, McGraw-Hill ISBN:
0073376043
 ( )
TCP Flow Control Contd…
Scenario – TCP Flow Control
 Segment 3
 ACK segment sent from client to server
 Segment 4
 Client sets window size to 800 (since rwnd from server is 800)
 Client process pushes 200 bytes of data to TCP client
 TCP client creates data segment with bytes (101-300) and sends to Server
 Client window adjusted
 Shows 200 bytes as sent but no ACK received from Server
 ( )
TCP Flow Control Contd…
Scenario – TCP Flow Control
 Shows 200 bytes as sent but no ACK received from Server
 Server stores 200 bytes in buffer & closes receive window
 Server indicates the next expected byte as 301
 Segment 5
 Server acknowledges receipt of 200 bytes from client & reduces rwnd to 600
 Client receives acknowledgement and resizes window size to 600
 Client closes the window (101-300) from left to right
 Client indicates the next byte to send as 301
 ( )
TCP Flow Control Contd…
Scenario – TCP Flow Control
 Segment 6
 Client pushes 300 more bytes to the server (Seq. No = 301 & Data = 300 bytes)
 Server stores 300 bytes in buffer
 100 bytes of data are pulled by the Client process
 So, Window size is reduced by 100 bytes to the left & opened by 100 bytes to the
right
 Overall, TCP client window size is reduced by 200 bytes
 Now, Receiver window size (rwnd) = 400
 ( )
TCP Flow Control Contd…
Scenario – TCP Flow Control
 Segment 7
 TCP Server acknowledges receipt of 300 bytes and sets window size (rwnd) =
400 & TCP Client reduces window size to 400
 Sender windows closes by 300 bytes from the left and opens by 100 bytes to the
right
 This process continues until all the data segments are sent from server to client and
connection gets closed
 ( )
TCP Flow Control Contd…
 Shrinking of Windows
 Shrinking : Decreasing window size i.e., right wall moves towards the left
 Sender window may shrink based on rwnd value defined by receiver
 Receiver window cannot shrink
 Illustration
 Upto 205 bytes of data received and acknowledged by sender
 Last advertised rwnd = 12 (Window size) & last advertised ACK No = 206
 Data can be sent from byte 206 to byte 217 (Since rwnd = 12)
 New advertised rwnd = 12 (Window size) & new advertised ACK No = 210
 The window after the new advertisement; Window has shrunk

Source: Behrouz A. Forouzan, “TCP IP Protocol Suite ” 4th edition, 2010, McGraw-Hill ISBN:
0073376043
 ( )
TCP Flow Control Contd…
 Shrinking of Windows Contd…
 Shrinking of window has occurred from byte 217 to byte 213 (Window had
moved from right to left
 Shrinking can be prevented by the relation given below:

New ACK number + new rwnd > = Lask ACK Number + Last rwnd

 To prevent shrinking,
 Wait until enough buffer locations are available in its window
 ( )
TCP Flow Control Contd…
 Silly Window Syndrome
 Occurs when either the sending process creates data slowly (or) the receiving
process consumes data slowly (or) both
 Silly window syndrome sends / receives data in small segments thus resulting in
poor efficiency
 Example
 A 42 byte TCP datagram is needed to send Segment with 2 bytes of data
 Overhead : 42 / 2 Network capacity used inefficiently
 ( )
TCP Flow Control Contd…
 Silly Window Syndrome Created by Sender
 Sending TCP creates syndrome since sending application program creates data
slowly i.e., 1 byte at an instance
 Suggestions
 Prevent sending TCP from transmitting data byte by byte
 Sending TCP made to wait & collect data to send data in larger block
 Disadvantage: Waiting too long delays the process
 Solution
 Nagle’s Algorithm
 ( )
TCP Flow Control Contd…
 Nagle’s Algorithm for Silly Window Syndrome Created by Sender
i. First segment of data sent by sending TCP irrespective of the size of segment
ii. Data is accumulated in buffer by sending TCP until acknowledgment is received
from receiving TCP (or) enough data accumulated to send a segment
iii. Repeat step 2 until transmission completes
 Nagle’s algorithm works based on speed of application program and the network
speed
 Faster the application program larger the segment size
 Advantage: Simple to implement
 ( )
TCP Flow Control Contd…
 Silly Window Syndrome Created by Receiver
 Syndrome created when serving application consumes slowly
 Example
 1 KB data blocks created by sending application
 1 byte of consumed at a time by receiving application
 Once sending window buffer is full, window size (rwnd) becomes 0
 Solution 1: Clarks’s Solution
 Send ACK as data segment arrives
 Set rwnd = 0 iff receive buffer is half empty (or) accommodate max size
of segment
 ( )
TCP Flow Control Contd…
 Silly Window Syndrome Created by Receiver Contd…
 Solution 2: Delayed Acknowledgment
 Acknowledgement is withheld when segment arrives
 Receiver waits for space in incoming buffer before acknowledging
 Delayed ACK prevents sending TCP from sliding
 Delayed ACK reduces network traffic
 Note: ACK not to be delayed by more than 500 ms
TCP Error
Control
 ( )
TCP Error Control
 TCP – Reliable Transport layer Protocol
 Entire data stream to be delivered without error / loss / duplication
 Reliability is provided by TCP using Error Control
 Error Control includes:
 Finding and resending corrupted segments
 Resending lost segments
 Storing out-of-order segments till missed segments arrive
 Discarding duplicate segments
 Error control achieved by: Checksum, Acknowledgement and Time-out
 ( )
TCP Error Control Contd…
a) Checksum
 TCP uses 16-bit mandatory checksum field
 Checksum field associated with each segment
 Checks for corrupted segment
 Invalid Checksum: Segment discarded by receiving TCP & considered lost
 ( )
TCP Error Control Contd…
b) Acknowledgement
 Acknowledgement segments (ACK) carry no data & confirms data segment receipt
 Types : Cumulative and Selective Acknowledgment
 Cumulative Acknowledgment (ACK)
 32-bit ACK field used
 Acknowledges segments cumulatively (sets ACK flag to 1)
 No feedback provided for discarded, lost or duplicate segments
 Selective Acknowledgement (SACK)
 Reports out of order & duplicate segments
 ( )
TCP Error Control Contd…
b) Acknowledgement Contd…
 No provision for SACK in TCP header
 SACK included as part of options field in the TCP header
 Rules for Generating Acknowledgments
1) When data is sent from sender to receiver, ACK provides the next Seq. No
expected to be received
 This results in less traffic and less segments between sender and receiver
2) In case of one in-order segment remaining, receiver needs to delay sending ACK
segment. Network traffic is thus reduced.
 ( )
TCP Error Control Contd…
b) Acknowledgement Contd…
3) At no point of time there should be more than two in-order segments
unacknowledged. (avoid unnecessary retransmission)
4) Receiver acknowledges (ACK) an higher out-of-order sequence number
immediately leading to fast retransmission of next segment
5) Receiver sends ACK when a missing segment arrives. Segments reported as
missing are thus informed to the receiver
6) Receiver discards duplicate segment & sends ACK indicating the next in-order
segment. Lost ACK segment problems are thus solved.
 ( )
TCP Error Control Contd…
c) Retransmission of Segments
 When retransmission occurs?
 Expiry of retransmission timer (or)
 Sender receives more than 2 duplicate ACK’s for 1st segment
 Retransmission after RTO
 One retransmission time-out (RTO) maintained by sending TCP for each
connection
 In case of time-out, timer is restarted by TCP & first segment of Queue is sent
 This version of TCP is called Tahoe
 ( )
TCP Error Control Contd…
c) Retransmission of Segments Contd…
 Retransmission after 3 Duplicate Segments
 Also called as Fast Retransmission & followed by most implementations
 TCP version called as Reno
 If 3 identical duplicate ACK’s along with the original ACK are received for a
segment, the next segment is retransmitted
 Note: Retransmission does not wait for time-out in this case
 ( )
TCP Error Control Contd…
d) Out-of-Order Segments
 Out-of-Order segments are not discarded by TCP
 TCP flags such segments as out-of-order and store them temporarily until missing
segments arrive
 TCP makes sure that data segments are delivered in sequence to the process
 ( )
TCP Error Control Contd…
e) FSM for Data Transfer in TCP
 FSM – Finite State Machine
 Similar to Selective repeat and Go Back-N protocol
 Sender-side & Receiver Side FSM
 Assumption : Unidirectional communication
 Ignored Parameters: Selective ACK and Congestion Control
 Nagle’s algorithm / Windows shutdown not included in FSM
 Advantage: Fast transmission policy using 3 duplicate ACK segments
 Bi-directional FSM : Complex and more practical
 Simplified
FSM for TCP
Sender Side

Source: Behrouz A. Forouzan, “TCP IP Protocol Suite ” 4th edition, 2010, McGraw-Hill ISBN:
0073376043
 Simplified
FSM for TCP
Receiver
Side

Source: Behrouz A. Forouzan, “TCP IP Protocol Suite ” 4th edition, 2010, McGraw-Hill ISBN:
0073376043
TCP Congestion
Control
 ( )
TCP Congestion Control
 Congestion window and congestion policy handles TCP congestion
a) Congestion Window
 Client window size (rwnd) decided by the available buffer space of Server
 Ignored entity in deciding window size : Network Congestion
 Sender window size determined by,
 rwnd (receiver advertised window size) &
 cwnd (Congestion window size)

Actual window size = min (rwnd, cwnd)

 ( )
TCP Congestion Control
Contd… TERMINOLOGIES & ABBREVIATIONS USED
 rwnd – Sender Window Size
 cwnd – Congestion Window Size
 ssthresh – Slow Start Threshold
 MSS – Maximum Segment Size
 ACK – Acknowledgement
 RTT – Round Trip Time
 RTO – Retransmission Time-out
 ( )
TCP Congestion Control
b) Congestion Policy
Contd…
 Three phases : Slow Start, Congestion avoidance & Congestion detection
i. Slow Start (Exponential Increase)
 Assumption: rwnd(Sender Window Size) > cwnd(Congestion Window Size)
 cwnd initialized to one Maximum window size (MSS)
 On arrival of each ACK, cwnd increases by 1
 Algorithm starts slowly & grows exponentially
 Delayed ACK policy is ignored
 Note: Consider each segment is individually acknowledged
Slow Start,
Exponential
Increase

Source: Behrouz A. Forouzan, “TCP IP Protocol Suite ” 4th edition, 2010, McGraw-Hill ISBN:
0073376043
 ( )
TCP Congestion Control
b) Congestion Policy
Contd…
i. Slow Start (Exponential Increase) contd…
 Initial value of cwnd = 1 MSS
No of MSS sent No of Segments RTT cwnd in MSS
Acknowledged
Nil Nil - 1
1 1 1 1x2=2 21
2 2 2 2x2=4 22
4 4 3 4x2=8 23
8 8 4 8 x 2 = 16 24
 ( )
TCP Congestion Control
b) Congestion Policy
Contd…
i. Slow Start (Exponential Increase) contd…
 For Delayed Acknowledgements
 If multiple segments are acknowledged accumulatively, cwnd increases by 1
 Example: if ACK = 4 then cwnd = 5
 Growth is exponential but not to the power of 2
 Slow start stops with a threshold value ssthresh
 It stops when window size = = ssthresh
 ( )
TCP Congestion Control
b) Congestion Policy
Contd…
ii. Congestion Avoidance : Additive Increase
 Slow start increases congestion window size (cwnd) exponentially
 Congestion avoidance increases cwnd additively
 Additive phase begins when slow start reaches ssthresh i.e. cwnd = I
 Increase in cwnd is based on RTT & not on number of ACK’s

RTT cwnd in MSS

1 i
2 i+1
Congestive
avoidance,
Additive
Increase

Source: Behrouz A. Forouzan, “TCP IP Protocol Suite ” 4th edition, 2010, McGraw-Hill ISBN:
0073376043
 ( )
TCP Congestion Control
b) Congestion Policy
Contd…
iii. Congestion Detection : Multiplicative Decrease
 Size of Cwnd must be decreased in case of congestion
 Retransmission occurs during missing segments / lost segments
 Retransmission helps identify whether congestion has occurred or not
 Retransmission occurs when
 There is RTO Time-out
 On receipt of three duplicate ACK’s
 Note: In both cases, ssthresh is reduced by half (Multiplicative decrease)
 ( )
TCP Congestion Control
b) Congestion Policy
Contd…
iii. Congestion Detection : Multiplicative Decrease Contd…
a) Time-out increases possibility of congestion. TCP reacts as follows:
 Ssthresh set to half the value of rwnd
 Cwnd initialized to 1
 Slow start phase is initiated again
b) Three duplicate ACK’s indicates a weaker possibility of Congestion. Also called as
fast transmission & fast recovery. TCP reacts as follows:
 Ssthresh set to half the value of rwnd
 ( )
TCP Congestion Control
b) Congestion Policy
Contd…
iii. Congestion Detection : Multiplicative Decrease Contd…
 Cwnd = ssthresh
 Congestion avoidance phase is initiated again
 TCP
Congestion
Policy : A
Summary

Source: Behrouz A. Forouzan, “TCP IP Protocol Suite ” 4th edition, 2010, McGraw-Hill ISBN:
0073376043
 ( )
TCP Congestion Control
Contd… Summarization with Example
 Assumptions
 Maximum window Size (MSS) = 32
 Threshold (ssthresh) = 16
 TCP moves to slow start
 rwnd starts from 1 and and grows exponentially till it reaches ssthresh (16)
 Additive increase increases rwnd from 16 to 20 (one by one)
 When rwnd = 20, time-out occurs
 Multiplicative Decrease: ssthresh reduced to 10 (half the window size)
Congestion
Example

Source: Behrouz A. Forouzan, “TCP IP Protocol Suite ” 4th edition, 2010, McGraw-Hill ISBN:
0073376043
 ( )
TCP Congestion Control
Contd… Summarization with Example Contd…
 New ssthresh = 10
 TCP moves to Slow start again
 rwnd starts from 1 and and grows exponentially till it reaches new ssthresh (10)
 Additive increase increases rwnd from 10 to 12 (one by one)
 2 duplicate ACK’s are received by the sender
 Multiplicative Decrease: ssthresh reduced to 6 (half the window size)
 Multicasting and
Multicast Routing Protocols
Objectives
Upon completion you will be able to:
• Differentiate between a unicast, multicast, and broadcast message
• Know the many applications of multicasting
• Understand multicast link state routing and MOSPF
• Understand multicast link state routing and DVMRP
• Understand the Core-Based Tree Protocol
• Understand the Protocol Independent Multicast Protocols
• Understand the MBONE concept
219
UNICAST, MULTICAST,
AND BROADCAST
A message can be unicast, multicast, or broadcast. Let us clarify these
terms as they relate to the Internet.

The topics discussed in this section include:

Unicasting
Multicasting
Broadcasting
Multicasting versus Multiple Unicasting

220
Unicasting

221
 Note:

In unicasting, the router forwards the

received packet through only
one of its interfaces.

222
Multicasting

223
 Note:

In multicasting, the router may

forward the received packet
through several of its interfaces.

224
Multicasting versus multiple unicasting

225
 Note:

Emulation of multicasting through

multiple unicasting is not efficient and
may create long delays, particularly
with a large group.

226
MULTICAST APPLICATIONS
Multicasting has many applications today such as access to distributed
databases, information dissemination, teleconferencing, and distance
learning.

The topics discussed in this section include:

Access to Distributed Databases
Information Dissemination
Dissemination of News
Teleconferencing
Distance Learning

227
MULTICAST ROUTING
In this section, we first discuss the idea of optimal routing, common in all
multicast protocols. We then give an overview of multicast routing
protocols.

The topics discussed in this section include:

Optimal Routing: Shortest Path Trees

Routing Protocols

TCP/IP Protocol Suite 228

 Note:

In unicast routing, each router in the

domain has a table that defines a
shortest path tree to possible
destinations.

229
Shortest path tree in unicast routing

230
 Note:

In multicast routing, each involved

router needs to construct a shortest
path tree for each group.

231
 Note:

In the source-based tree approach,

each router needs to have one shortest
path tree for each group.

232
Source-based tree approach

233
Group-shared tree approach

234
 Note:

In the group-shared tree approach,

only the core router, which has a
shortest path tree for each group, is
involved in multicasting.

TCP/IP Protocol Suite 235

Taxonomy of common multicast protocols

236
MULTICAST LINK STATE
ROUTING: MOSPF
In this section, we briefly discuss multicast link state routing and its
implementation in the Internet, MOSPF.

The topics discussed in this section include:

Multicast Link State Routing

MOSPF

237
 Note:

Multicast link state routing uses the

source-based tree approach.

238
MULTICAST DISTANCE
VECTOR: DVMRP
In this section, we briefly discuss multicast distance vector routing and its
implementation in the Internet, DVMRP.

The topics discussed in this section include:

Multicast Distance Vector Routing

DVMRP

239
 Note:

Flooding broadcasts packets, but

creates loops in the systems.

240
 Note:

RPF eliminates the loop in the

flooding process.

241
 RPF

TCP/IP Protocol Suite 242

Problem with RPF

243
 RPF versus RPB

TCP/IP Protocol Suite 244

 Note:

RPB creates a shortest path broadcast

tree from the source to each destination.
It guarantees that each destination
receives one and only one
copy of the packet.

245
RPF, RPB, and RPM

246
 Note:

RPM adds pruning and grafting to

RPB to create a multicast shortest path
tree that supports dynamic
membership changes.

247
CBT
The Core-Based Tree (CBT) protocol is a group-shared protocol that uses
a core as the root of the tree. The autonomous system is divided into
regions and a core (center router or rendezvous router) is chosen for each
region.

The topics discussed in this section include:

Formation of the Tree

Sending Multicast Packets
Selecting the Rendezvous Router

248
Group-shared tree with rendezvous router

249
Sending a multicast packet to the rendezvous router

250
 Note:

In CBT, the source sends the multicast

packet (encapsulated in a unicast packet)
to the core router.

The core router decapsulates the packet

and forwards it to all interested
interfaces.

251
PIM
Protocol Independent Multicast (PIM) is the name given to two
independent multicast routing protocols: Protocol Independent Multicast,
Dense Mode (PIM-DM) and Protocol Independent Multicast, Sparse Mode
(PIM-SM).

The topics discussed in this section include:

PIM-DM
PIM-SM

252
 Note:

PIM-DM is used in a dense multicast

environment, such as a LAN.

253
 Note:

PIM-DM uses RPF and

pruning/grafting strategies to handle
multicasting.

However, it is independent from the

underlying unicast protocol.

254
 Note:

PIM-SM is used in a sparse multicast

environment such as a WAN.

255
 Note:

PIM-SM is similar to CBT but uses a

simpler procedure.

256
MBONE
A multicast router may not find another multicast router in the
neighborhood to forward the multicast packet. A solution for this problem
is tunneling. We make a multicast backbone (MBONE) out of these isolated
routers using the concept of tunneling.

257
Logical tunneling

258
MBONE

259