lunes, 11 de julio de 2011

Tamaño de datagramas IP, unidad de transmisión máxima (MTU), fragmentación y reensamblado. (VIII entrega)

Pues aquí va la octava entrega, que debió salir mas temprano (en mi huso horario todavía es lunes), bueno .... entonces al menos técnicamente es lunes de redes. Trata hoy del proceso de fragmentación de datagramas IP, antes hemos visto que la capa donde reside IP es una especie de cuello de botella viendo la pila en perspectiva, esto significa (entre otras cosas) que debe cargar con complejidades adicionales para que el resto de las capas (superiores e inferiores) pueden operar sin complicaciones.  Una de estas complejidades refiere precisamente al proceso de fragmentación que asegura que el datagrama atraviese literalmente el planeta y (solo Dios sabe) un sin número de tecnologías en la capa física de manera transparente. Adelante los detalles, los originales inician aquí y concluyen aquí. Es muy probable que le semana que entra iniciemos finalmente IPv6, trataremos al menos, hasta entonces pues les saludo y provecho!


Contenido.
2.3- Tamaño de datagramas IP, unidad de transmisión máxima (MTU), fragmentación y reensamblado.
2.3.1- Tamaño de datagramas IP, unidad de transmisión máxima (MTU), y generalidades de la fragmentación.
2.3.2- Proceso de fragmentación del mensaje IP.
2.3.3- Proceso de reensamblado del mensaje IP.


La responsabilidad principal de IP es entregar los datos entre los dispositivos interconectados. Como vimos en la sección anterior, esto requiere que los datos recibidos de las capas superiores se encapsulen en datagramas IP para su transmisión. Estos datagramas se transmiten a la capa de enlace de datos en la que se envían a través de enlaces de red física.
Para que esto funcione correctamente, cada datagrama debe ser lo suficientemente pequeño como para caber en el formato de la trama de la tecnología subyacente. Si el mensaje es más grande que el tamaño máximo de trama de la red subyacente, puede ser necesario dividir un mensaje en varios datagramas IP, un proceso conocido como fragmentación. Los datagramas se envían por separado y se vuelven a unir en el mensaje original.
El Protocolo IP está diseñado para administrar el tamaño de datagrama, y para permitir la fragmentación y el montaje de una manera sencilla. En esta sección voy a explorar temas relacionados con la administración del tamaño de los datagramas IP. Comienzo con una visión general de los problemas relativos al tamaño de datagrama y el importante concepto de la unidad de transmisión máxima (MTU) de la red, discutiendo por qué es necesaria la fragmentación. Luego describo el proceso por el cual los mensajes IP a transmitir son fragmentados por el dispositivo de origen y posiblemente por los routers, a lo largo de la ruta hacia el destino, y luego esbozo la forma en que se vuelven a juntar por el destinatario.

Antecedentes: Explicar la fragmentación y el montaje requiere una cierta comprensión del formato básico de los datagramas IP y algunos de los campos que contienen. Si usted no ha leído todavía el tema que describe el formato general de los datagramas IP es posible que desee revisarlo antes de continuar con esto.

Como protocolo central de la capa de red de la suite TCP/IP, IP está diseñado para implementar interconexiones potencialmente grandes de dispositivos. Cuando trabajamos con IP nos acostumbramos a la idea de que los hosts son capaces de enviar información de ida y vuelta a pesar de que los extremos pueden estar muy lejos y los datos pueden tener que viajar a través de muchos dispositivos entre ellos. A pesar de que por lo general se puede considerar la Internet TCP/IP como un gran "red virtual" de dispositivos abstractos, debemos recordar que por debajo de la capa de red, los datos siempre viajan a través de una o más redes físicas. La implementación del Protocolo de Internet debe tener en cuenta también esta realidad.

Para enviar mensajes empleando el protocolo IP se encapsulan los datos de las capas superiores en datagramas IP. Estos datagramas entonces deben ser enviados a la capa de enlace de datos, donde además se encapsulan en tramas de la clase de tecnología que vaya a ser utilizada para transportarlos físicamente, ya sea directamente a su destino, o indirectamente a la siguiente etapa intermedia en su viaje al destinatario. La implementación de la capa de enlace de datos pone el datagrama IP completo en la parte de datos (la carga) de su formato de trama, al igual que IP pone los mensajes de la capa de transporte, el dato y los encabezados, en su campo de datos IP. Esto inmediatamente nos plantea un problema potencial: y es el de hacer corresponder el tamaño de los datagramas IP con el tamaño de la trama subyacente de la capa de enlace de datos.

