Seguramente se dieron cuenta que existen algunos campos en el header IP, que no son muy estudiados y comentados, estos campos son Identification, Flags y Fragment Offset. Estos campos nos ayudan en el proceso de la fragmetanción del datagrama IP del cual hablaremos en esta entrada del blog.
Estos 3 campos los podemos ver en la imagen 1.
MTU
Antes de hablar del proceso de la fragmentación, es importante conocer el termino MTU. El Maximun Transfer Unit o MTU, es el tamaño máximo que puede tener el payload de una trama de la capa de Acceso a la red al enviarse físicamente por una interface. En la imagen 2 te mostramos los campos que componen el MTU en el proceso de encapsulación, está compuesto por el header de la capa de Internet, el header de la capa de Transporte y los datos de la capa de Aplicación, no se toma en cuenta el header y el trailer de la capa de Acceso a la red.
El MTU tiene un tamaño determinado de acuerdo al protocolo de capa 2 que se esté utilizando. En la tabla 1 te mostramos algunos de los MTUs más comunes.
Como ejemplo, en la imagen 3, se está utilizando el protocolo de capa 2 Ethernet para la conexión entre la computadora y el router, por lo tanto el payload de la trama tiene que ser menor o igual a 1500 bytes.
¿De qué depende el tamaño del MTU?
Lo más tentador, es enviar el datagrama IP más grande dentro de la trama Ethernet, ¿no es cierto?, ¿por qué limitar el tamaño del datagrama de la trama a 1500 bytes si estamos utilizando Ethernet? porque no enviar 5000 bytes… o 10000 bytes, por más que parezca lógico, todo tiene una razón de ser.
Imaginen esta situación, supongamos que tenemos un enlace propenso a fallas a través del cual viajan las tramas de un tamaño de 20000 bytes, mientras más grande es la trama, más posibilidades existen que se pierdan los datos de esa trama. Si una trama se pierde, gracias a TCP se la vuelve a enviar, lo significa que tenemos que volver a enviar 20000 bytes de datos a través de un enlace propenso a errores, y esto provoca una ineficiencia en la transmisión a medida que más tramas se pierden y se reenvían.
Por el otro lado, ¿por qué no nos conviene enviar tramas con datagramas de tamaño pequeño?, enviar muchas tramas con datagramas pequeños, provoca que los dispositivos de red tengan que analizar muchos headers de las diferentes capas y las diferentes tramas.
Tomando en cuenta las anteriores situaciones, el MTU se elige de acuerdo a la mayor EFICIENCIA que pueda tener cierto protocolo de capa 2, para enviar tramas de un tamaño adecuado, sin añadir sobrecarga de procesamiento en los dispositivos al analizar todos los diversos headers que tienen las tramas
¿Qué es la fragmentación?
Consideremos los siguientes escenarios.
En la topología de la imagen 4, podemos ver que el MTU es el mismo en los 3 saltos, se esta utilizando el protocolo Ethernet en la capa de Acceso a la red, por lo tanto el MTU es 1500 bytes. La computadora PC1 quiere comunicarse con la computadora PC2, y supongamos que los datagramas que se encuentran dentro de las tramas, tienen un tamaño igual a 1500 bytes. Por lo tanto las tramas pueden enviarse sin ningún problema a través de todos los enlaces de la topología y la comunicación se completa
Ahora veamos esta segunda situación en la imagen 5. La computadora PC1 quiere comunicarse con la computadora PC2. En el enlace a través del cual viajan las tramas desde el router R1 al router R2, se está utilizando un protocolo de capa de Acceso a la red que tiene un tamaño de MTU de 620 bytes. Eso quiere decir que el datagrama de 1500 bytes generado por la computadora PC1, no podrá ser enviado por ese enlace a no ser que se «Fragmente», en otras palabras, el datagrama encapsulado por la trama, tendrá que ser dividido en pedazos manejables por ese enlace entre el router R1 y el router R2. Es decir se tendrán que construir tramas con datagramas no mayores a 620 bytes
Nota: Estamos tomando en cuenta que no existe el MSS, PMTU u otras tecnologías que ayudan a evitar la fragmentación.
Siguiendo con la imagen 5, si en alguna situación, el MTU desde el router R2 a la computadora PC2 fuera menor a 620 bytes, el datagrama encapsulado por la trama que se envia desde el router R1 al router R2, tendría que volver a fragmentarse una segunda vez.
Proceso general de la fragmentación
» Cuando un dispositivo tiene que enviar un datagrama IPv4, tiene que determinar la interface a través de la cual debe ser enviada. Lógicamente esto se logra a través del proceso de enrutamiento.
» Cuando la interface de salida es definida, se compara el MTU de la interface con el tamaño del datagrama. Si el tamaño del datagrama IPv4 es mayor, se procede a realizar la fragmentación.
» Cuando un datagrama IPv4 es fragmentado, solo el dispositivo de destino del paquete IPv4 puede volver a ensamblarlo. En el caso de la imagen 5. Los fragmentos no pueden ensamblarse por el router R2, sino por el dispositivo final PC2.
Nota: Solo en el primer fragmento del datagrama IP, se tiene el header de la capa de transporte.
Según la imagen 5, tenemos que fragmentar el datagrama IPv4 de 1500 bytes en el router R1.
Nota: Según la literatura que estén siguiendo, los terminos datagrama y paquete son usados de manera indistinta, sin embargo cuando se explica el proceso de fragmentación, generalmente se utiliza la palabra datagrama, para identificar al componente existente ANTES del proceso de la fragmentación, y el termino paquete, es utilizado para referirse a los pedazos que se obtienen cuando se fragmenta un datagrama (paquete = después de la fragmentación).
Campos necesarios en la fragmentación
Para realizar el proceso de la fragmentación se necesitan los campos mencionados en la imagen 1.
Campo «Identification».
Este campo tiene un tamaño de 16 bits y sirve para identificar a los paquetes resultantes del proceso de la fragmentación. Se asignara el mismo número a todos los paquetes obtenidos de manera que el dispositivo final, pueda identificar todos los paquetes que pertenecen a un datagrama para poder ensamblarlos.
Campo «Flags»
Tiene un tamaño de 3 bits, donde cada bit representa un «flag».
– El primero de los bits flags no se utiliza y siempre tiene un valor de 0.
– El segundo bit lleva la denominación de «Don’t Fragment (DF)» y se utiliza para indicar al dispositivo que ese datagrama NO debe ser fragmentado en su trayecto al dispositivo final. En el caso de la imagen 5, si el router R1 recibe un datagrama con el bit DF con un valor de 1, significa que ese router no debe fragmentar ese datagrama. Sin embargo, como su MTU para enviarlo al router R2 es menor, y el datagrama indica que no se debe fragmentar, como resultado se descarta el datagrama y se envía un mensaje de notificación al dispositivo de origen.
– El tercer bit lleva la denominación de «More Fragments (MF)», sirve para indicar que existen más paquetes por ser recibidos. Si el valor es 0, hace referencia a que ese paquete es el último «pedazo» correspondiente al datagrama.
Campo «Fragment Offset»
Tiene un tamaño de 13 bits y se utiliza para ensamblar nuevamente el datagrama IP. Almacena valores múltiplos de 8 de manera que se pueda llegar al tamaño máximo de un datagrama IP (65536).
Ejercicio fragmentación
De acuerdo a la imagen 5, el paquete que se va a enviar desde la computadora PC1 hasta la computadora PC2, es el que vemos en la imagen 6.
Cuando el datagrama viaja de la PC1 al router R1 no existen problemas, cuando el datagrama tiene que ser enviado desde el router R1 al router R2, debe fragmentarse.
Generalmente se realiza la división del datagrama, en paquetes que tienen un tamaño similar al MTU a través del cual deben ser transportados, el primer paquete IP lo tenemos en la imagen 7 y tiene un tamaño de 620 bytes que es igual al MTU.
El campo Identification tiene el valor de 2000, este valor es el mismo para todos los paquetes que corresponden a un datagrama. El campo flag MF tiene un valor de 1 y sirve para indicar al dispositivo de red, que todavía se tienen más paquetes que corresponden al datagrama. Finalmente tenemos en el campo Fragment Offset un valor 0, un valor de 0 indica que se trata del primer paquete del datagrama IP.
Según lo mencionado, el header UDP solo se presenta en el primer paquete del datagrama.
El siguiente paquete lo vemos en la imagen 8 y tiene un tamaño de 620 bytes igual al MTU.
El campo Identification tiene el valor de 2000, este valor es el mismo para todos los paquetes que corresponden a un datagrama fragmentado. El campo flag MF tiene un valor 1 e indica que no se trata del último paquete correspondiente al datagrama. Finalmente tenemos en el campo Fragment Offset el valor de 75, este valor se calcula con la siguiente formula:
[(tamaño total del paquete IP anterior - Header IP)/8] + (sumatoria de valores "Fragment offset" anteriores)
(620-20)/8 + 0 = 75
El último paquete correspondiente al datagrama lo vemos en la imagen 9.
El campo Identification tiene el valor de 200, este valor es el mismo para todos los paquetes que corresponden a un datagrama fragmentado. El campo flag MF tiene un valor 0 e indica que se trata del último fragmento correspondiente al datagrama. Finalmente tenemos en el campo Fragment Offset el valor 150, este valor se calcula con la misma formula:
[(tamaño total del paquete IP anterior - Header IP)/8] + (sumatoria de valores "Fragment offset" anteriores)
(620-20)/8 + 0 = 150
Ya tenemos los 3 paquetes en el dispositivo de destino, se emsamblan los paquetes, y para verificar el tamaño total del datagrama, utilizamos la siguiente formula:
(Fragment offset del último paquete *8 ) + Tamaño total del último paquete IP
Esto nos da como resultado:
[150*8] + 300 = 1500 (incluyendo el header IP y el header UDP)
Esperamos que el presente artículo haya sido de tu agrado!
¿Te quedaron dudas?
No te preocupes e inscribite a nuestro curso!
¡Muchas gracias por este artículo! Me ha sido de gran ayuda.
Solo un pequeño apunte: creo que hay una errata en esta línea: (620-20)/8 + 0 = 150 (faltaría incluir 75 como sumatoria de valores «Fragment offset» anteriores).