Sistemas de red Xerox

Xerox Network Systems (XNS) es un conjunto de protocolos de redes informáticas desarrollado por Xerox dentro de la arquitectura de sistemas de red de Xerox. Proporcionó comunicaciones de red de propósito general, enrutamiento de internetwork y entrega de paquetes, y funciones de nivel superior, como un flujo confiable y llamadas a procedimientos remotos. XNS precedió e influyó en el desarrollo del modelo de red de interconexión de sistemas abiertos (OSI), y fue muy influyente en los diseños de redes de área local durante la década de 1980.

XNS fue desarrollado por el Departamento de desarrollo de sistemas de Xerox a principios de la década de 1980, encargado de llevar la investigación de Xerox PARC al mercado. XNS se basó en la suite PARC Universal Packet (PUP) anterior (e igualmente influyente) de finales de la década de 1970. Algunos de los protocolos de la suite XNS eran versiones ligeramente modificadas de los de la suite Pup. XNS agregó el concepto de un número de red, lo que permite construir redes más grandes a partir de varias más pequeñas, con enrutadores que controlan el flujo de información entre las redes.

Las especificaciones del conjunto de protocolos para XNS se colocaron en el dominio público en 1977. Esto ayudó a que XNS se convirtiera en el protocolo de red de área local canónico, copiado en diversos grados por prácticamente todos los sistemas de red en uso en la década de 1990. XNS fue utilizado sin cambios por 3Com's 3+Share y Ungermann-Bass's Net/One. También se utilizó, con modificaciones, como base para Novell NetWare y Banyan VINES. XNS se utilizó como base para el sistema AppleNet, pero nunca se comercializó; En el reemplazo de AppleNet, AppleTalk, se utilizaron varias soluciones de XNS para problemas comunes.

Descripción

Diseño general

En comparación con las 7 capas del modelo OSI, XNS es un sistema de cinco capas, como el conjunto de protocolos de Internet posterior.

Las capas física y de enlace de datos del modelo OSI corresponden a la capa física (capa 0) en XNS, que fue diseñada para usar el mecanismo de transporte del hardware subyacente y no separó el enlace de datos. Específicamente, la capa física de XNS es realmente el sistema de red de área local de Ethernet, que Xerox también está desarrollando al mismo tiempo, y varias de sus decisiones de diseño reflejan ese hecho. El sistema fue diseñado para permitir que Ethernet fuera reemplazado por algún otro sistema, pero eso no estaba definido por el protocolo (ni tenía que estarlo).

La parte principal de XNS es su definición de la capa de transporte interno (capa 1), que corresponde a la capa de red de OSI, y es aquí donde se define el protocolo principal de interconexión de redes, IDP. XNS combinó las capas de sesión y transporte de OSI en una sola capa de comunicaciones entre procesos (capa 2). La capa 3 era Control de recursos, similar a la Presentación de OSI.

Finalmente, encima de ambos modelos, está la capa de Aplicación, aunque estas capas no estaban definidas en el estándar XNS.

Protocolo básico de interconexión de redes

El principal protocolo de la capa interred es el Protocolo de datagramas de Internet (IDP). IDP es un descendiente cercano del protocolo de interconexión de redes de Pup y corresponde aproximadamente a la capa de Protocolo de Internet (IP) en el conjunto de protocolos de Internet.

IDP usa la dirección de 48 bits de Ethernet como base para su propio direccionamiento de red, generalmente usando la dirección MAC de la máquina como el identificador único principal. A esto se le suma otra sección de dirección de 48 bits proporcionada por el equipo de red; Los enrutadores proporcionan 32 bits para identificar el número de red en la interconexión de redes, y otros 16 bits definen un número de socket para la selección de servicios dentro de un solo host. La parte del número de red de la dirección también incluye un valor especial que significa 'esta red', para uso de hosts que (todavía) no conocen su número de red.

A diferencia de TCP/IP, los números de socket son parte de la dirección de red completa en el encabezado IDP, por lo que los protocolos de capa superior no necesitan implementar la demultiplexación; IDP también proporciona tipos de paquetes (nuevamente, a diferencia de IP). IDP también contiene una suma de verificación que cubre todo el paquete, pero es opcional, no obligatoria. Esto refleja el hecho de que las LAN generalmente tienen tasas de error bajas, por lo que XNS eliminó la corrección de errores de los protocolos de nivel inferior para mejorar el rendimiento. La corrección de errores podría agregarse opcionalmente en niveles más altos en la pila de protocolos, por ejemplo, en el propio protocolo SPP de XNS. XNS fue ampliamente considerado como más rápido que IP debido a esta nota de diseño.