Haciendo coincidir el tamaño del datagrama IP con el tamaño de la trama subyacente de la capa de enlace de datos.
La red subyacente que utiliza el dispositivo para conectarse a otros dispositivos podría ser una conexión LAN como Ethernet o Token Ring, una conexión LAN inalámbrica, como 802.11 o un acceso telefónico, DSL, T-1 u otra conexión WAN. Cada red física en general, hará uso de su propio formato de trama, y cada formato tiene un límite en la cantidad de datos que puede enviar en una sola trama. Si el datagrama IP es demasiado grande para el formato de trama de la capa de enlace de datos, tenemos un problema!
Por ejemplo, considere una FDDI. El tamaño máximo del campo de datos en FDDI es de alrededor de 4.470, dependiendo de si se utiliza o no SNAP. Esto significa que FDDI puede manejar un datagrama IP de hasta 4470 bytes. Por el contrario, una trama Ethernet regular utiliza un formato que limita el tamaño de la carga útil enviada a 1.500 bytes. Esto significa que Ethernet no puede hacer frente a datagramas IP de más de 1500 bytes de tamaño.

Ahora, recuerde que en el envío de un datagrama a través de una red interna, este puede pasar a través de más de una red física. Para acceder a un sitio en Internet, por ejemplo, normalmente enviamos una solicitud a través de nuestro router local, que luego se conecta a otros routers que finalmente transmiten la petición a la página de Internet. Cada salto que reenvía el datagrama puede utilizar una red física diferente, con un tamaño máximo de trama subyacente diferente.
La idea detrás de un protocolo de capa de red es poner en práctica el concepto de una "red virtual" donde los dispositivos hablan entre ellos a pesar de que están lejos. Esto significa que las capas superiores no deberían tener que preocuparse por detalles como los límites de tamaño de las tecnologías subyacentes de la capa de enlace de datos. Sin embargo, alguien tiene que preocuparse por esto. Esta tarea recae en el Protocolo de Internet.

Unidad de transmisión máxima (MTU) y fragmentación de datagramas.
La implementación IP de todos los dispositivos en una red IP tiene que ser consciente de la capacidad de la tecnología utilizada por esta implementación para su conexión con la capa de enlace de datos inmediata con otros dispositivos. Este límite se llama Unidad de Transmisión Máxima (MTU Maximum Transmission Unit) de la red. Este término también se ve a veces como la unidad de transferencia máxima.
Si una capa de IP recibe un mensaje para ser enviado a través de la red interna, primero observa el tamaño del mensaje y luego calcula que tamaño tendrá el datagrama IP después de la adición de los 20 o más bytes necesarios para la cabecera IP. Si la longitud total es mayor que la MTU de la red subyacente, la capa IP divide el mensaje en múltiples fragmentos. Por lo tanto, si un host está conectado a través de una LAN Ethernet a su red local, puede usar un MTU de 1500 para los datagramas IP, y fragmentará cualquier cosa que sea mayor que esto. La figura 88 muestra un ejemplo de diferentes MTU y la fragmentación.

Concepto clave: El tamaño del mayor datagrama IP que puede ser transmitido a través de una red física se conoce como unidad de transmisión máxima (MTU Maximum Transmission Unit) de la red. Si un datagrama pasa de una red con un MTU alta a una con una MTU baja, debe ser fragmentado para adaptarse a la red con la MTU más pequeña.

Dado que algunas redes físicas en el camino entre dos dispositivos pueden tener una MTU más pequeña que otros, puede ser necesario fragmentar más de una vez. Por ejemplo, supongamos que el dispositivo de origen quiere enviar un mensaje IP de 12.000 bytes de largo. Su conexión local tiene una MTU de 3300 bytes. Entonces tendrá que dividir este mensaje en cuatro fragmentos para la transmisión: tres de alrededor de 3.300 bytes de longitud y un cuarto remanente de alrededor de 2.100 bytes. (Estoy simplificando, al ignorar las cabeceras extra que se requieren. El tema siguiente incluye todos los detalles del proceso de fragmentación)

