The IP packet format again:
| 4-bit   | 4-bit header |8-bit "type | 16-bit total length (in bytes)  |
| version | length       |of service" |                                |
| 16-bit identification               | 3-bit | 13-bit fragment offset  |
|                                     | flag  |                         |
| 8-bit "time to live"   | 8-bit     |  16-bit header checksum         |
|                        | protocol   |                                  |
|         32-bit source IP address                                      |
|         32-bit destination IP address                                 |
|          options (if any)                                             |
|                                                                       |
|                       data                                            |
|                                                                       |

   Version - currently has the value 4
   Header length - the number of 32-bit words in the header
                 - because this is 4 bits, the max header length
                &nbs p;  is 15 words (i.e. 60 bytes)
                 - the header is at least 20 bytes, but options may
                &nbs p;  make it bigger
   Type of Service - contains a 3-bit precedence field (that is
                &nbs p;    ignored today), 4 service bits, and 1 unused bit.
                &nbs p;    The four service bits can be:
                &nbs p;    1000 - minimize delay
                &nbs p;    0100 - maximize throughput
                &nbs p;    0010 - maximize reliability
                &nbs p;    0100 - maximize throughput
                &nbs p;    0010 - maximize reliability
                &nbs p;    0001 - minimize monetary cost
                &nbs p;  - This is a "hint" of what characteristics of the
                &nbs p;    physical layer to use
                &nbs p;  - The Type of Service is not supported in most
                &nbs p;    implementations.  However, some implementations
                &nbs p;    have extra fields in the routing table to indicate
                &nbs p;    delay, throughput, reliability, and monitary cost.
   Total Length - specified in bytes.
                - we know where the data starts by the header length
                - we know the size of the data by computing
                &nbs p; "total length - header length"
   Identification - uniquely identifies the datagram.
                &nbs p;  usually incremented by 1 each time a datagram is sent.
   Flags and Fragmentation Offset - used for fragmentation (described below)
   Time to Live - Upper limit of routers
                - usually set to 32 or 64.
                - decremented by each router that processes the datagram,
                - router discards the datagram when TTL reaches 0.
   Protocol - Tells IP where to send the datagram up to.
            - 6 means TCP
            - 17 means UDP
   Header checksum -  Only covers the header, not the data.
   Source IP address -- the sender
   Destination IP address -- the final destination
   Options -- optional data.  Some examples include having the router
              put in a IP address of router and a time stamp so the
              final destination knows how long it took to get to each hop.
Note:  The source and destination in the IP header is the original source
       and the final destination!  The physical layer addresses pass
       the datagram from router to router.  So, while the physical layer
       addresses change from router to router, the source and destination
       IP addresses in the IP datagram remain constant.
Note:  Here's how to compute a checksum:
       1. Put a 0 in the checksum field.
       2. Add each 16-bit value together.
       3. Add in any carry
       4. Inverse the bits and put that in the checksum field.
       To check the checksum:
       1. Add each 16-bit value together (including the checksum).
       2. Add in carry.
       3. Inverse the bits.
       4. The result must be 0.
       Remember, only the bits in the header are calculated in
       the IP checksum.
Consider the following IP header, with source IP address of and destination address of  All
values are given in hex:
                &nbs p;    45 00 00 6c
                &nbs p;    92 cc 00 00
                &nbs p;    38 06 00 00
                &nbs p;    92 95 ba 14
                &nbs p;    a9 7c 15 95
