Fundamentals (of Linux Networking) - Internet Protocol (Page 4 of 8 )
So far, we’ve discussed building a network based on Ethernet. We’ve also discussed connecting two or more networks together via a gateway, called an internet, and we’ve covered the basic issues surrounding network and host addressing that allow network nodes to communicate with each other without conflicts. Yet how are all of these dissimilar networks expected to communicate efficiently without problems? What is it that lets one network look the same as any other network?
A protocol exists that enables packet exchanges between networks as if the connected networks were a single, homogenous network. This protocol is known as the Internet Protocol, or IP, and was defined by RFC 791 in September 1981. These interconnected networks are known as internets, not to be confused with the Internet. The Internet is just one example of a global internet, albeit the most popular and the most well known. However, this does not preclude the existence of other internets that use the same technologies, such as IP.
Because IP is hardware independent, it requires a hardware-independent method of addressing nodes on a network, which is the IP addressing system already discussed. In addition to being hardware independent and being a packet-switching technology, IP is also connectionless. IP performs three key functions in an internet:
- It defines the basic unit of data transfer.
- It performs the routing function used by gateways and routers to determine which path a packet will take.
- It uses a set of rules that allow unreliable packet delivery.
These rules determine how hosts and gateways on connected networks should handle packets, whether a packet can be discarded, and what should happen if things go wrong.
Like the physical Ethernet frame that contains data as well as header information, the basic unit of packet transfer used by IP is called the Internet datagram. This datagram also consists of both a header portion and a data portion. Table 1-4 lists the format of the IP datagram header, along with the size of each field within the header.
Table 1-4. IP Datagram Header Format
FIELD | SIZE | DESCRIPTION |
VERS | 4 bits | The version of IP used to create this |
datagram |
HLEN | 4 bits | The length of the datagram header, |
| | | measured in 32-bit words |
SERVICE TYPE | 8 bits | Specifies how the datagram should be |
| | handled |
TOTAL LENGTH | 16 bits | The total length of the datagram, |
| | measured in octets |
IDENTIFICATION | 16 bits | A unique integer generated by the |
| | sender that allows accurate datagram |
| | reassembly |
FLAGS | 3 bits | Various control flags, such as whether |
| | the datagram may be fragmented |
FRAGMENT OFFSET | 13 bits | Indicates where in the datagram this |
| | fragment belongs |
TIME TO LIVE | 8 bits | Specifies how long, in seconds, the |
| | datagram is allowed to exist |
PROTOCOL | 8 bits | Specifies which higher-level protocol |
| | was used to create the data in the data |
| | portion of the datagram |
HEADER CHECKSUM | 16 bits | Checksum for the header, recomputed |
| | and verified at each point where the |
| | datagram is processed |
SOURCE ADDRESS | 32 bits | IP address of the sender |
DESTINATION ADDRESS | 32 bits | IP address of the recipient |
OPTIONS | Variable | Any number of various options, typically |
| | used for testing and debugging |
PADDING | Variable | Contains the number of zero bits |
| | needed to ensure the header size is an |
| | exact multiple of 32 bits |
/mini-image_6.JPG)
Figure 5-6. IP datagram encapsulation in an Ethernet frame
Most of these fields look pretty similar to the description of an Ethernet frame. What is the relationship between Ethernet frames, or packets, and IP datagrams? Remember that IP is hardware independent and that Ethernet is hardware. Thus, the IP datagram format must be independent of the Ethernet frame specification. In practice, the most efficient design would be to carry one IP datagram in every Ethernet frame. This concept of carrying a datagram inside a lower-level network frame is called . When an IP datagram is encapsulated within an Ethernet frame, it means the entire IP datagram, including header, is carried within the portion of the Ethernet frame, as shown in Figure 1-6.
We’ve said that an Ethernet frame has a maximum size of 1500 octets. Yet an IP datagram has a maximum total length of 16 bits. A 16-bit number can represent a data size of up to 65,535 octets and could potentially be much higher. How do we cram 65,535 octets into a network frame that maxes out at 1500? By using a technique called fragmentation.
Fragmentation is necessary in network protocols because the goal should be to hide the underlying hardware used to create the network. In our case, it’s Ethernet, but in practice it could be any number of different systems, past or future. It wouldn’t make sense to require changes to higher-level protocols every time someone invented a new hardware network technology, so to be universally compatible, the designers of IP incorporated the ability to split IP datagrams into fragments, assigning one fragment per network frame in the most efficient way possible.
The IP protocol does not guarantee that large datagrams will be delivered without fragmentation, nor does it limit datagrams to some smaller size. The sending node determines the appropriate datagram size and performs the fragmentation, while the receiving node performs the reassembly. The reassembly is made possible by the fragment offset field of the datagram header, which tells the receiver where this particular fragment should go. When the datagram is fragmented, each fragment carries a header that is essentially a duplicate of the original datagram header, with some minor changes. The fragment’s header differs because, if there are more fragments, the “more fragments” flag is set, and the fragment offset will change on each fragment to prevent overwriting.
Thus, an IP datagram of 4000 octets might get fragmented into three Ethernet frames, two containing the maximum data size and the third containing what’s left. On the receiving end, these fragments would be reassembled into the original datagram and would be processed. If our physical network had a smaller frame size than Ethernet, we would get more fragments, and less fragments (or no fragments at all) with a larger frame size.
NOTE Gateways are responsible for converting packets from one frame size to another.
Every network has a maximum transfer unit, or MTU. The MTU can be any size. If your packets are sent from a network with a large MTU value to a network with a smaller value (or vice versa), the gateway between the two is responsible for reformatting the packets to comply with each network’s specifications. For example, say you had a gateway with an Ethernet interface and a Token Ring interface. The MTU on one network is 1500 octets, while the MTU on the Token Ring network might be larger or smaller. It is the gateway’s responsibility to reformat and fragment the packets again when moving from one network to another. The downside to this is that once fragmented to accommodate the smaller MTU, the packets aren’t reassembled until they reach their destination. Thus, the receiving node will receive datagrams that are fragmented according to the network with the smallest MTU used in the transfer. This can be somewhat inefficient, since after traversing a network with a small MTU, the packets might traverse a network with a much larger MTU without being reformatted to take advantage of the larger frame size. This minor inefficiency is a good trade-off, however, because the gateways don’t need to store or rebuild packet fragments, and the packets can be sent using the best path without concern for reassembly problems for the destination node.
Next: Protocol Layering >>
More Administration Articles
More By Apress Publishing
|
 This article is excerpted from chapter one of the book The Definitive Guide to Linux Networking Programming, written by Keir Davis et. al. (Apress, 2004; ISBN: 1590593227). Check it out today at your favorite bookstore. Buy this book now.
|
|
/ 19 
