MXPA01000970A - Aislamiento de fallas en una red - Google Patents

Abstract

Se proporcionan técnicas para mejorar el aislamiento y reducción de fallas. Se describe un sistema que se utiliza con una red de datos e incluye múltiples unidades de diagnóstico, cada una adaptada para comunicarse con la red, incluyendo al usuario de la red. Un controlador central estáconectado operativamente a las unidades de diagnóstico, el controlador estáadaptado para comunicarse con las unidades diagnóstico y coordinar las operaciones de las mismas, para instruir a las unidades de diagnóstico a realizar pruebas adaptadas para ayudar a aislar una falla en la red y para analizar los resultados de prueba recibidos de las unidades de diagnóstico a fin de intentar determinar la falla de la red. También se proporcionan varios métodos para mejorar el aislamiento de fallas y la reducción de fallas.

Description

AISLAMIENTO DE FALLAS EN UNA RED ANTECEDENTES DE LA INVENCIÓN La invención se relaciona con redes, por ejemplo, redes de datos y de comunicaciones y, más particularmente, se relaciona con el aislamiento de fallas en este tipo de redes . Las redes de comunicaciones y de datos crecen rápidamente en cuanto a su uso y complejidad. Por ejemplo, el número de personas que utiliza la Internet para transmitir y recibir datos está creciendo diariamente. También, las personas que utilizan la Internet, la están utilizando cada vez más a medida que se añaden más sitios en la web, y a medida que los usuarios se sienten más cómodos en el uso de más servicios disponibles en línea, por ejemplo, la compra de artículos, en lugar de solamente tener acceso a la información. La adición de fuentes de información y de servicios, por ejemplo, el número siempre en aumento de sitios en la web, aumenta la complejidad de la Internet. A medida que el uso y complejidad de las redes aumenta, también aumenta el número de problemas que experimentan los usuarios. Los proveedores de servicios de red desean reducir el impacto que los problemas de la red tienen sobre los usuarios, así como el costo que ocasionan los problemas de la red a los proveedores de servicio. La reducción del impacto de los problemas, así como del tiempo de paro y de la imposibilidad de accesar la red o una información o servicio particular en la red, aumenta el deseo de que los usuarios quieran utilizar un proveedor de servicio de red en particular. Idealmente, los usuarios nunca desean tener problemas con la red. De preferencia, desean que los problemas sean poco frecuentes y, cuando se presenten, desean que se corrijan rápidamente. La reducción del costo al proveedor del servicio le permite a éste aumentar sus ganancias y/o los servicios para los usuarios. El costo de los proveedores de servicios de la red puede reducirse en por lo menos tres formas: (1) reducir el costo de aislamiento de un problema; (2) reducir la frecuencia del problema, y (3) reducir el costo de la corrección del problema . Una técnica actual para aislar los problemas en las redes de comunicación es que el usuario llame a una línea de ayuda para corrección de problemas. El usuario llama a la línea de ayuda y describe su problema, por ejemplo, las operaciones que el usuario no puede realizar y los mensajes de error que está recibiendo, en su caso. Un recepcionista o un técnico analizan la información proporcionada por el usuario. El recepcionista puede decirle al usuario cuál es el problema, en caso de problemas que no requieran pruebas para el diagnóstico. Si el diagnóstico del problema requiere realizar una prueba, entonces el técnico desarrolla cualquier prueba necesario sobre la red. El técnico tendrá que coordinarse con otras personas, incluyendo al usuario, para realizar las pruebas necesarias. El técnico debe confiar en cualquier acción del usuario para corregir el problema y/o cualquier información respecto a cuál es el problema y qué tanto tiempo le llevará corregirlo, ya sea a través del usuario o a través del proveedor de servicios de la red. Otra técnica de aislamiento de problemas en la red implica el monitoreo de la información transmitida a través de la red y el análisis de esta información. Típicamente, una computadora central recolecta la información y la presenta a un técnico en un formato entendible. Al analizar esta información, los problemas de la red pueden aislarse. Sin embargo, esta técnica requiere típicamente de otras técnicas complejas de recolección y/o filtrado y/o presentación de los datos recolectados. También, puede resultar muy difícil aislar muchos de los problemas con el uso de esta técnica.

SUMARIO DE LA INVENCIÓN En general, en un aspecto, la invención proporciona un método que incluye indicar a una unidad de diagnóstico de red un problema experimentado por un usuario que está interactuando con la red. Los datos son transferidos entre la unidad de diagnosis de red y el usuario y entre la unidad de diagnosis de red y las porciones de la red que no corresponden al usuario, a fin de diagnosticar una causa del problema. El método incluye también reportar al usuario una indicación de la acción remediadora para corregir la causa. Las modalidades de este aspecto de la invención pueden incluir una o más de las siguientes características. La indicación del problema puede incluir que el usuario envíe un mensaje a la unidad de diagnóstico de red, lo cual originará una falla al enviar el mensaje a la red. El diagnóstico del problema puede incluir adaptarse a un protocolo inadecuado del mensaje enviado por el usuario y proporcionar una indicación al usuario respecto a un protocolo adecuado asociado con el mensaje. En general, en otro aspecto, la invención proporciona un método para mejorar las operaciones en red, el método incluye identificar los síntomas de las fallas de la red. Las causas de los síntomas identificados están asociadas con los síntomas. Los costos están asociados con la combinación de síntomas y causas. La combinación de alto costo de causas y síntomas tiene un mayor costo asociado que los costos asociados con otras combinaciones de causas y síntomas. La causa de una combinación de alto costo de causas y síntomas es el objetivo para la reducción de costos asociada con la combinación de costo de causas y síntomas . En general, en otro aspecto, la invención proporciona un método para mejorar las operaciones de la red, el método incluye indicar síntomas de fallas de red a lo largo de un primer eje de una gráfica. Las causas de los síntomas se indican a lo largo de un segundo eje de la gráfica. Los costos asociados con la combinación de los síntomas y las causas se indican en los puntos de la gráfica asociados con las respectivas combinaciones de síntomas y causas. En general, en otro aspecto, la invención proporciona un sistema para utilizarse con una red de datos, el sistema incluye unidades de diagnóstico múltiples, cada una de ellas adaptada para comunicarse con la red, incluyendo con un usuario de la red. Un controlador central está conectado operativamente a las señales de diagnóstico, el controlador está adaptado para comunicarse con las unidades de diagnóstico y coordinar la operación de las mismas, para dar instrucciones a las unidades de diagnóstico respecto a la realización de pruebas adaptadas para ayudar a aislar una falla de la red, y para analizar los resultados de prueba recibidos desde una unidad de diagnóstico, a fin de intentar determinar la falla de la red. Las modalidades de este aspecto de la invención pueden incluir una o más de las siguientes características. Las unidades de diagnóstico pueden distribuirse en ubicaciones por toda la red. El controlador puede adaptarse para instruir a múltiples unidades de diagnóstico a realizar pruebas concurrentes. El controlador puede adaptarse para instruir a una unidad de diagnóstico a que inyecte datos de prueba hacia la red. El controlador puede adaptarse para instruir a una primera unidad de diagnóstico a inyectar datos de prueba hacia la red y a una segunda unidad de diagnóstico a monitorear una respuesta de red frente a los datos de prueba inyectados por la primera unidad de diagnóstico. Una unidad de diagnóstico podrá adaptarse para aceptar los datos proveniente de un usuario en un protocolo incompatible con un elemento de la red, hacia el cual se pretende se envíen los datos, para comunicarse con el elemento de red utilizando un protocolo compatible con el elemento de red y para comunicarse con el usuario utilizando un protocolo compatible con el protocolo de los datos provenientes del usuario. El controlador puede adaptarse para determinar operaciones para instruir a una unidad de diagnóstico a que las realice con base en prioridades comerciales predeterminadas.

En general, en otro aspecto, la invención proporciona una unidad de diagnóstico de red que incluye un procesador conectado de manera selectiva y operativa a la primera y segunda porciones de una red de datos, la segunda porción incluye a un usuario de red. La unidad de diagnóstico de red también incluye una memoria legible para el procesador, para almacenar instrucciones para ocasionar que el procesador: reciba los primeros datos desde una porción específica de la primera y segunda porciones de la red; determinar segundos datos correspondientes a los primeros datos y que simulan los mismos en un protocolo compatible con la porción de la red que no corresponde a la porción específica; y transmitir los segundos datos hacia la porción de la red que no corresponde a la porción específica. En general, en otro aspecto, la invención proporciona un producto de programa para computadora que se utiliza con una computadora instalada en una red de comunicaciones que incluye elementos de red, el producto de programa para computadora incluye instrucciones para hacer que una computadora: acepte datos provenientes de una fuente en un protocolo de fuente inconsistente con el protocolo del elemento de red, de un elemento de red seleccionado; establecer un enlace de comunicación con la fuente, y enviar una indicación de los datos recibidos desde la fuente hacia el elemento de red seleccionado, en un protocolo consistente con el protocolo de elemento de red. Las modalidades de este aspecto de la invención pueden incluir otras instrucciones para hacer que una computadora determine si el protocolo fuente está inhibiendo la comunicación entre la fuente y el elemento de red seleccionado. En general, en otro aspecto, la invención proporciona un producto de programa de computadora que se utiliza con una computadora instalada en una red de comunicaciones que incluye elementos de red, el producto de programa para computadora incluye instrucciones para hacer que una computadora: reciba datos desde un usuario, inyecte datos de prueba hacia la red de comunicaciones en respuesta a los datos recibidos del usuario; y monitoree una respuesta de red frente a los datos de prueba. Las modalidades de este aspecto de la invención podrán incluir otras instrucciones para hacer que una computadora determine si inyectar más datos de prueba a la red de comunicación, de acuerdo con la respuesta de red monitoreada por la computadora. En general, en otro aspecto, la invención proporciona un sistema de diagnóstico que se utiliza en una red, el sistema incluye una primera unidad de diagnóstico conectada a la red y que es capaz de inyectar datos de prueba hacia la red. Una segunda unidad de diagnóstico está conectada la red y es capaz de monitorear una respuesta frente a los datos de prueba y proporcionar una indicación de la respuesta monitoreada. Las modalidades de este aspecto de la invención pueden incluir una o más de las siguientes características. El analizador puede además ser capaz de determinar si deben inyectarse más datos de prueba hacia la red y proporcionar una indicación de esta determinación a una de las unidades de diagnóstico. Los datos de prueba pueden ser los primeros datos de prueba y la segunda unidad de diagnóstico es capaz de inyectar segundos datos de prueba hacia la red, de manera que los primeros y segundos datos de prueba afectan a la red al mismo tiempo. La primera unidad de diagnóstico puede desplazarse de la segunda unidad de diagnóstico en la red. Otros aspectos de la invención podrán proporcionar una o más de las siguientes ventajas. Las fallas pueden aislarse a través de una red heterogénea a diferentes capas de protocolo, en incluso a todas, como se identifica por la Organización Internacional de Normas (ISO- International Organization for Standardization) en el modelo ISO 7498. Las fallas pueden aislarse sin conocimiento de la topología de la red o actualizando el conocimiento de la topología de la red. Cuando la información de la topología de la red es requerida para el aislamiento de la falla, la topología de la red puede determinarse utilizando algoritmos automatizados de descubrimiento de topología. La reparación de las fallas aisladas puede verificarse. La justificación con base a la regla, la justificación con base al caso, el aprendizaje de la máquina, las gráficas de las fallas y otras técnicas de diagnóstico de representación de conocimiento en el dominio de la inteligencia artificial pueden utilizarse para aislar fallas. Las causas determinadas de las fallas pueden utilizarse para mejorar el conocimiento de aislamiento de fallas. Las fallas en una red pueden aislarse por un sistema simple e integrado. Los componentes de prueba activos pueden utilizarse para aislar fallas, por ejemplo inyectando datos de prueba hacia una red. Las fallas pueden aislarse con un análisis automatizado más incluyente y más exacto que con la recolección pasiva de datos y el análisis de estos datos recolectados en forma pasiva. Las fallas pueden aislarse rápidamente y con ausencia total o poca intervención del personal de soporte. Las pruebas de aislamiento de fallas pueden realizarse revisando una red, en forma alejada de un usuario u observando desde la red, hacia el usuario. Estas pruebas pueden efectuarse independientemente de la configuración u operación del usuario o la red, respectivamente. La comunicación con un usuario de red es posible incluso si el protocolo del usuario y/o la configuración resultan algo inadecuadas, inhibiendo la comunicación con otras porciones de la red. Pueden hacerse adaptaciones a un protocolo inadecuado de un usuario de red y/o a la configuración. El usuario y/o o la red pueden simularse uno a otro. La prueba de aislamiento de fallas puede efectuarse bajo control centralizado. La prueba de aislamiento de fallas en varios puntos de la red puede coordinarse de manera que, por ejemplo, puedan realizarse pruebas en forma simultánea y el impacto de los datos de pruebas inyectados hacia una red en un punto de la red pueda determinarse en otro punto de la red. El aislamiento de fallas puede hacerse con base en un sistema experto. Se puede aislar a los usuarios de la red de las fallas que les producen problemas, con o sin asistencia del personal de soporte. Las interacciones complejas de red pueden reducirse a simple información. Se puede informar a los usuarios respecto a acciones de corrección para corregir las fallas que producen los problemas para el usuario y se les puede informar de cómo llevar a cabo esas acciones correctivas. Puede mejorarse el tiempo activo de la red, la confiabilidad, el desempeño y el tiempo respuesta/reparación. Los síntomas y las raíces que los causan pueden graficarse para determinar las causas que hay que atacar para una reducción de ocurrencia/costo. Los síntomas y sus causas raíz pueden monitorearse para determinar mejoras en la reducción ocurrencia/costo de las combinaciones síntoma-causa.

