MX2008003407A - Comunicaciones tolerantes a fallas en redes dirigidas. - Google Patents

Abstract

Un metodo para proveer comunicaciones de red tolerantes a fallas entre una pluralidad de nodos para una aplicacion, que consiste en proveer una pluralidad de trayectorias de comunicaciones iniciales a traves de una pluralidad de redes acopladas a la pluralidad de nodos, recibir un paquete de datos en un nodo de envio desde la aplicacion, el nodo de envio es una de la pluralidad de nodos, el paquete de datos esta destinado por la aplicacion a una direccion en una de la pluralidad de nodos, y seleccionar una primera trayectoria seleccionada para el paquete de datos de entre una pluralidad de trayectorias de comunicaciones iniciales en donde la primera trayectoria seleccionada es una trayectoria preferida.

Description

COMUNICACIONES TOLERANTES A FALLAS EN REDES DIRIGIDAS Antecedentes de la Invención En un entorno de redes de computadora, múltiples nodos pueden comunicarse entre sí en una red. En caso de que la red experimentara fallas, la comunicación entre los nodos puede verse interrumpida. Breve Descripción de la Invención A continuación se presenta un resumen simplificado de la descripción con el fin de proveer un entendimiento básico al lector. Este resumen no es un panorama extenso de la descripción y no identifica elementos clave o críticos de la invención o delinea el alcance de la invención. Su único propósito es presentar algunos conceptos descritos en la presente en una forma simplificada como una introducción a la descripción más detallada que se presenta más adelante. Los siguientes ejemplos proveen comunicación de red de computadora tolerante a fallas mediante arquitecturas de red únicas que requieren consideración mínima por programa de aplicación que opera en nodos en redes. Muchas de las características se apreciarán más fácilmente conforme se entiendan mejor por referencia a la siguiente descripción detallada considerada en conjunto con los dibujos que la acompañan.

Breve Descripción de las Figuras La presente descripción se entenderá mejor a partir de la siguiente descripción detallada leída en conjunto con los dibujos que la acompañan, en los que: La figura 1 es un diagrama de bloque que muestra una arquitectura de red ejemplar. La figura 2 es un diagrama de bloque que muestra un entorno de computadora en red incluyendo dos nodos ejemplares acoplados a través de dos redes. La figura 3 es un diagrama de bloque que muestra un controlador de comunicaciones tolerante a fallas, NETFT. La figura 4 es un diagrama de bloque que muestra una arquitectura de comunicaciones tolerante a fallas incluyendo NETFT y una aplicación. La figura 5 es un diagrama de flujo que muestra datos que fluyen a través de un entorno de comunicaciones tolerante a fallas incluyendo un nodo fuente y un nodo destino acoplado mediante una Trayectoria A sobre una red 1 y una Trayectoria B sobre una red 2. La figura 6 es un diagrama de flujo que muestra datos a través del entorno de comunicaciones tolerante a fallas mostrado en la figura 5 con la adición de varias fallas de comunicaciones posibles. La figura 7 es un diagrama de bloque que muestra otro ejemplo de un controlador de comunicaciones tolerante a fallas, NETFT. La figura 8 es un diagrama de bloque que muestra una arquitectura de comunicaciones tolerante a fallas incluyendo NETFT y una aplicación. La figura 9 es un diagrama de flujo que muestra datos que fluyen a través de un entorno de comunicaciones tolerante a fallas incluyendo un nodo de fuente y un nodo destino acoplado mediante una Trayectoria A sobre una red 1 y una Trayectoria B sobre una red 2. La figura 10 es un diagrama de flujo que muestra datos que fluyen a través de un entorno de comunicaciones tolerante a fallas mostrado en la figura 9 con la adición de varias fallas de comunicaciones posibles. La figura 11 es un diagrama de bloque que muestra un entorno de computación ejemplar en el que puede implementarse la tecnología descrita con anterioridad. Números de referencia iguales se usan para designar partes iguales en los dibujos adjuntos. Descripción Detallada de la Invención La descripción detallada provista adelante en conjunto con los dibujos intenta ser una descripción de los ejemplos presentes y no pretende representar la única forma en la que los ejemplos pueden construirse o utilizarse. La descripción establece las funciones de ios ejemplos y la secuencia de pasos para construir y operar los ejemplos. Sin embargo, las mismas funciones o equivalentes y las secuencias pueden lograrse por diferentes ejemplos. Aunque los ejemplos de ia presente se describen e ilustran como implementados en un sistema de red y cómputo, el sistema descrito se provee como un ejemplo y no como una limitación. Como será evidente para los expertos en la técnica, los ejemplos de la presente son adecuados para aplicarlos en una variedad de diferentes tipos de sistemas de cómputo y redes. La figura 1 es un diagrama de bloque que muestra una arquitectura de red ejemplar 100. Una pila de red ("pila") generalmente se acopla con las aplicaciones de software a través de las interfaces de pila de red y/u otras interfaces para proveer funcionalidad de comunicaciones en red a las aplicaciones. Típicamente se dice que una aplicación está en (o acoplada a) la parte "superior" de la pila. Normalmente se dice que una red está en (o acoplada a) la parte "inferior" de la pila. Varios elementos de una pila de red puede referirse como en o cerca de la parte superior o inferior de la pila, o más arriba o abajo en la pila en relación entre sí. Por ejemplo, en la figura 1, el controlador de protocolo 130 está más arriba en la pila que NIC 180 que se muestra en la parte inferior de la pila en esta figura en particular. Varias ilustraciones de una pila de red pueden o no incluir ciertos elementos de pila, o pueden agrupar, ordenar o nombrar los elementos en diversas formas, dependiendo del propósito o enfoque de la ilustración, como se entiende por un experto en la técnica. El término "controlador" como se usa en la presente se refiere a un programa de control o similar que permite a un nodo operar con un dispositivo particular, tal como una impresora, tarjeta de interfaz de red, u otro subsistema de computadora, u operar con uno o más programas tales como pilas de red, controladores de protocolo, y/u otros programas de computadora o programación en firme o similares. Por ejemplo, un controlador de protocolo típicamente opera con una pila de red. Una aplicación puede pasar un paquete de datos a una pila destinada para una aplicación que opera en otro nodo. En este caso, los datos se dice que fluyen "hacia abajo" de la pila y son enviados sobre una red. Los daros recibidos por un nodo se dice fluyen "hacia arriba" de la pila hasta que alcanzan la aplicación destino. Dichos sistemas de redes son bien conocidos por los expertos en la técnica. En un ejemplo una pila se basa en la Especificación de Interfaz de Controlador de Red ("NDIS", por sus siglas en inglés) la cual define una interfaz de programación de aplicación estándar ("API") para tarjetas de interfaz de red ("NICs"), tales como NIC 180, y abstrae el hardware de la red de los consoladores de red. Los NDIS también especifican una interfaz estándar entre los controladores de red en capas, abstrayendo así controladores de nivel más bajo que administran hardware, tal como un controlador de minipuerto, de controladores de nivel más alto, tales como controladores de protocolo. Múltiples controladores de protocolo que se adaptan a NDIS también pueden coexistir en un solo nodo. Además, si un nodo incluye múltiples NICs, quizá porque está conectado a más de una red, las NDIS dirigen el tráfico de la red a la NIC adecuada a través de su controlador relacionado como se indica por el tráfico. Se muestra una ilustración de las NDIS en la figura 1. Otros estándares, tecnologías y/o arquitecturas de pilas de redes, tal como la Interfaz de enlace de datos abierta ("ODI"), la Interfaz de proveedor de enlace de datos ("DLPI"), la Interfaz de Controlador Uniforme ("UDI"), u otras tecnologías, pueden usarse con los siguientes ejemplos así como con modificaciones adecuadas, como entenderán los expertos en la técnica. Como cuestión de conveniencia, la terminología de NDIS y NDIS se usa con ejemplos a lo largo de la descripción, pero otros estándares, tecnologías y/o arquitecturas pueden usarse en todos estos ejemplos con las modificaciones adecuadas, a menos que se especifique de otra forma. Como se muestra en la figura 1, junto con la NIC 180 a través de NDIS 120 está el controlador de minipuerto 160. Un controlador de minipuerto típicamente interactúa con NDIS a través de una interfaz de minipuerto NDIS 162. El controlador de minipuerto 160 puede estar relacionado con la NIC 180 y puede administrar sus operaciones, incluyendo enviar y recibir datos a través de la NIC. El controlador de minipuerto 160 típicamente se interconecta con controladores de nivel más alto, tal como el controlador intermedio 140 y el controlador de protocolo 130. Un controlador de minipuerto se considera un controlador de NIC. Los minipuertos de NIC generalmente llevan a cabo las operaciones específicas de hardware necesarias para administrar una NIC particular con funcionalidad común o independiente de NIC provista por la NDIS. Un nodo puede incluir múltiples NICs con cada NIC generalmente asociado con un controlador de NIC. Algunos ejemplos en esta descripción muestran el uso del controlador de minipuertos pero, como será evidente para los expertos en la técnica, cualquier tipo de controlador de NIC o similar puede ser usado en estos ejemplos, a menos que se especifique de otra forma. El controlador de protocolo o transporte 130 se acopla a las NDIS 120 a través de una interfaz de protocolo NDIS 134. Los controladores de protocolo o los controladores de protocolo de transporte generalmente proveen la funcionalidad para crear, enviar y recibir paquetes de datos que son enviados de un nodo a otro a través de la pila de red y sobre una red. Como se conoce por los expertos en la técnica, un protocolo de transporte de suministro confiable o garantizado común puede ser TCP/IP (Protocolo de Control de Transmisión / Protocolo de Internet). El UDP (Protocolo de Datagrama de Usuario) sobre IP puede ser un protocolo de suministro no confiable o no garantizado común. Los TCP, UDP y/u otros protocolos tales como IPX/SPX (Intercambio de Paquetes entre Redes / Intercambio de Paquetes Secuenciados), pueden usarse con los siguientes ejemplos a menos que se establezca lo contrario. Los controladores intermediarios de NDIS ("IM") 140 se muestran entre los controladores de protocolo 130 y los minipuertos NIC de NDIS 160 en la figura 1. Para los controladores de protocolo IM, los controladores parecen ser minipuertos NDIS mientras que para los controladores NIC parecen controladores de protocolo. Los paquetes de datos que fluyen hacia arriba o abajo de la pila de red pasan a través de un controlador IM 140 que puede ignorar, inspeccionar, filtrar, reenviar, redirigir y/o modificar los paquetes de datos. Un controlador intermedio 140 también puede ser conocido como un controlador de filtro. La figura 2 es un diagrama de bloque que muestra un entorno de cómputo en red 200 incluyendo dos nodos de ejemplo 210 y 260 acoplados a través de dos redes 202 y 282. Los nodos 210 y 260 pueden ser las dos computadoras personales ("PCs"), computadoras de clientes, servidores, huéspedes, laptops, dispositivos portátiles, dispositivos electrónicos de consumo, o cualquier otro tipo de dispositivo de cómputo o procesamiento, máquinas o sistemas. Un ejemplo no limitativo de un tipo de sistema de cómputo se describe a detalle abajo con respecto a la figura FIG. 11. Los círculos 212, 214, 262, y 264 representan NICs relacionadas con sus nodos respectivos. Un ejemplo no limitativo de un tipo de NIC se describe abajo con respecto a la figura 11 como un adaptador de red 1113. Como se usa en la presente, el término nodo se refiere a cualquier sistema de cómputo, dispositivo o proceso que es atendible de forma única, o de otra manera identificable de manera única, en una red (e.g., red 202) y que es operable para comunicar con otros nodos en la red. Por ejemplo, y sin limitar, un nodo puede ser una computadora personal, una computador de servidor, un dispositivo manual o laptop, un dispositivo de tableta, un sistema multiprocesador, un sistema basado en microprocesador, un decodificador, un dispositivo electrónico de consumo, una PC en red, una minicomputadora, una computadora mainframe, o similar. Un ejemplo no limitativo de un nodo 210, en la forma de un sistema de cómputo, se establece más adelante con respecto a la figura 11. Las redes 202 y 282 pueden ser la misma red, pueden existir en las mismas o diferentes subredes, pueden acoplarse o aislarse lógica o físicamente entre sí, pueden usar tecnologías de red similares o diferentes, etc. En particular, las redes 202 y 282 pueden ser redes dirigidas, es decir, las redes incluyendo enrutadores que reenvían paquetes de protocolo dirigibles. Los protocolos dirigibles típicamente se consideran protocolos de comunicación utilizados para dirigir datos de una red a otra. Un ejemplo de un protocolo dirigible es TCP/IP. El envío de un paquete de datos en una forma dirigible implica usar un protocolo de transporte dirigible para dar formato y/o enviar el paquete de datos. Los expertos en la técnica estarán familiarizados con los protocolos dirigibles y las topologías, sistemas y arquitecturas de redes. En un ejemplo, las redes 202 y 282 pueden ser independientes entre sí de tal forma que si hay un problema o falla con una red es poco probable que afecte la condición operativa de la otra. En otros ejemplos, pueden usarse tres o más redes. En ejemplos en los que se desean grados mayores de tolerancia a fallas, puede emplearse un gran número de redes junto con la conectividad relacionada de nodos a esas redes, incluyendo un número similar de NICs instaladas en un nodo. NIC 212, relacionada con el nodo 210, se muestra con una dirección ejemplar de 172.56.48.37 y está acoplada con la red 1202. NIC 214, también relacionada con el nodo 210, se muestra con una dirección ejemplar de 197.71.48.38 y está acoplada a la red 2282. NIC 262, relacionada con el nodo 260, se muestra con una dirección ejemplar de 172.56.48.38 y también está acoplada a la red 1202. NIC 264, también relacionada con le nodo 260, se muestra con una dirección ejemplar de 197.71.48.39 y también es acoplada a la red 2282.

