Articulo de referencia

Fiabilidad (redes informáticas)

En redes informáticas , un protocolo fiable es un protocolo de comunicación que notifica al remitente si la entrega de datos a los destinatarios previstos se realizó correctamen...

En redes informáticas , un protocolo fiable es un protocolo de comunicación que notifica al remitente si la entrega de datos a los destinatarios previstos se realizó correctamente o no. Fiabilidad es sinónimo de garantía , término utilizado por la UIT y el Foro ATM , y da lugar a la mensajería tolerante a fallos .

Los protocolos fiables suelen generar más sobrecarga que los protocolos no fiables y, como consecuencia, funcionan más lentamente y con menor escalabilidad. Esto no suele ser un problema para los protocolos unicast , pero puede convertirse en un problema para los protocolos multicast fiables .

El Protocolo de Control de Transmisión (TCP), el principal protocolo utilizado en Internet , es un protocolo unicast fiable que proporciona a las aplicaciones la abstracción de un flujo de bytes fiable . El Protocolo Definitivo de Usuario (UDP) es un protocolo no fiable que se suele utilizar en videojuegos , transmisión de contenido multimedia o en otras situaciones donde la velocidad es crucial y se tolera cierta pérdida de datos debido a su naturaleza transitoria.

A menudo, un protocolo unicast fiable también está orientado a la conexión . Por ejemplo, TCP está orientado a la conexión, y el identificador del circuito virtual consta de direcciones IP de origen y destino y números de puerto. Sin embargo, algunos protocolos poco fiables están orientados a la conexión, como el Modo de Transferencia Asíncrona ( ATM) y Frame Relay . Además, algunos protocolos sin conexión, como IEEE 802.11 , son fiables.

Historia

Basándose en los conceptos de conmutación de paquetes propuestos por Donald Davies , el primer protocolo de comunicación en ARPANET fue un procedimiento de entrega de paquetes confiable para conectar sus hosts a través de la interfaz 1822. [ 1 ] [ 2 ] Un ordenador host simplemente organizaba los datos en el formato de paquete correcto, insertaba la dirección del ordenador host de destino y enviaba el mensaje a través de la interfaz a su Procesador de Mensajes de Interfaz (IMP) conectado. Una vez que el mensaje se entregaba al host de destino, se enviaba una confirmación al host emisor. Si la red no podía entregar el mensaje, el IMP enviaba un mensaje de error al host emisor.

Mientras tanto, los desarrolladores de CYCLADES y ALOHAnet demostraron que era posible construir una red informática eficaz sin proporcionar una transmisión de paquetes fiable. Esta lección fue posteriormente adoptada por los diseñadores de Ethernet .

Si una red no garantiza la entrega de paquetes, entonces es responsabilidad del host proporcionar confiabilidad detectando y retransmitiendo los paquetes perdidos. La experiencia posterior en ARPANET indicó que la propia red no podía detectar de forma confiable todos los fallos de entrega de paquetes, lo que, en cualquier caso, trasladó la responsabilidad de la detección de errores al host emisor. Esto condujo al desarrollo del principio de extremo a extremo , uno de los principios de diseño fundamentales de Internet .

Propiedades de confiabilidad

Un servicio fiable es aquel que notifica al usuario si la entrega falla, mientras que uno no fiable no lo notifica. Por ejemplo, el Protocolo de Internet (IP) ofrece un servicio no fiable. En cambio, el Protocolo de Control de Transmisión (TCP) y el IP ofrecen un servicio fiable, mientras que el Protocolo de Datagramas de Usuario (UDP) y el IP ofrecen uno no fiable.

En el contexto de los protocolos distribuidos, las propiedades de confiabilidad especifican las garantías que el protocolo proporciona con respecto a la entrega de mensajes al destinatario o destinatarios previstos.

Un ejemplo de propiedad de confiabilidad para un protocolo unicast es "al menos una vez", es decir, se garantiza que al menos una copia del mensaje se entregará al destinatario.

Las propiedades de confiabilidad para protocolos de multidifusión pueden expresarse para cada destinatario individualmente (propiedades de confiabilidad simples) o bien, pueden relacionarse con la entrega o el orden de entrega entre los distintos destinatarios (propiedades de confiabilidad fuertes). En el contexto de los protocolos de multidifusión, las propiedades de confiabilidad fuertes expresan las garantías que el protocolo ofrece con respecto a la entrega de mensajes a los diferentes destinatarios.

Un ejemplo de una propiedad de alta fiabilidad es la recuperación de la última copia , lo que significa que, siempre que al menos una copia de un mensaje permanezca disponible en cualquiera de los destinatarios, todos los demás destinatarios que no fallen también recibirán una copia. Las propiedades de alta fiabilidad como esta suelen requerir que los mensajes se retransmitan o reenvíen entre los destinatarios.

Un ejemplo de una propiedad de confiabilidad más fuerte que la recuperación de la última copia es la atomicidad . Esta propiedad establece que si se ha entregado al menos una copia de un mensaje a un destinatario, todos los demás destinatarios eventualmente recibirán una copia del mensaje. En otras palabras, cada mensaje siempre se entrega a todos o a ninguno de los destinatarios.

Una de las propiedades de fiabilidad fuerte más complejas es la sincronía virtual .

La mensajería confiable es el concepto de transmisión de mensajes a través de una infraestructura no confiable, al tiempo que se pueden hacer ciertas garantías sobre la transmisión exitosa de los mensajes. [ 3 ] Por ejemplo, que si el mensaje se entrega, se entrega como máximo una vez, o que todos los mensajes entregados con éxito llegan en un orden determinado.

La entrega fiable se puede contrastar con la entrega con el mejor esfuerzo posible , donde no hay garantía de que los mensajes se entreguen rápidamente, en orden o en absoluto.

Implementaciones

Un protocolo de entrega fiable puede construirse sobre un protocolo poco fiable. Un ejemplo muy común es la superposición del Protocolo de Control de Transmisión sobre el Protocolo de Internet , una combinación conocida como TCP/IP .

Los sistemas de comunicación de grupo (GCS), como IS-IS , Appia Framework , JGroups o QuickSilver Scalable Multicast , ofrecen sólidas propiedades de confiabilidad . El marco de propiedades QuickSilver es una plataforma flexible que permite expresar estas sólidas propiedades de confiabilidad de forma puramente declarativa, mediante un lenguaje sencillo basado en reglas, y traducirlas automáticamente a un protocolo jerárquico.

Un protocolo que implementa mensajería confiable es WS-ReliableMessaging , que maneja la entrega confiable de mensajes SOAP . [ 4 ]

La función de coordinación específica del servicio ATM proporciona una entrega transparente y garantizada con AAL5 . [ 5 ] [ 6 ] [ 7 ]

El estándar IEEE 802.11 busca brindar un servicio confiable para todo el tráfico. La estación emisora ​​reenviará una trama si no recibe una trama ACK dentro de un período de tiempo predeterminado.

Sistemas en tiempo real

Sin embargo, existe un problema con la definición de confiabilidad como "entrega o notificación de falla" en la computación en tiempo real . En estos sistemas, la falla en la entrega de datos en tiempo real afectará negativamente el rendimiento de los sistemas, y algunos sistemas, por ejemplo, los de seguridad crítica , los que involucran seguridad y algunos sistemas de misión crítica seguros , deben demostrar que funcionan a un nivel mínimo especificado. Esto, a su vez, requiere que se cumpla una confiabilidad mínima especificada para la entrega de los datos críticos. Por lo tanto, en estos casos, solo importa la entrega; la notificación de la falla en la entrega sí mitiga la falla. En los sistemas de tiempo real estricto , todos los datos deben entregarse antes de la fecha límite o se considera una falla del sistema. En los sistemas de tiempo real firme , los datos tardíos siguen siendo inútiles, pero el sistema puede tolerar cierta cantidad de datos tardíos o faltantes. [ 8 ] [ 9 ]

Existen diversos protocolos capaces de satisfacer los requisitos en tiempo real para una entrega fiable y puntual:

MIL-STD-1553B y STANAG 3910 son ejemplos bien conocidos de protocolos puntuales y fiables para buses de datos de aviónica . MIL-1553 utiliza un medio compartido de 1 Mbit/s para la transmisión de datos y el control de estas transmisiones, y se utiliza ampliamente en sistemas de aviónica militar federados. [ 10 ] Utiliza un controlador de bus (BC) para ordenar a los terminales remotos (RT) conectados que reciban o transmitan estos datos. El BC puede, por lo tanto, asegurar que no habrá congestión y que las transferencias siempre serán puntuales. El protocolo MIL-1553 también permite reintentos automáticos que pueden asegurar una entrega puntual y aumentar la fiabilidad por encima de la de la capa física. STANAG 3910, también conocido como EFABus en su uso en el Eurofighter Typhoon , es, en efecto, una versión de MIL-1553 aumentada con un bus de medios compartidos de 20 Mbit/s para transferencias de datos, conservando el bus de medios compartidos de 1 Mbit/s para fines de control.

El Modo de Transferencia Asíncrona (ATM), el Ethernet conmutado dúplex completo para aviónica (AFDX) y el Ethernet activado por tiempo (TTEthernet) son ejemplos de protocolos de red de conmutación de paquetes que garantizan la puntualidad y la fiabilidad de las transferencias de datos. AFDX y TTEthernet también se basan en el estándar IEEE 802.3 Ethernet, aunque no son totalmente compatibles con él.

ATM utiliza canales virtuales (VC) orientados a la conexión, que cuentan con rutas totalmente deterministas a través de la red, y control de uso y parámetros de red (UPC/NPC), implementados dentro de la red, para limitar el tráfico en cada VC de forma independiente. Esto permite calcular el uso de los recursos compartidos (búferes de conmutación) de la red a partir de los parámetros del tráfico que se transportará, es decir, durante el diseño del sistema. El hecho de que estos cálculos se implementen en la red garantiza su validez incluso cuando otros usuarios de la red se comportan de forma inesperada, por ejemplo, transmitiendo más datos de los previstos. Los usos calculados se pueden comparar con la capacidad de estos recursos para demostrar que, dadas las restricciones en las rutas y los anchos de banda de estas conexiones, el recurso utilizado para estas transferencias nunca se sobrecargará. Por lo tanto, estas transferencias nunca se verán afectadas por la congestión y no se producirán pérdidas debido a este efecto. A partir de los usos máximos previstos de los búferes de conmutación, también se puede predecir el retardo máximo a través de la red. Sin embargo, para que se demuestre la fiabilidad y la puntualidad, y para que las pruebas sean tolerantes a fallos y acciones maliciosas por parte de los equipos conectados a la red, los cálculos de estos usos de recursos no pueden basarse en parámetros que no sean aplicados activamente por la red; es decir, no pueden basarse en lo que se espera que hagan las fuentes del tráfico ni en análisis estadísticos de las características del tráfico (véase cálculo de redes ). [ 11 ]

AFDX utiliza asignación de ancho de banda en el dominio de la frecuencia y control de tráfico , lo que permite limitar el tráfico en cada enlace virtual para predecir los requisitos de recursos compartidos y prevenir la congestión , de modo que se pueda demostrar que no afecta a los datos críticos. [ 12 ] Sin embargo, las técnicas para predecir los requisitos de recursos y demostrar que se previene la congestión no forman parte del estándar AFDX.

TTEthernet proporciona la menor latencia posible en la transferencia de datos a través de la red mediante el uso de métodos de control en el dominio del tiempo: cada transferencia activada por tiempo se programa en un momento específico para que se controle la contención por recursos compartidos y, por lo tanto, se elimine la posibilidad de congestión. Los conmutadores en la red imponen esta sincronización para proporcionar tolerancia a fallas en, y acciones maliciosas por parte de, otros equipos conectados. Sin embargo, "los relojes locales sincronizados son el requisito previo fundamental para la comunicación activada por tiempo". [ 13 ] Esto se debe a que las fuentes de datos críticos tendrán que tener la misma visión del tiempo que el conmutador, para que puedan transmitir en el momento correcto y el conmutador lo vea como correcto. Esto también requiere que la secuencia con la que se programa una transferencia crítica debe ser predecible tanto para la fuente como para el conmutador. Esto, a su vez, limitará el programa de transmisión a uno altamente determinista, por ejemplo, el ejecutivo cíclico .