BREVE DESCRIPCIÓN DE OS DIBUJOS Las figuras 1 a 2 son diagramas parcialmente esquemáticos de una red de comunicaciones. La figura 3 es un diagrama de bloques de un proceso para aislar fallas en la red de comunicaciones mostrada en la figura 1. La figura 4 es un diagrama funcional de interacciones entre porciones de la red mostradas en la figura 1. La figura 5 es un diagrama de bloque de un proceso de un usuario que está marcando a una unidad de diagnóstico . La figura 6 es un diagrama de bloque de una gráfica acíclica dirigida, que implementa una representación del conocimiento de diagnóstico de la red. Las figuras 7 a 15 son diagramas funcionales de las interacciones entre las porciones de la red mostradas en la Figura 1 para el aislamiento de fallas en la red. La figura 16 es un diagrama de barras tridimensional de la combinación de los síntomas de la red y las causas de los mismos.

DESCRIPCIÓN DE LAS MODALIDADES PREFERIDAS La invención proporciona técnica para el aislamiento mejorado de fallas y la reducción de las mismas. El dispositivo de diagnóstico puede colocarse a través de una red de comunicaciones bajo un control centralizado. Estos dispositivos de diagnóstico pueden comunicarse con una terminal de usuario para determinar un problema o síntoma experimentado por un usuario, por ejemplo, cuando se trata de transmitir o recibir datos, incluso si la terminal de usuario no puede comunicarse con un protocolo adecuado para las interacciones deseadas de la red. Los problemas o síntomas son aquellos que reporta el usuario como constancia de una falla en la red. Las fallas también pueden denominarse causas o causas raíz. A través de las comunicaciones con el usuario y otras porciones de la red, los dispositivos de diagnóstico, con ayuda del control centralizado en caso necesario, pueden aislar las fallas en la red e indicar y registrar la fallas y las acciones correctivas, e iniciar la acción correctiva correspondiente. Las fallas pueden supervisarse y la acción puede llevarse a cabo para reducir la frecuencia con la que ocurren las fallas. Los dispositivos de diagnóstico pueden estar bajo el control de un proveedor del servicio de Internet (ISP) y la acción correctiva puede ser iniciada solamente para las fallas que el ISP puede corregir. Los dispositivos de diagnóstico podrán, sin embargo, estar bajo el control de otras entidades y/o las acciones correctivas podrán ser iniciadas para las causas que no pueda corregir el ISP. Como se muestra en la figura 1, una red de datos o comunicaciones 10 ejemplificativa, que aquí involucra a la Internet, incluye las instalaciones del cliente 12, un bucle o ciclo local 14, una central 16 y un sistema troncal 18, un Punto de Presencia (POP), una Red de Proveedor de Servicio de Internet (ISP Net) 22, la Internet 24 y una empresa 26. La red 10 muestra un ejemplo de las conexiones para los usuarios en las instalaciones 12 de usuario, para que interactúen con, por ejemplo: los sitios de la world wide web proporcionados por la empresa 26. Las instalaciones 12 del cliente incluyen una variedad de posibilidades para que las terminales de los usuarios se conecten al ciclo o bucle local 14. Por ejemplo, una computadora personal (PC) 28 se conecta a través de un módem analógico 30 a una línea telefónica 32, compartida por un teléfono 34 que se conecta a una línea 36 en el bucle o ciclo local 14. Otra PC 38 se conecta a través del equipo de terminación de red (NTE) 40 a una línea telefónica 42 en el bucle o ciclo local 14. El NTE 40 también está conectado a un teléfono 44. Un dispositivo de interfaz de usuario 46, que incluye una PC, un teléfono y capacidades de video, se conecta a un Concentrador de Servicio (SH) 48, que es una red integrada por demanda o por solicitud, que se conecta a una línea 50 en el ciclo o bucle local 14. Otra PC 52 se conecta a un módem 54 de línea de suscriptor digital (DSL) . El módem 54 y un teléfono 56 se acoplan a una línea 58 en el bucle o ciclo local 14, a través de un multiplexor 60. Las líneas 36, 42, 50 y 58 en el bucle o ciclo local son las conexiones (que normalmente son pares de alambres de cobre) entre el usuario, por ejemplo, el hogar o el negocio del usuario, y la compañía telefónica local. En el sentido aquí utilizado, el término "usuario" puede indicar a la persona que interactúa con la red 10 y/o los dispositivos, por ejemplo: una PC, que el usuario utiliza para interactuar con la red 10. Las líneas 36, 42, 50 y 58 están conectadas a la central telefónica 16, que incluye un conmutador 62, un enrutador/bus firewall 64, un multiplexor 66 y un Multiplexor de Acceso de Línea de Subscriptor Digital (DSLAM) 68. El DSLAM 68 proporciona una conexión entre las líneas de alta velocidad y el enrutador/bus firewall 64.