Estas direcciones pueden, en la práctica, ser direcciones IPv4 o IPv6 o similares, o cualquier otro tipo de dirección de red típicamente relacionado con el protocolo utilizado. Cada nodo puede incluir una o más NICs. Las flechas 201 y 203, también mostradas en la figura 11 como la flecha 1114, representan una primera ruta o trayectoria de comunicaciones ("Trayectoria A") sobre la red 1202 entre los nodos 210 y 260. Las flechas 281 y 283 representan una segunda ruta o trayectoria de comunicaciones ("Trayectoria B") sobre la red 2282 entre los nodos 210 y 260. En la práctica, puede haber una o más trayectorias sobre una o más redes entre los dos o más nodos en el entorno 200. El término "trayectoria" como se usa en la presente se define como una ruta de comunicaciones, o enlace de comunicaciones, entre los nodos en una red. Dicha ruta o enlace puede ser dinámico en que la ruta exacta entre nodos puede cambiar en el transcurso del tiempo. Los bloques 216 y 266 representan una aplicación y una pila de red, incluyendo un controlador de comunicaciones tolerante a fallas ("FT"), provisto en cada uno de los nodulos 210 y 260. El controlador FT del bloque 216 se muestra con una dirección ejemplar de 10.0.0.1 y el controlador FT de bloque 266 se muestra con una dirección ejemplar de 10.0.0.2. Estas direcciones se consideran típicamente direcciones virtuales, Estas direcciones pueden ser direcciones IPv4 o IPv6 o similares, o cualquier otro tipo de red o dirección de comunicación. Los controladores FT pueden o no tener direcciones virtuales como se muestran en los diversos ejemplos siguientes. Una pila de red tolerante a fallas es una pila de red que incluye un controlador FT, tal como NETFT descrito abajo en relación con la figura 3, o similar. Un controlador FT, tal como NETFT, que opera en combinación con una pila de red típicamente permite que los nodos se comuniquen entre sí vía una o más trayectorias de comunicaciones, tal como la Trayectoria A y la Trayectoria B, sobre una o más redes. En caso de que fallara cualquiera de estas trayectorias de comunicaciones, los nodos pueden continuar comunicándose en al menos una trayectoria operativa. Dicha falla en la trayectoria puede resultar de la falla de una NIC o la falla de cualquier elementos de una trayectoria, incluyendo conexiones, cableado u otros medios de comunicación (incluyendo radiofrecuencia ("RF") o infrarrojo ("IR") y similar), enrutadores, núcleos, interruptores, cortafuegos, Proveedores de Servicios de Internet ("ISPs"), falla de energía en cualquier nodo, dispositivo o sistema de la red, o similares. En un ejemplo, una falla de comunicación puede dar como resultado en un evento de plug-and-play ("PnP"). Un evento PnP puede indicar la eliminación de una NIC de su nodo o un cambio de sentido en el medio. Una desconexión del sentido en el medio, por ejemplo, normalmente resulta de una falla que provoca que la NIC pierda la señal o vehículo en el medio de red, tal como un cable de red, enlace RF o IR o similar. Una desconexión en el sentido del medio puede ser provocada al desconectar el cable de red o vehículo de la NIC o al apagar el otro extremo del cable (un núcleo o interruptor, por ejemplo). Una conexión de sentido en el medio es típicamente lo opuesto, tal como reconectar el cable, re-energizar el núcleo o interruptor o similar. Estos tipos de eventos, también conocidos como eventos de conectividad, son generalmente eventos locales ya que ocurren en o están próximos al propio nodo. Dichos eventos de conectividad local típicamente resultan en una indicación de evento, tal como un evento PnP o similar, sobre un nodo. En otro ejemplo, una falla en la comunicación puede detectarse al usar paquetes heartbeat enviados entre nodos. El fracaso de dicho paquete heartbeat puede indicar la falla de una trayectoria entre nodos. Los paquetes heartbeat tienden a ser marcados de tal forma que el controlador FT puede detectarlos al recibirlos y retirarlos del flujo del paquete que pasa hacia la pila de red. En un ejemplo, los paquetes heartbeat pueden implementarse usando el protocolo de control de ruta ("RCP") al formar paquetes RCP. Dichos paquetes heartbeat pueden usarse para validad la condición operativa de extremo a extremo de una trayectoria. Es decir, al enviar un paquete heartbeat del nodo 210 sobre la Trayectoria A al nodo 260 y por el nodo 210 recibir una respuesta al paquete heartbeat enviado del nodo 260, generalmente se considera que la Trayectoria A es operativa de extremo a extremo. En caso de que falle el paquete heartbeat (no se recibe contestación en respuesta al heartbeat enviado), dicha falla puede indicar que la Trayectoria A no es operativa, quizá debido a la falla de algún elemento de la red 1202 tal como enrutador, interruptor, conexión, o similar, o debido a la propia falla del nodo receptor. En particular, el nodo 210 puede tener una NIC operativa 212 y sentido de medio válido, indicando que está adecuadamente conectado a la red, pero que todavía puede detectar una falla heartbeat debido a cierta falla en la red o en el sistema en la línea. La figura 3 es un diagrama de bloque que muestra un controlador de comunicaciones tolerante a fallas ejemplar, NETFT 300. El NETFT 300 puede implementarse como un controlador de minipuerto NDIS (figura 1, 160) para usarse con una pila de red NDIS y para proveer comunicaciones de red entre los nodos tolerantes de fallas de trayectoria. Esto es, las comunicaciones entre dos o más nodos pueden continuar cuando cada uno está usando un NETFT a pesar de la falla de cualquier componente en la trayectoria siempre y cuando al menos una trayectoria se mantenga operativa. En un ejemplo, la implementación del controlador FT como un controlador de minipuerto NDIS provee al menos dos beneficios. El primero, debido a que dicho controlador FT generalmente yace por debajo de cualquier controlador de protocolo en la pila, la confiabilidad del protocolo tiende a ser provista por cualquier controlador de protocolo confiable a un nivel más alto que generalmente no es afectado por la adición de tolerancia a fallas a nivel de enlace provista por un controlador FT. Por ejemplo, al utilizar un controlador FT en combinación con un controlador de protocolo tal como un controlador TCP/IP, el controlador FT típicamente detectará las trayectorias fallidas y los paquetes de datos sobre la trayectorias operativas de extremo a extremo independientes de cualquier controlador de protocolo. En caso de que ocurra cualquier pérdida de paquete debido al intercambio de trayectorias, el controlador de protocolo TCP/IP, que generalmente yace sobre el controlador FT en la pila, tiende a detectar dichas pérdidas y llevar a cabo cualquier reintento o reenvío de operaciones para asegurarse de que el protocolo confiable tenga éxito en la entrega del paquete. Un segundo beneficio de colocar el controlador FT por debajo del controlador de protocolo en la pila es que típicamente no se presenta degradación de la viabilidad del protocolo. Cuando se configura de tal forma, cualquier operación de encapsulación (tunneling) que un controlador FT realiza sobre un paquete de datos puede emplear un protocolo dirigible, tal como TCP o UDP, asegurando así que dicha información es dirigible, además de ser tolerante a fallas a nivel de enlace. "Encapsular de forma dirigible" un paquete de datos es encapsular un paquete de datos usando un protocolo dirigible. NETFT, como parte de una pila de red, generalmente se acopla a una aplicación de software a través de NDIS u otras interfaces de pila de red. Tal acoplamiento generalmente permite a las aplicaciones enviar y recibir paquetes de datos sobre redes acopladas a la parte inferior de la pila. En un ejemplo, las aplicaciones tienden a usar direcciones virtuales como la dirección fuente para sus paquetes de datos, esta dirección virtual es conocida como NETFT y es aplicada y comunicada a otros nodos en la red como se describen más adelante. Como se muestra en la figura 3, NETFT incluye un adaptador de minipuerto 302 (también conocido como un elemento de procesamiento) una base de datos de ruta 304, y uno o más adaptadores de monitor de ruta 306 y adaptadores de túneles 308. El adaptador de túnel 308 típicamente representa una NIC en el nodo local (o, en algunos casos, una NIC virtual) y mantiene un socket usado para encapsular paquetes a NETFT en el nodo objetivo. Típicamente hay un adaptador de túnel 308 asociado con cada NIC en el nodo local con cada NIC siendo acoplado a una red que provee una trayectoria a otro nodo. Cada red puede o no estar aislada de cualquier otra red. Un adaptador de túnel 308 típicamente se asocial con un controlador de protocolo de encapsulación y paquetes de datos de túneles a través de un protocolo de encapsulación de y hacia su NIC asociado a través de interfaces NDIS. Un ejemplo de un protocolo de encapsulación es UDP. Alternativamente, otros protocolos, tales como TCP, IPX, o SPX, pueden usarse para encapsulación. Un adaptador de túnel 308 puede volverse inactivo si la NIC o conexión de medios relacionados se vuelven inactivos. Una base de datos de ruta 304, como se implementa en NETFT, es típicamente una estructura de datos simple, que puede localizarse en la memoria del sistema, que incluye entradas que aplican a una dirección virtual para una o más trayectoria a una NETFT similar sobre otro nodo. En un ejemplo, las aplicaciones son representadas por adaptadores de monitor de ruta tal como el adaptador de monitor de ruta 306 que típicamente está asociado con un adaptador de túnel 308. Generalmente una base de datos de ruta tal como una base de datos de ruta 304 incluirá un grupo de adaptadores de ruta para cada adaptador de túnel, cada adaptador de ruta está asociado con un nodo objetivo diferente alcanzable sobre una trayectoria relacionada con el adaptador de túnel. Al usar el TCP/IP, por ejemplo, la base de datos puede trazar una dirección virtual destino a una dirección física de un nodo remoto específico. Una base de datos de ruta 304 puede incluir también información de prioridad para cada trayectoria. Dicha información de prioridad puede usarse para indicar una trayectoria primaria o preferida a otro nodo y/o puede incluir información acerca de la velocidad de la trayectoria u otras características. Una trayectoria preferida es la trayectoria calculada por NETFT a ser usada sobre otras posibles trayectorias, cuando sea posible, con base en información de prioridad y/o condición de la trayectoria. La información de prioridad puede indicar alternativamente un algoritmo de equilibrio de carga round-robin para hacer uso de múltiples trayectorias para un nodo objetivo para equilibrar la carga de tráfico sobre las trayectorias, o permitir algún otro esquema de priorización de la trayectoria. Un ejemplo de una tabla de trazado de la base de datos de la tabla de ruta 304 se muestra en la tabla 1.

