Notes On Chapter Twenty-One -- IP Encapsulation, Fragmentation, And Reassembly

• 21.1 Introduction
  
  
  • This chapter explains how datagrams get across physical networks.
    
    
• 21.2 Datagram Transmission And Frames
  
  
  • Each time an IP datagram crosses a network it has to "go by the rules" of that network.
    
    
• 21.3 Encapsulation
  
  
  • Encapsulation is the the "trick" we use to shuttle IP packets across a physical network: the IP packet is just placed in the data portion of a physical network frame.
    
    
  • Of course the correct physical address of the next-hop host or router has to go into the proper field of the physical frame
    
    
  • Also the physical frame must contain a type field marking it as the carrier of IP traffic, so that the contents of the frame will be handed off to IP software running on the destination host.
    
    
• 21.4 Transmission Across An Internet
  
  
  • The physical frame is received at the link layer on the router. When it is passed to the network layer, the IP packet is removed and the containing frame is discarded.
    
    
  • To send the IP packet to the next hop the router places the packet in a new frame, appropriate to the network it will travel over next.
    
    
  • An IP datagram does not accumulate more and more "trip headers" as it moves across the Internet. As described above, the packet is returned to its original state on each transmitting router.
    
    
• 21.5 MTU, Datagram Size, And Encapsulation
  
  
  • Each network has a maximum transmission unit (MTU)
    
    
  • The MTU is the maximum size physical frame the network can accept for transit.
    
    
  • Problem: It can happen that an IP datagram arriving at a router cannot be forwarded intact to the next hop because the MTU of the next link is so small that the IP packet will not fit in the data section of a physical frame.
    
    
  • Solution: IP routers can break an IP datagram into a series of "fragment" datagrams, each of which carries a portion of the data from the original datagram.
    
    
  • The IP software on the router carefully constructs each fragment datagram so it fits within the data portion of a physical network frame.
    
    
  • A bit in the FLAGS field of the header marks an IP datagram as a fragment. Each fragment is assigned a different FRAGMENT OFFSET. This is all that is required to allow the receiver to reassemble the packet.
    
    
  • The header of each fragment is basically a copy of the header of the original IP datagram -- with the obvious changes made, such as TOTAL LENGTH, FLAGS, and FRAGMENT OFFSET fields.
    
    
• 21.6 Reassembly
  
  
  • You might think that the next hop-router would reassemble the fragmented packet -- not true.
    
    
  • Packet reassembly is the responsibility of the ultimate destination host.
    
    
  • When a router fragments a packet P, it may forward different fragments over different routes. There can be more than one next-hop router, and so the job of reassembly cannot be done on a next-hop router.
    
    
  • Also, routers are busy and should not have to be "bothered" with doing reassembly.
    
    
• 21.7 Identifying A Datagram
  
  
  • Fragments can be lost, delayed, or delivered out of order.
    
    
  • The receiver recognizes a fragment from one particular datagram by looking at the combination of sender IP address, and the IDENTIFICATION field of the datagram (fragment).
    
    
• 21.8 Fragment Loss
  
  
  • When the first fragment arrives, the receiver starts a timer. If the timer expires before all the fragments have arrived then the receiver rejects the entire packet.
    
    
  • Fragment delivery is "all or nothing at all."
    
    
  • It is not practical to request that a fragment be resent.
    
    
  • There is no guarantee that a packet will be fragmented again in the same way if the packet is resent.
    
    
• 21.9 Fragmenting A Fragment
  
  
  • A fragment can itself be fragmented if it runs into a network with an MTU so small that it cannot get through.
    
    
  • One thing that helps with this is that the FRAGMENT OFFSET denotes the offset of the fragment in the original packet. The FRAGMENT OFFSET is not a "serial number"
    
    
  • The upshot is that a fragment of a fragment is still just an ordinary fragment. At reassembly time there is no need to assemble "sub-fragments" into "fragments" - no special handling required for fragments of fragments.
    
    
• 21.10 Summary