Figura 88: Unidad máxima de transmisión (MTU) y fragmentación.
Clic para ampliar.
En este sencillo ejemplo el dispositivo A, se comunica con un dispositivo B en una pequeña red interna que consta de un router y dos enlaces físicos. El enlace desde A hasta el router tiene una MTU de 3300 bytes, pero desde el router a B solo es de 1300 bytes. Por lo tanto, los datagramas IP más de 1.300 bytes tendrán que ser fragmentados.

Fragmentación de etapas múltiples.
En lo que los fragmentos anteriores se encuentran en tránsito, pueden necesitar atravesar un salto entre dos routers en el que la MTU de la red física es de solo 1300 bytes. En este caso, cada uno de los fragmentos tendrá que ser fragmentado nuevamente. Los fragmentos de 3.300 bytes va a terminar en tres trozos cada uno (dos de alrededor de 1.300 bytes, y uno de unos 700 bytes) y el fragmento final de 2100 bytes se convertirá en un fragmento de 1300 bytes y otro 800 bytes. Así que en lugar de tener cuatro fragmentos, vamos a terminar con once (3 * 3 + 1 * 2)! Esto se ilustra en la Figura 89.
Figura 89: Fragmentación de un datagrama IPv4.
Clic para ampliar.
Este ejemplo ilustra la fragmentación de dos pasos de un datagrama IP grande. Las cajas representan los datagramas o fragmentos de datagramas y se muestran a escala. El datagrama original es de 12.000 bytes de tamaño, representado por el cuadro gris de gran tamaño. Para transmitir estos datos a través del primer enlace local, el dispositivo A lo divide en cuatro fragmentos, mostrados a la izquierda en cuatro colores primarios. El primer router debe dividir cada uno de estos en fragmentos más pequeños para enviarlos a través del enlace con la MTU de 1300 bytes, como se muestra en la parte inferior. Tenga en cuenta que el segundo router no reensambla los fragmentos de 1.300 bytes, aun cuando su enlace con el dispositivo B tiene una MTU de 3300 bytes.
(La figura 90 muestra el proceso mediante el cual se crean los fragmentos de este ejemplo.)

MTU mínima de Internet: 576 Bytes.
Cada router debe ser capaz de fragmentar según la necesidad para manejar datagramas IP de hasta el tamaño de la mayor MTU utilizada por las redes a las que está conectado. También se requiere que los routers manejen MTU mínimas de al menos 576 bytes. Este valor se especifica en el RFC 791, y fue elegido para permitir un bloque de datos de "tamaño razonable" de al menos 512 bytes, además del espacio para el encabezado IP y las opciones estándar. Ya que es el tamaño mínimo especificado en el estándar IP, 576 bytes se ha convertido en un valor común de MTU por defecto utilizado para los datagramas IP. Incluso si un equipo está conectado a través de una red local con un MTU mayor que 576, de todos modos puede optar por utilizar un valor de MTU de 576, para asegurarse que no se requiera de alguna fragmentación adicional en los routers intermedios.

Tenga en cuenta que aun cuando los routers intermedios pueden fragmentar aún más un mensaje IP ya fragmentado, los dispositivos intermedios no reensamblan fragmentos. El reensamblado se realiza sólo por el dispositivo receptor. Esto tiene algunas ventajas y algunas desventajas, como veremos al examinar el proceso de reensamblado.

Descubrimiento del camino (path) MTU.
Al tratar de enviar una gran cantidad de datos, la eficiencia en la transmisión de mensajes se vuelve importante. Cuanto mayor sea cada datagrama IP que enviamos, menor es el porcentaje de bytes empleados en gastos generales, tales como los campos de cabecera. Esto significa que, idealmente, querríamos utilizar una MTU tan grande como sea posible sin que haya fragmentación.
En la determinación de la MTU óptima para el uso de una ruta entre dos dispositivos es necesario conocer el valor de la MTU de todos los eslabones de esa ruta, información que los puntos extremos de la conexión simplemente no tienen. Se puede determinar la MTU de la ruta en general, sin embargo, usando una técnica inteligente llamada descubrimiento del camino (path) MTU. Yo llamo a esta técnica "inteligente", ya que no utiliza ninguna característica especial diseñada para el propósito específico de la determinación de la ruta MTU, sino más bien un mecanismo de informe de errores integrados en TCP/IP el Internet Control Message Protocol (ICMP).