Tabla 1 Con referencia a la tabla 1 y a la figura 2, la tabla 1 muestra una tabla de trazado ejemplar como la que se usaría para el NETFT que opera en el nodo 216. La tabla 1 muestra la dirección de destino virtual 1 0.0.0.2, la dirección virtual como se muestra para el nodo 266, trazado para la dirección física 172.56.48.38 relacionada con la Trayectoria A al nodo 266 y la dirección física 197.71.48.39 asociada con la Trayectoria B al nodo 266. La trayectoria A se muestra con la primera prioridad y la Trayectoria B con la segunda prioridad. La tabla 1 se provee como un ejemplo y no pretende ser limitativa. Al enviar información del nodo 216 al nodo 266, dicha tabla de trazado se usa típicamente para encapsular un paquete destinado a la dirección destino virtual 10.0.0.2 al reenviar el paquete a través del protocolo de túnel, tal como UDP, a la dirección destino física 1 72.56.48.38, encapsulando así el paquete del nodo 216 sobre la Trayectoria A al nodo 266. Una tabla de trazado similar puede crearse en la base de datos de ruta (FIG.3, 304) para cada grupo de trayectorias entre dos nodos. Dicha tabla de trazado puede implementarse en diversas formas, usar varios esquemas de prioridad y/o almacenar otra información incluyendo la condición operativa de la trayectoria. La estructura de la tabla de trazado, el número de trayectorias, los formatos de direcciones, etc. que se muestran en la Tabla 1 se proveen como ejemplos y no intentan ser limitativos. La dirección virtual del nodo local, las direcciones virtuales del nodo remoto, y la prioridad así como otra información de trayectoria típicamente se proveen a los nodos mediante un mecanismo fuera de banda y pasan a NETFT a través de sus interfaces de NDIS. Este mecanismo fuera de banda puede ser tan simple como un administrador de sistemas usando una aplicación de administración para especificar la información, o puede ser un sistema automatizado o similar. Dichos mecanismos fuera de banda son bien conocidos por los expertos en la técnica. Como se muestra en la figura 3, el adaptador de minipuerto 302 (también conocido como el elemento de procesamiento del controlador) típicamente analiza un paquete de datos que fluye hacia abajo de la pila de red, examina la dirección virtual destino del paquete y usa información de la base de datos de ruta 304 para determinar cual adaptador de túnel 308 dirigirá el paquete de datos. Los paquetes entrantes, o paquetes de datos que fluyen de la pila, son reenviados de la pila hacia su dirección virtual de destino, el protocolo de túnel habiendo eliminado previamente los encabezados del paquete de túnel. En particular, el adaptador de túnel 308 inspecciona los paquetes entrantes y reenvía los paquetes heartbeat a un adaptador de monitor de ruta 306 y reenvía otros paquetes a la fila a través de un adaptador de minipuerto 302. Los aspectos de los paquetes de datos de encapsulación que usan un protocolo de encapsulación y la forma en la que los encabezados de protocolo son agregados y retirados por los controladores de protocolo son bien conocidos por los expertos en la técnica. El adaptador de monitor de ruta 306 típicamente representa un nodo remoto accesible sobre una trayectoria específica identificada por un adaptador de túnel asociado. El adaptador de monitor de ruta 306 típicamente proveerá una dirección física para el nodo remoto, la dirección física también corresponde a una trayectoria específica al nodo remoto. Esta dirección física se usa típicamente para trazar en una base de datos de ruta 304. Típicamente hay un adaptador de monitor de ruta para cada trayectoria diferente a un nodo remote, cada adaptador de monitor de ruta está asociado con un adaptador de túnel que representa una trayectoria. En un ejemplo, con referencia de nuevo a la figura 2, el nodo 210 se muestra acoplado al nodo 260 sobre dos trayectorias, una a través de la red 1202 ("Trayectoria A") y la otra a través de la red 2282 ("Trayectoria B"). NETFT que opera en el nodo 210 puede incluir un primer adaptador de monitor de ruta ("RMA-A") proveyendo un nodo remoto 260 de la dirección física 172.56.48.38 asociado con su NIC 262. RMA-A puede estar relacionado con un primer adaptador de túnel ("TA-A") en el nodo 210 que puede estar asociado con la Trayectoria A. NETFT en el nodo 210 también puede incluir un segundo adaptador de monitor de ruta ("RMA-B") proveyendo un nodo remoto 260 de la segunda dirección física 1 97.71 .48.39 asociada con su NIC 264. RMA-B puede estar asociado con un segundo adaptador de túnel ("TA-B") en el nodo 210 que puede estar asociado con la Trayectoria B. Con referencia a la figura 3, el adaptador de monitor de ruta 306 típicamente monitorea la salud de una trayectoria a un nodo remoto e indica una trayectoria fallida o no operativa en la base de datos de ruta 304. El monitoreo típicamente incluye recibir cualquier indicación de evento y/o notar cualquier falla de heartbeat y actualizar la base de datos 304 de forma correspondiente. En un ejemplo, un evento que indica la falla de una NIC o conexión de medios puede resultar en la desactivación del adaptador de túnel 308. En otro ejemplo, una falla en heartbeat puede dar como resultado la desactivación del adaptador de monitor de ruta 306 asociado con el nodo remoto específico para el que falló el heartbeat. La figura 4 es un diagrama de bloque que muestra un ejemplo de arquitectura de comunicaciones tolerante a fallas 216 incluyendo NETFT 300 y una aplicación 402. En este ejemplo, la aplicación 402 envía paquetes de datos a NETFT 300 a través de la pila usando una dirección de fuente virtual 217 y una dirección destino virtual que representa el nodo destino. Dichos paquetes de datos salientes fluyen hacia la trayectoria 480 de la aplicación y a través de la pila de red al controlador 300. El controlador 300 típicamente determina cuál de las posibles trayectorias deberá tomar cada paquete, en general usando información de prioridad e información de condición operativa de la trayectoria almacenada en la base de datos de ruta, y encapsula el paquete al nodo objetivo sobre la trayectoria seleccionada usando la dirección fuente física apropiada 422 o 424. La aplicación 402 puede enviar un paquete de datos a través de NETFT 300 mediante el protocolo de TCP, como se muestra en la figura 4. Alternativamente puede usarse UDP o cualquier otro protocolo. Además, como se muestra, NETFT 300 puede usar el protocolo UDP para encapsular paquetes al nodo objetivo. Alternativamente, puede usarse TCP o cualquier otro protocolo para encapsulación. Además, ejemplos alternativos pueden no hacer uso del adaptador de minipuertos o controladores NDIS pero puede usar otros mecanismos o arquitecturas para desempeñar funciones similares. Por último, los diversos elementos de la pila de red y similares pueden operar en el Modo de Usuario o un Modo Kernel, ya sea como se muestra o de otra forma, o en sistemas con o sin modos equivalentes de operación. La figura 5 es un diagrama de flujo que muestra datos que fluyen a través de un entorno de comunicaciones tolerante a fallas 500 incluyendo un nodo fuente 216 y un nodo destino 266 acoplado a través de la Trayectoria A sobre la red 1202 y la Trayectoria B sobre la red 2282. En este entorno ejemplar 500, los datos se muestran enviados desde la aplicación que opera en el nodo 216 a la aplicación que escucha en la dirección virtual destino en el nodo 266. Los paquetes de datos fluyen hacia debajo de la pila de red que opera en el nodo 216 usando el protocolo TCP en NETFT como lo muestra la trayectoria 501.

