Este tema trata de una de las técnicas usadas por los programadores, y administradores de sistemas para establecer la comunicación entre redes con diferentes topologías. En particular, se examina la forma que permite a un ordenador, usar un servicio de alto nivel de un protocolo, para canalizar tráfico de información IP a sistemas que usan otros protocolos.

Antes de entrar en materia, es conveniente el repaso de algunos conceptos a los que se hace referencia a lo largo del texto.

Los distintos niveles de red pueden ofrecer dos tipos de servicios diferentes a las capas superiores : uno orientado a conexión y otro sin conexión.

El servicio orientado a conexión se modeló basándose en el sistema telefónico. Para poder hablar con alguien se debe tomar el teléfono, marcar el número, hablar y colgar. De forma similar, para utilizar una red con servicio orientado a conexión, el usuario del servicio establece primero la conexión, la utiliza y después la termina. El aspecto fundamental de la conexión es que actúa de forma parecida a la de un tubo : el que envía, introduce objetos por un extremo y el receptor los recoge, en el mismo orden, por el otro extremo.

A diferencia de esto el servicio sin conexión se asemeja al sistema postal. Cada mensaje lleva consigo la dirección completa de destino y cada uno de ellos se encamina, de forma independiente, a través del sistema. Normalmente, cuando dos mensajes se envían al mismo destino, el primero que se envió será el primero en llegar. Es posible, sin embargo, que el primero que se envíe sufra un retardo y llegue antes el que se envió en segundo lugar. Con un servicio orientado a conexión es imposible que suceda esto. Por otro lado hemos de puntualizar que no todas las aplicaciones necesitan conexiones. A los paquetes independientes de un sistema sin conexión se les denomina datagramas por analogía a los telegramas.

Los puentes son dispositivos del nivel de enlace cuyo propósito fundamental es la conexión de redes de área local (LAN). Funcionan en modo de almacenamiento y reenvio de forma que almacenan la trama enviada por el emisor y la reexpiden después de haberla tratado. Se trata de un dispositivo de cierta complejidad hardware que funciona a un nivel superior que la simple transmisión de bits entre un punto y otro.

Las organizaciones que instalaron redes antes de que los protocolos TCP/IP estuvieran disponibles, tuvieron que escoger el conjunto de protocolos, que usaba en particular, la empresa informática vendedora. Como resultado de esta evolución en las redes, la mayoría de las grandes organizaciones tienen diferentes grupos de máquinas, donde cada grupo utiliza su propio conjunto de protocolos.

Por ejemplo, la Figura 1 ilustra una organización con dos sedes que utiliza tres redes. Cada sede tiene su propia Ethernet . Una red de área extensa (WAN) que utiliza los protocolos X.25 conecta los host de las dos sedes. La figura muestra un subconjunto de máquinas conectadas a cada red.

Normalmente, una red TCP/IP consiste en un conjunto de hosts que a nivel físico se interconectan mediante puentes (gateways) y routers. Todos los host y puentes en la red deben usar los protocolos TCP/IP. Del mismo modo que una red que utiliza los protocolos DECNET consta de una serie de ordenadores y enlaces físicos que usan DECNET exclusivamente. Sin embargo, debido a que un servicio del nivel de transporte puede conducir paquetes de un punto a otro entre redes, con la misma facilidad con que una conexión hardware lo haría, sería posible sustituir una línea física de un sistema de transmisión de paquetes por un determinado servicio de conexión del nivel de transporte.

Hay muchas redes que funcionan mediante el uso de los servicios de conexión a nivel de transporte en lugar de conexiones físicas. Por ejemplo, consideremos las redes de la Figura 1 de nuevo. Supongamos que la organización decide interconectar sus dos Ethernet para configurar una sola red TCP/IP que permita a todos los host pertenecientes a cada una de ellas comunicarse con la otra. La estrategia más común a seguir, sería instalar dos puentes entre las Ethernet. Sin embargo, si una gran distancia separa a las dos Ethernet, el coste de introducir una línea alquilada dedicada a interconectar las dos redes puede ser prohibitivo. Este coste adicional puede ser especialmente difícil de justificar teniendo en cuenta que la organización ya dispone de una red X.25 para conectar las dos sedes.

La Figura 2 ilustra como la organización de la Figura 1 puede usar la capacidad de conexión de la red X.25 para implantar una conexión TCP/IP entre las dos redes.