So, first add all 16-bit values together, adding in the carry each time:
 + 006c
 + 92cc
 + 0000
 + 3806
  1103e <---But, we have a carry here!  So, remove the leftmost bit
            and add it back in.  So, we get:  103e + 1 = 103f.
 + 0000
 + 9295
 + ba14
  15ce8 <---Again, we have a carry here!  So, remove the leftmost bit
            and add it back in.  So, we get:  5ce8 + 1 = 5ce9.
 + a97c
  10665 <---Again, we have a carry here!  So, remove the leftmost bit
            and add it back in.  So, we get:  0665 + 1 = 0666.
 + 1595
   Now we have to inverse the bits.
        1bfb = 0001 1011 1111 1011
 inverse bits: 1110 0100 0000 0100  = e404
   So, the checksum is e404.  So, the IP header we send looks like:
                &nbs p;    45 00 00 6c
                &nbs p;    92 cc 00 00
                &nbs p;    38 06 e4 04
                &nbs p;    92 95 ba 14
                &nbs p;    a9 7c 15 95
  As an excercise, please act as the receiver, compute the checksum on
  that packet, and make sure the result is 0!
IP Fragmentation
  Note:  the total_length field in the IP header is 16 bits.
         that means the max size of of an IP datagram is
         65535 bytes.
         BUT, the physical layer may not allow a packet size of
         that many bytes (for example, a max ethernet packet is
         1500 bytes)
         SO, IP must sometimes fragment packets.
  - When an IP datagram is fragmented, each fragment is treated
    as a separate datagram.
      - it is reassembles at the final destination, not at a router!
      - it does that because the router may have to fragment it again!
  - Each fragment has its own header.
  - The identification number is copied into each fragment.
  - One bit in the "flags" field says "more fragments are coming.
     - If that bit is 0, then it signifies this is the last fragment.
  - The "fragment offset" field contains the offset of the data.
    NOTE:  fragment flag of 0 and offset of 0 means the datagram
           is not fragmented.
    NOTE: fragment offset is measured in units of 8 bytes (64 bits).
          That is because the fragment offset field is 3 bits shorter
          than the total length field (and 2^3 is 8).
  - The entire flags field looks like this:
       | bit 0 | bit 1  | bit 2  |
       bit 0:  not used
       bit 1:  if 1, it means "don't fragment".  If IP must fragment the
               packet and this bit is set, IP throws away the datagram.
       bit 2:  The fragment flag.
  Suppose we have a physical layer that can transmit a maximum of 660 bytes.
  And, suppose IP wants to send 1460 bytes of data.  So, the IP datagram
  is a total of 1480 bytes, including the 20 byte IP header:
     | 20-byte ip header  |   1460 bytes of data |
  Here is what IP sends:
First packet:
   bytes:  20                  640
     | IP header   |    first 640 bytes of data  |
   In that packet, "fragment flag" is 1, offset is 0.
Second packet:
   bytes:  20                  640
     | IP header   |   second 640 bytes of data  |
   In that packet, "fragment flag" is 1, offset is 80.  The offset
   is 80 because (80 * 8) is 640, so the offset of that data is 640
   byes into the packet.
   Note: all other fields of the IP header are identical to the
         first packet (except the checksum)!
Third packet:
   bytes:  20                  640
     | IP header   |   third 180 bytes of data   |
   In that packet, "fragment flag" is 0, offset is 160.  The offset
   is 160 because (160 * 8) is 1280, so the offset of that data is 1280
   byes into the packet.
   Note: all other fields of the IP header are identical to the
         first packet except the checksum.
The routers see 3 separate packets.  The final destination reassembles
the packet before passing the packet to the upper layers.
Now, as an exercise, please try to figure out what the "frag flag" and
"offset" would be for the above packets if a router had to pass the
above three packets to a physical layer than only accepted packets of
max size 400.  I'll probably put a question like that on the final.
Note:  IP can tell if it's fragmenting a fragment, right?  If a packet
       has "frag flag" of 0 and offset of 0, then the packet is not
       fragmented.  When fragmenting a fragment, IP must make sure
       the final destination can put the packet back together correctly.
       So, IP only sets the "frag flag" to 0 on a packet if in fact
       the packet contains the very last fragment of the entire packet.
Let's look at a transport-layer protocol:
        UDP -- The User DataGram Protocol
 - UDP is a simple, connectionless protocol
      - it provides no reliability; it simply sends data to the IP layer
 - To use UDP, an application associates itself with a "transport address"
   - for UDP, a transport address is a combination of an IP address and
     a port number
   - a port number is a 16-bit number that uniquely identifies the
     application using UDP.