Dando por hecho, como se muestra, que la Trayectoria A es la trayectoria seleccionada, NETFT traza los paquetes de datos de dirección virtual fuente siendo usada por la aplicación a la Trayectoria A y encapsula los datos a través del protocolo UDP usando la dirección física destino de la Trayectoria A para el nodo objetivo 266, fuera NIC 1 del nodo 216 como se muestra por la trayectoria 501 y hacia la red 1202 a través del enlace 201. Los datos entonces fluyen a través de la red 1202, sobre el enlace 203 y al nodo 266, fluyendo hacia arriba de la pila de red que opera en el nodo 266 como lo muestra la trayectoria 503. Los datos fluyen entonces a través del UDP controlador de protocolo, el mismo protocolo que se usó en el lado de envío como el protocolo de encapsulación, en donde los encabezados de protocolo UDP son deshechos de los paquetes de datos que después pasan a NETFT que opera en el nodo 266. NETFT reenvía después los paquetes de datos hacia la pila a la aplicación que está escuchando en la dirección virtual destino. Las respuestas tienden a fluir en el orden inverso. La figura 6 es un diagrama de flujo que muestra datos que fluyen a través del entorno de comunicaciones tolerante a fallas 500 mostrado en la figura 5 con la adición de las diversas fallas de comunicaciones posibles 610, 612, 620, 622, y 630. Otras fallas de comunicación también son posibles. La falla 610 indica una falla de NIC 1 operando en el nodo de envío 216. Dicha falla puede ocurrir en caso de que NIC 1 sea retirado del nodo, si falla el controlador de NIC 1, si falla la propia NIC 1, o similar. La falla puede detectarse por NETFT a través de una indicación de evento, tal como un evento PnP o similar, y/o una falla heartbeat. En tal situación la Trayectoria A típicamente se considera que ha fallado y NETFT seleccionará una trayectoria operativa de extremo a extremo alternativa. Una trayectoria operativa de extremo a extremo es típicamente una trayectoria que puede entregar exitosamente datos del nodo fuente y la aplicación al nodo destino y aplicación. La falla 620 indica una falla de los medios de red que se acopla con la NICI del nodo 216. Esta falla puede deberse a un cable que ha sido desconectado de NIC 1, del cable que se desconecta de cierto dispositivo de red 1202, cuando el dispositivo de cable que está conectado en el lado de la red es apagado o falla, o similar. Este tipo de falla también puede ser detectada por NETFT a través de una indicación de evento, tal como un evento PnP o similar, y/o una falla heartbeat y una trayectoria alternativa seleccionada. La falla 630 indica una falla de algún tipo dentro de la red 202 que da como resultado paquetes de datos que no alcanzan el nodo destino 266. En este caso de falla, el nodo de envío 216 puede estar todavía acoplado a la red 202 con una indicación de sentido de medio apropiado, aunque la Trayectoria A se ha interrumpido más debajo de la red. En vista de tal falla, NETFT que opera en el nodo de envío 216 puede no detector la falla a través de una indicación de evento si las indicaciones locales muestran conectividad a la red 202 como buena, pero pueden detectar la falla a través de la falla heartbeat Trayectoria A. La falla 622 del enlace 203 y la falla 612 de NIC 1 que opera en el nodo de recepción 266 tienden a ser similar a las fallas correspondientes mostradas para el nodo 216. Pero estas fallas, no siendo locales al nodo 216 pueden no ser detectadas a través de indicaciones de evento pero sí detectadas a través de la falla heartbeat. Cualquiera de estas fallas, y otras fallas, pueden detectarse por NETFT que opera en el nodo 216 y resulta en seleccionar una trayectoria operativa de extremo a extremo alternativa, tal como la Trayectoria B sobre la red 2282. En este ejemplo, como se muestra en la figura 6, NETFT encapsula los datos hacia la trayectoria alternativa 681 y sobre la red 2282 para recibir el nodo 266. En caso de que la condición de falla sea corregida y la condición operativa de extremo a extremo restaurada en la Trayectoria A, NETFT que opera en el nodo de envío 216 puede detectar la recuperación y de nuevo hacer uso de la Trayectoria A. Además, cualquier respuesta del nodo 266 de vuelta al nodo 216 puede ser encapsulada en un modo tolerante a fallas similar por NETFT. La figura 7 es un diagrama de bloque que muestra otro ejemplo de un controlador de comunicaciones tolerante a fallas, NETFT 700. Este ejemplo es similar al ejemplo mostrado en la figura 3 pero incluye variaciones como se describe más adelante. En este ejemplo, una aplicación de software puede no necesitar el uso de direcciones virtuales. En vez de esto, una aplicación puede usar una dirección física destino a los paquetes de datos de dirección al nodo objetivo. El adaptador de protocolo 710 generalmente se acopla al adaptador de minipuerto 702 (también conocido como el elemento de procesamiento del controlador) y a un adaptador de NIC de minipuerto (no se muestra). Existe típicamente un adaptador de protocolo para cada NIC instalada en el nodo, cada adaptador de protocolo está relacionado con una NIC a través de su adaptador de NIC. Al igual que cada adaptador de protocolo está relacionado con una NIC, también está asociado con la trayectoria acoplada a la NIC. El adaptador de protocolo 710 es operable para aceptar paquetes de datos de una aplicación a través del elemento de procesamiento 702 y pasa los paquetes de datos a la NIC relacionada sin la necesidad de encapsular. El elemento de procesamiento 702 típicamente analiza un paquete de datos que fluye hacia abajo de la pila de red, examina la dirección de destino física para el paquete y usa la información de la base de datos de ruta 704 para determinar si el paquete puede ser reenviado sobre un adaptador de protocolo 710 o necesita ser encapsulado sobre un adaptador de túnel 308 al nodo objetivo. Generalmente, si la trayectoria indicada por la dirección física destino es operativa de extremo a extremo, el paquete de datos se enviará sobre esa trayectoria. De otra manera una trayectoria alternativa puede seleccionarse sobre el paquete que será encapsulado. En este ejemplo la base de datos de ruta 704 mantiene trazados de las direcciones y trayectorias físicas, junto con la prioridad y otra información como se describe con anterioridad.

Un ejemplo de una tabla de trazado de la base de datos de ruta 704 se muestra en la tabla 2.

