Modelo del protocolo TCP-IP

Objetivos

Dar a conocer la función de cada una de las capas que forman parte del protocolo TCP IP.

Introducción

Una red de computadoras es el enlace entre dos o más computadoras. Dicha red se caracteriza por la interacción de elementos de hardware y software con el fin de proveer un servicio de voz, datos o video al usuario.

Los elementos de hardware permiten el enlace entre computadoras y la distancia que existe entre computadoras o grupos de computadoras nos sirve para determinar la escala de una red.

En una red de escala local "LAN" todas las computadoras que conforman la red se encuentran en un mismo cuarto, edificio o campo. Una red de escala metropolitana "MAN" se caracteriza por el enlace de redes locales situadas en un área determinada, por ejemplo una ciudad. Una red de escala amplia "WAN" está caracterizada por el enlace de redes locales y metropolitanas que pueden estar localizadas en diferentes ciudades o países. Finalmente, una red de escala mundial "Internet" se caracteriza por el enlace de redes WAN, MAN y LAN.

En la figura 1.1 podemos observar la estructura de la red Internet la cual está caracterizada por la interconexión de múltiples sistemas autónomos "Autonomous System AS". Un sistema autónomo puede estar compuesto por redes LAN, MAN y WAN.

Figura 1.1 Estructura genérica de la red Intenet

Los elementos de software son los pasos "Protocolos" a seguir para el envío y recepción de datos entre aquellas computadoras que están ofreciendo un servicio de comunicación al usuario, bien sea de voz, datos o video.

Modelo del protocolo TCP-IP

El protocolo TCP-IP es el protocolo standard de la red Internet. Este protocolo está compuesto por las siguientes capas: Capa de aplicación, Capa de Transporte, Capa de Enrutamiento y Capa de interfase. El sistema operativo ejecuta los procesos de la capa de aplicación con privilegio de usario y los procesos que pertenecen a las capas "transporte, enrutamineto e interfase" son ejecutados con privilegio Kernel. En la figura 1.2 podemos observar el diagrama en bloques del modelo TCP-IP.

Figura 1.2 Diagrama en bloques del modelo TCP-IP

Capa de aplicación

La función de la capa aplicación es la de proveer servicios de comunicación a las aplicaciones. Un ejemplo es el protocolo http "Hypertext transfer protocol" el cual provee servicios de recobro y envío de páginas webs a las aplicaciones capaces de interpretar el código HTML contenido en dichas páginas.

Capa de transporte

La capa de transporte ofrece a la capa de aplicación dos servicios y es la responsable del envío y la recepción de los segmentos de datos de la capa de aplicación. Un servicio consiste en el envío y recepción de datos orientado a conexión y el otro consiste en el envío y recepción de datos no orientados a conexión. El protocolo TCP "Transmition Control Protocol" de la capa de transporte es un servicio orientado a conexión. La unidad de datos que envía o recibe el protocolo TCP es conocido con el nombre de segmento TCP. El protocolo UDP "User Datagram Protocol" de la capa de transporte es un servicio no orientado a conexión. La unidad de datos que envía o recibe el protocolo UDP es conocido con el nombre de datagrama UDP.

Capa de enrutamiento

La capa de enrutamiento es la responsable de proveer los siguientes servicios a la capa de transporte:

-. Establecer el sistema de direccionamiento lógico de la red.-. Enrutamiento de paquetes. Si un paquete que va a ser enrutado excede la máxima unidad de transferencia "Maximun Transfer Unit MTU" de un enlace esta capa fragmenta el paquete con el fin de adaptarse al MTU del enlace y el paquete es ensamblado en el computador destino.

Durante el proceso de enrutamiento se hace uso de un servicio de conexión no orientado para el envío y recepción de paquetes. Esta capa está compuesta por los protocolos: IP, ARP, ICMP. El protocolo IP "Internet Protocol" ofrece el servicio de direccionamiento lógico de la red TCP-IP y el de enrutamiento de paquetes. El protocolo ARP "Address Resolution Protocol" ofrece el servicio de resolución de direcciones IP con su respectiva dirección física. Y el protocolo ICMP "Internet Control Message Protocol" ofrece el servicio de reporte de errores que pueden ocurrir durante el enrutamiento de paquetes.

La unidad de datos que envía o recibe el protocolo IP se conoce con el nombre de datagrama IP.

Capa de interfase

La capa de interfase está compuesta por dos capas. La capa de enlace y la capa física. La capa de enlace es responsable de proveer los siguientes servicios a la capa de enrutamiento:

-. Delimita el principio y fin de los frames a ser enviados.-. Establece el sistema de direccionamiento físico de la red.-. Detecta los errores de envío o recepción de información entre dos o más computadoras.

La capa de enlace puede ofrecer un servicio de conexión orientado o un servicio de conexión no orientado. Los protocolos HDLC, PPP, LLC son ejemplos de protocolos de la capa de enlace.

La función de la capa física es la de hacer uso de la línea de transmisión para el envío y la recepción de los bits contenidos en un frame. Los protocolos Ethernet y Token Ring son ejemplos de protocolos de la capa física. La unidad de envío o recepción de datos de la capa física se conoce con el nombre de frame.

Comunicación entre capas

En la figura 1.3 podemos observar que el envío y recepción de datos entre dos aplicaciones es un proceso de intercambio de datos entre capas iguales, basado en un modelo cliente - servidor. La aplicación del computador 1 es una aplicación cliente "Browser / Navegador" que hace uso del protocolo "HTTP" de la capa de aplicación y la aplicación del computador 2 es una aplicación de servicios de páginas webs que hace uso del demonio HTTPD.

Figura 1.3 Comunicación entre capas

Cuando la aplicación cliente requiere de los servicios de la aplicación servidor "HTTPD", dicha aplicación solicita los servicios de red al sistema operativo a través de una interfaz de programación de servicios TCP-IP "API socket BSD". Un socket es un descriptor que un proceso cliente utiliza para establecer una conexión e intercambiar datos con el proceso servidor. Este descriptor sirve para identificar: el protocolo, el proceso - cliente, la dirección - cliente, el proceso - servidor y la dirección - servidor. Una vez establecida la conexión virtual entre el proceso cliente "Navegador - HTTP" y el proceso servidor "HTTPD" pueden comenzar con el intercambio de datos.

Es importante mencionar que durante el seminario no analizaremos la interfase de programación de servicios TCP-IP "API Socket BSD" ya que no es el objetivo del seminario.

Las aplicaciones cliente servidor dependen de los servicios de las capas de aplicación, transporte, enrutamiento y enlace. Cuando una aplicación hace uso de los servicios de la capa de aplicación para el envío de datos, cada capa debe de incluir: los parámetros del protocolo de comunicación entre capas adyacentes y los parámetros del protocolo de comunicación entre capas iguales. Una vez que cada capa haya incluido los parámetros antes mencionados, los datos de la aplicación estarán encapsulados. Y cuando los datos encapsulados llegan al computador destino un proceso de de-encapsulamiento ocurre en cada capa estableciendo de esta manera la comunicación virtual entre capas iguales.

En la figura 1.4 podemos observar que los servicios que ofrecen cada una de las capas determinan la manera como los datos de la aplicación son enviados y recibidos entre capas iguales.

Figura 1.4 Servicios que ofrece una capa

El servicio que ofrece una capa puede ser de cuatro tipos:

-. Servicio orientado a conexión.-. Servicio no orientado a conexión.-. Servicio de conexión punto a punto.-. Servicio de conexión de salto en salto.

Servicio orientado a conexión

Un servicio de conexión orientado se caracteriza por la iniciación de la conexión previa al envío y/o a la recepción de información entre capas iguales. Una vez iniciada la conexión ambas capas pueden comenzar a enviar y/o recibir los datos de la aplicación. Un servicio de conexión orientado es diseñado para corregir errores que pueden ocurrir durante el envío y/o recepción de datos, como también es diseñado para controlar el flujo de envío y recepción de datos.

Servicio no orientado a conexión

Un servicio de conexión no orientado se caracteriza por el envío y recepción de datos sin la previa iniciación de la conexión entre capas iguales. Es un servicio que no está diseñado para corregir errores que puedan ocurrir durante el envío y/o recepción de datos ya que este tipo de servicio es utilizado cuando la probabilidad de error durante en el envío y/o recepción de datos es prácticamente nula. Tampoco está diseñado para controlar el flujo de envío y recepción de datos.

Servicio de conexión punto a punto

Un servicio de conexión punto a punto consiste en no modificar lo parámetros de control de una capa durante el proceso de enrutamiento de los datos. Por ejemplo el protocolo TCP de la capa de transporte es un servicio de conexión orientado a conexión y es un servicio de conexión punto a punto ya que los parámetros de control generados por esta capa no son modificados durante el proceso de enrutamiento.

Servicio de conexión de salto en salto

Un servicio de conexión de salto en salto consiste en que los parámetros de control de una capa son modificados durante el proceso de enrutamiento de los datos. Por ejemplo el protocolo IP de la capa de enrutamiento es un servicio de conexión no orientado a conexión y es un servicio de conexión de salto en salto ya que los parámetros de control generados por esta capa son modificados durante el proceso de enrutamiento.

En la figura 1.5 se presenta un modelo genérico de un servicio orientado a conexión. En él se puede observar que una vez que el computador 2 haya recibido el paquete de datos enviado por el computador uno, el computador 2 envía un

paquete de control indicando que el paquete fue recibido sin errores y que puede proceder a enviar el siguiente paquete. Con el fin de evitar ambigüedades durante el flujo de datos entre la capa n del computador 1 y la capa n del computador 2, es necesario que cada paquete de datos esté identificado por un número de secuencia. Dicho número en conjunto con los parámetros de control de flujo sirve para controlar el flujo de envío y/o recepción de datos entre capas iguales.

El algoritmo de control de flujo debe ser lo suficientemente robusto a fin de evitar momentos de congestión. Se dice que un momento de congestión ocurrió cuando el buffer de datos recibidos por el computador 1 ó 2 se encuentra completamente lleno. Si el momento de congestión persiste, los datos recibidos no pueden ser procesados.

Figura 1.5 Modelo genérico de un servicio orientado a conexión

Conclusiones

-. Una red de computadoras se caracteriza por la interacción de elementos de hardware y software con el fin de proveer un servicio de voz, datos o video al usuario. Los elementos de hardware permiten el enlace entre computadoras. En cambio, los elementos de software son los pasos o "protocolos" a seguir para el envío y recepción de datos entre computadoras.

-. El protocolo TCP-IP es el protocolo standard de la red Internet. Este protocolo está compuesto por las siguientes capas:

-. Capa de aplicación.-. Capa de transporte.-. Capa de enrutamiento.-. Capa de interfase.

-. Cuando la aplicación cliente requiere de los servicios de la aplicación servidor, dicha aplicación solicita los servicios de red al sistema operativo a través de una interfaz de programación de servicios TCP-IP "API socket BSD".

-. Un socket es un descriptor que un proceso cliente utiliza para establecer comunicación con el proceso servidor. Este descriptor sirve para identificar: el protocolo, el proceso - cliente, la dirección - cliente, el proceso - servidor y la dirección - servidor.

-. Cuando una aplicación hace uso de los servicios de la capa de aplicación para el envío de datos cada capa debe incluir: los parámetros del protocolo de comunicación entre capas adyacentes y los parámetros del protocolo de comunicación entre capas iguales. Una vez que cada capa haya incluido los parámetros antes mencionados, los datos de la aplicación se encuentran encapsulados por los parámetros de control de cada capa. Cuando los datos encapsulados llegan al

computador destino ocurre un proceso de de-encapsulamiento en cada capa estableciendo de esta manera la comunicación entre capas iguales.

-. Los servicios que ofrecen cada una de las capas determinan la manera como los datos de la aplicación son enviados y/o recibidos entre capas iguales. El servicio que ofrece una capa puede ser de cuatro tipos:

-. Servicio orientado a conexión.-. Servicio no orientado a conexión.-. Servicio de conexion punto a punto.-. Servicio de conexion de salto en salto.

-. Se dice que un momento de congestión ocurrió cuando el buffer de datos recibidos se encuentra completamente lleno. Sí el momento de congestión persiste, los datos recibidos no pueden ser procesados.

En las siguientes secciones analizaremos:

-. Los parámetros de comunicación entre protocolos adyacentes y los parámetros del protocolo de comunicación entre capas iguales del protocolo TCP-IP.-. El proceso de encapsulamiento y de-encapsulamiento de datos a partir de los datos a ser transmitidos por una aplicación.-. Los protocolos que analizaremos son: TCP, UDP, IP, ARP, ICMP y los protocolos de resolución de nombres por direcciones IP: archivo hosts y Domain Name System DNS.

Referencias Bibliográficas

RFC 1180, "A TCP/IP Tutorial".

Day, J.D., and Zimmermann, H.: "The OSI Reference Model", Proc. of the IEEE, vol. 71, pp1334-1340, Dec. 1983.

W. Richard Stevens, Unix Network Programming. Prentice-Hall 1990, ISBN 0-13-949876-1.

W. Richard Stevens, TCP/IP Ilustrated Volume 1, The protocols. Prentice-Hall 1994, ISBN 0-201-63346-9.

Capa de transporte del protocolo TCP-IP

Luciano PoloCopyright © 2000. Luciano Polo. Tutorial protegido por la GLP.

Objetivos

Dar a conocer la bases de la capa de transporte del protocolo TCP-IP el cual está compuesto por el protocolo orientado a conexión TCP y el protocolo no orientado a conexión UDP. Durante el análisis del protocolo TCP se analizan los siguientes mecanismos: Multiplexamiento, Conexiones, Fiabilidad y Control de flujo y congestión.

Protocolo TCP

La capa de transporte ofrece a la capa de aplicación dos servicios: un servicio orientado a conexión protocolo TCP "Transmition Control Protocol" y un servicio no orientado a conexión protocolo UDP "User Datagram Protocol". La unidad de envío o recepción datos del protocolo TCP se conoce con el nombre de segmento TCP y la unidad de envío o recepción de datos del protocolo UDP es conocido como datagrama UDP.

La función protocolo TCP consiste en ofrecer un servicio de envío y recepción de datos orientado a conexión que sea seguro y que goce de los siguientes mecanismos:

-. Multiplexamiento.-. Conexiones.-. Fiabilidad.-. Control de flujo y congestión.

En la figura 1.1 podemos observar la cabecera del protocolo TCP cuyos parámetros de control son utilizados para satisfacer los mecanismos mencionados anteriormente.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Puerto de origen | Puerto de destino |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Número de secuencia |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Número de acuse de recibo |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Posic | |U|A|P|R|S|F| |

| de los| Reservado |R|C|S|S|Y|I| Ventana |

| datos | |G|K|H|T|N|N| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Suma de control | Puntero urgente |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Opciones | Relleno |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Datos |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 1.1 Cabecera del protocolo TCP-IP

Macanismo de multiplexamiento

El mecanismo de multiplexamiento consiste en que más de una aplicación pueda utilizar los servicios del protocolo TCP. El protocolo TCP hace uso de los parámetros de control: Puerto destino y Puerto origen incluidos en una cabecera TCP y los parámetros de control: Dirección IP Destino y Dirección IP Origen incluidos en una cabecera IP con el fin de satisfacer el mecanismo de multiplexamiento.

Cuando los números de puerto son concatenados con las direcciones IP de la capa de enrutamiento, conforman lo que se denomina un conector "socket". Un par de conectores identifica de forma única la conexión bidireccional entre una aplicación cliente y una aplicación servidor.

En la figura 1.2 podemos apreciar como una computadora con dirección IP 10.1.1.1 y una computadora con dirección IP 10.1.1.2 tienen establecidas dos conexiones TCP. Una conexión TCP donde la aplicación navegador de la computadora 10.1.1.1 hace uso del protocolo http de la capa de aplicación, puerto 1130 para el recobro o envío de páginas webs almacenadas en el servidor HTTPD puerto 80 y la aplicación cliente Telnet hace uso del puerto 1700 para recibir o enviar datos del servidor de servicios Telnet puerto 23.

Aplicaciones

IP: 10.1.1.1 IP: 10.1.1.2

Navegador Telnet HTTPD Servidor Telnet

| | | |

_______|______________|____ ______|______________|_____

Puerto 1130 Puerto 1700 Puerto 80 Puerto 23

\ / | \ / ^

\ / | \ / |

------------- flujo ---------------- flujo

Pila |multiplexor| de |de-multiplexor| de

TCP-IP ------------- datos ---------------- datos

| | | |

| v --> | |

|__________________________________|

Figura 1.2 Mecanismo de multiplexamiento

Los puertos de las aplicaciones que ofrecen servicios a las aplicaciones clientes han sido estandarizados y se conocen con el nombre de "puertos bien conocidos". La organización que controla y estandariza el número de un puerto es la IANA "Internet Assigned Numbers Authority".

El número de puerto de una aplicación está definido por un registro de 16 bit "parámetro de control Puerto destino y/o puerto origen", esto implica un rango de puertos que va de 0 a 65535 puertos. El rango de puertos que va de 0 a 1023 son conocidos con el nombre de puertos privilegiados. Los procesos que hacen uso de estos puertos son ejecutados con privilegio root.

En un encabezado TCP el número de puerto que refleja el parámetro puerto origen es el número de puerto de la aplicación que está enviando los datos. Y el número de puerto que refleja el parámetro puerto destino es el número de puerto de la aplicación destino.

Mecanismo de conexión

Como el protocolo TCP es un protocolo orientado a conexión, es necesario iniciar y mantener la información del estado para cada conexión TCP. Cada conexión queda identificada de forma única por un par de conectores que corresponden con sus dos extremos "Socket".

Cuando dos procesos "cliente/servidor" desean comunicarse, el protocolo TCP debe establecer primero una conexión (inicializar la información de estado en cada lado) y cuando la comunicación se ha completado, la conexión se termina con la intención de liberar recursos en el sistema.

Como las conexiones tienen que establecerse entre "computadoras, enrutadores, etc." y sobre un servicio no orientado a conexión ofrecido por la capa de enrutamiento, el protocolo TCP utiliza un mecanismo de acuerdo que usa números de secuencia para la inicialización de las conexiones.

Los parámetros de control utilizados para iniciar, reiniciar y finalizar una conexión TCP son:

-. SYN: Es utilizado para sincronizar el número de secuencia de los segmentos a ser enviados o recibidos.-. FIN: Este parámetro es utilizado para notificar al receptor que los datos recibidos son los últimos datos enviados por el emisor y su función es la de notificar el cierre de la conexión.-. RST: La función del parámetro RST es la de reiniciar la conexión.-. ACK: La función del paránetro ACK es la de hacer valedera el parámetro: número de acuse recibido.-. Número de secuencia: Indica el número de secuencia del segmento. Si el parámetro SYN es igual a uno lógico este campo refleja el número de secuencia inicial.-. Número de acuse recibido: Si el bit de control ACK es igual a uno lógico, este campo contiene el valor del siguiente número de secuencia que el emisor del segmento espera recibir y a su vez indica que el segmento anterior fue recibido sin errores.-. Ventana: Es el número de octetos de datos que el receptor de este segmento está dispuesto a aceptar, contados a partir del número indicado en el campo de "Número de acuse de recibo".-. Opciones: EL campo de opciones puede ocupar un espacio al final de la cabecera de TCP pero siempre de una longitud múltiplo de 8 bits. La opción más común es el parámetro: tamaño máximo del segmento "MSS". Si esta opción está presente, entonces indica el tamaño máximo de segmento que puede recibir el módulo de TCP que envía este segmento. Este campo debe enviarse únicamente en la petición inicial de conexión. Si esta opción no está presente en una cabecera TCP por defecto el MSS es igual a 556 Byte = 536 Byte "Payload" + 20 Byte "Cabecera TCP".

En el ejemplo que se muestra en la figura 1.3 podemos observar los pasos necesarios para iniciar una conexión TCP.

Computador / Cliente Computador / Servidor

1. Cerrado Espera

2. SYN-Enviado-->(SEQ=200)(CTL=SYN)(ventana=4096)(MSS=1460) -->SYN-Recibido

3. Establecida<--(SEQ=400)(ACK=201)(CTL=SYN,ACK)(ventana=4096)(mss=1460)<--SYN-Recibido

4. Establecida-->(SEQ=201)(ACK=401)(CTL=ACK)(ventana=4096) -->Establecida

5. Establecida-->(SEQ=201)(ACK=401)(CTL=ACK)(ventana=4096)(DATOS) -->Establecida

Figura 1.3 Pasos necesarios para iniciar una conexión TCP

En el paso número uno el computador Cliente no tiene ninguna conexión TCP abierta y el computador servidor se encuentra en estado de espera de una solicitud de conexión TCP. En el paso número dos el computador cliente inicia el proceso de una conexión TCP enviando un paquete de control TCP al computador servidor el cual indica:

-. La intención de sincronizar el número de secuencia de los segmentos a ser enviados una vez establecida la conexión "(SEQ=200)(CTL=SYN)".-. El tamaño máximo de segmento que puede recibir el computador cliente y el número de octetos de datos que puede aceptar "(SEQ=200)(CTL=SYN)(ventana=4096)(MSS=1460) ".

Una vez que dicho paquete es recibido y procesado por el servicio TCP del computador servidor el mismo envía un paquete de control TCP al computador cliente que indica:

-. El número de secuencia enviado por el computador cliente fue recibido y procesado sin error (ACK=201). A su vez este paquete (CTL=ACK) incluye la intención de sincronizar el número de secuencia de los segmentos a ser enviados por el computador servidor "(SEQ=400), (CTL=SYN)" y el tamaño máximo de segmento que puede recibir el computador servidor y el número de octetos de datos que puede aceptar "(ventana=4096)(MSS=1460) ".

Una vez que el computador cliente recibe y procesa el paquete de control enviado por el computador servidor en el paso tres, este procede a enviar un paquete de control al computador servidor el cual indica que el paquete ha sido recido y procesado sin errores "(SEQ=201)(ACK=401)(CTL=ACK)". Cuando el computador servidor haya finalizado de procesar dicho paquete la conexión TCP queda establecida y sincronizada y ambos computadores pueden proceder a enviar o a recibir segmentos TCP, tal como se muestra en el paso número cinco donde el computador cliente envía un segmento TCP al computador servidor "(SEQ=201)(ACK=401)(CTL=ACK)(datos)". Es importante resaltar que el número de secuencia del segmento en la línea 5 es el mismo que el de la línea 4 ya que el ACK no consume ningún número del espacio de secuencias.

Este ejemplo demuestra:

-. La función de los parámetros de control: SYN, ACK, Número de secuencia, Número de acuse recibido "ACK" y opciones para establecer una conexión TCP.-. Que para establecer una conexión TCP se requiere del intercambio de tres mensajes a fin de evitar confusión con conexiones iniciadas anteriormente.-. Que para finalizar una conexión TCP se activa el parámetro de control FIN en el último segmento de datos a enviar.

Si una conexión TCP no está sincronizada se hace uso del parámetro de control RST con el fin de reiniciar la conexión.

Mecanismo de fiabilidad

Con el fin de poder recuperar los datos que se corrompan, pierdan, dupliquen o se entreguen desordenados por los servicios de la capa de enrutamiento, el protocolo TCP está diseñado para satisfacer los principios de un protocolo orientado a conexión, es decir; que por cada segmento enviado por el emisor este debe recibir un número de acuse de recibido enviado por el receptor. En el ejemplo que se muestra en la figura 1.4 podemos observar que:

Computador / Cliente Computador / Servidor

1. Cerrado Espera

2. SYN-Enviado -->(SEQ=200)(CTL=SYN)(ventana=4096)(MSS=1460) -->SYN-Recibido

3. Establecida<--(SEQ=400)(ACK=201)(CTL=SYN,ACK)(ventana=4096)(MSS=1460)<--SYN-Recibido

4. Establecida-->(SEQ=201)(ACK=401)(CTL=ACK) -->Establecida

5. Establecida-->(SEQ=201)(ACK=401)(CTL=ACK)(ventana=4096)(DATOS) -->Establecida

6. Establecida<--(SEQ=401)(ACK=202)(CTL=ACK)(ventana=4096)(DATOS) <--Establecida

7. Establecida-->(SEQ=202)(ACK=402)(CTL=ACK)(ventana=4096)(DATOS) -->Establecida

8. Establecida<--(SEQ=402)(ACK=203)(CTL=ACK)(ventana=4096)(DATOS) <--Establecida

9. Establecida-->(SEQ=203)(ACK=403)(CTL=ACK)(ventana=4096)(DATOS) -->Establecida

10. Establecida<--(SEQ=403)(ACK=204)(CTL=ACK)(ventana=4096) <--Establecida

11. Establecida-->(SEQ=204)(ACK=404)(CTL=ACK,FIN) -->Establecida

12. Cerrado <--(ACK=205)(CTL=ACK)(ventana=4096) <--Establecida

13. Cerrado <--(SEQ=404)(ACK=205)(CTL=ACK,FIN) <--Establecida

14. Cerrado -->(ACK=405)(CTL=ACK) -->Espera

Figura 1.3 Mecanismo de fiabilidad

-. Los pasos: 2 ,3 , 4 son los pasos necesarios para establecer la conexión.-. En los pasos 5, 6, 7, 8 podemos observar que por cada segmento enviado por el emisor este recibe un número de acuse de recibido enviado por el receptor.-. Los pasos 9, 10, 11, 12 son los pasos necesarios para cerrar la conexión en ambos computadores.

Es importante resaltar que no existe ninguna restricción en el protocolo TCP sobre el hecho de reutilizar más de una vez una misma conexión. Como hemos explicado anteriormente una conexión se define por un par de conectores "Sockets". Cualquier nueva instancia de una conexión será referida como una encarnación de la conexión. ¿Cómo el protocolo TCP identifica los segmentos duplicados de encarnaciones previas?. Esta condición es posible si la conexión presenta momentos de inestabilidad, es decir; que una conexión se abre y se cierra varias veces de forma contínua debido a la inestabilidad en la línea de transmisión o por falta de recursos en el sistema.

Para evitar que el protocolo TCP se confunda, se debe evitar que los segmentos de una encarnación utilicen los números de secuencia que posiblemente estén siendo utilizados por el protocolo TCP por una encarnación anterior. Para asegurarnos de esto es necesario que cuando se creen nuevas conexiones, el protocolo TCP haga uso de un generador de números iniciales de secuencia (ISN, 'initial sequence number') para eligir un nuevo ISN de 32 bits por cada conexión nueva. Este generador está asociado a un reloj de 32 bit, cuyo bit menos significativo se incrementa aproximadamente cada 4 microsegundos. Esto implica que un número inicial de secuencia rote aproximadamente cada 4.55 horas. Partiendo de esta premisa queda razonablemente explícito suponer que los números de secuencia iniciales serán únicos durante el proceso de sincronización de una conexión ya que cada implementación del protocolo TCP tiene que elegir un valor que determine el tiempo de vida máximo de un segmento en la red "Maximun Segment Life MSL". Si este tiempo de vida es mayor que el definido, el protocolo TCP descarta el segmento.

Cada que vez que el protocolo TCP cierra una conexión o envia el último número de acuse de recibo, el protocolo TCP debe de dejar activa la conexión por un tiempo igual a dos veces el tiempo de vida máximo de un segmento. Con esta acción se asegura que el último número de acuse recibido es procesado por el protocolo TCP. Este tiempo varía entre sistemas operativos.

El protocolo TCP trata a la corrupción de datos con el uso del parámetro de control Suma de control "Checksum" por cada segmento transmitido, comprobándose en el receptor y descartando los segmentos dañados. El campo "Suma de control" es el complemento "a uno" de 16 bits de la suma de los complementos "a uno" de todas las palabras de 16 bits de la cabecera y del texto. Si un segmento contiene un número impar de octetos de cabecera y texto, el último octeto se rellena con ceros a la derecha para formar una palabra de 16 bits con el propósito de calcular la suma de control. En el cálculo de la suma de control, el propio campo suma de control se considera formado por ceros. La suma de control también incluye una pseudocabecera de 96 bits prefijada imaginariamente a la cabecera TCP ver figura 1.4. Esta pseudocabecera contiene la dirección de origen, la dirección de destino, el protocolo, y la longitud del segmento de TCP. Esto proporciona una protección ante segmentos mal encaminados. Esta información es transportada por el protocolo de internet y es transferida a través de la interfaz TCP/Red en los argumentos o en los resultados de las llamadas de TCP a IP.

+--------+--------+--------+--------+

| Dirección de origen |

+--------+--------+--------+--------+

| Dirección de destino |

+--------+--------+--------+--------+

| cero | PTCL | Longitud TCP |

+--------+--------+--------+--------+

Figura 1.4 Pseudocabecera TCP

La "longitud TCP" consiste en la suma de la longitud de la cabecera de TCP más la de los datos en octetos (esto no es una cantidad transmitida explícitamente, sino que ha de calcularse), y no incluye los 12 octetos de la pseudocabecera.

Mecanismo de cotrol de flujo

El protocolo TCP está diseñado para controlar el envío y recepción de segmentos TCP a fin de evitar momentos de congestión en la red. Las principales técnicas de control de flujo implementadas en el protocolo TCP son:

-. Desplazamiento de ventana "Sliding Window".-. Comienzo lento "Slow Start" y control de congestión.

La técnica de desplazamiento de ventana es una técnica de control del flujo impuesta por el receptor de segmentos TCP con el fin de evitar momentos de congestión en el computador receptor. Durante el proceso de inicialización de una conexión TCP, el proceso TCP de cada computador da a conocer los parámetros de control ventana y MSS. Con estos dos parámetros el proceso de envío de segmentos del protocolo TCP puede calcular el máximo número de segmentos que puede recibir el proceso de recepción del protocolo TCP en un momento determinado. El parámetro ventana incluido en una cabecera TCP es un registro de 16 bits y el valor del mismo puede variar durante el envío y recepción de segmentos TCP hasta llegar al punto de que sea igual a cero. Cuando esto ocurre indica que el proceso de recepción de segmentos no está en capacidad de recibir ningún segmento TCP ya que el buffer de recepción se encuentra completamente lleno. Esto obliga al proceso de envío de segmentos TCP del computador remoto no transmitir ningún segmento hasta que el parámetro de control ventana sea mayor o igual a un segmento.

Esta técnica funciona si la conexión TCP se establece en una red local pero cuando la conexión TCP se establece a través de una red WAN los enrutadores pueden experimentar momentos de congestión ya que los mismos interactúan con un servicio de conexión no orientado y la capacidad de envío y recepción de datos de un enlace WAN en la mayoría de los casos es mucho menor que el de una red LAN. Para resolver este inconveniente el protocolo TCP hace uso de la técnicas comienzo lento "Slow Start" y control de congestión. Estas técnicas son técnicas de control de flujo impuestas en el emisor para evitar momentos de congestión en la red.

Las técnicas slow start y control de congestión consisten en que el transmisor de segmentos TCP hace uso de los parámetros de control: ventana de congestión y umbral de congestión. El parámetro de control ventana de congestión es utilizado para calcular el máximo número de segmentos que pueden ser transmitidos por el transmisor en un momento determinado. Y el parámetro umbral de congestión es utilizado para detectar momentos de congestión en la red.

El valor inicial del parámetro congestión de ventana es igual al parámetro MSS y el valor inicial del umbral de congestión es igual a 65535. Por cada número de acuse recibido de cada segmento transmitido el parámetro congestión de ventana se incrementa a un MSS; esto implica un posible crecimiento exponencial de este parámetro.

El máximo número de segmentos TCP que el transmisor puede enviar en un monento dado es seleccionado por el mínimo valor de la comparación de los parámetros Ventana y Congestión de ventana, es decir; que si el valor del parámetro Ventana es igual a 4096 bytes y el parámetro Congestión de ventana es igual a 2048 bytes. El transmisor de segmentos TCP hará uso del parámetro congestión de ventana para determinar el máximo número de segmentos que pueden ser transmitidos en un momento dado. El crecimiento del parámetro congestión de ventana se detiene hasta que el mismo sea igual al parámetro de control ventana.

Si el transmisor de segmentos TCP detecta un posible momento de congestión en la red debido a que el tiempo de espera de un número de acuse recibido expiró, el protocolo slow start se inicia nuevamente inicializando la ventana de congestión con el valor asignado al MSS y el parámetro umbral de congestión se le asigna un valor igual a la mitad de la ventana de transmisión pero nunca por debejo de dos segmentos. Esto implica que el umbral de congestión es determinado por la siguiente fórmula:

Umbral de congestión = max [2 segmentos, 1 / 2 min( ventana, ventana de congestion)]

Luego la técnica slow start entra en acción hasta que el parámetro congestión de ventana sea mayor que el umbral del congestión. Cuando esto ocurre el crecimiento de la ventana de congestión deja de ser exponencial ya que se incrementa a uno no por cada número de acuse recibido por segmento sino por el grupo de números de acuse recibido del rango de segmentos que son incluidos en la ventana de congestión en ese momento.

Se dice que el protocolo de transmisión TCP se encuentra en el estado slow start si la ventana de congestión es menor o igual al umbral de congestión. Y si la ventana de congestión es mayor que el umbral de congestión se dice que el protocolo de transmisión se encuentra en un estado de control de congestión.

En la figura 1.5 podemos observar de manera gráfica una aproximación del comportamiento de los algoritmos slow start y control de congestión.

Figura 1.5 Gráfica de los algoritmos slow start y control de congestión

Control de flujo para aplicaciones interactivas

Cuando las aplicaciones interactivas Ejemplo: Telnet hacen uso de los servicios de la capa de transporte por cada caracter a ser enviado, el protocolo TCP crea un segmento TCP de 21 Bytes que al ser encapsulado por la capa de enrutamiento tenemos un paquete de 41 Bytes. Una vez que este paquete es recibido y procesado, el computador destino envía un paquete IP de 40 bytes, el cual incluye el número de acuse recibido del segmento enviado. Esto implica que por cada caracter a ser enviado se requieren como mínimo de 81 Bytes. Para optimizar esta situación en el receptor muchas de las aplicaciones retardan el envío de los números de acuse recibido o las actualizaciones de ventanas a un tiempo fijo,

el cual varía dependiendo de la aplicación TCP. Este retardo se encuentra en el rango de 200mseg - 500mseg. Para el transmisor se hace uso del algoritmo de Nagle el cual consiste en enviar el primer caracter y almacenar en un buffer los posibles nuevos caracteres que serán enviados cuando se reciba el número de acuse recibido del primer caracter.

Tiempo de espera de retransmisión

Debido a la variabilidad de las redes que componen el sistema de redes de la red Internet y la gran cantidad de casos de conexiones TCP, el tiempo de espera de retransmisión se debe determinar dinámicamente ya que el tiempo de ida y vuelta es distinto para cada conexión TCP. Veamos a continuación un procedimiento para determinar un tiempo de espera de retransmisión.

