Ch22 Datagram Forwarding
Download
Report
Transcript Ch22 Datagram Forwarding
Department of Engineering Science
ES465/CES 440, Intro. to Networking & Network Management
Datagram Forwarding
http://www.sonoma.edu/users/k/kujoory
References
• “Computer Networks & Internet,” Douglas Comer, 6th ed, Pearson, 2014, Ch 22,
Textbook, 5th ed, slides by Lami Kaya ([email protected]) with some changes.
• “Computer Networks,” A. Tanenbaum, 5th ed., Prentice Hall, 2011, ISBN:
13:978013212695-3.
• “Computer & Communication Networks,” Nader F. Mir, 2nd ed, Prentice Hall, 2015, ISBN:
13: 9780133814743.
• “Data Communications Networking,” Behrouz A. Forouzan, 4th ed, Mc-Graw Hill, 2007
• “Data & Computer Communications,” W. Stallings, 7th ed., Prentice Hall, 2004.
• “Computer Networks: A Systems Approach," L. Peterson, B. Davie, 4th Ed., Morgan
Kaufmann 2007.
Ali Kujoory
5/31/2016
Not to be reproduced without permission
1
Topics Covered
•
•
•
•
•
•
•
•
•
•
•
22.1 Introduction
22.2 Connectionless Service
22.3 Virtual Packets
22.4 The IP Datagram
22.5 The IPv4 Datagram
Header Format
22.6 The IPv6 Datagram
Header Format
22.7 IPv6 Header Base Format
22.8 Forwarding an IP
Datagram
22.9 Network Prefix Extraction
& Datagram Forwarding
22.10 Longest Prefix Match
22.11 Destination Address &
Next-Hop Address
Ali Kujoory
5/31/2016
• 22.12 Best-Effort Delivery
• 22.13 IP Encapsulation
• 22.14 Transmission Across an
Internet
• 22.15 MTU & Datagram
Fragmentation
• 22.16 Fragmentation of an
IPV6 Datagram
• 22.17 Reassembly of an IP
Datagram from Fragments
• 22.18 Collecting the Fragments
of a Datagram
• 22.19 The Consequence of
Fragment Loss
• 22.20 Fragmenting an IPv4
Fragment
• 22.21 Summary
Not to be reproduced without permission
2
22.1 Introduction
• This chapter
– discusses the fundamental communication service in
the Internet
– describes the format of packets that are sent across the
Internet
– discusses the key concepts of datagram encapsulation,
forwarding, & fragmentation & reassembly
Ali Kujoory
5/31/2016
Not to be reproduced without permission
3
22.2 Connectionless Service
• Application programs mainly remain unaware of the underlying
physical networks
– they can send/receive data without knowing the details of
• the LAN to which a computer connects
• the remote network to which the destination connects
• What are services that will be offered by a network?
– connection-oriented service
– connectionless service, or
– a combination of both
• TCP/IP include protocols for both
– An unreliable & low delay connectionless delivery service
– A reliable connection-oriented service that
• uses the underlying connectionless network service
• The design forms the basis for all Internet communication
Ali Kujoory
5/31/2016
Not to be reproduced without permission
4
22.3 Virtual Packets
• In connectionless each packet travels independently
– It contains information that identifies the intended recipient
• How does a packet pass across the Internet?
– A host
• creates a packet
• places the destination address in the packet header &
• then sends the packet to a nearby router
– A router
• receives a packet
• uses the destination address to select the next router on the path &
• then forwards the packet
– Eventually, the packet reaches a router that can deliver the packet
to its final destination
Ali Kujoory
5/31/2016
Not to be reproduced without permission
5
22.3 Virtual Packets
• What format is used for an Internet packet?
– Internet consists of heterogeneous networks that
• use incompatible frame formats
• it cannot adopt a hardware frame format since they vary
• A router cannot simply reformat the frame header
– because the two networks may use incompatible addressing
• To overcome network heterogeneity
– IP defines a packet format that is independent of the hardware
– The result is a universal, virtual packet
• that can be transferred across the underlying hardware intact
– As the term virtual implies
• The Internet packet format is not tied directly to any hardware
• The underlying hardware does not understand or recognize an Internet packet
– As the term universal implies
• Each host or router in the Internet contains protocol software that recognizes
Internet packets
Ali Kujoory
5/31/2016
Not to be reproduced without permission
6
22.4 The IP Datagram
• TCP/IP uses the name IP datagram to refer to a packet
• Fig. 22.1 illustrates an IP datagram format
– Each datagram consists of a header followed by data area
(payload)
• The amount of data carried in a datagram is not fixed
• The size of a datagram is determined by the application that sends data
• A datagram can contain as little as a single octet of data or at most
64K octets
Ali Kujoory
5/31/2016
Not to be reproduced without permission
7
22.5 The IPv4 Datagram Header Format
• What does a datagram header contain?
– It contains information used to forward the datagram
• A datagram header contains information, such as:
– the address of the source (the original sender)
– the address of the destination (the ultimate recipient) &
– a field that specifies the type of data being carried in the payload
• Each address in the header is an IP address
– MAC addresses for the sender & recipient do not appear
• Each field in an IP datagram header has a fixed size
– which makes header processing efficient
• Fig. 22.2 shows the fields of an IP datagram header
Ali Kujoory
5/31/2016
Not to be reproduced without permission
8
22.5 The IPv4 Datagram Header Format
• IP datagram is specified by IETF RFC 791
Also see https://en.wikipedia.org/wiki/IPv4
Ali Kujoory
5/31/2016
Not to be reproduced without permission
9
22.5 The IPv4 Datagram Header Format
• VERS
– Each datagram begins with a 4-bit protocol version #
(the figure shows a version 4 header)
• H.LEN
– 4-bit header specifies the # of 32-bit (4-byte) quantities in the header
– If no options are present, the value is 5
• SERVICE TYPE
– 8-bit field that carries a Class Of Service for the datagram
(seldom used in practice)
– Chapter 28 explains the DiffServ interpretation of the service type field
• TOTAL LENGTH
– 16-bit integer that specifies the total # of bytes in the datagram
(including header & data)
– Min = 20 bytes header + 0 data byte, max = 65536 bytes
Ali Kujoory
5/31/2016
Not to be reproduced without permission
10
22.5 The IPv4 Datagram Header Format
• IDENTIFICATION
– 16-bit # (usually sequential) assigned to the datagram
• used to gather all fragments for reassembly to the datagram
• FLAGS
– 3-bit field with individual bits specifying whether the datagram is a
fragment
– Bit 0: Reserved (=0); bit 1: Don’t fragment (=1), bit 2: More
fragments (=1)
• FRAGMENT OFFSET
– 13-bit field that specifies where in the original datagram the data in
this fragment belongs
– the value of the field is in 8-byte blocks (multiply offset by 8)
– the first fragment has an offset of zero
Ali Kujoory
5/31/2016
Not to be reproduced without permission
11
22.5 The IPv4 Datagram Header Format
• TIME TO LIVE (TTL, usually = hop count)
– 8-bit integer initialized by the original sender
– it is decremented by each router that processes the datagram
– if the value reaches zero (0)
• the datagram is discarded & an error message is sent back to the source
– This field limits a datagram's lifetime
• TYPE (Protocol #, e.g., ICMP=1, TCP=6, UDP=17, ..), RFC 1700
– 8-bit field that specifies the type of the payload
• HEADER CHECKSUM (RFC 1071)
Errors in data is handled by TCP/UDP
– 16-bit ones-complement checksum of header fields
– it is computed according to Algorithm 8.1
• SOURCE IP ADDRESS
– 32-bit Internet address of the original sender
– (the addresses of intermediate routers do not appear in the header)
Ali Kujoory
5/31/2016
Not to be reproduced without permission
12
22.5 The IPv4 Datagram Header Format
• DESTINATION IP ADDRESS
– 32-bit Internet address of the ultimate destination
– Addresses of intermediate routers do not appear in the header
• IP OPTIONS
– Optional header fields used to control routing & datagram
processing, e.g.,
• Strict source routing, partial source routing, route recording,
– Most datagrams do not contain any options
• which means the IP OPTIONS field is omitted from the header
• PADDING
– If options do not end on a 32-bit boundary
• zero bits of padding are added to make the header a multiple of 32 bits
Ali Kujoory
5/31/2016
Not to be reproduced without permission
13
22.6 The IPv6 Datagram Header Format
• IPv6 designed to support high quality real-time traffic (audio, video)
• IPv6 header starts with a base header, followed by
– Zero or more extension headers, followed by
– Data
• Header makes Internet Protocol more flexible
Figure 22.3 The General form of IPv6 datagram (fields not to scale)
Ali Kujoory
5/31/2016
Not to be reproduced without permission
14
22.7 IPv6 Base Header Format
IPv6 Base Header is much richer & contains less # of fields, Fig. 22.4
Figure 22.4 The format of the base header in an IPv6 datagram
Ali Kujoory
5/31/2016
Not to be reproduced without permission
15
22.7 IPv6 Base Header Format
• Base Header contains the following fields, in addition to source
/destination addresses
• VERS (Version 6)
• TRAFFIC CLASS
– specifies the traffic class using a definition of traffic types
– known as differentiated services to specify general characteristics that
the datagram needs, e.g.,
• to send interactive traffic such as keystrokes/mouse with low latency
– To send real-time audio across the Internet
• a sender might request a path with low jitter
• PAYLOAD LENGTH
– corresponds to IPv4's datagram length field
– specifies only the size of the data being carried (i.e., the payload)
• size of the header is excluded
• HOP LIMIT
– corresponds to the IPv4 TIME-TO-LIVE field
Ali Kujoory
5/31/2016
Not to be reproduced without permission
16
22.7 IPv6 Base Header Format
• FLOW LABEL
– intended to associate a datagram with a particular path
• NEXT HEADER, Figure 22.5
– Used to specify type of information that follows the current header
– If the datagram includes an extension header
• NEXT HEADER field specifies the type of the extension header
– If no extension header exists
• NEXT HEADER field specifies the type of data being carried in the
payload
TCP
Payload
Figure 22.5 The NEXT HEADER field in (a) an IPv6 datagram that has a base header
& TCP payload & (b) a datagram with a base header, route header & TCP payload.
Ali Kujoory
5/31/2016
Not to be reproduced without permission
17
22.8 Forwarding an IP Datagram
• The Internet uses next-hop forwarding
• Each router along the path
– receives the datagram
– extracts the destination address from the header
– uses the destination address to determine a next hop
• to which the datagram should be sent
– then forwards the datagram to the next hop
• either the final destination or another router
• To make the selection of a next hop efficient, an IP
router uses a forwarding table
• A forwarding table is initialized when the router boots, &
– must be updated if the topology changes or hardware fails
Ali Kujoory
5/31/2016
Not to be reproduced without permission
18
22.8 Forwarding an IP Datagram
• Forwarding table contains a set of entries
– each specifies a destination & the next hop used to reach that
destination
• Fig. 22.6 shows a simple example internet & the contents
of a forwarding table in one of the three routers
– each router has been assigned two IP addresses
Net-IDs
• one for each interface
– Router R2, which is connected 40.0.0.0/8 & 128.1.0.0/16
• has been assigned addresses 40.0.0.8 & 128.1.0.8
– IP does not require the suffix to be the same on all interfaces
• But a network administrator can chose the same suffix for each
interface to make it easier for humans who manage the network
• Each destination in the table corresponds to a network
– the # of entries in a forwarding table is proportional to the # of
networks in the Internet
Ali Kujoory
5/31/2016
Not to be reproduced without permission
19
22.8 Forwarding an IP Datagram
Figure 22.6 (a) An example IPv4 internet with four networks &
(b) the forwarding table found in router R2.
Ali Kujoory
5/31/2016
Not to be reproduced without permission
20
22.9 Network Prefix Extraction & Datagram Forwarding
• The process of using a forwarding table to select a next
hop for a given datagram is called forwarding
• The mask field in a forwarding table entry is used to
extract the network portion of an address during lookup
• When a router encounters a datagram with destination IP
address D
– the forwarding function must find an entry in the forwarding table
that specifies a next hop for D
– The software examines each entry in the table by using the mask
in the entry to extract a prefix (Net_ID) of address D
– It compares the resulting prefix to the Destination field of the
entry
• If the two are equal, the datagram will be forwarded to the Next Hop
Ali Kujoory
5/31/2016
Not to be reproduced without permission
21
22.9 Network Prefix Extraction & Datagram Forwarding
• The bit mask representation makes extraction efficient
– the computation consists of a Boolean AND between the mask &
destination address, D
– the computation to examine the ith entry in the table can be as:
if ( (Mask[i] AND D) == Destination[i] ) forward to NextHop[i]
• As an example
– Consider a datagram destined for address 192.4.10.3
– Assume the datagram arrives at the center router, R2 (Fig. 22.6)
– Assume the forwarding searches entries of the table in order
• The first entry fails since 255.0.0.0 AND 192.4.10.3 ≠ 30.0.0.0
• After rejecting the second & third entries in the table
• The routing software eventually chooses next hop 128.1.0.9 because
255.255.255.0 AND 192.4.10.3 == 192.4.10.0
What makes the forwarding table?
Ali Kujoory
5/31/2016
Not to be reproduced without permission
22
22.10 Longest Prefix Match
• Fig. 22.6 contains a trivial example
– In practice, Internet forwarding tables can be extremely large &
• the forwarding algorithm is complex
• Internet forwarding tables can contain a default entry
– that provides a path for all destinations that are not explicitly listed
• A network manager can specify a host-specific route
– it directs traffic destined to a specific host along a different path
than traffic for other hosts on the same network
• An important feature of an Internet forwarding table is
that address masks can overlap
Ali Kujoory
5/31/2016
Not to be reproduced without permission
23
22.10 Longest Prefix Match
• Suppose a router's forwarding table contains entries for the following
two network prefixes:
128.10.0.0/16 & 128.10.2.0/24
• What happens if a datagram arrives destined to 128.10.2.3?
• Matching procedure succeeds for both of the entries
– a Boolean & of a 16-bit mask will produce 128.10.0.0
– a Boolean & with a 24-bit mask will produce 128.10.2.0
• Which entry should be used?
– To handle ambiguity that arises from overlapping address masks,
Internet forwarding uses a longest prefix match
• Instead of examining the entries in arbitrary order
• forwarding software arranges to examine entries with the longest prefix first
• Here, Internet forwarding will choose the entry that corresponds to
128.10.2.0/24
Ali Kujoory
5/31/2016
Not to be reproduced without permission
24
22.11 Destination Address & Next-Hop Address
• What is the relationship between the
– destination address in a datagram header & the
– address of the next hop to which the datagram is forwarded?
• The DESTINATION IP ADDRESS field in a datagram
contains the address of the ultimate destination
– it does not change as the datagram passes through the Internet
• When a router receives a datagram
– the router uses the ultimate destination, D to compute the address
of the next router to be sent, N
• The router forwards a datagram to the next hop, N
– the header in the datagram retains destination address D
Ali Kujoory
5/31/2016
Not to be reproduced without permission
25
22.12 Best-Effort Delivery
• Term best-effort describes the service of IP protocol
• IP makes a best-effort to deliver each datagram
– IP does not guarantee that it will handle all problems
• The following problems can occur in IP protocol
– Datagram duplication
– Delayed or out-of-order delivery
– Corruption of data
– Datagram loss
• IP is designed to run over any type of network
– network equipment can experience interference from noise
• Packets following one path may take longer than those
following another path
– this can result in out-of-order delivery
Ali Kujoory
5/31/2016
Not to be reproduced without permission
26
22.13 IP Encapsulation
• How can a datagram be transmitted across a physical network that
does not understand the datagram format?
– The answer lies in a technique known as encapsulation
• When an IP datagram is encapsulated in a frame
– the entire datagram is placed in the payload area of a frame
• The network hardware treats a frame that contains a datagram
exactly like any other frame
– hardware does not examine or change the contents of the payload
• Fig. 22.7 illustrates the concept
Figure 22.7 Illustration of an IP datagram encapsulated in a frame.
Ali Kujoory
5/31/2016
Not to be reproduced without permission
27
22.13 IP Encapsulation
• How does a receiver know whether the payload of an
incoming frame contains an IP datagram or other data?
– Sender/receiver must agree on the value used in the frame type
field
– Software on the sending computer assigns the frame type field
• When a frame arrives with the IP value in its type field
– the receiver knows that the payload area contains an IP datagram
• E.g., the Ethernet specifies that the type field of a frame carrying an IP
datagram is assigned 0x0800
• Encapsulation requires the sender to supply the MAC
address of the next computer
– to which the datagram should be sent
Ali Kujoory
5/31/2016
Not to be reproduced without permission
28
22.14 Transmission Across an Internet
• After the sender selects a next hop
– the sender encapsulates the datagram in a frame &
– transmits the result across the physical network
• When the frame reaches the next hop
– the receiving software examines the IP datagram
• If the datagram must be forwarded across another
network
– a new frame is created
• Fig. 22.8 illustrates how a datagram is encapsulated &
unencapsulated as it travels along a path
• Each network can use a different hardware technology
than the others
– meaning that the frame formats & frame header sizes can differ
Ali Kujoory
5/31/2016
Not to be reproduced without permission
29
22.14 Transmission Across an Internet
Figure 15.1, Comer ed 5 Ethernet Frame
Header.
Figure 22.8 An IP datagram as it travels across the Internet.
Ali Kujoory
5/31/2016
Not to be reproduced without permission
30
22.14 Transmission Across an Internet
• Frame headers do not accumulate during a trip through
the Internet
• When a datagram arrives
– the datagram is removed from the incoming frame before being
encapsulated in an outgoing frame
• When the datagram reaches its final destination
– the frame header will be the header of the last network over which
the datagram arrived
– once the header is removed, the result is the original datagram
Ali Kujoory
5/31/2016
Not to be reproduced without permission
31
22.15 MTU & Datagram Fragmentation
• Each hardware technology specifies the maximum
amount of data that a frame can carry
– The limit is known as a Maximum Transmission Unit (MTU)
• There is no exception to the MTU limit
– Network hardware is not designed to accept or transfer frames that
carry more data than the MTU allows
– A datagram must be smaller or equal to the network MTU, OR
• it cannot be encapsulated for transmission
• In an internet that contains heterogeneous networks,
MTU restrictions create a problem
• A router can connect networks with different MTU values
– a datagram that a router receives over one network can be too
large to send over another network
Ali Kujoory
5/31/2016
Not to be reproduced without permission
32
22.15 MTU & Datagram Fragmentation
• Fig. 22.9 illustrates a router that interconnects two
networks with MTU values of 1500 & 1000
– Host H1 attaches to a network with an MTU of 1500 &
• can send a datagram that is up to 1500 octets
– Host H2 attaches to a network that has an MTU of 1000
• which means it cannot send/receive a datagram larger than 1000 octets
– If host H1 sends a 1500-octet datagram to host H2
• router R will not be able to encapsulate it for transmission across
network 2
Figure 22.9 Illustration of a router that connects two networks with
different MTUs.
Ali Kujoory
5/31/2016
Not to be reproduced without permission
33
22.15 MTU & Datagram Fragmentation
• To solve the problem of
heterogeneous MTUs
• A fragment has the same
format as other datagrams
– a router uses a technique
known as fragmentation
– a bit in the FLAGS field of the
header indicates whether a
datagram is a fragment or a
complete datagram
• When a datagram is larger
than the MTU of the
network over which it must
be sent
– the router divides the
datagram into smaller pieces
called fragments &
– sends each fragment
independently
Ali Kujoory
5/31/2016
• Other fields in the header
are assigned information
for the ultimate destination
to reassemble fragments
– to reproduce the original
datagram
• The FRAGMENT
OFFSET specifies where
in the original datagram
the fragment belongs
Not to be reproduced without permission
34
22.15 MTU & Datagram Fragmentation
• A router uses the network MTU & the header size to
calculate the
– max amount of data that can be sent in each fragment & the
– # of fragments that will be needed
• The router then creates the fragments
– It uses fields from the original header to create a fragment header
• E.g., the router copies the IP SOURCE & IP DESTINATION fields from
the datagram into the fragment header
– It copies the appropriate data from the original datagram into the
fragment, then
– it transmits the result
• Fig. 22.10 & 22.11 illustrate the division of a datagram
into fragments in IPv4 & IPv6
Ali Kujoory
5/31/2016
Not to be reproduced without permission
35
22.15 MTU & Datagram Fragmentation
Ali Kujoory
5/31/2016
Not to be reproduced without permission
36
22.16 Fragmentation of an IPV6 Datagram
• In IPv6, fragment info is placed in a separate extension header.
• Fragmentation is performed by the sending host & not by routers.
– If fragmentation is required, sending host receives an ICMP error
message, & reduces the fragment size until fragments can be sent to the
destination
Figure 22.11 Illustration of IPv6 fragmentation with a datagram.
(a) divided into fragments (b) through (d).
Ali Kujoory
5/31/2016
Not to be reproduced without permission
37
22.17 Reassembly of an IP Datagram from Fragments
• Recreating a copy of the original datagram from
fragments is called reassembly
• Each fragment begins with a copy of the original
datagram header
– all fragments have the same destination address as the original
datagram from which they were derived
• The fragment that carries the final piece of data has an
additional bit set in the header
– Thus, a host performing reassembly can tell whether all fragments
have arrived successfully
• The ultimate destination should reassemble fragments
Ali Kujoory
5/31/2016
Not to be reproduced without permission
38
22.17 Reassembly of an IP Datagram from Fragments
• Consider the configuration in Fig. 22.12
– if host H1 sends a 1500-octet datagram to host H2, router R1 will
divide the datagram into two fragments, which it will forward to R2
– Router R2 does not reassemble the fragments
• Instead R2 uses the destination address in a fragment to forward the
fragment as usual
– The ultimate destination host, H2, collects the fragments &
reassembles them to produce the original datagram
Does a routers along the way reassemble?
Why yes / no?
Figure 22.12 Illustration of the three networks connected by two routers.
Ali Kujoory
5/31/2016
Not to be reproduced without permission
39
22.17 Reassembly of an IP Datagram from Fragments
• Requiring the ultimate destination to reassemble
fragments has two advantages:
• 1st, it reduces the amount of state information in routers
– When forwarding a datagram, a router does not need to know
whether the datagram is a fragment
• 2nd, it allows routes to change dynamically
– If an intermediate router were to reassemble fragments, all
fragments would need to reach the router
• By postponing reassembly until the ultimate destination
– IP is free to pass some fragments from a datagram along different
routes than other fragments, i.e.,
– the Internet can change routes at any time, e.g.,
• to route around a hardware failure
Ali Kujoory
5/31/2016
Not to be reproduced without permission
40
22.18 Collecting the Fragments of a Datagram
• Datagram fragments can arrive out-of-order or get lost
• How does the receiving host reassemble fragments that
arrive out-of-order?
• A sender places a unique identification # in the
IDENTIFICATION field of each outgoing datagram
• When a router fragments a datagram
– the router copies the identification # into each fragment
• A receiver uses the identification # & IP source
address in an incoming fragment
– to determine the datagram to which the fragment belongs
• The FRAGMENT OFFSET field tells a receiver where
data in the fragment belongs in the original datagram
Ali Kujoory
5/31/2016
Not to be reproduced without permission
41
22.19 The Consequence of Fragment Loss
• A datagram cannot be
reassembled until all fragments
arrive
• A problem arises when one or
more fragments from a
datagram arrive & other
fragments are delayed or lost
• The receiver must save (buffer)
the fragments that
– have arrived in case missing
fragments are only delayed
• A receiver cannot hold
fragments an arbitrarily long
time
• IP specifies a maximum time
to hold fragments
• When the first fragment arrives
from a given datagram
– the receiver starts a reassembly
timer
• If all fragments of a datagram
arrive before the timer expires
– the receiver cancels the timer &
reassembles the datagram
• If the timer expires before all
fragments arrive
– the receiver discards the
fragments that have arrived
– because fragments occupy
space in memory
Ali Kujoory
5/31/2016
Not to be reproduced without permission
42
22.19 The Consequence of Fragment Loss
• The result of IP's reassembly timer is all-or-nothing:
– Either all fragments arrive & IP reassembles the datagram, or
– IP discards the incomplete datagram
• There is no mechanism for a receiver to tell the sender
which fragments have arrived &
– the sender does not know about fragmentation
• If a sender retransmits, the datagram routes may be
different
– a retransmission would not necessarily traverse the same routers
• also, there is no guarantee that a retransmitted datagram would be
fragmented in the same way as the original
Ali Kujoory
5/31/2016
Not to be reproduced without permission
43
22.20 Fragmenting an IPv4 Fragment
• What happens if a fragment eventually reaches a
network that has a smaller MTU?
• It is possible to fragment a fragment when needed
– A router along the path divides the fragment into smaller fragments
• If networks are arranged in a sequence of decreasing
MTUs
– each router along the path must further fragment each fragment
• Designers work carefully to insure that such situations do
not occur in the Internet
Ali Kujoory
5/31/2016
Not to be reproduced without permission
44
22.20 Fragmenting an IPv4 Fragment
• In any case, IP does not distinguish between original
fragments & subfragments
• A receiver cannot know if an incoming fragment is the
result of one router fragmenting a datagram or multiple
routers fragmenting fragments
• Making all fragments the same has an advantage
– a receiver can perform reassembly of the original datagram
• without first reassembling subfragments
• this saves CPU time, & reduces the amount of information needed in
the header of each fragment
Ali Kujoory
5/31/2016
Not to be reproduced without permission
45