On the server side, the server application does the following:
   1. Get a transport endpoint into UDP
   2. Bind to a transport address
   3. Wait for a datagram to arrive
   4. Read the datagram
   5. Send a reply datagram is the application protocol warrents it.
On the client side, the client application does the following:
   1. Get a transport endpoint into UDP
   2. Bind to a transport address
   3. Send a datagram to the application on the server machine, specifying
      the transport address to which the server bound.
   4. Wait for a reply if the application protocol warrents it
   5. Client should time-out and resend the datagram if a response does not
      arrive after a time-out period.
Let's look at the UDP protocol:
        --------------------------------------------------------- --------
        | 16-bit source port number  |   16-bit destination port number |
        --------------------------------------------------------- --------
        | 16-bit UDP length      &n bsp;   |   16-bit UDP checksum            |
        --------------------------------------------------------- --------
        |         &n bsp;            data                 &n bsp;                 &n bsp; |
        --------------------------------------------------------- --------
  - The length is that of the header and the data in bytes.
       - Header is 8 bytes
       - Note:  Max IP datagram size is 65535 bytes, minus 20 bytes
                for the IP header ===> 65515 bytes left for data.
                But, UDP header is 8 bytes, leaving 65507 bytes for the
                maximum amount of user data.

                However, some implementations of UDP limit that value.
                AIX 3.2.2 and Solaris 2.5 and 2.6 allow the full size.
                SunOS 4.1.3 can only accept UDP packets of no more than
                32766 bytes (i.e., 32758 bytes of user data).
  - UDP Checksum covers header, data, and extra information.
     - To compute checksum:
       1.  If the data has an odd length, pad the data with a 0 byte.
       2.  Put a 0 in the checksum field.
       3.  Create a "pseudo-header" that contains a 32-bit source IP
           address, a 32-bit destination IP address, 8 bits of 0's,
           an 8-bit protocol number (17 for UDP), and a 16-bit UDP
           length, followed by the real UDP header, followed by the data.
       4.  Compute the checksum just like IP does it.
       5.  If calculated checksum is 0, store it as all 1's.
Note:  You don't have to compute the checksum!
         - if you don't, you must store a 0 in the checksum field.
       Checksum is optional to speed things up in a reliable physical
         - usually a tunable parameter to control if a checksum is computed
           or not.
Example of checksum
Let's say an application at, port 4052 wants
to send a packet containing elvis0 to, port 5134.
Now, port 4052 is hex 0FD4, and port 5134 is hex 140E.  And, because
the data has 6 characters, the total length is 14 (that hex E).  And,
the word "elvis0" has a ASCII hex representation of "65 6c 76 69 73 00"
So, if we put a 0 in the checksum field, the packet looks like this:
        0FD4 140E
        000E 0000
        656c 7669
To compute the checksum, we have to create a pseudo header.  Now, has a hex value of C6 4B 18 79.  Also, the destination
( has a hex value of  C6 4B 18 24.  And, the value "17"
has a hex value of "11".  So, we create a "pseudo-header" that looks
like this:
        C64B 1879    <- source IP address
        C64B 1824    <- destination IP address
        0011 000E    <- 00, 17, and length
        0FD4 140E    <- source port, dest port
        000E 0000    <- length (again) and 0 checksum
        656c 7669    <- "elvi"
        7300         <- "s0"
Now add all the 16-bit values together and add in any carry.
+ 1879
+ C64B
+    1 <- carry
+ 1824
+ 0011
+ 000E
+ 0FD4
+ 140E
+ 000E
+ 0000
+ 656c
+    1 <- carry
+ 7669
+ 7300
+    1 <- carry
In binary, that 0011000000011010.  Inverse it, you get 1100111111100101,
which is CFE5.  That's the checksum!