Uno de los tipos de mensajes definidos en ICMPv4 es el Mensaje de Destino Inaccesible (Destination Unreachable), que se devuelve en diversas condiciones en las que un datagrama IP no pueda ser entregado. Una de estas situaciones es cuando un datagrama que se envía es demasiado grande para ser enviado por un router sobre un enlace físico, pero tiene la bandera de no fragmentar (DF Don’t Fragment) establecida para evitar la fragmentación. En este caso, el datagrama será descartado y un mensaje de destino inalcanzable enviado de vuelta a la fuente. Un dispositivo puede explotar esta capacidad mediante pruebas de la ruta con datagramas de diferentes tamaños, para ver que tan grande deben ser antes de que sean rechazados.
El nodo de origen normalmente envía un datagrama que tiene el MTU de su enlace físico local, ya que representa el límite superior a la MTU de cualquier ruta con origen en este dispositivo. Si esto sucede sin errores, entonces sabe que puede utilizar ese valor para los futuros datagramas con ese destino. Si recibe cualquier mensaje de "destino inalcanzable" - "Se necesita fragmentación" o "no fragmentar", significa entonces que algún otro vínculo entre el origen y el destino tiene una MTU más pequeña. Intenta de nuevo con un datagrama de tamaño más pequeño, y continúa así hasta que encuentra el mayor MTU que se pueden utilizar en ese camino.

Cuando un datagrama IP es demasiado grande para la unidad de transmisión máxima (MTU) de la tecnología de capa de datos del enlace subyacente utilizado para la siguiente etapa de su viaje, debe ser fragmentado antes de que pueda ser enviado a través de la red. El mensaje de capa superior que se transmite no se envía en un datagrama IP único, sino más bien divido en trozos llamados fragmentos que se envían por separado. En algunos casos, puede ser necesario fragmentar aun mas estos mismos fragmentos.

Detalles y preocupaciones relativas a la fragmentación.
La fragmentación es necesaria para implementar una capa de red, independiente de los detalles de la capa inferior, pero introduce una complejidad considerable al protocolo IP. Recuerde que IP es un protocolo no fiable, sin conexión. Los datagramas IP pueden tomar cualquiera de varias rutas en su camino desde el origen al destino, y algunos ni siquiera consiguen llegar al destino en absoluto. Cuando fragmentamos un mensaje convertimos un solo datagrama en muchos, lo cual introduce varias cuestiones referidas a:

  • Secuenciación y Colocación: Los fragmentos típicamente se enviará en orden secuencial desde el principio del mensaje hasta el final, pero no necesariamente aparecen en el orden en que fueron enviados. El dispositivo receptor debe ser capaz de determinar la secuencia de los fragmentos para volver a montarlos en el orden correcto. De hecho, algunas implementaciones envían el último fragmento primero, de modo que el dispositivo receptor sabrá inmediatamente el tamaño total del datagrama original completo. Esto hace la gestión del orden de los segmentos sea aun mas sencilla.
  • La separación de mensajes fragmentados: Un dispositivo de origen puede necesitar enviar más de un mensaje fragmentado a la vez, o bien, puede enviar múltiples datagramas que son fragmentados en el camino. Esto significa que el destino puede estar recibiendo múltiples conjuntos de fragmentos que se debe poner de nuevo juntos. Imagine una caja en la que las piezas de dos, tres o más puzzles han sido mezcladas y entenderá el problema.
  • Finalización: El dispositivo de destino tiene que ser capaz de decir cuando ha recibido todos los fragmentos para que sepa cuándo debe comenzar el reensamblado (o cuando renunciar si no recibe todas las piezas).
Para abordar estos problemas y permitir el reensamblado correcto del mensaje fragmentado, IP incluye varios campos en el encabezado del formato IP que transmiten información desde la fuente hasta el destino de los fragmentos. Algunos de ellos contienen un valor común para todos los fragmentos del mensaje, mientras que otros son diferentes para cada fragmento.