Con los puentes instalados, un usuario de cualquier host puede invocar el software de cliente estándar de TCP/IP que lo conecta a un servidor de cualquier host. Las comunicaciones cliente-servidor pueden establecerse a través de una misma Ethernet o bien atravesar la red X.25 para llegar a la otra. Ni los usuarios, ni las aplicaciones cliente-servidor, necesitan saber que los datagramas pasan a través de la X.25 cuando viajan desde una Ethernet a otra. Las dos redes Ethernet simplemente forman parte de una red TCP/IP. De esta manera, los hosts que usan X.25 en la red de área extensa, no necesitan cambios. Estos pueden continuar con sus comunicaciones sin interferir de manera alguna en el tráfico TCP/IP ya que los circuitos virtuales que usan, actuarán de forma independiente con respecto a la nueva conexión de los puentes.

En la topología que ilustra la Figura 2, las comunicaciones con TCP/IP necesitan sólo un circuito virtual a través de la X.25 ya que la organización tiene sólo dos sedes. Si la organización se expandiera añadiendo nuevas sedes, podría extender la topología colocando un puente en cada nueva sede, creando de esta manera circuitos adicionales a través de la red X.25 para interconectar cada nuevo puente a los puentes de las sedes existentes.

El esquema de circuitos descrito, no pude expandirse a cualquier número de sedes, ya que la mayoría de las redes X.25 limitan el número de circuitos que un ordenador puede direccionar simultáneamente. Normalmente, el hardware limita a la máquina a 16 ó 32 circuitos virtuales. Una organización con N sedes necesita (N*(N-1))/2 circuitos para interconectarse totalmente. De este modo, un puente necesita 15 conexiones si hay 6 sedes y supera las 32 conexiones cuando la organización tiene 9 sedes.

Por supuesto, la ampliación del sistema es posible, ya que cada nuevo puente que se añada no necesitará un circuito hacia todos los destinos posibles. Sin embargo, para reducir costes, la mayoría de las sedes que usan X.25 para el transporte de datagramas funcionan de un modo diferente, se abren circuitos dependiendo de la demanda y se cierran los que no estén siendo usados. Cuando un datagrama llega a un puente, este chequea la dirección de destino para determinar la ruta que debe seguir. El chequeo del encaminamiento produce una next-hop address , dirección del próximo puente al que debe ser enviado el datagrama. Si esta dirección pertenece a una sede remota, el puente consultará su tabla de circuitos virtuales X.25 . Si existe un circuito hacia el destino en cuestión, el puente enviará el datagrama a través del circuito. Si el circuito no existe, el puente "abrirá" un nuevo circuito hacia el destino deseado de forma dinámica.

Si un puente no tiene un circuito libre cuando es necesario abrir uno nuevo, se cerrará alguno de los existentes para permitir la creación del nuevo. El problema consiste en determinar qué circuito cerrar. A menudo los puentes siguen la misma política que un sistema de paginación de memoria: se cierra el circuito menos recientemente usado (LRU). Después de enviar los datagramas a través del nuevo circuito virtual , el puente abandona el circuito abierto. Normalmente los datagramas enviados provocarán una réplica del receptor, por tanto, si se mantiene el circuito abierto se minimizan retrasos y costes.

Mediante la apertura y cierre dinámicos de circuitos virtuales, un puente puede limitar el número de conexiones simultáneas necesarias sin que se pierda la capacidad de comunicación con todos los puntos. El puente solo necesita tener un circuito abierto para cada lugar con el que se establece comunicación en un momento determinado.

El término encapsulado describe el proceso de colocar un datagrama IP dentro de un paquete de red para que pueda ser enviado a través de la red subyacente. El encapsulado se refiere a como el interface de la red usa el paquete de acuerdo con el hardware. Por ejemplo, dos host que se comunican a través de una Ethernet usando IP, encapsulan cada datagrama en un solo paquete Ethernet en las transmisiones. El encapsulado estándar para TCP/IP especifica que un datagrama IP, debe ocupar la zona de datos del paquete Ethernet y que el campo tipo de dicho paquete debe estar puesto a un determinado valor, que denota el contenido de un datagrama IP.

Por otro lado, el término canalización (del inglés Tunneling), se refiere al uso de un servicio de alto nivel de la capa de transporte para transmitir paquetes o mensajes a otro servicio. El ejemplo de la figura 2 muestra como los puentes pueden hacer una canalización a través de un servicio X.25 para enviar datagramas IP de un lugar a otro. La principal diferencia entre la canalización y el encapsulado reside en que IP transmita los datagramas en paquetes hardware o use un servicio del nivel de transporte para enviarlos.

