Notes On Chapter Twenty-Two
-- Datagram Forwarding
22.1 Introduction
Internet communication service
Packet format
Encapsulation
Forwarding
Fragmentation and Reassembly
22.2 Connectionless Service
Fundamentally Internet service is connectionless and packet-based.
However, the Internet supports reliable connection-based service,
which is implemented using underlying connectionless service.
22.3 Virtual Packets
There is an Internet packet format that is hardware-independent.
22.4 The IP Datagram
Refer to figure 22.1 on page 364.
Formally, an IP packet is called an IP datagram.
An IP datagram consists of a header followed by a data area.
The data area is often referred to as the payload.
The payload can be as small as one octet (an octet is 8 bits).
The combined size of the header and payload is allowed to be as large
as 64K octets (but no larger).
22.5 The IP Datagram Header Format
Refer to figure 22.2 on page 366.
There is a variable-sized header containing:
Source IP address
Destination IP address
Other stuff
There is a variable sized data area too -- important
flexibility for the wide range of uses of IP.
22.6 Forwarding an IP Datagram
Refer to figure 22.3 on page 367.
If an IP datagram is not addressed to a local destination, it is
forwarded from router to router until it reaches a router connected
to the destination network. That router forwards the packet to its
final destination.
The Internet uses next-hop forwarding.
Routers decide on the next hop based on the network prefix of the
destination address.
22.7 Network Prefix Extraction and Datagram Forwarding
Refer to figure 22.3 on page 367.
Conceptually, each entry in a forwarding table contains three fields:
a Destination IP network address, a Mask that encodes the
prefix/suffix boundary of the Destination network address, and the IP
address of a next hop to send packets addressed to that Destination
network.
To forward a packet with destination address D, the router examines
table entries until finding one such that:
Mask[i] & D == Destination[i]
When such match is found the router decides to forward the packet to
NextHop[i].
22.8 Longest Prefix Match
The matching method favors longer matching prefixes.
22.9 Destination Address and Next-Hop Address
The destination address in the IP datagram is always the IP address
of the final destination
In particular, the IP addresses of intermediate routers are NOT
entered into the IP datagram header (or payload).
22.10 Best-Effort Delivery
IP standards specify that IP makes a "best-effort" to deliver each
datagram.
However it does not guarantee that it will handle all problems.
The standard acknowledges the possibility of:
Datagram duplication
Delayed or out-of-order delivery
Corruption of data
Datagram loss
22.11 Encapsulation
Refer to figure 22.4 on page 371.
When it's time to forward an IP datagram across a physical network,
the datagram is placed inside one of the frames used on the physical
network.
In other words, when in transit IP datagrams travel INSIDE physical
frames - as their data portions (their payloads).
The header of a physical frame typically has a type field. The
sender uses that type field to indicate that the payload of the
physical frame is an IP datagram. This helps the receiver know to
which protocol software the payload of the physical frame should be
forwarded.
The MAC destination address of the physical frame is the MAC address
of the next hop. For example, when one router sends an IP datagram
to a next-hop router, it puts the MAC address of the next-hop router
into the physical frame that encapsulates the IP datagram.
22.12 Transmission Across an Internet
Refer to figure 22.5 on page 372.
Each time that a datagram is sent across a physical network, the
receiver on the other side, removes it from the encapsulating frame
and discards the frame.
22.13 MTU and Datagram Fragmentation
Refer to figure 22.6 on page 373.
Refer to figure 22.7 on page 374.
Each physical network technology has a Maximum Transmission
Unit (MTU).
If an IP router needs to forward a datagram over a network but it is
too large for the MTU, then the router can fragment the
datagram.
Each fragment is a smaller IP datagram that contains a contiguous
section of the payload of the original datagram.
The router encapsulates and transmits each fragment separately.
The headers of the fragments are almost the same as the header of the
original datagram. However a bit is set to indicate the datagram is
a fragment, and there is a FRAGMENT OFFSET field to specify where the
fragment fits in to the whole.
22.14 Reassembly of a Datagram from Fragments
Refer to figure 22.8 on page 375.
The final fragment has a bit set in its header that helps the
computer that reassembles a datagram know when it has all the
fragments.
The final destination host is responsible for reassembly.
One advantage of that is that it allows busy routers to simplify
their work. They don't have to be aware of which datagrams are
fragments, and they don't have to do the reassembly work.
Another advantage is that if routes change and not all fragments are
forwarded to the same next-hop, it doesn't cause a problem with
reassembly.
22.15 Collecting the Fragments of a Datagram
The computer that reassembles a datagram that has been fragmented has
to determine:
Which fragments belong to which original IP datagrams?
Once we have all the fragments belonging to one particular
datagram, how do we figure out in what order they go back
together?
The computer figures out the answer to the first question by looking
at the combination of source IP address and unique datagram
identification number.
The answer to the second question is settled by examining the FRAGMENT
OFFSET fields in the fragments.
22.16 The Consequence of Fragment Loss
A receiver sets a time when it first gets one of the fragment of an
IP datagram. If it does not receive all the fragments before the
time expires, it discards all the fragments of that datagram.
There is no mechanism for the receiver to request that a fragment be
resent. Such a mechanism wouldn't make sense.
22.17 Fragmenting a Fragment
The way fragmentation works, fragments can be fragmented.
Fragments of fragments are just ordinary fragments.
It's simpler that way -- when reassembling, it's not necessary to
worry about rebuilding fragments from sub-fragments.