Tabla 2 Con referencia a la tabla 2 y a la figura 2, la tabla 2 muestra una tabla de trazado ejemplar como la que se usaría para el NETFT que opera en el nodo 216. La tabla 2 muestra un trazado que incluye la dirección física de destino 172.56.48.38 relacionada con la Trayectoria A al nodo 266 y la dirección física de destino 197.71.48.39 asociada con la Trayectoria B al nodo 266. La trayectoria A se muestra con la primera prioridad y la Trayectoria B con la segunda prioridad. Al enviar información del nodo 216 al nodo 266, dicha tabla de trazado se usa típicamente para reenviar (o encapsular si es necesario) un paquete de datos destinado a la dirección física de destino 172.56.48.38 o nodo 266. Si la trayectoria relacionada con la dirección destino original es operativa, el paquete de datos tiende a ser reenviado al nodo destino sin encapsulación. Si dicha trayectoria no está disponible, entonces el paquete de datos es enviado sobre la trayectoria alternativa a la dirección física de destino 197.71 .48.39 del nodo 266 mediante encapsulación. Otros aspectos de NETFT 700 son generalmente similares a los de NETFT como se describen para la figura 3. La figura 8 es un diagrama de bloque que muestra una arquitectura de comunicaciones tolerante a fallas ejemplar 216 incluyendo NETFT 700 y una aplicación 402. En este ejemplo, la aplicación 402 envía paquetes de datos a NETFT 700 a través de la pila usando una dirección física fuente y una dirección física destino 801 representando el nodo destino. Tales paquetes de datos de salida fluyen a través de la trayectoria 880 de la aplicación y a través de la pila de red al controlador 700. El controlador 700 típicamente determina cuáles de las posibles trayectorias deberá tomar cada paquete, en general usando información de prioridad y condición operativa de la trayectoria almacenada en la base de datos de ruta, y ya sea que reenvíe el paquete al nodo objetivo sobre la trayectoria indicada por la dirección física destino original o, si dicha trayectoria no es de operación de extremo a extremo, encapsula el paquete sobre una trayectoria alternativa como se indica en este ejemplo por la ruta 882 y NIC 2892. La aplicación 402 puede enviar paquete de datos a través de NETFT 700 mediante el protocolo TCP, como se muestra en la figura 8. Alternativamente se puede usar UDP o cualquier otro protocolo. Además, como se muestra, NETFT 700 puede usar el protocolo UDP para encapsular paquetes de túnel al nodo objetivo. De manera alternativa, puede usarse TCP o cualquier otro protocolo para encapsulación. Además, otros ejemplos podrían no utilizar los NDIS controladores sino otros mecanismos o arquitecturas para realizar funciones similares. Por ultimo, los diversos elementos de la pila de red y similares pueden operar ya sea en un Modo de Usuario o un Modo Kernel, ya sea como se muestra o de otra forma, o sobre sistemas con o sin modos equivalentes de operación. La figura 9 es un diagrama de flujo que muestra datos que fluyen mediante un entorno de comunicaciones tolerante a fallas 900 incluyendo un nodo fuente 816 y un nodo destino 966 acoplado a través de la Trayectoria A sobre la red 1202 y la Trayectoria B sobre la red 2282. En este entorno ejemplar 900, los datos se muestran enviados desde la aplicación que opera en el nodo 216 a la aplicación que escucha en la dirección física destino en el nodo 266. Los paquetes de datos fluyen hacia debajo de la pila de red que opera en el nodo 216 usando el protocolo TCP en NETFT como lo muestra la trayectoria 901. Dando por hecho, como se muestra, que la Trayectoria A es la trayectoria seleccionada, NETFT envía los paquetes de datos usando la dirección física destino provista por la aplicación a través de la NIC 1 del nodo 216 sobre la Trayectoria A y la red 1202 a través del enlace 201. Después los datos fluyen a través de la red 1202, sobre el enlace 203 y al nodo 966, fluyendo hacia arriba de la pila de red en el nodo 966 como lo muestra la trayectoria 903. Después los datos fluyen a través de NETFT y el controlador de protocolo (un controlador de protocolo para el mismo protocolo que se usó en el lado de envío como el protocolo de envío) y hasta la aplicación. Las respuestas tienden a fluir en orden inverso. La figura 10 es un diagrama de flujo que muestra datos que fluyen a través del entorno de comunicaciones tolerante a fallas 900 mostrado en la figura 9 con la adición de varias fallas de comunicación posibles 1010, 1012, 1020, 1022, y 1030. Otras fallas de comunicación también son posibles. La falla 1010 indica una falla de NIC 1 que opera en el nodo de envío 816. Tal falla puede ocurrir si la NIC 1 es retirada del nodo, si falla el controlador de NIC 1, si falla la propia NIC 1, o similar. La falla puede detectarse por NETFT a través de una indicación de evento, tal como un evento PnP o similar, y/o una falla heartbeat. En tal situación la Trayectoria A típicamente se considera que ha fallado y NETFT seleccionará una trayectoria operativa de extremo a extremo alternativa.

La falla 1020 indica una falla de los medios de red que se acopla con la NICI del nodo 816. Esta falla puede deberse a un cable que ha sido desconectado de NIC 1, del cable que se desconecta de cierto dispositivo de red 1202, cuando el dispositivo de cable que está conectado en el lado de la red es apagado o falla, o similar. Este tipo de falla también puede ser detectada por NETFT a través de una indicación de evento, tal como un evento PnP o similar, y/o una falla heartbeat y una trayectoria alternativa seleccionada. La falla 1030 indica una falla de algún tipo dentro de la red 202 que da como resultado paquetes de datos que no alcanzan el nodo destino 966. En este caso de falla, el nodo de envío 816 puede estar todavía acoplado a la red 202 con una indicación de sentido de medio apropiado, aunque la Trayectoria A se ha interrumpido más debajo de la red. En vista de tal falla, NETFT que opera en el nodo de envío 816 puede no detectar la falla a través de una indicación de evento si las indicaciones locales muestran conectividad a la red 202 como buena, pero pueden detectar la falla a través de la falla heartbeat Trayectoria A. La falla 1022 del enlace 203 y la falla 1012 de NIC 1 que opera en el nodo de recepción 966 tienden a ser similares a las fallas correspondientes mostradas para el nodo 816. Pero estas fallas, no siendo locales al nodo 816 pueden no ser detectadas a través de indicaciones de evento pero sí detectadas a través de la falla heartbeat. Cualquiera de estas fallas, y otras fallas, pueden detectarse por NETFT que opera en el nodo 816 y resulta en seleccionar una trayectoria operativa de extremo a extremo alternativa, tal como la Trayectoria B sobre la red 2282. En este ejemplo, como se muestra en la figura 10, NETFT encapsula los datos hacia la trayectoria alternativa 1081 y sobre la red 2282 para recibir el nodo 966. En caso de que la condición de falla sea corregida y la condición operativa de extremo a extremo restaurada en la Trayectoria A, NETFT que opera en el nodo de envío 816 puede detectar la recuperación y de nuevo hacer uso de la Trayectoria A. Además, cualquier respuesta del nodo 966 de vuelta al nodo 816 puede ser reenviada o encapsulada, dependiendo de la condición operativa de la Trayectoria A y la Trayectoria B, en un modo tolerante a fallas similar por NETFT.

