IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

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.

Introducció

ipmtu.png
ipfragmentationreassembly.png

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:

  • Sequencing and Placement: The fragments will typically be sent in sequential order from the beginning of the message to the end, but they won't necessarily show up in the order in which they were sent. The receiving device must be able to determine the sequence of the fragments to reassemble them in the correct order. In fact, some implementations send the last fragment first, so the receiving device will immediately know the full size of the original complete datagram. This makes keeping track of the order of segments even more essential.
  • Separation of Fragmented Messages: A source device may need to send more than one fragmented message at a time; or, it may send multiple datagrams that are fragmented en route. This means the destination may be receiving multiple sets of fragments that must be put back together. Imagine a box into which the pieces from two, three or more jigsaw puzzles have been mixed and you understand this issue.
  • Completion: The destination device has to be able to tell when it has received all of the fragments so it knows when to start reassembly (or when to give up if it didn't get all the pieces).

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:

Fragmentació en xarxes

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:

  • Primer paquet: tindrà una mida de 1500 = 20 de IP header + 24 bytes de TCP header i la resta 1,456 bytes de dades del protocol superior (per exemple HTTP).
  • Segon paquet: Serà de 910 bytes = 20 bytes IP header + 24 de TCP header i la resta 866 de dades.

Recursos:

Fragmentació IP

Procediment detallat:

Vegeu també Fragmentació IP

Fragmentació IPv6

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

Reensamblament

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.

ipfragmentationreassembly.png


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.

Procés

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.

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

Vegeu també

Enllaços externs