=================================
· Not all link-layer protocols
can carry network-layer packets of the same size. Some protocols can carry big
datagrams, whereas other protocols can carry only little packets.
· For example, Ethernet frames
can carry upto 1,500 bytes of data, whereas frames for some wide-area links can
carry no more than 576 bytes.
· The maximum amount of data that a link-layer frame can carry is
called the maximum transmission unit (MTU). Because each IP datagram is encapsulated
within the link-layer frame for transport from one router to the next router,
the MTU of the link-layer protocol places a hard limit on the length of an IP
datagram.
· Having a hard limit on the
size of an IP datagram is not much of a problem. What is a problem is that each
of the links along the router between sender and destination can use different
link-layer protocols, and each of these protocols can have different MTUs.
IP Datagram Fragmentation:
======================
To
understand the forwarding issue better, imagine that you are a router that
interconnects several links, each running different link-layer protocols with
different MTUs.
Suppose
you receive an IP datagram from one link. You check your forwarding table to
determine the outgoing link, and this outgoing link has an MTU that is smaller
than the length of the IP datagram. Time to panic – how are you going to squeeze
this oversized IP datagram into the payload field of the link-layer frame?
The
solution is to fragment the data in the IP datagram into two or more smaller IP
datagrams, encapsulate each of these smaller IP datagrams in a separate
link-layer frame; and send these frames over the outgoing link. Each of these
smaller datagrams is referred to as a fragment.
Fragments need to be reassembled before they reach the transport
layer at the destination.
Indeed,
both TCP and UDP are expecting to receive complete, unfragmented segments from
the network layer.
NOTE:
The
designers of IPv4 felt that reassembling datagram in the routers would
introduce significant complication into the protocol and put a damper on router
performance. (if you were a router, would you want to be reassembling fragments
on top of everything else you had to do?).
Sticking
to the principle of keeping the network core simple, the designers of IPv4
decided to put the job of datagram reassembly in the end system rather than in
network routers.
When
a destination host receives a series of datagrams from the same source, it
needs to determine whether any of these datagrams are fragments of some
original larger datagram.
If
some datagrams are fragments, it must further determine when it has received
the last fragment and how the fragments it has received should he pieced back
together to form the original datagram.
To
allow the destination host to perform these reassembly tasks, the designers of
IP (version 4) put identification flag, and fragmentation
offset fields in the IP datagram header.
When
a datagram is created, the sending host stamps the datagram with an
identification number as well as source and destination address. Typically, the
sending host increments the identification number for each datagram it sends.
When a router needs to fragment a datagram, each resulting datagram (that is,
fragment) is stamped with the source address, destination address, and
identification number of the original datagram.
When
the destination receives a series of datagrams from the same sending host, it
can examine the identification numbers of the datagrams to determine which of
the datagrams are actually fragments of the same larger datagram.
Because
IP is an unreliable service, one or more of the fragments may never arrive at
the destination. For this reason, in order for the destination host to be
absolutely sure it has received the last fragment of the original datagram, the
last fragment has a flag bit set to 0, whereas all the other fragments have
flag bit set to 1. Also, in order for the destination host to determine whether
a fragment is missing ( and also to be able to reassemble the fragments in
their proper order), the offset field is used to specify where the fragment
fits within the original IP datagram.
Fields Related to Fragmentation:
=========================
Identification:
The
identification is 16 bits and is a value assigned by the sender of an IP
datagram to aid in the reassembly of the fragments of a datagram.
Fragment offset:
The
fragment offset is 13 bits and indicates where a fragment belongs in the
original IP datagram. This value is a multiple of eight bytes.
DF, MF, other bit:
In
the flags field of the IP header, there are three bits for control flags. It is
important to note that the "don't fragment" (DF) bit plays a central
role, because it determines whether or not a packet is allowed to be
fragmented.
Bit 0 is reserved, and is
always set to 0.
Bit 1 is the DF bit (0 = "may
fragment," 1 = "do not fragment").
Bit 2 is the MF bit (0 = "last
fragment," 1 = "more fragments").
IP Datagram Fragmentation Example1:
==============================
The figure below shows an IP datagram fragmentation example.
The figure below shows an IP datagram fragmentation example.
A
datagram of 4,000 bytes (20 bytes of
IP header plus 3,980 bytes of IP payload) arrives at a router and must be
forwarded to a link with an MTU of 1,500
bytes.
This
implies that the 3,980 data bytes in
the original datagram must be allocated to three separate fragments (each of
which is also an IP datagram).
Suppose
that the original datagram is stamped with an identification number of 777.
The
characteristics of three fragments are shown in the table below.
The
values in the above table reflect the requirement that the amount of original
payload data in all but the last fragment be a multiple of 8 bytes, and that
the offset value be specified in units of 8-byte chunks.
At
the destination, the payload of the datagram is passed to the transport layer
only after the IP layer has fully reconstructed the IP datagram. If one or more
of the fragments does not arrive at the destination, the incomplete datagram is
discarded and not passed to the transport layer.
But,
we know that if TCP is being used at the transport layer, then TCP will recover
from this loss by having the source retransmit the data in the original
datagram.
Question Related to above
problem:
===========================
1. Why are we dividing 1480 by
8 to get the offset?
Ans:
The
offset is the address or the locator from where the data starts with reference
to the original data payload.
For
IP the data payload comprises all the data that’s after the IP header and
Options header. Thus, the system/router takes the payload and divides it into
smaller parts and keeps the track of the offset with reference to the original
packet so that reassembly can be done.
As
given in the RFC Page 12.
"The
fragment offset field tells the receiver the position of a fragment in the
original datagram. The fragment offset and length determine the portion of the
original datagram covered by this fragment. The more-fragments flag indicates
(by being reset) the last fragment. These fields provide sufficient information
to reassemble datagrams. "
The
fragment offset is measured in Units of 8 bytes each. It has 13 bit field in
the IP header. As said in the RFC page 17
"This
field indicates where in the datagram this fragment belongs.The fragment offset
is measured in units of 8 octets (64 bits). The first fragment has offset zero."
Thus,
in the question where did this 8 come from, its the standard that’s been
defined for IP protocol specification, where 8 octets are taken as one value.
This also helps us to transmit large packets via this.
Page
28 of the RFC writes: *Fragments are counted in units of 8 octets. The
fragmentation strategy is designed so than an unfragmented datagram has all
zero fragmentation information (MF = 0, fragment offset = 0). If an internet
datagram is fragmented, its data portion must be broken on 8 octet boundaries.
This format allows 2**13 = 8192 fragments of 8 octets each for a total of
65,536 octets. Note that this is consistent with the the datagram total length
field (of course, the header is counted in the total length and not in the
fragments).*
IP Datagram Fragmentation Example2:
==============================
==============================
· The first fragment has an
offset of 0, the length of this fragment is 1500; this includes 20 bytes for
the slightly modified original IP header.
· The second fragment has an
offset of 185 (185 x 8 = 1480), which means that the data portion of this
fragment starts 1480 bytes into the original IP datagram. The length of this
fragment is 1500; this includes the additional IP header created for this
fragment.
· The third fragment has an
offset of 370 (370 x 8 = 2960), which means that the data portion of this
fragment starts 2960 bytes into the original IP datagram. The length of this
fragment is 1500; this includes the additional IP header created for this
fragment.
· The fourth fragment has an
offset of 555 (555 x 8 = 4440), which means that the data portion of this fragment
starts 4440 bytes into the original IP datagram. The length of this fragment is
700 bytes; this includes the additional IP header created for this fragment.
· It is only when the last
fragment is received that the size of the original IP datagram can be
determined.
· The fragment offset in the
last fragment (555) gives a data offset of 4440 bytes into the original IP
datagram. If you then add the data bytes from the last fragment (680 = 700 -
20), that gives you 5120 bytes, which is the data portion of the original IP
datagram. Then, adding 20 bytes for an IP header equals the size of the
original IP datagram (4440 + 680 + 20 = 5140).
For
detailed explanation refer to the below link:
Watch
The below Videos, They have a good explanation.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.