La figura 11 es un diagrama de bloque que muestra otro ejemplo de un entorno de cómputo 1100 en el que implementa la tecnología descrita con anterioridad. Puede implementarse un entorno de cómputo adecuado con numerosos sistemas de propósitos generales o sistemas de propósitos especiales. Ejemplos de sistemas bien conocidos pueden incluir, pero no limitarse a, computadoras personales ("PC"), dispositivos portátiles a mano o laptop, sistemas basados en microprocesadores, sistemas de multiprocesadores, servidores, estaciones de trabajo, dispositivos electrónicos de consumo, decodificadores, y similares. El entorno de cómputo 1100 generalmente incluye un sistema de cómputo de propósitos generales en la forma de un dispositivo de cómputo 1101 acoplado con varios dispositivos periféricos 1102, 1103, 1104 y similares. El sistema 1100 puede acoplarse a varios dispositivos de entrada 1103, incluyendo teclados y dispositivos de puntero, tal como un ratón o una trackball, a través de una o más interfaces l/O 1112. Los componentes del dispositivo de cómputo 1101 pueden incluir uno o más procesadores (incluyendo unidades de procesamiento central ("CPU"), unidades de procesamiento de gráficos ("GPU"), microprocesadores ("uP"), y similares) 1107, memoria de sistema 1109, y un bus de sistema 1108 que típicamente acopla los diversos componentes. El procesador 1107 típicamente procesa o ejecuta varias instrucciones ejecutables por computadora para controlar la operación del dispositivo de cómputo 1101 y para comunicar con otros dispositivos electrónicos y/o de cómputo, sistemas o entorno (no se muestra) a través de varias conexiones de comunicación tal como una conexión de red 1114 o similar. El bus del sistema 1108 representa cualquier número de varios tipos de estructuras de bus, incluyendo un bus de memoria o controlador de memoria, bus periférico, bus serial, un puerto de gráficos acelerado, un procesador o bus local usando cualquiera de una variedad de arquitecturas de bus, y similares.

El sistema de memoria 1109 puede incluir medios legibles por computadora en la forma de memoria volátil, tal como la memoria de acceso aleatorio ("RAM"), y/o memoria no volátil, tal como memoria de sólo lectura ("ROM") o memoria instantánea ("FLASH"). Un sistema de entrada/salida básico ("BIOS") puede almacenarse en no volátil o similar. El sistema de memoria 1109 típicamente almacena datos, instrucciones ejecutables por computadora y/o módulos de programa que comprenden instrucciones ejecutables por computadora que son inmediatamente accedidas y/o actualmente operadas por uno o más de los procesadores 1107. Los dispositivos de almacenamiento masivo 1104 y 1110 pueden acoplarse al dispositivo de cómputo 1101 o incorporarse en el dispositivo de cómputo 1101 a través del acoplamiento al bus del sistema. Dichos dispositivos de almacenamiento masivo 1104 y 1110 pueden incluir una unidad de disco magnético que lee de y/o escribe a un disco magnético removible, no-volátil (e.g., un "disco flexible ") 1105, y/o una unidad de disco óptico que lee de y/o escribe a un disco óptico no volátil tal como un CD ROM, DVD ROM 1106. De forma alternativa, un dispositivo de almacenamiento masivo, tal como un disco duro 1110, puede incluir medios de almacenamiento no removibles. Otros dispositivos de almacenamiento masivo pueden incluir tarjetas de memoria, barras de memoria, dispositivos de almacenamiento de cinta, y similares.

Cualquier número de programas de computadora, archivos, estructuras de datos, y similares pueden almacenarse en el disco duro 1110, otros dispositivos de almacenamiento 1104, 1105, 1106 y memoria del sistema 1109 (típicamente limitada por el espacio disponible) incluyendo, a manera de ejemplo, sistemas operativos, programas de aplicación, archivos de datos, estructuras de directorio, e instrucciones ejecutables por computadora. Los dispositivos de salida, tal como el dispositivo de pantalla 1102, pueden acoplarse al dispositivo de cómputo 1101 a través de una ¡nterfaz, tal como el adaptador de video 1111. Otros tipos de dispositivos de salida pueden incluir impresoras, salidas de audio, dispositivos táctiles u otros mecanismos de salida sensoriales, o similares. Los dispositivos de salida pueden permitir que el dispositivo de cómputo 1101 interactúe con los operadores humanos u otras máquinas o sistemas. Un usuario puede interconectarse con un entorno de cómputo 1100 a través de un número de diferentes dispositivos de entrada 1103 tal como un teclado, ratón, palanca de mando, almohadilla de juego, puerto de datos y similares. Estos y otros dispositivos de entrada pueden acoplarse al procesador 1107 a través de interfaces de entrada/salida 1112 que pueden ser acopladas al bus del sistema 1108, y pueden acoplarse por otras interfaces y estructuras de bus, tales como un puerto paralelo, puerto de juego, bus serial universal ("USB"), cable de fuego, puerto infrarrojo, y similares. El dispositivo de cómputo 1101 puede operar en un entorno de red a través de conexiones de comunicaciones a uno o más dispositivos de cómputo remotos a través de una o más redes de área local ("LAN"), redes de área amplia ("WAN"), redes de área de almacenamiento ("SAN"), Internet, enlaces de radio, enlaces ópticos y similares. El dispositivo de cómputo 1101 puede acoplarse a una red vía el adaptador de red 1113 o similar, o alternativamente, vía un módem, enlace de línea de suscriptor digital ("DSL"), enlace de red digital de servicios integrados ("ISDN"), enlace a Internet, enlace inalámbrico, o similar. La conexión de comunicaciones 1114, tal como una conexión de red, típicamente provee un acoplamiento a los medios de comunicación, tal como una red. Los medios de comunicación típicamente proveen instrucciones legibles por computadora y ejecutables por computadora, estructuras de datos, archivos, módulos de programa y otros datos que usan una señal de datos modulada, tal como una onda portadora u otro mecanismo de transporte. El término "señal de datos modulada" típicamente significa una señal que tiene una o más características establecidas o cambiadas de tal manera que codifiquen información en la señal. A manera de ejemplo, y no de limitación, los medios de comunicación pueden incluir medios alámbricos, tales como una red alámbrica o conexión alámbrica directa o similar, y medios inalámbricos, tal como mecanismos acústicos, radiofrecuencia, infrarrojo u otros mecanismos de comunicaciones inalámbricas. Los expertos en la técnica reconocerán que los dispositivos de almacenamiento usados para proveer instrucciones legibles por computadora o ejecutables por computadora y datos que pueden distribuirse en una red. Por ejemplo, una computadora remota o dispositivo de almacenamiento puede almacenar instrucciones legibles por computadora e instrucciones ejecutables por computadora en la forma de aplicaciones de software y datos. Una computadora local puede acceder la computadora remota o el dispositivo de almacenamiento a través de la red y descargar parte o toda la aplicación de software o datos y puede ejecutar cualquier instrucción ejecutable por computadora. De forma alternativa, la computadora local puede bajar piezas del software o datos como sea necesario, o procesar distribuidamente el software al ejecutar algunas de las instrucciones en la computadora local y algunas en las computadoras remotas y/o dispositivos. Será evidente para los expertos en la técnica que, al utilizar las técnicas convencionales, todas o partes de las instrucciones ejecutables por computadora del software pueden llevarse a cabo por un circuito electrónico dedicado tal como un procesador de señal digital ("DSP"), una disposición lógica programable ("PLA"), circuitos discretos, y similares. El término "aparato electrónico" puede incluir dispositivos de cómputo o dispositivos electrónicos de consume que comprenden cualquier software, firmware o similar, o dispositivos electrónicos o circuitos que no comprenden software, firmware o similar. El término "firmware" típicamente se refiere a instrucciones ejecutables, códigos o datos mantenidos en un dispositivo electrónico tal como una ROM. El término "software" generalmente se refiere a instrucciones ejecutables, códigos, datos, aplicaciones, programas, o similares que se mantienen en cualquier forma de medio legible por computadora. El término "medios legibles por computadora" típicamente se refiere a memoria del sistema, dispositivos de almacenamiento y otros medios asociados, medios de comunicación, y similares.

