IP fragmentation
Author: Updated: Legume Source: Update Time: 2004.07.11 Contributor mail: jc@ddvip.net As we described in two 8, the physical network layer generally limit the maximum length of each transmission data frame. At any time, the IP layer receives a part of the IP datagram to send, it is to be judged to send data (selection) to the local, and query the interface to obtain its MTU. IP compares the MTU with the data report length if needed. Split can occur on the original transmit-end host, or on the intermediate router. After the IP data is divided, only the destination is re-assembled (the reassembly here is different from other network protocols, which requires reassembly in the next stop, not in the final destination). Reissue the IP layer of the destination to complete, the purpose is to make the slice and reassembly process transparent to the transportation layer (T C P and UDP), except for some possible levels of operation. Data that has been sliced may be shard again (possibly more than once). The data contained in the IP header provides sufficient information for fragmentation and reassembly. Recall the first IP header (Figure 3 - 1), below for fragmentation processes. For each IP datagram file sent by the sender, its identity field contains a unique value. This value is copied to each piece when the data is divided (we have seen this field). The flag field uses one of the bits to represent "more slides". In addition to the last one, the other of each of the other components of the data is set to 1. The slice offset field refers to the position of the film offset the original datagram. Further, after the data is reported, the total length value of each sheet is changed to the length value of the sheet. Finally, there is a bit called "no slice" bit in the flag field. If this ratio is set, IP will not slide the datagram. In contrast, discard the datagram and send an I c m p error message ("" need to be shard, but set up no sliver, see Figure 6 - 3) give the start end. In the next section we will see examples of this error. When IP datagram is sliced, each piece is a group, with its own IP head, and independently in selecting routes. Thus, it is possible to sequel when the sheets of the data report arrive at the destination, but there is sufficient information in the IP header to make the receiving end correctly assemble these data messages. Although the IP fragmentation processes look transparent, there is a point that people don't want to use it: even if only one piece of data is lost, it is necessary to retransmit the entire datagram. Why do this happen? Because the IP layer itself does not have timeout retransmission mechanism - by the higher level is responsible for timeout and retransmission (T C P has timeout and retransmission mechanism, but UDP does not. Some UDP applications itself perform timeout and retransmission). When a piece of loss from the T c p report segment, T C P retransmit the entire T c P packet section after the timeout, which corresponds to an IP datagram. There is no way only to retransmit a data report in the datagram. In fact, if the data is divided into an intermediate router, instead of a starting system, the starting system cannot know how the datagram is slid. This reason is often avoided. Document [Kent and Mogul 1987] discusses the separation of fragmentation. Using UDP can easily lead to IP shards (later we will see, T C P attempt to avoid shards, but for applications, it is almost impossible to force T C P to send a long-term report section that requires fragmentation. We can use the S O C K program to increase the length of the datagram until the fragmentation occurs.