Sin embargo, una baja latencia en la transferencia de datos a través del bus o la red no se traduce necesariamente en bajos retrasos de transporte entre los procesos de la aplicación que originan y reciben estos datos. Esto es especialmente cierto cuando las transferencias a través del bus o la red se programan cíclicamente (como suele ocurrir con MIL-STD-1553B y STANAG 3910, y necesariamente con AFDX y TTEthernet), pero los procesos de la aplicación no están sincronizados con dicha programación.

Tanto AFDX como TTEthernet requieren funciones adicionales de las interfaces, como el control de la brecha de asignación de ancho de banda de AFDX y la sincronización precisa de las fuentes de datos activados por tiempo de TTEthernet, lo que dificulta el uso de interfaces Ethernet estándar. Actualmente se investigan otros métodos para controlar el tráfico de la red que permitan el uso de dichas interfaces de red estándar IEEE 802.3. [ 14 ]

Véase también

Referencias

  1. Gillies, J.; Cailliau, R. (2000). Cómo nació la web: La historia de la World Wide Web . Oxford University Press . págs. 23–25 . ISBN  0192862073.
  2. Roberts, Dr. Lawrence G. (noviembre de 1978). "La evolución de la conmutación de paquetes" (PDF) . Artículo invitado del IEEE . Archivado del original (PDF) el 31 de diciembre de 2018. Recuperado el 10 de septiembre de 2017. En casi todos los aspectos , la propuesta original de Davies, desarrollada a finales de 1965, era similar a las redes que se están construyendo actualmente.
  3. Documento del W3C sobre mensajería fiable
  4. "Especificación WS-ReliableMessaging (PDF)" (PDF) . Archivado del original (PDF) el 21 de mayo de 2009. Consultado el 29 de octubre de 2019 .
  5. Young-ki Hwang, et al., Función de coordinación específica del servicio para una entrega transparente y garantizada con AAL5 (SSCF-TADAS) , Actas de la Conferencia de Comunicaciones Militares, 1999. MILCOM 1999, vol. 2, páginas 878–882. ​​doi : 10.1109/MILCOM.1999.821329
  6. ATM Forum, Interfaz de red de usuario (UNI), v. 3.1, ISBN 0-13-393828-X, Prentice Hall PTR, 1995.
  7. ITU-T, Especificación de la capa de adaptación ATM B-ISDN: AAL tipo 5 , Recomendación I.363.5, Unión Internacional de Telecomunicaciones, 1998.
  8. S., Schneider, G., Pardo-Castellote, M., Hamilton. "¿Puede Ethernet ser en tiempo real?", Real-Time Innovations, Inc., 2001
  9. Dan Rubenstein, Jim Kurose, Don Towsley, "Multidifusión confiable en tiempo real mediante corrección proactiva de errores hacia adelante", NOSSDAV '98
  10. Mats Ekman, Arquitecturas de aviónica: tendencias y desafíos (PDF) , KTH, archivado del original (PDF) el 3 de febrero de 2015. Cada sistema tiene sus propios ordenadores que realizan sus propias funciones.
  11. Kim, YJ; Chang, SC; Un, CK; Shin, BC (marzo de 1996). "Algoritmo UPC/NPC para QoS garantizada en redes ATM". Computer Communications . 19 (3). Ámsterdam, Países Bajos: Elsevier Science Publishers : 216–225 . doi : 10.1016/0140-3664(96)01063-8 .
  12. "Tutorial AFDX® / ARINC 664" (PDF) . TechSAT. 29 de agosto de 2008. Archivado del original (PDF) el 18 de junio de 2015. Consultado el 3 de febrero de 2015 .
  13. Wilfried Steiner y Bruno Dutertre, " Verificación formal basada en SMT de una función de sincronización TTEthernet ", S. Kowalewski y M. Roveri (Eds.), FMICS 2010, LNCS 6371, pp. 148–163, 2010.
  14. DW Charlton; et al. (2013), "Una red Gigabit Ethernet para aviónica", Conferencia sobre aviónica, fibra óptica y fotónica (AVFOP) , IEEE, pp. 17–18 , doi : 10.1109/AVFOP.2013.6661601 , ISBN   978-1-4244-7348-9, S2CID 3162009