-. Mídase el tiempo transcurrido entre el envío de un octeto de datos con un número de secuencia determinado y la recepción de un acuse de recibo que incluya ese número de secuencia (los segmentos enviados no tienen por qué concordar con los segmentos recibidos). Este tiempo medido es la muestra del tiempo de ida y vuelta 'Round Trip Time' o RTT.-. Calcular un promedio ponderado del RTT:

-. RTT-Estimado = alpha x RTT-Estimado + Beta * RTT-Muestra. Donde alpha + beta = 1. alpha entre 0.8 y 0.9 y beta entre 0.1 y 0.2.-. El tiempo de espera de retransmisión => RTO = 2 * RTT-Estimado.

El incoveniente de este algoritmo es que no se distingue entre un Ack del segmento enviado y un Ack de retransmisión.Los algoritmos de Karn y Partridge solucionan este problema no tomando muestras del RTT al retransmitir un segmento y duplicando el RTO despues de cada retransmisión.

Opciones

La implementación del protocolo TCP basado en el RFC 793 sólo incluye las opciones: fin de la lista de opciones, no operación y el tamaño máximo del segmento. En el RFC 1323 se definen las siguientes opciones: Factor de posicionamiento de la ventana "Window Scale Factor" y Timestamp.

-. Factor de posicionamiento de la ventana: Está opción es utilizada para incrememtar el parámetro de control ventana de un registro de 16 bits a un registro de 32 bits sin tener que modificar el parámetro de control ventana definido en una cabecera TCP. Esta opción está definida por un registro de tres bytes. En el primer byte se define el tipo de opción que para este caso es igual a tres, en el segundo byte se define el número de bytes de la opción, que para este caso es igual tres bytes, y el último byte define el factor de escala del registro ventana. Es importante mencionar que el valor máximo definido en el RFC 1323 del registro del factor de escala es igual a 14.Cuando esta opción está presente en la petición inicial de una conexión TCP, el parámetro de control ventana es calculado por la siguiente fórmula:

Ventana con factor de escala = ventana * 2 ^ factor de escala.

Esto implica que el máximo valor del parámetro de control ventana una vez aplicado el factor de escala de una ventana es:

1.073.725.440 Bytes = 65535 * 2 ^ 14.

Esta opción es utilizada para redes de alta velocidad con el fin de evitar el efecto del producto del ancho de banda en una conexión TCP.-.Timestamp: Esta opción le ofrece al protocolo TCP un mecanismo para calcular el RTT por cada número de acuse recibido. Por cada segmento a ser enviado se registra el momento de envío en el campo de opciones => Timestamp y en el momento de envío del acuse de recibido se registra el momento de envío en el campo de opciones => Timestamp. De esta manera el módulo TCP puede tener un aproximado del RTT.Este campo debe enviarse en la petición inicial de la conexión TCP. Si esta opción no está presente en una cabecera TCP este mecanismo no se activa.

Protocolo UDP

El protocolo UDP "User Datagram Protocol" de la capa de transporte es un servicio no orientado a conexión y la unidad de datos que envia o recibe este protocolo es conocido con el nombre de datagrama UDP. Las aplicaciones que requieran de una entrega fiable y ordenada de secuencias de datos deberían utilizar el Protocolo TCP o que la aplicación cumpla con los principios de un protocolo orientado a conexión. El protocolo UDP goza del mismo mecanismo de multiplexamiento utilizado por el protocolo TCP. Debido a que el protocolo UDP es un protocolo no orientado a conexión el campo puerto origen es opcional, es decir; que el puerto origen puede ser igual cero. En la figura 1.6 se muestra la cabecera del protocolo UPD.

0 7 8 15 16 23 24 31

+--------+--------+--------+--------+

| Puerto de | Puerto de |

| Origen | Destino |

+--------+--------+--------+--------+

| | |

| Longitud | Suma de Control |

+--------+--------+--------+--------+

| |

| octetos de datos ... |

+-----------------------------------+

Figura 1.6 Cabecera UDP

El campo Longitud representa la longitud en octetos de un datagrama UDP, incluyendo la cabecera y los datos. El campo longitud es un registro de 16 bits y pesar de que la máxima longitud de un datagrama UDP puede ser de 65536 bytes no es común ver datagramas UDP mayores que 512 bytes de datos.

El campo Suma de Control (Checksum) es el complemento "a uno" de 16 bits de la suma de los complementos "a uno" de las palabras de la combinación de una pseudo-cabecera construida con información de la cabecera IP, la cabecera UDP y los datos. La combinación de la pseudo-cabecera es rellenada con octetos de valor cero en la parte final (si es necesario) hasta tener un múltiplo de dos octetos. La pseudo-cabecera que imaginariamente antecede a la cabecera UDP contiene la dirección de origen, la dirección de destino, el protocolo y la longitud UDP. Esta información proporciona protección frente a datagramas mal encaminados. Este procedimiento de comprobación es el mismo que el utilizado en TCP. Es importante mencionar que la suma de control en una cabecera UDP es opcional.

Cuando la transferencia de datagramas se establece a través de una red WAN haciendo uso de un protocolo UDP que es un protocolo no orientado a conexión, los enrutadores pueden experimentar momentos de congestión, ya que los mismos interactúan con un servicio de conexión no orientado y el ancho de banda de un enlace WAN en la mayoráa de los casos es menor que el ancho de banda de una red LAN. Para resolver este inconveniente muchas veces se tiene que implementar técnicas de control de flujo de datagramas UDP en el enrutador de salida de la red local con el fin de adaptar el flujo de paquetes UDP con la capacidad de recepción y re-envío de paquetes de los enrutadores y asíevitar momentos de congestión. Como ejemplo de estas técnicas tenemos el protocolo Random Early Detection RED.

Parámetros de configuración. Caso de estudio Linux

Cuando tomamos en cuenta el producto del ancho de banda de una conexión TCP y los parámetros de configuración: control de ventana, tamaño del buffer de envío y recepción de datos y los posibles diferentes valores del parámetro de configuración MTU de los enlaces de transmisión, el rendimiento de una conexión TCP puede verse afectado notablemente. Estas son las razones que demuestran lo dicho anteriormente:

-. El producto del ancho de banda es la máxima cantidad de datos que pueden ser transmitidos en una unidad de tiempo - segundo - desde un computador A a un computador B tomando en cuenta el RTT. Esto implica que el producto del ancho de banda viene dado por la siguiente expresión matemática:

Producto del ancho de banda = Ancho de banda de la línea de transmisión * RTT

Si el ancho de banda de una línea de transmisión entre dos computadoras es de 155MB/Seg esto implica que en el caso ideal para un protocolo de conexión orientada, el tiempo de transferencia de un archivo de 10MBytes desde un computador a otro es de 10MBytes / 155MB/Seg =~ 0.5 seg. Si en este ejemplo incluimos las siguientes variables: RTT, tamaño del parámetro de control ventana y el tamaño del buffer de envió y recepción de datos tenemos que:

a.- Si el RTT promedio es de 50mseg tenemos que el producto del ancho de banda es igual a 155MB/Seg * 50mseg = 7.75MB. Esto implica que 7.75MB es mucho mayor que el tamaño máximo del parámetro de control ventana basado en el RFC 793 y a su vez 7.75MB es mucho mayor que el buffer de envío y recepción de datos configurado por defecto en ambos computadores. Por lo tanto a fin de optimizar el rendimiento de las conexiones TCP los siguientes parámetros de configuración pueden ser manipulados: factor de posicionamiento de la ventana RFC 1323, El tamaño del buffer de envió y recepción de datos.

En el sistema operativo Linux a partir de la versión 2.1, el parámetro de control ventana está definido por un registro de 15 Bits tal como se muestra en el siguiente código extraído del header tcp.h

/** Never offer a window over 32767 without using window scaling. Some* poor stacks do signed 16bit maths!*/#define MAX_TCP_WINDOW 32767U

Los siguientes parámetros de control son manipulados en el sistema operativo Linux a fin optimizar las conexiones TCP afectadas por el producto del ancho de banda:

-. /proc/sys/net/core/rmem_default - default receive window-. /proc/sys/net/core/rmem_max - maximum receive window-. /proc/sys/net/core/wmem_default - default send window-. /proc/sys/net/core/wmem_max - maximum send window-. tcp_adv_win_scale-. tcp_window_scaling-. tcp_timestamps-. tcp_mem-. tcp_rmem-. tcp_wmem

Los valores por defecto de cada uno de los parámetros de control presentados y su significado se encuentran incluidos en el archivo sysctl.txt. Este archivo se encuentra en la documentación del Kernel. Ejemplo: /usr/src/kernel-source-2.4.18/Documentation/networking/ip-sysctl.txt.

Es importante mencionar que manipular dichos parámetros de configuración puede ser contraproducente, ya que a medida que se incrementa el número de conexiones TCP los recursos de memoria del sistema disminuyen. Además el promedio del RTT de cada conexión varia.

Actualmente una de las áreas de investigación con el fin de optimizar el protocolo TCP consiste en la búsqueda de algoritmos que permitan adaptar los parámetros de configuración mencionados anteriormente de forma automática.

Conclusiones

La capa de transporte es la responsable del envío y la recepción de los segmentos de datos de la capa de aplicación. Esta capa ofrece a la capa de aplicación, dos servicios. Un servicio que consiste en el envío y recepción de datos orientado a conexión y otro que consiste en el envío y recepción de datos no orientados a conexión.

El protocolo TCP "Transmition Control Protocol" de la capa de transporte es un servicio orientado a conexión y la unidad de datos que envía o recibe el protocolo TCP es conocido con el nombre de segmento TCP.

La función protocolo TCP consiste en ofrecer un servicio de envío y recepción de datos orientado a conexión que sea seguro y que goce de los siguientes mecanismos:

-. Multiplexamiento.-. Conexiones.-. Fiabilidad.-. Control de flujo y congestion.

El producto del ancho de banda de una conexión TCP puede afectar el rendimiento de las conexiones TCP; y los siguientes parámetros de configuración pueden ser manipulados a fin de optimizar el rendimiento de las conexiones TCP:

-. Factor de posicionamiento de la ventana RFC 1323.-. El tamaño del buffer de envio y recepción de datos.-. Un mismo MTU entre los enlaces del computador fuente y destino.

El protocolo UDP "User Datagram Protocol" de la capa de transporte es un servicio no orientado a conexión y la unidad de datos que envía o recibe el protocolo UDP es conocido con el nombre de datagrama UDP.

Cuando la transferencia de datagramas se establece a través de una red WAN haciendo uso de un protocolo UDP que es un protocolo no orientado a conexión, los enrutadores pueden experimentar momentos de congestión, ya que los mismos interactúan con un servicio de conexión no orientado y el ancho de banda de un enlace WAN en la mayoría de los casos es menor que el ancho de banda de una red LAN. Para resolver este inconveniente muchas veces se tiene que implementar técnicas de control de flujo de datagramas UDP en el enrutador de salida de la red local con el fin de adaptar el flujo de paquetes UDP con la capacidad de recepción y re-envío de paquetes de los enrutadores y así evitar momentos de congestión. Como ejemplo de estas técnicas tenemos el protocolo Random Early Detection RED.

En las siguientes secciones analizaremos los protocolos de la capa de enrutamiento. IP, ICMP, ARP.

Referencias Bibliográficas

RFC 768, "User Datagram Protocol".

RFC 793, "Protocolo de control de transmision".

RFC 826, "Control de congestión en IP / TCP Internetworks".

RFC 1071, "Cálculo de la suma de comprobación de Internet".

RFC 1072, "TCP Extensions para larga Rutas de retardo".

RFC 1180, "Un Tutorial de TCP / IP".

RFC 1122, "Requisitos para hosts de Internet - Comunicación Capas".

RFC 1323, "TCP Extensions for High Performance".

RFC 2001, "TCP comienzo lento, evitar la congestión, retransmisión rápida, y Fast Recovery Algoritmos".