De acuerdo con las conexiones LAN de baja latencia en las que se ejecuta, XNS utiliza un tamaño de paquete corto, lo que mejora el rendimiento en el caso de tasas de error bajas y tiempos de respuesta cortos. Los paquetes IDP tienen una longitud máxima de 576 bytes, incluido el encabezado IDP de 30 bytes. En comparación, IP requiere que todos los hosts admitan al menos 576, pero admite paquetes de hasta 65 000 bytes. Los pares de host XNS individuales en una red en particular pueden usar paquetes más grandes, pero no se requiere un enrutador XNS para manejarlos, y no se define ningún mecanismo para descubrir si los enrutadores intermedios admiten paquetes más grandes. Además, los paquetes no se pueden fragmentar, como sí se puede en IP.

El Protocolo de información de enrutamiento (RIP), un descendiente del Protocolo de información de puerta de enlace de Pup, se usa como el sistema de intercambio de información del enrutador y (ligeramente modificado para que coincida con la sintaxis de las direcciones de otros conjuntos de protocolos), sigue en uso hoy en día en otros conjuntos de protocolos, como el conjunto de protocolos de Internet.

XNS también implementa un protocolo de eco simple en la capa de interconexión de redes, similar al ping de IP, pero que opera en un nivel más bajo en la pila de red. En lugar de agregar los datos ICMP como carga útil en un paquete IP, como en ping, el eco de XNS colocó el comando directamente dentro del paquete IDP subyacente. Lo mismo podría lograrse en IP expandiendo el campo Protocolo ICMP del encabezado IP.

Protocolos de la capa de transporte

Hay dos protocolos de capa de transporte primarios, ambos muy diferentes de su predecesor Pup:

• Protocolo de paquete secuenciado ()SPP) es un protocolo de transporte reconocido, análogo al TCP; una diferencia técnica principal es que los números de secuencia cuentan los paquetes, y no los bytes como en TCP y PUP BSP; es el antecedente directo al IPX/SPX de Novell.
• Protocolo de intercambio de paquetes ()PEP) es un protocolo no confiable sin conexión similar en la naturaleza a UDP y el antecedente de la PXP de Novell.

XNS, al igual que Pup, también utiliza EP, el Protocolo de errores, como un sistema de informes para problemas como paquetes descartados. Esto proporcionó un conjunto único de paquetes que se pueden filtrar para buscar problemas.

Protocolos de aplicación

Correo RPC

En el concepto original de Xerox, los protocolos de aplicación, como la impresión, el archivado y el envío por correo remotos, etc., empleaban un protocolo de llamada a procedimiento remoto llamado Courier. Courier contenía primitivas para implementar la mayoría de las funciones de las llamadas a funciones del lenguaje de programación Mesa de Xerox. Las aplicaciones tenían que serializar y deserializar manualmente las llamadas a funciones en Courier; no había una instalación automática que tradujera un marco de activación de función en un RPC (es decir, no había un 'compilador RPC' disponible). Debido a que Courier fue utilizado por todas las aplicaciones, los documentos del protocolo de aplicación XNS especificaban solo interfaces de llamada de función de Courier y tuplas de enlace de módulo + función. Había una instalación especial en Courier para permitir que una llamada de función enviara o recibiera datos masivos.

Inicialmente, la ubicación del servicio XNS se realizó a través de la transmisión de llamadas a procedimientos remotos utilizando una serie de transmisiones en anillo en expansión (en consulta con el enrutador local, para obtener redes a distancias cada vez mayores). creado para realizar la ubicación del servicio, y las transmisiones del anillo en expansión se usaron solo para ubicar una Cámara de compensación inicial.