Cuando TCP/IP fueron definidos por primera vez, se experimentó con la intención de ver como se podría desarrollar el software IP para llevar a cabo la canalización a través de redes ya existentes (como X.25) y enviar datagramas. Los motivos estaban claros: muchas organizaciones disponían de redes instaladas que usaban otros sistemas. Sorprendentemente esta tendencia ha cambiado de sentido. Hoy en día la canalización se realiza debido a que los proveedores de redes usan protocolos IP para recibir paquetes desde protocolos distintos de TCP/IP. Ahora se desarrolla software para adaptar otros protocolos a las comunicaciones TCP/IP y antes se hacía lo contrario.

Comprender este cambio en cuanto a la canalización requiere que entendamos primero la evolución que han seguido las redes. A medida que TCP/IP se hacían cada vez más populares, se fue convirtiendo en el mecanismo estándar de envío de paquetes en muchas compañías. De hecho, es IP actualmente lo que proporciona la gran capacidad de conexión existente entre los ordenadores de la mayoría de las organizaciones.

Para ilustrar las facilidades que ofrece IP con respecto a otros protocolos, consideremos que dos ordenadores de una organización necesitan comunicarse usando un protocolo particular desarrollado por el proveedor del sistema. En lugar de añadir líneas físicas para efectuar la conexión entre los dos ordenadores, el administrador del sistema puede considerar el sistema de la organización, como si fuera una gran red, haciendo que el software de protocolo de los dos ordenadores intercambie mensajes mediante el envío de estos en datagramas IP. Actualmente hay software disponible que usa IP para transportar tráficos de información IPX (Novell), SNA (IBM) y de otros protocolos de alto nivel. A demás, los investigadores han desarrollado las vías que permiten a las redes IP transportar tráficos OSI, permitiendo a los proveedores de sistemas construir protocolos OSI de alto nivel antes de haber implementado el software de las capas más bajas.

Para comprender como trabaja la canalización al nivel de aplicación, pensemos en dos ordenadores conectados a una red X.25. Supongamos que el programador desea correr una aplicación UDP de cliente en uno y una aplicación UDP de servidor en otro. Normalmente, los programadores de aplicaciones no modifican el sistema operativo. Sin embargo, si el sistema operativo de los dos ordenadores no soporta el protocolo TCP/IP y la canalización a nivel de transporte, el programador puede considerar inconveniente e incluso imposible usar UDP o hacer la canalización de datagramas IP a través de la X.25.

En estos casos, la canalización al nivel de aplicación hace viable la comunicación entre clientes y servidores a través de una red X.25. para hacer esto, el programador debe construir una biblioteca de rutinas que simulan el interfaz socket. La biblioteca de simulación debe permitir a una aplicación crear un socket UDP activo o pasivo, y enviar o recibir datagramas UDP. Las rutinas de la biblioteca de simulación del socket aceptan las llamadas a rutinas estándar socket (socket, send, receive,...) y realizan las operaciones para direccionar y manipular las estructuras de datos locales, así como la transmisión de mensajes a través de la red X.25. Cuando un cliente hace una llamada socket para crear un socket, la rutina socket de la biblioteca crea una conexión X.25 con el servidor. Cuando el cliente o el servidor hacen una llamada a la rutina send para transmitir un mensaje, la rutina send de la biblioteca transfiere el datagrama UDP a través de la conexión X.25.

Cuando la biblioteca de simulación socket ha sido creada, los programadores pueden compilar cualquier programa UDP de cliente o servidor usando llamadas a funciones de dicha biblioteca. La Figura 3 ilustra la estructura software resultante.

La canalización consiste en el envío de paquetes entre ordenadores mediante el uso de un sistema de liberación de paquetes de la capa de transporte, en lugar de enviarlos directamente a través de conexiones físicas. En un principio el empleo de la canalización IP sobre las redes ya existentes fue motivado por las organizaciones que disponían de redes de área extensa totalmente instaladas. Estas organizaciones querían evitar el coste de añadir nuevas conexiones físicas para usar IP. En los centros de investigación se diseñaron vías que permitían a IP usar las redes existentes para la transferencia de paquetes. IP trata al nivel de transporte como a un simple enlace hardware; el nivel de transporte trata al tráfico IP como si se tratase de envíos de alguna aplicación.

IP se ha convertido en el sistema que provee de una mayor capacidad de interconexión. A consecuencia de esto, el trabajo actual en canalización se concentra en la búsqueda de los caminos que permitan usar IP como un sistema de transmisión que puede transportar paquetes desde otros protocolos de red. Actualmente muchos proveedores de redes incorporan software a sus sistemas para permitir la comunicación mediante IP.