El proceso de fragmentación IP: un ejemplo.
El dispositivo que realiza la fragmentación sigue un algoritmo específico para dividir el mensaje en fragmentos para su transmisión. La implementación exacta del proceso de fragmentación depende del dispositivo. Vamos a tomar el mismo ejemplo del tema anterior, un mensaje IP de 12.000 bytes de ancho (incluyendo la cabecera IP de 20 bytes) que necesita ser enviado a través de un enlace con una MTU de 3300. He aquí un método típico de como se podría realizar esta fragmentación (puede encontrar útil la ilustración de la figura 90):
Figura 90: Proceso de fragmentación de un datagrama IPv4.
Clic para ampliar.
En este diagrama, los campos MF y FO de cada fragmento se muestran como referencia. Los campos de datos se muestran a escala (la longitud de cada uno es proporcional al número de bytes en el fragmento.)
  1. Crear el primer fragmento: El primer fragmento se crea tomando los primeros 3300 bytes del datagrama IP de 12.000 bytes. Esto incluye la cabecera original, que se convierte en la cabecera IP del primer fragmento (con ciertos campos modificados como se describe más adelante). Por lo tanto, en el primer fragmento se encuentran 3280 bytes de datos. Esto deja a 8.700 bytes por encapsular (11.980 menos 3.280).
  2. Crear el segundo fragmento: Los siguientes 3280 bytes de datos se toman de los 8700 bytes que quedan luego de construir el primer fragmento, y se combina con una nueva cabecera para crear el fragmento n º 2. Esto deja 5.420 bytes.
  3. Crear el tercer fragmento: El tercer fragmento es creado a partir de los próximos 3.280 bytes de datos, con un encabezado de 20 bytes. Esto deja 2.140 bytes de datos.
  4. Crear el cuarto fragmento: El resto de los 2140 bytes se colocan en el cuarto fragmento, con un encabezado de 20 bytes, por supuesto.
Quiero destacar dos puntos importantes aquí. En primer lugar, la fragmentación IP no funciona encapsulando el mensaje IP original completo en los campos de datos de los fragmentos. Si esto se hiciera, los primeros 20 bytes del campo de datos del primer fragmento contendrían la cabecera IP original. Esta técnica es utilizada por algunos otros protocolos, como el Protocolo PPP Multilink, pero no por IP. La cabecera IP original es "transformada" en la cabecera IP del primer fragmento.
Segundo, note que el número total de bytes transmitidos aumenta: estamos enviando 12.060 bytes (tres veces 3.300, más 2160) en lugar de 12.000. Los 60 bytes adicionales son de las cabeceras adicionales en los fragmentos segundo, tercero y cuarto. (El aumento en tamaño en teoría podría ser aún mayor si los encabezados contienen opciones.)

Campos en el encabezado del datagrama IP relacionados con la fragmentación.
Cuando un dispositivo de origen o router fragmenta un datagrama, debe proporcionar información que permita que el dispositivo receptor sea capaz de identificar los fragmentos y volver a unirlos en el datagrama que se envió originalmente. Esta información es registrada por el dispositivo fragmentador en una serie de campos en la cabecera del datagrama IP.

Longitud total
Después de la fragmentación, este campo indica la longitud de cada fragmento, no la longitud del mensaje en general. Normalmente, el tamaño de los fragmentos se selecciona para que coincida con el valor de la MTU en bytes. Sin embargo, los fragmentos deben tener una longitud que es múltiplo de 8, para permitir la especificación correcta del offset (ver más abajo). El último fragmento por lo general será más corto que los otros, ya que contendrá una pieza "sobrante", a menos que la longitud del mensaje sea un múltiplo exacto del tamaño de los fragmentos.

Identificación
Para resolver el problema del "rompecabezas de muchos rompecabezas en una caja", un identificador único es asignado a cada mensaje que es fragmentado. Considere esto como escribir un número diferente en la parte inferior de cada pieza del rompecabezas antes de echarlo en la caja. Este valor se coloca en el campo de identificación en la cabecera IP de cada fragmento enviado. El campo de identificación es de 16 bits de ancho, por lo que se pueden utilizar un total de 65.536 identificadores diferentes.
Obviamente, queremos asegurarnos de que cada mensaje fragmentado enviado entre el mismo origen y el destino tenga un identificador diferente. La fuente puede decidir cómo generar identificadores únicos. Esto se puede hacer a través de algo tan simple como un contador que se incrementa cada vez que se crea un nuevo conjunto de fragmentos.

Mas fragmentos
Este indicador se ponen a 1 para todos los fragmentos excepto el último, que se pone a 0. Cuando el fragmento con un valor de 0 en el indicador de más fragmentos es reconocido, el destino sabe que ha recibido el último fragmento del mensaje.