RFC 2147 "TCP y UDP sobre IPv6 Jumbograms".

Día, JD, y Zimmermann, H.: "El modelo de referencia OSI", Proc. del IEEE, vol. 71, pp1334-1340, diciembre de 1983.

Floyd, S., y Jacobson, V., azar portales de detección temprana para evitar la congestión, IEEE / ACM Operaciones en Red, V.1 N.4, agosto de 1993, pp 397-413.

http://www.psc.edu/networking/tcp.html

Karn, P. y C. Partridge, "Estimación Ida y vuelta veces en protocolos de transporte fiables", Proc. SIGCOMM '87, Stowe, VT, agosto de 1987.

W. Richard Stevens, Unix Programming Network. Prentice-Hall 1990, ISBN 0-13-949876-1.

W. Richard Stevens, TCP / IP Ilustrated Volumen 1, Los protocolos. Prentice-Hall 1994, ISBN 0-201-63346-9.

Capa de enrutamiento del protocolo TCP-IP

Luciano PoloCopyright © 2000. Luciano Polo. Tutorial protegido por la GLP.

Objetivos

Durante el estudio del protocolo IPv4 se analiza el proceso de enrutamiento de paquetes IP, el reporte de errores del protocolo IPv4, el sistema de direccionamiento del protocolo TCP-IP y la estructura de la red Internet. El objetivo de este tutorial es dar a conocer las funciones de la capa de enrutamiento del protocolo IPv4.

Introducción

La capa de enrutamiento - protocolo IPv4 - ofrece a la capa de transporte un servicio no orientado a conexión que cumple con las siguientes funciones:

-. Enrutamiento, Fragmentación y reensamblaje.-. Clasificación de servicios.-. Tiempo de vida de un paquete.

Enrutamiento, Fragamentación y reemsamblaje

Una de las funciones del Protocolo IP es enrutar paquetes IP a través de un conjunto de redes TCP-IP interconectadas. Los paquetes IP son encaminados desde un computador a otro a través de redes individuales basándose en la interpretación de una dirección IP. Para cumplir con esta función el protocolo IP utiliza las direcciones IP fuente y destino que se encuentran en una cabecera IP a fin de determinar la ruta de los paquetes IP desde un computador fuente a un computador destino. Este proceso se conoce con el nombre de enrutamiento de paquetes IP. Este proceso de enrutamiento puede ser generalizado por el siguiente algoritmo:

1. Determinar la dirección IP del computador destino.2. ¿La red de la direcció IP destino es igual a la red de la dirección IP del computador fuente? Si la respuesta es sí ir al paso 3 de lo contrario ir al paso 4.3. Obtener la dirección física asociada a la dirección IP destino haciendo uso del protocolo ARP y transmitir el paquete con la interface de red apropiada.4-. ¿La red destino se encuentra listada en la tabla de rutas? Si la respuesta es sí enviar el paquete IP a la dirección IP asociada a la ruta hasta alcanzar a la red del computador destino y proceder con el paso 3.. Si la respuesta es no, utilizar la ruta por defecto. Si la ruta por defecto no está configurada: generar un paquete ICMP indicando el error "red inalcanzable".

Durante el proceso de enrutamiento, un paquete IP puede ser fragmentado cuando el tamaño del mismo es mayor que la máxima unidad de transferencia de datos - MTU Maximun Transfer Unit - del enlace que une a dos redes TCP-IP. Los paquetes IP fragmentados solo son reensamblados cuando lleguan al computador destino.

En la figura 1.1 podemos observar los parámetros de control de una cabecera IP donde los parámetros: Dirección IP fuente, Dirección IP destino, Identificación, Flags y Posición son uilizados para cumplir con las funciones de enrutamiento, fragmentación y reensamblaje del protocolo IPv4.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Versión| IHL | Tipo Servicio | Longitud Total |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identificación |Flags| Posición |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Tiempo de Vida | Protocolo | Suma de Control de Cabecera |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Dirección de Origen |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Dirección de Destino |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Opciones | Relleno |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cada signo - indica un Bit.

Figura 1.1 Cabecera IPv4

El registro Flags -banderas- está compuesto por tres bits los cuales están codificados de la siguiente manera:

Bit 0: reservado, debe ser cero.

Bit 1: (DF) No Fragmentar (Don't Fragment) 0 = puede fragmentarse,

1 = No Fragmentar.

Bit 2: (MF) Más Fragmentos (More Fragments) 0 = último Fragmento,

1 = Más Fragmentos.

0 1 2

+---+---+---+

| | D | M |

| 0 | F | F |

+---+---+---+

La función del registro flags es indicar si los paquetes recibidos por el computador destino se encuentran fragmentados o no. Si los paquetes se encuentran fragmentados estos parámetros de control trabajan en conjunto con los parámetros de control Indentificación y Posición.

El parámetro de control Identificación es un registro de 16 Bits el cual es asignado por el remitente para el ensamblaje de fragmentos de un datagrama.

El parámetro de control Posición del Fragmento es un registro de 13 Bits y sirve para indicar a que parte del paquete IP pertenece este fragmento. La posición del fragmento se mide en unidades de 8 octetos (64bits). El primer fragmento tiene posición 0.

Los registros dirección IP Origen y Dirección IP Destino son registros de 32 Bits e indican la dirección IP de un computador.

Clasificación de servicios

El protocolo IP puede ser utilizado para diferenciar los datos de los servicios generados por las aplicaciones. De esta manera se establecen prioridades entre las aplicaciones con el fin de satisfacer sus requerimientos. En la figura 1.1 podemos observar el parámetro de control Tipo de Servicio. Este parámetro de control es utilizado para diferenciar los

datos de los servicios generados por las aplicaciones. El registro Tipo de Servicio es un registro de 8 bits tal como se presenta a continuación:

Bits 0-2: Prioridad.

Bit 3: 0 = Demora Normal, 1 = Baja Demora.

Bit 4: 0 = Rendimiento Normal , 1 = Alto rendimiento.

Bit 5: 0 = Fiabilidad Normal , 1 = Alta fiabilidad.]

Bits 6-7: Reservado para uso futuro.

0 1 2 3 4 5 6 7

+-----+-----+-----+-----+-----+-----+-----+-----+

| | | | | | |

| PRECEDENCIA | D | T | R | 0 | 0 |

| | | | | | |

+-----+-----+-----+-----+-----+-----+-----+-----+

Precedencia

111 - Control de Red

110 - Control Entre Redes

101 - CRITICO/ECP

100 - Muy urgente (Flash Override)

011 - Urgente (Flash)

010 - Inmediato

001 - Prioridad

000 - Rutina

Tiempo de vida de un paquete

Debido a que el protocolo IP es un protocolo no orientado a conexión el mismo hace uso de un mecanismo que determina el tiempo de vida "TTL Time to Live" de un paquete IP. Este tiempo de vida fijado por el computador Origen es reducido a uno cada vez que el paquete IP es enrutado. Si el tiempo de vida se reduce a cero antes de que el paquete IP llegue a su destino, el paquete IP es destruido. En la figura 1.1 podemos observar que el registro "Tiempo de Vida" es un registro de 8 bits.

El parámetro de control Suma de control "Checksum" del protocolo IP incluye unicamente la cabecera IP. Dado que algunos campos de la cabecera cambian cada vez que un paquete IP es enrutado o procesado (Ej: Parámetro de control Tiempo de Vida), esta suma es recalculada y verificada en cada punto donde la cabecera internet es procesada. El algoritmo de la suma de control es el complemento A uno de 16 bits de la suma de los complementos A uno de todas las palabras de 16 bits de la cabecera. A la hora de calcular la suma de control, el valor inicial de este campo es cero.

El parámetro de control Versión presente en una cabecera IP es un registro de 4 bits e indica el formato de la cabecera IP.

El parámetro de control Longitud de la Cabecera IP (IHL Internet Header Length), es un registro de 4 Bits e indica la longitud de la cabecera en palabras de 32 bits, y por tanto apunta al comienzo de los datos. Es importante mencionar que el valor mínimo para una cabecera IP correcta es 5.

El parámetro de control opciones puede o no aparecer en una cabecera IP ya que su transmisión es opcional. Las Opciones proporcionan funciones de control necesarias tales como marcas de tiempo, seguridad y enrutamiento. Analicemos a continuación el sistema de direccionamiento del protocolo IP versión 4 y la estructura de la red Internet.

Sistema de direccionamiento IPv4 y estructura de la red Internet

Una de las funciones del protocolo IPv4 es establecer el direccionamiento lógico de una red con el objetivo de que dos o más computadores puedan establecer el proceso de comunicación. Cuando el protocolo IPv4 comenzó a estandarizarse, el esquema de direccionamiento estaba basado en un registro fuente y en un registro destino de 32 bit cada uno tal como se muestra en la figura 1.1.

Cada uno de estos registros está dividido en 3 campos, a saber: clase, red y host. La función del campo clase es clasificar a una dirección IP fuente y/o destino. La función del campo red es determinar a la red que pertenece un host "computador" destino y/o fuente. Y el campo host "computador" tiene como función determinar a la computadora destino o fuente que pertenece a una red. El conjunto de estos tres campos se conoce con el nombre de dirección IP.

En la figura 1.2 podemos observar 5 clases de direcciones IP:

Figura 1.1 Clases de direcciones IP

-. Clase A. Está definida cuando el valor del bit menos significativo es igual a 0. En esta clase se puede representar hasta 2^24 computadoras incluidas en cada una de las 2^7 posibles redes.-. Clase B. Está definida si el valor de los 2 bit menos significativos es igual a 10. En esta clase se puede representar hasta 2^16 computadoras incluidas en cada una de las 2^14 posibles redes.-. Clase C. Se define cuando el valor de los 3 bit menos significativos es igual a 110. En esta clase se puede representar hasta 2^8 computadoras incluidas en cada una de las 2^21 posibles redes.-. Clase D y E. Las direcciones que forman parte de la clase D son utilizadas por los protocolos que hacen uso de la comunicación tipo multicast. Las direcciones que forman parte de la clase E son utilizadas para experimentación.

Para facilitar la lectura de una dirección IP, el registro de 32 bit de la dirección fuente y destino es dividido en 4 campos de 8 bit cada uno y se convierte el número binario de cada campo en su equivalente decimal. Esta representación de un registro IP se conoce con el nombre de notación de punto decimal; esto implica que el rango de redes para cada clase de dirección IP es el que se representa en la siguiente tabla:

Clase Rango campo red Rango campo hostClase A 0 - 127 0.0.0 hasta 255.255.255Clase B 128.0 hasta 191.255 0.0 hasta 255.255Clase C 192.0.0 hasta 223.255.255 0 hasta 255Clase D 224.0.0.0 hasta 239.255.255.255 No aplicaClase E 240.0.0.0 hasta 247.255.255.255 No aplica

Dicho rango de direcciones IP está compuesto por un grupo privado y un grupo público "RFC 1918". El rango de direcciones IP que pertenecen al grupo público es utilizado para interconectar redes que forman parte de la red Internet y

el rango de direcciones IP que pertenecen al grupo privado es utilizado para interconectar redes que no forman parte de la red Internet.

El rango de direcciones IP privadas está compuesto por los siguientes bloques: 10.0.0.0 hasta 10.255.255.255, 172.16.0.0 hasta 172.31.255.255 y 192.168.0.0 hasta 192.168.255.255. El rango de direcciones IP públicas está compuesto por todas las direcciones IP que no forman parte del rango de direcciones IP privadas incluyendo el rango de direcciones IP: 127.0.0.0 hasta 127.255.255.255 ya que dicho rango es utilizado como lazo cerrado del computador local - LoopBack LocalHost - . Aunque este rango de direcciones IP no está incluido en el rango de direcciones públicas todos los programas que hacen uso del protocolo TCP-IP están diseñados para reconocer a dicho rango como direcciones - loopback localhost -.

