When we sent packets from one router to another router on the network layer and the packet size is greater than the MTU (maximum transferable unit) of the router, we have to fragment the packet. My questions is: suppose we need to add padding bits in last fragment, then where do we add padding bits (in the LSB or MSB) and how does the destination router differentiate between packet bits or padding bits?
I want you to consider the following things before:
Limit on the maximum size of IP data-gram is imposed by data link protocol.
IP is the highest layer protocol that is implemented both at routers and hosts.
Reassembly of original data-grams is only done at destination host. This takes off the extra work that need to be done by the routers present in the network core.
I will use the information from the following image to help you get to the answer with an example.
Here initial length of the packet is 2400 bytes which needs to to fragmented according to MTU limit of 1000 bytes.
There are only 13 bits available for the fragment offset and the offset is given as a multiple of eight bytes. This is why the data fields in first and second fragment has size of 976 bytes (It is the highest number divisible by 8, which is smaller than 1000 - 20 bytes). This makes first and second fragment of total size of 996 bytes. The last fragment contains the remaining of 428 bytes of payload (with 448 bytes of total).
Offset can be calculated as 0; 976/8 = 122 and 1952/8 = 244.
When these fragments reach the destination host, reassembly needs to be done. Host uses identification, flag and fragmentation offset for this task. In order to make sure which fragments belong to which data-gram, host uses source, destination addresses and identification to uniquely identify them. Offset values and more fragment bits are used to determine whether all fragments have arrived or not.
Answer to your question
The need to divide payload into multiples of 8 is only required for non-last fragment. Reason of using offset dividing by 8 helps the host to identify the starting address of the next fragment. The host don't need the address of the next fragment if it encounters the last fragment. Thus, no need to worry about payload being multiple of 8 in case of last fragment. Host checks the more fragment flag to identify the last fragment.
A bit of additional information: It is not the responsibility of the network layer to guarantee the delivery of the data-gram. If it encounters that one or more fragment(s) have not arrived then, it simply discards the whole data-gram. Transport layer, which is working above network layer, will take care of this thing, if it is using TCP, by asking the source to re-transmit the data.
Reference: Computer Networking-A Top Down Approach, James F. Kurose, Keith W. Ross (Fifth Edition)
You don't need to add any padding bits. All bits will be push on down the route until the full frame has been sent.
Related
I am currently going through my networking slides and was wondering if someone could help me with the concept of fragmentation
so i understand the first part till "108 Bytes" but what I don't understand is this "8 Bytes = 13.5 => 13 * 8
Bytes = 104 Bytes"
what are these extra bytes ?
the rest is clear.
You must fragment the packet payload on eight-byte boundaries. With a 128-byte MTU, the largest payload fragment you can have is 104 bytes, which is smaller than simply subtracting the IP header from the MTU (108 bytes). What the text is telling you that subtracting the packet header size (20 bytes) from the MTU, the next smaller fragment size divisible by eight is 104 bytes.
RFC 791, Internet Protocol has a complete description of how IP fragmentation works:
Fragmentation
Fragmentation of an internet datagram is necessary when it originates
in a local net that allows a large packet size and must traverse a
local net that limits packets to a smaller size to reach its
destination.
An internet datagram can be marked "don't fragment." Any internet
datagram so marked is not to be internet fragmented under any
circumstances. If internet datagram marked don't fragment cannot be
delivered to its destination without fragmenting it, it is to be
discarded instead.
Fragmentation, transmission and reassembly across a local network
which is invisible to the internet protocol module is called intranet
fragmentation and may be used [6].
The internet fragmentation and reassembly procedure needs to be able
to break a datagram into an almost arbitrary number of pieces that can
be later reassembled. The receiver of the fragments uses the
identification field to ensure that fragments of different datagrams
are not mixed. 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 identification field is used to distinguish the fragments of one
datagram from those of another. The originating protocol module of an
internet datagram sets the identification field to a value that must
be unique for that source-destination pair and protocol for the time
the datagram will be active in the internet system. The originating
protocol module of a complete datagram sets the more-fragments flag to
zero and the fragment offset to zero.
To fragment a long internet datagram, an internet protocol module (for
example, in a gateway), creates two new internet datagrams and copies
the contents of the internet header fields from the long datagram into
both new internet headers. The data of the long datagram is divided
into two portions on a 8 octet (64 bit) boundary (the second portion
might not be an integral multiple of 8 octets, but the first must be).
Call the number of 8 octet blocks in the first portion NFB (for Number
of Fragment Blocks). The first portion of the data is placed in the
first new internet datagram, and the total length field is set to the
length of the first datagram. The more-fragments flag is set to one.
The second portion of the data is placed in the second new internet
datagram, and the total length field is set to the length of the
second datagram. The more-fragments flag carries the same value as
the long datagram. The fragment offset field of the second new
internet datagram is set to the value of that field in the long
datagram plus NFB.
This procedure can be generalized for an n-way split, rather than the
two-way split described.
To assemble the fragments of an internet datagram, an internet
protocol module (for example at a destination host) combines internet
datagrams that all have the same value for the four fields:
identification, source, destination, and protocol. The combination is
done by placing the data portion of each fragment in the relative
position indicated by the fragment offset in that fragment's internet
header. The first fragment will have the fragment offset zero, and
the last fragment will have the more-fragments flag reset to zero.
Per the definition of the Fragment offset field in the IP header:
Fragment offset(13 bits): In case of fragmented IP datagrams, this field contains the offset( in terms of 8 bytes units) from the start of IP datagram. So again, this field is used in reassembly of fragmented IP datagrams.
So even though payload sizes can be whatever, offset values can only be multiple of 8 bytes on IP headers thus payload sizes are 8-byte multiples. The calculation rounds down the IP payload size.
The TCPv4 specification (RFC 793) classifies a received segment as unacceptable if it has zero length, a sequence number equal to RCV.NXT+RCV.WND while the receive window is not zero (second row in the table).
This essentially means that the segment will be discarded, other than possibly sending an ACK. No ACK processing or send window update will be done.
What is the justification of this?
Consider this scenario:
Host A sends all possible data segments to host B, just exhausting the receive window of B.
Host A shortly also sends an empty segment, e.g. a window update or acknowledgement of received data. This segment has sequence number equal to the right edge of the receive window of host B (RCV.NXT+RCV.WND), since it was set to the latest SND.NXT of host A.
The mentioned data packets are lost in the network or delayed, and host B receives the empty segment first.
Host B will classify the empty segment as not acceptable, and drop it, ignoring any acknowledgement or window update.
Is there some part that I am not understanding correctly? Is this scenario really possible?
note: I ask here instead of on networkengineering.stackexchange.com since I encountered the issue while implementing a TCP/IP stack and these protocol details seem closer to programming than what is commonly understood as network engineering.
An IP packet with no options, broken into 3 fragments.
Fragment 1 - offset of 0
Fragment 2 - offset of 358
Fragment 3 - offset of 510 and a total length of 120
How can I calculate how long the original IP packet was?
I think you have some invalid numbers for fragment offsets since IP must be fragmented on 64-bit boundaries.
When in doubt, refer to the RFC (RFC 791, INTERNET PROTOCOL):
Fragmentation
Fragmentation of an internet datagram is necessary when it
originates in a local net that allows a large packet size and must
traverse a local net that limits packets to a smaller size to reach
its destination.
An internet datagram can be marked "don't fragment." Any internet
datagram so marked is not to be internet fragmented under any
circumstances. If internet datagram marked don't fragment cannot be
delivered to its destination without fragmenting it, it is to be
discarded instead.
Fragmentation, transmission and reassembly across a local network
which is invisible to the internet protocol module is called
intranet fragmentation and may be used [6].
The internet fragmentation and reassembly procedure needs to be able
to break a datagram into an almost arbitrary number of pieces that
can be later reassembled. The receiver of the fragments uses the
identification field to ensure that fragments of different datagrams
are not mixed. 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 identification field is used to distinguish the fragments of one
datagram from those of another. The originating protocol module of
an internet datagram sets the identification field to a value that
must be unique for that source-destination pair and protocol for the
time the datagram will be active in the internet system. The
originating protocol module of a complete datagram sets the
more-fragments flag to zero and the fragment offset to zero.
To fragment a long internet datagram, an internet protocol module
(for example, in a gateway), creates two new internet datagrams and
copies the contents of the internet header fields from the long
datagram into both new internet headers. The data of the long
datagram is divided into two portions on a 8 octet (64 bit) boundary
(the second portion might not be an integral multiple of 8 octets,
but the first must be). Call the number of 8 octet blocks in the
first portion NFB (for Number of Fragment Blocks). The first
portion of the data is placed in the first new internet datagram,
and the total length field is set to the length of the first
datagram. The more-fragments flag is set to one. The second
portion of the data is placed in the second new internet datagram,
and the total length field is set to the length of the second
datagram. The more-fragments flag carries the same value as the
long datagram. The fragment offset field of the second new internet
datagram is set to the value of that field in the long datagram plus
NFB.
This procedure can be generalized for an n-way split, rather than
the two-way split described.
To assemble the fragments of an internet datagram, an internet
protocol module (for example at a destination host) combines
internet datagrams that all have the same value for the four fields:
identification, source, destination, and protocol. The combination
is done by placing the data portion of each fragment in the relative
position indicated by the fragment offset in that fragment's
internet header. The first fragment will have the fragment offset
zero, and the last fragment will have the more-fragments flag reset
to zero.
I am working on a project in which i have to send data in bits.
Is it possible to send 1 bit from one computer to another through internet.Most of the people
said to me that minimum internet packet size is 64bytes.If i send 1bit from one computer to another then packet bandwidth is 64bytes.
A TCP or UDP packet consists of a header and data. Maybe you could have one bit of data in the data section, but you would need the header as well. Without the header it would be impossible to send the packet. The header contains all the information required for sending the packet where it is supposed to go and making sure it arrives safely.
I will take "internet packet" to mean Ethernet frame based on the value you give.
An Ethernet frame has a minimum total size of 64 bytes including both header and payload, this is to ensure that the time to transmit a single frame is greater than the round trip time between nodes.
This requirement is a feature of any network that uses CSMA/CD (specifically the CD (collision detection) part), it allows a sensing node to detect a collision whilst still transmitting a frame.
Whilst Ethernet can be used to send a frame smaller than 64 bytes "padding" will be added to ensure the frame is at least 64 bytes.
Suppose I have two hosts, host A and host B, and host A sends a 1500 byte packet to B and there are two routers between them with a MTU of 800 bytes for the first link, and MTU of 500 bytes for the second link between them.
As I understand it the packet will have to be fragmented both times. The packet will have to be fragmented into 3 packets (2 equally sized packets and one smaller one).
Then when we hit this second router we will have each of the first two fragmented packets be fragmented once more. The first two original fragments will produce 1 larger fragment (close to 500 bytes), and one smaller one.
This is where I am confused.
I know that the 'More Fragment' bit should be set to 1 on all of the first 3 fragments except the last indicating that the packets are part of a fragment up to and including the next packet with 'More Fragment' set to 0. However, for the second set of fragments I am not so sure. If this was the first time the packet had been fragmented, the last fragment would have 'More Fragment' of 0, but since this is actually just a fragment somewhere in the middle of the original message, I have a feeling it should be 1.
I am hoping someone with more experience can shed some light on this for me. Is the 'More Fragment' bit used in reassembly? If so I would imagine that when the fragments are fragmented then we do not set the last fragment to 0.
So the algorithm would go:
If fragmenting a packet with 'More Fragment' set to 0,
then set 'More Fragment' to 1 in all fragmented packets except the last.
Else If fragmenting a packet with 'More Fragment' set to 1,
then set 'More Fragment' to 1 in all of the fragmented packets.
Is my assumption here correct?
You are more or less right. Routers besides adding MF (more fragments) flag are doing some more processing:
To fragment/segment a long internet packet, a router (R1 in the figure
below) creates a new IP packet and copies the contents of the IP
header fields from the long packet into the new IP header. The data of
the long packet is then divided into two portions on a 8 byte (64 bit)
boundary, so that the first packet is less than the MTU of the
out-going interface. The more-fragments flag (MF) in the first packet
is set to one (to indicate that more fragments of this packet follow).
The More Flag may already be set in this packet if it has already been
fragmented by another system. This packet is forwarded.
The second created new packet is then processed. The packet header
field is identical to that of the original packet (including the same
value of the packet ID, the total length field, the more-fragments
flag (MF) and the fragment offset field in the original packet). The
packet header field is updated with a new offset field, by adding the
number of payload bytes sent in the first fragment. If this new packet
is larger than the allowed link MTU, the packet is again fragmented.
So in nutshell for already fragmented packets whole IP header is being copied to new packets (smaller fragments of fragment). It means that if IP packet has MF set it will be also copied to last fragmented packet. Thanks to changing offset and packets ID host receiving fragmented packets will be able to reassemble those.