Offset del fragmento
Este campo soluciona el problema de la secuenciación de fragmentos, indicándole al dispositivo receptor donde debe ser colocado cada fragmento en particular del mensaje original. El campo es de 13 bits de ancho, por lo que el desplazamiento puede ser de 0 a 8191. Los fragmentos se especifican en unidades de 8 bytes, que es la razón por la que la longitud del fragmento debe ser un múltiplo de 8. No es coincidencia que 8191 * 8 sea 65.528, casi el tamaño máximo permitido para un datagrama IP.

Tomemos el mismo ejemplo anterior. El primer fragmento tendrá un desplazamiento de fragmento de 0. El segundo tendría un desplazamiento de 410 (3280 dividido entre 8). El tercero tendría un desplazamiento de 820 (6.560 dividido entre 8). El cuarto tendría un desplazamiento de 1230.

Concepto clave: Cuando un requisito MTU fuerza a un datagrama a ser fragmentado, este se divide en varios pequeños datagramas IP, cada uno conteniendo parte del original. La cabecera del datagrama original se transforma en la cabecera del primer fragmento, y se crean nuevas cabeceras para los otros fragmentos. Cada uno se marca con idéntico valor de identificación para identificarlo como parte del mismo datagrama original. El desplazamiento del fragmento de cada uno se establece en el lugar donde el fragmento pertenece a la original. El campo más fragmentos se establece en 1 para todos los fragmentos excepto el último, para que el destinatario sepa cuando haya recibido todos los fragmentos.

Banderas en la cabecera IP relacionadas con la fragmentación.
Además de los campos anteriores, hay un par de banderas en la cabecera IP relacionadas con la fragmentación.

La bandera de copiado
Si un datagrama que contiene opciones debe ser fragmentado, algunas de las opciones deben ser copiadas a cada uno de los fragmentos. Esto es controlado por la bandera de copiado en cada campo de opción.

Bandera de no fragmentar.
Este indicador se puede establecer en 1 por un dispositivo de transmisión para especificar que un datagrama no sea fragmentado en su tránsito. Esto puede ser usado en ciertas circunstancias cuando el mensaje debe entregado intacto dado que las piezas no tendrían sentido. También se puede utilizar si el dispositivo de destino tiene una implementación IP limitada y no puede volver a montar los fragmentos, y también se utiliza para probar la unidad de transmisión máxima (MTU) de un enlace. Normalmente, sin embargo, los dispositivos no se preocupan por la fragmentación y el campo se deja en cero.
¿Qué sucede si un router encuentra un datagrama demasiado grande para atravesar la siguiente red física, pero tiene el bit No fragmentar establecido a 1? No se puede fragmentar el datagrama y tampoco se puede transmitir, por lo que está "atascado". Por lo general, se descartará el datagrama, a continuación, se envía un mensaje de error especial ICMP de destino inalcanzable: "se necesita fragmentar y el bit de no fragmentar esta establecido". Esto se utiliza en el Descubrimiento de la ruta MTU como se describe en la sección anterior.

Cuando un datagrama está fragmentado, ya sea por el dispositivo de origen o por uno o más routers que transmiten los datagramas, se convierte en datagramas de múltiples fragmentos. El destino del mensaje general debe reunir estos fragmentos y luego volverlos a montar en el mensaje original. El reensamblaje se realiza mediante el uso de la información especial en los campos que vimos en el tema anterior que nos ayudan a "poner el rompecabezas junto de nuevo".

La asimetría de la fragmentación y el reensamblado.
Es importante entender que mientras que el reensamblado es el complemento de la fragmentación, los dos procesos no son simétricos. Una diferencia principal entre ambos es que mientras que los routers intermedios pueden fragmentar un datagrama o fragmentar aun más un datagrama que ya está fragmentado, estos dispositivos intermedios no realizan el reensamblado. Esto se hace sólo por el destinatario final del mensaje IP. Por lo tanto, si un router intermedio de un lado de una red física con una MTU de 1.300 causa la fragmentación de un datagrama de 3.300 bytes, el router en el otro extremo de este enlace no va a restaurar el datagrama de 3.300 bytes a su estado original. Enviará todos los fragmentos de 1300 bytes por internet, como se muestra en la Figura 89.

