|
|
3.3.2 Reassembly
Connected: An Internet Encyclopedia
3.3.2 Reassembly
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1122
Up:
3. INTERNET LAYER PROTOCOLS
Up:
3.3 SPECIFIC ISSUES
Prev: 3.3.1.6 Initialization
Next: 3.3.3 Fragmentation
3.3.2 Reassembly
3.3.2 Reassembly
The IP layer MUST implement reassembly of IP datagrams.
We designate the largest datagram size that can be reassembled
by EMTU_R ("Effective MTU to receive"); this is sometimes
called the "reassembly buffer size". EMTU_R MUST be greater
than or equal to 576, SHOULD be either configurable or
indefinite, and SHOULD be greater than or equal to the MTU of
the connected network(s).
- DISCUSSION:
-
A fixed EMTU_R limit should not be built into the code
because some application layer protocols require EMTU_R
values larger than 576.
- IMPLEMENTATION:
-
An implementation may use a contiguous reassembly buffer
for each datagram, or it may use a more complex data
structure that places no definite limit on the reassembled
datagram size; in the latter case, EMTU_R is said to be
"indefinite".
Logically, reassembly is performed by simply copying each
fragment into the packet buffer at the proper offset.
Note that fragments may overlap if successive
retransmissions use different packetizing but the same
reassembly Id.
The tricky part of reassembly is the bookkeeping to
determine when all bytes of the datagram have been
reassembled. We recommend Clark's algorithm [IP:10] that
requires no additional data space for the bookkeeping.
However, note that, contrary to [IP:10], the first
fragment header needs to be saved for inclusion in a
possible ICMP Time Exceeded (Reassembly Timeout) message.
There MUST be a mechanism by which the transport layer can
learn MMS_R, the maximum message size that can be received and
reassembled in an IP datagram (see GET_MAXSIZES calls in
Section 3.4). If EMTU_R is not indefinite, then the value of
MMS_R is given by:
MMS_R = EMTU_R - 20
since 20 is the minimum size of an IP header.
There MUST be a reassembly timeout. The reassembly timeout
value SHOULD be a fixed value, not set from the remaining TTL.
It is recommended that the value lie between 60 seconds and 120
seconds. If this timeout expires, the partially-reassembled
datagram MUST be discarded and an ICMP Time Exceeded message
sent to the source host (if fragment zero has been received).
- DISCUSSION:
-
The IP specification says that the reassembly timeout
should be the remaining TTL from the IP header, but this
does not work well because gateways generally treat TTL as
a simple hop count rather than an elapsed time. If the
reassembly timeout is too small, datagrams will be
discarded unnecessarily, and communication may fail. The
timeout needs to be at least as large as the typical
maximum delay across the Internet. A realistic minimum
reassembly timeout would be 60 seconds.
It has been suggested that a cache might be kept of
round-trip times measured by transport protocols for
various destinations, and that these values might be used
to dynamically determine a reasonable reassembly timeout
value. Further investigation of this approach is
required.
If the reassembly timeout is set too high, buffer
resources in the receiving host will be tied up too long,
and the MSL (Maximum Segment Lifetime) [TCP:1] will be
larger than necessary. The MSL controls the maximum rate
at which fragmented datagrams can be sent using distinct
values of the 16-bit Ident field; a larger MSL lowers the
maximum rate. The TCP specification [TCP:1] arbitrarily
assumes a value of 2 minutes for MSL. This sets an upper
limit on a reasonable reassembly timeout value.
Next: 3.3.3 Fragmentation
Connected: An Internet Encyclopedia
3.3.2 Reassembly
|
|
|
 |

|
 |
|
Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
| |
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
| |
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
| |
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
| |
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!
|
|
Service Details
|
|
 |
|