Copy from:http://cs.nyu.edu/courses/fall98/G22.2262-001/class11.txt
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 |
| |
-------------------------------------------------------------------------
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
is 15 words (i.e. 60 bytes)
- the header is at least 20 bytes, but options may
make it bigger
Type of Service - contains a 3-bit precedence field (that is
ignored today), 4 service bits, and 1 unused bit.
The four service bits can be:
1000 - minimize delay
0100 - maximize throughput
0010 - maximize reliability
0001 - minimize monetary cost
- This is a "hint" of what characteristics of the
physical layer to use
- The Type of Service is not supported in most
implementations. However, some implementations
have extra fields in the routing table to indicate
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
"total length - header length"
Identification - uniquely identifies the datagram.
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.
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 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.
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 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.
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 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 | 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).
- 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
layer.
- usually a tunable parameter to control if a checksum is computed
or not.
Example of checksum
====================
Let's say an application at 198.75.24.121, port 4052 wants
to send a packet containing elvis0 to 198.75.24.36, 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
7300
To compute the checksum, we have to create a pseudo header. Now,
198.75.24.121 has a hex value of C6 4B 18 79. Also, the destination
(198.75.24.36) 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.
C64B
+ 1879
====
DEC4
+ C64B
====
A50F
+ 1 <- carry
====
A510
+ 1824
====
BD34
+ 0011
====
BD45
+ 000E
====
BD53
+ 0FD4
====
CD27
+ 140E
====
E135
+ 000E
====
E143
+ 0000
====
E143
+ 656c
====
46AF
+ 1 <- carry
====
46B0
+ 7669
====
BD19
+ 7300
====
3019
+ 1 <- carry
====
301A
In binary, that 0011000000011010. Inverse it, you get 1100111111100101,
which is CFE5. That's the checksum!