Topics

Fragmentation and Reassembly

Different interfaces have different MTUs (Maximum Transmission Unit):
- 1006 bytes for SLIP
- 1500 bytes for Ethernet
- 4096 bytes for FDDI
- 65527 bytes for ATM AAL-5
minimum MTU for carrying IP: 576 bytes
if a host or a router must send an IP packet bigger than the MTU, the packet is fragmented and each fragment is sent separately
each fragment is a valid IP packet
fragments are reassembled only by the destination host, never by routers
in-class question: when would a host have to send a packet larger than the MTU?

packet ID is different for different packets, same for different fragments of same packet
fragment offset is 1/8 the position of the first byte in the fragment (e.g. if the position is 1200, the fragment offset is 150 = 1200/8)
more fragments (MF) is 0 if this is the last fragment, 1 otherwise
don't fragment (DF) is 0 if you may fragment this packet, 1 otherwise

packet of total length L, header length h, to be sent on interface with MTU M < L
if DF is set, discard the packet
select n lengths L₁ ... L_n such that:
- L - h = sum_{1 <= i <= n} (L_i - h)
- L_i <= M for 1 <= i <= n
- (L_i - h) mod 8 = 0 for 1 <= i < n
send each fragment as an IP packet. All header fields are the same as for the original, except:
- total length is L_i + h
- fragment offset is (sum_{1 <= j < i} (L_j - h)) / 8
- MF is 1 except for the very last fragment

packet length is unknown until we get a fragment with MF=0
fragments may be out of order
packets may be as small as one byte
do not use dynamically-allocated memory
packet ID, protocol number, and source and destination address must match for all the fragments of one packet
must keep time-to-live timer for each packet, discard a packet if TTL expires and the packet is incomplete

RFC 815, http://www.ietf.org/rfc/rfc815.txt
single, maximum size buffer needed per packet (no dynamic memory allocation needed)
information about missing fragments (linked list of ``holes'') kept in the buffer itself
A "hole" is a part of the complete packet that we haven't received yet
Logically, before receiving the first fragment we have a single hole, from 0 to oo (16-bit numbers)
may have to delete holes or split one hole to create two new ones
packet payloads are placed into the buffer according to their fragment offset
when the last hole is deleted, the packet is reassembled

a hole describes byte positions first and last (inclusive), and the same for a fragment
when receiving a packet frag, loop over each hole hole:
1. if frag.first > hole.last, ignore this hole
2. if frag.last < hole.first, ignore this hole
3. delete hole
4. if frag.first > hole.first, create a new hole descriptor with newhole.first = hole.first and newhole.last = frag.first - 1
5. if frag.last < hole.last and frag.MF = 1, create a/another new hole descriptor with newhole.first = frag.last + 1 and newhole.last = hole.last

I have the following holes (given as offset of first byte, offset of last byte): (0, 79), (120, 143), (160, oo)
insert fragment 104, 111, MF=1 into this list
insert fragment 160, 162, MF=0 into this list
insert fragment 0, 79, MF=1 into this list
insert fragment 80, 119, MF=1 into this list