Aquest concepte en informàtica pot fer referència a múltiples qüestions:
En aquest article s'explica en detall la fragmentació en xarxes de comunicacions. El procés invers a la fragmentació és el reensamblament.
Quan un datagrama IP (aka IP datagram) arriba a un router però és massa gran per ser transmès degut a que supera el maximum transmission unit (MTU) del protocol d'enllaç de per sota del següent enllaç cap al següent encaminador, aleshores succeïx la fragmentació, és a dir s'ha re reconvertir en múltiples paquets IP anomenats fragments per tal de poder ser enviat pel següent enllaç. En alguns casos, els fragment poden tenir que ser tornats a fragmentar més endavant.
Qüestions a tenir en compte:
La fragmentació és necessària per tal de tenir un protocol com Internet que sigui independent dels protocols de capa inferior (protocols de capa d'enllaç), però introdueix complexitat al protocol IP. Cal recordar que el protocol IP és un protocol unreliable i sense connexió. Els datagrames IP poden prendre múltiples rutes diferents en el seu camí de l'origen al destí, i alguns paquets poden no arribar a la destinació. Cal doncs tenir en compte:
Per solucionar aquests problemes i poden reensamblar el paquet, el protocol IP inclou camps específics a la seva capçalera. Alguns valors són comuns a tots els fragments i altres són diferents a cada fragment.
Recursos:
Vegem un exemple de fragmentació amb el protocol IP transportant-se per un dels enllaços de comunicació punt a punt funcionant amb Ethernet:
Imagineu un paquet IP de mida 2366 bytes, que s'ha d'encapsular dins d'una trama Ethernet amb la mida de MTU estàndard (1500). Es obvi que el paquet no cap i s'ha de fragmentar en dos parts:
Recursos:
Procediment detallat:
Vegeu també Fragmentació IP
Amb IPv6, la fragmentació es realitza tan sols al node origen del paquet, contràriament que amb IPv4 - on els routers poden fragmentar un paquet. Amb IPv6, les opcions també se surten de la capçalera estàndard i són especificades pel campo "Capçalera Següent" (Next Header), similar en funcionalitat amb IPv4 al camp Protocol. Un exemple: amb IPv4 s'afegiria l'opció "ruta fixada des de l'origen" (Strict Source and Record Routing) a la capçalera IPv4 si es vol forçar una determinada ruta per al paquet- Però en IPv6 es modificaria el camp "Capçalera Següent", indicant que una capçalera d'encaminament és la pròxima de venir. La capçalera d'encaminament podrà llavors especificar la informació addicional d'enrutament per al paquet, i indicar que, por exemple, la capçalera TCP serà la següent. Aquest procediment és anàleg al d'AH i ESP amb IPsec per a IPv4 (que s'aplica igualment a IPv6).
El procés invers s'anomena Reassembly. El procés de fragmentació i reensamblació no és simètric:
Els routers intermediaris en una comunicació poden fragmentar un paquet simple o un paquet que ja és una fragmentació d'un altre paquet. En canvi els routers intermediaris no fan mai reensamblament. Això només és fa a la màquina de destinació del paquet, per tant un cop fragmentats els paquets en algun tram aleshores els fragments ja s'envien tal cual i només seran modificats si torben algun enllaç encara més petit de MTU i cal tornar a fragmentar per que els fragments śon més petits que el MTU.
Hi ha múltiples raons per fer-ho així, però segurament la més important és que diferents fragments poden arribar a prendre rutes diferents per anar d'origen a destí, i per tant els routers intermediaris no tenen perque veure tot els fragments. Un altre raó és que si els routers han de reensamblar aleshores augmenta la seva complexitat i per tant més temps de computació que implica menys rendiment.
Un altre raó és que cal esperar a tots els missatges per reensamblar, fet que un altre cop pot ser una penalització.
Els routers es poden dedicar a immediatament redirigir el paquet.
També hi ha inconvenients. El principal és que hi ha més posibilitats de que un fragment es perdi i per tant que calgui reenviar tot el paquet. L'altre és que no s'aprofita la capacitat del frame al nivell de enllaç.
A la gràfica l'últim link no aprofita la capacitat de 3300 de MTU.
The Reassembly Process
As we saw in looking at how fragmentation works, it involves a fair bit of complexity. Several IP header fields are filled in when a message is fragmented to give the receiving device the information it requires to properly reassemble the fragments. The receiving device follows a procedure to keep track of the fragments as they are received and build up its copy of the total received message from the source device. Most of its efforts are geared around dealing with the potential difficulties associated with IP being an unreliable protocol.
The details of implementation of the reassembly process are specific to each device, but generally include the following functions:
Fragment Recognition and Fragmented Message Identification: The recipient knows it has received a message fragment the first time it sees a datagram with the More Fragments bit set to one or the Fragment Offset a value other than zero. It identifies the message based on: the source and destination IP addresses; the protocol specified in the header; and the Identification field generated by the sender.
Buffer Initialization: The receiving device initializes a buffer where it can store the fragments of the message as they are received. It keeps track of which portions of this buffer have been filled with received fragments, perhaps using a special table. By doing this, it knows when the buffer is partially filled with received fragments and when it is completely full.
Timer Initialization: The receiving device sets up a timer for reassembly of the message. Since it is possible that some fragments may never show up, this timer ensures that the device will not wait “forever” trying to reassemble the message.
Fragment Receipt and Processing: Whenever a fragment of this message arrives (as indicated by it having the same source and destination addresses, protocol and Identification as the first fragment), the fragment is processed. It is inserted into the message buffer in the location indicated by its Fragment Offset field. The device also makes note of the fact that this portion of the message has been received.
Reassembly is finished when the entire buffer has been filled and the fragment with the More Fragments bit set to zero is received, indicating that it is the last fragment of the datagram. The reassembled datagram is then processed like a normal, unfragmented datagram would be. On the other hand, if the timer for the reassembly expires with any of the fragments missing, the message cannot be reconstructed. The fragments are discarded, and an ICMP Time Exceeded message generated. Since IP is unreliable, it relies on higher layer protocols such as TCP to determine that the message was not properly received and then retransmit it.
As we saw in looking at how fragmentation works, it involves a fair bit of complexity. Several IP header fields are filled in when a message is fragmented to give the receiving device the information it requires to properly reassemble the fragments. The receiving device follows a procedure to keep track of the fragments as they are received and build up its copy of the total received message from the source device. Most of its efforts are geared around dealing with the potential difficulties associated with IP being an unreliable protocol.
The details of implementation of the reassembly process are specific to each device, but generally include the following functions:
Fragment Recognition and Fragmented Message Identification: The recipient knows it has received a message fragment the first time it sees a datagram with the More Fragments bit set to one or the Fragment Offset a value other than zero. It identifies the message based on: the source and destination IP addresses; the protocol specified in the header; and the Identification field generated by the sender.
Buffer Initialization: The receiving device initializes a buffer where it can store the fragments of the message as they are received. It keeps track of which portions of this buffer have been filled with received fragments, perhaps using a special table. By doing this, it knows when the buffer is partially filled with received fragments and when it is completely full.
Timer Initialization: The receiving device sets up a timer for reassembly of the message. Since it is possible that some fragments may never show up, this timer ensures that the device will not wait “forever” trying to reassemble the message.
Fragment Receipt and Processing: Whenever a fragment of this message arrives (as indicated by it having the same source and destination addresses, protocol and Identification as the first fragment), the fragment is processed. It is inserted into the message buffer in the location indicated by its Fragment Offset field. The device also makes note of the fact that this portion of the message has been received.
Reassembly is finished when the entire buffer has been filled and the fragment with the More Fragments bit set to zero is received, indicating that it is the last fragment of the datagram. The reassembled datagram is then processed like a normal, unfragmented datagram would be. On the other hand, if the timer for the reassembly expires with any of the fragments missing, the message cannot be reconstructed. The fragments are discarded, and an ICMP Time Exceeded message generated. Since IP is unreliable, it relies on higher layer protocols such as TCP to determine that the message was not properly received and then retransmit it.
Acacha Wiki
