Notes On Chapter Twenty -- IP Datagrams And Datagram Forwarding

• 20.1 Introduction
  
  
  • This chapter is about:
    • The format of IP packets, and
    • How routers use the information in IP packets.
      
      
• 20.2 Connectionless Service
  
  
  • Fundamentally the Internet offers connectionless service, but there is a virtual connection-based service that will be discussed more later on.
    
    
• 20.3 Virtual Packets
  
  
  • IP packets travel hop-at-a-time from router to router.
    
    
  • The IP packet (aka IP datagram) has to be uniform across the Internet, and independent of the various physical frame formats and addressing modes of the underlying physical networks.
    
    
• 20.4 The IP Datagram
  
  
  • The IP datagram is pictured on page 328 of the fourth edition.
    
    
  • There is a variable-sized header containing:
    • Source IP address
    • Destination IP address
    • Other stuff
    
    
  • There is a variable sized data area too -- important flexibility for the wide range of uses of IP.
    
    
  • The IPv4 standard allows an IP datagram to contain as little as one byte of data.
    
    
  • The standard allows the datagram to be as large as 64 Kbytes total, including header.
    
    
• 20.5 Forwarding An IP Datagram
  
  
  • Routers use routing tables.
    
    
  • Routing tables have to be initialized and updated.
    
    
  • Conceptually a router's routing table is just a mathematical mapping or function . To each non-local IP network address the table must assign an outgoing interface and next-hop router address.
    
    
  • The route has to include the interface and the address of the next router because there could be several routers (gateways) on the network attached to an interface.
    
    
• 20.6 IP Addresses And Routing Table Entries
  
  
  • An IP router R actually keeps a "mask" M with each IP destination network address Destination in its routing table.
    
    
  • When R gets a destination IP address D out of a packet, R computes the logical "and" of M with D If (M&D)==Destination, that means Destination is the network address corresponding to D. R routes the packet to network Destination.
    
    
• 20.7 The Mask Field And Datagram Forwarding
  
  
  • The routing software can search down the "rows" of the routing table in order, looking for a pair (Destination,M ) such that D&M==Destination. When it finds a match, other entries in that row tell the next-hop interface and IP address.
    
    
  • In practice hashing techniques are used to reduce the amount of search required. A router has to find the route for each address very quickly.
    
    
• 20.8 Destination and Next-Hop Addresses
  
  
  • The next-hop IP address is often some intermediate router, not the final destination.
    
    
  • It is important to understand that a router never alters the destination IP address field of the IP packet.
    
    
  • When a router sends a packet to its next-hop, the router does not put the IP address of the next hop in the IP packet.
    
    
  • Throughout its trip across the Internet, the IP packet carries the final destination address in its destination address field.
    
    
  • Every router that receives the packet extracts the final destination address D, and computes various D&M "ands" until it finds a match.
    
    
  • All Internet routers base their decisions on such a match.
    
    
  • Once the router has learned the correct interface and IP address for the next-hop of a route, it uses standard address resolution techniques to learn the physical address of the next-hop.
    
    
  • The router places the IP packet in a physical frame appropriate to the interface it will be traveling on, and sends that frame to the next-hop host or router.
    
    
• 20.9 Best-Effort Delivery
  
  
  • According to specifications, IP (Internet Protocol) offers only a "best effort" connectionless service.
    
    
  • IP does not guarantee against duplication of packets, delayed or out of order delivery, corruption of data, or datagram loss.
    
    
  • The shortcomings of IP can be "fixed" by protocols at higher levels. More will be said about this later.
    
    
• 20.10 The IP Datagram Header Format
  
  
  • Page 328 of the 4th edition contains a depiction of an IP datagram header.
    
    
  • The fields are:
    
    
    1. VERS: 4-bit protocol IP version number (4 or 6)
       
       
    2. H.LEN: 4-bit header length (tells how many 32-bit "cells" are in the header ... usually 5, but possibly 6 or more)
       
       
    3. SERVICE TYPE: 8-bit value that tells whether the sender prefers that the packet travel over a path with minimal delay or a path with maximal throughput.
       
       
    4. TOTAL LENGTH: 16-bit integer tells the total number of octets (bytes) in the datagram. (Note the largest 16-bit integer is 64K, so an IP packet cannot be longer than that.)
       
       
    5. IDENTIFICATION: A 16-bit counter used to number packets. This field is discussed in chapter 21.
       
       Information from RFC 791:
       
       "The originating protocol module of an internet datagram sets the identification field to a value that must be unique for that source-destination pair and protocol for the time the datagram will be active in the internet system. ...
       
       "It seems then that a sending protocol module needs to keep a table of Identifiers, one entry for each destination it has communicated with in the last maximum packet lifetime for the internet.
       
       However, since the Identifier field allows 65,536 different values, some host may be able to simply use unique identifiers independent of destination.
       
       It is appropriate for some higher level protocols to choose the identifier. ..."
       
       Note from JS: Judging from anecdotal evidence, it appears some systems merely use something very like a 'serial number' for the IDENTIFICATION field, just incrementing the field by 1 for each new datagram (or some other constant value), and allowing the number to wrap around once it has cycled through all the possible values.
       
       
    6. FLAGS: 3-bit field marks a packet as eligible for fragmentation or not. Also there is a bit to say whether or not this packet is a "last" fragment. This field is discussed in chapter 21.
       
       
    7. FRAGMENT OFFSET: 13-bit integer used to number fragments. This field is discussed in chapter 21.
       
       Information from RFC 791:
       
       "The Fragment Offset field identifies the fragment location, relative to the beginning of the original unfragmented datagram. Fragments are counted in units of 8 octets. ... If an internet datagram is fragmented, its data portion must be broken on 8 octet boundaries."
       
       
    8. TIME TO LIVE: This 8-bit field is initialized by the sender and decremented by each router. It's a device to prevent faulty routing from causing a packet to travel around in the network indefinitely. If the TTL reaches zero, the packet is dropped and the router sends an error message back to the sender.
       
       
    9. TYPE: 8-bit value denotes the higher-level protocol type the packet is used for -- for example ICMP, UDP, TCP.
       
       
    10. HEADER CHECKSUM: This is an ordinary 16-bit checksum.
        
        
    11. SOURCE IP ADDRESS: 32-bit IP address of sender
        
        
    12. DESTINATION IP ADDRESS: 32-bit IP address of recipient
        
        
    13. IP OPTIONS (MAY BE OMITTED): In most IP datagrams, the value of H.LEN is 5 and the IP OPTIONS field is not present. The IP OPTIONS one can choose have to do with network control, debugging and measurement, or whatever researchers decide to make up. Directives in the options fields can call for such things as source routing and recording of the route taken.
        
        
    14. PADDING: If options are included, sufficient padding is added to fill the header out to a whole number of 32-bit "cells".
        
        
• 20.11 Summary