Hay una serie de razones por las cuales se tomó la decisión de implementar el reensamblado IP de esta manera. Tal vez el más importante es que los fragmentos pueden tomar distintas rutas para llegar desde el origen al destino, por lo que cualquier router dado puede no ver todos los fragmentos en un mensaje. Otra razón es que hacer que los routers se ocupen de reensamblar fragmentos incrementaría su complejidad. Por último, como veremos, el reensamblado de un mensaje requiere esperar por todos los fragmentos antes de enviar el mensaje reensamblado. Hacer esto alentaría demasiado el funcionamiento de los routers. Ya que los routers no reensamblan puede enviar todos los fragmentos inmediatamente hacia destinatario final.
Sin embargo, también hay desventajas a este diseño. Una de ellas es que se traduce en más fragmentos más pequeños que viajan por rutas más largas que si se hiciera el reensamblado intermedio. Esto aumenta las posibilidades de que se pierda un fragmento y todo el mensaje se descarte. Otra es una ineficiencia potencial en la utilización de la capacidad de las tramas de la paca de enlace de datos. En el ejemplo anterior, los fragmentos de 1.300 bytes no se reensamblan en un datagrama de 3300 byte al final del enlace de 1000 de MTU. Si el enlace siguiente, también tiene una MTU de 3300, tendría que enviar tres tramas, cada una encapsulando un fragmento de 1.300 bytes, en lugar de una sola trama más grande, lo cual es algo más lento.

Concepto clave: En IPv4, la fragmentación puede ser realizada por un router entre el origen y el destino de un datagrama IP, pero el montaje se realiza sólo por el dispositivo de destino.

El proceso de reensamblado.
Como vimos en el estudio de cómo funciona la fragmentación, esta implica alguna complejidad. Varios campos de la cabecera IP se llenan cuando un mensaje se fragmenta para dar al dispositivo receptor la información que necesita para volver a ensamblar correctamente los fragmentos. El dispositivo receptor sigue un procedimiento para realizar un seguimiento de los fragmentos a medida que se reciben y construir su copia del mensaje total recibido desde el dispositivo fuente. La mayor parte de sus esfuerzos se orientan en torno a lidiar con las dificultades potenciales asociadas al hecho de que IP es un protocolo no fiable.

Los detalles de implementación del proceso de montaje son específicos para cada dispositivo, pero en general incluyen las siguientes funciones:

  • Reconocimiento de fragmento e identificación del mensaje fragmentado: El receptor sabe que ha recibido un fragmento del mensaje la primera vez que ve un datagrama con el bit de "mas fragmentos" a uno o el offset del fragmento con un valor distinto de cero. Se identifica el mensaje en función de: las direcciones IP de origen y destino, el protocolo especificado en la cabecera, y el campo de identificación generado por el remitente.
  • Inicialización de búfer: El dispositivo de recepción inicializa un buffer donde puede almacenar los fragmentos del mensaje, a medida que son recibidos. Se realiza un seguimiento de qué partes de este buffer se llenan de los fragmentos recibido, quizá mediante una tabla especial. De esta manera, sabe cuando el buffer está parcialmente lleno con fragmentos recibidos y cuando está completamente lleno.
  • Inicialización del temporizador: El dispositivo receptor establece un temporizador para reensamblar el mensaje. Dado que es posible que algunos fragmentos nunca aparezcan, el contador asegura que el dispositivo esperará "por siempre" tratando de montar de nuevo el mensaje.
  • Recepción y procesamiento de fragmento: Siempre que un fragmento de este mensaje llegue (lo que es indicado por tener direcciones IP de origen y destino iguales, protocolo e identificación como el primer fragmento), el fragmento se procesa. Se inserta en el buffer de mensaje en el lugar indicado por su campo de offset del fragmento. El dispositivo también tiene en cuenta el hecho de que esta parte del mensaje ha sido recibida.
El reensamblado se termina cuando todo el búfer se ha llenado y el fragmento con el bit de "mas fragmentos" a cero es recibido, lo que indica que es el último fragmento del datagrama. El datagrama reensamblado se procesa como se haría con un fragmento normal sin fragmentar. Por otro lado, si el temporizador de ensamblado expira y aun falta fragmentos, el mensaje no puede ser reconstruido. Los fragmentos se descartan, y se genera un mensaje ICMP de tiempo excedido. Puesto que IP no es fiable, se basa en protocolos de nivel superior como TCP para determinar que el mensaje no se ha recibido correctamente y retransmitirlo en consecuencia.
Regresar al contenido.