Si aplicamos este esquema de direccionamiento a una organización dividida en n departamentos es importante resaltar que:

-. Para definir la red de un departamento es necesario utilizar una dirección IP clase A, B o C, esto trae como consecuencia que el número de computadoras posibles que pueden ser definidas en una dirección IP clase A, B o C, no necesariamente se adapte a la realidad. Por ejemplo si asignamos una dirección IP clase A por cada departamento el número de computadoras posibles por red es igual a 2^24 y 2^24 es un número irreal para un departamento de cualquier organización.-. El número de redes es directamente proporcional al número de departamentos que posee cada organización. En la medida en que esta proporción se incremente, el rango de direcciones IP posibles disminuye ineficientemente y a su vez la tabla de rutas del enrutador se incrementa proporcionalmente a medida que una nueva red es definida. Esta relación la podemos observar en el ejemplo que se presenta en la figura 1.2.

Figura 1.2 El número de redes es directamente proporcional al número de departamentos

Sub-Redes y VLSM

Si se hace uso de la técnica de subredes definida inicialmente en el RFC 917 y luego en el RFC 950, el número de departamentos de cada organización no es directamente proporcional al número de redes, y el rango de direcciones IP posibles es administrado con mayor eficiencia.

Esta técnica consiste en la inclusión del campo Sub-Red en el registro de una dirección IP. Su función es definir la sub-red de una red. El método más utilizado para determinar la sub-red de una red es haciendo uso de un registro conocido con el nombre de "máscara de una sub-red" y al efectuar la operación booleana AND entre una dirección IP y la "máscara de la sub-red" se determina la sub-red de una red.

Figura 1.3 Máscara de una dirección IP

En el ejemplo que se muestra en la figura 1.3 se define:

-. Una dirección IP clase B, cuya red está definida por el número: 140.120.x.x y máscara 255.255.0.0.-. 255 sub-redes.-. 255 computadoras por sub-red.-. La máscara de las sub-redes es 255.255.255.0

Es importante mencionar que en el RFC 950 se establece que él número de bit del campo sub-red puede variar dependiendo del número necesario de computadoras por sub-red. Por ejemplo, dada la red clase B: 130.130.0.0, dicha red podría ser dividida por uno de los siguientes arreglos de sub-redes:

Red: 130.130.0.0-Mascara de la subred: 255.255.255.0-No. Sub-Redes: 255-Computadoras/Sub-Red: 255

-Mascara de la subred: 255.255.255.240-No. de Sub-Redes: 16-Computadoras/Sub-Red: 16

-Mascara de la subred: 255.255.255.252-No. de Sub-Redes: 64-Computadoras/Sub-Red:4

130.130.0.0 130.130.0.0 130.130.0.0130.130.1.0 130.130.0.16 130.130.0.4130.130.2.0 130.130.0.32 130.130.0.8130.130.3.0 130.130.0.48 130.130.0.12130.130.4.0 130.130.0.64 .130.130.5.0 130.130.0.80 .130.130.6.0 130.130.0.96 .

. 130.130.0.112 .

. 130.130.0.128 .

. 130.130.0.144 .

. 130.130.0.160 .130.130.251.0 130.130.0.176 .130.130.252.0 130.130.0.192 .130.130.253.0 130.130.0.208 130.130.0.244130.130.254.0 130.130.0.224 130.130.0.248130.130.255.0 130.130.0.240 130.130.0.252

Esta técnica se conoce con el nombre de longitud variable de la máscara de una sub-red "VLSM" y su función es definir sub-redes que se adapten con mayor facilidad al número de computadoras por sub-red. Para hacer aún más explícita esta técnica analizamos el siguiente ejemplo:

A una organización se le ha asignado la red Clase C número 194.120.14.x/255.255.255.0. Dicha organización está compuesta por los departamentos: A, B, C; cada departamento requiere el siguiente número de computadoras: 98, 48 y 50 respectivamente. El crecimiento en 2 años de cada departamento está previsto que sea del 20% para el departamento A, del 18% para el departamento B y del 10% para el departamento C. Sobre la base de esta información la máscara de cada sub-red y el número de direcciones IP de cada computador es la siguiente:

Departamento A Sub-Red: 194.120.14.0Mascara de la Sub-Red: 255.255.255.128Rango de direciones IP: 194.120.14.0 hasta 194.120.14.127.Rango de direciones IP a utilizar inicialmente: 194.120.14.0 hasta 194.120.14.98Rango de direciones IP a utilizar en dos años: 194.120.14.0 hasta 194.120.14.116Rango de direciones IP de reserva: 194.120.14.117 hasta 194.120.14.127Departamento B Sub-Red: 194.120.14.128Mascara de la Sub-Red: 255.255.255.192Rango de direciones IP: 194.120.14.129 hasta 194.120.14.191Rango de direciones IP a utilizar inicialmente: 194.120.14.129 hasta 194.120.14.177Rango de direciones IP a utilizar en dos años: 194.120.14.129 hasta 194.120.14.186Rango de direciones IP de reserva: 194.120.14.187 hasta 194.120.14.191Departamento C Sub-Red: 194.120.14.192Mascara de la Sub-Red: 255.255.255.192Rango de direciones IP: 194.120.14.193 hasta 194.120.14.255Rango de direciones IP a utilizar inicialmente: 194.120.14.193 hasta 194.120.14.243Rango de direciones IP a utilizar en dos años: 194.120.14.193 hasta 194.120.14.248Rango de direciones IP de reserva: 194.120.14.249 hasta 194.120.14.255

Es importante mencionar que el RFC 950 establece las siguientes reglas:

-. Cada uno de los bit que definen al campo sub-red de una dirección IP no puede tener el valor 0 y tampoco el valor de los bitdel campo computador puede ser igual a 0, ya que se estaría definiendo a la red de la sub-red.-. Cada uno de los bit que conforman al campo computador de una dirección IP no puede tener el valor 0 ó 1. Ya que si todos los bit son iguales a 0 se estaría definiendo a la sub-red. Y si todos los bit del campo computador son iguales a 1 se estaría definiendo a la dirección broadcast de la sub-red.

Si aplicamos este esquema de direccionamiento a una organización que está dividida en n departamentos es importante resaltar que:

-. El campo sub-red incluido en el registro de una dirección IP es el que define a la red de un departamento y por ende, el número de redes no es directamente proporcional al número de departamentos.-. El número de computadoras que pueden ser definidas en una sub-red se adapta con mayor facilidad al número de computadoras por departamento, y el rango de direcciones IP posibles es administrado con mayor eficiencia.-. Un nuevo nivel jerárquico es incluido de manera implícita en el sistema de direccionamiento IPv4.

Prefijo de una dirección IP "CIDR"

A medida que el número de redes "sub-redes y/o redes" se incrementa, la tabla de rutas administradas por el enrutador aumenta proporcionalmente hasta llegar al punto de colapsar la capacidad de procesamiento del enrutador. Para solucionar este problema se creó la técnica CIDR "Classless InterDomain Routing" cuya función principal es incluir a un grupo de redes en una dirección IP. Con la técnica CIDR cada red definida está asociada a un prefijo, el cual determina el bloque de direcciones IP y su nivel jerárquico. Por ejemplo la dirección IP 192.40.0.0 con prefijo 16 "192.40.0.0/16" define al bloque de direcciones IP que va desde 192.40.0.0 hasta 192.40.255.255. En dicho bloque de direcciones IP se definen las sub-redes y cada sub-red tiene asociado un prefijo, el cual tiene que ser mayor que el prefijo que define al bloque. Ejemplo : 192.40.1.0/24, 192.40.2.0/24, 192.40.3.0/24 y 192.40.4.0/24.

Para poder hacer uso de la técnica CIDR el enrutador debe elegir de la tabla de rutas la red que posea el mayor número de bits contínuos iguales a la dirección IP destino "Longest Match Prefix" para ello debe definirse en el enrutador el bloque de direcciones IP "Agregación".

En la figura 1.4 podemos observar a la dirección IP 192.24.0.0/16 la cual tiene un prefijo igual a 16, dicho prefijo determina la máscara: 255.255.0.0 y el bloque de direcciones IP que pueden ser definidas desde 192.24.0.0 hasta 192.24.255.255. En este ejemplo se definen 4 sub-redes: 192.24.1.0/24, 192.24.2.0/24, 192.24.3.0/24 y 192.24.4.0/24 de 255 computadoras cada una. El enrutador R2 puede dar a conocer a las sub-redes: 192.24.1.0/24, 192.24.2.0/24, 192.24.3.0/24 y 192.24.4.0/24 al enrutador R0 con el bloque que las define 192.24.0.0/16 reduciendo de esta manera la tabla de rutas del enrutador R0 a una proporción de cuatro a uno.

Figura 1.4 Prefijo de una dirección IP

Es importante mencionar que el uso del prefijo de una red "RFC1812, RFC1517, RFC1518, RFC1519, RFC1520" elimina las siguientes reglas definidas en el RFC 950:

-. Cada uno de los bit que definen al campo sub-red de una dirección IP no puede tener el valor 0 y tampoco el valor de los bit del campo computador puede ser igual a 0, ya que se estaría definiendo a la red de la sub-red.-. Cada uno de los bit que conforman al campo computador de una dirección IP no puede tener el valor 0 ó 1. Ya que si todos los bit son iguales a 0 se estaría definiendo a la sub-red. Y si todos los bit del campo computador son iguales a 1 se estaría definiendo a la dirección broadcast de la sub-red.

Si aplicamos este esquema de direccionamiento a una organización que está dividida por n departamentos es importante resaltar que:

-. Se elimina el campo clase A, B o C del registro de una dirección IP ya que el mismo es reemplazado por el prefijo de una red.-. EL prefijo de una dirección IP determina a un bloque de direcciones IP.-. El número de computadoras que pueden ser definidas en una sub-red se adapta con mayor facilidad al número de computadoras por departamento.-. El rango de direcciones IP posibles y la tabla de rutas de los enrutadores es administrado con mayor eficiencia.-. Los niveles jerárquicos pueden ser incluidos de manera implícita en el sistema de direccionamiento IPv4.-. Haciendo uso de la notación CIDR las siguientes redes clase A, B o C se pueden incluir en el bloque:

Prefijo Notación punto decimal # de redes clase A, B o C/1/2/3/4/5/6/7/8

128.0.0.0192.0.0.0224.0.0.0240.0.0.0248.0.0.0252.0.0.0254.0.0.0255.0.0.0

128 redes clase A64 redes clase A32 redes clase A16 redes clase A8 redes clase A4 redes clase A2 redes clase A1 rede clase A o 256 redes clase B

/9/10/11/12/13/14/15/16

255.128.0.0255.192.0.0255.224.0.0255.240.0.0255.248.0.0255.252.0.0255.254.0.0255.255.0.0

128 redes clase B64 redes clase B32 redes clase B16 redes clase B8 redes clase B4 redes clase B2 redes clase B1 red clase B o 256 redes clase C

/17/18/19

255.255.128.0255.255.192.0255.255.224.0

128 redes clase C64 redes clase C32 redes clase C

/20/21/22/23/24

255.255.240.0255.255.248.0255.255.252.0255.255.254.0255.255.255.0

16 redes clase C8 redes clase C4 redes clase C2 redes clase C1 red clase C

/25/26/27/28/28/30/31/32

255.255.255.128255.255.255.192255.255.255.224255.255.255.240255.255.255.248255.255.255.252255.255.255.254255.255.255.255

1/2 de red clase C1/4 de red clase C1/8 de red clase C1/16 de red clase C1/32 de red clase C1/64 de red clase C1/128 de red clase C1/256 de red clase C

Estructura de la red Internet