Claims (1)

1. REIVINDICACIONES 1. Un método para proveer una aplicación con comunicaciones de red tolerantes a fallas entre una pluralidad de nodos, que consiste en: proveer una pluralidad de trayectorias de comunicaciones iniciales a través de una pluralidad de redes acopladas a la pluralidad de nodos; recibir un paquete de datos en un nodo de envío desde la aplicación, el nodo de envío es una pluralidad de nodos, el paquete de datos está dirigido por la aplicación a una dirección en uno de la pluralidad de nodos; y seleccionar una primera trayectoria seleccionada del paquete de datos de entre la pluralidad de trayectorias de comunicaciones iniciales en donde la primera trayectoria seleccionada es una trayectoria preferida. 2. El método de conformidad con la reivindicación 1, caracterizado además porque comprende: detectar un evento de conectividad local relacionado con una de la pluralidad de trayectorias de comunicaciones iniciales; e indicar si la pluralidad de trayectorias de comunicaciones iniciales es operativa con base en el evento de conectividad local. 3. El método de conformidad con la reivindicación 1, caracterizado además porque comprende: enviar un paquete heartbeat dirigible sobre una de la pluralidad de trayectorias de comunicaciones iniciales; monitorear una respuesta al paquete heartbeat dirigible para determinar una condición operativa de extremo a extremo de una de la pluralidad de trayectorias de comunicaciones iniciales; e indicar si la una de la pluralidad de trayectorias de comunicaciones iniciales es operativa de extremo a extremo con base en el monitoreo de la respuesta. 4. El método de conformidad con la reivindicación 1, caracterizado además porque la dirección es una dirección de Protocolo de Internet versión 4 o una dirección de Protocolo de Internet versión 6. 5. El método de conformidad con la reivindicación 1, caracterizado además porque el paquete de datos recibido de la aplicación es un paquete de Protocolo de Control de Transmisión o un paquete de Protocolo de Datagrama de Usuario. 6. El método de conformidad con la reivindicación 1, caracterizado además porque las instrucciones ejecutables por computadora para ejecutar el método se almacenan en un medio legible por computadora. 7. El método de conformidad con la reivindicación 1, caracterizado además porque la dirección es una dirección virtual. 8. El método de conformidad con la reivind icación 7, caracterizado además porque comprende encapsular el paquete de datos sobre la primera trayectoria seleccionada sin requerir q ue la aplicación esté pendiente de que la pluralidad de trayectorias de comunicaciones iniciales sea la trayectoria seleccionada. 9. El método de conformidad con la reivind icación 8 , caracterizado además porque el paquete de datos dirigible encapsu lado sobre la primera trayectoria seleccionada es u n paquete de Paquete de Protocolo de Control de Transm isión o u n Paquete de Protocolo de Datagrama de Usuario. 1 0. El método de conformidad con la reivind icación 7, caracterizado además porque comprende: detectar u na falla de la primera trayectoria seleccionada; seleccionar una segunda trayectoria seleccionada de entre la pl ural idad de trayectorias de comunicaciones in iciales en donde la segu nda trayectoria seleccionada es tanto operativa de extremo a extremo como una trayectoria preferida; y encapsu lar de forma dirigible el paquete de datos sobre la segunda trayectoria seleccionada sin requerir la aplicación está al tanto de q ue la una o más trayectorias de com unicaciones iniciales es la segu nda trayectoria seleccionada. 1 1 . El método de conformidad con la reivind icación 1 , caracterizado además porq ue la primera trayectoria seleccionada se elige con base en una dirección física destino incluida con el paquete de datos. 12. El método de conformidad con la reivindicación 11, caracterizado además porque comprende enviar el paquete de datos sobre la primera trayectoria seleccionada sin requerir que la aplicación esté al tanto de cual de la pluralidad de trayectorias de comunicaciones iniciales es ia primera trayectoria seleccionada. 13. El método de conformidad con la reivindicación 11, caracterizado además porque comprende: detectar una falla de la primera trayectoria seleccionada; seleccionar una segunda trayectoria seleccionada de una pluralidad de trayectorias de comunicaciones iniciales en donde la segunda trayectoria seleccionada es tanto operativo de extremo a extremo como una trayectoria preferida; y encapsulado dirigible del paquete de datos sobre la segunda trayectoria seleccionada sin requerir que la aplicación esté al tanto de cual de la una o más trayectorias de comunicaciones iniciales es la segunda trayectoria seleccionada. 14. El método de conformidad con la reivindicación 13, caracterizado además porque el paquete de datos encapsulado de forma dirigible sobre la segunda trayectoria seleccionada es un paquete de Protocolo de Control de Transmisión o un paquete de Protocolo de Datagrama de Usuario. 15. Un método para proveer una aplicación con comunicaciones de red tolerantes a fallas entre una pluralidad de nodos, que consiste en proveer una pluralidad de trayectorias de comunicaciones iniciales a través de una pluralidad de redes acopladas a la pluralidad de nodos; recibir un paquete de datos en un nodo de recepción, el nodo de recepción incluye una pila de red tolerante a fallas y es una pluralidad de nodos, el paquete de datos está destinado a la aplicación; determinar si el paquete de datos se encapsuló de forma dirigible; y si el paquete de datos se encapsuló de forma dirigible, reenviar el paquete de datos arriba a la pila de red tolerante a fallas. 16. El método de conformidad con la reivindicación 15, caracterizado además porque comprende: recibir un paquete heartbeat dirigible en el nodo de recepción sobre una de la pluralidad de trayectorias de comunicaciones iniciales; y responder con una respuesta al paquete heartbeat dirigible para indicar una condición operativa de extremo a extremo de la una de la pluralidad de trayectorias de comunicaciones iniciales. 17. El método de conformidad con la reivindicación 15, caracterizado además porque el paquete de datos es un Paquete de Protocolo de Control de Transmisión o un Paquete de Protocolo de Datagrama de Usuario. 18. El método de conformidad con la reivindicación 15, caracterizado además porque las instrucciones ejecutables por computadora para ejecutar el método se almacenan en un medio legible por computadora. 19. Un sistema para proveer una aplicación con comunicaciones de red tolerantes a fallas entre una pluralidad de nodos, que comprende: un primer controlador tolerante a fallas acoplado a una primera pila de red y que opera en un primer nodo, el primer nodo es una de la pluralidad de nodos; un segundo controlador tolerante a fallas acoplado a una segunda pila de red y que opera en un segundo nodo, el segundo nodo es una de la pluralidad de nodos; y el primer controlador tolerante a fallas y el segundo controlador tolerante a falles son acoplados a través de una pluralidad de trayectorias de comunicaciones iniciales sobre una pluralidad de redes. 20. El sistema de conformidad con la reivindicación 19, caracterizado además porque el primer controlador tolerante a fallas comprende: un elemento de procesamiento acoplado con la aplicación a través de una primera pila de red; una base de datos de ruta acoplada al elemento de procesamiento que incluye: una entrada que representa una trayectoria para el segundo nodo incluyendo una dirección física del segundo nodo, la trayectoria es una de la pluralidad de trayectorias de comunicaciones iniciales; y una indicación de una condición operativa de extremo a extremo de la trayectoria para el segundo nodo; un adaptador de protocolo acoplado al elemento de procesamiento y acoplado a una de la pluralidad de redes a través de la primera pila de red, la una de la pluralidad de redes está asociada con la trayectoria al segundo nodo; y un adaptador de túnel asociado con la trayectoria al segundo nodo y acoplado al elemento de procesamiento y acoplado a la una de la pluralidad de redes a través de una primera pila de red.