El conmutador 62 puede conectar la línea entrante 36, 42, 50 o 58 al troncal deseado, aquí el troncal 70, en el sistema troncal 18 que está conectado al POP 20 especificado por el login de la red del usuario. A través del multiplexor 66, la línea entrante 58 puede conectarse al conmutador 62 o al DSLAM 68. El DSLAM 68 puede procesar la información desde la línea 58 y transmitir la información procesada hacia el enrutador/firewall 64. El enrutador/firewall 64 puede inhibir la conexión adicional del usuario a la red 10, por ejemplo, dependiendo de la conexión solicitada (por ejemplo, para evitar acceso a sitios de web restringidos por la edad de los usuarios en una escuela primaria) . El enrutador/firewall 64 está conectado al POP 20 a través de un troncal 72 en el sistema troncal 18. La central 16 es parte de una Red de Teléfono Público Conmutada (PSTN) , el resto de la cual está indicada por PSTN 19. El POP 20 incluye un Servidor de Acceso de Red (ÑAS) , también llamado Servidor de Acceso Remoto (RAS) , 74 y un enrutador/firewall 76. El ÑAS 74 puede recibir información sobre la troncal 70 desde la central telefónica 16 y determinar si la información cumple con los criterios de acceso de otras porciones de la red 10. El ÑAS 74 está conectado al enrutador/firewall 76 mediante una línea 78. El enrutador/firewall 76 puede recibir información del enrutador/firewall 64 de la central telefónica 16 sobre la línea 72 y desde el ÑAS 74 sobre la línea 78, y puede enrutar la información a través de una línea 80 hacia la ISP Net 22. La ISP Net 22 incluye una red 82, un enrutador/firewall 84 y un servidor caché 86. La red 82 conecta al POP 20 con la ISP Net 22 y puede enrutar información recibida desde el POP 20 a cualquiera del enrutador/firewall 84 o al servidor caché 86. El servidor caché 86 proporciona soporte caché a la red central 82 para permitir rápidas transferencias de información desde el POP 20 hacia la ISP Net 22. El enrutador/firewall 84 conecta la red central 82 a la Internet 24. La Internet 24 conecta la ISP Net 22 a la empresa 26 para formar un enlace entre el usuario y la empresa 26. El enlace permite que la información del usuario sea pasada a la empresa 26 y la información de la empresa pase al usuario. La Internet 24 es la red de comunicación internacional bien conocida que proporciona enlaces de comunicación electrónicos entre, por ejemplo, sistemas de computadoras . La empresa 26 incluye un enrutador/firewall 88 y servidores 90 y 92. El enrutador/firewall 88 enruta información hacia y desde los servidores 90 y 92 y la Internet 24. Los servidores 90 y 92 pueden proporcionar diversas informaciones y servicios, por ejemplo, sitios web. Por ejemplo, el servidor 90 puede ser un sitio web para adquirir libros y grabaciones de video y audio y el servidor 92 puede ser una revista en línea que proporciona críticas sobre los artículos que pueden adquirirse a través del servidor 90. Aunque en este ejemplo los servidores 90 y 92 proporcionan servicios/información relacionados, esto no se requiere. Como se muestra, una red de Modo de Transferencia Asincrona/Relé de Cuadro (ATM/FR) 27 proporciona protocolos para comunicaciones de larga distancia. La red ATM/FR 27 es la red estructural que une a la central telefónica 16, al POP 20, a la ISP Net 22, la Internet y a la empresa 26. Como se muestra en la figura 2, la red 10 incluye Unidades de Diagnóstico de Internet (UDU) 94 y 96 y un controlador del sistema 98. Juntas, las IDU 94 y 96 y el controlador de sistema 98 forman un sistema de diagnóstico 99 para aislar fallas en la red 10. Las IDU 94 y 96 están conectadas al controlador central 98 para comunicación bilateral a través de las conexiones de red 100 y 102, respectivamente. La red 10 también incluye varios operadores o recepcionistas 105, conectados al controlador del sistema 98 que forman un servicio de recepción 103. Aunque los recepcionistas 105 se muestran agrupados en una ubicación común, pueden estar distribuidos en diferentes ubicaciones en toda la red 10. Las porciones de la red 10 se muestran en la figura 2 con más detalle y otras porciones se muestran con menos detalle que la figura 1. Específicamente, dos POPs 104, 106 se muestran y cada uno incluye más detalles que el POP 20 mostrado en la figura 1. Los POP 104, 106 incluyen conmutadores ethernet (Conmutadores E) 111, 113, 115, 117 que pueden inhibir o permitir conexiones hacia los enrutadores 119, 121, 123, 125, respectivamente. Los POP 104 y 106 incluyen a las IDU 94 y 96, respectivamente: Las IDU 94 y 96 son hardware con programas de software asociados con instrucciones para que el hardware desarrolle las funciones de ayuda del diagnóstico y aislamiento de problemas en la red 10. El hardware de las IDU 94 y 96 puede dedicarse a diagnosticar problemas en la red o pueden ser unidades no dedicadas que se utilizan también para otras funciones. Un ejemplo de las IDU no dedicadas es una computadora personal que almacena software de diagnóstico, por ejemplo, en el disco duro, en la memoria de acceso aleatorio, en la memoria sólo de lectura, en una unidad zip, en un CD-ROM, en un disco flexible o en una FLASH-ROM. Como se muestra, las IDU 94 y 96 se distribuyen en toda la red 10. Las IDU pueden estar presentes en ubicaciones distintas a los POP, por ejemplo las ISP Nets o en las instalaciones del cliente 12. Debido a la naturaleza flexible del software, las IDU pueden estar presentes prácticamente en cualquier lugar de la red 10 y pueden tener porciones de su funcionalidad, como se describe a continuación, en diferentes ubicaciones de la red 10. En general, mientras más IDU haya en el sistema y haya más ubicaciones en todos los sistemas donde están presentes las IDU, mejor será la resolución de fallas en la red 10. Las IDU 94 y 96 pueden comunicarse con porciones de la red 10 hacia el interior desde el usuario. Al observar "hacia adentro" de la red 10, en forma alejada del usuario, las IDU 94 y 96 pueden determinar si existen problemas con la red 10 en forma independiente de los problemas con la configuración o información del usuario. Las IDU 94 y 96 pueden comunicarse con la red 10 utilizando su información propia predeterminada que es compatible con la red 10. Por lo tanto, las IDU 94 y 96 pueden simular al usuario frente a la red 10, de manera compatible con la red 10, incluso si la configuración del usuario no es compatible con otras porciones de la red 10. Las IDU 94 y 96 pueden introducir o inyectar datos de prueba hacia la red 10. Los resultados de la prueba se monitorean por las IDU 94 y 96 y son enviados al controlador central 98 para su análisis. Los datos de prueba pueden diseñarse y destinarse, por ejemplo, a eliminar una o más categorías de las posibles causas de un problema, a eliminar una causa posible específica, a identificar una o más categorías de causas posibles de un problema o a determinar que una causa posible específica es la causa real de un problema en la red. Los datos de prueba inyectados de este último tipo pueden llamarse "ping" (eco de respuesta) . Las IDU 94 y 96 pueden comunicarse con el usuario independientemente de otras porciones de la red 10. Al ver "hacia fuera" de la red 10, hacia el usuario, las IDU 94 y 96 pueden determinar si las fallas existen con el usuario, en forma independiente de las fallas con la información de la red o la configuración. Por lo tanto, las IDU 94 y 96 pueden simular porciones de la red 10 hacia el usuario, incluso si las fallas de la red inhibieran o evitaran la comunicación con el usuario. Por ejemplo, las IDU pueden aceptar una petición de un Sistema de Nombre de Dominio (DNS) proveniente del usuario, incluso si la petición está dirigida a una dirección IP errónea. Las ID pueden efectuar una búsqueda adecuada y suministrar una respuesta DNS correcta. Las IDU también pueden inyectar datos de prueba hacia el sistema del usuario o introducir datos de prueba al mismo, monitorear los resultados y pasar los resultados al controlador 98. Al comunicarse con el usuario y el resto de la red 10, las IDU 94 y 96 pueden servir como un servidor de acceso de red, por lo menos durante el diagnóstico de los problemas de red. Para ayudar a la comunicación con el usuario, las IDU 94 y 96 incluyen software para implementar un protocolo tolerante a fallas. Este protocolo permite que las IDU 94 y 96 establezcan un enlace con el usuario, incluso si el usuario está intentando comunicarse con la red 10 utilizando un protocolo o configuración inadecuada. Las IDU 94 y 96 pueden comunicarse con los usuarios que están suministrando un protocolo que es inconsistente con un protocolo de un elemento de la red con el cual el usuario desea comunicarse. Esto permite que el sistema 99 se comunique con el usuario, por ejemplo, para enviar información de diagnóstico al usuario, para ayudar a aislar la falta que provoca el problema/síntoma que está experimentando el usuario, cuando el usuario pudiera de otra suerte no ser capaz de comunicarse con la red 10 en ningún momento, y por lo tanto no se entendería porque el usuario no es capaz de comunicarse en la forma deseada con la red 10. El protocolo tolerante a fallas permite la comunicación con un usuario configurado inadecuadamente, al adaptarse al protocolo del usuario. Con el protocolo tolerante a fallas, una IDU se adapta a la configuración del usuario para permitir que las conexiones se realicen y se haga la comunicación. Los protocolos incluyen indicaciones de pasos de transacción, formato de datos y datos, por ejemplo, una dirección de Protocolo de Internet (IP) . Por lo tanto, por ejemplo, durante la negociación del Protocolo de Control del Protocolo de Internet (IPCP) la IDU puede aceptar una dirección IP si el usuario insiste en ello, o puede asignar una dirección IP si el usuario no insiste en ninguna dirección. El IDU también registra información sobre el comportamiento del usuario y/o la configuración por comparación con una base de datos para determinar errores con el comportamiento y/o configuración del usuario, por ejemplo, que el usuario intente conectarse con una dirección IP estática mientras que la base de datos indica que el usuario debe conectarse con una dirección IP dinámica . El sistema 99 emplea un planteamiento centrado en el protocolo e independiente de la topología para aislar las fallas. Este planteamiento permite que el sistema 99 aisle las fallas sin tener conocimiento predeterminado de la topología de red. El sistema 99 puede determinar si la red 10 contiene una falla sin tener que saber cómo debe actuar la red 10. Con base en los protocolos, el sistema 99 puede adaptarse a diferentes topologías y determinar que existe una falla. Sin embargo, si el sistema 99 necesita o desea tener una información de topología para aislar fallas particular, el sistema 99 emplea algoritmos de descubrimiento de topología automatizados. Estos algoritmos pueden determinar la topología de la red 10, como por ejemplo, qué tipo de hardware está en la red 10, cómo está conectado el hardware y qué porciones de la red 10 son accesibles. El controlador 98 de sistema controla al sistema 99 a fin de diagnosticar y aislar las causas raíz de los problemas de la red. El controlador 98 es una computadora de alta velocidad capaz de implementar inteligencia artificial para aislar los problemas de la red. La indicaciones de los problemas se envían al controlador 98 mediante las IDU 94 y 96. El controlador 98 coordina el aislamiento de la causa raíz del problema o problemas mediante, por ejemplo, instrucciones a una IDU a fin de que monitoree cierta información que el controlador 98 puede filtrar y analizar. El controlador 98 también puede hacer que una IDU inyecte datos de prueba, por ejemplo, protocolos de prueba hacia la red 10. Las instrucciones del controlador 98 pueden solicitar que el usuario desarrolle cierta operación. También, el controlador 98 puede hacer que varias IDU efectúen pruebas coordinadas, por ejemplo, inyectando datos hacia diferentes porciones de la red 10, de manera que una o más porciones de la red 10 estén procesando datos de prueba (los datos de prueba están afectando la red) al mismo tiempo, o inyectando datos de prueba en una porción de la red 10 y monitoreando los resultados en otra porción de la red 10. Esto permite una prueba compleja de las respuestas de la red que no sería posible si se utilizara una sola IDU, o si se utilizaran varias IDU que no pudieran actuar en conjunción entre sí. Una o más de las características de diagnóstico del controlador 98 pueden proporcionarse para, por ejemplo, programarse en la IDU 94 y/o 96. Por lo tanto, las IDU 94 y/o 96 pueden diagnosticar por sí mismas fallas en la red, independientemente de un controlador. Las IDU 94 y 96 pueden comunicarse con el usuario a través de una porción de la red 10 llamada enlace de usuario. El enlace de usuario se comunica directamente con el usuario y es una interfaz entre el usuario y el sistema 99. El enlace de usuario proporciona datos al usuario, por ejemplo, preguntas de solicitud de información sobre la naturaleza de los problemas encontrados por el usuario. Los datos de situación o condición son suministrados al usuario a través del enlace de usuario, así como las indicaciones de los resultados del aislamiento de la falla realizado por el controlador 98. El controlador 98 determina qué datos presentar al usuario a través del enlace de usuario para ayudar a aislar las fallas y para informar al usuario los resultados . La figura 3 ilustra un proceso 120 parar aislar las fallas en la red 10. Como se muestra, en el paso 122, el usuario intenta tener acceso a una porción de la red 10, por ejemplo, un sitio web, a través de una ruta 127 (figura 2) pero no lo logra. Para tratar y resolver la falla, el usuario llama a la línea de ayuda en el paso 124. Un operador en la mesa de ayuda habla con el usuario para tratar de aislar y corregir la falla. Para ayudar al aislamiento, en especial para fallas que el operador no puede aislar rápidamente, el operador da instrucciones al usuario para que marque un número de diagnóstico. En el paso 128, el usuario llama al número del diagnóstico asociado con la IDU, por ejemplo, IDU 94 (figura 2) . El operador puede estar en contacto con el usuario, por ejemplo, si el operador no se siente cómodo al interactuar con la IDU 94 a través del enlace del usuario. En el paso 130, la IDU 94 acepta la llamada del usuario para formar una ruta de diagnóstico 131 (figura 2) e intenta negociar una conexión con el usuario (por ejemplo, la PC del usuario) . Durante la negociación, el usuario y la IDU se comunican con objeto de encontrar un conjunto compatible de valores a partir de los conjuntos de valores aceptables que tiene cada uno. En el paso 132, una o más IDU, por ejemplo, las IDU 94 y 96 (figura 2), bajo las instrucciones del controlador 98 (figura 2), realizan pruebas en la red 10 (figura 2) . Las pruebas continúan utilizando la retroalimentación de las pruebas previas para determinar más pruebas, hasta que se aisla la falla, si es posible. Los resultados de las pruebas se reportan por las IDU 94 (y 96) al controlador 98 en la etapa 134. En la etapa 136, se inicia la acción correctiva, si es posible. Por ejemplo, puede enviarse un mensaje al Centro de Operaciones de Red ISP (NOC) en la ISP Net 22 (figura 1) indicando la causa de acción para corregir/arreglar el problema. Pueden enviarse mensajes a otras porciones de la red 10 (figura 1) incluso si no se hace bajo el control del ISP. También, se informa al usuario, por ejemplo, mediante la IDU 94 o por medio del operador, sobre la falla y cualquier acción correctiva que se está llevando a cabo y sobre quién la está llevando a cabo, sobre la acción correctiva que llevará a cabo el usuario o por qué no se tomará ninguna acción correctiva. Los resultados de qué raíz provocó o produjo el problema reportado por el usuario se obtienen para el procesamiento futuro, por ejemplo, de intentar reducir la aparición de fallas. El proceso 120 termina, por ejemplo, cuando el usuario se desconecta del sistema 99 (figura 2) . Como se muestra en la figura 4, los pasos 124, 126, 128 y 130 (figura 3) implican varias transacciones con un recepcionista 105 (figura 2), el usuario (subscriptor) 140, el navegador del usuario 142, el enlace de usuario 144, un enlace experto 146 (por ejemplo, el controlador del sistema 98 - figura 2), un enlace de acceso 148 (por ejemplo, una IDU) , el POP 20 (figura 1) y la ISP Net 22 (figura 1) . El navegador 142 puede incluir cualquier aplicación de red, por ejemplo, correo electrónico, navegación en la web, servicios de mensajería, audio, video, chat, Protocolo de Internet con Voz Sobrepuesta (VOIP) , transferencia de archivos, actualizaciones automatizadas de software, monitoreo de condición de paciente médico, aprendizaje a distancia y aplicaciones de noticias de la red. Las flechas de la figura 4 y las figuras similares siguientes indican la dirección del flujo de datos . En el paso 124, el usuario 140 llama al recepcionista 105 para reportar un problema en el paso 124a. En respuesta a la llamada del usuario, el recepcionista 105 inicia una sesión de enlace de usuario con el enlace de usuario (es decir, interfaz de usuario) 144 en la etapa 124b. El recepcionista 105 actúa con el enlace de usuario 144 para relevar la información sobre el problema reportado por el usuario. En el paso 126, el enlace de usuario 144 llega a la conclusión de que el usuario 140 debe marcar al enlace de acceso/lDU 148. En el paso 126a, el enlace de usuario 144 transfiere esta conclusión al recepcionista 105 y el recepcionista 105 proporciona instrucciones adecuadas al usuario 140, en el paso 126b. En el paso 128 (figura 5) , el usuario 140 marca a la IDU 148, de acuerdo a las instrucciones recibidas 128a. La IDU 148 contesta la llamada del usuario 128b, de manera que las acciones adecuadas puedan llevarse a cabo para establecer la comunicación entre el usuario 140 y la IDU 148. En el paso 130 y, en particular en el paso 130a, se presenta un entrenamiento adecuado del módem y la negociación del Protocolo Punto a Punto (PPP) , con el análisis e inscripción correspondiente de los datos, hasta que el usuario (por ejemplo, la terminal de usuario) 140 y la IDU 148 pueden comunicarse. Si el usuario 140 no puede tener acceso a la IDU 148, entonces el recepcionista 105 pueden efectuar una sesión de diagnóstico guiada a fin de diagnosticar una falla o fallas que producen el problema del usuario. Algunas fallas no podrán ser aisladas utilizando esta sesión guiada. Por ejemplo, los problemas que se relacionan con la conectividad a un POP no pueden ser diagnosticables debido a la incapacidad del usuario para conectarse a la IDU 148. Si el usuario 140 está encerrado en un protocolo X2 y la llamada del usuario fue contestada por un ÑAS estándar que sólo soporta KFlex, V.90, y protocolos más lentos, entonces la conexión entre el ÑAS y el usuario 140 podrá fallar. El protocolo tolerante a fallas de la IDU 148 es, sin embargo, capaz de comunicarse son una amplia gama de protocolos a fin de negociar un protocolo compatible entre la IDU 148 y el usuario 140. También, la IDU 148 y el usuario 140 negocian con un Protocolo de Control de Enlace (LCP) . Una vez más, si se utiliza una ÑAS estándar en lugar de una IDU 148, esta negociación puede fallar, por ejemplo si el PPP del usuario requiere del Protocolo de Autenticación de Contraseña (PAP) mientras que el ÑAS puede solamente permitir CHAP . La IDU 148 permitirá, sin embargo, muchas opciones para adaptarse a diferentes requerimientos de usuario . En las etapas 130a y 130b, la autenticación IDU a usuario ("hacia fuera") y la autenticación IDU a ISP Net ("hacia adentro") se presentan. La IDU 148 se destraba hacia el navegador 142 del usuario para autenticar la contraseña del usuario para que se utilice con la IDU 148. Los datos son inscritos y analizados. En el paso 130b, la IDU 148 se engancha a la red 10 (figura 1) hacia la ISP Net 22 para autenticar la contraseña suministrada por el usuario 140 y capturada por éste, para que sea utilizada con la ISP Net 22. La negociación IPCP se presenta entre la IDU 148 y el usuario 140 y los datos son inscritos y analizados (por ejemplo, se asigna una dirección de protocolo de Internet/netmask) . Si una AS estándar se utiliza en lugar de la IDU 148, entonces esta negociación puede fallar, por ejemplo, si la pila IP del usuario se configura para IP estática y la ÑAS se configura para asignación dinámica. La IDU tolerante a fallas 148 puede, sin embargo, permitir que diferentes direcciones IP soporten (y detecten) a usuarios con mala configuración 140 para ayudar a asegurar que la negociación tenga éxito. La IDU 148 también abre una sesión de control con el ExpertLink/controlador 146 y envía información del subscriptor al controlador 146. En el paso 130c, el usuario 140 lanza al navegador 142 de usuario, por ejemplo, un navegador de Internet. En el paso 130d, el usuario 140 proporciona una URL al navegador 142 de acuerdo a las instrucciones del recepcionista 105. El navegador 142, la IDU 148 y el enlace de usuario 144 entran a una serie de transacciones para establecer comunicación entre el usuario 140 y la IDU 148. En el paso 13Oe, el navegador 142 del usuario envía una petición de NS a la IDU 148, que responde al navegador 142 en el paso 13 Of con una respuesta DNS predeterminada. Mientras que un sistema con un AS estándar puede fallar si el usuario utiliza un servidor DNS inadecuado o el servidor DNS no funciona, la IDU tolerante a fallas 148 puede proporcionar el servicio DNS. En el paso 13 Og, el navegador 142 envía una petición de Protocolo de Transferencia de Hipertexto (HTTP) a la IDU 148, que responde al navegador 142 en el paso 13Oh con una respuesta de redireccionamiento http, enviando el navegador 142 a una URL canónica (por ejemplo, http://www.diag.com/Start/). El navegador 142 envía una petición DNS para la URL canónica y la IDU 148 envía una respuesta DNS para la URL canónica hacia el navegador 142. El navegador 142 establece una conexión de protocolo de control de transmisión (TCP) con la IDU 148 y envía una petición HTTP en el paso 130 y a la IDU 148 para la URL canónica. En el paso 130j, la IDU 148 envía la petición HTTP al enlace de usuario 144, que envía una respuesta HTTP de una página de enlace de usuario inicial a la IDU 148, en el paso 130k. En el paso 1301, la IDU 148 envía la respuesta HTTP al navegador 142, por ejemplo, para exhibir una página web de diagnóstico 141 en la terminal del usuario. Haciendo de nuevo referencia a la figura 3, con una conexión establecida con el usuario en el paso 130, el proceso 120 continúa al paso 132 en donde una o más de las IDU 94 y 96 (figura 1) desarrollan pruebas para aislar la falla que provocó el problema del usuario. Dependiendo de la información proporcionada por el usuario y los resultados de la prueba desarrollada por una o más de las IDU 94 y 96, el controlador 98 (figura 1) determina cómo proceder al aislar la causa raíz del problema. Para hacer esto, el controlador 98 corre un software de control de proceso de diagnóstico con base en inteligencia artificial, que contiene una serie de rutas de acción. Un ejemplo simplificado de una gráfica acíclica dirigida (DAG) 110 que ilustra las instrucciones de software implementadas por el controlador 98 en el paso 132, se muestra en la figura 6. Una serie de pruebas indicada en el DAG 110 mediante nodos o casillas 112a-112t, están conectadas por rutas indicadas por las flechas que conectan a las casillas 112a-112t. Las pruebas pueden hacerse, por ejemplo, con preguntas para el usuario 140 (figura 4) o con datos monitoreados desde la red o inyectados hacia la red 10 (figura 1) por una o más IDU 94, 96 (figura 2) . La información suministrada por el usuario y/o los resultados de las pruebas determinan qué ruta seguir. Estos datos se procesan de acuerdo a las decisiones que implementan, por ejemplo, propiedades comerciales como la reducción de costos de reparación y/ tiempos de reparación. Cuando el DAG 110 llega a uno de los nodos de terminación (112f, 112i, 112j , 112k, 1121, 112m, 112n, 112o, 112p, 112q, 112r, 112s o 112t, la falla se ha aislado en la medida de lo posible por el software DAG. En este punto, los resultados se reportan al controlador 146 (figura 4; paso 13, figura 3), y el controlador 146 puede iniciar la acción correctiva, informar al usuario 140 (figura 4) de la acción o dar instrucciones al usuario 140 para llevar a cabo la acción correctiva (paso 136, figura 3) . También puede proporcionarse otro tipo de información, por ejemplo, cuando la acción correctiva puede completarse. Los resultados de aislamiento de falla logrados (paso 136, figura 3) pueden utilizarse para mejorar el DAG 110. Al analizar las combinaciones almacenadas de problemas/síntomas del usuario y las fallas/causas que condujeron a esos problemas/síntomas, el DAG 110 puede modificarse para aislar de manera exacta y más rápida las fallas . Las figuras 7 y 8 ilustran transacciones ejemplificativas para aislar una falla, como se indica en el paso 132 de la figura 3, en donde la falla o causa raíz es un mensaje de correo electrónico muy grande en una fila POP y el usuario está cancelando los intentos de recibir el correo electrónico antes de que el correo electrónico pueda ser bajado. Haciendo referencia a la figura 7, en los pasos 150 y 152, el usuario 140 y la interfaz de usuario 144 interactúan para determinar el problema del usuario. Pueden ser necesarias varias interacciones con el usuario 140 para que suministre información en respuesta a las preguntas hechas por el enlace de usuario 144, por ejemplo, a través de una página web de diagnóstico 149 que se exhibe en un monitor de la computadora del usuario. Esta interacción continúa hasta que el problema inicial del usuario 140 queda descrito adecuadamente. En los pasos 154, 156, 158 y 160, se realiza una prueba de recibir un correo electrónico. En el paso 154 el enlace de usuario 144 emite una petición de prueba de recibir correo electrónico hacia el enlace experto 146. El enlace experto 146 envía la prueba de correo electrónico recibida hacia la IDU 148 en el paso 156. En respuesta, en el paso 158 la IDU 148 reconoce que los recursos de prueba están disponibles. En el paso 160, el enlace experto 146 reconoce al enlace de usuario 144 que el enlace experto 146 está dando inicio a la prueba. En el paso 162, el enlace de usuario 144 instruye al navegador 142 a exhibir en pantalla una página de instrucciones 163 para que el usuario 140 la vea. La página de instrucciones 163 instruye al usuario 140 a recuperar el correo electrónico en una forma normal, lanzando la aplicación de correo electrónico del usuario y, por ejemplo, utilizando un ratón o accionando un botón continuo, según sea lo indicado para el navegador 142. En los pasos 164, 166, 168, 170, 172 y 174, el navegador 142 y la IDU 148 interactúan para efectuar el análisis de la prueba de correo electrónico recibido. En el paso 164, el usuario 140 ha iniciado el programa de correo electrónico del usuario e intenta recuperar el correo electrónico con las instrucciones del enlace de usuario 144, y el navegador 142 envía una petición DNS para el servidor POP y para la IDU 148. La IDU 148 envía una respuesta DNS en el paso 166. En el paso 168 el navegador 142 envía una petición POP (por ejemplo, para abrir una conexión TCP y enviar la contraseña del nombre del usuario y la petición de lista de correo electrónico) . En el paso 170, la IDU 148 envía una respuesta POP predeterminada relativa a que hay un mensaje pendiente. En el paso 172, el navegador 142 envía a la IDU 148 un mensaje de petición o una orden de lectura. La IDU 148 responde en el paso 174 enviando un mensaje de diagnóstico de prueba predeterminado hacia la aplicación de correo electrónico del navegador 142. Al mismo tiempo, el enlace de usuario 144 puede actualizar al navegador 142 de usuario con instrucciones adicionales. Por ejemplo, el usuario 140 puede presentarse con una página 175 que indica una opción para hacer clic en el ratón sobre un área designada del monitor del usuario si el usuario 140 recibió el mensaje. El usuario 140 emite una indicación de salir del POP y la IDU 148 envía los resultados de esta prueba al enlace experto 146. Haciendo referencia también a la figura 8, en los pasos 176, 178 y 180, una prueba de correo electrónico que ve hacia el interior de la red 10 (figura 1) inicia. En el paso 176, el usuario 140 envía una petición HTTP, por ejemplo, haciendo clic en un botón continuo del monitor del usuario. El enlace de usuario 144 hace una pregunta al enlace experto 146 respecto a qué operación tiene que desarrollar. En el paso 178, el enlace experto 146 da instrucciones al enlace de usuario 144 indicando que se va a efectuar una observación al interior de la prueba de recepción de correo electrónico. En el paso 180, el enlace de usuario 144 envía una respuesta HTTP al navegador 142, a fin de informar al usuario 140 sobre lo que está sucediendo. Por ejemplo, puede presentarse al usuario 140 una página 181 que indique que no hay ningún problema con la configuración de usuario y que la prueba de red se está llevando a cabo o se llevará a cabo. En los pasos 182, 184, 186, 188, 190, 192, 194, 196 y 198, la observación al interior de la red 10 para la prueba de recepción de correo (figura 1) se observa y se analizan los resultados. En el paso 182, el enlace experto 146 da instrucciones a la IDU 148 para iniciar la observación hacia el interior de la red 10 respecto a la prueba de recepción de correo electrónico (figura 1) . La IDU 148 reconoce que la prueba va a desarrollarse y la IDU 148 envía, en el paso 184, una petición DNS para el servidor POP hacia el servidor DNS de la ISP Net 22. En el paso 186, la ISP Net 182 envía una respuesta DNS a la IDU 148. En el paso 188, la IDU 148 envía una petición POP (por ejemplo, para abrir la conexión TCP, enviar nombre y contraseña del usuario y solicitar una lista de correo electrónico) . En el paso 190, el servidor POP de la ISP Net 22 envía una respuesta POP a la IDU 148 indicando que, por ejemplo, están pendientes cuatro mensajes. La IDU 148, en el paso 192, solicita el tamaño de los mensajes pendientes a la ISP Net 22. En el paso 194, la ISP Net 22 envía indicaciones del tamaño de los mensajes pendientes hacia la IDU 148. La IDU 148 solicita la transferencia de porciones de los mensajes pendientes para obtener las estadísticas de transferencia de los mismos. En el paso 196, la IDU 148 regresa los resultados de la observación al interior de la red 10 respecto a la prueba de recepción de correo electrónico (figura 1) hacia el enlace experto 146. En el paso 198, el enlace experto 146 analiza los resultados recibidos de la IDU 148 para aislar el problema. Como ya se observó, la IDU 148 puede incluir capacidades de diagnóstico y, por lo tanto, puede efectuarse el análisis en el paso 198, en la IDU 148. En los pasos 200, 202, 204, 206 y 208, los resultados del aislamiento de las fallas se proporcionan al usuario 140 y se archivan para uso adicional. En el paso 200, el enlace experto 146 envía indicaciones de los resultados al enlace de usuario 144. En el paso 202, el enlace experto 146 pide a la IDU 148 cerrar la prueba que la IDU 148 estaba realizando, en este caso, la observación al interior de la red 10 respecto a la prueba de restricción de correo electrónico (figura 1) . La IDU 148 inscribe cualquier conexión que tenga actualmente, por ejemplo una conexión POP. El enlace de usuario 144 notifica en el paso 204, al navegador 142, los resultados de la prueba. Los resultados proporcionados al navegador 142 incluyen cualquier acción requerida y también pueden solicitar más información del usuario 140 con objeto de decidir qué otra prueba desarrollar, en caso necesario. Una página ejemplificativa 205 de estos resultados de prueba proporcionados al navegador 142 se muestra a la figura 8, donde se indica al usuario que está pendiente un correo electrónico de gran tamaño y se le dan instrucciones de que espere a que este correo electrónico sea descargado o verifique el tamaño máximo posible de correo electrónico que puede recibir el usuario 140 o reconfigure este tamaño máximo de correo electrónico si no es lo suficientemente grande para recibir el correo electrónico pendiente . La información proporcionada también pregunta al usuario 140 si está satisfecho con la información proporcionada. En el paso 206, el navegador 142 envía una indicación de si el usuario 140 está satisfecho con el enlace de usuario 144. En el paso 208, los resultados de la sesión se archivan en una base de datos para uso futuro. Las figuras 9 y 10 muestran los pasos de aislamiento de fallas para una situación donde el usuario 140 no puede accesar ninguna página de web. La incapacidad de accesar las páginas de web puede ser intermitente de conexión a conexión. En este ejemplo, la causa raíz es una asignación de un intervalo de dirección IP recientemente abierto que no está configurado en los filtros firewall (es decir, el escenario prototipo) . El usuario 140 está conectado a la IDU 148 como se describe arriba, con relación a la figura 4. En los pasos 210 y 212, el usuario 140 y el enlace de usuario 144 interactúan para establecer una descripción del problema. El enlace de usuario 144 pregunta al usuario, en el paso 210, respecto a la naturaleza de los problemas del usuario con respecto a la página 211. El usuario 140 responde, en el paso 212, proporcionando una descripción de los problemas. Los pasos 210 y 212 pueden repetirse, con preguntas diferentes que realiza el enlace de usuario 144 hasta que el usuario 140 proporcione las respuestas adecuadas que describan los problemas/síntomas . En los pasos 214, 216, 218 y 220, se inicia una prueba de acceso de web. En el paso 214, el enlace de usuario 144 pide la prueba de acceso a la web del enlace experto 146. El enlace experto 146, en el paso 216, pide la observación hacia el interior de la red 10 respecto a la prueba de acceso a la web (figura 1) desde la IDU 148. La IDU 148 reconoce la petición de prueba al enlace experto 146. En el paso 218, el enlace experto 146 reconoce la prueba de acceso de red al enlace de usuario 144. En el paso 220, el enlace de usuario 144 proporciona una página de instrucciones 221 al navegador 142. La página de instrucciones 221, por ejemplo, instrucciones para que el usuario 140 despliegue una nueva ventana 223 y accese a un URL en la nueva ventana 223 y entre al nuevo URL en la nueva ventana. En los pasos 222, 224. 226, 228, 230, 232, 234, 236, 238 y 240 la prueba de acceso de web se realiza y analiza. En el paso 222, el usuario 140 entra al nuevo URL en la nueva ventana 223, como se le ordenó por la página de instrucciones 221 enviada desde el enlace de usuario 144 en el paso 220. En el paso 224, el navegador 142 envía una petición DNS a la IDU 148. La IDU envía, en el paso 226, una petición de búsqueda DNS a la ISP Net 22. En el paso 228, el servidor DNS de la ISP Net 22 envía una respuesta DNS a la IDU 148. La respuesta DNS contiene una dirección IP numérica que corresponde al nombre del anfitrión contenido en la petición de búsqueda DNS, de manera que el navegador 142 pueda conectarse al servidor deseado. En el paso 230, la IDU 148 envía la respuesta DNS al navegador 142. El navegador 142, en el paso 232, envía una petición HTTP utilizando la respuesta DNS recibida en el paso 230. La IDU 148 captura la URL de la petición HTTP recibida del navegador 142. Con el uso de la URL capturada, la IDU 148, en el paso 234, envía una petición HTTP a la empresa 26. Esta petición utiliza una dirección IP asignada por un servidor RADIUS (servicio de usuario de marcado por autenticación remota) . Se asume que esta dirección IP es similar a la dirección utilizada por el usuario 140 cuando tuvo el problema por el cual se está quejando el usuario 140. En el paso 236, no se recibió respuesta HTTP desde la empresa 26 o se recibió un mensaje de rechazo de un enrutador ISP Net 22. La carencia de una respuesta HTTP o la recepción de un mensaje de rechazo pudieron deberse, por ejemplo, a reajuste de tiempo fuera o reajuste de conexión. Haciendo referencia a la figura 10, en el paso 238, la IDU 148 regresa los resultados de prueba al enlace experto 146. En el paso 240, el enlace experto 146 analiza los resultados de prueba recibidos en el paso 238. El enlace de prueba 146 determina que se necesita una prueba de caracterización firewall y pide esta prueba. En los pasos 242, 244, y 246, la prueba de caracterización firewall que se determinó necesaria en el paso 240, inicia. En el paso 242, el enlace experto 146 informa al enlace de usuario 144 sobre la nueva prueba. El enlace de usuario 144, en el paso 244, envía instrucciones al navegador 142 para informar al usuario 140 sobre la nueva prueba, mediante una página 245. En el paso 246, el enlace experto 146 lanza la prueba de caracterización firewall, que la IDU 148 reconoce. La prueba firewall se efectúa y analiza en los pasos 248, 250, 252, 254, 256, 258, 260 y 262. En el paso 248, se envía un ping de Protocolo de Mensaje de Control de Internet (ICMP) hacia la ISP Net 22 y la empresa 26. La IDU 148 envía el ping ICMP , un mensaje de eco estándar como se define en la Solicitud de Comentarios 792 (RFC) hacia una máquina de destino y espera un paquete de respuesta de eco esperado, en respuesta al ping ICMP. Si no se recibe una respuesta de eco dentro de un periodo de tiempo configurable, entonces el ping ICPM transcurre y expira en el paso 250. Si el ping ICPM expira, entonces la máquina de destino no puede estar activa o ser alcanzable actualmente. Alternativamente, las máquinas firewall en la ruta que va de la IDU 148 a la máquina de destino, puede estar rechazando las transmisiones de ciertos paquetes, incluyendo los ecos ICMP y los mensajes de respuesta de eco.

En respuesta al ping ICMP enviado en el paso 248 y que expiró en el paso 250, la IDU 148 envía un ping de Protocolo de Control de Transmisión (TCP) hacia los puertos como TELNET, Protocolo de Transferencia de Archivo (File Transfer Protocol), puertos SMTP, HTTP en el paso 252. El ping TCP es similar al ping ICMP, pero se presenta en la capa de transporte de la red y ayuda a dirigir la acción del filtrado potencial de firewall . El ping TCP intenta abrir una conexión TCP hacia un puerto TCP específico en la máquina de destino utilizando un procedimiento estándar descrito en RFC 793.

Si la conexión TCP se abre exitosamente, entonces la máquina de destino está activa y puede ser alcanzada y el ping TCP cierra la conexión en una forma estándar. La conexión TCP puede rechazarse explícitamente, como se indica por la recepción de un paquete de reestablecimiento o de error que puede provenir de la máquina de destino o de una máquina en la trayectoria que está entre la IDU 148 y la máquina de destino. También, el ping TCP puede expirar en el paso 254 si no se recibe respuesta dentro de un periodo de tiempo configurable. Un ping TCP puede intentarse hacia cualquier puerto TCP. Un puerto TCP no será detenido por una firewall que está filtrando paquetes ICMP. Si una firewall está filtrando algunos paquetes TCP, entonces el intentar los pings TCP hacia diferentes puertos no sólo puede negar los efectos de firewall, sino también caracterizarlo. En el paso 256, se repiten los pasos 248 y 252 utilizando una dirección IP "golden" (dorada) . Una dirección IP dorada es una dirección IP predeterminada asignada a la IDU 148 y que se sabe es válida. Por ejemplo, el ping TCP puede ser enviado al puerto 80, que corresponde a un servidor para HTTP. En el paso 258, la empresa 26 envía una respuesta de ping TCP a la IDU 148. La IDU 148 envía, en el paso 260, los resultados de las pruebas de acceso a la web y/o firewall hacia el enlace experto 146. En el paso 262, el enlace experto 146 analiza los resultados de las pruebas. Al analizar los resultados de la pruebas, el enlace experto 146 obtiene una conclusión respecto a una causa raíz del síntoma del usuario. La causa aislada del problema del usuario es relevada hacia el usuario 140, la sesión con el usuario se cierra y se inicia la acción correctiva. En el paso 264, el enlace experto 146 envía indicaciones de la causa raíz al enlace de usuario 144 que envía información respecto a la falla y a la acción requerida, hacia el navegador 142 en el paso 266. El navegador 142 proporciona información al usuario 140, por ejemplo a través de una ventana 267 que indica que el problema está en la red y le da instrucciones al usuario 140 para que se salga de la red y se vuelva a conectar. El usuario 140 también recibe información de que recibirá un correo electrónico cuando ya se haya resuelto el problema. En el paso 268, el navegador 142 reconoce la recepción de las indicaciones del aislamiento de la falla y de la acción requerida. En el paso 265, el enlace experto 146 da instrucciones a la IDU 148 de que termina la prueba. En el paso 270, el enlace de usuario 144 instruye al enlace experto 146 para que archive los resultados de la prueba. En el paso 272, el enlace experto 146 envía un correo electrónico al NOC en la ISP Net 22 para que inicie la acción correctiva para el problema aislado. La NOC tiene la responsabilidad en la ISP Net 22 de mantener la red del ISP. Un ejemplo del correo electrónico es "Se está negando acceso a las siguientes direcciones clase C a través del Enrutador/Pasarela five.backbone.net. Problema de filtro probable con la dirección IP 110.101.23.XXX. " Las figuras 11 y 12 ilustran otro ejemplo para aislar y reportar una falla, de acuerdo a los pasos 132, 134, 136 de la figura 3, para un ejemplo del momento en que el usuario 140 no puede conectarse adecuadamente a la red 10 (figura 1) . En este ejemplo, la causa raíz o falla es que un servidor RADIUS o ÑAS está configurado inadecuadamente (por ejemplo, existe un secreto mal compartido, el ÑAS no está enlistado en una lista de acceso RADIUS o el servidor RADIO erróneo está configurado en el ÑAS) . La sesión ilustrada para aislar y reportar la falla se establece como ya se describió con relación a la figura 4. En los pasos 274, 276 y 278, se inicia una prueba para determinar la causa de los síntomas de conectividad del usuario. En los pasos 274 y 276, el enlace de usuario 144 y el usuario 140 interactúan con una página de web de diagnóstico 275 intercambiando preguntas y respuestas para establecer el síntoma del usuario al no ser capaz de conectarse (tal vez en forma intermitente) . En el paso 278, el enlace de usuario 144 pide una prueba de conectividad desde el enlace experto 146. El enlace experto 146 procede con la prueba de conectividad para aislar la causa raíz del síntoma del usuario. En el paso 280, el enlace experto 146 recupera los resultados acumulados de la sesión de mareaje del usuario a partir de la IDU 148. En el paso 282 se realiza el entrenamiento del módem, las negociaciones de protocolo y las autenticaciones que se describieron antes con relación a los pasos 130a y 130 b que se describen con respecto a la figura 4. En el paso 284, la IDU 148 pasa los resultados de la prueba de conectividad al enlace experto 146. En el paso 286, el enlace experto 146 analiza los resultados de prueba y determina que la causa probable de los síntomas del usuario 140 es una causa intermitente o una causa aislada a un solo ÑAS. En el paso 288, la IDU 148 reverifica la vista al interior de la autenticación respecto a la ISP Net 22, sin que se espere respuesta de la ISP Net 22, debido al problema de conectividad. El aislamiento de fallas se reporta al usuario 140 y se archiva para futuro uso y se reporta para posible acción correctiva. En el paso 290, el enlace experto 146 reporta la falla determinada al enlace de usuario 144, que reporta el aislamiento de la falla y la acción requerida hacia el navegador 142, en el paso 292. Por ejemplo, el usuario 140 puede recibir información mediante una página 293, respecto a que existe una falla en la red que provoca los síntomas de conectividad del usuario y que se está atendiendo la misma. La información también puede dar instrucciones al usuario para que marque más tarde o intente otro POP y que el usuario 140 reciba un correo electrónico cuando la causa del problema esté resuelta. En el paso 294, el navegador 142 reconoce la recepción de la información que indica el aislamiento de la falla y la acción requerida. En el paso 296, los resultados del aislamiento de la falla se archivan para uso futuro. El correo electrónico puede enviarse en el paso 298 desde el enlace experto 146 hacia la ISP Net 22 y específicamente el NOC en la ISP Net 22, para iniciar una posible acción correctiva. Un ejemplo de este correo electrónico es "Imposible autenticar al usuario Juan Pérez del ÑAS. CHAP del usuario verificada. RADIUS no responde, prueba de rutina en cola. Probable problema de conexión ÑAS a RADIUS." En la etapa 300, el enlace experto 146 adiciona una prueba de rutina ÑAS a una cola de rutina. Una prueba de rutina incluye una o más peticiones de prueba manejadas como grupo. Aquí, una prueba de conectividad de rutina incluye peticiones de prueba de conectividad individual para cada número ÑAS posible que pudiera provocar el" problema de conectividad. Una cola de enrutamiento proporciona almacenaje para una lista de pruebas de rutina pendientes y activas que se conserva en cierto orden dependiendo, por ejemplo, del tiempo o prioridad de la ejecución secuencial. Algunas pruebas de rutina se ponen en cola (como en el paso 300) como resultado de una secuencia explícita de resolución de problemas. Otras pruebas de rutina se ponen en cola periódicamente para la prueba proactiva de la funcionalidad de la red y el análisis de la causa raíz, incluso si no se han reportado síntomas. Cuando todas las peticiones de prueba de una prueba de rutina se han ejecutado, la prueba de rutina se considera completa y se retira de la cola. El usuario 140 es capaz de seleccionar entre recibir una notificación por correo electrónico cuando se haya completado la prueba de rutina o indicar también si el usuario 140 estuvo satisfecho con la sesión de aislamiento de falla. Como se muestra en la figura 12, se realiza una rutina ÑAS. La rutina adecuada se selecciona de la cola de rutina en el paso 302. En el paso 304, el enlace experto 146 establece una sesión con la IDU 148 para realizar la prueba de conectividad de rutina en una ÑAS. En el paso 306, el enlace experto 146 pide una prueba de conectividad de rutina (marcación) para la ÑAS seleccionada y la IDU 148 reconoce, en el paso 308, que los recursos están disponibles para la prueba de rutina solicitada. La IDU 148 marca la ÑAS seleccionada en el paso 310, para iniciar la prueba de conectividad de rutina para la ÑAS seleccionada. En el paso 312, se presenta el entrenamiento del módem entre la IDU 148 y la ISP Net 22 para establecer el protocolo adecuado para la comunicación entre la IDU 148 y la ISP Net 22. Se presentan varios intercambios para la negociación PPP y el análisis. La autenticación y el análisis, posiblemente utilizando información capturada previamente, también se realiza. La negociación y el análisis IPCP también se efectúan y se asigna una dirección/netmask IP. En el paso 314, la IDU envía una petición DNS para consultar un nombre de anfitrión estándar, por ejemplo, www.diag.com. En el paso 316, la ISP Net 22 envía una respuesta DNS a la IDU 148 que corresponde a la petición DNS recibida de la IDU 148. Al usar la respuesta DNS recibida, la IDU 148 envía, en el paso 318, una petición HTTP a la empresa 26 para recuperar una página de diagnóstico estándar. En el paso 320, la empresa 26 envía una respuesta HTTP a la IDU 148. La IDU 148 cierra la sesión con la ÑAS en el paso 322 y reporta los resultados de prueba al enlace experto 146 en el paso 324. Estos resultados reportados al enlace experto 146 incluyen, por ejemplo, la métrica del desempeño de la ÑAS, la negociación PPP del entrenamiento del módem, la autenticación y la negociación IPCP efectuadas. En el paso 326, el enlace experto 146 selecciona la siguiente ÑAS o un puerto que va a ser probado en su conectividad. Se repite la rutina de conectividad para el nuevo puerto o ÑAS seleccionado. Para por lo menos uno de los servidores ÑAS probados respecto a la conectividad, la IDU 148 describe, en este ejemplo, que la autenticación y el análisis utilizando la información capturada son fallidos. Esta información se reporta de nuevo al enlace experto 146 en el paso 324. Estos resultados pueden enviarse al usuario 140 y/o a cualquier otra entidad para iniciar una acción correctiva adecuada. El enlace experto 146 analiza todos los resultados de todas las pruebas ÑAS y concluye que existe una mala configuración RADIUS para un ÑAS. El enlace experto 146 envía un despacho al NOC en la ISP Net 22 para iniciar la acción correctiva. El enlace experto 146 envía notificación al usuario 140 y los resultados de enrutado son inscritos en una base de datos para uso futuro. Las figuras 13 a 15 ilustran los pasos para resolver los problemas de un usuario en accesar a una URL particular (en este caso www2.webbank.com) a través del aislamiento de la causa del problema y del reporte y archivado de los resultados de aislamiento. En este ejemplo, el usuario 140 no puede accesar una URL particular, posiblemente en forma intermitente, y la causa raíz de este problema es que el servidor de web está utilizando la redirección para un balanceo de cargas y una de las máquinas de balanceo de cargas no está respondiendo. La figura 13 ilustra los pasos para iniciar una sesión para resolver un problema encontrado por el usuario 140. El paso 124 y el paso 126 de la figura 13 son los mismos que los pasos con número idéntico que se describen anteriormente para la figura 4, excepto que en la figura 13 el problema es la incapacidad de accesar a una URL particular. En los pasos 328 y 330 el usuario 140 lanza el navegador 142 y accesa una URL deseada de acuerdo a las instrucciones del recepcionista 105, respectivamente, como ya se describió con relación a los pasos 130c y 130d (figura 4) . En el paso 332, el navegador 142 envía una petición DNS a la ISP Net 22 que responde en el paso 334 con una dirección IP enviada al navegador 142. En el paso 336, el navegador 142 envía una petición HTTP a la ISP Net 22 y recibe una respuesta HTTP correspondiente desde la ISP Net 22 en el paso 338. Se le presenta al usuario una página web de diagnóstico 339, solicitándole que suministre información para describir el problema de usuario. Haciendo referencia a la figura 14, se inicia una prueba de web para aislar la causa raíz del problema del usuario consistente en accesar a una URL particular. En el paso 340 y en el paso 342 el usuario 140 y el enlace de usuario 144 interactúan para describir el problema que se le presentó al usuario 140. En este ejemplo, el usuario 140 indica que existe un problema en la web al accesar un URL particular. En el paso 344, el enlace de usuario 144 pregunta al usuario 140, a través de la página web de diagnóstico 339, cuál es la URL que presenta el problema y el usuario 140 suministra la URL, en este caso www2.webbank.com, en el paso 346 mediante la página de diagnóstico 339. En el paso 348, el enlace de usuario 144 pide una prueba de web desde el enlace experto 146. En respuesta a la recepción de la petición de una prueba de web desde el enlace de usuario 144, el enlace experto 146 inicia una prueba de web. En el paso 350, el enlace experto 146 se comunica con la IDU 148 para lanzar la prueba de web. La IDU 148 reconoce, en el paso 356, la petición de prueba de red. El enlace experto 146 envía el reconocimiento desde la IDU 148 hacia el enlace de usuario 144 en el paso 354. En el paso 356, el enlace de usuario 144 envía la información relativa a la prueba de web hacia el navegador 142, para informar al usuario 140 que la prueba se está llevando a cabo mediante una página 357. La IDU 148 coordina la ejecución de la prueba de web. En el paso 358, la IDU 148 envía una petición DNS a la ISP Net 22 que responde en el paso 360 con una respuesta DNS. En este ejemplo, la respuesta DNS indica que la petición DNS enviada en el paso 358 fue una petición DNS aceptable. En el paso 362, la IDU 148 envía una petición HTTP idéntica a la petición enviada por el usuario 140, con la cual el usuario 140 tuvo el problema cuya causa se está aislando. Esta petición es enviada a la empresa 26 y la empresa 26 responde enviando una redirección HTTP hacia la IDU 148 en el paso 364. En el paso 366, la IDU 148 envía otra petición DNS hacia la ISP Net 22. La ISP Net 22 responde en el paso 368 enviando una respuesta DNS a la IDU 148. La petición DNS enviada en el paso 366 y respondida en el paso 368, corresponde al nombre del servidor en la redirección HTTP recibida por la IDU 148 en el paso 364. En el paso 370, la IDU 148 envía una petición HTTP a la máquina redirigida que corresponde a la respuesta de la redirección HTTP recibida en el paso 364. En este ejemplo, la DNS de la máquina redirigida es www2.webbank.com. En el paso 372, la IDU 148 recibe una respuesta HTTP, una página web real, proveniente de la empresa 26. Los pasos 363, 364, 366, 368, 370 y 372 se repiten para identificar más redirecciones si todas no son posibles para la URL que produce el problema al usuario 140. Por ejemplo, estos pasos pueden repetirse hasta que se exceda una cuenta máxima, o hasta que la misma URL redirigida sea observada un número predeterminado de veces, o cuando los pasos se repitan cierto número de veces, por ejemplo, tres. Haciendo referencia a la figura 15, eventualmente la petición enviada en el paso 370 dará por resultado una expiración de tiempo en la conexión TCP, de manera que no hay respuesta HTTP que provenga del anfitrión en la empresa 22. En el paso 374, los resultados de la prueba de web se envían de la IDU 148 al enlace experto 146 para su análisis en el paso 376. En este ejemplo, el enlace experto 146 concluye del análisis del paso 376 que la causa raíz del problema del usuario no está clara y que la IDU 148 debe efectuar una prueba de conectividad. En el paso 378, el enlace experto 146 envía la conclusión del paso 376 al enlace de usuario 144, que a su vez transmite esta información al navegador 142 en el paso 380. El navegador 142 puede entonces informar o continuar informando al usuario 140 que la prueba se está llevando a cabo mediante la página 357. El enlace experto 146 inicia la prueba de conectividad que el enlace experto 146 determinó, en el paso 376, se debe llevar a cabo. En el paso 382 el enlace experto 146 da instrucciones a la IDU 148 para lanzar la prueba de conectividad. La IDU 148 reconoce la prueba de conectividad solicitada por el enlace experto 146 y en el paso 384 envía un ping ICMP al anfitrión de redirección fallida. En el paso 386, la empresa 26 envía a la IDU 148 una respuesta ping que indica que el anfitrión de la redirección está presente. La IDU 148 recibe la respuesta ping y en el paso 388 envía varias pings TCP a varios puertos comunes (por ejemplo, TELNET, protocolo tolerante a fallas, SMTP, HTTP) . En el paso 390, la empresa 26 envía una respuesta TCP ping a la IDU 148. La respuesta TCP ping es una respuesta real para ciertos puertos, es un rechazo para otros y no representa nada para el puerto HTTP. Las asignaciones de puerto comúnmente utilizadas son 21 para el protocolo tolerante a fallas, 25 para SMTP, 23 para TELNET y 80 para HTTP. En el paso 392, los resultados de la prueba de conectividad son transportados de la IDU 148 al enlace experto 146 para análisis en el paso 394. El enlace experto 146 analiza los resultados de prueba y transporta las conclusiones del análisis al enlace de usuario 144 en el paso 396. En el paso 398, el enlace de usuario 144 envía información respecto al aislamiento de fallas y cualquier acción requerida, hacia el navegador 142. El navegador 142 suministra información al usuario 140 respecto al aislamiento de fallas y a la acción requerida. Por ejemplo, una ventana o página 399 puede desplegarse al usuario 140 donde se indique el sitio web del usuario 140 está intentando accesar, tiene un problema intermitente y se le da instrucciones al usuario 140 de que intente volver a cargar la página deseada, unas cuantas veces. La información suministrada al usuario 140 también puede indicar que el proceso HTTP no está corriendo en un servidor anfitrión redireccionado . El navegador 142 reconoce la recepción del aislamiento de la falla y la información de la acción requerida en el paso 400. En el paso 402, el enlace de usuario 144 envía los resultados de los pasos anteriores al enlace experto 146 para archivarlos. En el paso 404, el enlace experto se comunica con la IDU 148 para terminar la prueba de aislamiento de fallas. En este ejemplo, la causa raíz queda fuera de la ISP Net 22 y por lo tanto no se transmite petición de servicio por la IDU 148. Esta petición de acción correctiva puede ser enviada por la IDU 148, si se desea, por ejemplo si la entidad que realizará la acción correctiva estuviera bajo el control común de la IDU 148. La figura 16, muestra una representación gráfica de una correlación entre problemas/síntomas y las causas de los síntomas. Los datos almacenados a partir de interacciones entre el usuario 140 (Figura 4) y la IDU 148 (figura 4) y los resultados de las pruebas archivadas por el enlace experto 146 (Figura 4) o datos similares que se obtienen en alguna otra forma, pueden compilarse en la gráfica 500 que se muestra. Como se muestra, los síntomas se grafican a lo largo del eje "x" de la gráfica 500, las causas de problemas/síntomas (fallas) se grafican a lo largo del eje "y" y los costos asociados con las combinaciones de los síntomas y causas se grafican en el eje " z" . Los síntomas elegidos pueden variar y pueden depender del tipo de trabajo, los tipos de síntomas comunes en la red y/o los síntomas que preocupan a la entidad productora de la gráfica 500. Los síntomas ejemplificativos se muestran como correo electrónico, web, comercio electrónico (Ecomm) . Otros síntomas posibles incluyen el no poder enviar correo electrónico, no poder recibir correo electrónico, acceso demasiado lento, no poder conectarse, no poder conectarse al sitio web, desconexiones repetidas y no poder correr el navegador. La elección de las causas graficadas puede depender de muchos factores. Por ejemplo, las causas elegidas pueden depender del tipo de red y equipo que se utilice en la red, de qué causas se diagnostican con más frecuencia, qué causas cuestan más en su reparación/arreglo, y/o qué causas son de preocupación para la entidad que realiza la gráfica 500 (es decir, las causas por las cuales la entidad graficadora tiene una responsabilidad/control que arreglar) . Las causas ejemplificativas mostradas son el usuario, la PC y al DNS. Otras posibles causas incluyen la configuración de la PC, el módem, el no aislamiento (entre el bucle o ciclo local, la central telefónica y el troncal), ÑAS, enrutador ISP, servidor ISP (DNS, RADIUS, DHCP, correo electrónico) , enrutador de internet y servidor de internet . El costo de las combinaciones de los síntomas y las causas puede incluir más que solamente el costo de la reparación de piezas y mano de obra. Por ejemplo, este costo puede incluir costos incidentales como por ejemplo el asignado al tiempo de paro, que puede producir pérdidas al negocio y la frustración del cliente que puede conducir a pérdida de tiempo. Los costos pueden estimarse con relación a qué tanto negocio potencial se pierde debido a periodos de inactividad y frecuencia de fallas. Estos costos pueden por lo tanto deberse, por ejemplo, a grandes costos de reparación tanto en piezas como en mano de obra, costos incidentales altos y/o alta frecuencia de fallas, incluso si los costos individuales de reparación y/o costos incidentales asociados son bajos. En cada intersección de un síntoma y una causa existe una indicación del costo de esta combinación, que aquí es una barra vertical con una altura proporcional a este costo. Estas barras verticales proporcionan a la gráfica 500 la apariencia de rascacielos amontonados. Por lo tanto, la gráfica 500 se denomina como "Gráfica Manhattan" . La gráfica 500 no necesita, sin embargo, utilizar barras verticales. Otras indicaciones, por ejemplo, líneas verticales o puntos que se desplazan en sentido vertical, pueden utilizarse además de las indicaciones no tridimensionales, como colores, números colocados en las intersecciones de los síntomas y causas en el plano "x-y" . Al hacer la gráfica 500, las combinaciones de las causas y síntomas que producen los costos relativamente más altos pueden identificarse fácilmente y atacarse para su mejora. Por ejemplo, la barra 502 representa el costo de los problemas de correo que resultan de las fallas en PC. La barra 504 indica el costo de los problemas de correo electrónico que se deben a fallas en la DNS. La barrar 506 indica el costo de los síntomas de comercio electrónico debido a problemas DNS. La barra 508 y la barra 510 representan los costos de los síntomas de la web que resultan de fallas en el usuario y en la PC, respectivamente. A partir de la gráfica Manhattan 500, puede observarse que las barras 502, 504 y 506 indican costos relativamente altos con respecto a otras barras. Por lo tanto, la gráfica 500 sugiere que las fallas DNS atacadas con relación a los problemas de correo electrónico y comercio electrónico, y las fallas en PC relativas a los problemas de correo electrónico, deberán ser de mayor prioridad que las fallas del usuario y de la PC con respecto a los problemas de la web. Los costos pueden reducirse, por ejemplo, reduciendo el costo de reparación por arreglo, reduciendo la frecuencia en que se presentan las fallas y/o reduciendo el tiempo de reparación de las fallas (lo que afecta tanto los costos incidentales como los costos de reparación) . Después de atacar estas combinaciones causa/síntoma de alto costo a fin de reducir el costo de la combinación, la gráfica 500 puede volverse a elaborar como se indica por las barras punteadas 512, 514 y 516. Las barras 512, 514 y 516 indican que el costo de las combinaciones correo electrónico-PC, correo electrónico-DNS y comercio electrónico-DNS han disminuido todas. Al comparar la gráfica 500 con las gráficas de las combinaciones síntoma-causa indicadas antes y después de que se ha atacado el problema para su mejora, la reducción en los problemas de red y los costos podrán apreciarse fácilmente . Otras modalidades quedan dentro del alcance de las reivindicaciones anexas. Por ejemplo, las IDU 94 y 96 se describieron en términos de instrucciones de software para que el hardware desarrolle operaciones. Debido a la naturaleza del software, la funcionalidad del software puede lograrse utilizando el hardware, el firmware, el cableado duro o la combinación de éstos. También, las funciones de los análisis desarrolladas por el controlador central 98 pueden efectuarse en una o más de las IDU 94 o 96. También, la red 10 mostrada en la Figura 1 que incluye al ciclo o bucle local 14 es únicamente ilustrativa y de ninguna manera limitativa. Diferentes tipos de redes quedan dentro del alcance de la invención y las reivindicaciones anexas, incluyendo las redes que pertenecen a redes de televisión por cable, que no incluyen un bucle o ciclo local. Por ejemplo, el bucle o ciclo local 14 en la Figura 1 puede reemplazarse por un sistema coaxial de fibra híbrida (HFC) o un sistema inalámbrico. Además, la Figura 2 muestra las conexiones de red 100 y 102 que conectan operativamente la IDU 94 y 96 al controlador central 98, como si fueran líneas. Las IDU 94 y 96 pueden conectarse operativamente al controlador 98 en una variedad de formas, por ejemplo con alambres, cables de fibra óptica o dispositivos inalámbricos.

Claims (44)

1. REIVINDICACIONES I 1. Un método que comprende : indicar a una unidad de diagnóstico de red un problema que experimenta un usuario que interactúa con la red; transferir datos entre la unidad de diagnóstico de red y el usuario y entre la unidad de diagnóstico de red y porciones de la red, que no corresponden al usuario, a fin de diagnosticar una causa del problema; y reportar al usuario una indicación de una acción correctiva para corregir la causa.
2. 2. El método según la reivindicación 1, que comprende además reportar al usuario una indicación de la causa del problema.
3. 3. El método según la reivindicación 1, en donde la indicación del problema incluye que el usuario envíe un mensaje a la unidad de diagnóstico de red, y el mensaje dará por resultado una falla al ser enviado a la red.
4. 4. El método según la reivindicación 3, en donde el diagnóstico del problema incluye adaptarse a un protocolo inadecuado del mensaje enviado por el usuario y proporcionar una indicación al usuario sobre un protocolo adecuado asociado con el mensaje.
5. 5. Un método para mejorar las operaciones de una red, el método comprende: identificar los síntomas de las fallas de la red; asociar las causas de los síntomas identificados con los síntomas; asociar los costos con las combinaciones de síntomas y causas; identificar una combinación de causa y síntoma de alto costo que tenga un costo asociado mayor a los costos asociados con otras combinaciones de las causas y síntomas; y atacar la causa en la combinación de causa y síntoma de alto costo a fin de reducir el costo asociado con la combinación de causa y síntoma de alto costo.
6. 6. El método según la reivindicación 5, que comprende además monitorear el costo de la combinación de alto costo.
7. 7. El método según la reivindicación 5, que comprende además reducir una frecuencia de ocurrencias de la causa en la combinación de causa y síntoma de alto costo.
8. 8. El método según la reivindicación 5, que comprende además reducir un costo de reparación de la causa en la combinación de causa y síntoma de alto costo.
9. 9. El método según la reivindicación 5, que comprende además reducir un tiempo de reparación de la causa en la combinación de causa y síntoma de alto costo.
10. 10. Un método para mejorar operaciones de red, el método comprende : indicar los síntomas de las fallas de la red a lo largo de un primer eje de una gráfica; indicar las causas de los síntomas a lo largo de un segundo eje de la gráfica; e indicar los costos asociados con las combinaciones de los síntomas y las causas en puntos de la gráfica asociados con combinaciones de síntomas y causas respectivas .
11. 11. El método según la reivindicación 10, que comprende además : identificar una combinación de causa y síntoma de alto costo que tenga un costo asociado superior en comparación con los costos asociados con otras combinaciones de causas y síntomas; y atacar la causa de la combinación de causas y síntomas de alto costo para obtener una reducción en el costo asociado con la combinación de causa y síntoma de alto costo.
12. 12. El método según la reivindicación 11, que comprende además : graficar repetidamente la gráfica y monitorear los costos indicados por la gráfica.
13. 13. Un sistema que se utiliza con una red de datos, el sistema comprende: una pluralidad de unidades de diagnóstico, cada una adaptada para comunicarse con la red, incluyendo a un usuario de red; un controlador central conectado operativamente a las unidades de diagnóstico, el controlador está adaptado para comunicarse con las unidades de diagnóstico y coordinar sus operaciones, a fin de dar instrucciones a las unidades de diagnóstico para que efectúen pruebas adaptadas para ayudar a aislar una falla en la red, y para analizar los resultados de prueba recibidos desde la unidad de diagnóstico a fin de intentar determinar la falla de la red.
14. 14. El sistema según la reivindicación 13, en donde las unidades de diagnóstico están distribuidas en ubicaciones por toda la red.
15. 15. El sistema según la reivindicación 13, en donde el controlador está adaptado para instruir a múltiples unidades de diagnóstico a realizar una prueba concurrente .
16. 16. El sistema según la reivindicación 13, en donde el controlador está adaptado para instruir a una unidad de diagnóstico a inyectar datos de prueba hacia la red.
17. 17. El sistema según la reivindicación 13, en donde el controlador está adaptado para instruir a una primera unidad de diagnóstico a inyectar datos de prueba hacia la red y a una segunda unidad de diagnóstico a monitorear una respuesta de red hacia los datos de prueba inyectados por la primera unidad de diagnóstico.
18. 18. El sistema según la reivindicación 13, en donde la unidad de diagnóstico está adaptada para aceptar datos que provienen de un usuario en un protocolo incompatible con un elemento de red al cual se pretende enviar los datos, para comunicarse con el elemento de red utilizando un protocolo compatible con el elemento de red y para comunicarse con el usuario utilizando un protocolo compatible con el protocolo compatible con el protocolo de lo datos del usuario.
19. 19. El sistema según la reivindicación 13, en donde el controlador está adaptado para determinar operaciones que den instrucciones a una unidad de diagnóstico para actuar con base en una información recibida de una unidad de diagnóstico.
20. 20. El sistema según la reivindicación 13, en donde el controlador está adaptado para determinar operaciones para instruir a una unidad de diagnóstico a que actúe con base en prioridades comerciales predeterminadas.
21. 21. El sistema según la reivindicación 13, en donde la unidad de diagnóstico incluye un procesador e instrucciones almacenadas que pueden ser leídas por el procesador, para dar instrucciones a las unidades de diagnóstico a que realicen operaciones en respuesta a los datos recibidos por la unidad de diagnóstico.
22. 22. El sistema según la reivindicación 13, en donde el controlador está adaptado para enviar a una unidad de diagnóstico, una indicación de la falla de la red y de la acción correctiva para eliminar la falla.
23. 23. Una unidad de diagnóstico de red que comprende : un procesador conectado en forma selectiva y operativa a primera y segunda porciones de una red de datos, la segunda porción comprende un usuario de red; y una memoria legible para el procesador, para almacenar instrucciones para producir que el procesador: reciba los primeros datos a partir de una porción específica de la primera y segunda porciones de red; determine segundos datos que correspondan a los primeros datos y que simulen los mismos en un protocolo compatible con la porción de la red que no corresponde a la porción específica; y transmita los segundos datos hacia la porción de la red que no corresponde a la porción específica.
24. 24. La unidad de diagnóstico de red según la reivindicación 23, en donde los primeros datos son recibidos desde la primera porción de la red y los segundos datos son transmitidos hacia la segunda porción de la red, las instrucciones incluyen además instrucciones para hacer que el procesador: reciba terceros datos a partir de la segunda porción de la red; determine cuartos datos que corresponden a los terceros datos y que simulan a éstos en un protocolo compatible con la primera porción de la red; y transmita los cuartos datos hacia la primera porción de la red.
25. 25. La unidad de diagnóstico según la reivindicación 23, en donde las instrucciones incluyen además instrucciones para hacer que el procesador evalúe los datos recibidos de una de las porciones de la red, a fin de determinar si hay que transmitir los datos hacía una de las porciones de la red para intentar aislar la falla en la red.
26. 26. La unidad de diagnóstico según la reivindicación 25, en donde las instrucciones incluyen además instrucciones para hacer que el procesador determine los datos que se van a transmitir a una de las porciones de la red, a fin de intentar aislar una falla en la red.
27. 27. La unidad de diagnóstico según la reivindicación 23, en donde las instrucciones incluyen además instrucciones para hacer que el procesador envíe al usuario de la red, una indicación de una falla en la red y una acción correctiva asociada con la falla.
28. 28. Un producto de programa de computadora que se utiliza con una computadora instalada en una red de comunicaciones, que incluye elementos de red, el producto de programa de computadora comprende instrucciones para hacer que una computadora : acepte datos a partir de una fuente en un protocolo de fuente inconsistente con un protocolo de elemento de red de un elemento de red seleccionado; establezca un enlace de comunicación con la red; y envíe una indicación de los datos recibidos desde la fuente hacia el elemento de red seleccionado, en un protocolo consistente con el protocolo de elemento de red.
29. 29. El producto de programa de computadora según la reivindicación 28, en donde las instrucciones para hacer que una computadora establezca un enlace de comunicación, incluyen instrucciones para hacer que una computadora negocie un protocolo compatible con la fuente y la computadora instalada en la red.
30. 30. El producto de programa de computadora según la reivindicación 28, que comprende además instrucciones para hacer que una computadora determine si el protocolo de fuente está inhibiendo la comunicación entre la fuente y el elemento de red seleccionado.
31. 31. El producto de programa de computadora según la reivindicación 28, que comprende además instrucciones para hacer que una computadora envíe una indicación a la fuente, de que el protocolo fuente está inhibiendo la comunicación entre la fuente y el elemento de red seleccionado y de la acción correctiva para corregir el protocolo fuente.
32. 32. El producto de programa de computadora según la reivindicación 28, que comprende además instrucciones para hacer que una computadora determine si existe una falla con el elemento de red que inhibe la comunicación entre la fuente y el elemento de red.
33. 33. El producto de programa de computadora según la reivindicación 32, que comprende además instrucciones para hacer que una computadora envíe una indicación a la fuente de la falla con el elemento de red y una acción correctiva asociada con la falla.
34. 34. Un producto de programa de computadora que se utiliza con una computadora instalada en una red de comunicaciones que incluye a los elementos de red, el producto de programa de computadora comprende instrucciones para hacer que una computadora: reciba los datos a partir de un usuario; inyecte datos de prueba hacia la red de comunicaciones en respuesta a los datos recibidos desde el usuario; y monitoree una respuesta de red hacia los datos de prueba .
35. 35. El producto de programa de computadora según la reivindicación 34, que comprende además instrucciones para hacer que una computadora determine si inyectar más datos de prueba hacia la red comunicación, de acuerdo a la respuesta de red monitoreada por la computadora.
36. 36. El producto de programa de computadora según la reivindicación 35, que comprende además instrucciones para hacer que una computadora determine una falla de red comunicación asociada con la respuesta.
37. 37. El producto de programa de computadora según la reivindicación 36, que comprende además instrucciones para hacer que una computadora envíe al usuario una indicación de la falla de red de comunicación y la acción correctiva asociada con la falla.
38. 38. Un sistema de diagnóstico que se utiliza en una red, el sistema comprende: una primera unidad de diagnóstico conectada a la red y capaz de inyectar los datos de prueba hacia la red; y una segunda unidad de diagnóstico conectada a la red y capaz de monitorear una respuesta a los datos de prueba y proporcionar una indicación de la respuesta monitoreada .
39. 39. El sistema de diagnóstico según la reivindicación 38, que además comprende un analizador capaz de determinar si la respuesta indica un problema en la red.
40. 40. El sistema de diagnóstico según la reivindicación 39, en donde el analizar es capaz además de determinar si deben inyectarse más datos de prueba hacia la red y proporcionar una indicación de esta determinación a una de las unidades de diagnóstico.
41. 41. El sistema de diagnóstico según la reivindicación 38, en donde el analizar comprende una porción de una de las unidades de diagnóstico.
42. 42. El sistema de diagnóstico según la reivindicación 38, en donde los datos de prueba son primeros datos de prueba y la segunda unidad de diagnóstico es capaz de inyectar los segundos datos de prueba hacia la red.
43. 43. El sistema de diagnóstico según la reivindicación 42, en donde la primera y segunda unidades de diagnóstico pueden inyectar el primero y segundo datos de prueba hacia la red, de manera que el primero y segundo datos de prueba afecten a la red, al mismo tiempo.
44. 44. El sistema de diagnóstico según la reivindicación 38, en donde la primera unidad de diagnóstico se desplaza de la segunda unidad de diagnóstico en la red.