Una red es el enlace entre dos o más nodos. Dicho enlace tiene como función permitir el envío y recepción de información entre los nodos que están realizando el proceso de comunicación. Una red está compuesta por elementos de hardware y software. La manera como se agrupan e intregran estos elementos genera las diferentes tecnologías de redes de comunicación.

Los elementos de hardware son los elementos físicos que permiten el enlace entre dos o más nodos o grupo de nodos. Los elementos de Software son los pasos "Protocolos" a seguir entre nodos o grupos de nodos a fin de satisfacer el proceso de comunicación.

La distancia que existe entre dos o más nodos o grupos de nodos nos sirve para determinar la escala de una red. En una red de escala local "LAN", todos los nodos que conforman la red se encuentran en un mismo cuarto, edificio o campo. En una red de escala metropolitana "MAN" la interconexión de redes locales localizadas en un área determinada por ejemplo una ciudad. Una red de escala amplia "WAN" se caracteriza por la interconexión de redes locales y metropolitanas que pueden estar localizadas en diferentes ciudades o países. Y una red de escala mundial "Internet" se caracteriza por la interconexión de redes WAN, MAN y LAN.

En la figura 1.5 podemos observar la estructura de la red Internet la cual está caracterizada por múltiples sistemas autónomos "Autonomous System AS" interconectados. Un sistema autónomo puede estar compuesto por redes LAN, MAN y WAN. Un sistema autónomo "AS" goza de un o más prefijos de direcciones IP. Cada prefijo define al bloque direcciones IP asignadas a un sistema autónomo. Cada prefijo que pertenece a un sistema autónomo está relacionado a una política de enrutamiento que define la interconexión lógica entre sistemas autónomos y define de manera implícita los diferentes tipos de sistemas autónomos: Sistema autónomo de tránsito, sistema autónomo multi-homed y sistema autónomo rama "stub".

Figura 1.5 Estructura genérica de la red Internet

Un sistema autónomo de tránsito se caracteriza por interconectar y direccionar el tránsito de datos entre dos o más sistemas autónomos. El sistema autónomo ISP 2 "AS 60" que se muestra en la figura 1.5 es un sistema autónomo del tipo tránsito ya que si algún computador que pertenece al sistema autónomo Empresa 3 "AS 120" establece comunicación con otro computador que pertenece al sistema autónomo Empresa 1 "AS 100" la única vía de tránsito de los datos es a través de los sistemas autónomos ISP 1 e ISP 2 "AS 50 y AS 60". Los sistemas autónomos AS 50 y AS 60 que se presentan en la figura 1.5 son sistemas autónomos del tipo tránsito.

Un sistema autónomo multi-homed se caracteriza por estar interconectado con dos o más sistemas autónomos pero el mismo no es utilizado como tránsito. El sistema autónomo empresa 2 "AS 110" que se muestra en la figura 1.5es un sistema autónomo del tipo multi-homed ya que está conectado a los sistemas autónomos AS 50 y AS 60 y el mismo no es utilizado como tránsito para que los computadores que forman parte del sistema autónomo AS 60 y AS 50 puedan comunicarse. El sistema autónomo AS 110 que se presenta en la figura 1.5 es un sistema autónomo del tipo multi-homed.

Un sistema autónomo stub se caracteriza por estar conectado con un solo sistema autónomo. Los sistemas autónomos AS 100 , AS 120 y AS 140 que se presentan en la figura 1.5 son sistemas autónomos del tipo stub.

Los protocolos de enrutamiento utilizados para interconectar los sistemas autónomos forman parte del grupo de protocolos EGP "Exterior Gateway Protocol". El protocolo BGP4 (RFC-1771) es el protocolo de enrutamiento utilizado para interconectar los sistemas autónomos que forman parte de la red Internet. Los protocolos de enrutamiento para interconectar a las redes que forman parte de un sistema autónomo forman parte del grupo de protocolos IGP "Interior Gateway Protocol". Los protocolos RIP (RFC-1923 y RFC-1723) y OSPF (RFC-1247) son los protocolos de enrutamiento más comunes para interconectar a las redes que forman parte de un sistema autónomo.

La interconexión de los puntos de acceso a la red "Network Access Point NAP" es la columna vertebral de la red Internet. Los puntos de acceso a la red "NAP" por lo general son utilizados (y muchos de ellos administrados) por los proveedores de servicio para interconectar sus sistemas autónomos a la red Internet formando de esta manera una red de escala mundial "Internet". En la figura 1.6 se presenta una configuración típica de un NAP la cual está compuesta por un grupo de swicthes ATM "Asyncronous Transfer Mode" full interconectados que permiten la interconexión de los enrutadores que pueden formar parte de los diferentes sistemas autónomos. Para centralizar la transferencia de rutas entre los enrutadores interconectados por los switches ATM e incrementar el rendimiento y estabilidad de la red se hace uso de un servidor de rutas. Cada uno de los enrutadores además de estar interconectados a la red ATM están conectados a un o unos switches con el fin de formar los puntos de conexión "Points of Presence POP" que permiten la conexión de redes. Estos puntos de conexión por lo general son de las siguientes tecnologías: Ethernet, ATM o Frame Relay. En el siguiente URL http://www.ep.net/ se pueden conocer como están distribuidos los puntos de acceso de la red Internet.

Figura 1.6 Puntos de acceso

Politicas de enrutamiento entre sistemas autónomos

En la figura 1.7 se presentan 4 sistemas autónomos AS1, AS2, AS3 y AS4 y cada uno de ellos están relacionados a través de una política de enrutamiento la cual permite la comunicación entre los sistemas autónomos. La relación entre cada sistema autónomo presentado en la figura está basado por la siguiente política de enrutamiento: el sistema autónomo AS1 origina el prefijo 24.12.0.0/16 y dicho prefijo define al bloque de direcciones IP que pertenecen al sistema autónomo AS1.

Figura 1.7 Politicas de enrutamiento

Cada uno de los sistemas autónomos AS2, AS3 y AS4 conocen de la ruta "24.12.0.0/16" a través de la siguiente política de enrutamiento la cual es definida por los protocolos EGP y para el caso de la red Internet es el protocolo Border Gateway Protocol versión 4 "BGP4".

-. El sistema autónomo AS1 exporta el prefijo "24.12.0.0/16" al sistema autónomo AS2 y el sistema autónomo AS2 lo importa.-. El sistema autónomo AS2 exporta el prefijo "24.12.0.0/16" al sistema autónomo AS3 y el sistema autónomo AS3 lo importa.-. El sistema autónomo AS3 exporta el prefijo "24.12.0.0/16" al sistema autónomo AS4 y el sistema autónomo AS4 lo importa.

De esta manera cada uno de los sistemas autónomos AS2, AS3 y AS4 pueden tener acceso al bloque de direcciones IP definidas por el prefijo 24.12.0.0/16. El standard para definir las políticas de enrutamiento entre sistemas autónomos en la red Internet es el RFC 2622 "Routing Policy Specification Language RPSL". RPSL es un lenguaje orientado a objetos cuya función es describir las políticas de enrutamiento de cada sistema autónomo.

Protocolos ARP e ICMP

Protocolo ARP

El protocolo IP debe conocer la dirección fisica del computador destino para que la capa de enlace pueda proceder con la transmisión de paquetes IP. Para ello el protocolo IP hace uso del protocolo de resolución de direcciones "ARP Address Resolution Protocol". La función de este protocolo es dar a conocer al protocolo IP la dirección física asociada a la dirección IP destino. Una vez que el protocolo IP conoce la dirección física asociada a una dirección IP la capa de enlace puede proceder con el envío del frame. En la siguiente figura 1.7 podemos apreciar la cabecera del protocolo ARP:

16 bits Hardware type

16 bits Protocol type

8 bits Octet length of hardware address (n)

8 bits Octet length of protocol address (m)

16 bits Operation code (solicitus o respuesta)

noctets fuente hardware address

moctets fuente protocol address

noctets destino hardware address

moctets destino protocol address

Figura 1.7 Cabecera del protocolo ARP

La función de cada uno de los campos es la siguiente:

-. Hardware address space. Especifica el tipo de hardware. Ejemplo: Ethernet.-. Protocol address space. Especifica el tipo de protocolo.-. Hardware address length. Especifica la longitud(en bytes) de la dirección de hardware del paquete. Para los standares IEEE 802.3 e IEEE 802.5 son 6 Bytes.-. Protocol address length. Especifica la longitud en bytes de las direcciones del protocolo. Para IP será de 4 bytes.-. Operation code. Especifica si se trata de una solicitud (1) o una respuesta de una solicitud(2) ARP.-. Fuente/Destino hardware address. Contiene las direcciones físicas del computador destino y fuente. En IEEE 802.3 son direcciones de 48 bits.-. Fuente/Destino protocol address. Contiene las direcciones del protocolo IP del computador destino y fuente. En TCP/IP son direcciones IP de 32 bits.

Para el paquete de solicitud, la dirección de hardware del computador destino es el único campo indefinido del paquete.

Es importante resaltar que el formato de una dirección física utilizada por los protocolos 802 es el siguiente:

1Byte - 2Byte - 3Byte - 4Byte - 5Byte - 6Byte

Los bytes 1, 2 y 3 pertenecen al identificador OUI "Identificador único de la organizacion". Este identificador es asignado por la IEEE a los fabricantes de hardware o software que soliciten un OUI. Los bytes 4, 5 y 6 son asignados por el fabricante de hardware. La IEEE tiene la responsabilidad de asignar un único OUI. Esto implica que por cada OUI asignado el fabricante puede fabricar hasta 2^24 interfaces de red.

El formato de una dirección física 802 "MAC" fuente es distinta al formato de una dirección destino. El formato del primer byte de una direccion MAC fuente es el siguiente:

+-+-+-+-+-+-+-+-+

|0 1 2 3 4 5 6 7|

+-+-+-+-+-+-+-+-+

-. Si Bit 1 es igual a 0 implica que la direccion MAC tiene sentido global.-. Si Bit 1 es igual a 1 implica que la direccion MAC tiene sentido local.

En el diseño inicial de protocolo Ethernet no existía el concepto de sentido local. Todas las direcciones en ese momento tenían sentido global únicamente. Cuando el protocolo Ethernet fue standarizado por la IEEE y absorbido por el grupo 802 se tomó la decisión de incorporar el sentido local en una dirección MAC. El sentido local de una dirección MAC permite al administrador de la red asignar los bytes 4, 5 y 6. El sentido global de una dirección MAC es la dirección MAC asignada por el fabricante y no puede ser manipulada por el administrador de la red.

El bit 0 es utilizado por los protocolos Token Ring y FDDI únicamente y su función es inidicar la presencia del parámetro de enrutamiento RII en una trama Token Ring o FDDI. El valor de este bit es igual a cero para las tramas Ethernet.

El formato del primer byte de una dirección MAC destino es la siguiente:

+-+-+-+-+-+-+-+-+

|0 1 2 3 4 5 6 7|

+-+-+-+-+-+-+-+-+

-. Si Bit 0 es igual a 0 implica que la dirección MAC destino es UNICAST.-. Si Bit 0 es igual a 1 implica que la dirección MAC Destino es MULTICAST.-. Si Bit 1 es igual a 0 implica que la dirección MAC tiene sentido global.-. Si Bit 1 es igual a 1 implica que la dirección MAC tiene sentido local.

Es importante resaltar que la dirección MAC destino con valor FF-FF-FF-FF-FF-FF es una dirección física del tipo MULTICAST donde muchos protocolos interpretan está dirección como una dirección broadcast.

ARP Gratuito

Cada vez que un computador inicia la configuración de una interface de red que hace uso del protocolo ARP, el protocolo ARP envía un paquete ARP con el fin de determinar si su dirección IP o dirección física está siendo utilizada por otro computador y así ofrecer la oportunidad a los demás computadores de actualizar su ARP Cache.

