IP -- The Internet Protocol (continued)

The IP packet format:

-------------------------------------------------------------------------
| 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                                 |
|                                                                       |
-------------------------------------------------------------------------
 

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.

Example:

Consider the following IP header, with source IP address of 146.149.186.20 and destination address of 169.124.21.149. All values are given in hex:

45 00 00 6c
92 cc 00 00
38 06 00 00
92 95 ba 14
a9 7c 15 95

So, first add all 16-bit values together, adding in the carry each time:

  4500
+ 006c
  ----
  456c
+ 92cc
  ----
  d838
+ 0000
  ----
  d838
+ 3806
  ----
  1103e <---But, we have a carry here! So, remove the leftmost bit and add it back in. So, we get: 103e + 1 = 103f.
  103f
+ 0000
  ----
  103f
+ 9295
  ----
  a2d4
+ ba14
  ----
 15ce8 <---Again, we have a carry here! So, remove the leftmost bit and add it back in. So, we get: 5ce8 + 1 = 5ce9.
  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.
  0666
+ 1595
  ----
  1bfb

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:

45 00 00 6c
92 cc 00 00
38 06 e4 04
92 95 ba 14
a9 7c 15 95

As an exercise, please act as the receiver, compute the checksum on that packet, and make sure the result is 0!
 

IP Fragmentation

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.

Example:

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                       180
    ---------------------------------------------
    | 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 bytes into the packet.

Note: all other fields of the IP header are identical to the first packet except the checksum.

IMPORTANT:
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 warrants 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 warrants 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          |   16-bit UDP checksum            |
   -----------------------------------------------------------------
   |                      data                                     |
   -----------------------------------------------------------------
 
  - 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).