Class 26: Fragmentation and Reassembly

Held Wednesday, April 5, 2000

Overview

Today we continue our examination of the Internet protocol by considering fragmentation, addresses, forwarding, and other topics.

Notes

• I encourage those of you who are second year students (Jared, Dan, Todd, Chris, Tony, Erin, Prashant, Joe, Ashfaqur, Joe, Josh) to consider declaraing a computer science major.
  • No matter what major you declare, you need to work out a four-year plan and write a short essay on your version of the liberal arts education.
  • When you write the essay, be sure to reflect on the college's statement about liberal arts education (found on pp. 31-33 of the catalog).
• Assignment 6 is now ready.

Contents

• Review
• Handling Different MTUs
  • Fragmentation and Reassembly

Summary

• IP fragmentation and reassembly

Review

• IP is an intenetworking protocol intended for transmitting information over heterogeneous networks.
• Most of the work for IP goes on in routers, although hosts must also understand (and follow) IP and other related protocols.
• IP provides a ``best effort'' datagram model: it tries to get data to the recipient, but doesn't guarantee that it will.
  • Acknowledgements and ordering are typically handled at the next level.
• IP is an adaptive protocol. Different packets from A to B may travel along different paths as routers learn about different networking issues, such as dead hosts.

Handling Different MTUs

• One of the issues that IP (and any internet protocol) must consider is limitations on packet size.
• Each network might have a different maximum transmission unit: the size of the payload that it can carry in a frame.
• Consider the following picture, in which each edge between routers is labeled with its MTU:

          1044      1044      1044
  A-----R1--------R2--------R3---------R4
        |         |         |          |
        |1044     |532      | 276      | 532
        |         |         |          |
        R5--------R6--------R7---------R8--------B
          532        276      1044        1044
  

• What can we do?
  • We can limit the size of our IP datagrams to the minimum MTU.
  • We can break up the datagrams when necessary.
• Why don't you want to use the minimum MTU?
  • Extra overhead for determining minimum MTU.
  • Waste capacity on bigger networks.
  • Increase overhead on bigger networks.
  • The path may change, and hence the minimum MTU may change.

Fragmentation and Reassembly

• The better solution is to break up the datagrams and then reassemble them when appropriate.
• Some considerations:
  • When is it appropriate to reassemble? Should we reassemble when we hit a larger MTU?
  • How do we handle repeated fragmentation (as for a packet that goes from R1 to R5 to R6 to R7)?
  • Can datagrams arrive out of order or follow different paths?
  • What do we do when fragments never arrive?
• If datagrams can follow different paths, they can arrive out of order.
• In fact, receivers can receive fragments from one message mixed with fragments for another message.
• If datagrams can follow different paths, we can't really reassemble along the way (after all, there's no guarantee that a larger section receives all the smaller fragments).
• In IP, each logical datagram has a unique identifier. The receiver uses the identifier to determine where each fragment it receives belongs.
• What information can we use for reassembly? It doesn't make sense to number the fragments when we segment the data, because those fragments may be refragmented.
• The IP solution: fragments contain an offset within the original datagram. The offset is a multiple of 8 bytes.
• How do we know when we have the whole original datagram, since the length must be the length of the fragment?
  • Each datagram has one flag (M) that is set when there is ``more to follow''.
• How do we reassemble?
  • Look at the address plus number: If it's the number of a fragment you're currently building, work there. If it's the number of a new fragment, start a new work area.
  • Copy the bits of the fragment into the appropriate work area.
  • If the packet does not have the M bit set, you've found the end of the datagram.
  • Once you've found the end and all the parts have been received, you can pass the datagram up to the next level.
  • If you don't receive all the parts within a reasonable amount of time, give up.
• Note that you can't really reassemble until also the fragments have arrived (or at least until the one at the end has arrived), since you don't know how much memory to reserve for the rebuilt packet.
• We'll look at an example using the diagram above.