En un paquete ARP gratuito la dirección fisica destino es igual a la dirección física Fuente, y la dirección IP destino es igual a la dirección IP fuente. Si algún computador de la red local detecta un paquete ARP gratuito cuya dirección IP es la misma que la configurada en su interface de red el mismo envía un paquete ARP indicando su dirección IP y dirección física al computador que transmitió el ARP gratuito. De esta manera el computador que envió el ARP gratuito genera un mensaje de advertencia indicando que dicha dirección IP está siendo utilizada por otro computador.

Protocolo de mensajes de control Internet "ICMP"

El Protocolo IP utiliza el protocolo de mensajes de control Internet "ICMP Internet Control Message Protocol" para informar de los errores que pueden ocurrir durante el enrutamiento de paquetes IP. El protoclo ICMP utiliza el soporte básico de IP como si se tratara de un protocolo de nivel superior. Sin embargo, ICMP es realmente una parte integral del protocol IP, y debe ser implementado por todo módulo IP.

Los mensajes ICMP son enviados en varias situaciones: por ejemplo, cuando un datagrama no puede alcanzar su destino, cuando un enrutador no dispone de capacidad de almacenamiento temporal para reenviar un paquete IP, y cuando el enrutador puede dirigir al computador para enviar el tráfico por una ruta más corta. El propósito de estos mensajes de control no es hacer a IP fiable, sino suministrar información sobre los problemas en el entorno de comunicación.Los mensajes ICMP se envían usando la cabecera IP básica. El primer octeto de la parte de datos del datagrama es el campo de tipo ICMP; el valor de este campo determina el formato del resto de los datos. Los campos etiquetados como "no usado" están reservados para posteriores extensiones y deben ser cero al ser enviados, y los receptores no deberán usar estos campos (excepto para incluirlos en la suma de control).

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Tipo | Código | Suma de Control |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| sin usar |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Cabecera Internet |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 1.8 Cabecera ICMP

A continuación se presenta un resumen de los tipos de mensajes.

0 Eco Respuesta ("Echo Reply")3 Destino Inaccesible ("Destination Unreachable")4 Disminución del tráfico desde el origen ("Source Quench")5 Redirección ("Redirect")8 Eco ("Echo")11 Tiempo Superado ("Time Exceeded")12 Problema de Parámetros ("Parameter Problem")13 Marca de Tiempo ("Timestamp")14 Respuesta de Marca de Tiempo ("Timestamp Reply")15 Solicitud de Información ("Information Request")16 Respuesta de Información ("Information Reply")

Parámetros de configuración. Caso de estudio Linux Debian versión Woody

Asumiendo que el Kernel del sistema operativo Linux tiene configurado el manejador "driver" de la tarjeta de red y el protocolo TCP-IP, el siguiente paso es configurar los siguientes parámetros de configuración:

-. Dirección IP de la tarjeta de red.-. Máscara de la dirección IP.-. Gateway o enrutador de salida.-. Dirección IP broadcast.

Para configurar dichos parámetros en el sistema operativo Linux "Debian versión Woody" el procedimiento es el siguiente:

1-. Incluir los parámetros de configuración mencionados anteriormente en el archivo interfaces el cual está ubicado en el directorio /etc/network/. Ejemplo:

lupolo@pc-1:/etc/network$ more interfaces# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)# The loopback interfaceiface lo inet loopback# The first network card - this entry was created during the Debian installation# (network, broadcast and gateway are optional)

auto eth0iface eth0 inet static # Reemplazar static por DHCP si lo requiereaddress 192.168.0.30 # Si la interface esta configurada para DHCP este parametro de configuración no es necesario.netmask 255.255.255.0 # Si la interface esta configurada para DHCP este parametro de configuración no es necesario.network 192.168.0.0 # Si la interface esta configurada para DHCP este parametro de configuración no es necesario.broadcast 192.168.0.255 # Si la interface esta configurada para DHCP este parametro de configuración no es necesario.gateway 192.168.0.1 # Si la interface esta configurada para DHCP este parametro de configuración no es necesario.

-. iface lo inet loopback. Define a la interface lo "loopback local-host" con la dirección IP 127.0.0.1.-.iface eth0 inet static. Define los siguientes parámetros de configuración para la interface de red Ethernet 0:

-. address 192.168.0.30. Dirección IP de la interface Ethernet 0.-. netmask 255.255.255.0. Máscara de la red de la interface Ethernet 0.-. network 192.168.0.0. Define la red que pertenece a la dirección IP 192.168.0.30.-. broadcast 192.168.0.255. Define la dirección broadcast a la que pertenece a la dirección IP 192.168.0.30.-. gateway 192.168.0.1. Define el enrutador de salida de la red 192.168.0.

2-. Para activar los parámetros de configuración en las interfaces Eth0 y lo se reinicia el servicio con el siguiente script: "/etc/init.d/networking restart". Una vez ejecutados dicho script con el comando ifconfig y route -v se puede verificar que los parámetros de configuración fueron aplicados a las interfaces Eth0 y lo.

-. ifconfig eth0eth0 Link encap:Ethernet HWaddr 00:06:5B:BB:D9:1Dinet addr:192.168.0.30 Bcast:192.168.0.255 Mask:255.255.255.0BROADCAST MULTICAST MTU:1500 Metric:1RX packets:15 errors:0 dropped:0 overruns:0 frame:0TX packets:22 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:100RX bytes:1372 (1.3 KiB) TX bytes:2289 (2.2 KiB)Interrupt:11 Base address:0xec80-. ifconfig lolo Link encap:Local LoopbackLOOPBACK MTU:16436 Metric:1RX packets:0 errors:0 dropped:0 overruns:0 frame:0TX packets:0 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:0RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)-. route -vKernel IP routing tableDestination     Gateway     Genmask    Flags    Metric Ref Use Ifacelocalnet            *           255.255.255.0    U          0       0   0     eth0default        192.168.0.1     0.0.0.0           UG       0       0   0     eth0

Conclusiones

-. La capa de enrutamiento - protocolo IPv4 - ofrece a la capa de transporte un servicio no orientado a conexión que cumple con las siguientes funciones:

-. Enrutamiento, Fragmentación y Reensamblaje.-. Clasificación de servicios.-. Tiempo de vida de un paquete.

-. El proceso de enrutamiento de un paquete IP puede ser generalizado por el siguiente algoritmo de enrutamiento:

1. Determinar la dirección IP del computador destino.2. ¿La red de la direcció IP destino es igual a la red de la dirección IP del computador fuente? Si la respuesta es sí ir al paso 3 de lo contrario ir al paso 4.3. Obtener la dirección física asociada a la dirección IP destino haciendo uso del protocolo ARP y transmitir el paquete con la interface de red apropiada.4-. ¿La red destino se encuentra listada en la tabla de rutas? Si la respuesta es sí enviar el paquete IP a la dirección IP asociada a la ruta hasta alcanzar a la red del computador destino y proceder con el paso 3.. Si la respuesta es no, utilizar la ruta por defecto. Si la ruta por defecto no está configurada: generar un paquete ICMP indicando el error "red inalcanzable".

-. Durante el proceso de enrutamiento, un paquete IP puede ser fragmentado cuando el tamaño del mismo es mayor que la máxima unidad de transferencia de datos - MTU Maximun Transfer Unit - del enlace que une a dos redes TCP-IP. Los paquetes IP fragmentados sólo son reensamblados cuando lleguan al computador destino.

-. Debido a que el protocolo IP es un protocolo no orientado a conexión el mismo hace uso de un mecanismo que determina el tiempo de vida "TTL Time to Live" de un paquete IP. Este tiempo de vida fijado por el computador Origen es reducido a uno cada vez que el paquete IP es enrutado. Si el tiempo de vida se reduce a cero antes de que el paquete IP llegue a su destino, el paquete IP es destruido.

-. Una de las funciones del protocolo IPv4 es establecer el direccionamiento lógico de una red con el objetivo de que dos o más computadores puedan establecer el proceso de comunicación.

-. Para definir una sub-red basado en el RFC-950 las siguientes reglas deben ser respetadas:

1-. Cada uno de los bit que definen al campo sub-red de una dirección IP no puede tener el valor 0 y tampoco el valor de los bit del campo computador puede ser igual a 0, ya que se estaría definiendo a la red de la sub-red.2-. Cada uno de los bit que conforman al campo computador de una dirección IP no puede tener el valor 0 ó 1. Ya que si todos los bit son iguales a 0 se estaría definiendo a la sub-red. Y si todos los bit del campo computador son iguales a 1 se estaría definiendo a la dirección broadcast de la sub-red.

-. El uso del prefijo de una red "RFC1812, RFC1517, RFC1518, RFC1519, RFC1520" elimina las reglas definidas anteriormente "RFC 950".

-. El prefijo de una dirección IP determina un bloque de direcciones IP y su nivel jerárquico.

-. EL prefijo de una dirección IP elimina el campo clase A, B o C del registro de una dirección IP.

-. Un sistema autónomo goza de uno o más prefijos de direcciones IP. Cada prefijo define al bloque direcciones IP asignadas a un sistema autónomo. Cada prefijo que pertenece a un sistema autónomo está relacionado a una política de enrutamiento que define la interconexión lógica entre sistemas autónomos y define de manera implícita los diferentes tipos de sistemas autónomos: Sistema autónomo de transito, sistema autónomo multi-homed y sistema autónomo rama "stub".

-. Los protocolos de enrutamiento utilizados para interconectar los sistemas autónomos forman parte del grupo de protocolos EGP "Exterior Gateway Protocol". El protocolo Border Gateway Protocol "BGP4 " es el protocolo de enrutamiento utilizado para interconectar los sistemas autónomos que forman parte de la red Internet.

-. Los protocolos de enrutamiento para interconectar a las redes que forman parte de un sistema autónomo forman parte del grupo de protocolos IGP "Interior Gateway Protocol". Los protocolos Routing Information Protocol "RIP" y Open Shortest Path First "OSPF" son los protocolos de enrutamiento más comunes para interconectar a las redes que forman parte de un sistema autónomo.

Referencias Bibliográficas

RFC 791, "Protocolo de Internet".

RFC 792, "Internet Control Message Protocol".

RFC 826, "Un Ethernet Address Resolution Protocol".

RFC 917, "Internet subredes".

RFC 950 "Subnetting procedimiento estándar de Internet".

RFC 1180, "Un Tutorial de TCP / IP".

RFC 1122, "Requisitos para hosts de Internet - Comunicación Capas".

RFC 1247, "OSPF Versión 2".

RFC 1517, "Declaración de Aplicabilidad de la Implementación de Classless Inter-Domain Routing (CIDR).

RFC 1518, "Una Arquitectura para la asignación de direcciones IP con CIDR".

RFC 1519, "Un Asignación de direcciones y estrategia de agregación".

RFC 1520, "Intercambio de información de enrutamiento a través de fronteras de proveedores en el entorno CIDR".

RFC 1531, "Dynamic Host Configuration Protocol".

RFC 1771, "A Border Gateway Protocolo 4 (BGP-4)".

RFC 1723, "RIP Versión 2 Llevar Información Adicional".

RFC 1812, "Requisitos para IP versión 4 Routers".

RFC 1918, "Asignación de direcciones para Internets privadas".

RFC 1923, "RIPv1 Aplicabilidad Declaración de Estado histórico".

RFC 2622, "Política de Enrutamiento Language Specification (RPSL)".

Día, JD, y Zimmermann, H.: "El modelo de referencia OSI", Proc. del IEEE, vol. 71, pp1334-1340, diciembre de 1983.

http://www.caida.org.

http://www.debian.org.

http://www.ep.net.

http://www.merit.edu

W. Richard Stevens, Unix Programming Network. Prentice-Hall 1990, ISBN 0-13-949876-1.

W. Richard Stevens, TCP / IP Ilustrated Volumen 1, Los protocolos. Prentice-Hall 1994, ISBN 0-201-63346-9.