Debido a su estrecha integración con Mesa como tecnología subyacente, muchos de los protocolos tradicionales de alto nivel no formaban parte del propio sistema XNS. Esto significó que los proveedores que usaban los protocolos XNS crearon sus propias soluciones para compartir archivos y admitir impresoras. Si bien, en teoría, muchos de estos productos de terceros podían comunicarse entre sí a nivel de paquete, había poca o ninguna capacidad para llamar a los servicios de aplicaciones de los demás. Esto condujo a la fragmentación completa del mercado XNS y se ha citado como una de las razones por las que IP lo desplazó fácilmente.

Autenticación

Los protocolos XNS también incluían un Protocolo de autenticación y un Servicio de autenticación para admitirlo. Sus "Credenciales sólidas" se basaron en el mismo protocolo Needham-Schroeder que luego utilizó Kerberos. Después de ponerse en contacto con el servicio de autenticación para obtener las credenciales, este protocolo proporcionó una forma sencilla de firmar digitalmente las llamadas de procedimiento de Courier, de modo que los receptores pudieran verificar la firma y autenticar a los remitentes a través de Internet XNS, sin tener que volver a ponerse en contacto con el servicio de autenticación durante la duración del protocolo. sesión de comunicación.

Impresión

El lenguaje de impresión de Xerox, Interpress, era un estándar de formato binario para controlar impresoras láser. Los diseñadores de este lenguaje, John Warnock y Chuck Geschke, luego abandonaron Xerox PARC para iniciar Adobe Systems. Antes de irse, se dieron cuenta de la dificultad de especificar un lenguaje de impresión binario, donde las funciones para serializar el trabajo de impresión eran engorrosas y dificultaban la depuración de trabajos de impresión erróneos. Para darse cuenta del valor de especificar un trabajo de impresión programable y fácilmente depurable en ASCII, Warnock y Geschke crearon el lenguaje Postscript como uno de sus primeros productos en Adobe.

Protocolos de depuración remota

Debido a que las más de 8000 máquinas en la intranet corporativa de Xerox ejecutaban la arquitectura Wildflower (diseñada por Butler Lampson), había un protocolo de depuración remota para el microcódigo. Básicamente, una función peek and poke podría detener y manipular el estado del microcódigo de una máquina de la serie C o la serie D, en cualquier parte del mundo, y luego reiniciar la máquina.

Además, había un protocolo de depuración remota para el depurador de intercambio de mundos. Este protocolo podría, a través del depurador "nub", congelar una estación de trabajo y luego inspeccionar varias partes de la memoria, cambiar variables y continuar con la ejecución. Si los símbolos de depuración estuvieran disponibles, una máquina bloqueada podría depurarse de forma remota desde cualquier lugar del mundo.

Historia

Orígenes en Ethernet y PUP

En su último año en la Universidad de Harvard, Bob Metcalfe comenzó a entrevistarse en varias empresas y Jerry Elkind y Bob Taylor de Xerox PARC le dieron una cálida bienvenida, quienes estaban comenzando a trabajar en las estaciones de trabajo informáticas en red que se convertirían en la Xerox Alto. Aceptó incorporarse al PARC en julio, luego de defender su tesis. En 1970, mientras navegaba en el sofá en la casa de Steve Crocker mientras asistía a una conferencia, Metcalfe tomó una copia de Proceedings of the Fall Joint Computer Conference de la mesa con el objetivo de quedarse dormido mientras la leía. En cambio, quedó fascinado por un artículo sobre ALOHAnet, un sistema de red de área amplia anterior. Para junio, había desarrollado sus propias teorías sobre la creación de redes y se las presentó a sus profesores, quienes las rechazaron y fue "echado de culo".

Metcalfe fue bienvenido en PARC a pesar de su tesis fallida, y pronto comenzó el desarrollo de lo que entonces se conocía como "ALOHAnet in a wire". Se asoció con David Boggs para ayudar con la implementación electrónica y, a fines de 1973, estaban construyendo hardware funcional a 3 Mbit/s. Luego, la pareja comenzó a trabajar en un protocolo simple que se ejecutaría en el sistema. Esto condujo al desarrollo del sistema PARC Universal Packet (Pup) y, a fines de 1974, los dos tenían Pup funcionando con éxito en Ethernet. Presentaron una patente sobre los conceptos, y Metcalfe agregó varios otros nombres porque creía que merecían una mención, y luego enviaron un documento sobre el concepto a Comunicaciones de la ACM sobre "Ethernet: Conmutación distribuida de paquetes para redes informáticas locales", publicado en julio de 1976.

CACHORRO a XNS

En 1975, mucho antes de que se completara PUP, Metcalfe ya estaba irritada por la rígida dirección de Xerox. Él creía que la empresa debería poner inmediatamente Ethernet en producción, pero encontró poco interés entre la alta dirección. Un evento trascendental tuvo lugar cuando los profesores del famoso Laboratorio de Inteligencia Artificial del MIT se acercaron a Xerox en 1974 con la intención de comprar Ethernet para usar en su laboratorio. La gerencia de Xerox se negó, creyendo que era mejor usar Ethernet para ayudar a vender su propio equipo. El AI Lab luego continuaría creando su propia versión de Ethernet, Chaosnet.

Metcalfe finalmente dejó Xerox en noviembre de 1975 por Transaction Technology, una división de Citibank encargada del desarrollo de productos avanzados. Sin embargo, fue atraído de nuevo a Xerox siete meses después por David Liddle, quien recientemente había organizado la División de Desarrollo de Sistemas dentro de Xerox específicamente para llevar los conceptos de PARC al mercado. Metcalfe inmediatamente comenzó a rediseñar Ethernet para que funcionara a 20 Mbit/s y comenzó un esfuerzo por reescribir Pup en una versión de calidad de producción. En busca de ayuda con Pup, Metcalfe se acercó a Yogin Dalal, quien en ese momento estaba completando su tesis con Vint Cerf en la Universidad de Stanford. Dalal también estaba siendo fuertemente reclutado por el equipo ARPANET de Bob Kahn (que trabajaba en TCP/IP), pero cuando Cerf se fue para unirse a DARPA, Dalal aceptó mudarse a PARC y comenzó allí en 1977.

Dalal formó un equipo que incluía a William Crowther y Hal Murray, y comenzó con una revisión completa de Pup. Dalal también intentó seguir involucrado en los esfuerzos de TCP en curso en DARPA, pero finalmente se dio por vencido y se centró por completo en Pup. Dalal combinó su experiencia con ARPANET con los conceptos de Pup y, a fines de 1977, publicaron el primer borrador de la especificación del sistema de red Xerox. Esta era esencialmente una versión de Pup con el concepto agregado de enchufes y una red de trabajo en red, que permitía a los enrutadores reenviar paquetes a través de redes conectadas.

A principios de 1978, el nuevo sistema estaba funcionando, pero la gerencia aún no estaba haciendo ningún movimiento para comercializarlo. Como dijo Metcalfe:

Cuando volví a Xerox en 1976, estábamos a unos dos años y medio del envío de productos y en 1978 estábamos a unos dos años y medio del envío de productos.

Cuando no se tomaron más medidas, Metcalfe dejó la empresa a fines de 1978.

Impacto

Usado por última vez por Xerox para la comunicación con el sistema de publicación DocuTech 135, XNS ya no se usa debido a la ubicuidad de IP. Sin embargo, desempeñó un papel importante en el desarrollo de la tecnología de redes en la década de 1980, al influir en los proveedores de software y hardware para que consideraran seriamente la necesidad de que las plataformas informáticas admitieran más de una pila de protocolos de red simultáneamente.

Una amplia variedad de sistemas de red patentados se basaron directamente en XNS u ofrecieron variaciones menores sobre el tema. Entre estos estaban Net/One, 3+, Banyan VINES y Novell's IPX/SPX. Estos sistemas agregaron sus propios conceptos además del sistema de enrutamiento y direccionamiento XNS; VINES agregó un servicio de directorio entre otros servicios, mientras que Novell NetWare agregó una serie de servicios orientados al usuario, como impresión y uso compartido de archivos. AppleTalk usaba enrutamiento similar a XNS, pero tenía direcciones incompatibles que usaban números más cortos.

XNS también ayudó a validar el diseño del subsistema de red 4.2BSD al proporcionar un segundo conjunto de protocolos, uno que era significativamente diferente de los protocolos de Internet; Al implementar ambas pilas en el mismo kernel, los investigadores de Berkeley demostraron que el diseño era adecuado para algo más que IP. Finalmente, se necesitaron modificaciones adicionales de BSD para admitir la gama completa de protocolos de interconexión de sistemas abiertos (OSI).