por Kostas
Pentikousis
Traducido por Paulo N.
Lama
El diseño de los sistemas de red se han desarrollado significativamente durante los ultimos 20 años. Los ingenieros han abandonado el monolítico, "spaguetti-like ", esos programas todo-en-uno con montones de capas de pilas de protocoloy de los sistemas de comunicación orientados al objeto. Una arquitectura basada en estas pilas permite que los diseñadores de redes descompongan las funciones en múltiples capas abstractas [ 2 ]. Cada capa contiene códigos que implementan un protocolo o conjunto de reglas y convenciones para la comunicación entre múltiples computadores. Para más detalles, vea la columna del artículo publicado en el mes de Julio del 2000, " IP el Protocolo de Internet ".
Cada nivel o capa en un pila tiene una interface pública la cual proporciona servicios a la capa directamente arriba de ella. Además, cada capa también contiene una interfaz de igual a igual que define cómo los datos se intercambian entre las capas idénticas en dos computadores principales. Los detalles subyacentes acerca de cómo se ponen en ejecución estos servicios continuan siendo privados y ocultados. Encapsulando los detalles de la implementación, los cambios se pueden realizar a una sola capa sin afectar otras capas de la pila. Si el interfaz público de la capa no cambia, la compatibilidad previa está garantizada. Además, el diseño modular de la pila de protocolo promueve la reutilización del código, que es más fácil de desarrollarse y de mantenerse.
Sin embargo, un diseño arquitectónico por capas requiere de significativas planificaciones con anticipacion. Determinar cómo asignar las funciones dentro de una pila de protocolo no es siempre directa. Saltzer y otros (1984) escribieron, "en un sistema que incluya comunicaciones, uno traza el límite modular alrededor del subsistema de comunicación y define una interface firme entre éste y el resto del sistema. Al hacerlo así, se torna evidente que haya una lista de funciones, cada uno de las cuales deben ser implementadas de varias maneras: por el subsistema de comunicación, por su cliente, como joint-venture o empresa de riesgo compartido, o quizás mejor, cada uno debe hacer su propia versión " [ 4 ].
Por ejemplo, la detección de error se puede realizar en cualquier la trasmisión de datos, el transporte, o la capa de aplicación. Los errores pueden ser descubiertos más rápidamente si la detección de los errores se realizan en un nivel inferior (ej, el nivel de trasmisión de datos). Por otra parte, uno puede reducir el riesgo en el proceso de los paquetes de envío de información en el ordenador principal del otro extremo de la red, poniendo la detección del error en este nivel de las redes. No obstante, este acercamiento puede no ser confiable porque los componentes defectuosos de la red pueden introducir los errores que los ordenadores principal del otro extremo no pueden detectar. Alternativamente, se pueden poner detectores de error en las múltiples capas. Sin embargo, vale la redundancia de que una pobre planificación puede cargar innecesariamente el sistema.
El argumento end-to-end o “de punta a cabo” sugiere que ciertas funciones se puedan poner en ejecución solamente en los niveles más altos de la pila del protocolo. Saltzer y otros (1984) fueron los primeros en definir explícitamente este concepto de diseño:
" (ciertas funciones) pueden ser correctamente implementados en su totalidad, solamente con el conocimiento y la ayuda de la aplicación que está en los puntos finales del sistema de comunicación. Por lo tanto, proporcionar la función cuestionada como una característica per-se del sistema de comunicación, no es posible (a veces una versión incompleta de la función proporcionada por el sistema de comunicación puede ser mas útil para mejorar el funcionamiento.) [ 4 ].
Para clarificar los comentarios anteriores, déjeme repasar abreviadamente uno de los ejemplos famosos [ 4 ] usados por los abogados del argumento “end-to-end” (de punta a cabo). El ejemplo ocurrió en una red interna en el MIT que consistió en varias redes locales conectadas por entradas de acceso o gateways. La red utilizó una sumatoria para la comprobación de los saltos en los paquetes de información enviados a partir de un gateway al siguiente. Se asumió que la principal fuente de errores ocurrió durante la transmisión entre los saltos. Los programadores de aplicación asumieron que la red proporcionó a una transmisión confiable, y no realizaron ningún chequeo de error adicional. Desafortunadamente, los datos fueron dejados desprotegidos mientras que siendo guardados en los gateways. Saltzer y otros (1984) escriben: "un computador del gateway desarrolló un error transitorio en el cual mientras copiaban los datos de entrada de información al buffer de salida, un par de bytes fueron intercambiados, con una frecuencia de cerca de un intercambio en cada millón de bytes. Durante este periodo de tiempo muchos de las fuentes de archivos del sistema operativo fueron transferidos en varias ocasiones a través del gateway defectuoso. Algunos de estos fuente de archivos fueron corrompidos por los intercambios de bytes, y forzaron a sus propietarios un último intento para chequear del error de punta a cabo, de un extremo a otro: es decir, la comparación y corrección manual con los viejos listados." En este ejemplo, el chequear errores a nivel de la red no era claramente suficiente. Una solución total de punta a cabo o end-to-end más comprensiva era necesaria para garantizar un canal de comunicaciones sin errores.
Los niveles de los protocolos de transporte tales como el UDP y los TCP son ejemplos de protocolos del tipo end-to-end. Es decir, se ponen en ejecución en los ordenadores principales de ambos extremos y no dentro de la infraestructura de la red. Ambos protocolos ofrecen las funciones de la multiplexación, que permite a más de un proceso para utilizar la red simultáneamente [ 2 ]. Sin embargo, el UDP y los TCP difieren en la clase de servicio que ellos ofrecen a los protocolos del nivel de aplicaciones.
El UDP ofrece un servicio de datagrama sin conexión, no fiable. Se asegura de que los paquetes corrompidos no sean entregados al nivel de aplicación, pero no hace ningún esfuerzo de solicitar una retransmisión de un segmento corrompido o ausente. Asume que la capa de aplicación proporcionará a la corrección de error si es necesario.
El TCP, por otra parte, ofrece un confiable servicio a traves del flujo de bytes en una conexión . El TCP asume que la infraestructura subyacente de la red es no fiable y se podría perder o duplicar segmentos durante su transmisión. El TCP hace cada esfuerzo de asegurarse de que el protocolo de aplicación recibe sus datos en orden, sin duplicados, exactamente como fue enviado. Además, el TCP utiliza control de flujo y control de congestión. El control de flujo se asegura de que el remitente no envíe demasiados datos para no sobrecargar el buffer o almacenador intermedio del receptor. El control de congestión asegura de que el remitente no transmita más datos en la red que él pueda manejar.
Desafortunadamente, las versiones tempranas del TCP sufrieron desperfectos por códigos ineficientes. Muchos desarrolladores de software optaron por dejar de utilizar el UDP y escribir sus propias operaciones de confiabilidad en el nivel de las aplicaciones. Estos arreglos fueron posible gracias a la arquitetura o configuracion por capas de la pila del IP (Internet Protocol). La mayoría de los conocidos protocolos del nivel de aplicaciones, ya utilizan ahora el TCP para transferir datos. tales como el protocolo simple de transferencia del correo electrónico (SMTP, Simple Mail Transfer Protocol), el protocolo de transferencia de hypertext (HTTP, Hypertext Transfer Protocol), y el protocolo de transferencia de archivos (FTP, File Transfer Protocol). Además, las aplicaciones que utilizaron una vez el UDP también utilizan TCP (ej, NFS) [ 5 ].
Debido a que los desarrolladores influyen en las funciones existentes proporcionadas por TCP (o el UDP), las aplicaciones pueden ser desarrolladas de manera más rápidas y más simple. Por ejemplo, el HTTP seguía siendo un protocolo simple, ligero porque fue construido por encima del TCP. Es interesante observar que el HTTP 1,0 no utilizó conexiones del TCP de una manera eficiente. En su lugar, los diseñadores del HTTP decidieron presentar una versión mejorada rapidamente, para luego perfeccionar su funcionamiento en la versión siguiente. La flexibilidad de una configuración por capas o niveles permite tales ciclos de desarrollo. Reed (2000) escribe al respecto que "la infraestructura del E-mail y de la Web que impregna la economía mundial no habría sido posible si no habiesen construidos según el principio end-to-end " [ 3 ].
El argumento end-to-end se puede aplicar a otras áreas que diseño del sistema de redes. Transmeta ha introducido recientemente una familia nueva de microprocesadores, llamada Crusoe diseñado especialmente para los dispositivos que computación móviles. Los microprocesadores de Crusoe utilizan tecnología convencional del CMOS, Complementary Metal-Oxide Semiconductor (semiconductor complementario de óxido metálico) y son completamente x86 compatibles. Con todo estos microprocesadores se diferencian de los chips convencionales en sus capacidades de administrar la potencia: ajustan continuamente su velocidad de reloj y la fuente de voltaje, solamente a la potencia que se requiere, de ese modo conservando la vida de la batería.
Los microchips de Crusoe son interesantes no solamente debido a sus funciones -- aunque sus velocidad de 700MHz son de hecho impresionantes. Lo especialmente significativo en estos chips es la manera de la cual fueron diseñados. El acercamiento convencional al diseño del microchip implica el agregar de nuevas características a la dotación física. Este acercamiento ha sido seguido por Intel, AMD, y otros, liderando a la arquitectura del chip CISC, Complex Instruction Set Computer [1 ], que todavía continua entregandonos chips altamente eficientes. Transmeta llevó una alternativa, brindandonos el acercamiento más innovador al problema: ellos implementaron una solución del tipo end-to-end, que incluyó la dotación física y el software.
El chip en sí mismo es bastante limitado en sus capacidades, y esta encapsulada por una capa de software, que se amplía sobre sus funciones. Este diseño permite una reducción significativa en el número de transistores que consumen la energia del chip. La capa de software, llamada Code Morphing Software, implementa todas las funciones necesarias de un x86 y proporciona una interfaz a las capas sobre ella (las aplicaciones es decir, el sistema operativo y los programas del usuario final). En consecuencia, muchas funciones altamente sofisticadas son raramente usadas y no son integradas el chip y en lugar de otro no se ponen en ejecución en niveles más altos [ 6 ].
La proliferación de dispositivos móviles y la introducción de eficientes protocolos de comunicación inalámbrica han puesto nuevos requisitos en los protocolos existentes. Los protocolos actuales deben desarrollarse para resolver las necesidades de este nuevo Internet. Aunque la comunidad de la red mundial todavía no ha resuelto un númerosos asuntos , el argumento end-to-end puede probar otra vez ser efectivos en sistemas abiertos eficientes, confiables y flexibles.
Considere, por ejemplo, el problema de proporcionar a la salida confiable de los datos a la capa de aplicación en un Internet que incluya Internetcon y sin cables. Las conexiones inalambricas de hoy tienden ser encontradas en el ultimo salto de un canal de comunicaciones. Una detección de error de bajo nivel y los mecanismos de corrección pueden ser suficientes asegurar la entrega confiable. Se espera que, aunque continúen proliferando las conexiones inalambricas a traves del Internet. En este caso, la confiabilidad no se puede asegurar eficientemente a traves de una solución del tipo salto-por-salto o hop-by-hop. Un mecanismo end-to-end se convierte claramente en algo necesario.
Uno puede discutir que el hecho de incluir el TCP en la memoria limitada de un teléfono inalambrico puede no ser técnico factible o económicamente razonable. En cambio, un protocolo más simple de transporte, como el UDP, debiera ser utilizado. O quizás, uno puede evitar la capa de transporte en conjunto, que a la luz de los principios del diseño de las capas del sistema y del argumento end-to-end, les advierto contra esas aproximaciones.
He explorado las ventajas del argumento end-to-end en configuraciones de red por capas. Este argumento es de ninguna manera una regla absoluta, pero puede conducirnos a mejorar los sistemas cuando están aplicados correctamente. Cuando la confiabilidad end-to-end es necesaria, el argumento end-to-end se debe aplicar sin dificultad adicional. Incluso cuando otros metodos o aproximaciones están tentando a los diseñadores de sistemas de redes, ellos no deben pasar por alto el poder de este argumento. Finalmente, el argumento end-to-end se aplica a otras áreas del diseño del sistema, tales como la configuración de la arquitectura del ordenador, con resultados notables.
1. Hennessy, J. and Patterson, D., (1996). Computer Architecture: A Quantitative Approach, 2nd edition, Morgan-Kaufmann, 1996.
2. Peterson, L. L. and Davie, B. S., (2000). Computer Networks, 2nd edition, Morgan-Kaufmann, 2000.
3. Reed, D. P., (2000). The end of the end-to-end argument, April 2000.
4. Saltzer, H., Reed, D. P., Clark, D., (1984). " End-to-end arguments in system design", in ACM Transactions on Computing Systems, vol. 2, no. 4, 1984.
5.Stevens, W. R., (1998). UNIX Network Programming Volume 1, 2nd edition, Prentice-Hall, 1998.
6. Transmeta, (2000). The Technology Behind CrusoeTM Processors, May 2000.
Last Modified: